Internet Draft Anwar Siddiqui
draft-ietf-rmonmib-raqmon-framework-07.txt Avaya Inc.
Category: Standards Track Dan Romascanu
Expires April 2005 Avaya
Eugene Golovinsky
BMC Software
15 October 2004
Real-time Application Quality of Service
Monitoring (RAQMON) Framework
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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 made obsolete 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.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
There is a need to monitor end devices such as IP phones, pagers,
Instant Message clients, mobile phones, and various other hand-held
computing devices. This memo extends the remote network monitoring
(RMON) family of specifications to allow real-time quality of service
(QoS) monitoring of various applications that run on these devices,
and allows this information to be integrated with the RMON family
using the Simple Network Management Protocol (SNMP). This memo
RMON WG Expires April 2005 [Page 1]
INTERNET DRAFT RAQMON Framework 15 October 2004
defines the framework, architecture, relevant metrics, and transport
requirements for real-time quality of service monitoring of
applications.
Distribution of this memo is unlimited.
Table of Contents
Status of this Memo..................................................1
Abstract.............................................................1
1 Introduction.......................................................3
2 RAQMON Functional Architecture.....................................5
3 RAQMON Operation in Congestion-Safe Mode..........................12
4 Measurement Methodology...........................................14
5 Metrics pre-defined for the BASIC Part of the RAQMON PDU..........15
6 Report Aggregation and Statistical Data processing................25
7 Keeping Historical Data and Storage...............................26
8 Acknowledgements..................................................27
9 Security Considerations...........................................27
10 Normative References.............................................29
11 Informative References ..........................................30
Authors' Addresses..................................................31
Full Copyright Statement............................................31
RMON WG Expires April 2005 [Page 2]
INTERNET DRAFT RAQMON Framework 15 October 2004
1. Introduction
With the growth of the Internet and advancements in embedded
technologies, smart IP devices, such as IP phones, pagers, instant
message clients, mobile phones, wireless hand-helds and various other
computing devices, have become an integral part of our day-to-day
operations. Enterprise operators, information technology (IT)
managers, application service providers, network service providers,
and so on need to monitor these application and device types in order
to ensure that end user quality of service (QoS) objectives are met.
This memo describes a monitoring solution for these environments,
extending the remote network monitoring (RMON) family of
specifications [RFC2819]. These extensions support real-time QoS
monitoring of typical applications that run on end devices like
these, and allows this information to be integrated using the
familiar RMON family of specifications via SNMP.
The Real-time Application QoS Monitoring Framework (RAQMON) allows
end devices and applications to report QoS statistics in real time.
Many real-time applications as well as non-real-time applications
managed within the RMON family of specifications can report
application level QoS statistics in real time using the RAQMON
Framework outlined in this memo. Some possible applications
scenarios include applications such as Voice over IP, Fax over IP,
Video over IP, Instant Messaging (IM), Email, software download
applications, e-business style transactions, web access from handheld
computing devices, etc.
The user experience of an application running on an IP end device
depends upon the type of application the user is running and the
surrounding resources available to that application. An end-to-end
application quality of service (QoS) experience is a compound effect
of various application level transactions and available network and
host resources. For example, the end-to-end user experience of a
Voice over IP (VoIP) call depends on the total time required to set
up the call as much as on media related performance parameters such
as end-to-end network delay, jitter, packet loss, and the type of
codec used in a call. Behavior of network protocols like RSVP,
explicit tags in differentiated services (DiffServ) [RFC2475] or IEEE
802.1 [IEEE802.1D] along with available host resources such as device
CPU or memory utilized by other applications while the call is
ongoing also influence the performance of a VoIP call.
End-to-end application quality of service (QoS) experience is
application context sensitive. For example, the kinds of parameters
reported by an IP telephony application may not really be needed for
other applications such as Instant Messaging. The Real Time
Application QoS Monitoring (RAQMON) Framework offers a mechanism to
RMON WG Expires April 2005 [Page 3]
INTERNET DRAFT RAQMON Framework 15 October 2004
report the end-to-end QoS experience appropriate for a specific
application context by providing mechanisms to report a subset of
metrics from a pre-defined list.
In order to facilitate a complete end-to-end view, RAQMON correlates
statistics that involve:
i. "User, Application, Session" specific parameters - e.g.
session setup time, session duration parameters based on
application context.
ii. "IP end device" specific parameters during a session - e.g.
CPU usage, memory usage.
iii. "Transport network" specific parameters during a session -
e.g. end-to-end delay, one-way delay, jitter, packet loss
etc.
At any given point, it's the applications at these devices that can
correlate such diverse data and report end-to-end performance. The
RAQMON Framework specified in this memo offers a mechanism to report
such end-to-end QoS view and integrate such a view into the RMON
family of specifications. In particular, the RAQMON Framework
standardizes the following:
a. A set of basic metrics sent as reports between the RAQMON
entities using existing Internet Transport Protocols such as
TCP, or SNMP.
b. Requirements to be met by the underlying transport protocols
that carry the RAQMON reports.
c. A portion of the Management Information Base (MIB) as an
extension of the RMON MIB Modules for use with network
management protocols in the Internet community.
This memo provides the RAQMON functional architecture, RAQMON entity
definitions and requirements, requirements for the transport
protocols, and a set of metrics and informational model for the
RAQMON reports,
Supplementary memos will describe the mapping of the basic RAQMON
metrics onto different transport protocols. For example the RAQMON
PDU [RAQMON-PDU] memo provides definitions of syntactical PDU
structure and use case scenarios of transmission of such PDUs over
the Transmission Control Protocol (TCP) and the Simple Network
Management Protocol (SNMP).
RMON WG Expires April 2005 [Page 4]
INTERNET DRAFT RAQMON Framework 15 October 2004
The RAQMON MIB [RAQMON-MIB] memo describes the Management Information
Base (MIB) for use with the SNMP protocol in the Internet community.
The document proposes an extension to the Remote Monitoring MIB
[RFC2819] to accommodate RAQMON solutions.
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
The RAQMON Framework extends the architecture created in the RMON MIB
[RFC2819] by providing application performance information as
experienced by end-users. The RAQMON architecture 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, application clients like instant message
clients, soft phones in PCs, etc. are envisioned to act as RDSs
within the RAQMON Framework.
RMON WG Expires April 2005 [Page 5]
INTERNET DRAFT RAQMON Framework 15 October 2004
+----------------------+ +---------------------------+
| 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 TCP or SNMP Notifications
|
+----------------------------+
| |
|/ |/
+------------------+ +------------------+ +------------------+
|RAQMON Report | .. |RAQMON Report | |Network Management|
|Collector (RRC) #n| |Collector (RRC) #1|<--5-->| Application |
+------------------+ +------------------+ +------------------+
Figure 1 - RAQMON Framework.
(1) Communication Session between applications
(2) Context-Sensitive Metrics
(3) Device State Specific Metrics
(4) RAQMON metrics transmitted over specified interfaces (Specific
Protocol Interface, IP Address, port)
(5) Management Application - RRC interaction using the RAQMON MIB
A RAQMON Report Collector (RRC) collects statistics from multiple
RDSs, analyzes them, 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. The RRC component of the RAQMON architecture is
envisioned to be computationally resourceful. Only RRCs should
implement the RAQMON MIB.
RMON WG Expires April 2005 [Page 6]
INTERNET DRAFT RAQMON Framework 15 October 2004
The RAQMON Management Information Base (RAQMON MIB) extends the
Remote Monitoring MIB [RFC2819] to accommodate the RAQMON Framework
and exposes End-to-End Application QoS information to Network
Management Applications.
2.1 RAQMON Data Source (RDS)
2.1.1 RAQMON Data Source (RDS) Functional Architecture
A RAQMON Data Source (RDS) is a source of data for monitoring
purposes. The RDS monitoring function is performed in real time
during each communication session. The RDS entities capture QoS
attributes of such communication sessions and report them within a
RAQMON "reporting session".
A RDS is primarily responsible for abstracting IP end devices and
applications within the RAQMON Architecture. It gathers the
parameters for a particular communication session and forwards them
to the appropriate RAQMON Report Collector (RRC). Since it is
envisioned that the RDS functionality will be realized by writing
firmware/software running on potentially small, low-powered end
devices, the design of the RDS element is optimized towards that end.
Like the implementations of routing and management protocols, an
implementation of RDS in an end device will typically execute in the
background, not in the data-forwarding path.
RDSs use a PUSH mechanism to report QoS parameters. While the
applications running on the RDS decide about the content of the PDU
appropriate for an application context, a RAQMON Data Source (RDS)
asynchronously sends out reports to RRC.
The rate at which PDUs are sent from RDSs to RRCs is controlled by
the applications' administrative domain policy. While this mechanism
provides flexibility to gather a detailed end-to-end experience
required by IT Managers and System Administrators, certain steps
should be followed to operate RAQMON in congestion-safe manner.
Section 3 addresses steps required for congestion-safe operation.
A RAQMON Data Source (RDS) reports QoS statistics for simplex flows.
At a given instance, a report from RDS is logically viewed as a
collection of QoS parameters associated with a communication session
as perceived by the reporting RDS. If two IP Phone users for example
Alice and John, are involved in a communication session, the end-to-
end delay experienced by the IP Phone user Alice could be different
from the one experienced by the IP Phone user John for a variety of
reasons. Hence a report from Alice's IP Phone represents the QoS
performance of that call as perceived by the RDS that resides in
Alice's IP phone.
RMON WG Expires April 2005 [Page 7]
INTERNET DRAFT RAQMON Framework 15 October 2004
2.1.2 RAQMON Data Source (RDS) Requirements
1. RAQMON Data Sources SHALL gather reports from multiple
applications residing in that device and of SHALL send out
compound QoS reports associated with multiple communication
sessions at a given moment.
Examples include a conference bridge hosting several different
conference calls or a two party video call consisting of
audio/video sessions. In each case an RDS could send out one
single RAQMON report that consists of multiple sub-reports
associated with audio and video sessions or sub-reports for
each conference call.
2. RAQMON Data Sources MUST support at least one of the standard
mappings on transport protocols.
2.1.3 Configuring RAQMON Data Sources
In order to report statistics to RAQMON Report Collectors, RDSs will
need to be configured with the following parameters:
1. The time interval between RAQMON PDUs. This parameter MUST be
configured such that overflow of any RAQMON parameter within a
PDU between consecutive transmissions is avoided.
2. The IP address and port of target RRC.
A RDS MAY use one or more of the following mechanisms to gain access
to configuration parameters:
- RDS acts as a trivial file transfer protocol (TFTP) client and
downloads text scripts to read the parameters
- RDS acts as a Dynamic Host Configuration Protocol (DHCP) Client
and gets RRC addressing information as a DHCP option
- RDS acts as a DNS client and gets target collector information
from a DNS Server - RDS acts as a LDAP Client and uses
directory look-ups
- RDS is manually configured using command line interface (CLI),
Telephone User Interface (TUI) etc.
Compliance to the RAQMON specification does not require usage of any
specific configuration mechanisms mentioned above. It is left to the
implementers to choose appropriate provisioning mechanisms for a
system.
2.2 RAQMON Report Collector (RRC)
RMON WG Expires April 2005 [Page 8]
INTERNET DRAFT RAQMON Framework 15 October 2004
2.2.1 RAQMON Report Collector (RRC) Functional Architecture
A RAQMON Report Collector (RRC) receives RAQMON PDUs from multiple
RDSs, and analyzes and stores the information in the RAQMON MIB. The
RRC is envisioned to be computationally resourceful, providing a
storage and aggregation point for a set of RDSs.
Since RDSs can belong to separate administrative domains, the RAQMON
Framework allows RDSs to report QoS parameters to separate RRCs.
Vendors can develop a management application to correlate information
residing in different RRCs across multiple administrative domains to
represent one communication session. However such application level
specification in RRC is beyond the scope of this memo.
2.2.2 RAQMON Report Collector (RRC) Requirements
1. RAQMON Report Collectors MUST support both standard mappings of
the RAQMON informational model defined in [RAQMON-PDU] with the
purpose of receiving RAQMON reports from RAQMON Data Sources
(RDS).
2. RAQMON Report Collectors MUST implement session time out
mechanisms to assume end of reporting for RDSs that have been
out of reporting for a reasonable duration of time. Such time
out parameters SHOULD be configurable in vendor
implementations, programmable at deployment.
3. RAQMON Report Collectors MUST support the RAQMON-MIB module and
meet the compliance requirements of the raqmonCompliance
MODULE-COMPLIANCE definition as described in [RAQMON-MIB]. The
population of the RAQMON MIB with performance monitoring
information is independent of the transport protocol, or
protocols used to carry the information between RDSs and RRCs.
2.3 Informational Model and RAQMON Protocol Data Unit (PDU)
2.3.1. RAQMON Informational Model
RAQMON defines a set of basic metrics that characterize the Quality
of Service (QoS) of applications, as reported by RAQMON Data Sources.
This basic set of metrics is defined in Section 5 of this memo. There
is no minimal requirement for a mandatory set of metrics to be
supported by a RAQMON data source.
RMON WG Expires April 2005 [Page 9]
INTERNET DRAFT RAQMON Framework 15 October 2004
New applications, new types of network appliances, or new methods to
measure and characterize the QoS of applications lead to the
requirement for the information model to be extensible. To answer
this need the information model is designed so that vendors can
extend it by adding new metrics.
The RAQMON Informational Model is expressed by defining a conceptual
RAQMON Protocol Data Unit (PDU).
2.3.2 RAQMON Protocol Data Unit
A RAQMON Protocol Data Unit (PDU) is a common data format understood
by RDSs and RRCs. A RAQMON PDU does not transport application data
but rather occupies the place of a payload specification at the
application layer of the protocol stack. Different transport
mappings may be used to carry RAQMON PDU between RDSs and RRCs.
Transport protocol requirements are being defined in Section 2.4 of
this memo.
Though architected conceptually as a single Protocol Data Unit, the
RAQMON PDU is functionally divided into two different parts. They
are the BASIC Part, and the Application Specific Extensions, required
for vendor specific extensions. Structure of Management Information
(SMI) Network Management Private Enterprise Codes are being used to
indicate the owner of the definition of a specific section of the
RAQMON PDU. These codes are currently maintained by the Internet
Assigned Numbers Authority (IANA) at
http://www.iana.org/assignments/enterprise-numbers. Depending on the
respective transport, the enterprise code may be implicitly carried
by the protocol (i.e. SNMP OIDs), or will be carried in explicit
fields.
The BASIC Part of the RAQMON PDU:
The BASIC part of the RAQMON PDU trails behind the SMI Network
Management Private Enterprise Code 0 - indicating an IETF standard
construct. The RAQMON PDU BASIC part offers an entry-type from a
pre-defined list of QoS parameters defined in Section 5 and allows
applications to fill in appropriate values for those parameters.
Application developers also have the flexibility to make an RDS
report built only of a sub-set of the parameters listed in Section
5. There is no need to carry all metrics in every PDU, moreover it
is RECOMMENDED that static or pseudo-static metrics which do not
change, or seldom change for a given session or application will
be send only when the session or application are initiated, and
then at large time intervals.
RMON WG Expires April 2005 [Page 10]
INTERNET DRAFT RAQMON Framework 15 October 2004
The Application Part of RAQMON PDU:
Since it is difficult to structure a BASIC Part that meets the
needs of all applications, RAQMON provides extension capabilities
to convey application-, vendor-, device-, etc. specific parameters
for future use. Additional parameters can be defined within
payload of the APP part of the PDU by the application developers
or vendors. The Application part of the RAQMON PDU trails behind
a vendor's SMI Network Management Private Enterprise Codes found
in http://www.iana.org/assignments/enterprise-numbers. Such
application specific extensions should be maintained and published
by the application vendor.
Though RDSs and RRCs are designed to be stateless for an entire
reporting session, the framework would require an indication for the
end of the reporting. For this purpose an RDS MUST send a RAQMON
NULL PDU. A NULL PDU is a RAQMON PDU containing ALL NULL values
(i.e. nothing to report).
2.4 RDS/RRC Network Transport Protocol Requirements
The RAQMON PDUs rely on the underlying protocol(s) to provide
transport functionalities and other attributes of a transport
protocol, e.g., transport reliability, re-transmission, error
correction, length indication, congestion safety,
fragmentation/defragmentation, etc. The maximum length of the RAQMON
data packet is limited only by the underlying protocols.
The following requirements MUST be met by the transport protocols:
1. The transport protocol SHOULD allow for RDS lightweight
implementations - RDSs will be implemented on low powered
embedded devices with limited device resources.
2. Scalability - since RRCs need to interact with a very large
number (many tenth, many hundreds, more) of RDSs, scalability
of the transport protocol is REQUIRED.
3. Congestion safety - as per [RFC2914] - see also Section 3
4. Security - Since RAQMON statistics may carry sensitive system
information requiring protection from unauthorized disclosure
and modification in transit, a transport protocol that provides
strong secure modes is REQUIRED
5. NAT Friendly - The transport protocol SHOULD comply with
[RFC3235], so that an RDS could communicate with an RRC through
a Firewall/Network Address Translation device.
RMON WG Expires April 2005 [Page 11]
INTERNET DRAFT RAQMON Framework 15 October 2004
6. The transport protocol MAY implement session time out
mechanisms to assume end of reporting for RDSs that have been
out of reporting for a reasonable duration of time. Such time
out parameters SHOULD be configurable in vendor
implementations, programmable at deployment.
7. Reliability - The RAQMON Framework expects PDUs to operate in
lossy networks. However, retransmission is not included in the
RAQMON framework, in order to keep the design simple. If
retransmission is a necessity, RAQMON MAY operate over
transport protocols, such as TCP.
In the 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 for the RAQMON
packets must be defined to provide a framing mechanism. Framing is
also needed if the underlying protocol contains padding so that the
extent of the RAQMON payload cannot be determined. No framing
mechanism is defined in this document. Carrying several RAQMON
packets in one network or transport packet reduces header overhead.
Further memos like [RAQMON-PDU] describe how the PDU is transported
over existing protocols like the Transmission Control Protocol (TCP)
or the Simple Network Management Protocol (SNMP).
3. RAQMON Operation in Congestion-Safe Mode
RAQMON PDUs can be transmitted over multiple transport protocols,
including UDP, DCCP and TCP. The RAQMON Framework will be congestion
safe, if a RAQMON PDU is transported over TCP. To ensure congestion
safety, clearly the best thing to do is to use a transport protocol
like TCP or Stream Control Transmission Protocol (SCTP). If this is
not feasible, it may be necessary to fall back on UDP. A RAQMON PDU
from RDS to RRC over a transport protocol running over UDP for
transport, which might lead to network congestion under heavy network
load.
One solution to the congestion awareness problem could have been to
deprecate UDP entirely for RAQMON. Though RAQMON PDU can be
transported over TCP, Some transports like SNMP over TCP are not
commonly practiced in practical deployments.
The use of UDP inherently increases the risks of network congestion
problems, as UDP itself does not define congestion prevention,
avoidance, detection, or correction mechanisms. The fundamental
problem with UDP is that it provides no feedback mechanism to allow a
RMON WG Expires April 2005 [Page 12]
INTERNET DRAFT RAQMON Framework 15 October 2004
sender to pace its transmissions against the real performance of the
network. While this tends to have no significant effect on extremely
low-volume sender-receiver pairs, the impact of high-volume
relationships on the network can be severe. This problem could be
further aggravated by large RAQMON PDU fragmented at the UDP level.
Transport protocols such as DCCP can also be used as underlying
RAQMON PDU transport, which provides flexibility of UDP style
datagram transmission with congestion control.
It should be noted that the congestion problem is not just between
RDS and RRC pairs, but whenever there is a high fan-in ratio,
congestion would occur. E.g. many RDSs reporting to an RRC. Within
the RAQMON Framework using UDP as a transport, congestion safety can
be achieved in following ways:
1. Constant Transmission Rate: In a well-managed network a
constant transmission rate policy (e.g. 1 RAQMON PDU per device
every N seconds) will ensure congestion safety as devices are
introduced into the network in a controlled manner. For
example, in an Enterprise Network, IP Phones are added in a
controlled manner and a constant transmission rate policy can
be sufficient to ensure congestion safe operation. As a worst-
case scenario, if the RDSs enforce an administrative policy
where the maximum PDU transmission rate is no more 1 RAQMON PDU
every 2 minutes, a UDP based implementation can be as
congestion safe as a TCP based implementation. Such policies
can be enforced while configuring an RDS.
2. Retransmission timers with back offs: This approach requires
that a request be sent at the application level, then there is
a wait for some sort of response indicating that the request
was received before sending anything else. This produces an
effect described by some as "ping-ponging" -- traffic bounces
back and forth between two nodes like a ping-pong ball in a
match. Since there's only one ball in play between any two
players at any given time, most of the potential for congestion
cascades is eliminated. For example if RAQMON PDU is
transported using SNMP INFORM PDUs over UDP, a SNMP response
from the RRC SHOULD be processed by the RDS to implement this
mechanism.
This pacing or serialization approach has the side-effect of
significantly reducing the maximum throughput, as transmission
occurs in only one direction at a time and there is at least a
2xRTT (round-trip time) delay between transmissions. More
sophisticated algorithms such as those in TCP and SCTP have
been developed to address this, and it would be inappropriate
to duplicate that work at the application level. Consequently,
RMON WG Expires April 2005 [Page 13]
INTERNET DRAFT RAQMON Framework 15 October 2004
if greater efficiency is required than that provided by this
simple approach, implementers SHOULD use TCP, SCTP, or another
such protocol. But if one absolutely must use UDP, this
approach works. It has been also used in other application
scenarios like SIP over UDP.
3. By restricting transmission to maximum transmission unit (MTU)
Size: A RDS may be faced with a request to deliver a large
message using UDP as a transport. Fragmentation of such
messages is problematic in several ways. Loss of any fragment
requires time-out and retransmission of the message. The
fragments are commonly transmitted out of the interface at
local interface (usually LAN) rates, without awareness of the
intervening network conditions. For these reasons, it is
generally considered a bad practice to send large PDUs over
UDP. If the MTU size is known, as an implementation, an RDS
should not allow an application to send more information by
limiting the size of transmissions over UDP to reduce the
effects of fragmentation. As an alternate, an RDS MAY also
send parameters to RRC over multiple RAQMON PDUs but identify
them as the same RAQMON reporting session with exactly the same
Network Time Protocol (NTP) time stamp.
While the actual MTU of a link may not be known, common
practice seems to indicate that the RDS local interface MTU is
likely to be a reasonable "approximation". Where the actual
path MTU is known, that value SHOULD be used instead.
4. Irrespective of choice of transport protocol, it is also
RECOMMENDED that no more than 10% network bandwidth be used for
RDS/RRC reporting. More frequent reports from an RDS to RRC
would imply requirements for higher network bandwidth usage.
4. 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 to the implementers and equipment vendors to
choose. There are many different measurement methodologies available
for measuring application performance. These include probe-based,
client-based, synthetic-transaction, and other approaches. This
specification does not mandate a particular methodology. It is open
to any methodology that meets the minimum requirements. For
conformance to this specification, it is REQUIRED that the collected
data match the semantics described herein. However, it is
RECOMMENDED that vendors use IETF defined and International
Telecommunication Union (ITU) specified methodologies to measure
parameters when possible.
RMON WG Expires April 2005 [Page 14]
INTERNET DRAFT RAQMON Framework 15 October 2004
5. Metrics pre-defined for the BASIC part of the RAQMON PDU
The BASIC part of the RAQMON PDU provides for a list of pre-defined
parameters frequently used by applications to characterize end-to-end
application Quality of Service. This section defines a set of simple
metrics to be contained in the BASIC part of the RAQMON PDU, through
reference to existing IETF, ITU, and other standards organizations'
documents. Appropriate IETF or ITU references are included in the
metrics definitions.
As mentioned earlier, the RAQMON PDU also contains an application-
specific part, where application- and vendor-specific information not
included in BASIC part can be added as <Name, Value> pairs, or as a
variable binding list. These extensions, managed independently by
vendors or other organizations, should be published for wider
interoperability.
Applications are not required to report all the parameters mentioned
in this section, but should have the flexibility to report a subset
of these parameters appropriate to an application context. The
[RAQMON-PDU] memo further identifies the parameters that RDSs are
required to include in all PDUs for compliance, as well as optional
parameters that RDSs may report as needed. The definitions presented
here are meant to provide guidance to implementers, and IETF metric
definition references are provided for each metric. Application
developers should choose the metrics appropriate to their
applications' needs. Syntactical representations of the parameters
identified here are provided in the [RAQMON-PDU] specification.
5.1 Data Source Address (DA)
The Data Source Address (DA) is the address of the data source. This
could be either a globally unique IPv4 or IPv6 address, or a
privately allocated address as defined in [RFC1918].
It is expected that the Data Source Address (DA) would remain
constant within a given communication session. RDSs SHOULD avoid
sending these parameters within RAQMON reports too often to ensure an
efficient usage of network resources.
5.2 Receiver Source Address (RA)
The Receiver Source Address (RA) takes the same form as the Data
Source Address (DA) but represents the Receiver's Source Address. In
a communication session the reporting RDSs SHOULD fill in the other
party's address as a Receiver Source Address. Like the Data Source
Address, this could be either a globally unique IPv4 or IPv6 address,
or a privately allocated address as defined in [RFC1918].
RMON WG Expires April 2005 [Page 15]
INTERNET DRAFT RAQMON Framework 15 October 2004
It is expected that the Receiver Source Address (RA) would remain
constant within a given communication session. RDSs SHOULD avoid
sending these parameters within RAQMON reports too often to ensure an
efficient usage of network resources.
5.3 Data Source Name (DN)
The DN item could be of various formats as needed by the application.
Forms the DN could take include, but are not restricted to:
- "user@host", or "host" if a user name is not available as on
single-user systems. For both of these formats, "host" is 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]. Examples are
"big-guy@ip-phone.avaya.com" or "big-guy@135.8.45.178" for a
multi-user system. On a system with no user name, an example
would be "ip-phone4630.bigcompany.com". It is RECOMMENDED that
the standard host's numeric address not be reported via the DN
parameter, as the Data Source Address (DA) parameter is used for
that purpose.
- Another instance of a DN could be a valid E.164 phone number, a
SIP URI or any other form of telephone or pager number. It is
recommended that the phone number SHOULD be formatted with the
plus sign replacing the international access code. Example:
"+88 02 123 45678" for a number in Bangladesh.
The DN value is expected to remain constant for the duration of a
session. RDSs SHOULD avoid sending these parameters within RAQMON
reports too often to ensure an efficient usage of network resources.
5.4 Receiver Name (RN)
The Receiver Name (RN) takes the same form as Data Source Name (DN),
but represents the Receiver's name. In a communication session, an
application should supply as a Receiver Name the name of the other
party with which it is communicating.
The RN value is expected to remain constant for the duration of a
session. RDSs SHOULD avoid sending these parameters within RAQMON
reports too often to ensure an efficient usage of network resources.
5.5 Data Source Device Port Used
This parameter indicates the source port used by the application for
RMON WG Expires April 2005 [Page 16]
INTERNET DRAFT RAQMON Framework 15 October 2004
a particular session or sub-session in communication. Examples of
ports include TCP Ports or UDP Ports, as used by communication
application protocols such as Session Initiation Protocol (SIP), SIP
for Instant Messaging and Presence Leveraging Extensions (SIMPLE),
H.323, RTP, HyperText Transport Protocol (HTTP), and so on.
5.6 Receiver Device Port Used
This parameter indicates the receiver port used by the application
for a particular session or sub-session. Examples of ports include
TCP Ports, or UDP Ports used by communication application protocols
such as SIP, SIMPLE, H.323, RTP, HTTP, etc.
5.7 Session Setup Date/Time
This parameter gives the wall clock time when the RAQMON packet was
sent. This information is needed by the RRC. Wall clock time
(absolute time) is represented using the timestamp format of the
Network Time Protocol (NTP), which is in seconds relative to 0h UTC
(Coordinated Universal Time) on 1 January 1900 [RFC1305].
5.8 Session Setup Delay
The Session Setup Delay metric reports the duration of time required
by a network communication controller to set up a media path between
the communicating entities or end devices. For example, in VoIP
systems, a session setup time can be measured as the interval from
the last DTMF (dual-tone multi-frequency) button pushed to the first
ring-back tone that indicates that the far end is ringing. Another
example would be the Session Setup Delay of a SIP call, which is
measured as the elapsed time between when an INVITE is generated by a
User Agent and when the 200 OK is received. However as these
definitions are very specific to the type of system used and the
implementation details of such systems, no claim is made on the
appropriateness of the definition presented here. For any particular
application it is left to the implementers to define Session Setup
Delay appropriately.
5.9 Session Duration
The Session Duration metric reports how long a session or a sub-
session lasted. This metric is application context sensitive. For
example a VoIP Call Session Duration can be measured as the elapsed
time between call pick up and call termination, including session
setup time.
5.10 Session Setup Status
RMON WG Expires April 2005 [Page 17]
INTERNET DRAFT RAQMON Framework 15 October 2004
The Session Setup Status parameter is intended to report the
communication status of a session. Its values identify appropriate
communication session states, such as Call Progressing, Call
Established successfully, "trying," "ringing," "re-trying," "RSVP
reservation failed", and so on. This information could be used by
network management systems to calculate parameters such as call
success rate, call failure rate, etc., or by a debugging tool that
captures the status of a call's setup phase as soon as a call is
established.
5.11 Round Trip End-to-End Network Delay
The Round Trip End-to-End Network Delay [RFC3550], [RFC2681], is a
key metric for Application QoS Monitoring. Some applications do not
perform well (or at all) if the end-to-end delay between hosts is
large relative to some threshold value. Erratic variation in delay
values makes it difficult (or impossible) to support many real-time
applications such as Voice over IP, Video over IP, Fax over IP etc.
The Round Trip End-to-End Network delay of the underlying transport
network can be measured using methodologies described in [RFC2681],
or [RFC3550] depending on the type of application.
5.12 One Way End-to-End Network Delay
The One Way End-to-End Network Delay [RFC2679] metric reports the One
Way End-to-End delay encountered by traffic from the source to the
destination network interface. One-Way Delay measurements identified
by the IP Performance Metrics (IPPM) Working Group [RFC2679] will be
used to measure one-way end-to-end network delay.
The need for such a metric is derived from the fact that the path
from a source to a destination may be different from the path from
the destination back to the source ("asymmetric paths"), such that
different sequences of routers are used for the forward and reverse
paths. Therefore round-trip measurements actually measure the
performance of two distinct paths together.
Measuring each path independently highlights the performance
difference between the two paths that may traverse different Internet
service providers, and even radically different types of networks(for
example, research versus commodity networks, or ATM (asynchronous
transfer mode) versus Packet-over-SONET (synchronous optical)
transport networks.
Even when the two paths are symmetric, they may have radically
different performance characteristics due to asymmetric queuing.
Performance of an application may depend mostly on the performance in
RMON WG Expires April 2005 [Page 18]
INTERNET DRAFT RAQMON Framework 15 October 2004
one direction. For example, a file transfer using TCP may depend
more on the performance in the direction that data flows, rather than
the direction in which acknowledgements travel.
In quality-of-service (QoS) enabled networks, provisioning in one
direction may be radically different from provisioning in the reverse
direction, and thus the QoS guarantees differ. Measuring the paths
independently allows the verification of both guarantees.
While it is optional for application developers to report One way
End-to-End network delay within RAQMON PDU, RAQMON implementations
that readily derive One way End-to-End Network Delay by assuming
internet paths are symmetric (i.e. dividing Round Trip Delay by two)
are NOT RECOMMENDED.
5.13 Application Delay
Various Network Delay versions as outlined in section 5.11 and 5.12
do not include delays associated to buffering, play-out, packet-
sequencing, coding/decoding etc. in the end devices. The Application
Delay metrics defined in this section is targeted to capture such
delay parameter.
Application delay can be expressed as the time delay introduced
between the network interface and the application level presentation.
Since it is difficult to envision usage of all sorts of applications
the following guidance is provided to the implementers to measure the
Application delay:
- In the sending direction, Application delay is defined as the sum
of sample sequencing, accumulation and encoding delay.
- In the receiving direction application delay is calculated as the
sum of delays associated to buffering, play-out, packet-sequencing,
decoding associated with the receiving direction, if relevant.
It is easy to recognize that applications running on an IP device can
experience same network delay but have different application
associated delay values and hence the user experience associated to
specific applications will vary while the network delay value remains
same for both the applications.
Having network delay and application delay measurements available, a
management application can represent the delay experienced by the end
user at the application level as a sum of network delay and the
appropriate application delay. However the specification of such a
management application is outside the scope of RAQMON specification
RMON WG Expires April 2005 [Page 19]
INTERNET DRAFT RAQMON Framework 15 October 2004
5.14 Inter-Arrival Jitter
The Inter-Arrival Jitter metrics provides a short-term measure of
network congestion [RFC3550]. The jitter measure may indicate
congestion before it leads to packet loss. The inter-arrival jitter
field is only a snapshot of the jitter at the time of a RAQMON PDU is
generated and is not intended to be taken quantitatively as indicated
in [RFC3550]. Rather, it is intended for comparison of inter-arrival
jitter from one receiver over time. Such inter-arrival jitter
information is extremely useful to understand the behavior of certain
applications such as Voice over IP, Video over IP etc. Inter-arrival
jitter information is also used in the sizing of play-out buffers for
applications requiring the regular delivery of packets (for example,
voice or video play-out).
In [RFC3550], the selection function is implicitly applied to
consecutive packet pairs, and the "jitter estimate" is computed by
applying an exponential filter with parameter 1/16 to generate the
estimate (i.e., j_new = 15/16* j_old + 1/16*j_new).
5.15 IP Packet Delay Variation
[RFC 3393] provides guidance to several absolute jitter parameters.
RAQMON uses the [RFC 3393] definition of the IP Packet Delay
Variation (ipdv) for packets inside a stream of packets. The IP Delay
Variation metric is used to determine the dynamics of queues within a
network (or router) where the changes in delay variation can be
linked to changes in the queue length processes at a given link or a
combination of links. Such a parameter provides visibility within an
IP Network and a better understanding of application level
performance problems as it relates to IP Network performance.
5.16 Total Number of Application Packets Received
This metric reports the number of application payload packets
received by the RDS as part of this session since the last RAQMON PDU
was sent up until the time this RAQMON PDU was generated.
This parameter represents a very simple incremental counter that
counts the number of "application" packets that an RDS has received.
Since this count is a snapshot in time, depending on application
type, it also varies based on the application states e.g. an RDS
within an application session will report aggregated number of
application packets that were sent out during signaling setup, media
packets received, session termination etc.
For example, during Voice over IP or Video over IP session this
counter represents the number of signaling session related packets
RMON WG Expires April 2005 [Page 20]
INTERNET DRAFT RAQMON Framework 15 October 2004
that have been received which will be derived from the relevant
application signaling protocol stack such as SIP or H.323, SIMPLE and
various other signaling protocols used by the application to
establish the communication session.
However, during a period when media is established between the
communicating entities, this counter will be indicative of the number
of RTP Frames that have been sent out to the communicating party
since last PDU was sent out. The methodology described within RTCP
SR/RR reports [RFC3550] to count RTP frames can be one of the ways to
measure media related application packets received, applicable for
the scenarios described above.
5.17 Total Number of Application Packets Sent
This metric reports the number of signaling and payload packets sent
by the RDS as part of this session since the last RAQMON PDU was sent
up until the time this RAQMON PDU was generated. Similar to total
number of application packets parameter in section 5.14, this count
is a snapshot in time. Depending on application type, the counter
also varies based on various application states. including packet
counts for signaling setup, media establishment, session termination
states, and so on.
5.18 Total number of Application Octets Received
This metric reports the total number of signaling and payload octets
received in packets by the RDS as part of this session since the last
RAQMON PDU was sent, up until the time this RAQMON packet was
generated. This metric could be measured in different ways,
including the methodology described by [RFC3550].
5.19 Total number of Application Octets Sent
This metric reports the total number of signaling and payload octets
received in packets by the RDS as part of this session since the last
RAQMON PDU was sent, up until the time this RAQMON packet was
generated. This is similar to the Total Number of Application Octets
Received metric. This metric could be measured in different ways,
including the methodology described by [RFC3550].
5.20 Cumulative Packet Loss
The packet loss metric indicate loss associated with the network as
well as local device losses over time. This parameter is counted as
the total number of application packets from source that have been
lost since the beginning of reception. This number is defined to be
the number of packets expected less the number of packets actually
RMON WG Expires April 2005 [Page 21]
INTERNET DRAFT RAQMON Framework 15 October 2004
received, where the number of packets received includes any which are
late or duplicates. Thus for most applications, packets that arrive
late are not counted as lost. However, since receivers in certain
realtime application such as Voice over IP or Video over IP etc.
cannot be required to maintain unlimited buffers, a receiver MAY
categorize late-arriving packets as lost in such application context.
Packet loss by the underlying transport network can be measured using
methodologies described in [RFC2680], [RFC3550]. The number of
packets expected is defined to be the extended last sequence number
received, as defined next, less the initial sequence number received.
This may be calculated using techniques such as shown in Appendix A.3
of [RFC3550].
5.21 Packet loss in Fraction
The Packet loss in Fraction statistic represents packet loss as
defined above, but expressed as a percentage of the total traffic
over time. The fraction of application level packets from the source
lost since the beginning of reception, expressed as a fixed point
number with the binary point at the left edge of the field. This
value is calculated by dividing the total number of packets lost
(after the effects of applying any error protection such as FEC) by
the total number of packets expected, multiplying the result of the
division by 256, limiting the maximum value to 255 (to avoid
overflow), and taking the integer part.
5.22 Cumulative Application Packet Discards
RAQMON Framework allows applications to distinguish between packets
lost by the network and those discarded due to jitter and other
application level errors. Though packet loss and discard have equal
effect on the quality of the application, having separate counts for
packet loss and discards help identify the source of quality
degradation.
The packet discard metric SHOULD indicate packets discarded locally
by the device over time. Local device level packet discard is
captured as the total number of application level packets from the
source that have been discarded since the beginning of reception, due
to late or early arrival, under-run or overflow at the receiving
jitter buffer or any other application specific reasons.
Like most parameters reported within RAQMON PDU, it is optional for
the applications to report such parameters as part of RAQMON PDU.
RMON WG Expires April 2005 [Page 22]
INTERNET DRAFT RAQMON Framework 15 October 2004
5.23 Packet discards in Fraction
The Packet discards in Fraction parameter represents packets from the
source that have been discarded since the beginning of reception but
expressed as a percentage of the total traffic. It is calculated as
discarded packets as defined above percentage of the total traffic
5.24 Source Payload Type
The Source Payload Type reports payload formats (e.g. media
encodings) as sent by the data source, e.g. ITU G.711, ITU G.729B,
H.263, MPEG-2, ASCII, etc. This memo follows the definition of
Payload Type (PT) in [RFC3551]. For example, to indicate that the
Source Payload Type used for a session is PCMA (pulse-code modulation
with A-law scaling), the source payload field for the respective
session will be 8.
The Source Payload Type value is expected to remain constant for the
duration of a session, with the exception of events like dynamic
codec changes. RDSs SHOULD avoid sending these parameters within
RAQMON reports more often then necessary to ensure an efficient usage
of network resources.
5.25 Destination Payload Type
The Destination Payload Type reports payload formats (e.g. media
encodings) as sent by the other communicating party back to the
source, e.g. ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII, etc. This
document follows the definition of payload type (PT) in [RFC3551].
For example, to indicate that the Destination Payload Type used for a
session is PCMA the Destination Payload Type field for the respective
session will be 8.
The Destination Payload Type value is expected to remain constant for
the duration of a session, with the exception of events like dynamic
codec changes. RDSs SHOULD avoid sending these parameters within
RAQMON reports more often than necessary, to ensure an efficient
usage of network resources.
5.26 Source Layer 2 Priority
Many devices use Layer 2 technologies to prioritize certain types 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. Many devices use that standard to mark
RMON WG Expires April 2005 [Page 23]
INTERNET DRAFT RAQMON Framework 15 October 2004
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].
The Source Layer 2 Priority RAQMON field indicates what Layer 2
values were used by the RDS to prioritize these packets in the Local
Area Network environment.
The Source Layer 2 Priority value is expected to remain constant for
the duration of a session. RDSs SHOULD avoid sending these parameters
within RAQMON reports too often to ensure an efficient usage of
network resources.
5.27 Source TOS/DSCP Value
Various Layer 3 technologies are in place to prioritize traffic in
the Internet. For example, the traditional IP Precedence [RFC791],
and Type Of Service (TOS) [RFC1812], or more recent technologies like
Differentiated Services [RFC2474][RFC2475], use the TOS octet in
IPv4, while the Traffic class Octet is used to prioritize traffic in
Ipv6. Source Layer TOS/DCP RAQMON field reports the appropriate
Layer 3 values used by the Data Source to prioritize these packets.
The Source TOS/DSCP value is expected to remain constant for the
duration of a session. RDSs SHOULD avoid sending these parameters
within RAQMON reports too often to ensure an efficient usage of
network resources.
5.28 Destination Layer 2 Priority
The Destination Layer 2 Priority reports the Layer 2 value used by
the communication receiver to prioritize packets while sending
traffic to the data source in the Local Area Networks environment.
Like Source Layer 2 Priority, Destination Layer 2 Priority could
indicate whether the destination has used any Layer 2 technologies
like IEEE 802.1p/Q or priority queuing etc.
The Destination Layer 2 Priority value is expected to remain constant
for the duration of a session. RDSs SHOULD avoid sending these
parameters within RAQMON reports too often to ensure an efficient
usage of network resources.
5.29 Destination TOS/DSCP Value
The Destination TOS/DSCP RAQMON field reports the values used by the
Data Receiver to prioritize these packets received by the source.
Similar to Source Layer 3 Priority, Destination Layer 3 Priority
indicates whether the destination has used any Layer 3 technologies
RMON WG Expires April 2005 [Page 24]
INTERNET DRAFT RAQMON Framework 15 October 2004
like IP Precedence [RFC791], Type Of Service (TOS) [RFC2474],
[RFC1812] or more recent technologies like Differentiated Service
[RFC2474], [RFC2475].
The Destination TOS/DSCP value is expected to remain constant for the
duration of a session. RDSs SHOULD avoid sending these parameters
within RAQMON reports too often to ensure an efficient usage of
network resources.
5.30 CPU Utilization in Fraction
This parameter captures the IP Device CPU usage which may have very
critical implications for QoS of an end device. It is computed as an
average since the last reporting interval, and corresponds to the
percentage of that time that the CPU was busy.
5.31 Memory Utilization in Fraction
This parameter captures the IP Device Memory usage which may have
very critical implications for QoS of an end device. It is computed
as an average since the last reporting interval, and corresponds to
the average percentage of the total memory space critical for the
applications in use during that time interval (e.g. primary CPU RAM,
buffers).
5.32 Application Name/version
The Application Name/version parameter gives the name and optionally
the version of the application associated with that session or sub-
session, e.g., "XYZ VoIP Agent 1.2". This information may be useful
for scenarios where the end device is running multiple applications
with various priorities and could be very handy for debugging
purposes.
6. Report Aggregation and Statistical Data processing
Within the RAQMON Framework, RRCs are expected to have significantly
greater computational resources than RDSs. consequently, various
aggregation functions are performed by the RRCs, while RDSs are not
burdened by statistical data processing such as computation of
minima, maxima, averages, standard deviations, etc.
The RAQMON MIB is provides minimal aggregation of the RAQMON
parameters defined above. The RAQMON MIB is not designed to provide
extensive aggregation like the Application Performance Measurement
(APM) MIB [RFC3729] or the Transport Performance Metrics (TPM) MIB
[30]. One should use APM and TPM MIBs to aggregate parameters based
on protocols (e.g. performance of HTTP, RTP) or based on applications
RMON WG Expires April 2005 [Page 25]
INTERNET DRAFT RAQMON Framework 15 October 2004
(e.g. performance of VoIP, Video Applications).
In the RAQMON MIB, aggregation can be performed only on specific
RAQMON metric parameters. Aggregation always results in statistical
Mean/Min/Max values, according to these definitions:
Mean: Mean is defined as the statistical average of a metric over
the duration of a communication session. For example, if an
RDS reported End-to-End delay metric N times within a
communication session, then the Mean End-to-End Delay can be
computed by summing of these N reported values, and then
dividing by N.
Min: Min is defined as the statistical minimum of a metric over
the duration of a communication session. For example, if
the 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 smallest of the N end-to-end
delay metric values reported.
Max: Max is defined as the statistical maximum of a metric over
the duration of a communication session. For example, if
the 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 largest of the N End-to-End
Delay metric values reported.
7. Keeping Historical Data and Storage
It is evident from the document that the RAQMON MIB data need to be
managed to optimize storage space. The large 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.
Examples of how such storage space optimization can be performed
include:
1. Make data available through the MIB only at the end of a
communication session, i.e., upon receipt of a NULL PDU. The
aggregated data could be made available using the RAQMON MIB as
Mean, Max or Min entries and be saved for historical purposes.
2. Use a time-based algorithm that aggregates data over a specific
period of time within a communication session, thus requiring
fewer entries, to reduce storage space requirements. For
example, if an RDS sends data out every 10 seconds and the RRC
updates the RAQMON MIB once every minute, for every 6 data
RMON WG Expires April 2005 [Page 26]
INTERNET DRAFT RAQMON Framework 15 October 2004
points there would be one MIB entry.
3. Periodically delete historical data in accordance with an
administrative policy. An example of such a policy would be to
delete historical data older than 60 days. The implementation
of such policies is left to the application developer's
discretion, and their use is an operational concern.
8. Acknowledgements
The authors would like to thank Randy Presuhn for the extensive and
detailed review that he performed on this memo from all possible
aspects - technical content, editorial consistency, syntax, and
spelling. The authors would also like to thank Mahalingam Mani,
Steven Waldbusser, Alan Clark, Robert Cole, and Itai Zilbershtein for
interesting discussions and direct contributions in this problem
space.
9. Security Considerations
Security considerations associated with the RAQMON Framework are
discussed below, and in greater detail in other RAQMON memos as is
appropriate.
9.1 The RAQMON Threat Model
The vulnerabilities associated with the RAQMON Framework are a
combination of those associated with the underlying layers up to the
transport layer, and of possible exploits of RAQMON payload.
Possible exploits of RAQMON payloads fall within these classes:
1. Unauthorized examination of sensitive information in the
payload in transit;
2. Unauthorized modification of payload contents in transit,
leading to:
a. Mis-identification of information from one RAQMON reporting
session as belonging to another destined to the same RRC;
b. Mismapping of RAQMON sessions;
c. Various forms of session-level denial-of-service (DoS)
attacks;
d. DoS through modification of RAQMON parameter values and
statistics;
RMON WG Expires April 2005 [Page 27]
INTERNET DRAFT RAQMON Framework 15 October 2004
e. Invalid timestamps, leading to false interpretation of the
monitored data, affecting call records information, and
making difficult to place monitoring events in their
appropriate temporal context.
3. Malformed payloads, permitting the exploitation of potential
implementation weaknesses to compromise an RRC;
4. Unauthorized disclosure of sensitive data carried by
application PDUs, leading to a breach of confidentiality;
Consequently, threats based on unauthorized disclosure or
modification of payloads or headers will have to be assumed.
9.2 The RAQMON Security Requirements and Assumptions
In order to preserve integrity of the RAQMON PDU against these
threats, the RAQMON model must provide for cryptographically strong
security services.
Consequently, the RAQMON framework must be able to provide for the
following protections:
1. Authentication - the RRC should be able to verify that a RAQMON
PDU was in fact originated by the RDS that claims to have sent
it.
2. Privacy - Since RAQMON information includes identification of
the parties participating in a communication session, the
RAQMON framework should be able to provide for protection from
eavesdropping, to prevent an unauthorized third party from
gathering potentially sensitive information. This can be
achieved by using various payload encryption technologies, such
as Data Encryption Standard (DES), 3-DES, Advanced Encyrption
Standard (AES), etc.
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 should be stored in the RDS and will be reported only
after that interval has expired.
RMON WG Expires April 2005 [Page 28]
INTERNET DRAFT RAQMON Framework 15 October 2004
9.3 RAQMON Security Model
The RAQMON architecture permits the use of multiple transport
protocols. Most of these support a secure mode of operation. There
are advantages to relying on the security provided at the transport
protocol layer.
1. Transport protocol level security can generally protect the
payload with end-to-end authentication, confidentiality,
message integrity and replay protection services.
2. A good cryptographic security protocol always has an associated
key management protocol. Use of transport protocol security
relies on its key management, rather than requiring development
of another mechanism.
3. When transport protocol security is already enabled between the
RDS and RRC, additional encryption and message authentication
at the application level is avoided.
However, there are also shortcomings to be noted in relying on
transport protocol security.
1. When session-level isolation of the different RAQMON sessions
of an RDS-RRC pair is required, it will be necessary to open
separate transport protocol instances. Such cases, however,
may be rare.
2. Since security services are not provided by the RAQMON
framework, the absence of transport or lower protocol security
implies the absence of RAQMON security.
10. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000.
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations
for the Simple Network Management Protocol (SNMP)", STD
62, RFC 3416, December 2002.
RMON WG Expires April 2005 [Page 29]
INTERNET DRAFT RAQMON Framework 15 October 2004
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, July 2003.
11. Informative References
[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.
[RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305,
March 1992.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, March 1996.
[RFC2474] Nicholas, K., Blake, S., Baker, F, and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC2474, December
1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC2475, December 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-
Trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
RMON WG Expires April 2005 [Page 30]
INTERNET DRAFT RAQMON Framework 15 October 2004
Application Design Guidelines", RFC3235, January 2002.
[RFC 3393] Demichelis, C. and P. Chimento, "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)", RFC
3393, November 2002.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
and Video Conferences with Minimal Control", STD 65, RFC
3551, July 2003.
[RFC3711] Bauer, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC3729] Waldbusser, S., "Application Performance Measurement
MIB", RFC 3729, March 2004.
[RAQMON-PDU] Siddiqui, A., Romascanu, D., Golovinsky, E., Ramhman,
M., and B. Hu, "Transport Mappings for Real-time
Application Quality of Service Monitoring (RAQMON)
Protocol Data Unit (PDU)", Internet-Draft, draft-ietf-
raqmon-pdu-07.txt, October 2004.
[RAQMON-MIB] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-
time Application Quality of Service Monitoring (RAQMON)
MIB", Internet-Draft, draft-ietf-rmonmib-raqmon-
mib-05.txt, October 2004.
[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]
Authors' Addresses
Anwar A. Siddiqui
Avaya Labs
307 Middletown Lincroft Road
Lincroft, New Jersey 07738
USA
Tel: +1 732 852-3200
E-mail: anwars@avaya.com
Dan Romascanu
Avaya
Atidim Technology Park, Building #3
Tel Aviv, 61131
RMON WG Expires April 2005 [Page 31]
INTERNET DRAFT RAQMON Framework 15 October 2004
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com
Eugene Golovinsky
BMC Software Inc.
2101 CityWest Boulecard
Houston, Texas 77042
USA
Tel: +1 713 918-1816
Email: eugene_golovinsky@bmc.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
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 IPR disclosures made to the IETF secretariat 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 on-line repository at
http://www.ietf.org/ipr. 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 at ietf-ipr@ietf.org.
RMON WG Expires April 2005 [Page 32]
INTERNET DRAFT RAQMON Framework 15 October 2004
Acknowledgement:
Funding for the RFC Editor function is currently provided by the
Internet Society.
RMON WG Expires April 2005 [Page 33]