Internet Draft Anwar Siddiqui
Avaya Inc.
Dan Romascanu
Avaya
Eugene Golovinsky
BMC Software
9 February 2004
Real-time Application Quality of Service
Monitoring (RAQMON) Framework
<draft-ietf-rmonmib-raqmon-framework-05.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 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 extend the RMON family of specifications 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 RMON family of specifications to
allow QoS monitoring in real-time of various applications that run on
these types of end devices and allows such information to be
integrated with the RMON family of specifications via SNMP.
Distribution of this memo is unlimited.
RMON WG Expires August 2004 [Page 1]
INTERNET DRAFT RAQMON Framework February 2004
Table of Contents
Status of this Memo 1
Abstract 1
1 Introduction 2
2 RAQMON Functional Architecture 4
3 RAQMON Operation in Congestion Safe Mode 11
4 Measurement Methodology 13
5 A Simple list of Metrics pre-defined in BASIC PDU 14
6 Report Aggregation and Statistical Data processing 21
7 Keeping Historical Data and Storage 22
8 Normative References 23
9 Informative References 23
10 Intellectual Property 25
11 Security Considerations 25
12 Acknowledgements 29
13 Authors' Addresses 29
A Full Copyright Statement 30
1. Introduction
With the growth of the Internet and the 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, IT Managers, Application Service
Providers, Network Service Providers etc. have an inherent need to
monitor these types of applications and devices to assure end user
quality of service. It is the objective of this draft to deliver a
monitoring solution for such environment by extending the RMON family
of specifications [RFC2819]. This memo extends the RMON family of
specifications to allow real-time QoS Monitoring of various
applications that run on these types of end-devices and allows such
information to be integrated with the 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 draft. 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
RMON WG Expires August 2004 [Page 2]
INTERNET DRAFT RAQMON Framework February 2004
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 Delay, Jitter, Packet Loss, the type of codec used in a
call. Behavior of network protocols like RSVP, explicit tags in
DiffServ or IEEE 802.1p/Q, 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
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 RAQMON Protocol Data Unit (PDU) exchanged between RAQMON
entities using existing Internet Transport Protocols such as RTCP and
SNMP.
b. 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.
RMON WG Expires August 2004 [Page 3]
INTERNET DRAFT RAQMON Framework February 2004
This memo provides the RAQMON functional architecture, RAQMON entity
definitions, behavior of various RAQMON entities and definition of
various parameters carried within the RAQMON PDU.
The RAQMON PDU [RAQMON-PDU] memo provides definitions of syntactical
PDU structure and use case scenarios of transmission of such PDUs
over the Real-Time Transport Control Protocol (RTCP) and the Simple
Network Management Protocol (SNMP).
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.
+----------------------+ +---------------------------+
| IP End-Device | | IP End-Device >----+ |
|+--------------------+| |+--------------------+ | |
|| APPLICATION || || APPLICATION | | |
|| -Voice over IP <----(1)----> -Voice over IP >- + | |
|| -Instant Messaging|| || -Instant Messaging| | 3 |
|| -Email || || -Email | 2 | |
|+--------------------+| |+--------------------+ | | |
| | | | | |
| | | +------------------+ | | |
RMON WG Expires August 2004 [Page 4]
INTERNET DRAFT RAQMON Framework February 2004
+----------------------+ | |RAQMON Data Source|<-+ | |
| | (RDS) |<---+ |
| +------------------+ |
+-----------|---------------+
|
(4) RAQMON PDU transported
over RTCP APP Packet or SNMP Notifications
|
+----------------------------+
| |
|/ |/
+------------------+ +------------------+ +-------------+
|RAQMON Report | .. |RAQMON Report | |Network Mngmt|
|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.
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)
A RAQMON Data Source (RDS) is a source of data for monitoring
purposes. The RDS monitoring function is performed in real-time
RMON WG Expires August 2004 [Page 5]
INTERNET DRAFT RAQMON Framework February 2004
during each communication session. The RDS and RRC 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. It is further envisioned
that a RDS residing in an IP end device is cable of gathering reports
from multiple applications residing in that device and of sending out
compound QoS reports associated with multiple communication sessions
at a given moment. Examples are a conference bridge hosting several
different conference calls or a two party video call consisting of
audio/video sessions. In each case a 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.
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
than 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.
2.2 RAQMON Report Collector (RRC)
RMON WG Expires August 2004 [Page 6]
INTERNET DRAFT RAQMON Framework February 2004
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.3 RAQMON Protocol Data Unit (PDU)
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. Either RTCP or SNMP is used
to carry RAQMON PDU between RDSs and RRCs. So any transport layer
protocol that supports RTCP and SNMP such as TCP, UDP, DCCP can be
used to carry RAQMON PDUs.
Though transmitted as one Protocol Data Unit, the RAQMON PDU is
functionally divided into two different parts namely the Basic Part
and the Application Specific Extensions required for vendor specific
extensions. Both functional parts trail behind SMI Network Management
Private Enterprise Codes and are currently maintained by IANA at
http://www.iana.org/assignments/enterprise-numbers.
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 a RDS report built only of a sub-set of the
parameters listed in Section 5.
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
as Type Length Value (TLV) triplets or varbinds 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
RMON WG Expires August 2004 [Page 7]
INTERNET DRAFT RAQMON Framework February 2004
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 a RDS MUST send a RAQMON NULL
PDU. A NULL PDU is a RAQMON PDU containing ALL NULL values (i.e.
nothing to report) and a syntactical definition of NULL PDU
specification is available in [RAQMON-PDU].
Though the RAQMON Framework expects PDUs to operate in lossy
networks, retransmission is not included in the RAQMON framework, to
keep the design simple. If retransmission is a necessity RAQMON MAY
operate over transport protocols like TCP. In order to ensure that
the RRCs know the state of reporting, the following measures SHOULD
be taken to deal with the potential loss of NULL PDUs:
- Lower level indications such as RTCP BYE packets from RDS to RRC to
indicate the end of a reporting session.
- 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.
Further specification of the RAQMON PDUs can be found in [RAQMON-
PDU].
2.4 RDS/RRC Network Transport Protocol Interface
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 memo [RAQMON-PDU] defines the structure of the RAQMON PDU and
describes how the PDU is transported over existing application level
protocols like the Real-Time Transport Control Protocol (RTCP) and
the Simple Network Management Protocol (SNMP).
Carrying RAQMON PDUs over existing protocols like RTCP or SNMP has
the following advantages:
1. Lightweight - RDSs will be implemented on low powered embedded
devices with limited device resources.
2. Scalable - since RRCs need to interact with a very large number
RMON WG Expires August 2004 [Page 8]
INTERNET DRAFT RAQMON Framework February 2004
of RDSs, scalability of the transport protocol is a requirement.
3. Congestion safety - as per [RFC2914]
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 a requirement - met by RTCP and SNMP.
5. NAT Friendly - Comply with [RFC3235], so that an RDS could
communicate with an RRC through a Firewall/Network Address
Translation device.
Though RAQMON PDUs can be transported over RTCP as well as SNMP, it
is not mandatory for RDSs to support both transport protocol
interfaces. However, since RRCs are computationally resourceful, it
is RECOMMENDED that RRCs support both RTCP and SNMP interfaces to
accommodate RDSs running either protocol. Choice of an appropriate
network transport protocol (i.e. TCP or UDP or DCCP) also depends
upon the specific implementation as it fits the deployment need.
Readers should note that if SNMP is used to carry RAQMON PDU,
practical deployments may dictate UDP as the only viable choice.
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 of the RAQAMON
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. The framing
mechanism is not defined in this document. Carrying several RAQMON
packets in one network or transport packet reduces header overhead.
The following sections describe the usage of RTCP and SNMP to carry
RAQMON PDU:
2.4.1 Usage of RTCP to carry RAQMON PDUs
The RAQMON Framework includes a unidirectional transmission of PDUs
with RDS/RRC pairs. The protocol data units are mapped to an
existing transport protocol such as the Real-Time Transport Control
Protocol (RTCP).
To accommodate RTCP as the RAQMON PDU Transport, the RRC-RTCP
interface needs to minimally recognize RTCP APP reports as defined in
[RFC3550].
+ During a monitored communication session, the RDSs will send a
RAQMON PDU to a target RRC as a payload of a RTCP APP Packet
RMON WG Expires August 2004 [Page 9]
INTERNET DRAFT RAQMON Framework February 2004
[RFRC3550].
The RAQMON PDU transport over RTCP constitutes a simple one-way send
protocol. The transport protocol used to carry RAQMON PDUs would have
effects on the overall operation and deployment of the RAQMON
Framework. It should be noted that RAQMON is designed to operate over
a lossy network and retransmission, error detection or recovery are
not supported within the RAQMON framework.
+ Session termination SHOULD be indicated in RTCP by sending an RTCP
BYE packet as defined in Section 2.3.
+ IANA Port XXXX has been reserved as a default port to carry RAQMON
PDUs over RTCP - see Section 10 in [RAQMON-PDU].
2.4.2 SNMP Notifications as the RDS/RRC Network Transport Protocol
SNMP Notifications are used to transport RAQMON PDUs in the following
manner:
+ RDSs embed the RAQMON PDU information in SNMP Notifications to
report RAQMON information. The MIB used to define the mapping of the
RAQMON PDU information to SNMP is defined in [RAQMON-PDU].
+ 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.
+ RRCs MUST send an SNMP INFORM Response for each associated SNMP
INFORM originated by the RDS, as defined in [RFC3416].
However sending out acknowledgements from RRCs to RDSs can create
bottleneck as additional RDS load is created, specially when the RRCs
will be receving many Inform PDUs from many RRCs. As an alternate,
SNMP Traps could be used to avoid such ACKs; however that diminishes
any possibility of using SNMP in a congestion-safe manner in
practical deployments. Congestion safety related issues are discussed
in section 3.0 of this memo.
+ The RDS may ignore the SNMP INFORM Responses.
+ The SNMP Notifications transport for RAQMON PDUs will use the
standard UDP port 162 used for SNMP Notifications.
Using SNMP INFORM PDUs for RAQMON has all the advantages offered by a
well-known protocol like SNMP. Privacy and authentication issues
related to RAQMON are "mostly" covered by SNMP framework. One of the
drawbacks of using SNMP is the associated overhead SNMP puts on low-
RMON WG Expires August 2004 [Page 10]
INTERNET DRAFT RAQMON Framework February 2004
powered RDSs, for instance - BER encoding, SNMP INFORM Responses sent
from RRC to RDS etc. As a result added flexibility of the proposed
RAQMON Framework could be constrained in a real life deployment
scenario depending on the use case.
2.5 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 can use one or more of the following mechanisms to gain access
to configuration parameters:
- RDS acts as a tftp client and downloads text scripts to read the
parameters - RDS acts as a 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.
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 SCTP. If this is not feasible, it may be necessary to
fall back on UDP. A RAQMON PDU from RDS to RRC either over RTCP or
SNMP allows the use of 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, either SNMP or RTCP over TCP are not commonly
practiced in practical deployments. Moreover there are legitimate
RMON WG Expires August 2004 [Page 11]
INTERNET DRAFT RAQMON Framework February 2004
places where UDP appears to be quite useful such as tiny mobile
phones, pagers, various other hand held computing devices, RAQMON
Report Collectors where extremely high-volume RDSs connect over
dedicated networks, etc.
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
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 a 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 a 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
RMON WG Expires August 2004 [Page 12]
INTERNET DRAFT RAQMON Framework February 2004
significantly reducing the maximum throughput, as transmission occurs
in only one direction at a time and there is at least a 2xRTT 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, 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.
Retransmission timers with back offs will not be useful if RAQMON
PDUs are transported over RTCP/UDP; RRCs do not provide any
acknowledgement that RDS can rely on.
3. By restricting transmission to 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, a 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, a RDS MAY also
send parameters to RRC over multiple RAQMON PDUs but identify them as
the same RAQMON reporting session with exactly the same 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 (e.g., probe-based, client-
based, synthetic-transaction, etc.). This specification does not
RMON WG Expires August 2004 [Page 13]
INTERNET DRAFT RAQMON Framework February 2004
mandate a particular methodology - it is open to any methodology that
meets the minimum requirements. Conformance to this specification
requires that the collected data match the semantics described
herein. However it is recommended that vendors use IETF defined and
ITU specified methodologies to measure parameters when possible.
5. A Simple list of Metrics pre-defined in the BASIC PDU
The BASIC part of the RAQMON PDU provides a list of pre-defined
parameters frequently used by the applications to indicate 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 varbind
list. Such extensions should be managed by the vendors independently
and published for wider interoperability. For example one such
extension can be derived out of subset of RTCP extended reports
[RFC3611] to further extend the voice "media" related information
already provided in the BASIC part of the RAQMON PDU.
Applications are not required to report all the parameters mentioned
in the section but should rather have the flexibility to report a
subset of these parameters as appropriate for 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 application
optional parameters that that RDSs report as needed. The definitions
presented here are meant to provide guidance to implementers, and
IETF metrics definitions are reference for each of the specific
metrics. Application developers should choose the metrics specific to
their application needs. Syntactical representations of the
parameters identified here, are standardized 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 [RFC1597].
It is expected that a Data Source Address (DA) would remain constant
within a communication session.
RMON WG Expires August 2004 [Page 14]
INTERNET DRAFT RAQMON Framework February 2004
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 [RFC1597].
5.3 Data Source Name (DN)
The DN item could be of various formats as needed by the application.
A few instances of DN could include but are not restricted to
* "user@host", or "host" if a user name is not available as on
single-user systems. For both 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]. The DN value is expected to remain constant for the
duration of a session. 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.
It is expected that a Data Source Name (DN) will remain constant
within a communication session.
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
applications should fill in the other party's name that they are
communicating with as a Receiver Name.
5.5 Data Source Device Port Used
This parameter indicates the source port used by the application for
a particular session or sub-session in communication. Examples of
ports include TCP Ports, or UDP Ports used by communication
application protocols such as SIP, SIMPLE, H.323, RTP, HTTP, etc.
RMON WG Expires August 2004 [Page 15]
INTERNET DRAFT RAQMON Framework February 2004
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
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].
5.8 Session Setup Delay
The 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 since the last DTMF
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 an INVITE
generated from a User Agent and the reception of a 200 OK. 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 a particular
application need it is left to the implementers to define as
appropriate.
5.9 Session Duration
This parameter describes how long a session or a sub-session lasted.
This parameter is application context sensitive. For example a VoIP
Call Session Duration can be measured as the elapsed time between the
establishment of the call pick up to call termination.
5.10 Session Setup Status
This parameter is intended to report communication status of a
session. This field is used to describe appropriate communication
session states e.g. Call Progressing, Call Established successfully,
"trying", "ringing", "re-trying", RSVP reservation failed, and
various other status. This information could be used by network
management systems to calculate parameters such as call success rate,
call failure rate etc., or a debugging tool that captures the status
of a call-setup as soon as a call is established.
RMON WG Expires August 2004 [Page 16]
INTERNET DRAFT RAQMON Framework February 2004
5.11 Round Trip End-to-End Delay
Round Trip End-to-End Delay [RFC 3550], [RFC2681], [RFC2679] 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 such
as Voice over IP, Video over IP, Fax over IP etc.
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, and coding/decoding delays be added
to network transport delay to report end-to-end delay.
The End-to-End delay of underlying transport network can be measured
using various methodologies as described in [RFC2681], [RFC2679],
[RFC 3550] depending on the application needs and left up to the
implementers to select the appropriate IETF and ITU methodologies to
measure end-to-end Delays appropriate for a specific application.
5.12 One Way End-to-End Delay
The One Way End-to-End Delay [RFC2679] allows applications to reflect
the end-to-end delay as experienced by the source application to
reach the destination application. One Way Delay measurements
identified by the IPPM Working Group [RFC2679] could be used to
measure one way end-to-end delay. The need for such a metrics is
derived from the fact that the path from a source to a destination
may be different than 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 versus Packet-over-SONET).
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
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.
RMON WG Expires August 2004 [Page 17]
INTERNET DRAFT RAQMON Framework February 2004
In quality-of-service (QoS) enabled networks, provisioning in one
direction may be radically different than provisioning in the reverse
direction, and thus the QoS guarantees differ. Measuring the paths
independently allows the verification of both guarantees.
It is outside the scope of this document to say precisely which
applications would use one way end-to-end delay. One way end-to-end
delay is expressed in the same units as round trip end-to-end Delay.
5.13 Jitter
The variation in packet delay is called "jitter" [RFC 3393]. The
definition of jitter is context sensitive and measurement specific.
One important use of jitter is the sizing of play-out buffers for
applications requiring the regular delivery of packets (for example,
voice or video play-out). Other uses of a delay variation metric are,
for example, 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 process at a given link or a combination of
links. [RFC 3393] provides guidance to several absolute jitter
parameters.
An alternate, but related, way of computing an estimate of jitter is
given in RFC 3550. The selection function there is implicitly
consecutive packet pairs, and the "jitter estimate" is computed by
taking the absolute values of the ipdv sequence (as defined in RFC
3393) and applying an exponential filter with parameter 1/16 to
generate the estimate (i.e., j_new = 15/16* j_old + 1/16*j_new).
Inter-arrival jitter provides a short-term measure of congestion [RFC
3550]. The jitter measure indicates congestion before it leads to
packet loss.
5.14 Total Number of Application Packets Received
The total 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. a RDS
within an application session will report number of application
packet 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
RMON WG Expires August 2004 [Page 18]
INTERNET DRAFT RAQMON Framework February 2004
counter represents the number of signaling session related packets
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 [RFC 3550] to count RTP frames can be one of the ways
to measure media related application packet received, applicable for
the scenarios described above.
5.15 Total Number of Application Packets Sent
The total number of 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 i.e. signaling setup, media establishment,
session termination states etc.
5.16 Total number of Application Octets Received
The total number of 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 metrics could be measured
in different ways, including the methodology described by [RFC 3550].
5.17 Total number of Application Octets Sent
The total number of 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. Similar to total number of
octets received. This metrics could be measured in different ways,
including the methodology described by [RFC 3550].
5.18 Cumulative Application Packet Loss
Packet loss tracks persistent congestion while jitter measures tracks
transient congestion. Packet loss metric SHOULD indicate loss
associated to 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],
RMON WG Expires August 2004 [Page 19]
INTERNET DRAFT RAQMON Framework February 2004
[RFC 3550] and local device level packet losses should to be captured
by the local device specific algorithms.
5.19 Packet loss in Fraction
Packet loss in Fraction represents packet loss as defined above but
expressed in percentage.
5.20 Source Payload Type
The source payload type defines 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 document follows the definition of
Payload Type (PT) as in [RFC1890]. To give an example, if an
application ought to indicate that the Source Payload Type used for a
session were PCMA, source payload field for the respective session
ought to be 8.
5.21 Destination Payload Type
Destination payload type defines payload formats (e.g. media
encodings) as sent by the other communicating party 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) as in [RFC1890]. To give
an example, if an application ought to indicate that the source
payload type used for a session were PCMA, Source Payload Field for
the respective session ought to be 8.
5.22 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 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 RDS
to prioritize these packets in the Local Area Networks environment.
5.23 Source TOS/DSCP Value
Various Layer 3 technologies are in place to prioritize certain types
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] are using
RMON WG Expires August 2004 [Page 20]
INTERNET DRAFT RAQMON Framework February 2004
the TOS octet in IPv4, while the Traffic class Octet is used to
prioritize traffic in Ipv6. Source Layer 3 RAQMON field indicates
appropriate Layer 3 values used by the Data Source to prioritize
these packets.
5.24 Destination Layer 2 Priority
The Destination Layer 2 RAQMON indicates Layer 2 values used by the
communication receiver to prioritize these 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 if the destination has used any Layer 2 technologies like
IEEE 802.1p/Q or priority queuing etc.
5.25 Destination TOS/DSCP Value
The Destination Layer 3 RAQMON field indicates appropriate Layer 3
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 if destination has used any Layer 3 technologies
like IP Precedence [RFC791], Type Of Service (TOS) [RFC1349],
[RFC1812] or more recent technologies like Differentiated Service
[RFC2474], [RFC2475].
5.26 CPU Utilization in Fraction
This parameter captures the IP Device CPU usage rate to indicate the
current state of the local IP Device resource, which may have very
critical implications for QoS of an end device. e.g. x % CPU busy
averaged over session duration.
5.27 Memory Utilization in Fraction
This parameter captures the IP Device Memory usage rate to indicate
current state of the local IP Device resource, which may have very
critical implications for QoS of an end device. e.g. y % memory
utilized over session duration.
5.28 Application Name/version
The Application Name/version parameter gives the name and possibly
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
RMON WG Expires August 2004 [Page 21]
INTERNET DRAFT RAQMON Framework February 2004
Within the RAQMON Framework, since RRCs are computationally
resourceful, various aggregation functions are performed by the RRCs
while RDSs are not burdened by statistical data processing such as
computation of min/max/average/standard deviation etc.
The RAQMON MIB is designed to provide minimal aggregations of various
RAQMON parameters defined in section 5.0. The RAQMON MIB is designed
not to provide extensive aggregations like the APM MIB [29] or the
TPM MIB [30] and one should use APM and TPM MIBs to aggregate
parameters based on protocols (e.g. performance of HTTP, RTP) or
based on applications (e.g. performance of VoIP, Video Applications).
In the RAQMON MIB, aggregation can be performed only on specific
RAQMON metrics parameters. Aggregation always results in statistics
Mean/Min/Max values.
The following aggregation definitions are used in this document:
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 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.
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.
Such storage space optimization can be performed in the following
ways:
1. Store data in the MIB only at the end of a communication session
RMON WG Expires August 2004 [Page 22]
INTERNET DRAFT RAQMON Framework February 2004
(i.e. a NULL PDU or an RTCP BYE 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 a few scalars will be used to
store a metric.
2. A time-based algorithm that aggregates 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 an 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 the
usage of these policies is left to the application developer's
discretion.
8. Normative References
[RFC3416] Presuhn, R., "An Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks", STD 61, RFC
3416, December 2002.
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000.
[RFC 3550] Henning Schulzrinne, S. Casner, R. Frederick, and
V. Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFRC 3550, July 2003.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
9. 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.
RMON WG Expires August 2004 [Page 23]
INTERNET DRAFT RAQMON Framework February 2004
[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
Loss Metric for IPPM", RFC 2680, September 1999
[RFC 3393] C.Demichelis and P.Chimento, "IP Packet Delay Variation Metric
for IP Performance Metrics (IPPM)", RFC 3393, November 2002
[RFC2681] G. Almes, S.kalidindi 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
[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
RMON WG Expires August 2004 [Page 24]
INTERNET DRAFT RAQMON Framework February 2004
[RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and W.Weiss,
"An Architecture for Differentiated Services", RFC2475,
December 1998
[RFC3235] D. Senie, "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC3235, January 2002
[RFC3611] T. Friedman, R. Caceres and A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", November 2003
[RAQMON-PDU] A. Siddiqui, D.Romascanu, and E. Golovinsky,
"Protocol Data Units for Real-time Application Quality of
Service Monitoring (RAQMON)", Internet-Draft,
draft-ietf-raqmon-pdu-05.txt, February 2003
[RAQMON-MIB] 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-03.txt,
November 2003
[SRTCP] Bauer, McGrew, Oran, Blom, Carrara, Naslund, Norrman, "Secure
Real Time Transport Protocol", Internet Draft,
draft-ietf-avt-srtp-06.txt, April 2003
10. 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.
11. Security Considerations
RMON WG Expires August 2004 [Page 25]
INTERNET DRAFT RAQMON Framework February 2004
11.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 possible exploits of RAQMON payload. A discussion
of RAQMON specific threat model is discussed within this memo. A
series of security considerations are also recommended in this memo
as well as in other RAQMON memos when appropriate. Possible exploits
of RAQMON payloads can fall within the class of
1. Unauthorized examination of sensitive information in the payload
(in transit)
2. Unauthorized modification of payload contents (in transit)
leading to:
a. Redirection of one RAQMON reporting session to another
destined to the same RRC
b. Mismapping of RAQMON sessions
c. Various forms of session-level DoS attacks
d. DoS by way of incorrect and modified RAQMON parameter values
and statistics
e. Invalid timestamps
3. Malforming payload - leading to exploit of potential
implementation weaknesses to compromise RRC.
4. Unauthorized disclosure of sensitive data (in application PDU's)
leading to threat to confidentiality
Since no assumptions can be made about the transport media, threats
based on unauthorized disclosure and modification of payload and
headers will have to be assumed.
11.2 The RAQMON Security Requirements & Assumptions
In order to preserve the sanity and integrity of the RAQMON PDU
against such classes of threats RAQMON model must provide for
cryptographically strong security services.
It is, therefore, 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
RMON WG Expires August 2004 [Page 26]
INTERNET DRAFT RAQMON Framework February 2004
PDU was originated by which ever RDS claims to have sent it.
2. Privacy - RAQMON information includes identification of the
parties participating in a communication session. RAQMON framework
should be able to provide protection from eavesdropping, 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 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 such duration.
4. NAT and Firewall Friendly Design - Presence of 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 provide IP addresses in the RAQMON PDU. Another way
to avoid this problem is by supporting NAT-aware RAQMON Application
Layer Gateways (ALGs) to translate IP addresses in RAQMON PDUs.
However, this will not be possible when RAQMON PDUs are encrypted
end-to-end.
11.3 RAQMON Security Model
The RAQMON architecture provides for using a wide range of transport
protocols most of which also carry an associable secure mode of
operation. There are advantages to relying on the security provided
at the transport protocol layer.
1. Besides affording transport protocol level security, the payload
is protected by available end-to-end authentication,
confidentiality, message integrity and replay protection services.
2. Good cryptographic security protocol always has an associated
key management protocol. Use of transport protocol security relies
on its key management.
3. When transport protocol security is already enabled between RDS
& RRC, additional encryption and message authentication is avoided
at application level.
RMON WG Expires August 2004 [Page 27]
INTERNET DRAFT RAQMON Framework February 2004
However, there are also shortcomings to be noted in relying on
transport protocol security.
1. When session-level isolation is required of different RAQMON
sessions between the same RDS-RRC pair it will be required to open
separate transport protocol instances. Such cases, however, may be
rare.
2. When security services are not self-contained within the RAQMON
framework, the absence of transport or lower protocol security
implies absence of RAQMON security.
3. When full transport protocol implementations are unavailable in
either RRC or RDS, such as when using SNMP or RTCP, secure mode
implementations such as SNMPv3 or SRTCP will be unavailable.
11.4 Use of SNMP as the transport protocol
RAQMON uses SNMP to transport RAQMON PDUs over SNMP, and defines an
SNMP MIB to provide the PDU encoding. Another MIB module is defined
to retrieve RAQMON information from the collectors. There are a
number of management objects defined in these MIB modules with a MAX-
ACCESS clause of read-write. 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.
The other RAQMON documents [RAQMON-PDU, RAQMON-MIB] define in their
Security Considerations sections the objects whose setting to
incorrect values can result in improper operation, excessive number
of notifications, or may be considered sensitive or vulnerable in
some network environments.
It is thus important to control even GET and/or NOTIFY access to
these objects and possibly to even encrypt their values when sending
them over the network via SNMP.
SNMP versions prior to SNMPv3 did not include adequate security.
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 module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
RMON WG Expires August 2004 [Page 28]
INTERNET DRAFT RAQMON Framework February 2004
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only of those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
11.5 Use of RTCP as Transport
In using RTCP as a transport, it is customary for RDSs as endpoints
to have RTCP protocol implementation with their communicating peers.
Thus, e.g., an IP phone endpoint may be communicating to its peer or
media gateway over RTCP.
The RTCP protocol security is defined in Secure RTCP [SRTCP], a
draft-in-progress. When the communicating parties are the RDS & RRC
as well, the RAQMON stream will work within the existing framework of
[SRTCP]. It must be noted, however, that the two SRTCP sessions will
need to be different and be using separate sets of keys and re-key
independently. However, they may share the same master key.
However, in case the target RRC or RDS are different than either
party, the RDS and/or RRC will need to implement SRTCP in order to
secure the protocol.
12. Acknowledgements
The authors would like to thank Mahalingam Mani, Steven Waldbusser,
Alan Clark, Robert Cole, and Itai Zilbershtein for interesting
discussions and various direct contributions in this problem space.
13. 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, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
RMON WG Expires August 2004 [Page 29]
INTERNET DRAFT RAQMON Framework February 2004
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.
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 August 2004 [Page 30]
