idnits 2.17.1 draft-ietf-ptopomib-mib-04.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 35 longer pages, the longest (page 2) being 111 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 36 pages 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1298 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 (11 February 2000) is 8839 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? 'RFC2026' on line 15 looks like a reference -- Missing reference section? 'RFC2571' on line 1404 looks like a reference -- Missing reference section? 'RFC1155' on line 1324 looks like a reference -- Missing reference section? 'RFC1212' on line 1331 looks like a reference -- Missing reference section? 'RFC1215' on line 1334 looks like a reference -- Missing reference section? 'RFC2578' on line 1423 looks like a reference -- Missing reference section? 'RFC2579' on line 1428 looks like a reference -- Missing reference section? 'RFC2580' on line 1432 looks like a reference -- Missing reference section? 'RFC1157' on line 1328 looks like a reference -- Missing reference section? 'RFC1901' on line 1345 looks like a reference -- Missing reference section? 'RFC1906' on line 1377 looks like a reference -- Missing reference section? 'RFC2572' on line 1408 looks like a reference -- Missing reference section? 'RFC2574' on line 1490 looks like a reference -- Missing reference section? 'RFC1905' on line 1371 looks like a reference -- Missing reference section? 'RFC2573' on line 1412 looks like a reference -- Missing reference section? 'RFC2575' on line 1491 looks like a reference -- Missing reference section? 'RFC2570' on line 1400 looks like a reference -- Missing reference section? 'RFC2737' on line 1436 looks like a reference -- Missing reference section? 'RFC2233' on line 1396 looks like a reference -- Missing reference section? 'RFC2021' on line 1384 looks like a reference -- Missing reference section? 'RFC2037' on line 1387 looks like a reference -- Missing reference section? 'RFC1493' on line 1337 looks like a reference -- Missing reference section? 'RFC2108' on line 1390 looks like a reference -- Missing reference section? 'RFC1700' on line 1342 looks like a reference -- Missing reference section? 'RFC1902' on line 1351 looks like a reference -- Missing reference section? 'RFC1903' on line 1358 looks like a reference -- Missing reference section? 'RFC1904' on line 1364 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 29 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PTOPOMIB Working Group Andy Bierman 2 Internet Draft Cisco Systems, Inc. 3 Ken Jones 4 Nortel Networks 5 11 February 2000 7 Physical Topology MIB 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026 [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this document is unlimited. Please send comments to the 32 authors. 34 1. Copyright Notice 36 Copyright (C) The Internet Society (2000). All Rights Reserved. 38 2. Abstract 40 This memo defines an experimental portion of the Management Information 41 Base (MIB) for use with network management protocols in the Internet 42 community. In particular, it describes managed objects used for 43 managing physical topology identification and discovery. 45 3. Table of Contents 47 1 Copyright Notice ................................................ 1 48 2 Abstract ........................................................ 2 49 3 Table of Contents ............................................... 2 50 4 The SNMP Network Management Framework ........................... 2 51 5 Overview ........................................................ 4 52 5.1 Terms ......................................................... 4 53 5.2 Design Goals .................................................. 5 54 6 Topology Framework .............................................. 7 55 6.1 Devices and Topology Agents ................................... 7 56 6.2 Topology Mechanisms ........................................... 7 57 6.3 Future Considerations ......................................... 8 58 7 Physical Topology MIB ........................................... 8 59 7.1 Persistent Identifiers ........................................ 8 60 7.2 Relationship to Entity MIB .................................... 9 61 7.3 Relationship to Interfaces MIB ................................ 9 62 7.4 Relationship to RMON-2 MIB .................................... 10 63 7.5 Relationship to Bridge MIB .................................... 10 64 7.6 Relationship to Repeater MIB .................................. 10 65 7.7 MIB Structure ................................................. 10 66 7.7.1 ptopoData Group ............................................. 10 67 7.7.2 ptopoGeneral Group .......................................... 11 68 7.7.3 ptopoConfig Group ........................................... 11 69 7.8 Physical Topology MIB Definitions ............................. 11 70 8 Intellectual Property ........................................... 30 71 9 Acknowledgements ................................................ 31 72 10 References ..................................................... 31 73 11 Security Considerations ........................................ 33 74 12 Authors' Addresses ............................................. 35 75 13 Full Copyright Statement ....................................... 36 77 4. The SNMP Network Management Framework 79 The SNMP Management Framework presently consists of five major 80 components: 82 o An overall architecture, described in RFC 2571 [RFC2571]. 84 o Mechanisms for describing and naming objects and events for the 85 purpose of management. The first version of this Structure of 86 Management Information (SMI) is called SMIv1 and described in 87 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 88 1215 [RFC1215]. The second version, called SMIv2, is described 89 in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 90 STD 58, RFC 2580 [RFC2580]. 92 o Message protocols for transferring management information. The 93 first version of the SNMP message protocol is called SNMPv1 and 94 described in STD 15, RFC 1157 [RFC1157]. A second version of 95 the SNMP message protocol, which is not an Internet standards 96 track protocol, is called SNMPv2c and described in RFC 1901 97 [RFC1901] and RFC 1906 [RFC1906]. The third version of the 98 message protocol is called SNMPv3 and described in RFC 1906 99 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 101 o Protocol operations for accessing management information. The 102 first set of protocol operations and associated PDU formats is 103 described in STD 15, RFC 1157 [RFC1157]. A second set of 104 protocol operations and associated PDU formats is described in 105 RFC 1905 [RFC1905]. 107 o A set of fundamental applications described in RFC 2573 108 [RFC2573] and the view-based access control mechanism described 109 in RFC 2575 [RFC2575]. 111 A more detailed introduction to the current SNMP Management Framework 112 can be found in RFC 2570 [RFC2570]. 114 Managed objects are accessed via a virtual information store, termed 115 the Management Information Base or MIB. Objects in the MIB are 116 defined using the mechanisms defined in the SMI. 118 This memo specifies a MIB module that is compliant to the SMIv2. A 119 MIB conforming to the SMIv1 can be produced through the appropriate 120 translations. The resulting translated MIB must be semantically 121 equivalent, except where objects or events are omitted because no 122 translation is possible (use of Counter64). Some machine readable 123 information in SMIv2 will be converted into textual descriptions in 124 SMIv1 during the translation process. However, this loss of machine 125 readable information is not considered to change the semantics of the 126 MIB. 128 5. Overview 130 There is a need for a standardized means of representing the physical 131 network connections pertaining to a given management domain. The 132 Physical Topology MIB (PTOPO-MIB) provides a standard way to identify 133 connections between network ports and to discover network addresses of 134 SNMP agents containing management information associated with each port. 136 A topology mechanism is used to discover the information required by the 137 PTOPO-MIB. There is a need for a standardized topology mechanism to 138 increase the likelihood of multi-vendor interoperability of such 139 physical topology management information. The PTOPO-MIB does not, 140 however, specify or restrict the discovery mechanism(s) used for an 141 implementation of the PTOPO-MIB. Topology mechanisms exist for certain 142 media types (such as FDDI) and proprietary mechanisms exist for other 143 media such as shared media Ethernet, switched Ethernet, and Token Ring. 144 Rather than specifying mechanisms for each type of technology, the 145 PTOPO-MIB allows co-existence of multiple topology mechanisms. The 146 required objects of the PTOPO-MIB define the core requirements for any 147 topology mechanism. 149 The scope of the physical topology (PTOPO) mechanism is the 150 identification of connections between two network ports. Network 151 addresses of SNMP agents containing management information associated 152 with each port can also be identified. 154 5.1. Terms 156 Some terms are used throughout this document: 158 Physical Topology 159 Physical topology represents the topology model for layer 1 of the 160 OSI stack - the physical layer. Physical topology consists of 161 identifying the devices on the network and how they are physically 162 interconnected. By definition of this document, physical topology 163 does not imply a physical relationship between ports on the same 164 device. Other means exist for determining these relationships 165 (e.g., Entity MIB [RFC2737]). exist for determining these 166 relationships Note that physical topology is independent of logical 167 topology, which associates ports based on higher layer attributes, 168 such as network layer address. 170 Chassis 171 A chassis is a physical component which contains other physical 172 components. It is identified by an entPhysicalEntry with an 173 entPhysicalClass value of 'chassis(3)' and an 174 entPhysicalContainedIn value of zero. A chassis identifier 175 consists of a globally unique DisplayString. 177 Local Chassis 178 The particular chassis containing the SNMP agent implementing the 179 PTOPO MIB. 181 Port A port is a physical component which can be connected to another 182 port through some medium. It is identified by an entPhysicalEntry 183 with an entPhysicalClass value of 'port(10)'. A port identifier 184 consists of a DisplayString which must be unique within the context 185 of the chassis which contains the port. 187 Connection Endpoint 188 A connection endpoint consists of a physical port, which is 189 contained within a single physical chassis. 191 Connection Endpoint Identifier 192 A connection endpoint is identified by a globally unique chassis 193 identifier and a port identifier unique within the associated 194 chassis. 196 Connection 197 A connection consists of two physical ports, and the attached 198 physical medium, configured for the purpose of transferring network 199 traffic between the ports. A connection is identified by its 200 endpoint identifiers. 202 Non-local Connection 203 A connection for which neither endpoint is located on the local 204 chassis. 206 Cloud 207 A cloud identifies a portion of the topology for which insufficient 208 information is known to completely infer the interconnection of 209 devices that make up that portion of the topology. 211 5.2. Design Goals 213 Several factors influenced the design of this physical topology 214 function: 216 - Simplicity 217 The physical topology discovery function should be as simple as 218 possible, exposing only the information needed to identify 219 connection endpoints and the SNMP agent(s) associated with each 220 connection endpoint. 222 - Completeness 223 At least one standard discovery protocol capable of supporting the 224 standard physical topology MIB must be defined. Multi-vendor 225 interoperability will not be achievable unless a simple and 226 extensible discovery protocol is available. However, the PTOPO MIB 227 should not specify or restrict the topology discovery mechanisms an 228 agent can use. 230 - No Functional Overlap 231 Existing standard MIBs should be utilized whenever possible. 232 Physical topology information is tightly coupled to functionality 233 found in the Interfaces MIB [RFC2233] and Entity MIB [RFC2737]. 234 New physical topology MIB objects should not duplicate these MIBs. 236 - Identifier Stability 237 Connection endpoint identifiers must be persistent (i.e. stable 238 across device reboots). Dynamic primary key objects like ifIndex 239 and entPhysicalIndex are not suitable for table indices in a 240 physical topology MIB that is replicated and distributed throughout 241 a managed system. 243 - Identifier Flexibility 244 Persistent string-based component identifiers should be supported 245 from many sources. Chassis identifiers may be found in the Entity 246 MIB [RFC2737], and port identifiers may be found in the Interfaces 247 MIB [RFC2233] or Entity MIB [RFC2737]. 249 - Partial Topology Support 250 Physical topology data for remote components may only be partially 251 available to an agent. An enumerated INTEGER hierarchy of 252 component identifier types allows for incomplete physical 253 connection identifier information to be substituted with secondary 254 information such as unicast source MAC address or network address 255 associated with a particular port. A PTOPO Agent maintains 256 information derived from the 'best' source of information for each 257 connection. If a 'better' identifier source is detected, the PTOPO 258 entries are updated accordingly. It is an implementation specific 259 matter whether a PTOPO agent replaces 'old' entries or retains 260 them, however an agent must remove information known to be 261 incorrect. 263 - Low Polling Impact 264 Physical topology polling should be minimized through techniques 265 such as TimeFiltered data tables (from RMON-2 [RFC2021]), and last- 266 change notifications. 268 6. Topology Framework 270 This section describes the physical topology framework in detail. 272 6.1. Devices and Topology Agents 274 The network devices, along with their physical connectivity, make up the 275 physical topology. Some of these devices (but maybe not all) provide 276 management agents that report their local physical topology information 277 to a manager via the physical topology MIB. 279 These devices include communication infrastructure devices, such as 280 hubs, switches, and routers, as well as 'leaf' devices such as 281 workstations, printers, and servers. Generally, user data passes 282 through infrastructure devices while leaf devices are sources and sinks 283 of data. Both types of devices may implement the physical topology MIB, 284 although implementation within leaf devices is much less critical. 286 Each managed device collects physical topology information from the 287 network, based on the topology mechanism(s) it is configured to use. 288 The data represents this agent's local view of the physical network. 289 Part of the topology data collected must include the identification of 290 other local agents which may contain additional topology information. 291 The definition of 'local' varies based on the topology mechanism or 292 mechanisms being used. 294 6.2. Topology Mechanisms 296 A topology mechanism is a means, possibly requiring some sort of 297 protocol, by which devices determine topology information. The 298 {topology mechanism must provide sufficient information to populate the 299 MIB described later in this document.} 301 Topology mechanisms can be active or passive. Active mechanisms require 302 a device to send and receive topology protocol packets. These packets 303 provide the device ID of the source of the packet and may also indicate 304 out which port the packet was transmitted. When receiving these 305 packets, devices typically are required to identify on which port that 306 packet was received. 308 Passive mechanisms take advantage of data on the network to populate the 309 topology MIB. By maintaining a list of device identifiers seen on each 310 port of all devices in a network, it is possible to populate the PTOPO- 311 MIB. 313 Many instances of a particular topology mechanism may be in use on a 314 given network, and many different mechanisms may be employed. In some 315 cases, multiple mechanisms may overlap across part of the physical 316 topology with individual ports supporting more than one topology 317 mechanism. In general, this simply allows the port to collect more 318 robust topology information. Agents may need to be configured so that 319 they know which mechanism(s) are in use on any given portion of the 320 network. 322 Most topology mechanisms need to be bounded to a subset of the network 323 to contain their impact on the network and limit the size of topology 324 tables maintained by the agent. Topology mechanisms are often naturally 325 bounded by the media on which they run (e.g. FDDI topology mechanism) or 326 by routers in the network that intentionally block the mechanism from 327 crossing into other parts of the network. 329 6.3. Future Considerations 331 While the framework presented here is focused on physical topology, it 332 may well be that the topology mechanisms and MIB described could be 333 extended to include logical topology information as well. That is not a 334 focus of this memo. 336 7. Physical Topology MIB 338 This section describes and defines the Physical Topology MIB. 340 7.1. Persistent Identifiers 342 The PTOPO MIB utilizes non-volatile identifiers to distinguish 343 individual chassis and port components. These identifiers are 344 associated with external objects in order to relate topology information 345 to the existing managed objects. 347 In particular, an object from the Entity MIB [RFC2737] or Interfaces MIB 348 [RFC2233] can be used as the 'reference-point' for a connection 349 component identifier. 351 The Physical Topology MIB uses two identifier types pertaining to the 352 PTOPO MIB: 354 - globally unique chassis identifiers. 356 - port identifiers; unique only within the chassis which contains the 357 port. 359 Identifiers are stored as OCTET STRINGs, which are limited to 32 bytes 360 in length, This supports flexible naming conventions and constrains the 361 non-volatile storage requirements for an agent. 363 7.2. Relationship to Entity MIB 365 The first version of the Entity MIB [RFC2037] allows the physical 366 component inventory and hierarchy to be identified. However, this MIB 367 does not provide persistent component identifiers, which are required 368 for the PTOPO MIB. Therefore, version 2 of the Entity MIB [RFC2737] is 369 required to support that feature. Specifically, the entPhysicalAlias 370 object is utilized as a persistent chassis identifier. 372 For agents implementing the PTOPO MIB, this new object must be used to 373 represent the chassis identifier. Port identifiers can be based on the 374 entPhysicalAlias object associated with the port, but only if the port 375 is not represented as an interface in the ifXTable. 377 Implementation of the entPhysicalGroup [RFC2737] and the 378 entPhysicalAlias object [RFC2737] are mandatory for SNMP agents which 379 implement the PTOPO MIB. No other objects must be implemented from 380 these MIBs to support the physical topology function. 382 7.3. Relationship to Interfaces MIB 384 The PTOPO MIB requires a persistent identifier for each port. The 385 Interfaces MIB [RFC2233] provides a standard mechanism for managing 386 network interfaces. Unfortunately, not all ports which may be 387 represented in the PTOPO MIB are also represented in the Interfaces MIB 388 (e.g., repeater ports). 390 For agents which implement the PTOPO MIB, for each port also represented 391 in the Interfaces MIB, the agent must use the associated ifAlias value 392 for the port identifier. For each port not represented in the 393 Interfaces MIB, the associated entPhysicalAlias value must be used for 394 the port identifier. Note that the PTOPO MIB requires only minimal 395 support from the Interfaces MIB. Specifically, the 396 'ifGeneralInformationGroup' level of conformance must be provided for 397 each port also identified in the PTOPO MIB. The agent may choose to 398 support these objects with read-only access, as specified in the 399 conformance section of the Interfaces MIB. 401 7.4. Relationship to RMON-2 MIB 403 The RMON-2 MIB [RFC2021] contains address mapping information which can 404 be integrated with physical topology information. The physical ports 405 identified in a physical topology MIB can be related to the MAC and 406 network layer addresses found in the addressMapTable. 408 7.5. Relationship to Bridge MIB 410 The Bridge MIB [RFC1493] contains information which may relate to 411 physical ports represented in the ptopoConnTable. Entries in the 412 dot1dBasePortTable and dot1dStpPortTable can by related to physical 413 ports represented in the PTOPO MIB. Also, bridge port MAC addresses may 414 be used as chassis and port identifiers in some situations. 416 7.6. Relationship to Repeater MIB 418 The Repeater MIB [RFC2108] contains information which may relate to 419 physical ports represented in the PTOPO MIB. Entries in the 420 rptrPortTable and rptrMonitorPortTable can by related to physical ports 421 represented in the ptopoConnTable. Entries in the rptrInfoTable and 422 rptrMonTable can be related to repeater backplanes possibly represented 423 in the ptopoConnTable. 425 7.7. MIB Structure 427 The PTOPO MIB contains three MIB object groups: 429 - ptopoData 430 Exposes physical topology data learned from discovery protocols 431 and/or manual configuration. 433 - ptopoGeneral 434 Contains general information regarding PTOPO MIB status. 436 - ptopoConfig 437 Contains configuration variables for the PTOPO MIB agent function. 439 7.7.1. ptopoData Group 441 This group contains a single table to identity physical topology data. 443 The ptopoConnTable contains information about the connections learned or 444 configured on behalf of the PTOPO MIB SNMP Agent. 446 7.7.2. ptopoGeneral Group 448 This group contains some scalar objects to report the status of the 449 PTOPO MIB information currently known to the SNMP Agent. The global last 450 change time, and table add and delete counters allow an NMS to set 451 threshold alarms to trigger PTOPO polling. 453 7.7.3. ptopoConfig Group 455 This group contains tables to configure the behavior of the physical 456 topology function. The transmission of ptopoLastChange notifications 457 can be configured using the ptopoConfigTrapInterval scalar MIB object. 459 7.8. Physical Topology MIB Definitions 461 PTOPO-MIB DEFINITIONS ::= BEGIN 463 IMPORTS 464 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, mib-2 465 FROM SNMPv2-SMI 466 TEXTUAL-CONVENTION, AutonomousType, RowStatus, TimeStamp, TruthValue 467 FROM SNMPv2-TC 468 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 469 FROM SNMPv2-CONF 470 TimeFilter 471 FROM RMON2-MIB 472 PhysicalIndex 473 FROM ENTITY-MIB; 475 ptopoMIB MODULE-IDENTITY 476 LAST-UPDATED "200002110000Z" 477 ORGANIZATION "IETF; PTOPOMIB Working Group" 478 CONTACT-INFO 479 "PTOPOMIB WG Discussion: 480 ptopo@3com.com 481 Subscription: 482 majordomo@3com.com 483 msg body: [un]subscribe ptopomib 485 Andy Bierman 486 Cisco Systems Inc. 487 170 West Tasman Drive 488 San Jose, CA 95134 489 408-527-3711 490 abierman@cisco.com 492 Kendall S. Jones 493 Nortel Networks 494 4401 Great America Parkway 495 Santa Clara, CA 95054 496 408-495-7356 497 kejones@nortelnetworks.com" 498 DESCRIPTION 499 "The MIB module for physical topology information." 500 REVISION "200002110000Z" 501 DESCRIPTION 502 "Initial Version of the Physical Topology MIB. This version 503 published as RFC xxxx (to be assigned by the RFC Editor)." 504 ::= { mib-2 xx } 506 ptopoMIBObjects OBJECT IDENTIFIER ::= { ptopoMIB 1 } 508 -- MIB groups 509 ptopoData OBJECT IDENTIFIER ::= { ptopoMIBObjects 1 } 510 ptopoGeneral OBJECT IDENTIFIER ::= { ptopoMIBObjects 2 } 511 ptopoConfig OBJECT IDENTIFIER ::= { ptopoMIBObjects 3 } 513 -- textual conventions 515 -- 516 -- IANAAddrFamily TC copied from 517 -- draft-ietf-disman-framework-00.txt 518 -- Eventually, it will be included from a general TC module 519 -- 520 IANAAddrFamily ::= TEXTUAL-CONVENTION 521 STATUS current 522 DESCRIPTION 523 "An address family. Values are defined in Assigned Numbers, 524 RFC1700. Note that not all these values make sense in all 525 contexts where this type is used in this MIB, but they are 526 included for completeness." 527 REFERENCE 528 "Assigned Numbers, [RFC1700], ADDRESS FAMILY NUMBERS" 529 SYNTAX INTEGER { 530 other(0), 531 ipV4(1), 532 ipV6(2), 533 nsap(3), 534 hdlc(4), 535 bbn1822(5), 536 ieee802(6), 537 e163(7), 538 e164(8), 539 f69(9), 540 x121(10), 541 ipx(11), 542 appleTalk(12), 543 decnetIV(13), 544 banyanVines(14), 545 e164WithNsap(15) 546 } 548 PtopoGenAddr ::= TEXTUAL-CONVENTION 549 STATUS current 550 DESCRIPTION 551 "The value of an address." 552 SYNTAX OCTET STRING (SIZE (0..20)) 554 PtopoChassisIdType ::= TEXTUAL-CONVENTION 555 STATUS current 556 DESCRIPTION 557 "This TC describes the source of a chassis identifier. 559 The enumeration 'chasIdEntPhysicalAlias(1)' represents a 560 chassis identifier based on the value of entPhysicalAlias 561 for a chassis component (i.e., an entPhysicalClass value of 562 'chassis(3)'). 564 The enumeration 'chasIdIfAlias(2)' represents a chassis 565 identifier based on the value of ifAlias for an interface on 566 the containing chassis. 568 The enumeration 'chasIdPortEntPhysicalAlias(3)' represents a 569 chassis identifier based on the value of entPhysicalAlias 570 for a port or backplane component (i.e., entPhysicalClass 571 value of 'port(10)' or 'backplane(4)'), within the 572 containing chassis. 574 The enumeration 'chasIdMacAddress(4)' represents a chassis 575 identifier based on the value of a unicast source MAC 576 address (encoded in network byte order and IEEE 802.3 577 canonical bit order), of a port on the containing chassis. 579 The enumeration 'chasIdPtopoGenAddr(5)' represents a chassis 580 identifier based on a network address, associated with a 581 particular chassis. The encoded address is actually 582 composed of two fields. The first field is a single octet, 583 representing the IANAAddrFamily for the specific address 584 type, and the second field is the PtopoGenAddr address 585 value." 586 SYNTAX INTEGER { 587 chasIdEntPhysicalAlias(1), 588 chasIdIfAlias(2), 589 chasIdPortEntPhysicalAlias(3), 590 chasIdMacAddress(4), 591 chasIdPtopoGenAddr(5) 592 } 594 PtopoChassisId ::= TEXTUAL-CONVENTION 595 STATUS current 596 DESCRIPTION 597 "This TC describes the format of a chassis identifier 598 string. Objects of this type are always used with an 599 associated PtopoChassisIdType object, which identifies the 600 format of the particular PtopoChassisId object instance. 602 If the associated PtopoChassisIdType object has a value of 603 'chasIdEntPhysicalAlias(1)', then the octet string 604 identifies a particular instance of the entPhysicalAlias 605 object for a chassis component (i.e., an entPhysicalClass 606 value of 'chassis(3)'). 608 If the associated PtopoChassisIdType object has a value of 609 'chasIdIfAlias(2)', then the octet string identifies a 610 particular instance of the ifAlias object for an interface 611 on the containing chassis. 613 If the associated PtopoChassisIdType object has a value of 614 'chasIdPortEntPhysicalAlias(3)', then the octet string 615 identifies a particular instance of the entPhysicalAlias 616 object for a port or backplane component within the 617 containing chassis. 619 If the associated PtopoChassisIdType object has a value of 620 'chasIdMacAddress(4)', then this string identifies a 621 particular unicast source MAC address (encoded in network 622 byte order and IEEE 802.3 canonical bit order), of a port on 623 the containing chassis. 625 If the associated PtopoChassisIdType object has a value of 626 'chasIdPtopoGenAddr(5)', then this string identifies a 627 particular network address, encoded in network byte order, 628 associated with one or more ports on the containing chassis. 629 The first octet contains the IANAAddrFamily enumeration 630 value for the specific address type, and octets 2 through N 631 contain the PtopoGenAddr address value in network byte 632 order." 633 SYNTAX OCTET STRING (SIZE (1..32)) 635 PtopoPortIdType ::= TEXTUAL-CONVENTION 636 STATUS current 637 DESCRIPTION 638 "This TC describes the source of a particular type of port 639 identifier used in the PTOPO MIB. 641 The enumeration 'portIdIfAlias(1)' represents a port 642 identifier based on the ifAlias MIB object. 644 The enumeration 'portIdPortEntPhysicalAlias(2)' represents a 645 port identifier based on the value of entPhysicalAlias for a 646 port or backplane component (i.e., entPhysicalClass value of 647 'port(10)' or 'backplane(4)'), within the containing 648 chassis. 650 The enumeration 'portIdMacAddr(3)' represents a port 651 identifier based on a unicast source MAC address, which has 652 been detected by the agent and associated with a particular 653 port. 655 The enumeration 'portIdPtopoGenAddr(4)' represents a port 656 identifier based on a network address, detected by the agent 657 and associated with a particular port." 658 SYNTAX INTEGER { 659 portIdIfAlias(1), 660 portIdEntPhysicalAlias(2), 661 portIdMacAddr(3), 662 portIdPtopoGenAddr(4) 663 } 665 PtopoPortId ::= TEXTUAL-CONVENTION 666 STATUS current 667 DESCRIPTION 668 "This TC describes the format of a port identifier string. 669 Objects of this type are always used with an associated 670 PtopoPortIdType object, which identifies the format of the 671 particular PtopoPortId object instance. 673 If the associated PtopoPortIdType object has a value of 674 'portIdIfAlias(1)', then the octet string identifies a 675 particular instance of the ifAlias object. 677 If the associated PtopoPortIdType object has a value of 678 'portIdEntPhysicalAlias(2)', then the octet string 679 identifies a particular instance of the entPhysicalAlias 680 object for a port component (i.e., entPhysicalClass value of 681 'port(10)'). 683 If the associated PtopoPortIdType object has a value of 684 'portIdMacAddr(3)', then this string identifies a particular 685 unicast source MAC address associated with the port. 687 If the associated PtopoPortIdType object has a value of 688 'portIdPtopoGenAddr(4)', then this string identifies a 689 network address associated with the port. The first octet 690 contains the IANAAddrFamily enumeration value for the 691 specific address type, and octets 2 through N contain the 692 PtopoGenAddr address value in network byte order." 693 SYNTAX OCTET STRING (SIZE (1..32)) 695 PtopoAddrSeenState ::= TEXTUAL-CONVENTION 696 STATUS current 697 DESCRIPTION 698 "This TC describes the state of address detection for a 699 particular type of port identifier used in the PTOPO MIB. 701 The enumeration 'not-used(1)' represents an entry for which 702 the particular MIB object is not applicable to the remote 703 connection endpoint, 705 The enumeration 'unknown(2)' represents an entry for which 706 the particular address collection state is not known. 708 The enumeration 'one-addr(3)' represents an entry for which 709 exactly one source address (of the type indicated by the 710 particular MIB object), has been detected. 712 The enumeration 'multi-addr(4)' represents an entry for 713 which more than one source address (of the type indicated by 714 the particular MIB object), has been detected. 716 An agent is expected to set the initial state of the 717 PtopoAddrSeenState to 'not-used(1)' or 'unknown(2)'. 719 Note that the PTOPO MIB does not restrict or specify the 720 means in which the PtopoAddrSeenState is known to an agent. 721 In particular, an agent may detect this information through 722 configuration data, or some means other than directly 723 monitoring all port traffic." 724 SYNTAX INTEGER { 725 not-used(1), 726 unknown(2), 727 one-addr(3), 728 multi-addr(4) 729 } 731 -- *********************************************************** 732 -- 733 -- P T O P O D A T A G R O U P 734 -- 735 -- *********************************************************** 737 -- Connection Table 739 ptopoConnTable OBJECT-TYPE 740 SYNTAX SEQUENCE OF PtopoConnEntry 741 MAX-ACCESS not-accessible 742 STATUS current 743 DESCRIPTION 744 "This table contains one or more rows per physical network 745 connection known to this agent. The agent may wish to 746 ensure that only one ptopoConnEntry is present for each 747 local port, or it may choose to maintain multiple 748 ptopoConnEntries for the same local port. 750 Entries based on lower numbered identifier types are 751 preferred over higher numbered identifier types, i.e., lower 752 values of the ptopoConnRemoteChassisType and 753 ptopoConnRemotePortType objects." 754 ::= { ptopoData 1 } 756 ptopoConnEntry OBJECT-TYPE 757 SYNTAX PtopoConnEntry 758 MAX-ACCESS not-accessible 759 STATUS current 760 DESCRIPTION 761 "Information about a particular physical network connection. 762 Entries may be created and deleted in this table, either 763 manually or by the agent, if a physical topology discovery 764 process is active." 765 INDEX { 766 ptopoConnTimeMark, 767 ptopoConnLocalChassis, 768 ptopoConnLocalPort, 769 ptopoConnIndex 770 } 771 ::= { ptopoConnTable 1 } 773 PtopoConnEntry ::= SEQUENCE { 774 ptopoConnTimeMark TimeFilter, 775 ptopoConnLocalChassis PhysicalIndex, 776 ptopoConnLocalPort PhysicalIndex, 777 ptopoConnIndex Integer32, 778 ptopoConnRemoteChassisType PtopoChassisIdType, 779 ptopoConnRemoteChassis PtopoChassisId, 780 ptopoConnRemotePortType PtopoPortIdType, 781 ptopoConnRemotePort PtopoPortId, 782 ptopoConnDiscAlgorithm AutonomousType, 783 ptopoConnAgentNetAddrType IANAAddrFamily, 784 ptopoConnAgentNetAddr PtopoGenAddr, 785 ptopoConnMultiMacSASeen PtopoAddrSeenState, 786 ptopoConnMultiNetSASeen PtopoAddrSeenState, 787 ptopoConnIsStatic TruthValue, 788 ptopoConnLastVerifyTime TimeStamp, 789 ptopoConnRowStatus RowStatus 790 } 792 ptopoConnTimeMark OBJECT-TYPE 793 SYNTAX TimeFilter 794 MAX-ACCESS not-accessible 795 STATUS current 796 DESCRIPTION 797 "A TimeFilter for this entry. See the TimeFilter textual 798 convention in RFC 2021 to see how this works." 799 ::= { ptopoConnEntry 1 } 801 ptopoConnLocalChassis OBJECT-TYPE 802 SYNTAX PhysicalIndex 803 MAX-ACCESS not-accessible 804 STATUS current 805 DESCRIPTION 806 "The entPhysicalIndex value used to identify the chassis 807 component associated with the local connection endpoint." 808 ::= { ptopoConnEntry 2 } 810 ptopoConnLocalPort OBJECT-TYPE 811 SYNTAX PhysicalIndex 812 MAX-ACCESS not-accessible 813 STATUS current 814 DESCRIPTION 815 "The entPhysicalIndex value used to identify the port 816 component associated with the local connection endpoint." 817 ::= { ptopoConnEntry 3 } 819 ptopoConnIndex OBJECT-TYPE 820 SYNTAX Integer32 (1..2147483647) 821 MAX-ACCESS not-accessible 822 STATUS current 823 DESCRIPTION 824 "This object represents an arbitrary local integer value 825 used by this agent to identify a particular connection 826 instance, unique only for the indicated local connection 827 endpoint. 829 A particular ptopoConnIndex value may be reused in the event 830 an entry is aged out and later re-learned with the same (or 831 different) remote chassis and port identifiers. 833 An agent is encouraged to assign monotonically increasing 834 index values to new entries, starting with one, after each 835 reboot. It is considered unlikely that the ptopoConnIndex 836 will wrap between reboots." 837 ::= { ptopoConnEntry 4 } 839 ptopoConnRemoteChassisType OBJECT-TYPE 840 SYNTAX PtopoChassisIdType 841 MAX-ACCESS read-create 842 STATUS current 843 DESCRIPTION 844 "The type of encoding used to identify the chassis 845 associated with the remote connection endpoint. 847 This object may not be modified if the associated 848 ptopoConnRowStatus object has a value of active(1)." 850 ::= { ptopoConnEntry 5 } 852 ptopoConnRemoteChassis OBJECT-TYPE 853 SYNTAX PtopoChassisId 854 MAX-ACCESS read-create 855 STATUS current 856 DESCRIPTION 857 "The string value used to identify the chassis component 858 associated with the remote connection endpoint. 860 This object may not be modified if the associated 861 ptopoConnRowStatus object has a value of active(1)." 862 ::= { ptopoConnEntry 6 } 864 ptopoConnRemotePortType OBJECT-TYPE 865 SYNTAX PtopoPortIdType 866 MAX-ACCESS read-create 867 STATUS current 868 DESCRIPTION 869 "The type of port identifier encoding used in the associated 870 'ptopoConnRemotePort' object. 872 This object may not be modified if the associated 873 ptopoConnRowStatus object has a value of active(1)." 874 ::= { ptopoConnEntry 7 } 876 ptopoConnRemotePort OBJECT-TYPE 877 SYNTAX PtopoPortId 878 MAX-ACCESS read-create 879 STATUS current 880 DESCRIPTION 881 "The string value used to identify the port component 882 associated with the remote connection endpoint. 884 This object may not be modified if the associated 885 ptopoConnRowStatus object has a value of active(1)." 886 ::= { ptopoConnEntry 8 } 888 ptopoConnDiscAlgorithm OBJECT-TYPE 889 SYNTAX AutonomousType 890 MAX-ACCESS read-only 891 STATUS current 892 DESCRIPTION 893 "An indication of the algorithm used to discover the 894 information contained in this conceptual row. 896 A value of ptopoDiscoveryLocal indicates this entry was 897 configured by the local agent, without use of a discovery 898 protocol. 900 A value of { 0 0 } indicates this entry was created manually 901 by an NMS via the associated RowStatus object. " 902 ::= { ptopoConnEntry 9 } 904 ptopoConnAgentNetAddrType OBJECT-TYPE 905 SYNTAX IANAAddrFamily 906 MAX-ACCESS read-create 907 STATUS current 908 DESCRIPTION 909 "This network address type of the associated 910 ptopoConnNetAddr object, unless that object contains a zero 911 length string. In such a case, an NMS application should 912 ignore any returned value for this object. 914 This object may not be modified if the associated 915 ptopoConnRowStatus object has a value of active(1)." 916 ::= { ptopoConnEntry 10 } 918 ptopoConnAgentNetAddr OBJECT-TYPE 919 SYNTAX PtopoGenAddr 920 MAX-ACCESS read-create 921 STATUS current 922 DESCRIPTION 923 "This object identifies a network address which may be used 924 to reach an SNMP agent entity containing information for the 925 chassis and port components represented by the associated 926 'ptopoConnRemoteChassis' and 'ptopoConnRemotePort' objects. 927 If no such address is known, then this object shall contain 928 an empty string. 930 This object may not be modified if the associated 931 ptopoConnRowStatus object has a value of active(1)." 932 ::= { ptopoConnEntry 11 } 934 ptopoConnMultiMacSASeen OBJECT-TYPE 935 SYNTAX PtopoAddrSeenState 936 MAX-ACCESS read-only 937 STATUS current 938 DESCRIPTION 939 "This object indicates if multiple unicast source MAC 940 addresses have been detected by the agent from the remote 941 connection endpoint, since the creation of this entry. 943 If this entry has an associated ptopoConnRemoteChassisType 944 and/or ptopoConnRemotePortType value other than 945 'portIdMacAddr(3)', then the value 'not-used(1)' is 946 returned. 948 Otherwise, one of the following conditions must be true: 950 If the agent has not yet detected any unicast source MAC 951 addresses from the remote port, then the value 'unknown(2)' 952 is returned. 954 If the agent has detected exactly one unicast source MAC 955 address from the remote port, then the value 'one-addr(3)' 956 is returned. 958 If the agent has detected more than one unicast source MAC 959 address from the remote port, then the value 'multi-addr(4)' 960 is returned." 961 ::= { ptopoConnEntry 12 } 963 ptopoConnMultiNetSASeen OBJECT-TYPE 964 SYNTAX PtopoAddrSeenState 965 MAX-ACCESS read-only 966 STATUS current 967 DESCRIPTION 968 "This object indicates if multiple network layer source 969 addresses have been detected by the agent from the remote 970 connection endpoint, since the creation of this entry. 972 If this entry has an associated ptopoConnRemoteChassisType 973 or ptopoConnRemotePortType value other than 974 'portIdGenAddr(4)' then the value 'not-used(1)' is returned. 976 Otherwise, one of the following conditions must be true: 978 If the agent has not yet detected any network source 979 addresses of the appropriate type from the remote port, then 980 the value 'unknown(2)' is returned. 982 If the agent has detected exactly one network source address 983 of the appropriate type from the remote port, then the value 984 'one-addr(3)' is returned. 986 If the agent has detected more than one network source 987 address (of the same appropriate type) from the remote port, 988 this the value 'multi-addr(4)' is returned." 989 ::= { ptopoConnEntry 13 } 991 ptopoConnIsStatic OBJECT-TYPE 992 SYNTAX TruthValue 993 MAX-ACCESS read-create 994 STATUS current 995 DESCRIPTION 996 "This object identifies static ptopoConnEntries. If this 997 object has the value 'true(1)', then this entry is not 998 subject to any age-out mechanisms implemented by the agent. 1000 If this object has the value 'false(2)', then this entry is 1001 subject to all age-out mechanisms implemented by the agent. 1003 This object may not be modified if the associated 1004 ptopoConnRowStatus object has a value of active(1)." 1005 DEFVAL { false } 1006 ::= { ptopoConnEntry 14 } 1008 ptopoConnLastVerifyTime OBJECT-TYPE 1009 SYNTAX TimeStamp 1010 MAX-ACCESS read-only 1011 STATUS current 1012 DESCRIPTION 1013 "If the associated value of ptopoConnIsStatic is equal to 1014 'false(2)', then this object contains the value of sysUpTime 1015 at the time the conceptual row was last verified by the 1016 agent, e.g., via reception of a topology protocol message, 1017 pertaining to the associated remote chassis and port. 1019 If the associated value of ptopoConnIsStatic is equal to 1020 'true(1)', then this object shall contain the value of 1021 sysUpTime at the time this entry was last activated (i.e., 1022 ptopoConnRowStatus set to 'active(1)')." 1023 ::= { ptopoConnEntry 15 } 1025 ptopoConnRowStatus OBJECT-TYPE 1026 SYNTAX RowStatus 1027 MAX-ACCESS read-create 1028 STATUS current 1029 DESCRIPTION 1030 "The status of this conceptual row." 1032 ::= { ptopoConnEntry 16 } 1034 -- *********************************************************** 1035 -- 1036 -- P T O P O G E N E R A L G R O U P 1037 -- 1038 -- *********************************************************** 1040 -- last change time stamp for the whole MIB 1042 ptopoLastChangeTime OBJECT-TYPE 1043 SYNTAX TimeStamp 1044 MAX-ACCESS read-only 1045 STATUS current 1046 DESCRIPTION 1047 "The value of sysUpTime at the time a conceptual row is 1048 created, modified, or deleted in the ptopoConnTable. 1050 An NMS can use this object to reduce polling of the 1051 ptopoData group objects." 1052 ::= { ptopoGeneral 1 } 1054 ptopoConnTabInserts OBJECT-TYPE 1055 SYNTAX Counter32 1056 MAX-ACCESS read-only 1057 STATUS current 1058 DESCRIPTION 1059 "The number of times an entry has been inserted into the 1060 ptopoConnTable." 1061 ::= { ptopoGeneral 2 } 1063 ptopoConnTabDeletes OBJECT-TYPE 1064 SYNTAX Counter32 1065 MAX-ACCESS read-only 1066 STATUS current 1067 DESCRIPTION 1068 "The number of times an entry has been deleted from the 1069 ptopoConnTable." 1070 ::= { ptopoGeneral 3 } 1072 ptopoConnTabDrops OBJECT-TYPE 1073 SYNTAX Counter32 1074 MAX-ACCESS read-only 1075 STATUS current 1076 DESCRIPTION 1077 "The number of times an entry would have been added to the 1078 ptopoConnTable, (e.g., via information learned from a 1079 topology protocol), but was not because of insufficient 1080 resources." 1081 ::= { ptopoGeneral 4 } 1083 ptopoConnTabAgeouts OBJECT-TYPE 1084 SYNTAX Counter32 1085 MAX-ACCESS read-only 1086 STATUS current 1087 DESCRIPTION 1088 "The number of times an entry has been deleted from the 1089 ptopoConnTable because the information timeliness interval 1090 for that entry has expired." 1091 ::= { ptopoGeneral 5 } 1093 -- *********************************************************** 1094 -- 1095 -- P T O P O C O N F I G G R O U P 1096 -- 1097 -- *********************************************************** 1099 ptopoConfigTrapInterval OBJECT-TYPE 1100 SYNTAX Integer32 (0 | 5..3600) 1101 UNITS "seconds" 1102 MAX-ACCESS read-write 1103 STATUS current 1104 DESCRIPTION 1105 "This object controls the transmission of PTOPO 1106 notifications. 1108 If this object has a value of zero, then no 1109 ptopoConfigChange notifications will be transmitted by the 1110 agent. 1112 If this object has a non-zero value, then the agent must not 1113 generate more than one ptopoConfigChange trap-event in the 1114 indicated period, where a 'trap-event' is the transmission 1115 of a single notification PDU type to a list of notification 1116 destinations. If additional configuration changes occur 1117 within the indicated throttling period, then these trap- 1118 events must be suppressed by the agent. An NMS should 1119 periodically check the value of ptopoLastChangeTime to 1120 detect any missed ptopoConfigChange trap-events, e.g. due to 1121 throttling or transmission loss. 1123 If notification transmission is enabled, the suggested 1124 default throttling period is 60 seconds, but transmission 1125 should be disabled by default. 1127 If the agent is capable of storing non-volatile 1128 configuration, then the value of this object must be 1129 restored after a re-initialization of the management 1130 system." 1131 DEFVAL { 0 } 1132 ::= { ptopoConfig 1 } 1134 ptopoConfigMaxHoldTime OBJECT-TYPE 1135 SYNTAX Integer32 (1..2147483647) 1136 UNITS "seconds" 1137 MAX-ACCESS read-write 1138 STATUS current 1139 DESCRIPTION 1140 "This object specifies the desired time interval for which 1141 an agent will maintain dynamic ptopoConnEntries. 1143 After the specified number of seconds since the last time an 1144 entry was verified, in the absence of new verification 1145 (e.g., receipt of a topology protocol message), the agent 1146 shall remove the entry. Note that entries may not always be 1147 removed immediately, but may possibly be removed at periodic 1148 garbage collection intervals. 1150 This object only affects dynamic ptopoConnEntries, i.e. for 1151 which ptopoConnIsStatic equals 'false(2)'. Static entries 1152 are not aged out. 1154 Note that dynamic ptopoConnEntries may also be removed by 1155 the agent due to the expired timeliness of learned topology 1156 information (e.g., timeliness interval for a remote port 1157 expires). The actual age-out interval for a given entry is 1158 defined by the following formula: 1160 age-out-time = 1161 min(ptopoConfigMaxHoldTime, ) 1163 where is determined by the 1164 discovery algorithm, and may be different for each entry. 1165 DEFVAL { 300 } 1166 ::= { ptopoConfig 2 } 1168 -- PTOPO MIB Notification Definitions 1169 ptopoMIBNotifications OBJECT IDENTIFIER ::= { ptopoMIB 2 } 1170 ptopoMIBTrapPrefix OBJECT IDENTIFIER ::= 1171 { ptopoMIBNotifications 0 } 1173 ptopoConfigChange NOTIFICATION-TYPE 1174 OBJECTS { 1175 ptopoConnTabInserts, 1176 ptopoConnTabDeletes, 1177 ptopoConnTabDrops, 1178 ptopoConnTabAgeouts 1179 } 1180 STATUS current 1181 DESCRIPTION 1182 "A ptopoConfigChange notification is sent when the value of 1183 ptopoLastChangeTime changes. It can be utilized by an NMS to 1184 trigger physical topology table maintenance polls. 1186 Note that transmission of ptopoConfigChange notifications 1187 are throttled by the agent, as specified by the 1188 'ptopoConfigTrapInterval' object." 1189 ::= { ptopoMIBTrapPrefix 1 } 1191 -- PTOPO Registration Points 1192 ptopoRegistrationPoints OBJECT IDENTIFIER ::= { ptopoMIB 3 } 1194 -- values used with ptopoConnDiscAlgorithm object 1195 ptopoDiscoveryMechanisms OBJECT IDENTIFIER ::= 1196 { ptopoRegistrationPoints 1 } 1198 ptopoDiscoveryLocal OBJECT IDENTIFIER ::= 1199 { ptopoDiscoveryMechanisms 1 } 1201 -- conformance information 1202 ptopoConformance OBJECT IDENTIFIER ::= { ptopoMIB 4 } 1204 ptopoCompliances OBJECT IDENTIFIER ::= { ptopoConformance 1 } 1205 ptopoGroups OBJECT IDENTIFIER ::= { ptopoConformance 2 } 1207 -- compliance statements 1209 ptopoCompliance MODULE-COMPLIANCE 1210 STATUS current 1211 DESCRIPTION 1212 "The compliance statement for SNMP entities which implement 1213 the PTOPO MIB." 1214 MODULE -- this module 1215 MANDATORY-GROUPS { 1216 ptopoDataGroup, 1217 ptopoGeneralGroup, 1218 ptopoConfigGroup, 1219 ptopoNotificationsGroup 1220 } 1221 ::= { ptopoCompliances 1 } 1223 -- MIB groupings 1225 ptopoDataGroup OBJECT-GROUP 1226 OBJECTS { 1227 ptopoConnRemoteChassisType, 1228 ptopoConnRemoteChassis, 1229 ptopoConnRemotePortType, 1230 ptopoConnRemotePort, 1231 ptopoConnDiscAlgorithm, 1232 ptopoConnAgentNetAddrType, 1233 ptopoConnAgentNetAddr, 1234 ptopoConnMultiMacSASeen, 1235 ptopoConnMultiNetSASeen, 1236 ptopoConnIsStatic, 1237 ptopoConnLastVerifyTime, 1238 ptopoConnRowStatus 1239 } 1240 STATUS current 1241 DESCRIPTION 1242 "The collection of objects which are used to represent 1243 physical topology information for which a single agent 1244 provides management information. 1246 This group is mandatory for all implementations of the PTOPO 1247 MIB." 1248 ::= { ptopoGroups 1 } 1250 ptopoGeneralGroup OBJECT-GROUP 1251 OBJECTS { 1252 ptopoLastChangeTime, 1253 ptopoConnTabInserts, 1254 ptopoConnTabDeletes, 1255 ptopoConnTabDrops, 1256 ptopoConnTabAgeouts 1257 } 1258 STATUS current 1259 DESCRIPTION 1260 "The collection of objects which are used to report the 1261 general status of the PTOPO MIB implementation. 1263 This group is mandatory for all agents which implement the 1264 PTOPO MIB." 1265 ::= { ptopoGroups 2 } 1267 ptopoConfigGroup OBJECT-GROUP 1268 OBJECTS { 1269 ptopoConfigTrapInterval, 1270 ptopoConfigMaxHoldTime 1271 } 1272 STATUS current 1273 DESCRIPTION 1274 "The collection of objects which are used to configure the 1275 PTOPO MIB implementation behavior. 1277 This group is mandatory for agents which implement the PTOPO 1278 MIB." 1279 ::= { ptopoGroups 3 } 1281 ptopoNotificationsGroup NOTIFICATION-GROUP 1282 NOTIFICATIONS { 1283 ptopoConfigChange 1284 } 1285 STATUS current 1286 DESCRIPTION 1287 "The collection of notifications used to indicate PTOPO MIB 1288 data consistency and general status information. 1290 This group is mandatory for agents which implement the PTOPO 1291 MIB." 1292 ::= { ptopoGroups 4 } 1294 END 1295 8. Intellectual Property 1297 The IETF takes no position regarding the validity or scope of any 1298 intellectual property or other rights that might be claimed to pertain 1299 to the implementation or use of the technology described in this 1300 document or the extent to which any license under such rights might or 1301 might not be available; neither does it represent that it has made any 1302 effort to identify any such rights. Information on the IETF's 1303 procedures with respect to rights in standards-track and standards- 1304 related documentation can be found in BCP-11. Copies of claims of 1305 rights made available for publication and any assurances of licenses to 1306 be made available, or the result of an attempt made to obtain a general 1307 license or permission for the use of such proprietary rights by 1308 implementors or users of this specification can be obtained from the 1309 IETF Secretariat. 1311 The IETF invites any interested party to bring to its attention any 1312 copyrights, patents or patent applications, or other proprietary rights 1313 which may cover technology that may be required to practice this 1314 standard. Please address the information to the IETF Executive 1315 Director. 1317 9. Acknowledgements 1319 The PTOPO Discovery Protocol is a product of the IETF PTOPOMIB Working 1320 Group. 1322 10. References 1324 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 1325 of Management Information for TCP/IP-based Internets", STD 1326 16, RFC 1155, May 1990. 1328 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1329 Network Management Protocol", STD 15, RFC 1157, May 1990. 1331 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 1332 16, RFC 1212, March 1991. 1334 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 1335 SNMP", RFC 1215, March 1991. 1337 [RFC1493] Decker, E., Langille, P., Rijsinghani, A., and K. 1338 McCloghrie, "Definitions of Managed Objects for Bridges", 1339 RFC 1493, Cisco Systems, Inc., Digital Equipment 1340 Corporation, Hughes LAN Systems, Inc., July 1993. 1342 [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1343 1700, USC/Information Sciences Institute, October 1994. 1345 [RFC1901] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 1346 and S. Waldbusser, "Introduction to Community-based SNMPv2", 1347 RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover 1348 Beach Consulting, Inc., International Network Services, 1349 January 1996. 1351 [RFC1902] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 1352 and S. Waldbusser, "Structure of Management Information for 1353 version 2 of the Simple Network Management Protocol 1354 (SNMPv2)", RFC 1902, SNMP Research, Inc., Cisco Systems, 1355 Inc., Dover Beach Consulting, Inc., International Network 1356 Services, January 1996. 1358 [RFC1903] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 1359 and S. Waldbusser, "Textual Conventions for version 2 of the 1360 Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP 1361 Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 1362 Inc., International Network Services, January 1996. 1364 [RFC1904] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 1365 and S. Waldbusser, "Conformance Statements for version 2 of 1366 the Simple Network Management Protocol (SNMPv2)", RFC 1904, 1367 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach 1368 Consulting, Inc., International Network Services, January 1369 1996. 1371 [RFC1905] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 1372 and S. Waldbusser, "Protocol Operations for Version 2 of the 1373 Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP 1374 Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 1375 Inc., International Network Services, January 1996. 1377 [RFC1906] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 1378 and S. Waldbusser, "Transport Mappings for Version 2 of the 1379 Simple Network Management Protocol (SNMPv2)"", RFC 1906, 1380 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach 1381 Consulting, Inc., International Network Services, January 1382 1996. 1384 [RFC2021] S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 1385 2021, International Network Services, January 1997. 1387 [RFC2037] McCloghrie, K., and A. Bierman, "Entity MIB using SMIv2", 1388 RFC 2037, Cisco Systems, October 1996. 1390 [RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K. 1391 McCloghrie, "Definitions of Managed Objects for IEEE 802.3 1392 Repeater Devices using SMIv2", RFC 2108, 3Com Corporation, 1393 Madge Networks (Israel) Ltd., Coloma Communications, Cisco 1394 Systems Inc., February 1997. 1396 [RFC2233] McCloghrie, K., and F. Kastenholtz, "The Interfaces Group 1397 MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software, 1398 November 1997. 1400 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 1401 "Introduction to Version 3 of the Internet-standard Network 1402 Management Framework", RFC 2570, April 1999. 1404 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 1405 for Describing SNMP Management Frameworks", RFC 2571, April 1406 1999. 1408 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1409 Processing and Dispatching for the Simple Network Management 1410 Protocol (SNMP)", RFC 2572, April 1999. 1412 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 1413 RFC 2573, April 1999. 1415 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 1416 (USM) for version 3 of the Simple Network Management 1417 Protocol (SNMPv3)", RFC 2574, April 1999. 1419 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 1420 Access Control Model (VACM) for the Simple Network 1421 Management Protocol (SNMP)", RFC 2575, April 1999. 1423 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1424 Rose, M., and S. Waldbusser, "Structure of Management 1425 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1426 1999. 1428 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1429 Rose, M., and S. Waldbusser, "Textual Conventions for 1430 SMIv2", STD 58, RFC 2579, April 1999. 1432 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1433 Rose, M., and S. Waldbusser, "Conformance Statements for 1434 SMIv2", STD 58, RFC 2580, April 1999. 1436 [RFC2737] McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", 1437 RFC 2737, Cisco Systems, December 1999. 1439 11. Security Considerations 1441 There are a number of management objects defined in this MIB that have a 1442 MAX-ACCESS clause of read-write and/or read-create. Such objects may be 1443 considered sensitive or vulnerable in some network environments. The 1444 support for SET operations in a non-secure environment without proper 1445 protection can have a negative effect on network operations. 1447 There are a number of managed objects in this MIB that may contain 1448 sensitive information. These are: 1450 read-create objects: 1451 ptopoConnRemoteChassisType 1452 ptopoConnRemoteChassis 1453 ptopoConnRemotePortType 1454 ptopoConnRemotePort 1455 ptopoConnAgentNetAddrType 1456 ptopoConnAgentNetAddr 1457 ptopoConnIsStatic 1458 ptopoConfigTrapInterval 1459 ptopoConfigMaxHoldTime 1461 read-only objects: 1462 ptopoConnDiscAlgorithm 1463 ptopoConnMultiMacSASeen 1464 ptopoConnMultiNetSASeen 1465 ptopoConnLastVerifyTime 1466 ptopoLastChangeTime 1468 notifications: 1469 ptopoConfigChange 1471 These MIB objects expose information about the physical connectivity for 1472 a particular portion of a network. 1474 A network administrator may also wish to inhibit transmission of any 1475 ptopoConfigChange notification by setting the ptopoConfigTrapInterval 1476 object to zero. 1478 It is thus important to control even GET access to these objects and 1479 possibly to even encrypt the values of these object when sending them 1480 over the network via SNMP. Not all versions of SNMP provide features 1481 for such a secure environment. 1483 SNMPv1 by itself is not a secure environment. Even if the network 1484 itself is secure (for example by using IPSec), even then, there is no 1485 control as to who on the secure network is allowed to access and GET/SET 1486 (read/change/create/delete) the objects in this MIB. 1488 It is recommended that the implementers consider the security features 1489 as provided by the SNMPv3 framework. Specifically, the use of the User- 1490 based Security Model RFC 2574 [RFC2574] and the View- based Access 1491 Control Model RFC 2575 [RFC2575] is recommended. 1493 It is then a customer/user responsibility to ensure that the SNMP entity 1494 giving access to an instance of this MIB, is properly configured to give 1495 access to the objects only to those principals (users) that have 1496 legitimate rights to indeed GET or SET (change/create/delete) them. 1498 12. Authors' Addresses 1500 Andy Bierman 1501 Cisco Systems 1502 170 West Tasman Drive 1503 San Jose, CA USA 95134 1504 Phone: +1 408-527-3711 1505 Email: abierman@cisco.com 1507 Kendall S. Jones 1508 Nortel Networks 1509 4401 Great America Parkway 1510 Santa Clara, CA USA 95054 1511 Phone: +1 408-495-7356 1512 Email: kejones@nortelnetworks.com 1514 13. Full Copyright Statement 1516 Copyright (C) The Internet Society (2000). All Rights Reserved. 1518 This document and translations of it may be copied and furnished to 1519 others, and derivative works that comment on or otherwise explain it or 1520 assist in its implementation may be prepared, copied, published and 1521 distributed, in whole or in part, without restriction of any kind, 1522 provided that the above copyright notice and this paragraph are included 1523 on all such copies and derivative works. However, this document itself 1524 may not be modified in any way, such as by removing the copyright notice 1525 or references to the Internet Society or other Internet organizations, 1526 except as needed for the purpose of developing Internet standards in 1527 which case the procedures for copyrights defined in the Internet 1528 Standards process must be followed, or as required to translate it into 1529 languages other than English. 1531 The limited permissions granted above are perpetual and will not be 1532 revoked by the Internet Society or its successors or assigns. 1534 This document and the information contained herein is provided on an "AS 1535 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1536 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1537 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1538 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1539 FITNESS FOR A PARTICULAR PURPOSE."