doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc3577.txt b/doc/rfc/rfc3577.txt
new file mode 100644
index 0000000..6e6d6a6
--- /dev/null
+++ b/doc/rfc/rfc3577.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                      S. Waldbusser
+Request for Comments: 3577                                       R. Cole
+Category: Informational                                             AT&T
+                                                          C. Kalbfleisch
+                                                             Verio, Inc.
+                                                            D. Romascanu
+                                                                   Avaya
+                                                             August 2003
+
+
+   Introduction to the Remote Monitoring (RMON) Family of MIB Modules
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The Remote Monitoring (RMON) Framework consists of a number of
+   interrelated documents.  This memo describes these documents and how
+   they relate to one another.
+
+Table of Contents
+
+   1.  The Internet-Standard Management Framework . . . . . . . . . .  2
+   2.  Definition of RMON . . . . . . . . . . . . . . . . . . . . . .  2
+   3.  Goals of RMON. . . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  RMON Documents . . . . . . . . . . . . . . . . . . . . . . . .  4
+       4.1.  RMON-1 . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       4.2.  Token Ring Extensions to RMON MIB. . . . . . . . . . . .  7
+       4.3.  The RMON-2 MIB . . . . . . . . . . . . . . . . . . . . .  9
+       4.4.  RMON MIB Protocol Identifiers. . . . . . . . . . . . . . 10
+       4.5.  Remote Network Monitoring MIB Extensions for Switched
+             Networks (SMON MIB). . . . . . . . . . . . . . . . . . . 10
+       4.6.  RMON MIB Extensions for Interface Parameters Monitoring
+             (IFTOPN) . . . . . . . . . . . . . . . . . . . . . . . . 12
+       4.7.  RMON Extensions for Differentiated Services (DSMON MIB). 12
+       4.8.  RMON for High Capacity Networks (HCRMON MIB) . . . . . . 13
+       4.9.  Application Performance Measurement MIB (APM MIB). . . . 14
+       4.10. RMON MIB Protocol Identifier Reference Extensions. . . . 15
+       4.11. Transport Performance Metrics MIB (TPM MIB). . . . . . . 16
+
+
+
+
+Waldbusser, et al.           Informational                      [Page 1]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+       4.12. Synthetic Sources for Performance Monitoring MIB
+             (SSPM MIB) . . . . . . . . . . . . . . . . . . . . . . . 17
+       4.13. RMON MIB Extensions for High Capacity Alarms . . . . . . 17
+       4.14. Real-Time  Application Quality of Service Monitoring
+             (RAQMON) MIB . . . . . . . . . . . . . . . . . . . . . . 17
+   5.  RMON Framework Components. . . . . . . . . . . . . . . . . . . 18
+       5.1.  MediaIndependent Table . . . . . . . . . . . . . . . . . 18
+       5.2.  Protocol Directory . . . . . . . . . . . . . . . . . . . 19
+       5.3.  Application Directory and appLocalIndex. . . . . . . . . 21
+       5.4.  Data Source. . . . . . . . . . . . . . . . . . . . . . . 22
+       5.5.  Capabilities . . . . . . . . . . . . . . . . . . . . . . 22
+       5.6.  Control Tables . . . . . . . . . . . . . . . . . . . . . 23
+   6.  Relationship of the SSPM MIB with the APM and TPM MIBs . . . . 24
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+       8.1.  Normative References . . . . . . . . . . . . . . . . . . 27
+       8.2.  Informative References . . . . . . . . . . . . . . . . . 27
+   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 29
+   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
+   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31
+
+1.  The Internet-Standard Management Framework
+
+   For a detailed overview of the documents that describe the current
+   Internet-Standard Management Framework, please refer to section 7 of
+   RFC 3410 [RFC3410].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  MIB objects are generally
+   accessed through the Simple Network Management Protocol (SNMP).
+   Objects in the MIB are defined using the mechanisms defined in the
+   Structure of Management Information (SMI).  This memo specifies a MIB
+   module that is compliant to the SMIv2, which is described in STD 58,
+   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+   [RFC2580].
+
+2.  Definition of RMON
+
+   Remote network monitoring devices, often called monitors or probes,
+   are instruments that exist for the purpose of managing and/or
+   monitoring 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, up to one per network segment, to manage its internet.
+   In addition, these devices may be used to manage a geographically
+   remote network such as for a network management support center of a
+   service provider to manage a client network, or for the central
+   support organization of an enterprise to manage a remote site.
+
+
+
+Waldbusser, et al.           Informational                      [Page 2]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   When the work on the RMON documents was started, this device-oriented
+   definition of RMON was taken quite literally, as RMON devices were
+   purpose-built probes and dedicated to implementing the RMON MIB
+   modules.  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 did not depend on promiscuous packet capture.
+   Today, some of the newest documents added to the RMON framework allow
+   multiple techniques of data gathering, where promiscuous packet
+   capture is just one of several implementation options.
+
+3.  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, RMON allows a probe to be configured to
+         perform diagnostics and to collect statistics continuously,
+         even when communication with 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 to continuously 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
+
+
+
+Waldbusser, et al.           Informational                      [Page 3]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+         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 to continuously 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 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 one management station,
+         potentially using its resources concurrently.
+
+4.  RMON Documents
+
+   The RMON Framework includes a number of documents.  Each document
+   that makes up the RMON framework defines some new useful behavior
+   (i.e., an application) and managed objects that configure, control
+   and monitor that behavior.  This section lists those documents and
+   describes the role of each.
+
+   One of the key ways to differentiate the various RMON MIB modules is
+   by noting at which layer they operate.  Because the RMON MIB modules
+   take measurements and present aggregates of those measurements, there
+   are 2 criteria to quantify for each MIB:
+
+
+
+
+
+Waldbusser, et al.           Informational                      [Page 4]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+      1. At which layers does the MIB take measurements?
+
+         For example, the RMON MIB measures data-link layer attributes
+         (e.g., packets, bytes, errors), while the APM MIB measures
+         application layer attributes (e.g., response time).  Supporting
+         measurement at higher layers requires analysis deeper into the
+         packet and many application layer measurements require stateful
+         flow analysis.
+
+      2. At which layers does the MIB aggregate measurements?
+
+         This criteria notes the granularity of aggregation.  For
+         example, the RMON MIB aggregates its measurements to the link,
+         hardware address, or hardware address pair - all data-link
+         concepts.  In contrast, the RMON-2 MIB takes the same data-link
+         metrics (packets, bytes, errors) and aggregates them based on
+         network address, transport protocol, or application protocol.
+
+   Note that a MIB may take measurements at one level while aggregating
+   at different levels.  Also note that a MIB may function at multiple
+   levels.  Figure 1 and Figure 2 show the measurement layers and
+   aggregation layers for each MIB.
+
+   Measurement Layers
+
+               Data Link       Network     Transport   Application
+                   Layer         Layer         Layer         Layer
+   RMON-1              X
+   TR-RMON             X
+   RMON-2              X
+   SMON                X
+   IFTopN              X
+   HCRMON              X
+   APM                                                           X
+   TPM                                             X
+
+                                  Figure 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Waldbusser, et al.           Informational                      [Page 5]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   Aggregation Layers
+
+               Data Link       Network     Transport   Application
+                   Layer         Layer         Layer         Layer
+   RMON-1              X
+   TR-RMON             X
+   RMON-2                            X             X             X
+   SMON                X
+   IFTopN              X
+   HCRMON              X
+   APM                               X             X             X
+   TPM                               X             X             X
+
+                                  Figure 2
+
+4.1.  RMON-1
+
+   The RMON-1 standard [RFC2819] is focused at layer 2 and provides
+   link-layer statistics aggregated in a variety of ways.  In addition,
+   it provides the 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 network media.
+
+      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.
+
+
+
+
+
+
+Waldbusser, et al.           Informational                      [Page 6]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+      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 MAC 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.
+
+4.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 [RFC1513].  In addition, this MIB defines additional
+   objects that provide monitoring functions unique to Token Ring.
+
+
+
+
+Waldbusser, et al.           Informational                      [Page 7]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   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 the 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 the 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.
+
+
+
+
+
+
+
+Waldbusser, et al.           Informational                      [Page 8]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+      The Token Ring Source Routing Group
+
+         The Token Ring Source Routing Group contains utilization
+         statistics derived from source routing information optionally
+         present in token ring packets.
+
+4.3.  The RMON-2 MIB
+
+   The RMON-2 MIB [RFC2021] 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 the collection of packet and octet
+         counts for any or all 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 on which interface they were last
+         seen.
+
+      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.
+
+
+
+
+
+
+
+Waldbusser, et al.           Informational                      [Page 9]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+      Application Layer Host Group
+
+         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.  This builds a user-configurable
+         set of variables to be monitored (not to be confused with data
+         about users).
+
+      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.
+
+4.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 [RFC2896]
+   is a companion document to the RMON-2 MIB that defines a number of
+   well-known protocols.  Another document, the RMON MIB Protocol
+   Identifiers Macros [RFC2895], defines a macro format for the
+   description of these well-known protocols and others that may be
+   described in the future.
+
+   As the RMON Framework has grown, other documents have been added to
+   the framework that utilize ProtocolIDs.
+
+4.5.  Remote Network Monitoring MIB Extensions for Switched Networks
+      (SMON MIB)
+
+   Switches have become pervasive in today's networks as a form of
+   broadcast media.  SMON [RFC2613] provides RMON-like functions for the
+   monitoring of switched networks.
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 10]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   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
+         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 a 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 sending it out to another port for
+         management purposes.  This occurs in addition to any copying
+         performed during the normal forwarding behavior of the switch.
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 11]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+         The portCopyConfig function provides control of the port copy
+         functionality in a device.
+
+4.6.  RMON MIB Extensions for Interface Parameters Monitoring (IFTOPN)
+
+   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 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 [RFC3144] allows the sorting to occur on the switch and
+   for only the top interfaces to be downloaded.
+
+4.7.  RMON Extensions for Differentiated Services (DSMON MIB)
+
+   This MIB [RFC3287] defines extensions of RMON for monitoring the
+   traffic usage of Differentiated Services [RFC2474] codepoint values.
+   The 6-bit DiffServ codepoint portion (DSCP) of the Type of Service
+   (TOS) octet in the IP header provides for 64 different packet
+   treatments for the implementation of differentiated network devices.
+   DSMON-capable RMON probes collect and aggregate statistics based on
+   the inspection of the DSCP value in monitored packets.
+
+   The DSMON MIB defines a DSCP counter aggregation mechanism to reduce
+   the total number of counters by configuring the agent to internally
+   aggregate counters based on the DSCP value.  This mechanism is
+   designed to overcome the agent data collection limitation, perform
+   data reduction at the agent and applications level, and optimize the
+   application for cases in which some codepoint values are not used, or
+   lead to similar packet treatment in the monitored network domain.
+
+   The components of the DSMON MIB are:
+
+      The Aggregate Control Group
+
+         The Aggregate Control Group enables the configuration of the
+         counter aggregation groups.
+
+      The DSMON Statistics Group
+
+         The DSMON Statistics Group contains per counter aggregation
+         group distribution statistics for a particular RMON data
+         source.
+
+
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 12]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+      The DSMON Protocol Distribution Group
+
+         The DSMON Protocol Distribution Group reports per counter
+         aggregation distribution statistics for each application
+         protocol detected on a particular RMON data source.
+
+      The DSMON Host Group
+
+         The DSMON Host Group contains host address distribution
+         statistics for each counter aggregation group, detected on a
+         particular RMON data source.
+
+      The DSMON Capabilities Group
+
+         The DSMON Capabilities Group reports the DSMON MIB functional
+         capabilities of the agent implementation.
+
+      The DSMON Matrix Group
+
+         The DSMON Matrix Group contains host address pair distribution
+         statistics for each counter aggregation group, detected on a
+         particular RMON data source.
+
+4.8.  RMON for High Capacity Networks (HCRMON MIB)
+
+   This MIB [RFC3272] 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 was not
+   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.
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 13]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+4.9.  Application Performance Measurement MIB (APM MIB)
+
+   The APM MIB [APM] 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 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.
+
+   The APM MIB includes the following functions:
+
+      The APM Application Directory Group
+
+         The APM Application Directory group contains configuration
+         objects for every application or application verb monitored on
+         this system.
+
+      The APM User Defined Applications Group
+
+         The APM User Defined Applications Group contains objects that
+         allow for the tracking of applications or application verbs
+         that are not registered in the protocolDirectoryTable.
+
+      The APM Report Group
+
+         The APM Report Group is used to prepare regular reports that
+         aggregate application performance by flow, by client, by
+         server, or by application.
+
+      The APM Transaction Group
+
+         The APM Transaction Group is used to show transactions that are
+         currently in progress and ones that have ended recently, along
+         with their responsiveness metric.
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 14]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+         One important benefit of this table is that it allows a
+         management station to check on the status of long-lived
+         transactions.  Because the apmReport and apmException
+         mechanisms act only on transactions that have finished, a
+         network manager may not have visibility for some time into the
+         performance of long-lived transactions, such as streaming
+         applications, large data transfers, or (very) poorly performing
+         transactions.  In fact, by their very definition, the apmReport
+         and apmException mechanisms only provide visibility into a
+         problem after nothing can be done about it.
+
+      The APM Exception Group
+
+         The APM Exception Group is used to generate immediate
+         notifications of transactions that cross certain thresholds.
+         The apmExceptionTable is used to configure which thresholds are
+         to be checked for which types of transactions.  The
+         apmTransactionResponsivenessAlarm notification is sent when a
+         transaction occurs with a responsiveness that crosses a
+         threshold.
+
+         The apmTransactionUnsuccessfulAlarm notification is sent when a
+         transaction, for which exception checking was configured,
+         fails.
+
+      The APM Notification Group
+
+         The APM Notification Group contains 2 notifications that are
+         sent when thresholds in the APM Exception Table are exceeded.
+
+4.10.  RMON MIB Protocol Identifier Reference Extensions
+
+   The protocol identifier defined in RMON-2 [RFC2021] can identify any
+   protocol at any layer and its encapsulation.  The protocol identifier
+   macro document [RFC2896] defines a convenient human readable and
+   machine parseable format for documenting well-known protocols.
+
+   For the most part, the protocol identifiers used by RMON-2
+   implementations have described protocols at any layer, including the
+   application layer, but have not gone any deeper into the application.
+   In order to differentiate an application's behavior while performing
+   different tasks (logging in vs. downloading, for example), it is
+   important to have a separate protocol identifier for each application
+   "verb".  The macro defined in [RFC2896] is inconvenient for defining
+   application verbs because it assumes that most protocols are
+   identified by an integer type field and many or most applications use
+   other means for identifying verbs, including character strings.
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 15]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   These extensions define another macro for defining application verbs
+   that are children of an application.  The parent application can be
+   defined with the original protocol identifier macro and the
+   application verbs are defined with the new macro.
+
+4.11.  Transport Performance Metrics MIB (TPM MIB)
+
+   The TPM MIB [TPM] monitors selected performance metrics and
+   statistics derived from the monitoring of network packets and sub-
+   application level transactions.  The MIB is defined to compliment the
+   APM reports by providing a 'drill-down' capability to better
+   understand selected applications' performance.  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 that 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 apmExceptionGroup [APM].  This group reports the
+         aggregated sub-application measurements for those applications
+         exceeding thresholds.
+
+
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 16]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+4.12.  Synthetic Sources for Performance Monitoring MIB (SSPM MIB)
+
+   The Synthetic Sources for Performance Monitoring MIB [SSPM] 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.
+
+4.13.  RMON MIB Extensions for High Capacity Alarms
+
+   There is a need for a standardized way of providing the same type of
+   alarm thresholding capabilities for Counter64 objects, as already
+   exists for Counter32 objects.  The RMON-1 alarmTable objects and
+   RMON-1 notification types are specific to 32-bit objects, and cannot
+   be used to properly monitor Counter64-based objects.  Extensions to
+   these existing constructs are needed which explicitly support
+   Counter64-based objects.  These extensions are completely independent
+   of the existing RMON-1 alarm mechanisms.
+
+   This MIB [RFC3434] contains the following functions:
+
+      The hcAlarmControlObjects group
+
+         Controls the configuration of alarms for high capacity MIB
+         object instances.
+
+      The hcAlarmCapabilities group
+
+         Describes the high capacity alarm capabilities provided by the
+         agent.
+
+      The hcAlarmNotifications group
+
+         Provides new rising and falling threshold notifications for
+         high capacity objects.
+
+4.14.  Real-Time Application Quality of Service Monitoring
+       (RAQMON) MIB
+
+   There is a need to extend the RMON framework to monitor end devices
+   such as IP phones, pagers, Instant Message Clients, mobile phones,
+   and PDA devices.  This memo proposes an extension of RMON Framework
+   to allow Real-time Application QoS information of these types of end
+
+
+
+Waldbusser, et al.           Informational                     [Page 17]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   devices to be retrieved with SNMP, independent of the technology used
+   to perform the measurements.  An end-to-end user experience of the
+   quality of service (QoS) and performance for such an application is a
+   combination of device performance, transport network performance and
+   specific application context.
+
+   RAQMON [RAQMON-FRAMEWORK] defines a common framework to identify a
+   set of application QoS parameters and a reporting mechanism using a
+   common protocol data unit (PDU) format used between a RAQMON Data
+   Source (RDS) and a RAQMON Report Collector (RRC) to report QOS
+   statistics using RTCP and SNMP as underlying transport protocol.
+
+   See the RAQMON MIB [RAQMON-MIB] for more information about its
+   components.
+
+5.  RMON Framework Components
+
+   The collection of documents in the RMON Framework are associated by
+   1) A common purpose and similar collection methodologies; and, 2) Use
+   of common infrastructure components.
+
+   These common infrastructure components are:
+
+      -  MediaIndependent Table
+      -  Protocol Directory
+      -  appDirectory
+      -  DataSource
+      -  Capabilities
+      -  Control Tables
+
+5.1.  MediaIndependent Table
+
+   While many data-link media types exist and they each have unique
+   features, there are many statistics that are common across most
+   media.  For example, counts of packets and octets are interesting for
+   most media.  The media independent table contains the most common
+   such statistics and forms a super class from which specific interface
+   types are inherited.  This means that the common statistics can be
+   monitored even for media types that are unknown.
+
+   For example, if the mediaindependentTable had existed prior to the
+   definition of the etherStatsTable, the etherStatsTable could have
+   omitted the etherStatsDropEvents, etherStatsOctets, etherStatsPkts
+   objects.
+
+   The Media Independent Table is defined in the High Capacity RMON MIB
+   [RFC3434].
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 18]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+5.2.  Protocol Directory
+
+   The second of the RMON infrastructure components is the Protocol
+   Directory Group defined in the RMON-2 MIB [RFC2021].  The main
+   objective of RMON-2 was to extend the remote network monitoring
+   agents capabilities beyond the link layer to higher level protocol
+   monitoring.  This required a means to globally identify individual
+   protocol encapsulations.  This capability is provided by the Protocol
+   Directory Group, specifically the protocolDirID found in the
+   protocolDirTable in the RMON-2 MIB.
+
+   The Protocol Directory allows the agent to provide an inventory of
+   the protocols that the agent can decode, count, categorize and time.
+   The directory and its objects are designed to allow for the addition,
+   deletion and configuration of the protocol encapsulations in the
+   directory list.  Protocol Directory entries are identified primarily
+   by an object called the protocolDirID.  The protocolDirID is a
+   hierarchically formatted OCTET STRING that globally identifies
+   individual protocol encapsulations.  A protocol descriptor macro has
+   been defined in RFC 2895 [RFC2895] to describe the various protocol
+   layers supported in the protocolDirID protocol hierarchy.  The
+   protocolDirID is defined as a tree built up from successive protocol
+   encapsulations.  Each layer is identified by a 4-octet identifier
+   that identifies the child protocol within the context of the parent
+   protocol identified by the preceding identifiers.
+
+   Associated with each protocol layer in the protocolDirID is a 1-octet
+   parameter field.  Each parameter identifies potential options
+   specific to that protocol, such as the agent's capability to count
+   fragmented packets correctly and to track sessions for port mapped
+   protocols, e.g., TFTP.  These 1-octet parameter fields are
+   concatenated, in order, in the protocolDirParameters object.
+
+   The protocolDirTable index is comprised of the protocolDirID, the
+   protocolDirParameters and their associated length fields.  The index
+   format is shown in Figure 3.
+
+      +---+--------------------------+---+---------------+
+      | c !                          | c !  protocolDir  |
+      | n !  protocolDirID           | n !  Parameters   |
+      | t !                          | t !               |
+      +---+--------------------------+---+---------------+
+
+         Figure 3: the protocolDirTable INDEX format.
+
+
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 19]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   An example protocolDirTable INDEX for SNMP over UDP over IP over
+   Ethernet is:
+
+       16.0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
+
+      |  |       |       |        |         | |       |
+      +--+-------+-------+--------+---------+-+-------+
+       c  ether2    ip      udp      snmp    c  param.
+
+       c = 1-subidentifier count field
+
+      Figure 4: A protocolDirTable INDEX example for
+         SNMP over UDP over IP over Ethernet.
+
+   The set of defined protocol layers currently described is found in
+   RFC 2896 [RFC2896].  RFC 2895 [RFC2895] defines a process for
+   submitting new protocols to add to the currently defined set.
+   Periodic updates to RFC 2896 will be published to incorporate new
+   protocol definitions that have been submitted.  In fact, RFC 2896 is
+   the second version of the defined protocol macros, obsoleting RFC
+   2074 [RFC2074].  RFC 2895 also defines how to handle protocols that
+   do not map into this well-defined tree hierarchy built up from
+   encapsulation protocol identifiers.  An example of such a protocol
+   encapsulation is RTP, which is mapped to specific UDP ports through a
+   separate signaling mechanism.  These are handled by the ianaAssigned
+   protocols, as described in RFC 2895.
+
+   The protocolDirTable is defined (and used) in the RMON-2 MIB
+   [RFC2021], and is being used in other RMON WG MIBs, as well as other
+   IETF defined MIBs.  Examples include the APM MIB [APM], the TPM MIB
+   [TPM] and the SSPM MIB [SSPM].
+
+   As mentioned in previous sections, the protocolDirID is being
+   extended in two ways.  First, work is underway on a new set of
+   protocol descriptor macros to extend the protocol encapsulation model
+   to identify application layer verbs [RFC3395].  This extension was
+   motivated by the work on the APM MIB and the TPM MIB.  Second, the
+   APM MIB defines the apmAppDirectoryTable that provides a directory of
+   applications that the agent can process.  This is discussed further
+   in the following section.  Combined, these extensions allow:
+
+      +  The APM MIB to define and monitor the end-user's view of
+         application performance.
+
+      +  The TPM MIB to clearly specify the sub-transactions that
+         comprise the application it monitors through the
+         tpmTransMetricDirTable.
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 20]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+      +  The SSPM MIB to generate synthetic application transactions by
+         importing the appLocalIndex from the APM MIB.
+
+5.3.  Application Directory and appLocalIndex
+
+   APM, TPM and related applications collect certain types of statistics
+   for each application or application verb they are decoding.  Some
+   applications and application verbs are defined in the protocol
+   directory and thus get their own protocolID and a corresponding
+   protocolDirLocalIndex.  Other application verbs are defined more
+   dynamically by entries in the apmHttpFilterTable or
+   apmUserDefinedAppTable.  These dynamically defined applications do
+   not have protocolDirID's assigned to them.
+
+   The APM MIB [APM] defines an important index called the
+   appLocalIndex.  For all application monitoring in the APM and TPM
+   MIBs, applications are identified by integer values of the
+   appLocalIndex.  However, there is no single registry of applications
+   (as there is for protocols) because there are a few different
+   mechanisms through which an application may be registered.  For each
+   value of appLocalIndex, a corresponding entry will exist in one of
+   several tables:
+
+      1. The protocolDirTable - Some values of appLocalIndex correspond
+         to protocolDirLocalIndex values assigned in the
+         protocolDirTable.  Each of these corresponds to a protocol
+         defined by a protocolID.
+
+      2. The apmHttpFilterTable - Some values of appLocalIndex
+         correspond to apmHttpFilterAppLocalindex values assigned in the
+         apmHttpFilterTable.  Each of these corresponds to an
+         application verb defined as a set of HTTP transactions that
+         match a set of filters.
+
+      3. The apmUserDefinedAppTable - Some values of appLocalIndex
+         correspond to index values of the apmUserDefinedAppTable.  Each
+         of them corresponds to an application or application verb
+         defined in a user-defined way.
+
+   Each value of appLocalIndex will only be registered in one of these
+   tables.  In effect, the appLocalIndex number space is the union of
+   these number spaces, where these tables must work together to avoid
+   assigning overlapping (duplicate) appLocalIndexes.
+
+   Each unique appLocalIndex value is also registered in the
+   apmAppDirectoryTable, where a number of attributes of the application
+   may be configured.
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 21]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+5.4.  Data Source
+
+   Most RMON functions use a DataSource as a pointer to the entity from
+   which data is to be collected.  The DataSource is an object
+   identifier that identifies one of three types of data sources:
+
+      ifIndex.<I>
+
+         Traditional RMON dataSources.  Called 'port-based' for
+         ifType.<I> not equal to 'propVirtual(53)'.  <I> is the ifIndex
+         value.
+
+      smonVlanDataSource.<V>
+
+         A dataSource of this form refers to a 'Packet-based VLAN' and
+         is called a 'VLAN-based' dataSource.  <V> is the VLAN ID as
+         defined by the IEEE 802.1Q standard.  The value is between 1
+         and 4094 inclusive, and it represents an 802.1Q VLAN-ID with a
+         global scope within a given bridged domain, as defined by
+         802.1Q.
+
+      entPhysicalEntry.<N>
+
+         A dataSource of this form refers to a physical entity within
+         the agent and is called an 'entity-based' dataSource.  <N> is
+         the value of the entPhysicalIndex in the entPhysicalTable.
+
+5.5.  Capabilities
+
+   Probe Capabilities objects have been introduced in the RMON MIB
+   modules with the goal of helping applications determine the
+   capabilities of the different probes in the domain.  These objects
+   use a BITS syntax (with the exception of some of the objects in the
+   TPM and SSPM MIBs), and list in an explicit manner the MIB groups
+   supported by the probe, as well as functional capabilities of the
+   specific RMON agents.  By reading the values of these objects, it is
+   possible for applications to know which RMON functions are usable
+   without going through a trial-and-error process that can result in
+   loss of time and bandwidth in the operational flow.  These objects
+   have the MAX-ACCESS of read-only, which defines their use as an
+   indication of what is supported by a probe, and not a means to
+   configure the probe for operational modes.  An RMON agent SHOULD
+   initiate the capabilities objects at agent initialization and SHOULD
+   NOT modify the objects during operation.
+
+   The probeCapabilities object in the RMON-2 MIB describes the
+   capabilities of probes that support RMON, Token-Ring RMON and RMON-2.
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 22]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   The smonCapabilities object in the SMON MIB describes the SMON-
+   specific capabilities of probes that support the SMON MIB.
+
+   The dataSourceCapsTable in the SMON MIB defines the capabilities of
+   the SMON data sources on probes that support the RMON MIB.
+
+   The interfaceTopNCaps object in the Interface TopN MIB defines the
+   sorting capabilities supported by an agent that supports the
+   Interface TopN MIB.
+
+   The dsmonCapabilities object in the DSMON MIB provides an indication
+   of the DSMON groups supported by an agent that supports the DSMON
+   MIB.
+
+   The tpmCapabilitiesGroup contains objects and tables, which show the
+   measurement protocol and metric capabilities of an agent that
+   supports the TPM MIB.
+
+   The sspmCapabilitiesTable indicates whether a device supporting the
+   SSPM MIB supports SSPM configuration of the corresponding
+   AppLocalIndex.
+
+   The hcAlarmCapabilities object provides an indication of the high
+   capacity alarm capabilities supported by an agent that supports the
+   HC-Alarm MIB.
+
+5.6.  Control Tables
+
+   Due to the complex nature of the available functions in the RMON MIB
+   modules, these functions often need user configuration.  In many
+   cases, the function requires parameters to be set up for a data
+   collection operation.  The operation can proceed only after these
+   parameters are fully set up.
+
+   Many functional groups in the RMON MIBs have one or more tables in
+   which to set up control parameters, and one or more data tables in
+   which to place the results of the operation.  The control tables are
+   typically read-write in nature, while the data tables are typically
+   read-only.  Because the parameters in the control table often
+   describe resulting data in the data table, many of the parameters can
+   be modified only when the control entry is invalid.  Thus, the method
+   for modifying these parameters is to invalidate the control entry,
+   causing its deletion and the deletion of any associated data entries,
+   and then create a new control entry with the proper parameters.
+   Deleting the control entry also gives a convenient method for
+   reclaiming the resources used by the associated data.
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 23]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   To facilitate control by multiple managers, resources have to be
+   shared among the managers.  These resources are typically the memory
+   and computation resources that a function requires.
+
+   Two facilities are used to ease cooperation between multiple managers
+   as they create and use control tables.  The first is the use of
+   EntryStatus or RowStatus objects that guarantee that two managers can
+   avoid creating the same control entry.  The second is the use of
+   OwnerString objects in control tables that provides the following
+   benefits:
+
+      1. Provides information to facilitate sharing of already existing
+         control entries instead of creating a new but identical entry.
+
+      2. Provides information to allow the ultimate human owners of
+         control entries to identify each other so they can cooperate in
+         cases of conflict over resources.
+
+      3. Provides information to allow software to identify control
+         entries that it owns but has forgotten about (e.g., due to a
+         crash or other error) so that it can re-use or free them.
+
+      4. Provides information to allow an administrator to make an
+         informed decision to override someone else's control entry when
+         circumstances make it necessary.
+
+      5. Provides information to identify control entries that are set
+         up automatically when the device starts up.
+
+   See the RMON MIB [RFC2819] for further information on the use of
+   control tables, EntryStatus/RowStatus, and OwnerStrings.
+
+6.  Relationship of the SSPM MIB with the APM and TPM MIBs
+
+   While APM and TPM may monitor actual traffic generated by end-users
+   on the network, they may also monitor synthetically generated
+   traffic.  The SSPM MIB provides a mechanism for the generation of
+   synthetic traffic but no mechanism for monitoring - the task of
+   monitoring the generated traffic is deferred to the APM and TPM MIBs.
+
+   Figure 5 shows an overview of the components of the SSPM MIB
+   architecture, including the roles played by the APM and TPM MIBs.
+   The RMON documents address the "Control-Level" in this diagram and
+   some aspects of the "Synchronization Control-Level".  The underlying
+   "Instrumentation-Level" is implementation dependent and outside the
+   domain of the RMON specifications.
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 24]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+                            +----------------+
+              +-------------|   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 5: An SSPM Performance Monitoring System
+
+   It is the responsibility of the network management application to
+   coordinate the individual aspects of the performance management
+   system.
+
+   Within the APM, TPM, and SSPM set of RMON MIB modules:
+
+      +  APM MIB [APM] is responsible for the aspects of the "Monitoring
+         Metrics Control" directly related to the end-user's perceived
+         application-level performance.  The APM MIB also handles
+         aspects of "Data Reduction Control" and "Reports".  Finally,
+         when TPM MIB relies upon the control tables in the APM MIB for
+         its own control, then APM MIB is providing some aspects of
+         "Synchronization Control" of the reports from these two MIBs.
+
+
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 25]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+      +  TPM MIB [TPM] is responsible for the aspects of the "Monitoring
+         Metrics Control".  TPM MIB also handles aspects of "Data
+         Reduction Control" and "Reports" related to sub-application-
+         level transactions.  Synchronization control with APM MIB is
+         provided by opting to rely on the APM MIB control tables within
+         the TPM MIB.
+
+      +  SSPM MIB [SSPM] is responsible for the "Traffic Generation
+         Control" in the event that synthetic traffic is to be
+         monitored.  The other, most common, option is to monitor
+         natural, user-generated traffic.
+
+   The "Monitor Metrics Control" is essentially hard-coded in the APM
+   MIB.  Within the TPM MIB, a metrics table is used to identify the
+   metrics monitored within a specific implementation of the TPM MIB.
+   The "Data Reduction Control" is essentially hard-coded within the MIB
+   structure of the APM MIB and the TPM MIB.  These MIBs strictly
+   specify the statistics to be reported within a set of report tables.
+
+   Both the TPM MIB and the SSPM MIB rely upon the APM MIB's
+   appLocalIndex to specify the application being monitored or
+   generated.  The APM MIB provides the end-user view of the application
+   performance, e.g., the Whois transaction time.  The TPM MIB, through
+   its tpmTransMetricDirTable, identifies a set of sub-application level
+   transactions and their metrics, which are associated with the
+   application.  E.g., an implementation of the TPM MIB could report the
+   DNS lookup time, the TCP connect time (to the Whois Server), the
+   Whois Req/Resp download time.  The SSPM MIB could be configured to
+   generate synthetically, these Whois transactions.
+
+   The testing model then is to first configure the traffic generation
+   instrumentation through the SSPM MIB 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 APM MIB and TPM MIB.  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., APM MIB and TPM MIB.
+
+7.  Acknowledgements
+
+   This memo is a product of the RMON MIB working group.  In addition,
+   the authors gratefully acknowledge the contributions by Lester
+   D'Souza of NetScout Systems, Inc.
+
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 26]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2819]          Waldbusser, S., "Remote Network Monitoring
+                      Management Information Base", STD 59, RFC 2819,
+                      May 2000.
+
+8.2.  Informative References
+
+   [RFC2026]          Bradner, S., "The Internet Standards Process --
+                      Revision 3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2578]          McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+                      Eds., "Structure of Management Information Version
+                      2 (SMIv2)", STD 58, RFC 2578, April 1999.
+
+   [RFC2579]          McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+                      J., Eds., "Textual Conventions for SMIv2", STD 58,
+                      RFC 2579, April 1999.
+
+   [RFC2580]          McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+                      J., Eds., "Conformance Statements for SMIv2", STD
+                      58, RFC 2580, April 1999.
+
+   [RFC3410]          Case, J., Mundy, R., Partain, D. and B. Stewart,
+                      "Introduction and Applicability Statements for
+                      Internet-Standard Management Framework", RFC 3410,
+                      December 2002.
+
+   [RFC1513]          Waldbusser, S., "Token Ring Extensions to the
+                      Remote Network Monitoring MIB", RFC 1513,
+                      September 1993.
+
+   [RFC2021]          Waldbusser, S., "Remote Network Monitoring
+                      Management Information Base Version 2 using
+                      SMIv2", RFC 2021, January 1997.
+
+   [RFC2895]          Bierman, A., Bucci, C. and R. Iddon, "Remote
+                      Network Monitoring Management Information Base
+                      Protocol Identification Reference", RFC 2895,
+                      August 2000.
+
+   [RFC2896]          Bierman, A., Bucci, C. and R. Iddon, "Remote
+                      Network Monitoring MIB Protocol Identifier
+                      Macros", RFC 2896, August 2000.
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 27]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   [RFC2613]          Waterman, R., Lahaye, B., Romascanu, D. and S.
+                      Waldbusser, "Remote Network Monitoring MIB
+                      Extensions for Switched Networks Version 1.0", RFC
+                      2613, June 1999.
+
+   [RFC3144]          Waldbusser, S., "Remote Monitoring MIB Extensions
+                      for Interface Parameters Monitoring", RFC 3144,
+                      August 2001.
+
+   [RFC3287]          Bierman, A., "Remote Monitoring MIB Extensions for
+                      Differentiated Services", RFC 3287, July 2002.
+
+   [RFC3273]          Waldbusser, S., "Remote Network Monitoring
+                      Management Information Base for High Capacity
+                      Networks", RFC 3273, July 2002.
+
+   [APM]              Waldbusser, S., "Application performance
+                      measurement MIB", Work in Progress.
+
+   [RFC3395]          Bierman, A., Bucci, C., Dietz, R. and A. Warth,
+                      "Remote Network Monitoring MIB Protocol Identifier
+                      Reference Extensions", RFC 3395, September 2002.
+
+   [TPM]              Dietz, R. and R.G.Cole, "Application Performance
+                      Measurement Framework Transport Performance
+                      Metrics MIB", Work in Progress.
+
+   [SSPM]             Kalbfleisch, K., Cole, R.G. and D. Romascanu,
+                      "Definition of Managed Objects for Synthetic
+                      Sources for Performance Monitoring Algorithms",
+                      Work in Progress.
+
+   [RFC3434]          Bierman, A. and K. McCloghrie, "Remote Monitoring
+                      MIB Extensions for High Capacity Alarms", RFC
+                      3434, December 2002.
+
+   [RFC2233]          McCloghrie, K. and F. Kastenholz, "The Interfaces
+                      Group MIB Using SMIv2", RFC 2233, November 1997.
+
+   [RFC2863]          McCloghrie, K. and F. Kastenholz, "The Interfaces
+                      Group MIB", RFC 2863, June 2000.
+
+   [RFC2330]          Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
+                      "Framework for IP Performance Metrics", RFC 2330,
+                      May 1998.
+
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 28]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+   [OWDP]             Shalunov, S., Teitelbaum, B. and M. Zekauskas, "A
+                      One-way Active Measurement Protocol", Work in
+                      Progress.
+
+   [RAQMON-FRAMEWORK] Siddiqui, A., Romascanu, D. and E. Golovinsky,
+                      "Real-time Application Quality of Service
+                      Monitoring (RAQMON) Framework", Work in Progress.
+
+   [RAQMON-MIB]       Siddiqui, A., Romascanu, D., Golovinsky, E. and R.
+                      Smith, "Real-Time Application Quality of Service
+                      Monitoring (RAQMON) MIB", Work in Progress.
+
+9.  Security Considerations
+
+   This document is a description of existing documents and as such it
+   does not have any security impact.  In order to understand the
+   security-related issues of the different RMON documents, the reader
+   is directed to the Security Considerations sections of the respective
+   documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 29]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+10.  Authors' Addresses
+
+   Steve Waldbusser
+
+   Phone: +1 650-948-6500
+   Fax:   +1 650-745-0671
+   EMail: waldbusser@nextbeacon.com
+
+
+   Carl W. Kalbfleisch
+   NTT/VERIO
+   8700 Stemmons Freeway, Suite 211
+   Dallas, TX 75247
+   United States
+
+   Phone: +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
+   United States
+
+   Phone: +1 410-939-8732
+   Fax: +1 410-939-8732
+   EMail: rgcole@att.com
+
+
+   Dan Romascanu
+   Avaya
+   Atidim Technology Park, Bldg. #3
+   Tel Aviv, 61131
+   Israel
+
+   Phone: +972-3-645-8414
+   EMail: dromasca@avaya.com
+
+
+
+
+
+
+
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 30]
+
+RFC 3577                  Introduction to RMON               August 2003
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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 assignees.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Waldbusser, et al.           Informational                     [Page 31]
+