Internet Draft Anwar Siddiqui
Avaya Inc.
Dan Romascanu
Avaya Inc.
Eugene Golovinsky
BMC Software
3 March 2003
Real-time Application Quality of Service
Monitoring (RAQMON) Framework
<draft-ietf-rmonmib-raqmon-framework-01.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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
There is a need to extend the RMON framework [RFC2819] to monitor end
devices such as IP Phones, Pagers, Instant Message Clients, Mobile
Phones, and various other Hand held computing devices. This memo
proposes an extension of RMON Framework to allow Real-time QoS
Monitoring of various Applications that runs on these types of end
devices and allows such information be integrated with RMON Framework
via SNMP.
Distribution of this memo is unlimited.
Table of Contents
RMON WG Expires September 2003 [Page 1]
INTERNET DRAFT RAQMON Framework March 2003
Status of this Memo 1
Abstract 1
1 Introduction 2
2 RAQMON Functional Architecture 3
3 A Simple list of Metrics pre-defined in BASIC PDU 9
4 Overview of RAQMON Framework 18
5 Normative References 22
6 Informative References 22
7 Intellectual Property 24
8 Security Considerations 24
9 IANA Considerations 25
10 Authors' Addresses 26
A Full Copyright Statement 26
1. Introduction
There is a need to extend the RMON framework [RFC2819] to monitor end
devices such as IP Phones, Pagers, Instant Message Clients, Mobile
Phones, and various other Hand held computing devices. This memo
proposes an extension of RMON Framework to allow Real-time QoS
Monitoring of various Applications that runs on these types of end
devices and allows such information be integrated with RMON Framework
via SNMP.
An end-to-end user experience of the quality of service (QoS) of such
applications is a combination of types of applications level
transactions, network resources and host performance. And at any
given point, it's the applications at these devices that can
correlate such data and report actual statistics to reflect end-to-
end view. Real-Time Application QOS Monitoring (RAQMON) Framework
provides an option to theses applications and end devices to report
specific parameters, appropriate for an application context. An
application running on a specific end device reports a selected set
of metrics derived from the monitoring of network packets, local host
performance and application level transactions.
In particular, Real-time Application QoS Monitoring (RAQMON)
Framework allows:
a. A set of Protocol Data Unit (PDU) with selectable QOS performance
metrics to be sent by the "applications" running on the end devices.
The metrics are defined through reference to existing IETF, ITU and
other standards organizations' documents. These PDUs are transmitted
over Real Time Control Protocol (RTCP) or Simple Network Management
Control Protocol (SNMP) to ensure reuse of existing internet
standards.
RMON WG Expires September 2003 [Page 2]
INTERNET DRAFT RAQMON Framework March 2003
b. A capability to accommodate new parameters not included in the
initial list, as Type Length Value(TLV) to be defined by the
Application Developers within RAQMON Framework.
c. A portion of the Management Information Base (MIB) as an extension
of RMON MIB Modules for use with network management protocols in the
Internet community.
This memo provides definition of RAQMON entities, a functional
architecture and behavior of various components. Further details
around RAQMON specification is published in RAQMON QOS PDU [darft-
ietf-rmonmib-raqmon-pdu-xx.txt] and RAQMON MIB [darft-ietf-rmonmib-
raqmon-mib-xx.txt] drafts.
RAQMON QOS PDU [darft-ietf-rmonmib-raqmon-pdu-xx.txt] draft describes
how various protocol PDUs can be transported over existing
Application level transport protocol like the Real Time Communication
protocol (RTCP) and Simple Network Management Protocol (SNMP) to
transport various Protocol Data Units.
RAQMON MIB [darft-ietf-rmonmib-raqmon-mib-xx.txt] draft defined the
Management Information Base (MIB) for use with network management
protocols in the Internet community. The document proposes an
extension to the Remote Monitoring MIB [RFC2819] to accommodate
RAQMON solution.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. RAQMON Functional Architecture
This document continues the architecture created in the RMON MIB
[RFC2819] by providing analysis of application performance as
experienced by end-users on a specific end point and correlating such
performance to its underlying transport network characteristics,
applications level transactions and host performance. RAQMON
framework is based on three functional components named below.
- RAQMON Data Source (RDS)
- RAQMON Report Collector (RRC)
- RAQMON MIB Structure
A RAQMON Data Source (RDS) is a functional component that acts as a
source of data for monitoring purposes. End devices like IP Phones,
cell Phones, pagers etc. and application clients like Instant Message
RMON WG Expires September 2003 [Page 3]
INTERNET DRAFT RAQMON Framework March 2003
Clients, Soft phones in PC is envisioned to act as an RDS within
RAQMON Framework.
A RAQMON Report Collector (RRC) receives statistics from multiple
RDSs, analyzes it, and stores such information appropriately. A
RAQMON Report Collector (RRC) is envisioned to be a network server
serving an administrative domain defined by the network
administrator.
RAQMON Management Information Base (RAQMON MIB) extends Remote
Monitoring MIB [RFC2819] to accommodate RAQMON Framework.
+----------------------+ +---------------------------+
| IP End Device | | IP End Device >----+ |
|+--------------------+| |+--------------------+ | |
|| APPLICATION || || APPLICATION | | |
|| -Voice over IP <----(1)----> -Voice over IP >- + | |
|| -Instant Messaging|| || -Instant Messaging| | 3 |
|| -Email || || -Email | 2 | |
|+--------------------+| |+--------------------+ | | |
| | | | | |
| | | +------------------+ | | |
+----------------------+ | |RAQMON Data Source|<-+ | |
| | (RDS) |<---+ |
| +------------------+ |
+-----------|---------------+
|
(4) RAQMON PDU transported
over RTCP APP Packet or SNMP INFORM
|
+----------------------------+
| |
|/ |/
+------------------+ +------------------+ +-------------+
|RAQMON Report | .. |RAQMON Report | |Network Alarm|
|Collector (RRC) #n| |Collector (RRC) #1|<--5-->| Manager |
+------------------+ +------------------+ +-------------+
Figure 1 - RAQMON Framework.
(1) Communication Session between applications
(2) Context-Sensitive Metrics
(3) Device State Specific Metrics
RMON WG Expires September 2003 [Page 4]
INTERNET DRAFT RAQMON Framework March 2003
(4) RAQMON metrics transmitted over specified interface (Specific
Protocol Interface, IP Address, port)
(5) RAQMON MIB sent within SNMP notifications.
2.1 RAQMON Data Source (RDS)
RAQMON Data Source is a source of data for monitoring purposes. A RDS
is primarily responsible for abstracting IP end-devices and
applications for the purpose of monitoring with RAQMON Architecture.
It gathers the parameters defined in table 1 for a particular
communication session, and forwards them to the RRC. Since it is
envisioned that the RDS functionality will be realized by writing
firmware/software running on potentially small, low powered end
device, the design of RDS specification and the protocol data units
sent from RDS is optimized towards that.
2.1.1 Configuring RAQMON Data Source
In order to report statistics to RAQMON report collector, RDSs will
need to be configured with some of the following parameters:
1. The time interval between RAQMON PDUs
2. The RRC IP address and port (i.e. Ports are IANA Registered and
could different based on protocol chosen to transport PDU)
3. The encryption/authentication scheme required and its parameters
(if used).
A RDS can use one or more of the following mechanisms to gain access
to configuration parameters:
- RDS acts as a tftp client and download text scripts to read the
parameters - RDS acts as a DHCP Client and get RRC address
information via DHCP options - RDS acts as a DNS client and get DNS
records - RDS acts as a LDAP Client and use directory look-ups - RDS
manually configured using command line interface (CLI), Telephone
User Interface (TUI)
Compliance to RAQMON specification does not require usage of any
specific mechanisms mentioned above. Administration and provisioning
RDSs is beyond the scope of this memo and left upon the implementers
to choose appropriate provisioning mechanisms for a system.
2.2 RAQMON Report Collector (RRC)
A RAQMON Report Collector (RRC) receives RAQMON statistics from
RMON WG Expires September 2003 [Page 5]
INTERNET DRAFT RAQMON Framework March 2003
multiple RDSs, analyzes it, and stores it in RAQMON MIB. The RRC is
envisioned to be computationally resourceful, providing a storage and
aggregation point for a set of RDSs.
RAQMON Framework allows multiple RDSs engaged in a communication
session with each other to report statistics to multiple different
RRCs as the RDSs may belong to different administrative domain. To
accommodate such scenarios, its beyond the scope of RRC functional
specification to establish relationship between multiple
communicating RDSs and a management application can be written to
correlate information residing in multiple administrative domain.
2.3 RAQMON Protocol Data Unit (PDU)
RAQMON Protocol Data Unit (PDU) provides a generic structure
exchanged between the RDS and RRC to report application and device
level statistics. RAQMON Framework uses a PUSH mechanism from RDSs to
RRC to gather application and device level statistics.
There are 2 types of PDUs within the RAQMON Framework:
BASIC PDU: A BASIC PDU provides mechanisms to report some frequently
used parameters from a pre listed parameter suit defined in table 1.
Application developers have the flexibility to make an RDS report a
sub-set of these pre-set parameters to RRC appropriate for an
application context. For example, An IP Phone developer might want to
use RAQMON BASIC PDU to report End-to-End Delay, Jitter, packet loss
etc while the Instant Message client can use the same BASIC PDU to
report only Packet Loss and End-to-End Delay.
APP PDU: Since is difficult to design a BASIC PDU that meets the
needs of all applications, RAQMON provides APP PDUs for further
extension required to convey application, vendor, device etc.
specific parameters for future usage. Additional parameters can be
defined within payload of the APP PDU as Type length Value (TLV)
pairs and defined by the application developers or vendors.
RAQMON PDUs, provides RDSs the flexibility to decide the parameters,
an end device/application is willing to report. RAQMON PDUs also
provide the RRCs the flexibility to store the parameters an
administrative domain feel important for a domain.
The memo [darft-ietf-rmonmib-raqmon-pdu-xx.txt] contains detailed
RAQMON PDU specifications.
2.4 RDS/RRC Network Transport Protocol interface
In order to re-use existing internet protocol, RAQMON PDUs will
RMON WG Expires September 2003 [Page 6]
INTERNET DRAFT RAQMON Framework March 2003
either use RTCP or SNMP to transport the RAQMON PDUs. Transport
protocol used to carry RAQMON PDUs would have affects on the
reliability of PDUs. This section describes requirements to carrying
RAQMON PDUs within a particular network an associated choice of
protocol.
RAQMON PDUs relies on the underlying protocol(s) to provide a length
indication. The maximum length of the RAQMON data packet is limited
only by the underlying protocols.
The memo [darft-ietf-rmonmib-raqmon-pdu-xx.txt] defines the RAQMON
QOS PDU and describes how PDUs are transported over existing
Application level transport protocol like Real Time Communication
protocol (RTCP) and Simple Network Management Protocol (SNMP).
Carrying RAQMON PDUs over RTCP and SNMP being as underlying transport
protocols has following advantages:
1. Lightweight - RDSs will be implemented on low powered embedded
devices with limited device resources such as IP Phones, Hand held
computing devices, cellular phones, pagers etc.
2. Scalable - Since RRCs need to interact with very large number of
RDSs, it is a requirement that the protocol be scalable.
3. Security - Since RAQMON statistics may contain sensitive system
information it is imperative that the protocol provides a strong
security solution and re-using RTCP and SNMP achieves that.
4. It is recommended that no more than 10% network bandwidth in a
system be used for RDS/RRC reporting. More frequent reports from an
RDS to RRC would imply requirements for higher network bandwidth
usage.
5. NAT Friendly - Comply with [RFC3235], so that an RDS could
communicate with an RRC through a Firewall/Network Address
Translation device.
6. RAQMON PDUs may be lossy, as RAQMON deals with getting statistics
rather than billing type critical functionalities. However RAQMON
PDUs with appropriate network transport protocol like TCP would
guarantee reliability of the RAQMON PDU transport.
In Future, if RAQMON PDUs are to be carried in an underlying protocol
that provides the abstraction of a continuous octet stream rather
than messages (packets), an encapsulation of the RAQAMON packets must
be defined to provide a framing mechanism. Framing is also needed if
the underlying protocol may contain padding so that the extent of the
RMON WG Expires September 2003 [Page 7]
INTERNET DRAFT RAQMON Framework March 2003
RAQMON payload cannot be determined. The framing mechanism is not
defined in this document. Carrying several RAQMON packets in one
network or transport packet reduces header overhead.
2.5 Mapping RAQMON PDUs in existing Transport Protocol
Though, RAQMON PDUs can be transported over RTCP as well as SNMP, it
is not mandatory for either RDS or RRC to implement both transport
protocols interfaces. However since RRCs are computationally
resourceful, it is recommended that RRCs support both RTCP and SNMP
interface to accommodate RDSs with one protocol interface.
Usage of RTCP (Section 2.5.1) and SNMP Inform (Section 2.5.2) to
carry RAQMON PDUs is described in the following sub-sections.
2.5.1 Usage of RTCP to carry RAQMON PDUs
RAQMON Framework is comprised of unidirectional exchange of PDUs
between RDSs and an RRC. The protocol data units are mapped to a
connectionless datagram service (UDP).
To accommodate RTCP as the RAQMON PDU Transport, RRC-RTCP interface
need to recognize 2 simple types of RAQMPON PDUs(i.e. like RTCP APP
reports) namely BASIC PDU and APP PDU as described above.
+ During a monitored communication session, the RDSs will send a
RAQMON PDU to a target RRC with the QOS metrics appropriate for a
specific application context. RDS embeds RAQMON PDUs as a payload to
RTCP APP Packet [RFC 1889].
+ Since the PDUs carry "complete" set of information, the reporting
session between RDS and RRC is stateless.
RAQMON PDU transport over RTCP is a simple one-way send protocol. The
RDSs will not be capable of inferring successful delivery PDUs over a
lossy network
RRCs could use specific fields of each RAQMON PDUs along with unique
parameters like 6 Octet MAC address, IP Address, Application name,
address to correlate a received RAQMON PDU to an ongoing session.
2.5.2 SNMP INFORM PDUs as RDS/RRC Network Transport Protocol
SNMP INFORM PDU are re-used to transport RAQMON PDUs with following
+ RDSs embeds RAQMON PDU in SNMP INFORM to report RAQMON statistics.
RMON WG Expires September 2003 [Page 8]
INTERNET DRAFT RAQMON Framework March 2003
+ To keep the RDS realization simple and keep the protocol
lightweight, the RDSs will not be REQUIRED to respond to SNMP
requests like get, set, etc., as an SNMP compliant responder would.
+ If the RRC chooses to implement an SNMP manager, an SNMP INFORM
Response could be sent for each associated SNMP INFORM originated by
the RDS.
+ The RDS may ignore the SNMP INFORM Responses, or, if better
reliability is required, will wait for the Inform response,
retransmitting the original Inform PDU every M seconds until it has
been sent N times.
+ The SNMP INFORM transport for RAQMON PDUs can use one of the two
UDP ports assignments:
- Standard UDP port 162 used for SNMP Notifications, if full SNMP
entities implementations are present in the RRC and RDS
- IANA assigned UDP port 5YYYY for RAQMON PDUs carried over SNMP, for
the cases when at least one of the RRC and RDS does not support a
full implementation of the SNMP entities.
The benefits of using SNMP Informs are: - Using a well-known
protocol. - Privacy and authentication are covered by SNMPv3 -
Limited or no need for specific RAQMON-protocol code in the RRC, as
it can use an SNMP manager implementation to process Informs.
The drawback of this approach is the overhead SNMP puts on low-
powered RDSs, for instance - BER encoding.
3. A Simple list of Metrics pre-defined in BASIC PDU
RAQMON BASIC PDUs provide a set of pre-defined list of parameters
frequently used by the application developers. It is an extremely
challenging task to define "appropriate metrics" to be presented in a
BASIC PDU as metrics are context-sensitive. However one can also
notice enough commonalities between the various QOS parameters
associated to various applications such that the task of defining a
"simple metrics" is feasible. This memo defines a simple metric to be
contained in BASIC PDU that in essence captures the performance and
associated quality-of-service parameters of a communication session.
Within RAQMON Framework one could use APP PDUs to add parameters not
covered in the BASIC PDU for extensions to this list. RAQMON
framework also provides a mechanism to add and drop various
RMON WG Expires September 2003 [Page 9]
INTERNET DRAFT RAQMON Framework March 2003
parameters to this metrics as defined in Table 1 below to accommodate
application context sensitivity:
1. Data Source Name (DN)
2. Receiver Name (RN)
3. Data Source Address (DA)
4. Receiver Address (RA)
5. Data Source Device Port used
6. Receiver Device Port used
7. Session Setup Date/Time
8. Session Setup delay
9. Session duration
10. Session Setup Status
11. Round Trip End-to-End Delay
12. One Way End-to-End Delay
13. Inter Arrival Jitter
14. Total number of Packets Received
15. Total number of Packets Sent
16. Total number of Octets Received
17. Total number of Octets Sent
18. Cumulative Packet Loss
19. Packet Loss in Fraction
20. Source Payload Type
21. Receiver Payload Type
22. Source Layer 2 Priority
23. Destination Layer 2 Priority
RMON WG Expires September 2003 [Page 10]
INTERNET DRAFT RAQMON Framework March 2003
24. Source Layer 3 Priority
25. Destination Layer 3 Priority
26. CPU utilization in Fraction
27. Memory utilization in Fraction
28. Application Name/version
Table 1: RAQMON Metrics Definition
Various parameters listed in table 1 are defined below. The
definition presented here is meant to provide guidance to
implementers. No claim is made that the definitions presented here
are appropriate for a particular application need.
Data Source Name (DN): The DN item could be of various formats as
needed by the application. Few instances of DN could be but not
restricting to
* "user@host", or "host" if a user name is not available as on
single-user systems. For both formats, "host" is either the fully
qualified domain name of the host from which the payload originates,
formatted according to the rules specified in [RFC1034], [RFC1035]
and Section 2.1 of [RFC1123]; The DN value is expected to remain
constant for the duration of a session. Examples are "big-guy@ip-
phone.bigcompany.com" or "big-guy@135.8.45.178" for a multi-user
system. On a system with no user name, examples would be "ip-
phone4630.bigcompany.com". It is recommended that the standard host's
numeric address not be reported via DN parameter as Data Source
Address (DA) parameter is used for that purpose.
* Another instance of a DN could a valid E.164 phone number, a SIP
URI or any other form of telephone or pager numbers. It is
recommended that the phone number should be formatted with the plus
sign replacing the international access code. For example, "+88 02
123 45678" for a number in Bangladesh.
It is expected that a Data Source Name (DN) will remain constant
within a communication session.
Receiver Name (RN): Same as Data Source Name (DN).
Data Source Address (DA): Data Source Address (DA) parameter should
be represented as the standard ASCII representation of the host's
numeric address. This could be an IPv4 Address, IPv6 Address, network
RMON WG Expires September 2003 [Page 11]
INTERNET DRAFT RAQMON Framework March 2003
address assignments such as the Net-10 assignment proposed in
[RFC1597] or any other form of numeric address represented in ASCII.
It is expected that a Data Source Name (DN) would remain constant
within a communication session.
DN and DA are intended to give the application writers an opportunity
to uniquely identify a record associated to a session. However
application writers should be aware that private network address
assignments such as the Net-10 assignment may create network
addresses that are not globally unique. To handle this case, the
burden is on the application either by converting private addresses
to public addresses if necessary to keep private addresses from being
exposed or by creating an application specific extension.
Receiver Address (RA): Same as Data Source Address
Data Source Device Ports used: This parameter is used to indicate the
port used for a particular session or sub-session used for
communication. Example of port includes TCP Port, UDP Port, RTP Port
etc. It is not expected that a Data Source Device Ports would remain
constant within a communication session.
Receiver Device Ports used: Same as Data Source Device Ports used.
Session Setup Date/Time Indicates the wallclock time when the RAQMON
packet was sent so that it may be used by the RRC to store Date/Time.
Wallclock time (absolute time) is represented using the timestamp
format of the Network Time Protocol (NTP), which is in seconds
relative to 0h UTC on 1 January 1900 [RFC1305].
Session Setup delay: Session setup delay indicates the duration of
time required by a network communication controller to set a media
path between the communicating entities or the end devices. For
example in VoIP systems a session setup time can be measured as the
last DTMF button pushed to the first ring back tone that indicates
that the far end is ringing. However as these definitions are very
specific to the type of system used and implementation details of
such system, no claim is made about the definition presented here are
appropriate for a particular application need and left upon the
implementers to define.
Session duration: This parameter describes how long a session or a
sub-session lasted.
Session Setup Status: This parameter is intended to report status of
a session in order to support applications those need to display
status in realtime. For example a debugging tool that captures the
RMON WG Expires September 2003 [Page 12]
INTERNET DRAFT RAQMON Framework March 2003
status of a call setup as soon as a call is established or a tool
that captures why a session failed or how many RSVP sessions failed
etc.
Round Trip End-to-End Delay: Round Trip End-to-End delay is a key
parameter for Application QOS Monitoring. Some applications do not
perform well (or at all) if end-to-end delay between hosts is large
relative to some threshold value. Erratic variation in delay makes it
difficult (or impossible) to support many real-time applications like
Voice over IP, Video over IP, Fax over IP etc.
RAQMON Framework should allow an application to report either Round
Trip Delay or One Way Delay. There are many measurement methodologies
available to fill this parameter but this parameter is intended to
capture the End-to-End delay as observed by the IP devices at the
application layer pertaining to a specific operation environment.
While appropriate, it is recommended that specific application layer
delays like play out delay, packet sequencing delays, coding,
decoding delays be added to transport network delay to report End-to-
End delay under RAQMON BASIC PDU.
End-to-End delay of underlying transport network can be measured
using various methodologies as described in [RFC2681], [RFC2679],
[RFC1889] depending on the application needs and left upon the
implementers to select appropriate IETF and ITU methodologies to
measure End-to-End Delays appropriate for a specific application.
One Way End-to-End Delay: Same as Round Trip End-to-End Delay.
Inter-arrival Jitter: Inter-arrival jitter field provides a short-
term measure of congestion. The definition of Jitter is context
sensitive and measurement specific. Measurement of inter-arrival
Jitter is beyond the scope of this document. The jitter measure
indicates congestion before it leads to packet loss. Inter-arrival
jitter of underlying transport network can be measured using various
methodologies and left upon the implementers based on there
application need. VoIP Systems can readily acquire Inter-arrival
Jitter calculations from RTCP measurements as described in [RFC1889].
Total number of Packets Received: The total number of packets
received by the data source since starting transmission up until the
time this RAQMON packet was generated.
Total number of Packets Sent: Similar to total number of packets
received.
Total number of Octets Received: The total number of payload octets
received in packets by the sender since starting transmission up
RMON WG Expires September 2003 [Page 13]
INTERNET DRAFT RAQMON Framework March 2003
until the time this RAQMON packet was generated.
Total number of Octets Sent: Similar to total number of octets
received.
Cumulative Packet Loss: Packet loss tracks persistent congestion
while the jitter measure tracks transient congestion. Since the
interarrival jitter field is only a snapshot of the jitter at the
time of a report, packet loss indicates the network environment as
well as local device losses over time. Packet loss of underlying
transport network can be measured using various methodologies e.g. as
described in [RFC2680], [RFC1889] and local device level packet
losses ought to be captured by the local device specific algorithms.
Measurement methodologies are left upon the implementers based on
their application need.
Packet loss in Fraction: Same as Packets loss but expressed in
percentage
Source Payload Type: Defines payload formats (e.g. media encodings)
as sent by the data source. e.g. ITU G.711-(law, ITU G.729B, H.263,
MPEG-2, ASCII etc. This document follows the same payload type
constants as defined in [RFC1890].
Destination Payload Type: Similar to Source Payload Type.
Source Layer 2 Priority: Many devices use Layer 2 technologies to
prioritize certain type of traffic in the Local Area Network
environment. For example the 1998 Edition of IEEE 802.1D [IEEE802.1D]
"Media Access Control" Bridges contains expedited traffic
capabilities to support transmission of time critical information and
many devices use the standard to mark Ethernet frames according to
IEEE 802.1p standard. Details on these can be found in IEEE 802.1Q
"Virtual Bridged LAN" specifications. 802.1p has been Incorporated
into ISO/IEC 15802-3 1998 [IEEE802.1Q]. Source Layer 2 RAQMON field
indicates Layer 2 values used by the Data Source to prioritize these
packets in the Local Area Networks environment.
Source Layer 3 Priority: Various Layer 3 technologies are in place to
prioritize certain type of traffic in the internet. For example
traditional IP Precedence [RFC791], Type Of Service (TOS)
[RFC1349],[RFC1812] or more recent technologies like Differentiated
Service [RFC2474][RFC2475] is achieved by using the TOS octet in IPv4
and the Traffic class Octet in IPv6 are used to prioritize traffic.
Source Layer 3 RAQMON field indicates appropriate Layer 3 values used
by the Data Source to prioritize these packets.
Destination Layer 2 Priority: Same as Source Layer 2 Priority.
RMON WG Expires September 2003 [Page 14]
INTERNET DRAFT RAQMON Framework March 2003
Destination Layer 3 Priority: Same as Source Layer 3 Priority.
CPU utilization in Fraction: This parameter captures the IP Device
CPU usage rate to indicate current state of the local IP Device
resource which has a very critical implications on QOS implications
of an end device. e.g. x % CPU busy averaged over session duration.
Memory utilization in Fraction: This parameter captures the IP Device
Memory usage rate to indicate current state of the local IP Device
resource which has a very critical implications on QOS implications
of an end device. e.g. y % memory utilized over session duration.
Application Name/version Application Name/version parameter gives the
name and possibly version of the application associated to that
session or sub-session, e.g., "XYZ VoIP Agent 1.2". This information
may be useful for scenarios where end device is running multiple
applications with various priorities and could be very handy for
debugging purposes.
3.1 Measurement Methodology
It is not the intent of this document to recommend a methodology to
measure any of the QOS parameters defined in table 1. Measurement
algorithms are left upon the implementers and equipment vendors to
choose. There are many different measurement methodologies available
for measuring application performance (e.g., probe-based, client-
based, synthetic-transaction, etc.). This specification does not
mandate a particular methodology - it is open to any that meet the
minimum requirements. Conformance to this specification requires that
the collected data match the semantics described herein.
3.2 Report Aggregation and Statistical Data processing
The RAQMON MIB is designed to provide minimal aggregations of various
RAQMON Parameters defined in table 1. RAQMON MIB is designed to not
to provide extensive aggregations like APM MIB [29] or TPM MIB [30]
and one should use APM and TPM MIBs to aggregate based on protocols
(e.g. Performance of HTTP, RTP) or based on application (e.g.
Performance of VoIP, Video Applications).
In RAQMON Framework, RDSs are not burdened by statistical data
processing as RDSs may be co-resident in end-devices and could be
resource constrained. Various aggregations are performed by the RRC.
Aggregation of RAQMON parameters collected over a period of time is
dependent on aggregation algorithms. In the RAQMON MIB, aggregation
can be performed only on specific RAQMON metrics parameters specified
below:
RMON WG Expires September 2003 [Page 15]
INTERNET DRAFT RAQMON Framework March 2003
Round Trip End-to-End Delay
One Way End-to-End Delay
Inter Arrival Jitter
Cumulative Packet Loss
Packet Loss in Fraction
CPU utilization in Fraction
Memory utilization in Fraction
The aggregation always results in the following statistics:
Mean Round Trip End-to-End Delay
Min Round Trip End-to-End Delay
Max Round Trip End-to-End Delay
Mean One Way End-to-End Delay
Min One Way End-to-End Delay
Max One Way End-to-End Delay
Mean Inter Arrival Jitter
Min Inter Arrival Jitter
Max Inter Arrival Jitter
Mean Cumulative Packet Loss
Min Cumulative Packet Loss
Max Cumulative Packet Loss
Mean Packet Loss in Fraction
Min Packet Loss in Fraction
Max Packet Loss in Fraction
Mean CPU utilization in Fraction
RMON WG Expires September 2003 [Page 16]
INTERNET DRAFT RAQMON Framework March 2003
Min CPU utilization in Fraction
Max CPU utilization in Fraction
Mean Memory utilization in Fraction
Min Memory utilization in Fraction
Max Memory utilization in Fraction
For this document following aggregation definitions are used:
Mean:
Mean is defined as the statistical average of a metric over the
duration of a communication session. For example if End-to-End delay
metric of an end device within a communication session is reported N
times by the RDS, then the Mean End-to-End Delay is the average End-
to-End Delay metric over N entries.
Min:
Min is defined as the statistical minimum of a metric over the
duration of a communication session. For example if End-to-End delay
metric of an end device within a communication session is reported N
times by the RDS, then the Min End-to-End Delay is the minimum of all
N End-to-End Delay metric entries in the table.
Max:
Max is defined as the statistical maximum of a metric over the
duration of a communication session. For example if End-to-End delay
metric of an end device within a communication session is reported N
times by the RDS, then the Max End-to-End Delay is the maximum of all
N End-to-End Delay metric entries in the table.
3.3 Keeping Historical Data and Storage
It is evident from the document that, RAQMON MIB data need to be
managed to optimize storage space. Enormous volume of data gathered
in a communication session could be optimized for storage space by
performing and storing only aggregated RAQMON metrics for history if
required.
Such storage space optimization can be performed in following ways:
1. Store data in the MIB only at the end of a communication session
RMON WG Expires September 2003 [Page 17]
INTERNET DRAFT RAQMON Framework March 2003
(i.e. after receiving an END packet), the aggregated data could be
stored in RAQMON MIB as Mean, Max or Min entry and saved for
historical purposes. This will minimize storage space requirement,
as instead of a column in a table, only few scalars will be used to
store a metric.
2. A time based algorithms that aggregate data over a specific period
of time within a communication session (i.e. thus requiring less
entries) also reduces storage space requirements. For example, if RDS
sends data out every 10 seconds and RRC writes to the RAQMON MIB once
every minute, for every 6 data points there will be one MIB entry.
3. Clearing up historical data periodically over a calendar time
using administration policy can perform further storage space
optimization. For example, an administrator could create a policy
such that all historical data get cleared up every 60 days. Such
policies are interpreted by the application, not by the RRC and usage
of these policies left at the application developer's discretion.
4. Overview of RAQMON Framework
RAQMON is a framework that extends RMON within which various end
devices and applications can be monitored and appropriate management
applications could take advantage of such information to perform
network management and administrative operations. In summary, RAQMON
Framework has following attributes:
+ The monitoring function is performed in real-time during each
communication session.
+ Any IP end points and applications who are producers or consumers
of IP Traffic, could use RAQMON Framework to report QOS statistics.
RAQMON QOS statistics can be used by many Real-Time Applications like
Voice over IP, Fax over IP, Video over IP, Instant Messaging etc. and
non-real time applications like Email, ftp/tftp based downloads, e-
business style transactions, web access from handheld devices etc to
report QOS statistics within one single framework.
+ RAQMON Framework is simplex, i.e., it RDSs reports statistics for
unidirectional data flows as experienced by the end device or
application.
+ RAQMON specifies a protocol data unit and provides specifications
to transport the RAQMON PDU over existing Internet standards like
RTCP APP Packet and SNMP INFORM.
RAQMON provides a framework to report QOS statistics for simplex
RMON WG Expires September 2003 [Page 18]
INTERNET DRAFT RAQMON Framework March 2003
flows, i.e., it reports statistics only in one direction. Therefore,
within RAQMON Framework, a RAQMON PDU is logically viewed QOS
parameters as perceived by the reporting end device or applications.
RAQMON operates on top of RTCP, SNMP, TCP, UDP, IPv4 or IPv6
occupying the place of a payload specification at the application
layer in the protocol stack. However, RAQMON PDUs does not transport
application data but is rather uses existing internet protocols like
RTCP APP Packet and SNMP INFORM to be transported from a RDS to RRC.
Like the implementations of routing and management protocols, an
implementation of RAQMON will typically execute in the background,
not in the data forwarding path. RAQMON PDUs by itself is not a
transport protocol; RAQMON PDUs are designed to operate with current
and future internet transport protocols.
+ RAQMON Framework is agnostic to the underlying measurement
methodology used to quantify a QOS parameter.
RAQMON PDUs offer an entry (a.k.a. "Name") to be filled in by
application specific software which with a specific "value". Since
RAQMON PDUs are common data formats commonly understood by RDS and
RRC to exchange RAQMON Statistics (i.e. "Name" and "Value" pair),
measurement methodologies are out of the scope of RAQMON
specification. It is also out of the scope of PDU specification to
validate specific measurement methodology used to gather a "value".
+ RAQMON Framework allows future extensibility by adding fields to
RAQMON APP PDUs. New Parameters not covered in the BASIC PDU could be
added to RAQMON APP PDU as Type Length Value (TLV) field. This
mechanism can also be used to accommodate application and vendor
specific extensions not covered in BASIC PDU.
+ In order to facilitate complete End-to-End view and to portray end
user experience, the RAQMON correlate statistics that involves:
i. "User, Application, Session" specific parameters - e.g. Instant
Message vs. VoIP, session setup time, session duration etc.
ii. "IP end device" specific parameters during a session e.g. CPU
Usage, memory usage
iii. "Transport network" specific parameter during a session (e.g.
End-to-End Delay, One Way Delay, Jitter, Packet loss etc.
User experience of an application running on a specific IP end point
has lot to do with the type of application an user is running, local
end device resources available as well as the underlying transport
network capabilities.
RMON WG Expires September 2003 [Page 19]
INTERNET DRAFT RAQMON Framework March 2003
+ RAQMON parameters in BASIC PDU are selectable by the RDS and
Application implementation.
End-to-End QOS view is sensitive to application type, device and
transport network. Though RAQMON PDUs are capable of carrying various
pre-specified parameters but the BASIC PDUs provide options to select
a sub-set of those parameters from the metrics definition list, to
fit the needs of the application-context. The Application implementer
controlling the RDS will be responsible for choosing a set of
parameters, as "monitoring context" is application specific.
For example an IP Soft Phone application running on a PC probably be
willing to report "Jitter" to RRC however an Email Application
running on the same host may not use the "Jitter" parameter to report
to RRC as Jitter is deemed to be not so critical for E-mail
Application.
+ Monitored statistics is reported by the RAQMON Data Source (RDS) at
will.
Content of the RAQMON PDUs, Transmission intervals between various
RAQMON PDUs etc. is controlled by the RDSs administrative domain
policy.
Though monitoring is a useful function but there are various
operation scenarios where monitoring could be expensive and degrade
the QOS of an application. There are also restrictions imposed on
end devices based on the administrative domains. For example, an
Enterprise IP Phone user is managed by the enterprise Telecom
manager, but the Service Level Agreements is monitored by the
Enterprise IT Managers. In such an environment, IP Phones may be
required to report QOS Problems to various administrative authorities
restricted by the administration domain policy. A RDS Driven
reporting mechanism allows enough flexibility to accommodate various
administrative constraints.
+ Quality of service parameters of each communication session should
be captured and stored "completely".
A communication session may consist of one or more combinations of
transaction-oriented, throughput-oriented, or streaming-oriented
operations. For example, the quality-of-service definition of a Video
over IP call using Video Phones involves:
- Caller Video Phone signaling for call setup that includes a
transaction with a session processing server which locates/connects
the callee using a protocols like SIP, H.323 or MGCP.
RMON WG Expires September 2003 [Page 20]
INTERNET DRAFT RAQMON Framework March 2003
- Eventually the video phone source/sinks media streams between two
IP end points using RTP as a result of successful session setup
transaction
In this particular application scenario, the session set up timing is
as critical as the end-to-end delay per packet of audio and video
media streams. The RAQMON PDUs should provide a capability to
capture such session specific data.
RAQMON draft would use the following definitions of transactions as
defined in the APM MIB [WALDBUSSER]:
Transaction-Oriented: These transactions have a fairly constant
workload to perform for all transactions. The responsiveness metric
for transaction-oriented applications is application response time,
the elapsed time between the user's request for service (e.g. pushing
the submit button or pressing DTMF in IP Phones) and the completion
of the request (e.g. displaying the results or getting a ring back).
Throughput-Oriented: These transactions have widely varying workloads
based on the amount of data requested. The metric for throughput-
oriented applications are expressed in is Kilobits per second (Kbps)
or Mega bits per second (Mbps).
Streaming-Oriented: These transactions deliver data at a constant
metered rate of speed regardless of excess capacity in the networking
and computing infrastructure. However, when the infrastructures
cannot deliver data at this speed, interruption of service or
degradation of service can result.
+ Within RAQMON Framework, a report on a communication session
between users captures the entire session by keeping records of all
the sub-sessions performed within that session.
A generic communication session between two users can be modeled as
multiple sub-sessions within a communication session. For example a
video call between two users would capture Quality of Service
parameters of a session for Audio, Video and Data separately but
within one compound report as it reflects the true nature of the
communication session. It is easier for an end device to correlate
between these sub-sessions and report the End-to-End QOS parameters
of that session in a compound report.
+ RAQMON Framework design is embedded device friendly.
The applications covered under the RAQMON Charter have become such a
commodity in our everyday lives that there are lots of simple
embedded smart devices being developed by various vendors at an
RMON WG Expires September 2003 [Page 21]
INTERNET DRAFT RAQMON Framework March 2003
enormous rate. Application Service Providers, Network Service
Providers, Enterprise operators, IT Managers etc. have an inherent
need to gather QOS Reports of these devices and applications to
manage there networks and services. It is the objective of this draft
to deliver a simple but easy to deploy monitoring solution.
+ RAQMON MIB is agnostic to the transport protocol used to carry
RAQMON PDUs between RDS and RRC.
5. Normative References
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000
[RFC1889] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications"
RFC 1889, January 1996.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
6. Informative References
[RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video Conferences
with Minimal Control" RFC 1890, January 1996.
[RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305,
March 1992.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot,
"Address Allocation for Private Internets", RFC 1597, March 1994.
[RFC2679] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999
[RFC2680] G. Almes, S.Kalidindi and M.Zekauskas, "A One-way Packet
RMON WG Expires September 2003 [Page 22]
INTERNET DRAFT RAQMON Framework March 2003
Loss Metric for IPPM", RFC 2680, September 1999
[RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay
Metric for IPPM", RFC 2681, September 1999
[WALDBUSSER] Steven Waldbusser, "Application Performance Measurement MIB",
draft-ietf-rmonmib-apm-mib-04.txt, July 2001
[DIETZ] Russel Dietz, Robert Cole, "Transport Performance Metrics MIB",
draft-ietf-rmonmib-tpm-mib-03.txt, July 2001
[ISO10646] International Standards Organization, "ISO/IEC DIS 10646-1:1993
information technology -- universal multiple-octet coded
character set (UCS) -- part I: Architecture and basic
multilingual plane," 1993.
[UNICODE] The Unicode Consortium, The Unicode Standard New York,
New York:Addison-Wesley, 1991.
[IEEE802.1D] Information technology-Telecommunications and information
exchange between systems--Local and metropolitan area networks-
Common Specification a--Media access control (MAC) bridges:
15802-3: 1998 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1998 Edition]
[RFC1349] P. Almquist, "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers" RFC1812,
June 1995
[RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC2474, December 1998
[RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and W.Weiss,
"An Architecture for Differentiated Services" RFC2475,
December 1998
[SIDDIQUI1] A. Siddiqui, D.Romascanu, E. Golovinsky, and R. Smith,
"Real-time Application Quality of Service Monitoring (RAQMON)
MIB", Internet-Draft, draft-siddiqui-rmonmib-raqmon-mib-01.txt,
February 2002
[SIDDIQUI2] A. Siddiqui, S. Waldbusser, D.Romascanu, and E. Golovinsky,
"Protocol Data Units for Real-time Application Quality of Service
Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon-pdu-
01.txt, March 2003
RMON WG Expires September 2003 [Page 23]
INTERNET DRAFT RAQMON Framework March 2003
[SIDDIQUI3] A. Siddiqui, D.Romascanu, E. Golovinsky, and R. Smith,
"Real-time Application Quality of Service Monitoring (RAQMON)
MIB", Internet-Draft, draft-ietf-rmonmib-raqmon-mib-00.txt,
January 2003
7. 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.
8. Security Considerations
There are a number of management objects defined in this MIB
that have a MAX-ACCESS clause of read-write and/or read-create.
Such objects may be considered sensitive or vulnerable in some
network environments. The support for SET operations in a
non-secure environment without proper protection can have a
negative effect on network operations.
It is thus important to control even GET access to these objects
and possibly to even encrypt the values of these object when
sending them over the network via SNMP. Not all versions of
SNMP provide features for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the
network itself is secure (for example by using IPSec), even then,
there is no control as to who on the secure network is allowed
to access and GET/SET (read/change/create/delete) the objects in
this MIB.
It is RECOMMENDED that the implementers consider the security
RMON WG Expires September 2003 [Page 24]
INTERNET DRAFT RAQMON Framework March 2003
features as provided by the SNMPv3 framework. Specifically, the
use of the User-based Security Model [RFC2274] and the
View-based Access Control Model [RFC2275] is RECOMMENDED.
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those
principals (users) that have legitimate rights to indeed GET or
SET (change/create/delete) them.
It is also imperative that the RAQMON framework be able to provide the
following protection mechanisms:
1. Authentication - the RRC should be able to verify that a RAQMON
report was originated by whom ever claims to have sent it.
2. Privacy - RAQMON information include identification of the parties
participating in a communication session. RAQMON framework should be
able to provide protection from eavsdropping, to prevent an
un-authorized third party from gathering potentially sensitive
information. This can be achieved by using various payload encryption
technologies like DES, 3-DES, AES
3. Protection from denial of service attacks directed at the RRC -
RDSs send RAQMON reports as a side effect of an external event (for
example, a phone call is being received). An attacker can try and
overwhelm the RRC (or the network) by initiating a large number of
events (i.e., calls) for the purpose of swamping the RRC with too many
RAQMON PDUs.
To prevent DoS attacks against RRC, the RDS will send the first report
for a session only after the session has been in progress for the TBD
reporting interval. Sessions shorter than that will not be reported.
4. NAT and Firewall Friendly Design: Presence for IP addresses,
TCP/UDP ports information in RAQMON PDUs may be NAT un-friendly. In
such a scenario, where NAT Friendliness is a requirement, the RDS may
opt to not to provide IP Addresses in RAQMON PDU. Another way to avoid
this problem is by using NAT Aware Application Layer Gateways (ALGs)
to fill out IP Addresses in RAQMON PDUs.
9. IANA Considerations
This memo introduces 2 new ports for IANA registration. This
specification registers port 5YYYY as specified in Section 4.5.1
and Port 5XXX as specified in section 4.5.2.2. at
http://www.iana.org/numbers.html
RMON WG Expires September 2003 [Page 25]
INTERNET DRAFT RAQMON Framework March 2003
10. Authors' Addresses
Anwar A. Siddiqui
Avaya Labs
307 Middletown Lincroft Road
Lincroft, New Jersey 07738
USA
Tel: +1 732 852-3200
Fax: +1 732 817-5922
E-mail: anwars@avaya.com
Dan Romascanu
Avaya Inc.
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com
Eugene Golovinsky
BMC Software Inc.
2101 CityWest Blvd.
Houston, Texas 77042
USA
Tel: +1 713 918-1816
Email: eugene_golovinsky@bmc.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
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.
RMON WG Expires September 2003 [Page 26]
INTERNET DRAFT RAQMON Framework March 2003
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.
RMON WG Expires September 2003 [Page 27]
