idnits 2.17.1 draft-ietf-ptopomib-pdp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 29 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (30 July 1997) is 9760 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: 'Length-1' is mentioned on line 254, but not defined == Outdated reference: A later version (-01) exists of draft-bierman-entmib-compid-00 -- Possible downref: Normative reference to a draft: ref. 'ENTITY-EXT' == Outdated reference: A later version (-05) exists of draft-ietf-ptopomib-mib-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ptopomib-mib (ref. 'PTOPO') ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Obsolete normative reference: RFC 1573 (Obsoleted by RFC 2233) ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2037 (Obsoleted by RFC 2737) Summary: 19 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 3 Physical Topology Discovery Protocol and MIB 5 30 July 1997 7 Andy Bierman 8 Cisco Systems Inc. 9 abierman@cisco.com 11 Keith McCloghrie 12 Cisco Systems Inc. 13 kzm@cisco.com 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference material 25 or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 30 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 1. Introduction 34 This memo defines an experimental protocol, and an experimental portion 35 of the Management Information Base (MIB) for use with network management 36 protocols in the Internet community. In particular, it describes a 37 physical topology discovery protocol and managed objects used for 38 Draft Physical Topology Discovery Protocol and MIB July 1997 40 managing the protocol. 42 2. The SNMP Network Management Framework 44 The SNMP Network Management Framework presently consists of three major 45 components. They are: 47 o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for 48 describing and naming objects for the purpose of management. 50 o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed 51 objects for the Internet suite of protocols. 53 o the protocol, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905], - the 54 protocol for accessing managed information. 56 Textual conventions are defined in RFC 1903 [RFC1903], and conformance 57 statements are defined in RFC 1904 [RFC1904]. 59 The Framework permits new objects to be defined for the purpose of 60 experimentation and evaluation. 62 This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A 63 semantically identical MIB conforming to the SNMPv1 SMI can be produced 64 through the appropriate translation. 66 2.1. Object Definitions 68 Managed objects are accessed via a virtual information store, termed the 69 Management Information Base or MIB. Objects in the MIB are defined 70 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 71 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 72 an administratively assigned name. The object type together with an 73 object instance serves to uniquely identify a specific instantiation of 74 the object. For human convenience, we often use a textual string, 75 termed the descriptor, to refer to the object type. 77 Draft Physical Topology Discovery Protocol and MIB July 1997 79 3. Overview 81 There is a need for a standardized way of representing the physical 82 network connections pertaining to a given management domain. A 83 standardized discovery mechanism is also required to increase the 84 likelihood of multi-vendor interoperability of such physical topology 85 management information. 87 This document specifies a discovery protocol, suitable for use with the 88 Physical Topolgy MIB [PTOPO]. 90 3.1. Terms 92 Some terms are used throughout this document: 94 SNMP Agent 95 This term refers to an SNMP agent co-located with a particular PDP 96 Agent. Specifically, it refers to the SNMP Agent providing PDP MIB, 97 Entity MIB, Interfaces MIB, and possibly PTOPO MIB support for a 98 particular chassis. 100 PDP Agent 101 This term refers to a software entity which implements the PTOPO 102 Discovery Protocol for a particular chassis. 104 3.2. Persistent Identifiers 106 The PTOPO MIB utilizes non-volatile identifiers to distinguish 107 individual chassis and port components. These identifiers are 108 associated with external objects in order to relate topology information 109 to the existing managed objects. 111 In particular, an object from the Entity MIB or Interfaces MIB can be 112 used as the 'reference-point' for a connection component identifier. 114 3.3. Relationship to the Physical Topology MIB 116 The Physical Topology MIB [PTOPO] allows a PDP Agent to expose learned 117 physical topology information, using a standard MIB. PDP is intended to 118 fully support the PTOPO MIB. 120 Draft Physical Topology Discovery Protocol and MIB July 1997 122 3.4. Relationship to Entity MIB 124 The Entity MIB [RFC2037] allows the physical component inventory and 125 hierarchy to be identified. The chassis identifier strings passed in 126 PDP messages identify entPhysicalTable entries, and implementation of 127 the entPhysicalTable and entPhysicalXTable (found in 'Entity MIB 128 Extensions for Persistent Component Identification' [ENTITY-EXT]) are 129 required for SNMP agents which also implement the PDP MIB. 131 3.5. Relationship to Interfaces MIB 133 The Interfaces MIB provides a standard mechanism for managing network 134 interfaces. The port identifier strings passed in PDP messages identify 135 ifTable (or entPhysicalTable) entries, and implementation of the ifTable 136 and ifXTable [RFC1573] are required for SNMP agents which also implement 137 the PDP MIB, for the ports which are represented in the Interfaces MIB. 139 4. PTOPO Discovery Protocol 141 This section defines a discovery protocol, suitable for supporting the 142 data requirements of the PTOPO MIB. 144 The PTOPO Discovery Protocol (PDP) is a media and protocol independent 145 protocol intended to be run on routers, bridges, access servers, 146 switches, etc., allowing a PDP agent to learn SNMP reachability and 147 connection endpoint information from adjacent devices. 149 PDP runs on various media that support Subnetwork Access Protocol 150 (SNAP), and runs over the data-link layer only, allowing two systems 151 running different network layer protocols can learn about each other. 153 Each device configured with an active PDP Agent sends periodic messages 154 to a multicast MAC address on all physical interfaces enabled for PDP 155 transmission, and listens for PDP messages on all operational ports. 156 Each PDP message contains information identifying the source port as a 157 PTOPO connection endpoint identifier. It also contains at least one 158 network address which can be used by an NMS to reach an SNMP agent on 159 the device (via the indicated source port). Each PDP message contains a 160 configurable time-to-live value, which tells the recipient PDP agent 161 when to discard each element of learned topology information. 163 Draft Physical Topology Discovery Protocol and MIB July 1997 165 4.1. Frame Encapsulation 167 A OUI value an HDLC protocol value must be chosen to identify PDP 168 messages. [TBD -- authority contact info on process and example] 170 4.2. PDP Message Format 172 The basic PDP packet consists of a header, followed by a variable number 173 of type/length/value (TLV) triplets, as indicated in Figure 1. 175 +------------------+----------+---...--+----------+ 176 | header | TLV 1 | ..... | TLV N | 177 +------------------+----------+---...--+----------+ 179 [ Figure 1 -- Basic PDP Message Format ] 181 4.2.1. PDP Header Format 183 The PDP header is a 6 byte header containing 4 fields, as shown in 184 figure 2: 186 0 1 2 3 187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Version | Flags | Time To Live | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 0 1 193 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Checksum | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 [ figure 2 -- PDP Message Format ] 200 The PDP header contains the following fields: 202 - Version 203 The PDP protocol version number, set to 0x01 for this version of 204 the protocol. 206 Draft Physical Topology Discovery Protocol and MIB July 1997 208 - Flags 209 The PDP flags field provide for future header extensions and keep 210 the header word-aligned for easier processing. No flag definition 211 bits are defined at this time. This field must be set to zero in 212 all version 1 PDP messages. 214 - Time to live 215 The number of seconds the information in this PDP message should be 216 regarded as valid by the recipient. Agents of the PTOPO MIB must 217 not return MIB information based on expired PDP messages. The 218 valid range is 0 to 65535 for this field. 220 - Checksum 221 The one's complement of the one's complement checksum of the entire 222 PDP message. PDP messages containing incorrect checksums must be 223 ignored by the recipient. 225 4.2.2. TLV Format 227 Following the PDP header are a variable number of TLVs, depending on 228 implementation and maximum message size. See figure 3 for TLV field 229 layout. 231 The type field consists of the 3 byte OUI of the naming authority, 232 followed by one byte of padding. 234 Draft Physical Topology Discovery Protocol and MIB July 1997 236 A 2 byte field follows, and contains the length, in octets, of the value 237 field contained in the TLV. 239 0 1 2 3 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | OUI | Padding | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 0 1 2 3 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | OIU-Specific-Type | Length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 0 252 0 1 2 3 4 5 6 7 253 +-+-+-+-+-+-+-+-+ 254 | Value byte 0 | ... repeated through value byte[Length-1] 255 +-+-+-+-+-+-+-+-+ 257 [ Figure 3 - TLV Format ] 259 The header fields are defined as follows: 261 OUI The identifier distinguishing the naming authority defining this 262 TLV. 264 Padding 265 A single byte, set to zero, used for alignment. 267 OUI-Specific-Type 268 The integer value identifying the type of information contained in 269 the value field. 271 Length 272 The length, in octets, of the value field to follow. 274 Value 275 A variable-length octet-string containing the instance-specific 276 information for this TLV. 278 Draft Physical Topology Discovery Protocol and MIB July 1997 280 4.3. Standard TLV Definitions 282 The standard PDP TLVs allow for a PDP agent to implement the PTOPO MIB 283 for connections terminating on the local chassis. 285 Draft Physical Topology Discovery Protocol and MIB July 1997 287 The following table summarizes the TLVs defined in this document. 289 +-------+------+-----------------+--------------------------------------+ 290 | OUI | Type | TLV Name | Example Usage | 291 +-------+------+-----------------+--------------------------------------+ 292 | IETF | 1 | Chassis ID | "acme.rg1000-switch.0000c07cf297" | 293 +-------+------+-----------------+--------------------------------------+ 294 | IETF | 2 | Chassis Source | OID string of entPhysicalAlias.11 | 295 +-------+------+-----------------+--------------------------------------+ 296 | IETF | 3 | Port ID | "eth0/0/0" | 297 +-------+------+-----------------+--------------------------------------+ 298 | IETF | 4 | Port Source | OID string of ifAlias.21 | 299 +-------+------+-----------------+--------------------------------------+ 300 | IETF | 5 | Mgmt Address | { ipV4(1), 4, '0x01020304' } | 301 +-------+------+-----------------+--------------------------------------+ 302 [ Figure 4 - TLV Summary ] 304 4.3.1. Chassis ID 306 The Chassis ID is a mandatory TLV which identifies the chassis component 307 of the endpoint identifier associated with the transmitting PDP agent. 309 It is a DisplayString, length [1..48] octets, representing the globally 310 unique, non-volatile string identifying the chassis containing the PDP 311 Agent. 313 4.3.2. Chassis Source 315 The Chassis Source is a mandatory TLV which identifies the MIB object 316 (implemented by the local PDP agent) which contains the chassis ID value 317 specified in the Chassis ID TLV. 319 The identifier is encoded as a DisplayString, and contains an ASCII 320 representation of the instance OID identifying the variable containing 321 the same string as specified in the Chassis ID TLV. For example, the 322 instance entPhysicalAlias.19 is encoded into the value string 323 "1.3.6.1.2.1.47.1.5.1.1.1.19", and the associated length field set to 324 the integer value '27'. 326 Draft Physical Topology Discovery Protocol and MIB July 1997 328 4.3.3. Port ID 330 The Port ID is a mandatory TLV which identifies the port component of 331 the endpoint identifier associated with the transmitting PDP agent. If 332 the specified port is an IEEE 802.3 Repeater port, then this TLV is 333 optional. 335 The identifier is encoded as a DisplayString, length [1..48] octets, 336 representing the chassis-unique, non-volatile string identifying the 337 source transmission port for this PDP message. 339 4.3.4. Port Source 341 The Port Source is a mandatory TLV which identifies the MIB object 342 (implemented by the local PDP agent) which contains the port ID value 343 specified in the Port ID TLV. If the specified port is an IEEE 802.3 344 Repeater port, then this TLV is optional. 346 The identifier is encoded as a DisplayString, and contains an ASCII 347 representation of the instance OID identifying the variable containing 348 the same string as specified in the Port ID TLV. For example, the 349 instance ifAlias.14 is encoded into the value string 350 "1.3.6.1.2.1.31.1.1.1.18.14", and the associated length field set to the 351 integer value '26'. 353 Draft Physical Topology Discovery Protocol and MIB July 1997 355 4.3.5. Management Address 357 The Management Address is a mandatory TLV which identifies a network 358 address associated with the local PDP agent, which can be used to reach 359 the agent on the port identified in the Port ID TLV. 361 0 1 2 3 362 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | IANA AddressFamily | Address Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 0 368 0 1 2 3 4 5 6 7 8 9 ..... 369 +-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+ 370 | Addr byte 1 | ... | Addr byte N | 371 +-+-+-+-+-+-+-+-+-+-+-+ .....-+-+-+-+-+-+-+-+-+-+ 373 [ Figure 5 -- Management Address TLV Format ] 375 The Management Address fields are defined as follows: 377 IANA Address Family 378 The enumerated value for the network address type identified in 379 this TLV. 381 Address Length 382 The number of octets contained in the address string to follow. 384 Address 385 The binary string containing the network management address for 386 this TLV. 388 4.4. Protocol Operation 390 An active PDP Agent must transmit PDP messages, process received PDP 391 messages, and maintain an instance of the PTOPO MIB containing the 392 information learned from received PDP messages. 394 During processing of received PDP messages, a PDP Agent must skip and 395 ignore TLVs unknown to the agent. 397 Draft Physical Topology Discovery Protocol and MIB July 1997 399 4.4.1. Message Transmission 401 An active PDP agent must transmit a PDP message out each interface 402 configured for PDP transmission, once each time interval specified in 403 the pdpMessageTxInterval MIB object. Actual transmission intervals are 404 jittered to prevent synchronization effects. Each message is sent with 405 a time-to-live field equal to the value of pdpMessageTxHoldTime MIB 406 object, and must contain at least the five mandatory IETF TLVs 407 supporting the PTOPO MIB. Additional proprietary TLVs may be added, as 408 maximum frame size permits. 410 4.4.2. Message Processing 412 Upon reception of a PDP message, and verifying the message checksum to 413 be correct, the TLV information is extracted, and relevant PTOPO MIB 414 information is updated. If an entry is added, deleted, or modified, the 415 appropriate TimeFilter and last change time internal variables should be 416 updated to signal the change to an NMS. 418 4.4.3. Interface Shutdown Procedure 420 In the event an interface, currently configured with PDP message 421 transmission enabled, either becomes disabled, or the interface is 422 administratively disabled, a final PDP message is transmitted with a 423 time to live value of zero. After reception of such a PDP message, the 424 PDP Agent must remove information in the PTOPO MIB associated with the 425 indicated connection endpoint. 427 5. PTOPO Discovery Protocol MIB 429 This section defines the MIB used to configure PDP agent behavior. 431 5.1. PDP MIB Definitions 433 PDP-MIB DEFINITIONS ::= BEGIN 435 IMPORTS 436 MODULE-IDENTITY, OBJECT-TYPE, Integer32 437 FROM SNMPv2-SMI 438 RowStatus 440 Draft Physical Topology Discovery Protocol and MIB July 1997 442 FROM SNMPv2-TC 443 MODULE-COMPLIANCE, OBJECT-GROUP 444 FROM SNMPv2-CONF 445 PhysicalIndex 446 FROM ENTITY-MIB; 448 pdpMIB MODULE-IDENTITY 449 LAST-UPDATED "9707300000Z" 450 ORGANIZATION "Cisco Systems, Inc." 451 CONTACT-INFO 452 "Andy Bierman 453 Cisco Systems Inc. 454 170 West Tasman Drive 455 San Jose, CA 95134 456 408-527-3711 457 abierman@cisco.com 459 Keith McCloghrie 460 Cisco Systems Inc. 461 170 West Tasman Drive 462 San Jose, CA 95134 463 408-526-5260 464 kzm@cisco.com" 465 DESCRIPTION 466 "The MIB module for managing the Physical Topology Discovery 467 Protocol." 468 ::= { experimental xx } 470 pdpMIBObjects OBJECT IDENTIFIER ::= { pdpMIB 1 } 472 -- MIB groups 473 pdpConfig OBJECT IDENTIFIER ::= { pdpMIBObjects 1 } 475 -- 476 -- *********************************************************** 477 -- 478 -- P T O P O P D P C O N F I G 479 -- 480 -- *********************************************************** 481 -- 482 -- The Physical Topology Discovery Protocol Configuration Group 484 pdpAdminStatus OBJECT-TYPE 485 SYNTAX INTEGER { 486 enabled(1), 488 Draft Physical Topology Discovery Protocol and MIB July 1997 490 disabled(2) 491 } 492 MAX-ACCESS read-write 493 STATUS current 494 DESCRIPTION 495 "The administratively desired status of the physical 496 topology discovery protocol. 498 If the agent is capable of storing non-volatile 499 configuration, then the value of this object must be 500 restored after a re-initialization of the management 501 system." 502 ::= { pdpConfig 1 } 504 pdpOperStatus OBJECT-TYPE 505 SYNTAX INTEGER { 506 enabled(1), 507 disabled(2) 508 } 509 MAX-ACCESS read-only 510 STATUS current 511 DESCRIPTION 512 "The current operational status of the physical topology 513 discovery protocol." 514 ::= { pdpConfig 2 } 516 pdpMessageTxInterval OBJECT-TYPE 517 SYNTAX Integer32 (5..32768) 518 UNITS "seconds" 519 MAX-ACCESS read-write 520 STATUS current 521 DESCRIPTION 522 "The interval at which PDP advertisements are transmitted on 523 behalf of this agent. 525 If the agent is capable of storing non-volatile 526 configuration, then the value of this object must be 527 restored after a re-initialization of the management 528 system." 529 DEFVAL { 60 } 530 ::= { pdpConfig 3 } 532 pdpMessageTxHoldTime OBJECT-TYPE 533 SYNTAX Integer32 (10..65535) 534 UNITS "seconds" 536 Draft Physical Topology Discovery Protocol and MIB July 1997 538 MAX-ACCESS read-write 539 STATUS current 540 DESCRIPTION 541 "The time-to-live value used in PDP advertisements 542 transmitted on behalf of this agent. 544 If the agent is capable of storing non-volatile 545 configuration, then the value of this object must be 546 restored after a re-initialization of the management 547 system." 548 DEFVAL { 180 } 549 ::= { pdpConfig 4 } 551 pdpTxSuppressTable OBJECT-TYPE 552 SYNTAX SEQUENCE OF PdpTxSuppressEntry 553 MAX-ACCESS not-accessible 554 STATUS current 555 DESCRIPTION 556 "A table controlling PDP advertisement transmission on 557 individual ports." 558 ::= { pdpConfig 5 } 560 pdpTxSuppressEntry OBJECT-TYPE 561 SYNTAX PdpTxSuppressEntry 562 MAX-ACCESS not-accessible 563 STATUS current 564 DESCRIPTION 565 "PDP advertisement transmission configuration information 566 for a particular port. The port must be contained in the 567 same chassis as the PDP agent. PDP advertisements will not 568 be transmitted on this port, even if the port is enabled. 570 If the agent is capable of storing non-volatile 571 configuration, then each active pdpTxSuppressEntry must be 572 re-created after a re-initialization of the management 573 system. 575 Only entries pertaining to the 'local' chassis may be 576 created in this table." 577 INDEX { 578 pdpTxSuppressChassisId, 579 pdpTxSuppressPortId 580 } 581 ::= { pdpTxSuppressTable 1 } 583 Draft Physical Topology Discovery Protocol and MIB July 1997 585 PdpTxSuppressEntry ::= SEQUENCE { 586 pdpTxSuppressChassisId PhysicalIndex, 587 pdpTxSuppressPortId PhysicalIndex, 588 pdpTxSuppressRowStatus RowStatus 589 } 591 pdpTxSuppressChassisId OBJECT-TYPE 592 SYNTAX PhysicalIndex 593 MAX-ACCESS not-accessible 594 STATUS current 595 DESCRIPTION 596 "The entPhysicalIndex value used to identify the chassis 597 component associated with this entry." 598 ::= { pdpTxSuppressEntry 1 } 600 pdpTxSuppressPortId OBJECT-TYPE 601 SYNTAX PhysicalIndex 602 MAX-ACCESS not-accessible 603 STATUS current 604 DESCRIPTION 605 "The entPhysicalIndex value used to identify the port 606 component associated with this entry." 607 ::= { pdpTxSuppressEntry 2 } 609 pdpTxSuppressRowStatus OBJECT-TYPE 610 SYNTAX RowStatus 611 MAX-ACCESS read-create 612 STATUS current 613 DESCRIPTION 614 "The status of this entry." 615 ::= { pdpTxSuppressEntry 3 } 617 -- conformance information 618 pdpConformance OBJECT IDENTIFIER ::= { pdpMIB 2 } 620 pdpCompliances OBJECT IDENTIFIER ::= { pdpConformance 1 } 621 pdpGroups OBJECT IDENTIFIER ::= { pdpConformance 2 } 623 -- compliance statements 625 pdpCompliance MODULE-COMPLIANCE 626 STATUS current 627 DESCRIPTION 628 "The compliance statement for SNMP entities which implement 630 Draft Physical Topology Discovery Protocol and MIB July 1997 632 the PDP MIB." 633 MODULE -- this module 634 MANDATORY-GROUPS { pdpConfigGroup } 636 ::= { pdpCompliances 1 } 638 -- MIB groupings 640 pdpConfigGroup OBJECT-GROUP 641 OBJECTS { 642 pdpAdminStatus, 643 pdpOperStatus, 644 pdpMessageTxInterval, 645 pdpMessageTxHoldTime, 646 pdpTxSuppressRowStatus 647 } 648 STATUS current 649 DESCRIPTION 650 "The collection of objects which are used to configure the 651 PTOPO Discovery Protocol implementation behavior. 653 This group is mandatory for agents which implement the PTOPO 654 Discovery Protocol." 655 ::= { pdpGroups 1 } 657 END 659 6. Acknowledgements 661 The PTOPO Discovery Protocol is based on the Cisco Discovery Ptotocol. 663 Draft Physical Topology Discovery Protocol and MIB July 1997 665 7. References 667 [ENTITY-EXT] 668 Bierman, A., McCloghrie, K., "Entity MIB Extensions for Persistent 669 Component Identification", draft-bierman-entmib-compid-00.txt, 670 Cisco Systems, July 1997. 672 [PTOPO] 673 Bierman, A., Kones, K., "Physical Topology MIB", draft-ietf- 674 ptopomib-mib-00.txt, Cisco Systems, Bay Networks, July 1997. 676 [RFC1157] 677 Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 678 Management Protocol", RFC 1157, SNMP Research, Performance Systems 679 International, MIT Laboratory for Computer Science, May 1990. 681 [RFC1213] 682 McCloghrie, K., and M. Rose, Editors, "Management Information Base 683 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 684 RFC 1213, Hughes LAN Systems, Performance Systems International, 685 March 1991. 687 [RFC1573] 688 McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", 689 RFC 1573, Hughes LAN Systems, FTP Software, January 1994. 691 [RFC1902] 692 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 693 S. Waldbusser, "Structure of Management Information for version 2 694 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 695 January 1996. 697 [RFC1903] 698 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 699 S. Waldbusser, "Textual Conventions for version 2 of the Simple 700 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 702 [RFC1904] 703 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 704 S. Waldbusser, "Conformance Statements for version 2 of the Simple 705 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 707 [RFC1905] 708 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 709 S. Waldbusser, "Protocol Operations for version 2 of the Simple 711 Draft Physical Topology Discovery Protocol and MIB July 1997 713 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 715 [RFC2037] 716 McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037, 717 Cisco Systems, October 1996. 719 Draft Physical Topology Discovery Protocol and MIB July 1997 721 8. Security Considerations 723 This protocol and associated MIB can expose the existence of MAC and 724 network layer addresses used by devices within a given network. A 725 network administrator may wish access to this management information, 726 using SNMP access control mechanisms, and restrict PDP advertisement 727 transmission to a particular set of ports, using the pdpTxSuppressTable. 729 9. Authors' Addresses 731 Andy Bierman 732 Cisco Systems, Inc. 733 170 West Tasman Drive 734 San Jose, CA 95134 735 Phone: 408-527-3711 736 Email: abierman@cisco.com 738 Keith McCloghrie 739 Cisco Systems, Inc. 740 170 West Tasman Drive 741 San Jose, CA 95134 742 Phone: 408-526-5260 743 Email: kzm@cisco.com 745 Draft Physical Topology Discovery Protocol and MIB July 1997 747 Table of Contents 749 1 Introduction .................................................... 1 750 2 The SNMP Network Management Framework ........................... 2 751 2.1 Object Definitions ............................................ 2 752 3 Overview ........................................................ 3 753 3.1 Terms ......................................................... 3 754 3.2 Persistent Identifiers ........................................ 3 755 3.3 Relationship to the Physical Topology MIB ..................... 3 756 3.4 Relationship to Entity MIB .................................... 4 757 3.5 Relationship to Interfaces MIB ................................ 4 758 4 PTOPO Discovery Protocol ........................................ 4 759 4.1 Frame Encapsulation ........................................... 5 760 4.2 PDP Message Format ............................................ 5 761 4.2.1 PDP Header Format ........................................... 5 762 4.2.2 TLV Format .................................................. 6 763 4.3 Standard TLV Definitions ...................................... 8 764 4.3.1 Chassis ID .................................................. 9 765 4.3.2 Chassis Source .............................................. 9 766 4.3.3 Port ID ..................................................... 10 767 4.3.4 Port Source ................................................. 10 768 4.3.5 Management Address .......................................... 11 769 4.4 Protocol Operation ............................................ 11 770 4.4.1 Message Transmission ........................................ 12 771 4.4.2 Message Processing .......................................... 12 772 4.4.3 Interface Shutdown Procedure ................................ 12 773 5 PTOPO Discovery Protocol MIB .................................... 12 774 5.1 PDP MIB Definitions ........................................... 12 775 6 Acknowledgements ................................................ 17 776 7 References ...................................................... 18 777 8 Security Considerations ......................................... 20 778 9 Authors' Addresses .............................................. 20