Internet Draft Steve Waldbusser R.G. Cole AT&T C. Kalbfleisch Verio, Inc. D. Romascanu Avaya Inc. 21 June 2002 RMON Framework Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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. Distribution of this document is unlimited. Please send comments to the SMIng WG mailing list . Internet Draft RMON Framework June 21, 2002 1. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. 2. Abstract The RMON Framework consists of a number of interrelated standards. This memo describes these standards and how they relate to one another. 3. Table of Contents Table of Contents 1 Copyright Notice ................................................ 2 2 Abstract ........................................................ 2 3 Table of Contents ............................................... 2 4 The SNMP Network Management Framework ........................... 3 5 Definition of RMON .............................................. 4 6 Goals of RMON ................................................... 4 7 RMON Standards .................................................. 6 7.1 RMON-1 ........................................................ 6 7.2 Token Ring Extensions to RMON MIB ............................. 7 7.3 The RMON-2 MIB ................................................ 9 7.4 RMON MIB Protocol Identifiers ................................. 10 7.5 Remote Network Monitoring MIB Extensions for Switched Net- works ........................................................ 10 7.6 RMON MIB Extensions for Interface Parameters Monitoring ....... 12 7.7 RMON for High Capacity Networks ............................... 12 7.8 Application Performance Measurement MIB ....................... 12 7.9 Transport Performance Metrics MIB ............................. 13 7.10 Synthetic Sources for Performance Monitoring MIB ............. 14 8 RMON Framework Components ....................................... 15 8.1 MediaIndependent Table ........................................ 15 8.2 Protocol Directory ............................................ 15 8.3 Application Directory ......................................... 15 8.4 Data Source ................................................... 15 9 Relationship of APM, TPM, and SSPM MIBs ......................... 16 10 Acknowledgements ............................................... 18 11 Informative References ......................................... 18 12 Security Considerations ........................................ 21 13 Author's Address ............................................... 21 Expires December 21, 2002 [Page 2] Internet Draft RMON Framework June 21, 2002 14 Full Copyright Statement ....................................... 23 4. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. 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 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. 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. Expires December 21, 2002 [Page 3] Internet Draft RMON Framework June 21, 2002 5. Definition of RMON Remote network monitoring devices, often called monitors or probes, are instruments that exist for the purpose of managing a network. Often these remote probes are stand-alone devices and devote significant internal resources for the sole purpose of managing a network. An organization may employ many of these devices, one per network segment, to manage its internet. In addition, these devices may be used for a network management service provider to access a client network, often geographically remote. When the RMON standard was young, this device-oriented definition of RMON was taken quite literally, as RMON devices were probes purpose- built and dedicated to running the RMON MIBs. Soon, cards were introduced that added RMON capability into a network hub, switch or router. RMON also began to appear as a software capability that was added to the software of certain network equipment, as well as software applications that could run on servers or clients. Despite the variety of these approaches, the RMON capability in each serves as a dedicated network management resource available for activities ranging from long- term data collection and analysis or for ad-hoc firefighting. In the beginning, most, but not all, of RMON's capabilities were based on the promiscuous capture of packets on a network segment or segments. Over time, that mixture included more and more capabilities that didn't depend on promiscuous packet capture. Today, the some of the newest standards added to the RMON framework allow multiple techniques of data gathering, one of which is promiscuous packet capture. 6. Goals of RMON o Offline Operation There are sometimes conditions when a management station will not be in constant contact with its remote monitoring devices. This is sometimes by design in an attempt to lower communications costs (especially when communicating over a WAN or dialup link), or by accident as network failures affect the communications between the management station and the probe. For this reason, this MIB allows a probe to be configured to perform diagnostics and to collect statistics continuously, even when communication with Expires December 21, 2002 [Page 4] Internet Draft RMON Framework June 21, 2002 the management station may not be possible or efficient. The probe may then attempt to notify the management station when an exceptional condition occurs. Thus, even in circumstances where communication between management station and probe is not continuous, fault, performance, and configuration information may be continuously accumulated and communicated to the management station conveniently and efficiently. o Proactive Monitoring Given the resources available on the monitor, it is potentially helpful for it continuously to run diagnostics and to log network performance. The monitor is always available at the onset of any failure. It can notify the management station of the failure and can store historical statistical information about the failure. This historical information can be played back by the management station in an attempt to perform further diagnosis into the cause of the problem. o Problem Detection and Reporting The monitor can be configured to recognize conditions, most notably error conditions, and continuously to check for them. When one of these conditions occurs, the event may be logged, and management stations may be notified in a number of ways. o Value Added Data Because a remote monitoring device represents a network resource dedicated exclusively to network management functions, and because it is located directly on the monitored portion of the network, the remote network monitoring device has the opportunity to add significant value to the data it collects. For instance, by highlighting those hosts on the network that generate the most traffic or errors, the probe can give the management station precisely the information it needs to solve a class of problems. o Multiple Managers An organization may have multiple management stations for different units of the organization, for different Expires December 21, 2002 [Page 5] Internet Draft RMON Framework June 21, 2002 functions (e.g. engineering and operations), and in an attempt to provide disaster recovery. Because environments with multiple management stations are common, the remote network monitoring device has to deal with more than own management station, potentially using its resources concurrently. 7. RMON Standards The RMON Framework includes a number of standards. Each standard that makes up the RMON framework defines some new useful behavior (i.e. an application) and managed objects that configure, control and montitor that behavior. This section lists those standards and described the role of each. 7.1. RMON-1 The RMON-1 standard is focused at layer 2 and provides link-layer statistics aggregated in a variety of ways. In addition, it provides generation of alarms when thresholds are crossed as well as the ability to filter and capture packet contents. The components of RMON-1 are: The Ethernet Statistics Group The ethernet statistics group contains statistics measured by the probe for each monitored Ethernet interface on this device. The History Control Group The history control group controls the periodic statistical sampling of data from various types of networks. The Ethernet History Group The ethernet history group records periodic statistical samples from an ethernet network and stores them for later retrieval. The Alarm Group The alarm group periodically takes statistical samples from variables in the probe and compares them to previously configured thresholds. If the monitored variable crosses a threshold, an event is generated. A hysteresis mechanism is implemented to limit the generation of alarms. Expires December 21, 2002 [Page 6] Internet Draft RMON Framework June 21, 2002 The Host Group The host group contains statistics associated with each host discovered on the network. This group discovers hosts on the network by keeping a list of source and destination MAC Addresses seen in good packets promiscuously received from the network. The HostTopN Group The hostTopN group is used to prepare reports that describe the hosts that top a list ordered by one of their statistics. The available statistics are samples of one of their base statistics over an interval specified by the management station. Thus, these statistics are rate based. The management station also selects how many such hosts are reported. The Matrix Group The matrix group stores statistics for conversations between sets of two addresses. As the device detects a new conversation, it creates a new entry in its tables. The Filter Group The filter group allows packets to be matched by a filter equation. These matched packets form a data stream that may be captured or may generate events. The Packet Capture Group The Packet Capture group allows packets to be captured after they flow through a channel. The Event Group The event group controls the generation and notification of events from this device. 7.2. Token Ring Extensions to RMON MIB Some of the functions defined in the RMON-1 MIB were defined specific to Ethernet media. In order to operate the functions on Token Ring Media, new objects needed to be defined in the Token Ring Extensions to RMON MIB. In addition, this MIB defines additional objects that provide Expires December 21, 2002 [Page 7] Internet Draft RMON Framework June 21, 2002 monitoring functions unique to Token Ring. The components of the Token Ring Extensions to RMON MIB are: The Token Ring Statistics Groups The Token Ring statistics groups contain current utilization and error statistics. The statistics are broken down into two groups, the Token Ring Mac-Layer Statistics Group and the Token Ring Promiscuous Statistics Group. The Token Ring Mac-Layer Statistics Group collects information from Mac Layer, including error reports for the ring and ring utilization of the Mac Layer. The Token Ring Promiscuous Statistics Group collects utilization statistics from data packets collected promiscuously. The Token Ring History Groups The Token Ring History Groups contain historical utilization and error statistics. The statistics are broken down into two groups, the Token Ring Mac-Layer History Group and the Token Ring Promiscuous History Group. The Token Ring Mac-Layer History Group collects information from Mac Layer, including error reports for the ring and ring utilization of the Mac Layer. The Token Ring Promiscuous History Group collects utilization statistics from data packets collected promiscuously. The Token Ring Ring Station Group The Token Ring Ring Station Group contains statistics and status information associated with each Token Ring station on the local ring. In addition, this group provides status information for each ring being monitored. The Token Ring Ring Station Order Group The Token Ring Ring Station Order Group provides the order of the stations on monitored rings. The Token Ring Ring Station Config Group The Token Ring Ring Station Config Group manages token ring stations through active means. Any station on a monitored ring may be removed or have configuration information downloaded from it. The Token Ring Source Routing Group Expires December 21, 2002 [Page 8] Internet Draft RMON Framework June 21, 2002 The Token Ring Source Routing Group contains utilization statistics derived from source routing information optionally present in token ring packets. 7.3. The RMON-2 MIB The RMON-2 MIB extends the architecture defined in RMON-1 primarily by extending RMON analysis up to the application layer. The components of the RMON-2 MIB are: The Protocol Directory Group Every RMON 2 implementation will have the capability to parse certain types of packets and identify their protocol type at multiple levels, The protocol directory presents an inventory of those protocol types the probe is capable of monitoring, and allows the addition, deletion, and configuration of protocol types in this list. Protocol Distribution Group This function controls collection of packet and octet counts for any or all of the protocols detected on a given interface. An NMS can use this table to quickly determine bandwidth allocation utilized by different protocols. Address Mapping Group This function lists MAC address to network address bindings discovered by the probe and what interface they were last seen on. Network Layer Host Group This function counts the amount of traffic sent from and to each network address discovered by the probe. Network Layer Matrix Group This function counts the amount of traffic sent between each pair of network addresses discovered by the probe. Application Layer Host Group Expires December 21, 2002 [Page 9] Internet Draft RMON Framework June 21, 2002 This function counts the amount of traffic, by protocol, sent from and to each network address discovered by the probe. Application Layer Matrix This function counts the amount of traffic, by protocol, sent between each pair of network addresses discovered by the probe. User History This function allows an NMS to request that certain variables on the probe be periodically polled and for a time-series to be stored of the polled values. Probe Configuration This group contains configuration objects that configure many aspects of the probe including the software downloaded to the probe, the out of band serial connection and the network connection. 7.4. RMON MIB Protocol Identifiers The RMON-2 MIB identifies protocols at any layer of the 7 layer hierarchy with an identifier called a Protocol Identifier, or ProtocolID for short.. ProtocolIDs also identify the particular configuration of layering in use including any arbitrary encapsulations. The RMON MIB Protocol Identifiers document is a companion document to the RMON-2 MIB that defines a number of well-known protocols. As the RMON Framwork has grown, other standards have been added to the framework that utilize ProtocolIDs. 7.5. Remote Network Monitoring MIB Extensions for Switched Networks Switches have become pervasive in today's networks as a form of broadcast media. SMON provides RMON-like functions for the monitoring of switched networks. Switches today differ from standard shared media protocols because: 1) Data is not, in general, broadcast. This MAY be caused by the switch architecture or by the connection-oriented nature of the data. This means, therefore, that monitoring non-broadcast Expires December 21, 2002 [Page 10] Internet Draft RMON Framework June 21, 2002 traffic needs to be considered. 2) Monitoring the multiple entry and exit points from a switching device requires a vast amount of resources - memory and CPU, and aggregation of the data in logical packets of information, determined by the application needs. 3) Switching incorporates logical segmentation such as Virtual LANs (VLANs). 4) Switching incorporates packet prioritization. 5) Data across the switch fabric can be in the form of cells. Like RMON, SMON is only concerned with the monitoring of packets. Differences such as these make monitoring difficult. The SMON MIB provides the following functions that help to manage switched networks: smonVlanStats This function provides traffic statistics per Virtual LAN for 802.1q VLANs. smonPrioStats This function provides traffic statistics per priority level for 802.1q VLANS. dataSourceCaps This function identifies all supported data sources on an SMON device. An NMS MAY use this table to discover the RMON and Copy Port attributes of each data source. portCopyConfig Many network switches provide the capability to make a copy of traffic seen on one port and send it out another port for management purposes. This occurs in addition to any copying performed during the normal forwarding behavior of the switch. The portCopyConfig function provides control of the port copy functionality in a device. Expires December 21, 2002 [Page 11] Internet Draft RMON Framework June 21, 2002 7.6. RMON MIB Extensions for Interface Parameters Monitoring Many network switches contain hundreds of ports, many with only one attached device. A common operation when managing such a switch is to sort the interfaces by one of the parameters (e.g. to the find the most highly utilized interface). If the switch contains many interfaces it can be expensive and time consuming to download information for all interfaces to sort it on the NMS. Instead, the ifTopN MIB allows the sorting to occur on the switch and for only the top interfaces to be downloaded. 7.7. RMON for High Capacity Networks This MIB defines extensions to RMON for use on high capacity networks. Except for the mediaIndependentTable, each of the tables in this MIB adds high capacity capability to an associated table in the RMON-1 MIB or RMON-2 MIB. The mediaIndependentTable provides media independent utilization and error statistics for full-duplex and half-duplex media. Prior to the existence of the HCRMON MIB, a new table needed to be created for RMON monitoring of each data-link layer media. These tables included many statistical attributes of the media including packet and octet counters that are independent of the media type. This wasn't optimal because there was no way to monitor media types for which a media- specific table had not been defined. Further, there were no common objects to monitor media-independent attributes between media types. In the future, for media other than ethernet and token ring, the mediaIndependentTable will be the source for media-independent statistics. Additional media-specific tables may be created to provide attributes unique to particular media such as error counters. 7.8. Application Performance Measurement MIB The APM MIB provides analysis of application performance as experienced by end-users. Application performance measurement measures the quality of service delivered to end-users by applications. With this perspective, a true end-to-end view of the IT infrastructure results, combining the performance of the application, desktop, network, and server, as well as Expires December 21, 2002 [Page 12] Internet Draft RMON Framework June 21, 2002 any positive or negative interactions between these components. Despite all the technically sophisticated ways in which networking and system resources can be measured, human end-users perceive only two things about an application: availability and responsiveness. Availability - The percentage of the time that the application is ready to give a user service. Responsiveness - The speed at which the application delivers the requested service. 7.9. Transport Performance Metrics MIB The TPM MIB monitors selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions. The metrics are defined through reference to existing IETF, ITU and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources. The TPM MIB includes the following functions: The tpmCapabilities Group The tpmCapabilitiesGroup contains objects and tables which show the measurement protocol and metric capabilities of the agent. The tpmAggregateReports Group The tpmAggregateReportsGroup is used to provide the collection of aggregated statistical measurements for the configured report intervals. The tpmCurrentReports Group The tpmCurrentReportsGroup is used to provide the collection of uncompleted measurements for the current configured report for those transactions caught in progress. A history of these transactions is also maintained once the current transaction has completed. The tpmExceptionReports Group The tpmExceptionReportsGroup is used to link immediate notifications of transactions that exceed certain thresholds defined in the Expires December 21, 2002 [Page 13] Internet Draft RMON Framework June 21, 2002 apmExceptionGroup [APM]. This group reports the aggregated sub- application measurements for those applications exceeding thresholds. 7.10. Synthetic Sources for Performance Monitoring MIB The Synthetic Sources for Performance Monitoring MIB covers the artificial generation of a) application-level, b) transport-level, and c) link-level traffic for the purpose of monitoring system performance. There are situations where it is useful to be able to control the generation of synthetic traffic when evaluating system performance. There are other situations where system performance evaluation can rely upon naturally generated application-level traffic, in which case one needs only monitor existing traffic and not instrument synthetic traffic. The SSPM MIB provides the ability to configure and control the generation of this synthetic traffic. Expires December 21, 2002 [Page 14] Internet Draft RMON Framework June 21, 2002 8. RMON Framework Components The collection of standards in the RMON Framework are associated by 1. A common purpose and similar collection methodologies; and, 2. Use of common infrastrure components These common infrastructure components are: - MediaIndependent Table - Protocol Directory - appDirectory - DataSource 8.1. MediaIndependent Table [TBD] 8.2. Protocol Directory [TBD] [Includes discussion of the ProtocolID itself] 8.3. Application Directory [TBD] 8.4. Data Source [TBD] Expires December 21, 2002 [Page 15] Internet Draft RMON Framework June 21, 2002 9. Relationship of APM, TPM, and SSPM MIBs Figure 1 below shows an overiew of the components of the performance monitoring system. On the far left of the diagram are the "Traffic Generation Control" and the "Traffic Generation Instrumentation". The underlying instrumentation is implementation dependent and outside the domain of the RMONMIB specifications. The focus of the SSPM specification within the RMONMIB is the traffic generation control aspects shown in the figure. +----------------+ +-------------| Application |-------------+ | +----------------+ | | | | +--------------------------------+ | | Synchronization Control | | +--------------------------------+ | | | | V V V +------------------+ +------------------+ +--------------+ |Traffic Generation| |Monitoring Metrics| |Data Reduction| | Control | | Control | | Control | +------------------+ +------------------+ +--------------+ | ^ | ^ | ^ | | | | | | V | V | V | +------------------+ +------------------+ +---------------+ |Traffic Generation| |Monitoring Metrics| |Data Reduction | | Instrumentation| | Instrumentation| +-->|Instrumentation| +------------------+ +------------------+ | +---------------+ | | | | Various levels | | and span +-----------| | | V Reports Figure 1: A performance monitoring system Expires December 21, 2002 [Page 16] Internet Draft RMON Framework June 21, 2002 It is the responsibility of the network management application to coordinate the individual aspects of the performance management system. For example, within the RMONMIB framework: + SSPMMIB [1] is responsible for the traffic generation control, + APMMIB [2] is responsible for the aspects of the "Monitoring Metrics Control" directly related to the end-user's perceived application-level performance, and + TPMMIB [3] is responsible for the aspecys of the monitoring metrics control related to sub-application-level transactions. The testing model then is to first configure the traffic generation instrumentation through the SSPMMIB control function. This defines aspects of the synthetic traffic such as application type, targets, etc. Once the traffic generation is configured, the network management application can setup the monitoring instrumentation through the APMMIB and TPMMIB. These control the reporting periods, the type of data aggregation, etc. Once the tests are complete, the network management application retrieves the reports from the monitoring metrics control MIBs, e.g., APMMIB and TPMMIB. In order to instrument the traffic generation, SSPMMIB provides various types of information for the tests. + Protocol Information - the protocol information is specified through the appLocalIndex from the APMMIB [2]. The appLocalIndex supports standard application specification and user-defined application specification. For more information on the appLocalIndex see the APMMIB[1]. + Transaction Timing Models - the SSPMMIB controls the timing generation of the sythentic traffic. Possible timing models include deterministic transation generation and random transaction generation. The SSPMMIB should support traffic generation models as specified by the IPPM Working Group within the IETF [4]. + Request Packet Configuration - the SSPMMIB supports three levels of packet configuration, i.e., Common Part, Link Level and Application Level. - The Common Part packet configuration covers aspects of the packet configuration common to all transactions. These include the appLocalIndex, source and destination network addresses, Expires December 21, 2002 [Page 17] Internet Draft RMON Framework June 21, 2002 timing model information, packet timeouts, packet fill, packet sequence number information, etc. - The Link Layer Configuration - the SSPMMIB contains a LinkLevelExtensionTable to configure aspects of the various link-level headers. Examples of link-level header information includes media QOS parameters, etc. - The Application Level Configuration - the SSPMMIB contains an ApplicationLayerExtentionTable to configure application specific aspects of the synthetic transactions. These include parameters such as username and password for application-layer authentication, application target information such as a URL in an HTTP transation, and other target information for other applications, e.g., hostname in an DNS transaction. Finally, the SSPMMIB presupposes the need for source and sink configuration in the context of one-way traffic generation for one- way measurements. In this case, the SSPMMIB has seperate source and sink configuration tables. For roundtrip measurements, the source and sink tables reside on the same device. For one-way measurements, the source and sink tables reside on seperate remote devices. This distinction may or may not be necessary, see, e.g., the One-Way Delay Protocol (OWDP) draft [5]. 10. Acknowledgements This memo is a product of the RMON MIB working group. 11. Informative References [RFC1905] SNMPv2 Working Group, 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. [RFC1906] SNMPv2 Working Group, 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. Expires December 21, 2002 [Page 18] Internet Draft RMON Framework June 21, 2002 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, Harvard University, October, 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels" RFC 2119, Harvard University, March 1997. [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, April 1999. [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, IBM T. J. Watson Research, April 1999. [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, International Network Services, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., Expires December 21, 2002 [Page 19] Internet Draft RMON Framework June 21, 2002 and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, International Network Services, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, International Network Services, April 1999. [RFC1155] 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. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [RFC1901] SNMPv2 Working Group, 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. [RFC1907] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [RFC2233] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB Using SMIv2", RFC 2233, Cisco Systems, FTP Software, November, 1997. Expires December 21, 2002 [Page 20] Internet Draft RMON Framework June 21, 2002 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates, Inc., Ericsson, Cisco Systems, April 1999. [RFC2863] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, Cisco Systems, Argon Networks, June, 2000. [RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [SSPM] Kalbfleisch, C., Cole, R.G. and D. Romascanu, "A Synthetic Source for Performance Monitoring MIB", , June 2001. [APM] Waldbusser, S., "Application performance measurement MIB", , 20 July 2001. [TPM] Dietz, R. and R.G.Cole, "Application Performance Measurement Framework Transport Performance Metrics MIB", Internet Draft, , 16 July 2001. [OWDP] Shalunov, S., Teitelbaum, B. and M. Zekauskas, "A One-Way Delay Protocol for IP Performance Measurements", , February 2001. 12. Security Considerations This document is a description of existing standards and as such it does not have any security impact. 13. Author's Address Steve Waldbusser Phone: +1 650-948-6500 Fax: +1 650-745-0671 Email: waldbusser@nextbeacon.com Expires December 21, 2002 [Page 21] Internet Draft RMON Framework June 21, 2002 Carl W. Kalbfleisch NTT/VERIO 8700 Stemmons Freeway, Suite 211 Dallas, TX 75247 USA Tel: +1 972-906-2034 Email: cwk@verio.net Robert G. Cole AT&T Labs Network Design and Performance Analysis Department 330 Saint John Street, 2nd Floor Havre de Grace, MD 21078 Phone: +1 410-939-8732 Fax: +1 410-939-8732 Email: rgcole@att.com Dan Romascanu Avaya Communication Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Tel: +972-3-645-8414 Email: dromasca@avaya.com Expires December 21, 2002 [Page 22] Internet Draft RMON Framework June 21, 2002 14. Full Copyright Statement Copyright (C) The Internet Society (2002). 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 implementation 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. Expires December 21, 2002 [Page 23] Internet Draft RMON Framework June 21, 2002 Table of Contents 1 Copyright Notice ................................................ 2 2 Abstract ........................................................ 2 3 Table of Contents ............................................... 2 4 The SNMP Network Management Framework ........................... 3 5 Definition of RMON .............................................. 4 6 Goals of RMON ................................................... 4 7 RMON Standards .................................................. 6 7.1 RMON-1 ........................................................ 6 7.2 Token Ring Extensions to RMON MIB ............................. 7 7.3 The RMON-2 MIB ................................................ 9 7.4 RMON MIB Protocol Identifiers ................................. 10 7.5 Remote Network Monitoring MIB Extensions for Switched Net- works ........................................................ 10 7.6 RMON MIB Extensions for Interface Parameters Monitoring ....... 12 7.7 RMON for High Capacity Networks ............................... 12 7.8 Application Performance Measurement MIB ....................... 12 7.9 Transport Performance Metrics MIB ............................. 13 7.10 Synthetic Sources for Performance Monitoring MIB ............. 14 8 RMON Framework Components ....................................... 15 8.1 MediaIndependent Table ........................................ 15 8.2 Protocol Directory ............................................ 15 8.3 Application Directory ......................................... 15 8.4 Data Source ................................................... 15 9 Relationship of APM, TPM, and SSPM MIBs ......................... 16 10 Acknowledgements ............................................... 18 11 Informative References ......................................... 18 12 Security Considerations ........................................ 21 13 Author's Address ............................................... 21 14 Full Copyright Statement ....................................... 23 Expires December 21, 2002 [Page 24]