Internet Draft Steve Waldbusser
R.G. Cole
AT&T
C. Kalbfleisch
Verio, Inc.
D. Romascanu
Avaya Inc.
6 January 2003
Introduction to the RMON Family of MIB Modules
<draft-ietf-rmonmib-framework-03.txt>
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 <sming@ops.ietf.org>.
Expires July 6, 2003 [Page 1]
Internet Draft RMON Introduction January 6, 2003
1. Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
2. Abstract
The RMON Framework consists of a number of interrelated documents. This
memo describes these documents 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 Internet-Standard Management Framework ...................... 3
5 Definition of RMON .............................................. 3
6 Goals of RMON ................................................... 4
7 RMON Documents .................................................. 5
7.1 RMON-1 ........................................................ 7
7.2 Token Ring Extensions to RMON MIB ............................. 8
7.3 The RMON-2 MIB ................................................ 10
7.4 RMON MIB Protocol Identifiers ................................. 11
7.5 Remote Network Monitoring MIB Extensions for Switched Net-
works ........................................................ 11
7.6 RMON MIB Extensions for Interface Parameters Monitoring ....... 13
7.7 RMON Extensions for Differentiated Services (DSMON MIB) ....... 13
7.8 RMON for High Capacity Networks ............................... 14
7.9 Application Performance Measurement MIB ....................... 15
7.10 RMON MIB Protocol Identifier Reference Extensions ............ 16
7.11 Transport Performance Metrics MIB ............................ 17
7.12 Synthetic Sources for Performance Monitoring MIB ............. 18
7.13 RMON MIB Extensions for High Capacity Alarms ................. 18
7.14 Real-Time Application Quality of Service Monitoring (RAQ-
MON) MIB ..................................................... 19
8 RMON Framework Components ....................................... 20
8.1 MediaIndependent Table ........................................ 20
8.2 Protocol Directory ............................................ 20
8.3 Application Directory and appLocalIndex ....................... 23
8.4 Data Source ................................................... 24
Expires July 6, 2003 [Page 2]
Internet Draft RMON Introduction January 6, 2003
8.5 Capabilities .................................................. 24
8.6 Control Tables ................................................ 25
9 Relationship of the SSPM MIB with the APM and TPM MIBs .......... 27
10 Acknowledgements ............................................... 29
11 Informative References ......................................... 29
12 Security Considerations ........................................ 33
13 Authors' Address ............................................... 33
14 Full Copyright Statement ....................................... 35
4. 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].
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, 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 a for a network
management support center of service provider to manage a client network
or for the central support organization of an enterprise to manage a
remote site.
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
Expires July 6, 2003 [Page 3]
Internet Draft RMON Introduction January 6, 2003
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, 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.
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, 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 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
Expires July 6, 2003 [Page 4]
Internet Draft RMON Introduction January 6, 2003
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
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.
7. 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 described the role
of each.
One of the key ways to differentiate the various RMON MIBs is by noting
Expires July 6, 2003 [Page 5]
Internet Draft RMON Introduction January 6, 2003
at which layer they operate. Because the RMON MIBs take measurements and
present aggregates of those measurements, there are 2 criteria to
quantify for each MIB:
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 aggegate 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 RMON2 MIB takes the same data-link metrics
(packets, bytes, errors) and aggregates them based on network
address, transport protocol, or appplication 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
RMON2 X
SMON X
IFTopN X
HCRMON X
APM X
TPM X
Figure 1
Aggregation Layers
Expires July 6, 2003 [Page 6]
Internet Draft RMON Introduction January 6, 2003
Data Link Network Transport Application
Layer Layer Layer Layer
RMON-1 X
TR-RMON X
RMON2 X X X
SMON X
IFTopN X
HCRMON X
APM X X X
TPM X X X
Figure 2
7.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 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.
Expires July 6, 2003 [Page 7]
Internet Draft RMON Introduction January 6, 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 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 [RFC1513]. In addition, this MIB defines additional objects that
Expires July 6, 2003 [Page 8]
Internet Draft RMON Introduction January 6, 2003
provide 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.
Expires July 6, 2003 [Page 9]
Internet Draft RMON Introduction January 6, 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.
7.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 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.
Expires July 6, 2003 [Page 10]
Internet Draft RMON Introduction January 6, 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.
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 [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.
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 [RFC2613] provides RMON-like functions for the
monitoring of switched networks.
Expires July 6, 2003 [Page 11]
Internet Draft RMON Introduction January 6, 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 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.
Expires July 6, 2003 [Page 12]
Internet Draft RMON Introduction January 6, 2003
The portCopyConfig function provides control of the port copy
functionality in a device.
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 [RFC3144]
allows the sorting to occur on the switch and for only the top
interfaces to be downloaded.
7.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, performs data
reduction at the agent and applications level, and optimizes the
application for cases when 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.
Expires July 6, 2003 [Page 13]
Internet Draft RMON Introduction January 6, 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.
7.8. RMON for High Capacity Networks
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 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
Expires July 6, 2003 [Page 14]
Internet Draft RMON Introduction January 6, 2003
attributes unique to particular media such as error counters.
7.9. Application Performance Measurement 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
aren't 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
Expires July 6, 2003 [Page 15]
Internet Draft RMON Introduction January 6, 2003
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.
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 fails for which exception checking was configured.
The APM Notification Group
The APM Notification Group contains 2 notifications that are sent
when thresholds in the APM Exception Table are exceeded.
7.10. RMON MIB Protocol Identifier Reference Extensions
The protocol identifier defined in RMON2 [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 RMON2 implementations
have described protocols at any layer including the application layer
but haven't 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
Expires July 6, 2003 [Page 16]
Internet Draft RMON Introduction January 6, 2003
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.
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.
7.11. Transport Performance Metrics MIB
The TPM MIB [TPM] monitors selectable 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
Expires July 6, 2003 [Page 17]
Internet Draft RMON Introduction January 6, 2003
defined in the apmExceptionGroup [APM]. This group reports the
aggregated sub-application measurements for those applications
exceeding thresholds.
7.12. Synthetic Sources for Performance Monitoring 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.
7.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
Provide new rising and falling threshold notifications for high
Expires July 6, 2003 [Page 18]
Internet Draft RMON Introduction January 6, 2003
capacity objects.
7.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 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 RAQMON Data Source (RDS)
and 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.
Expires July 6, 2003 [Page 19]
Internet Draft RMON Introduction January 6, 2003
8. 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
8.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
[RFC3287].
8.2. Protocol Directory
The second of the RMON infrastructure components is the Protocol
Directory Group defined in the RMON2 MIB [RFC2021]. The main objective
of RMON2 was to extend the remote network monitoring agents capabilities
beyond 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 and specifically
the protocolDirID found in the protocolDirTable in the RMON2 MIB.
The Protocol Directory allows the agent to provide an inventory of the
Expires July 6, 2003 [Page 20]
Internet Draft RMON Introduction January 6, 2003
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.
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.
Expires July 6, 2003 [Page 21]
Internet Draft RMON Introduction January 6, 2003
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
RFC2896 [RFC2896]. RFC2895 [RFC2895] defines a process for submitting
new protocols to add to the currently defined set. Periodic updates to
RFC2896 will be published to incorporate new protocol definitions that
have been submitted. In fact, RFC2896 is the second version of the
defined protocol macros, obsoleting RFC2074 [RFC2074]. RFC2895 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 RFC2895.
The protocolDirTable is defined (and used) in the RMON2 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 recently being
extended in two ways. First, work is underway on a new set of protocol
descriptor macros which 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 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.
+ The SSPM MIB to generate synthetic application transactions by
importing the appLocalIndex from the APM MIB.
Expires July 6, 2003 [Page 22]
Internet Draft RMON Introduction January 6, 2003
8.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 don't
have protocolDirID's assigned to them
The APM MIB 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 correspond 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.
Expires July 6, 2003 [Page 23]
Internet Draft RMON Introduction January 6, 2003
8.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 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.
8.5. Capabilities
Probe Capabilities objects have been introduced in the RMON MIBs 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 RMON2 MIB describes the capabilities
Expires July 6, 2003 [Page 24]
Internet Draft RMON Introduction January 6, 2003
of probes that support RMON, Token-Ring RMON and RMON2.
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.
8.6. Control Tables
Due to the complex nature of the available functions in the RMON MIBs,
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
Expires July 6, 2003 [Page 25]
Internet Draft RMON Introduction January 6, 2003
also gives a convenient method for reclaiming the resources used by the
associated data. b 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.
Expires July 6, 2003 [Page 26]
Internet Draft RMON Introduction January 6, 2003
9. 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 below 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.
+----------------+
+-------------| 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
Expires July 6, 2003 [Page 27]
Internet Draft RMON Introduction January 6, 2003
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 MIBs:
+ APMMIB [APM] is responsible for the aspects of the "Monitoring
Metrics Control" directly related to the end-user's perceived
application-level performance. The APMMIB also handles aspects of
"Data Reduction Control" and "Reports". Finally, when TPMMIB
relies upon the control tables in the APMMIB for its own control,
then APMMIB is providing some aspects of "Synchronization Control"
of the reports from these two MIBs.
+ TPMMIB [TPM] is responsible for the aspects of the "Monitoring
Metrics Control". TPMMIB also handles aspects of "Data Reduction
Control" and "Reports" related to sub-application-level
transactions. Synchronization control with APMMIB is provided by
opting to rely on the APMMIB control tables within the TPMMIB.
+ SSPMMIB [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
APMMIB. Within the TPMMIB, a metrics table is used to identify the
metrics monitored within a specific implementation of the TPMMIB.
The "Data Reduction Control" is essentially hard-coded within the MIB
structure of the APMMIB and the TPMMIB. These MIBs strictly specify
the statistics to be reported within a set of report tables.
Both the TPMMIB and the SSPMMIB rely upon the APMMIB's appLocalIndex
to specify the application being monitored or generated. The APMMIB
provides the end-user view of the application performance, e.g., the
Whois transaction time. The TPMMIB, 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 TPMMIB could report the
DNS lookup time, the TCP connect time (to the Whois Server), the
Whois Req/Resp download time. The SSPMMIB could be configured to
generate synthetically, these Whois transactions.
The testing model then is to first configure the traffic generation
instrumentation through the SSPMMIB control function. This defines
Expires July 6, 2003 [Page 28]
Internet Draft RMON Introduction January 6, 2003
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.
10. 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.
11. Informative References
[RFC3416]
SNMPv2 Working Group, Case, J., McCloghrie, K., Presuhn, R., Rose,
M., and S. Waldbusser, "Protocol Operations for Version 2 of the
Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3416,
December 2002.
[RFC3417]
SNMPv2 Working Group, Case, J., McCloghrie, K., Presuhn, R., Rose,
M., and S. Waldbusser, "Transport Mappings for Version 2 of the
Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3417,
December 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.
[RFC3411]
Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", STD 62, RFC 3411, December
2002.
[RFC3412]
Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Expires July 6, 2003 [Page 29]
Internet Draft RMON Introduction January 6, 2003
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[RFC3413]
Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", STD 62,
RFC 3413, December 2002.
[RFC3414]
Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)", STD
62, RFC 3414, December 2002.
[RFC3415]
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", STD 62, RFC 3415, December 2002.
[RFC2578]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Structure of Management Information Version 2
(SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC
2579, April 1999.
[RFC2580]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC
2580, April 1999.
[RFC1155]
Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155, May
1990.
[RFC1157]
Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", RFC 1157, May 1990.
[RFC1212]
Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212,
March 1991.
Expires July 6, 2003 [Page 30]
Internet Draft RMON Introduction January 6, 2003
[RFC1215]
M. Rose, "A Convention for Defining Traps for use with the SNMP",
RFC 1215, March 1991.
[RFC1901]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
[RFC3418]
SNMPv2 Working Group, Case, J., McCloghrie, K., Presuhn, R., Rose,
M., and S. Waldbusser, "Management Information Base for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1907,
December 2002.
[RFC3410]
Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and
Applicability Statements for Internet-Standard Management
Framework", RFC 3410, December 2002.
[RFC2819]
Waldbusser, S., Remote Network Monitoring Management Information
Base, RFC 2819, May 2000.
[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
Management Information Base Protocol Identifier Macros, RFC 2896,
August 2000.
[RFC2613]
Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, Remote
Network Monitoring MIB Extensions for Switched Networks Version
Expires July 6, 2003 [Page 31]
Internet Draft RMON Introduction January 6, 2003
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", <draft-
ietf-rmonmib-apm-mib-07.txt>, April 2002.
[RFC3395]
Bierman, A., Bucci, C., Dietz, R. and A. Warth, Remote Network
Monitoring Management Information Base Protocol Identifier
Reference Extensions, RFC3395, September 2002.
[TPM]
Dietz, R. and R.G.Cole, "Application Performance Measurement
Framework Transport Performance Metrics MIB", Internet Draft,
<draft-ietf-rmonmib-tpm-mib-07.txt>, August 2002.
[SSPM]
Kalbfleisch, K., Cole, R.G. and D. Romascanu, "Definition of
Managed Objects for Synthetic Sources for Performance Monitoring
Algorithms, <draft-ietf-rmonmib-sspm-mib-06.txt>, September 2002.
[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, Cisco Systems, FTP Software, November, 1997.
[RFC2863]
McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC
2863, Cisco Systems, Argon Networks, June, 2000.
Expires July 6, 2003 [Page 32]
Internet Draft RMON Introduction January 6, 2003
[RFC2330]
Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP
Performance Metrics", RFC 2330, May 1998.
[OWDP]
Shalunov, S., Teitelbaum, B. and M. Zekauskas, "A One-way Active
Measurement Protocol", <draft-ietf-ippm-owdp-05.txt>, August 2002.
[RAQMON-FRAMEWORK]
Siddiqui, A., Romascanu, D. and E. Golovinsky, "Real-time
Application Quality of Service Monitoring (RAQMON) Framework",
<draft-siddiqui-rmonmib-raqmon-framework-00.txt>, October, 2002.
[RAQMON-MIB]
Siddiqui, A., Romascanu, D., Golovinsky, E., and R. Smith, "Real-
time Application Quality of Service Monitoring (RAQMON) MIB",
<draft-siddiqui-rmonmib-raqmon-mib-02.txt>, October, 2002.
12. Security Considerations
This document is a description of existing documents and as such it does
not have any security impact.
13. Authors' Address
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
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
Expires July 6, 2003 [Page 33]
Internet Draft RMON Introduction January 6, 2003
Fax: +1 410-939-8732
Email: rgcole@att.com
Dan Romascanu
Avaya Inc.
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com
Expires July 6, 2003 [Page 34]
Internet Draft RMON Introduction January 6, 2003
14. 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 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 July 6, 2003 [Page 35]
