Internet Draft R.G. Cole
Expiration Date: Sept 2000 AT&T
C. Kalbfleisch
Verio, Inc.
D. Romascanu
Lucent
A Framework for Active Probes for Performance Monitoring
<draft-cole-appm-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
2. Abstract
This memo discusses the use of 'active' probes within the context of
remote performance monitoring. It discusses the importance of
developing an 'active' probe monitoring capability within the
Internet. It develops a framework for active probes in performance
monitoring against the backdrop of previous, related work within the
IETF.
Distribution of this memo is unlimited.
Cole, et al. [Page 1]
Internet Draft draft-cole-appm-00.txt March 2000
3. Objectives and Motivation
3.1 Introduction
There is much utility in fully defining a performance monitoring
capability within the IETF. As the Internet architecture becomes
more complex, as enhanced QOS capabilities are defined and deployed,
performance monitoring capabilities must be developed to account for
this richer transport and service infrastructure. ISP's will be
offering enhanced transport services, content hosting services will
offer differentiated hosting services, and customers will demand
methods to monitor the quality of the services to which they
subscribe.
This memo defines a framework for the development of an 'active'
probe capability for the purpose of enhancing remote performance
monitoring capabilites within IP networks and services. By an
'active' probe, we mean a device or embedded software which generates
a data packet (or packets) and injects it (them) into the network to
a corresponding probe or existing server for the primary purpose of
measuring some aspect of the performance of the end-to-end path or
service. By performance monitoring we mean the act of collecting a
specific set of measurements, either actively or passively, for the
purpose of evaluating the quality of the path or the service. Much
work within the IETF exists related to performance monitoring. One
interesting aspect of this body of work is that it does not
explicitly define an 'active' probe capability. An active probe is
complimentary to existing capabilities, and should be developed by
building as much as possible on this existing work.
3.2 Terms
This section defines the terms used throughout this memo.
+ 'Performance monitoring' is the act of monitoring traffic for
the purpose of evaluating a statistic of a metric related to the
performance of the system.
+ A 'probe' is a device or embedded software program that is
placed in the data flow path or on a client or server to provide a
performance monitoring function.
+ An 'active probe' is a probe which generates a data packet (or
packets) and injects it (them) onto the path to a corresponding
probe or existing server and provides a performance monitoring
function based upon measurements made upon the packets that it
injects. An active probe may talk intrusively to existing
application servers.
Cole, et al. [Page 2]
Internet Draft draft-cole-appm-00.txt March 2000
+ A 'passive probe' is a probe which non-intrusively listens to
packets flowing across the 'wire' or monitors request/responses on
a client or server and provides a performance monitoring function
based upon its observations.
+ A 'path' is a set of network transport components that provide a
transport service between a given source and destination address
pair. In its simpliest form the network components are a series
of routers interconnected by links. In more complex scenarios, a
path has a more complex topology due to asymetric routes,
alternate paths, load balancing and redirection.
+ A 'service' is a collection of network components and servers
designed to deliver a capability to an end user. The service
could be a transport capability, a processing capability, etc.
3.3 Motivation
There are a number reasons to develop an active probe capability for
performance monitoring within the Internet. However, thay all
fundamentally boil down to the single issue of control. As discussed
at length in the IPPM framework document [1], if you do not control
the nature of the traffic generation, then you do not control the
sampling and hence you do not control the quality of the respective
statistics. It is important to control the timing of the packet
generation to ensure the quality of the statistic (i.e., the random
nature of the underlying sample). It is important to control the
path of the test packets (at least the source and destination) to
ensure that enough measurements are taken over the path in order to
accurately identify the quality of the path. It is important to
control the 'size' of the transactions to ensure that the
measurements are relavant to the metric, e.g., throughput statistics
should be based upon measurements with large files.
The utility of active probe capabilities will be found in:
+ troubleshooting paths - a pingMIB [3] identifies that
connectivity exists but additional capabilities are required to
determine the quality of the connectivity,
+ circuit pre-test and turn-up - prior to turning up a capability
or customer, there is much value in monitoring the quality of
their path or service prior to putting the customer on-line
(without the capability of generating probe traffic this can be
problematic),
+ fault management - allows determination of whether the
application is operating or not,
Cole, et al. [Page 3]
Internet Draft draft-cole-appm-00.txt March 2000
+ baselining enhancements - active probes could be used to base-
line BEFORE and measure AFTER a certain set of QoS or routing
policies are applied. This would try to provide an answer to the
question 'how effective is my proposed policy strategy?'.
+ capacity management - typical capacity management programs
monitor local, utilization statistics to drive a capacity
management decision, e.g., upgrade a facility, a CPU, etc. An
active probe could be used to monitor complimentary aspects of
network performance, more akin to an end-to-end metric, whose
results could drive capacity management decisions as well. (This
can be correlated to component level measures and can trigger
specific capacity upgrades.),
+ Service Level Agreement (SLA) monitoring - because the nature of
the probe packets, which measure a metric, are tightly specified,
the corresponding statistics will have significance within the
context of an SLA.
The bulk of the current development within the IETF is in the area of
defining 'passive' monitoring, either self-monitoring as counters of
local metrics or external-monitoring as defined within the RMON
working group [2]. In contrast to passive monitoring is, what we
refer to as, active monitoring. Active monitoring relies upon the
injection of probe data or 'request' packets into the transport
network or into a service. The active monitoring probe (or
cooperating probes) then performs some type of measurement based upon
the specific packet(s) it injects.
There are distinct advantages and disadvantages of both passive and
active performance monitoring. These two approaches are very
complimentary in nature. Passive probes are, by their vary nature,
non-intrusive; they add no additional load on the network or service.
Passive monitors can provide a more extensive measurement capability
(not only in the type of measurements but also in the amount of
samples collected). Passive monitors do not, however, control the
generation of data for the measurement samples. In contrast, active
monitors are intrusive; they add load to the network or service.
Because they control the generation of the probes, they also control
the volume of traffic they introduce. In general, it is not expected
that the objectives for generating active probes would necessitate
high volumes of traffic.
Combined, these attributes limit the volume of measurements collected
from active monitoring probes. However, this will allow for a richer
set of historical data to be maintained in the probe due to the
relatively low volume of measurement data (as compared, say, to an
RMON probe sitting on a highly utilized fast ethernet LAN segment).
Cole, et al. [Page 4]
Internet Draft draft-cole-appm-00.txt March 2000
In the next section we discuss issues of an architectural nature. We
follow this with a section on related work, both previous and
current, within various working groups at the IETF. Then, we present
thoughts on Configuration Issues and Implementation Issues. Finally,
because this area of work is not currently part of an existing
working group's charter, we end with a brief presentation of Next
Steps in order to move the discussion of these capabilities within
the IETF along.
4. Architectural Considerations
There are various architectural considerations when discussing active
probes within the context of the Internet and it's standards. These
include:
+ the target of the monitoring process, e.g., network transport
versus server or process,
+ the 'layer' at which the probe functions, e.g., transport probes
versus synthetic applications,
+ relationship between fault management and performance management
data,
+ configuration - how to setup the behavior of the probe through a
RW MIB table for configuring the probe,
+ communication channels to remote probes,
+ the deployment architecture and its relationship to other
monitoring methods, e.g., passive monitoring devices, and
+ security - related to probe control and generation.
We consider each of these issues in this section.
It is envisioned that specific probes/monitoring capabilities are to
be developed specific to the service being monitored. When the
target of the monitoring process is a transport service, then one
naturally thinks of delay probes, loss probes, throughput and jitter
probes, etc. When one thinks of database access services, one
naturally thinks of various types of application request probes. We
will talk of 'network' or 'transport' probes when monitoring
transport services. We will speak of 'process-level', 'application-
level or 'synthetic-application' probes when speaking of monitoring
applications or a combination of transport and application services
depending upon the location of the probes. It may even make sense to
define an intermediate probe type, e.g., and 'infrastructure' probe,
Cole, et al. [Page 5]
Internet Draft draft-cole-appm-00.txt March 2000
for the purpose of monitoring some common aspects of the service and
transport services.
Examples of 'transport-level' probes are delay, loss, delay
variation, jitter, and throughput probes. Examples of 'synthetic-
application' probes would be Oracle or SAP transaction probe or
HTTP_get request probes, etc. Examples of 'infrastructure-level'
probes might be DNS or DHCP probes, SIP probes for monitoring aspects
of call setup delays, etc.
Related to each defined transport or application service, we
introduce the concept of a monitoring service, characterized by type
of service, passive monitoring method (if relevant), active
monitoring method (if relevant), metrics, passive probe and active
probe. In this context, a passive probe is an implementation of a
passive monitoring method. An active probe is an implementation of an
active monitoring method. Such an approach is currently being
discussed within the context of a passive monitoring capability in
the RMON working group. See, for example, [14] and [16].
There are very few pieces of information that one might extract from
a resource that are only useful for just one purpose, e.g., fault or
performance monitoring. For most of the attributes available today,
the differences are in the use to which the information is put, not
the data itself. It is only after we have defined higher-level
objects (computed from existing ones) that we really have
"performance data" or "fault data". Thus it should be possible to
report basic fault information as well as gather performance
statistics. For instance, at a mininmum the detected operational
state should be reportable with a notification to indicate the
transitions.
Given a probe, a framework can be built that looks something like:
+-----------------+------------+
|performance app. | fault app. |
+-----------------+------------+
| monitoring software |
+------------------------------+
| central selection, |
| aggregation & stats. |
+------------------------------+
| remote selection, |
| aggregation & stats. |
+------------------------------+
| probe hardware |
+------------------------------+
Cole, et al. [Page 6]
Internet Draft draft-cole-appm-00.txt March 2000
In the context of performance, fault can be viewed as not performing
at all. They should both be monitorable with the same probes to
reduce network traffic.
Various deployment scenarios are feasible, depending upon the
functionality desired and the allocation of that functionality across
components. Clearly, active and passive probes can be implemented as
either stand-alone devices that sit on the wire, or they can be
implemented as embedded software within specific network elements or
clients or server applications. An architecture can be envisioned
which combines active and passive probes, where the active probe is
designed for the sole purpose of generating traffic at particular
time points and the sample collection and statistical computations
occur in already defined passive probes, e.g., RMON probes.
Other architectural options relate to a) the fundamental nature of
the active probe development and b) the communications with the
remote probes and between the remote probes. The active probes could
be developed along the lines of the DISMAN's pingMIB [3], i.e., it is
defined within the context of a MIB, directly accessable through SNMP
and resident on a remote device. It could, instead be developed
within the framework of the DISMAN's scriptMIB [4], where the active
probe is an application which is distributed to the remote monitoring
device and run on that remote device. Within this latter
architecture, access to the probe's configuration, etc., may be
through means other than SNMP and a MIB. Also, depending upon the
nature of the probes, some form of communication and control may be
necessary between the communicating probes themselves (in addition to
the probe packets).
With respect to security considerations, past discussions related to
active monitoring encountered a certain degree of pessimism, as did
many other SNMP applications that involved configuration operations.
However, the recent development of the SNMPv3 [references..] security
model, improved this situation, and we are witnessing the increased
acceptance of SNMP as a 'trusted' and 'secure' protocol. This
framework will analyze the issue of security and propose if necessary
extra measures for ensuring a safe and secure utilization of the
active monitoring capabilities.
Several security issues exists, including:
+ the security of the communication between a management
application and the remote, active probes (at a minimum snmpv3
authentication mechanisms should be consider for this aspect of
configuration.),
Cole, et al. [Page 7]
Internet Draft draft-cole-appm-00.txt March 2000
+ when the probes are probing things at application levels we need
to discuss the security of those applications. (For instance we
may need to use secure protocols.)
+ there is the potential that the probes for monitoring will be
perceived as secuirty violations (port scans)
+ the nature of the communications between the active probes
themselves,
+ spoofing results (potentially disrupting communications), and
+ using the probes in denial of service attacks.
{Comment: These and other security issues need to be further
developed. Also see the note in Section 10 below on 'Security
Considerations'.}
5. Relationship to Other Work
Much work has already occurred within the IETF which has a direct
bearing on the development of active performance probe
definitions. This body of work is addressed in various working
groups over the years. In this section we focus our attention to
the work of a) the IPPM working group, b) the DISMAN working
group, c) the RMON working group, d) the ApplMIB working group,
and e) the RTFM working group.
5.1 IPPM
The IPPM working group has defined in detail a set of performance
metrics, sampling techniques and associated statistics for
transport level measurements. The IPPM framework document [1]
discusses numerous issues around samplying techniques, clock
accuracy, resolution and skew, wire time versus host time, error
analysis, etc. Much of these are considerations for Configuration
and Implementation Issues discussed below. The IPPM working group
has defined several metrics and their associated statistics,
including
+ a connectivity metric [5]
+ one-way delay metric [6]
+ one-way loss metric [7]
+ round trip delay and loss metrics [8]
Cole, et al. [Page 8]
Internet Draft draft-cole-appm-00.txt March 2000
+ delay variation metric [9]
+ a streaming media metric [10]
+ a throughput metric [11] and [12], and
+ others are under development.
These (or a subset) could form the basis for a set of active,
transport-level, probe types designed for the purpose of monitor the
quality of transport services. A consideration of some of these
metrics may form a set of work activites in a new working group
developing active probe monitoring capabilities and a set of early
deliverables out of such a working group.
5.2 DISMAN
The DISMAN working group is defining a set of 'active' tools for
remote management. Of relevance to this draft are:
+ the pingMIB [3],
+ the DNS Lookup MIB [3],
+ the tracerouteMIB [3], and
+ the scriptsMIB [4].
The pingMIB and tracerouteMIB define an active probe capability,
primarily for the remote determination of path and path connectivity.
There are some performance related metrics collected from the pingMIB
and one could conceivably use these measurements for the evaluation
of a limited set of performance statistics. But there is a
fundamental difference in determining connectivity versus determining
the quality of that connectivity. The DNS Lookup MIB also includes
some probe-like capabilities and performance time measurements for
the DNS lookup.
In the context of performance monitoring, a fault can be viewed as
not performing at all. Therefore, tThey should both be monitorable
with the same probes to reduce network traffic. This was discussed
further in the Architecture section above.
Also mentioned in the Architecture section above, the scriptsMIB
allows a network management application to distribute and manage
scripts to remote devices. Conceivably, these scripts could be
designed to run a set of active probe monitors on remote devices.
Cole, et al. [Page 9]
Internet Draft draft-cole-appm-00.txt March 2000
One possible outcome we would like to consider is the extension of
the DISMAN work to monitoring of the quality of the connectivity.
5.3 RMON
The RMON working group has developed a extensive, passive monitoring
capability defined in [2], [13], ... Initially, the monitors
collected statistics at the MAC layer, but has now been extended to
high-layer statistics. Higher-layer statistics are identified
through the definition of a Protocol Directory [2]. The working
group is recently re-chartered and is now concentrating on, amoung
other items, passive monitoring at the application level.
{Comment: Is this statement true, that the RMON group is totally
under the passive approach category?}
The minutes of the Boston interim meeting in January 2000 are the
best source right now for information about what these activities in
the RMON WG [19]. A number of individual drafts exist which discuss
a number of interesting areas such as:
+ application typing and relevant metrics [14] and [15]
+ transaction level statistics collection and reporting [15] and
[16]
One possible outcome we would like to consider is the extension of
the RMON work as it relates to application monitoring. Further, RMON
MIB data can be correlated with active probes actions.
5.4 ApplMIB
The ApplMIB working group defined a series of MIBs which monitor
various aspects of applications, processes and services.
The system application MIB (RFC 2287 [20]) describes a basic set of
managed objects for fault, configuration and performance management
of applications from a systems perspective. More specifically, the
managed objects it defines are restricted to information that can be
determined from the system itself and which does not require special
instrumentation within the applications to make the information
available.
The Application MIB (RFC 2564 [17]) complements the System
Application MIB, providing for the management of applications' common
attributes which could not typically be observed without the
cooperation of the software being managed. There are attributes which
provide information to application and communication performance.
Cole, et al. [Page 10]
Internet Draft draft-cole-appm-00.txt March 2000
{Comment: Should we include a list of attributes?}
The WWW MIB (RFC 2594 [18]) describes a set of objects for managing
network management protocols in the Internet Community, particularly
World Wide Web (WWW) services. Performance attributes are available
for the infomration about each WWW service, each each type of
request, each type of response and top accessed documents.
{Comment: Should we include a list of attributes?}
In the development of synthetic application-level probes,
consideration should be given to the relationship of the application
MIBs to the measurements being performed through a synthetic
application-level probe. Similar, cross-indexing issues arise within
the context of the RMON monitoring and synthetic application-level
active probes.
5.5 RTFM
{Comment: This section is to discuss the relevant aspects of the RTFM
working group to this draft.}
6. Configuration Issues
It is primarily assumed within this memo that the configuration of
the probes is accessable through a MIB and communications to the
remote probe is via SNMP. Other options, exist; one such option was
briefly discussed above in the Architecture section.
The remainder of this section focuses on various configuration issues
surrounding the definition and development of an active probe
capability. Here we discuss a) sampling methodologies, b) useful
probe configuration options, c) statistics, reporting and historical
data, and d) correlation of results to other measurements.
6.1 Sampling
{Comment: This section should cover frequency, interpacket times
(deterministic, random), timeouts, number of packets sent, probe
lifetime, etc. This section should also include reasonable defaults
and recommended ranges for polling intervals and retries. For
instance it may be fine for ping to have a 1 second retry. But for
higher level applications we may not want to allow 1 second retries.
}
6.2 Probe Configurations
The configuration of the specific probes can be quite extensive,
Cole, et al. [Page 11]
Internet Draft draft-cole-appm-00.txt March 2000
given all of the potential options. The options would cover areas
such as:
+ static, read only information related to the implementation of
the active probes,
+ timing and frequency of the probe packets (see Sampling section
above),
+ data configuration (payload size, data fill, etc),
+ protocol options (could include multiple layers of protocol
processing),
+ path configuration options (source and destination addresses,
TOS field settings, do not fragment settings, ifNumber, TTL,
etc.), and
+ others?
6.3 Statistics, Reports and Historical Data
{Comments: This section should cover the statistics computed
locally, the nature of the reports generated, and the storage of
historical data. Reference [16] has a good discussion of a
general set of statistics to maintain in probes, the complexities
involved and the utility of the various statistics. Also, the
work of the IPPM working group and their specific documents
discusses or recommends statistics related to the metrics they
define. This should be covered in this section.}
6.4 Indexing to Other Measurements
There will potentially be a great deal of performance related
information collected across numerous MIBs. The definition of a
set of active probes only adds to this data. Methods are
available within subsets of this data to cross-correlate results
through standard indexing tables. Various MIBs from the Appl
working group, i.e., [17], [18], and [20], are related through a
service instance identifier. To quote [18], "The WWW Service MIB
interfaces to the Application MIB [17] by using the service
instance identifier {applSrvIndex} for wwwServiceIndex if an
applicable instance of applSrvIndex is available." The discussion
and early drafts from the RMON working group, i.e., [16] and [14],
discuss the relationship between the metrics of application-level
and transport-level measurements and their cross-indexing. To
quote [16], ....
Cole, et al. [Page 12]
Internet Draft draft-cole-appm-00.txt March 2000
{Comment: Get quote from [16].}
The definition of active probes and their related statistics
should be defined in such a way that useful cross-correlation of
results is possible.
This type of correlation is currently possible for certain
definitions of "service" in RFC 2564 [17]. For instance in
Section 6.1 or RFC 2594 [18] indicates that for long lived
services like http and smtp there would be instances in the
service-level tables. For finger there may not be an entry. From
here we can determine the reference points back to system
application MIB and deteremine all of the information about the
application.
Clearly, it would be desirable to be able to correlate, e.g., the
results of a synthetic application probe running on a remote
device into an application server with the measurements found
within the applMIB for that same application running on that
server. To take this example further, then to correlate the
applications-level probe's measurements to transport-level
measurments and even to the individual component level. This
would require the ability to relate the path of the probes to the
specific components, which may be complicated due to asymmetries
in routing, load balancing across paths and servers, etc.
7. Implementation Issues
Implementation of active probes and their corresponding
measurements is a tricky business, as discussed in detail in the
body of the IPPM WG documents, in particular references [1] and
[6]. In this section we reinforce some of the discussion in these
references in the area of measurement accuracy, etc.
Specifically, we discuss a) requirements on implementations, b)
error analysis statements, and c) compliance tests.
7.1 Requirements on Implementations
{Comment: This section should discuss potential requirements on
specific implementations. Areas to cover include clock
resolution, and skew, types of packet injection process supported,
requirements on the upper and lower bounds on packet generation
rates, etc.}
7.2 Error Analysis Statements
Performance measurements, whether they are based on active or
passive monitoring, are error prone. It may make sense to define
Cole, et al. [Page 13]
Internet Draft draft-cole-appm-00.txt March 2000
an error analysis statement/methodolgy so that implementations can
clearly define their source of errors and hence the accuracy of
their results. There is a fair amount of discussion within the
IPPM framework document surrounding this issue, which should be
drawn upon extensively.
7.3 Compliance Tests
{Comment: this section should cover identifying supported probe
types, test to determine the accuracy of the specific
implementations, etc.}
8. Next Steps
There are several steps to move this work forward. A BOF is being
held in Adelaide to discuss this area of work as a potential basis
for a working group at the IETF. Here we throw out some thoughts
on moving this work forward. This includes a proposed set of
possible deliverables for the working group.
+ The first step is to have the BOF and see what momentum is
gained from it. At that point it will likely be more clear what
the next steps should be, where the work will be done within the
IETF and so forth.
If the decision is to move forward, we suspect several documents
may be reasonable. For example, we suggest:
+ Develop a framework/architecture document defining the
architecture of an active performance monitoring capability, its
tradeoffs relative to other potential architecures, and its
relationship to other, already defined monitoring capabilities.
+ (possibly) Develop a seperate security document,
+ Develop a MIB for active probes and another for a usage of that
MIB for some specific network or application layer. To accomplish
the later, then
+ Define a set of transport level metrics, drawing from the work
of the IPPM working group for the purpose of defining assocaited
active, transport-level probes.
+ Develop a set of related transport level performance probes.
These may require a document defining the metrics and a common
structure for the transport level probes, with a method for
extending this to include other transport level probes (as alluded
to in the above bullet). Then the seperate transport-level probes
Cole, et al. [Page 14]
Internet Draft draft-cole-appm-00.txt March 2000
may be seperately defined.
+ If interest merits it, there may be a set documents surrounding
the definition of synthetic application-level probes.
9. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
10. Security Considerations
{Comment: This needs a very close examination, probably more than
usual. Some security issues are briefly mentioned in the
Architecture section above, but the issue of security was one of the
reasons for this work being deferred in the past. We may want to
create a special document or a special section in this document that
deals with the issue.}
11. Acknowledgements
to be supplied.
12. References:
[1] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998.
[2] Waldbusser, S., "Remote Network Monitoring Management Information
Base Version 2 using SMIv2", RFC 2021, January 1997.
Cole, et al. [Page 15]
Internet Draft draft-cole-appm-00.txt March 2000
[3] White, K., "Definitions of Managed Objects for Remote Ping,
Traceroute, and Lookup Operations", Internet Draft, <draft-ieft-
disman-reops-mib-07.txt>, August 1999.
[4] Levi, D. and J. Schoenwaelder, "DDDefinitions of Managed Objects
for the Delegation of Management Scripts", RFC 2592, May 1999.
[5] IPPM connectivity metric (?)
[6] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999.
[7] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-Way Packet Loss
Metric for IPPM", Internet Draft, <draft-ietf-ippm-loss-07.txt>, May
1999.
[8] Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-Trip Delay
Metric for IPPM", RFC 2681, September 1999.
[9] Chimento, P., "Instantaneous PPPacket Delay Variation Metric for
IPPM", Internet Draft, <draft-ietf-ippm-ipdv-04.txt., October 1999.
[10] Raisanen, V. and G. Grotefeld, "Network Performance Measurement
for Periodic Streams", Internet Draft, <draft-ietf-ippm-
npmps-00.txt>, March 2000.
[11] Mathis, M. and M. Allman, "Empirical Bulk Transfer Capacity",
Internet Draft, <draft-ietf-ippm-btc-framework-02.txt>, Octobet 1999.
[12] Mathis, M., "TReno Bulk transfer Capacity", Internet Draft,
<draft-ietf-ippm-treno-btc-03.txt>, February 1999.
[13] Waldbusser, S., "Remote Network Monitoring Management
Information Base", RFC 1757, February 1995.
[14] Waldbusser, S., "Application performance measurement MIB",
<draft-waldbusser-apm-mib-00.txt>, March 2000.
[15] Warth, A. and J. McQuaid, "Application Response Time (ART) MIB",
Internet Draft, <draft-warth-art-mib-01.txt>, October 1999.
[16] Dietz, R. "Transport Performance Metrics MIB", Internet Draft,
<draft-dietz-tpm-mib-00.txt>, March 2000.
[17] Kalbfleisch, C., Krupczak, C., Presuhn, R. and J. Saperia,
"Application Management MIB", RFC 2564, May 1999.
[18] Hazewinkel, H., Kalbfleisch, C., and J. Schoenwaelder,
Cole, et al. [Page 16]
Internet Draft draft-cole-appm-00.txt March 2000
"Definitions of Managed Objects for WWW Services", RFC 2594, May
1999.
[19] Meeting minutes from the interim meeting of the RMON working
group on January 11 and 12, 2000 in Boston, MA.
[20] Krupczak, C. and J. Saperia, "Definitions of System-Level
Managed Objects for Applications", RFC 2287, February 1998.
13. Author Information
Robert G. Cole
AT&T Laboratories
Network Design and Performance Analysis Department
330 Saint John Street, 2nd Floor
Havre de Grace, MD 21078
Phone: +1 410-939-8732
Fax: +1 410-939-8732
Email: rgcole@att.com
Carl W. Kalbfleisch
Verio, Inc.
1950 Stemmons Freeway
Suite 2026
Dallas, TX 75207
Phone: + 1 214-853-7339
Fax: +1 214-744-0742
Email: cwk@verio.net
Dan Romascanu
Lucent Technologies
Atidim Technology Park, bldg. #3
Tel Aviv, 61131
Israel
Phone: +972-3-645-8414
Fax: +972-3-648-7146
Email: dromasca@lucent.com
A. Full Copyright Statement
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
Cole, et al. [Page 17]
Internet Draft draft-cole-appm-00.txt March 2000
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.
Cole, et al. [Page 18]