MSDP Working Group Bill Fenner INTERNET-DRAFT AT&T Research Expires November 1999 Dave Thaler Microsoft 27 May 1999 Multicast Source Discovery protocol MIB Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Expires November 1999 [Page 1] Draft MSDP MIB 27 May 1999 1. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) [17] speakers. Expires November 1999 [Page 2] Draft MSDP MIB 27 May 1999 2. Revision History A record of changes which will be removed before publication. 25 June 1999 (1) Renamed to DRAFT-MSDP-MIB. It will be renamed back to MSDP-MIB when it gets renumbered under mib-2, in order to avoid module naming problems. (2) Turned msdpSendRequestsTo into a table in order to handle administratively scoped groups with different RP's. 27 May 1999 (1) Added IANA-assigned experimental OID (2) Added msdpSendRequestsTo and msdpPeerProcessRequestsFrom to configure MSDP SA-Request/Response processing. (3) Added msdpPeerDataTtl to allow TTL scoping of data packets forwarded across MSDP peerings. (4) Renumbered msdpSACacheInDataPackets and further items in msdpSACacheTable, to eliminate duplicate OIDs 20 April 1999 (1) initial version. 3. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. Expires November 1999 [Page 3] Draft MSDP MIB 27 May 1999 o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires November 1999 [Page 4] Draft MSDP MIB 27 May 1999 4. Overview This MIB module contains one scalar and two tables. The tables are: o the Peer Table, containing information on the peers; and o the Source-Active Cache Table, containing the SA cache entries. Expires November 1999 [Page 5] Draft MSDP MIB 27 May 1999 5. Definitions --- --- DRAFT-MSDP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, experimental, Counter32, Gauge32, IpAddress, TimeTicks FROM SNMPv2-SMI RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; msdpMIB MODULE-IDENTITY LAST-UPDATED "9906240000Z" ORGANIZATION "IETF MSDP Working Group" CONTACT-INFO " Bill Fenner 75 Willow Road Menlo Park, CA 94025 Phone: +1 650 867 6073 E-mail: fenner@research.att.com Dave Thaler One Microsoft Way Redmond, WA 98052 Phone: +1 425 703 8835 Email: dthaler@microsoft.com" DESCRIPTION "An experimental MIB module for MSDP Management." ::= { experimental 92 } msdpMIBobjects OBJECT IDENTIFIER ::= { msdpMIB 1 } msdp OBJECT IDENTIFIER ::= { msdpMIBobjects 1 } msdpEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The state of MSDP on this MSDP speaker - globally enabled or disabled." Expires November 1999 [Page 6] Draft MSDP MIB 27 May 1999 ::= { msdp 1 } msdpCacheLifetime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-write STATUS current DESCRIPTION "The lifetime given to SA cache entries when created or refreshed. A value of 0 means no SA caching is done by this MSDP speaker." ::= { msdp 2 } msdpNumSACacheEntries OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of entries in the SA Cache table." ::= { msdp 3 } --- --- The MSDP Requests table --- msdpRequestsTable OBJECT-TYPE SYNTAX SEQUENCE OF MsdpRequestsEntry MAX-ACCESS na STATUS current DESCRIPTION "The (conceptual) table listing group ranges and MSDP peers used when deciding where to send an SA Request message when required. If SA Caching is enabled, this table may be empty." ::= { msdp 4 } msdpRequestsEntry OBJECT-TYPE SYNTAX MsdpRequestsEntry MAX-ACCESS na STATUS current DESCRIPTION "An entry (conceptual row) representing a group range used when deciding where to send an SA Request message." INDEX { msdpRequestsGroupAddress, msdpRequestsGroupMask } ::= { msdpRequestsTable 1 } Expires November 1999 [Page 7] Draft MSDP MIB 27 May 1999 MsdpRequestsEntry ::= SEQUENCE { msdpRequestsGroupAddressIpAddress, msdpRequestsGroupMaskIpAddress, msdpRequestsPeerIpAddress, msdpRequestsStatusRowStatus } msdpRequestsGroupAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS na STATUS current DESCRIPTION "The group address that, when combined with the mask in this entry, represents the group range for which this peer will service MSDP SA Requests." ::= { msdpRequestsEntry 1 } msdpRequestsGroupMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS na STATUS current DESCRIPTION "The mask that, when combined with the group address in this entry, represents the group range for which this peer will service MSDP SA Requests." ::= { msdpRequestsEntry 2 } msdpRequestsPeer OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The peer to which MSDP SA Requests for groups matching this entry's group range will be sent. Must match the INDEX of a row in the msdpPeerTable." ::= { msdpRequestsEntry 3 } msdpRequestsStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row, by which new rows may be added to the table." ::= { msdpRequestsEntry 4 } Expires November 1999 [Page 8] Draft MSDP MIB 27 May 1999 --- --- The MSDP Peer table --- msdpPeerTable OBJECT-TYPE SYNTAX SEQUENCE OF MsdpPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the MSDP speaker's peers." ::= { msdp 5 } msdpPeerEntry OBJECT-TYPE SYNTAX MsdpPeerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing an MSDP peer." INDEX { msdpPeerRemoteAddress } ::= { msdpPeerTable 1 } MsdpPeerEntry ::= SEQUENCE { msdpPeerRemoteAddress IpAddress, -- index msdpPeerConfigMethod INTEGER, -- read-only objects: msdpPeerState INTEGER, msdpPeerRPFFailures Counter32, msdpPeerInSAs Counter32, msdpPeerOutSAs Counter32, msdpPeerInSARequests Counter32, msdpPeerOutSARequests Counter32, msdpPeerInSAResponses Counter32, msdpPeerOutSAResponses Counter32, msdpPeerInControlMessages Counter32, msdpPeerOutControlMessages Counter32, msdpPeerInDataPackets Counter32, msdpPeerOutDataPackets Counter32, msdpPeerFsmEstablishedTransitions Counter32, msdpPeerFsmEstablishedTime Gauge32, msdpPeerInMessageElapsedTime Gauge32, msdpPeerLocalAddress IpAddress, -- configuration objects: msdpPeerSAAdvPeriod INTEGER, msdpPeerConnectRetryInterval INTEGER, msdpPeerHoldTimeConfigured INTEGER, msdpPeerKeepAliveConfigured INTEGER, Expires November 1999 [Page 9] Draft MSDP MIB 27 May 1999 msdpPeerDataTtl INTEGER, msdpPeerProcessRequestsFrom TruthValue, msdpPeerStatus RowStatus } msdpPeerRemoteAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The address of the remote MSDP peer." ::= { msdpPeerEntry 1 } msdpPeerConfigMethod OBJECT-TYPE SYNTAX INTEGER { manual(1), pimHello(2), bgpCapability(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "How this peer was configured; manually (1) or via one of the automatic mechanisms described in the MSDP spec." ::= { msdpPeerEntry 2 } msdpPeerState OBJECT-TYPE SYNTAX INTEGER { idle(1), connect(2), active(3), established(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the MSDP TCP connection with this peer." ::= { msdpPeerEntry 3 } msdpPeerRPFFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RPF failures on SA messages received from this peer." ::= { msdpPeerEntry 4 } msdpPeerInSAs OBJECT-TYPE Expires November 1999 [Page 10] Draft MSDP MIB 27 May 1999 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA messages received on this connection. This object should be initialized to zero when the connection is established." ::= { msdpPeerEntry 5 } msdpPeerOutSAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA messages transmitted on this connection. This object should be initialized to zero when the connection is established." ::= { msdpPeerEntry 6 } msdpPeerInSARequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA-Request messages received on this connection. This object should be initialized to zero when the connection is established." ::= { msdpPeerEntry 7 } msdpPeerOutSARequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA-Request messages transmitted on this connection. This object should be initialized to zero when the connection is established." ::= { msdpPeerEntry 8 } msdpPeerInSAResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA-Response messages received on Expires November 1999 [Page 11] Draft MSDP MIB 27 May 1999 this connection. This object should be initialized to zero when the connection is established." ::= { msdpPeerEntry 9 } msdpPeerOutSAResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA Response messages transmitted on this TCP connection. This object should be initialized to zero when the connection is established." ::= { msdpPeerEntry 10 } msdpPeerInControlMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of MSDP messages received on this TCP connection. This object should be initialized to zero when the connection is established." ::= { msdpPeerEntry 11 } msdpPeerOutControlMessages OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of MSDP messages transmitted on this TCP connection. This object should be initialized to zero when the connection is established." ::= { msdpPeerEntry 12 } msdpPeerInDataPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of encapsulated data packets received from this peer. This object should be initialized to zero when the connection is established." ::= { msdpPeerEntry 13 } Expires November 1999 [Page 12] Draft MSDP MIB 27 May 1999 msdpPeerOutDataPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of encapsulated data packets sent to this peer. This object should be initialized to zero when the connection is established." ::= { msdpPeerEntry 14 } msdpPeerFsmEstablishedTransitions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of times the MSDP FSM transitioned into the established state." ::= { msdpPeerEntry 15 } msdpPeerFsmEstablishedTime OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This timer indicates how long (in seconds) this peer has been in the Established state or how long since this peer was last in the Established state. It is set to zero when a new peer is configured or the MSDP speaker is booted." ::= { msdpPeerEntry 16 } msdpPeerInMessageElapsedTime OBJECT-TYPE SYNTAX Gauge32 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Elapsed time in seconds since the last MSDP message was received from the peer. Each time msdpPeerInControlMessages is incremented, the value of this object is set to zero (0)." ::= { msdpPeerEntry 17 } msdpPeerLocalAddress OBJECT-TYPE Expires November 1999 [Page 13] Draft MSDP MIB 27 May 1999 SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The local IP address of this entry's MSDP connection." ::= { msdpPeerEntry 18 } msdpPeerSAAdvPeriod OBJECT-TYPE SYNTAX INTEGER(1..2147483647) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Time interval in seconds for the MinSAAdvertisementInterval MSDP timer." DEFVAL { 60 } ::= { msdpPeerEntry 19 } msdpPeerConnectRetryInterval OBJECT-TYPE SYNTAX INTEGER (1..65535) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Time interval in seconds for the ConnectRetry timer." DEFVAL { 120 } ::= { msdpPeerEntry 20 } msdpPeerHoldTimeConfigured OBJECT-TYPE SYNTAX INTEGER ( 0 | 3..65535 ) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Time interval in seconds for the Hold Timer configured for this MSDP speaker with this peer." DEFVAL { 90 } ::= { msdpPeerEntry 21 } msdpPeerKeepAliveConfigured OBJECT-TYPE SYNTAX INTEGER ( 0 | 1..21845 ) UNITS "seconds" MAX-ACCESS read-create STATUS current Expires November 1999 [Page 14] Draft MSDP MIB 27 May 1999 DESCRIPTION "Time interval in seconds for the KeepAlive timer configured for this MSDP speaker with this peer. A reasonable maximum value for this timer would be configured to be one third of that of msdpPeerHoldTimeConfigured. If the value of this object is zero (0), no periodic KEEPALIVE messages are sent to the peer after the MSDP connection has been established." DEFVAL { 30 } ::= { msdpPeerEntry 22 } msdpPeerDataTtl OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The minimum TTL a packet is required to have before it may be forwarded using SA encapsulation to this peer." ::= { msdpPeerEntry 23 } msdpPeerProcessRequestsFrom OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates whether or not to process MSDP SA Request messages from this peer. If True(1), MSDP SA Request messages from this peer are processed and replied to (if appropriate) with SA Response messages. If False(2), MSDP SA Request messages from this peer are silently ignored. It defaults to False when msdpCacheLifetime is 0 and True when msdpCacheLifetime is non-0." ::= { msdpPeerEntry 24 } msdpPeerStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The RowStatus object by which peers can be added and deleted. A transition to 'active' will cause the MSDP Start Event to be generated. A transition out of the Expires November 1999 [Page 15] Draft MSDP MIB 27 May 1999 'active' state will cause the MSDP Stop Event to be generated. Care should be used in providing write access to this object without adequate authentication." ::= { msdpPeerEntry 25 } --- --- The MSDP Source-Active Cache table --- msdpSACacheTable OBJECT-TYPE SYNTAX SEQUENCE OF MsdpSACacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the MSDP SA advertisements currently in the MSDP speaker's cache." ::= { msdp 6 } msdpSACacheEntry OBJECT-TYPE SYNTAX MsdpSACacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing an MSDP SA advert." INDEX { msdpSACacheGroupAddr, msdpSACacheSourceAddr } ::= { msdpSACacheTable 1 } MsdpSACacheEntry ::= SEQUENCE { msdpSACacheGroupAddr IpAddress, msdpSACacheSourceAddr IpAddress, msdpSACacheOriginRP IpAddress, msdpSACachePeerLearnedFrom IpAddress, msdpSACacheRPFPeer IpAddress, msdpSACacheInSAs Counter32, msdpSACacheInDataPackets Counter32, msdpSACacheUpTime TimeTicks, msdpSACacheExpiryTime TimeTicks, msdpSACacheStatus RowStatus } msdpSACacheGroupAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible Expires November 1999 [Page 16] Draft MSDP MIB 27 May 1999 STATUS current DESCRIPTION "The group address of the SA Cache entry." ::= { msdpSACacheEntry 1 } msdpSACacheSourceAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The source address of the SA Cache entry." ::= { msdpSACacheEntry 2 } msdpSACacheOriginRP OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The address of the RP which originated the last SA message accepted for this entry." ::= { msdpSACacheEntry 3 } msdpSACachePeerLearnedFrom OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The peer from which this SA Cache entry was last accepted. This address must correspond to the msdpPeerRemoteAddress value for a row in the MSDP Peer Table." ::= { msdpSACacheEntry 4 } msdpSACacheRPFPeer OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The peer from which an SA message corresponding to this cache entry would be accepted (i.e. the RPF peer for msdpSACacheOriginRP). This may be different than msdpSACachePeerLearnedFrom if this entry was created by an MSDP SA-Response. This address must correspond to the msdpPeerRemoteAddress value for a row in the MSDP Peer Table." Expires November 1999 [Page 17] Draft MSDP MIB 27 May 1999 ::= { msdpSACacheEntry 5 } msdpSACacheInSAs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP SA messages received relevant to this cache entry. This object must be initialized to zero when creating a cache entry." ::= { msdpSACacheEntry 6 } msdpSACacheInDataPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MSDP encapsulated data packets received relevant to this cache entry. This object must be initialized to zero when creating a cache entry." ::= { msdpSACacheEntry 7 } msdpSACacheUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time since this entry was placed in the SA cache." ::= { msdpSACacheEntry 8 } msdpSACacheExpiryTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time remaining before this entry will expire from the SA cache." ::= { msdpSACacheEntry 9 } msdpSACacheStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-write STATUS current DESCRIPTION Expires November 1999 [Page 18] Draft MSDP MIB 27 May 1999 "The status of this row in the table. The only allowable actions are to retreive the status, which will be `active', or to set the status to `destroy' in order to remove this entry from the cache." ::= { msdpSACacheEntry 10 } -- Traps msdpTraps OBJECT IDENTIFIER ::= { msdp 7 } msdpEstablished NOTIFICATION-TYPE OBJECTS { msdpPeerFsmEstablishedTransitions } STATUS current DESCRIPTION "The MSDP Established event is generated when the MSDP FSM enters the ESTABLISHED state." ::= { msdpTraps 1 } msdpBackwardTransition NOTIFICATION-TYPE OBJECTS { msdpPeerState } STATUS current DESCRIPTION "The MSDPBackwardTransition Event is generated when the MSDP FSM moves from a higher numbered state to a lower numbered state." ::= { msdpTraps 2 } -- conformance information msdpMIBConformance OBJECT IDENTIFIER ::= { msdp 8 } msdpMIBCompliances OBJECT IDENTIFIER ::= { msdpMIBConformance 1 } msdpMIBGroups OBJECT IDENTIFIER ::= { msdpMIBConformance 2 } -- compliance statements msdpMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the MSDP MIB." MODULE -- this module MANDATORY-GROUPS { msdpMIBGlobalsGroup } GROUP msdpSACacheGroup DESCRIPTION Expires November 1999 [Page 19] Draft MSDP MIB 27 May 1999 "This group is mandatory if the MSDP speaker has the ability to cache SA messages." ::= { msdpMIBCompliances 1 } -- units of conformance msdpMIBGlobalsGroup OBJECT-GROUP OBJECTS { msdpEnabled, msdpSendRequestsTo } STATUS current DESCRIPTION "A collection of objects providing information on global MSDP state." ::= { msdpMIBGroups 1 } msdpMIBPeerGroup OBJECT-GROUP OBJECTS { msdpPeerConfigMethod, msdpPeerRPFFailures, msdpPeerState, msdpPeerInSAs, msdpPeerOutSAs, msdpPeerInSARequests, msdpPeerOutSARequests, msdpPeerInSAResponses, msdpPeerOutSAResponses, msdpPeerInControlMessages, msdpPeerOutControlMessages, msdpPeerInDataPackets, msdpPeerOutDataPackets, msdpPeerFsmEstablishedTransitions, msdpPeerFsmEstablishedTime, msdpPeerLocalAddress, msdpPeerSAAdvPeriod, msdpPeerConnectRetryInterval, msdpPeerHoldTimeConfigured, msdpPeerKeepAliveConfigured, msdpPeerInMessageElapsedTime, msdpPeerDataTtl, msdpPeerProcessRequestsFrom, msdpPeerStatus } STATUS current DESCRIPTION "A collection of objects for managing MSDP peers." ::= { msdpMIBGroups 2 } msdpSACacheGroup OBJECT-GROUP OBJECTS { msdpCacheLifetime, msdpNumSACacheEntries, msdpSACacheOriginRP, msdpSACachePeerLearnedFrom, msdpSACacheRPFPeer, msdpSACacheInSAs, msdpSACacheInDataPackets, msdpSACacheUpTime, msdpSACacheExpiryTime, msdpSACacheStatus } Expires November 1999 [Page 20] Draft MSDP MIB 27 May 1999 STATUS current DESCRIPTION "A collection of objects for managing MSDP SA cache entries." ::= { msdpMIBGroups 3 } msdpNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { msdpEstablished, msdpBackwardTransition } STATUS current DESCRIPTION "A collection of notifications for signaling changes in MSDP peer relationships." ::= { msdpMIBGroups 4 } END Expires November 1999 [Page 21] Draft MSDP MIB 27 May 1999 6. Open Issues A table to express policy was suggested on the MSDP mailing list. More discussion is required before including this in the MIB. An OID for control of encapsulation was suggested, although it might be more appropriate to be a table for fine-grained control. More discussion is required. Is the RowStatus object in the SACache appropriate? (e.g. used to flush potentially bad state) Is there any useful information that can be kept on a router that does no SA caching? (e.g. a 1-deep cache in the msdpPeerTable might be useful) Should the ipMRouteTable be augmented with a table that says that this entry was created based upon MSDP? (You can't just use ipMRouteProtocol, since that still needs to reflect how you're choosing the RPF/forwarding interfaces). Should there be a mechanism to describe alternate methods of RPF? (e.g. statically configured peer address and RP address lists - could be a table indexed by peer address and RP address with a value of accept/deny) A "mesh group" appears to be a group of MSDP speakers which have fully meshed connectivity; SA messages received from a member of a "mesh group" are never forwarded to other members of the "mesh group". Should membership in a mesh group be in the peer table? The "logical RP" method appears to require translation of the RP address when leaving the domain if you're using the method described in section 6.2 of draft-ietf-mboned-logical-rp-00.txt. One way to represent this translation is via a translation table with integer indexes and an integer-or-0 in the Peer table saying what RP translation occurs on this peering. Does the RP address to be used when originating SA messages belong in the global configuration section? 7. Security Considerations This MIB contains readable objects whose values provide information related to multicast tree construction. There are also a number of objects that have a MAX-ACCESS clause of read- write and/or read-create, such as those which allow an Expires November 1999 [Page 22] Draft MSDP MIB 27 May 1999 administrator to dynamically configure MSDP peers. While unauthorized read access to the objects in this MIB is relatively innocuous, unauthorized write access could cause a denial-of-service, or could cause unauthorized creation and/or manipulation of MSDP peering sessions. Hence, the support for SNMP operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec [16]), even then, there is no control as to who on the secure network is allowed to access and SET (change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [12] and the View- based Access Control Model RFC 2275 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them. 8. Acknowledgements Tom Pusateri and Billy Ng both provided valuable input on this draft. 9. Authors' Addresses Bill Fenner 75 Willow Road Menlo Park, CA 94025 Phone: +1 650 867 6073 EMail: fenner@research.att.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Expires November 1999 [Page 23] Draft MSDP MIB 27 May 1999 Phone: +1 425 703 8835 EMail: dthaler@microsoft.com 10. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems Expires November 1999 [Page 24] Draft MSDP MIB 27 May 1999 International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "MPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998. [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998. [16] R. Atkinson. "Security architecture for the internet protocol", RFC 1825, August 1995. [17] Farinacci, D., Rekhter, Y., Lothberg, P., Kilmer, H., and J. Hall, "Multicast Source Discovery Protocol (MSDP)", draft- ietf-msdp-spec-01.txt, March 1999. Expires November 1999 [Page 25] Draft MSDP MIB 27 May 1999 11. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Table of Contents 1: Abstract ................................................. 2 2: Revision History ......................................... 3 3: The SNMP Network Management Framework .................... 3 3.1: Object Definitions ..................................... 4 4: Overview ................................................. 5 5: Definitions .............................................. 6 6: Open Issues .............................................. 22 7: Security Considerations .................................. 22 8: Acknowledgements ......................................... 23 9: Authors' Addresses ....................................... 23 10: References .............................................. 24 11: Full Copyright Statement ................................ 26 Expires November 1999 [Page 26] Draft MSDP MIB 27 May 1999 Expires November 1999 [Page 27]