Internet Draft Anwar Siddiqui
Avaya Inc.
Dan Romascanu
Avaya Inc.
Eugene Golovinsky
BMC Software
9 June 2003
Real-time Application Quality of Service
Monitoring (RAQMON) Framework
<draft-ietf-rmonmib-raqmon-framework-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
There is a need to extend the RMON framework to monitor end devices
such as IP Phones, Pagers, Instant Message Clients, Mobile Phones,
and various other Hand held computing devices. This memo extends
RMON Framework to allow Real-time QoS Monitoring of various
Applications that run on these types of end devices and allows such
information be integrated with RMON Framework via SNMP.
Distribution of this memo is unlimited.
Table of Contents
RMON WG Expires December 2003 [Page 1]
INTERNET DRAFT RAQMON Framework June 2003
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 14
5 A Simple list of Metrics pre-defined in BASIC PDU 14
6 Report Aggregation and Statistical Data processing 20
7 Keeping Historical Data and Storage 21
8 Normative References 21
9 Informative References 22
10 Intellectual Property 23
11 Security Considerations 24
12 IANA Considerations 27
13 Acknowledgements 27
14 Authors' Addresses 28
A Full Copyright Statement 28
1. Introduction
With the growth of Internet and advancement of 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 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 framework [RFC2819]. This
memo extends the RMON Framework to allow Real-time QoS Monitoring of
various Applications that run on these types of end-devices and
allows such information be integrated with RMON Framework via SNMP.
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 RMON Framework can report application level QoS statistics in
Realtime using 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.
User experience of an application running on an IP end device has lot
to do with the type of application a 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 applications level transactions and available network and
RMON WG Expires December 2003 [Page 2]
INTERNET DRAFT RAQMON Framework June 2003
host resources. For example, End-to-End user experience of a Voice
over IP (VoIP) call depends on Total Time required to set up the call
as much as media related performance such as End-to-End Delay,
Jitter, Packet Loss, the Type of codec used in a call. Network
protocols like DiffServ, RSVP, IEEE 802.1p/Q tags along with
available host resources such as Device CPU or memory utilized by
other applications while the call is ongoing also influences such
performance of a VoIP call.
An 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. Real-Time Application QoS
Monitoring (RAQMON) Framework offers a mechanism to report end-to-end
QoS experience appropriate for a specific application context by
providing mechanisms to report a sub set of metrics from a pre-
defined list metrics.
In order to facilitate 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 an application context.
ii. "IP end device" specific parameters during a session e.g. CPU
Usage, memory usage
iii. "Transport network" specific parameter during a session (e.g.
End-to-End Delay, One Way Delay, Jitter, Packet loss etc.
At any given point, it's the applications at these devices that can
correlate such diverse data and report end-to-end performance. Real-
Time Application QoS Monitoring (RAQMON) Framework specified in this
memo offers a mechanism to report such end-to-end QoS view and
integrate such view to RMON Framework. In Particular, 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 RMON MIB Modules for use with network management protocols in the
Internet community.
This memo provides RAQMON functional architecture, RAQMON entity
definitions, behavior of various RAQMON entities and definition of
various parameters carried within RAQMON PDU.
RMON WG Expires December 2003 [Page 3]
INTERNET DRAFT RAQMON Framework June 2003
The RAQMON QoS PDU [RAQMON-PDU] memo provides definitions of
syntactical PDU structure and use case scenarios of transmission of
such PDU over Real-time Transport Control Protocol (RTCP) and Simple
Network Management Protocol (SNMP).
The RAQMON MIB [RAQMON-MIB] memo describes the Management Information
Base (MIB) for use with network management protocol in the Internet
community. The document proposes an extension to the Remote
Monitoring MIB [RFC2819] to accommodate RAQMON solution.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. RAQMON Functional Architecture
RAQMON Framework extends the architecture created in the RMON MIB
[RFC2819] by providing application performance 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 PC, etc. are envisioned to act as RDSs within
RAQMON Framework.
+----------------------+ +---------------------------+
| IP End-Device | | IP End-Device >----+ |
|+--------------------+| |+--------------------+ | |
|| APPLICATION || || APPLICATION | | |
|| -Voice over IP <----(1)----> -Voice over IP >- + | |
|| -Instant Messaging|| || -Instant Messaging| | 3 |
|| -Email || || -Email | 2 | |
|+--------------------+| |+--------------------+ | | |
| | | | | |
| | | +------------------+ | | |
+----------------------+ | |RAQMON Data Source|<-+ | |
| | (RDS) |<---+ |
| +------------------+ |
+-----------|---------------+
RMON WG Expires December 2003 [Page 4]
INTERNET DRAFT RAQMON Framework June 2003
|
(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 interface (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 it, and stores such information appropriately. A
RAQMON Report Collector (RRC) is envisioned to be a network server,
serving an administrative domain defined by the network
administrator. RRC component of the RAQMON architecture is envisioned
to be computationally resourceful.
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 to Network Management
Applications.
2.1 RAQMON Data Source (RDS)
A RAQMON Data Source (RDS) is a source of data for monitoring
purposes. RDS monitoring function is performed in real-time during
each communication session. RDS and RRC entity captures QoS
attributes of such communication session and report that within a
RAQMON "reporting session".
A RDS is primarily responsible for abstracting IP end-devices and
RMON WG Expires December 2003 [Page 5]
INTERNET DRAFT RAQMON Framework June 2003
applications within 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-
device, the design of RDS element is optimized towards that. 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 an RDS residing in an IP end Device is cable of gathering report
from multiple applications residing in that device and send out
compound QoS reports associated to multiple communication session at
a given moment. For example a conference bridge hosting few 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 to audio and video
session or sub-reports for each conference call.
RDSs use a PUSH mechanism to report QoS parameters. While the
applications running on the RDS decide 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 RDS to RRC is controlled by the
Applications' administrative domain policy. While this mechanism
provides flexibility to gather a detailed end-to-end experience
required by the 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 QoS
parameters associated to a communication session as perceived by the
reporting RDS. For example if two IP Phone users namely Alice and
John are involved in a communication session, end-to-end delay
experienced by IP Phone user Alice could be different than IP Phone
user John for variety of reasons. Hence a report from Alice's IP
Phone RDS represents QoS performance of that call as perceived by
Alice.
2.2 RAQMON Report Collector (RRC)
A RAQMON Report Collector (RRC) receives RAQMON PDUs from multiple
RDSs, analyzes and stores it 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
RMON WG Expires December 2003 [Page 6]
INTERNET DRAFT RAQMON Framework June 2003
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 (i.e.
"Name" and "Value" pair) commonly 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. Either TCP or UDP could be used as a transport
layer protocol within the protocol stack.
Though transmitted as one Protocol Data Unit, the RAQMON PDU is
functionally divided into two different parts namely Basic Part and
Application specific extensions required for vendor specific
extensions. Both functional parts trail behind SMI Network Management
Private Enterprise Codes and currently maintained by IANA at
http://www.iana.org/assignments/enterprise-numbers.
The BASIC Part of 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 (a.k.a. "Name") from a pre-defined list of QoS
parameters defined in table 1 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 table 1 by identifying appropriate "Name",
"Value" pairs to the RDS.
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
the application vendor.
Though RDSs and RRCs are designed to be mostly stateless for an
entire reporting session, the framework would require an indication
for the end of the reporting MAY send a RAQMON PDU with all NULL
RMON WG Expires December 2003 [Page 7]
INTERNET DRAFT RAQMON Framework June 2003
values to indicate the end of the reporting session to the RRC. 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 RAQMON Framework expects RAQMON PDUs to operate in lossy
networks, retransmission is not included in RAQMON design as it is
viewed as transport layer capability. However not having
retransmission and acknowledgements between RDS/RRC pair not only
make RAQMON Framework suffer from loss of PDUs, but it complicates
the problem further in the case RAQMON NULL PDUs since NULL PDUs
define end of reporting session. So to avoid having RRCs not knowing
the state of reporting, following measures are taken to deal with the
loss of NULL PDU gracefully, in case NULL PDUs are lost:
- RRCs should also use other lower level indications such as RRCs
receiving an RTCP BYE Packet from a RDS to interpret "end or
reporting session" which will help RRCs.
- RRCs must use session time out mechanisms to "assume" end of
reporting for RDSs which has been out of reporting for a reasonable
duration of time. Such time out parameters should be a configurable
parameter in vendor implementations and should be assigned during
deployment.
Further specification of RAQMON PDUs can be found in [RAQMON-PDU]
memo.
2.4 RDS/RRC Network Transport Protocol Interface
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 Real-time Transport Control Protocol (RTCP) and Simple
Network Management Protocol (SNMP).
Carrying RAQMON PDUs over existing protocols like RTCP or SNMP has
following advantages:
1. Lightweight - RDSs will be implemented on low powered embedded
devices with limited device resources.
RMON WG Expires December 2003 [Page 8]
INTERNET DRAFT RAQMON Framework June 2003
2. Scalable - since RRCs need to interact with a very large number
of RDSs, scalability of transport protocol is a requirement.
3. 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.
4. NAT Friendly - Comply with [RFC3235], so that an RDS could
communicate with an RRC through a Firewall/Network Address
Translation device.
Though RAQMON PDU can be transported over RTCP as well as SNMP, it is
not mandatory for RDSs to support both transport protocols
interfaces. However, since RRCs are computationally resourceful, it
is required 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) is also left upon the
specific implementation as it fits the deployment need. Readers
should note that if SNMP is used to carry RAQMON PDU, practical
deployment may dictate UDP as the only viable choice.
In Future, if RAQMON PDUs are to be carried in an underlying protocol
that provides the abstraction of a continuous octet stream rather
than messages (packets), an encapsulation of the RAQAMON packets must
be defined to provide a framing mechanism. Framing is also needed if
the underlying protocol may contain padding so that the extent of the
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 section describes the usage of RTCP and SNMP to carry
RAQMON PDU:
2.4.1 Usage of RTCP to carry RAQMON PDUs
The RAQMON Framework is comprised of a unidirectional exchange of
PDUs between RDS/RRC pair. The protocol data units are mapped to an
existing transport protocol such as Real-time Transport Control
Protocol (RTCP).
To accommodate RTCP as RAQMON PDU Transport, the RRC-RTCP interface
needs to minimally recognize RTCP APP reports as defined in RFC 1889.
+ During a monitored communication session, the RDSs will send a
RAQMON PDU to a target RRC as a payload to RTCP APP Packet [RFC
1889].
RMON WG Expires December 2003 [Page 9]
INTERNET DRAFT RAQMON Framework June 2003
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 RAQMON Framework.
The RDSs will not be capable of inferring successful delivery of PDUs
over a lossy network since the RAQMON PDU is expected to operate in
lossy network environments. However if required, RAQMON PDUs can be
carried over RTCP/TCP as oppose to RTCP/UDP to ensure transport
reliability.
+ The RAQMON reporting session between RDS and RRC is mostly
stateless.
If RTCP is used as transport, RDSs should also send a RTCP BYE Packet
after having sent a RAQMON NULL PDU within RTCP APP Packet to
indicate the end of a reporting session. Such measures will increase
the probability of reaching a RRC in a lossy network environment.
+ RRCs should implement session timers to timeout a RDS that has not
sent a report within that timeout period. In the case of a lossy
network (e.g. RAQMON PDU over RTCP/UDP), such measures will ensure
that RRCs do not wait for ever for another PDU from RDS which might
have been lost in the network.
RRCs, along with unique session IDs, could also use specific fields
within a RAQMON PDU like the 6-octet MAC address, the IPv4/IPv6
Address, the Application name or an address to correlate a received
RAQMON PDU to an ongoing session.
+ IANA Port XXXX has been reserved as a default port to carry RAQMON
PDU over RTCP.
2.4.2 SNMP Notifications as RDS/RRC Network Transport Protocol
SNMP Notifications (Trap or Inform) PDUs are used to transport RAQMON
PDUs in the following way:
+ RDSs embed the RAQMON PDU information in SNMP Notifications to
report RAQMON statistics. The MIB used to define the mapping of the
RAQMON PDU information in 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 implemented as an SNMP manager, must send an SNMP INFORM
Response could for each associated SNMP INFORM originated by the RDS.
However sending out Acknowledgements from RRCs to RDSs can create
RMON WG Expires December 2003 [Page 10]
INTERNET DRAFT RAQMON Framework June 2003
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 diimishes
any possibility of using SNMP in 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-
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 real life deployment
scenario depending on the use case.
2.5 Configuring RAQMON Data Sources
In order to report statistics to RAQMON Report Collector, RDSs will
need to be configured with the following parameters:
1. The time interval between RAQMON PDUs
2. The RRC 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 address
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 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,
RMON WG Expires December 2003 [Page 11]
INTERNET DRAFT RAQMON Framework June 2003
including UDP 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 to
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 problem might be to deprecate UDP entirely for
RAQMON. Though RAQMON PDU over RTCP can be transported over TCP, SNMP
over TCP is not commonly practiced in practical deployment. Moreover
there are legitimate 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
connecting 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.
It should be noted that congestion problem is not just between RDS
and RRC pair, but whenever there is high fan-in ratio, congestion
would occur. e.g. many RDSs reporting to a RRC. RAQMON Framework
using UDP as a transport can attain congestion safety 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 Maximum PDU Transmission rate is no more
1 RAQMON PDU every 2 minutes, a UDP based implementation can be as
congestion safe as TCP based implementation. Such policies can be
enforced while configuring a RDS.
2. Retransmission timers with back offs: This approach requires that
at the application level to send a request, then 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-
RMON WG Expires December 2003 [Page 12]
INTERNET DRAFT RAQMON Framework June 2003
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 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 PDU
is transported over RTCP/UDP, RRC does 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 the interface at local
interface (usually LAN) rates, without awareness of the intervening
network conditions. For these reason, it is considered in general 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 PDU but identifying them
as 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.
RMON WG Expires December 2003 [Page 13]
INTERNET DRAFT RAQMON Framework June 2003
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 upon the implementers and equipment vendors to
choose. There are many different measurement methodologies available
for measuring application performance (e.g., probe-based, client-
based, synthetic-transaction, etc.). This specification does not
mandate a particular methodology - it is open to any that meet the
minimum requirements. Conformance to this specification requires that
the collected data match the semantics described herein. 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, ITU Referenced are included in 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 extension should be managed by the vendors independently
and published for wider interoperability.
Applications are not required to report all of the parameters
mentioned in the section but rather have the flexibility to report a
subset of these parameters appropriate for an application context.
[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 it fit the need. The
definition presented here is meant to provide guidance to
implementers. No claim is made that the definitions presented here
are appropriate for a particular application need. Syntactical
representations of the parameters identified here, are standardized
in [RAQMON-PDU] specification.
Data Source Name (DN): The DN item could be of various formats as
needed by the application. A few instances of DN could be but not
restricted to
* "user@host", or "host" if a user name is not available as on
RMON WG Expires December 2003 [Page 14]
INTERNET DRAFT RAQMON Framework June 2003
single-user systems. For both formats, "host" is either the fully
qualified domain name of the host from which the payload originates,
formatted according to the rules specified in [RFC1034], [RFC1035]
and Section 2.1 of [RFC1123]. The DN value is expected to remain
constant for the duration of a session. Examples are "big-guy@ip-
phone.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 DN parameter, as Data Source
Address (DA) parameter is used for that purpose.
* Another instance of a DN could a valid E.164 phone number, a SIP
URI or any other form of telephone or pager numbers. It is
recommended that the phone number should be formatted with the plus
sign replacing the international access code. For example, "+88 02
123 45678" for a number in Bangladesh.
It is expected that a Data Source Name (DN) will remain constant
within a communication session.
Receiver Name (RN): Receiver Name (RN) takes the same form like 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.
Data Source Address (DA): The Data Source Address (DA) parameter
should be represented as the standard ASCII representation of the
host's numeric address. This could be an IPv4 Address, IPv6 Address,
network address assignments such as the Net-10 assignment proposed in
[RFC1597] or any other form of numeric addresses represented in
ASCII.
It is expected that a Data Source Address (DA) would remain constant
within a communication session.
DN and DA are intended to give the application writers an opportunity
to uniquely identify a record associated to a session. However
application writers should be aware that private network address
assignments such as the Net-10 assignment might create network
addresses that are not globally unique. To handle this case, the
burden is on the application either to convert private addresses to
public addresses if necessary to keep private addresses from being
exposed or to create an application specific extension.
Receiver Source Address (RA): Receiver Source Address (RA) takes the
same form like Data Source Address (DA) but represents the Receiver's
Source Address. In a communication session applications should fill
in the other party's address that they are communicating with as a
RMON WG Expires December 2003 [Page 15]
INTERNET DRAFT RAQMON Framework June 2003
Receiver Source Address. Like Data Source Address, this could be an
IPv4 Address, IPv6 Address, network address assignments such as the
Net-10 assignment proposed in [RFC1597] or any other form of numeric
address represented in ASCII.
Data Source Device Ports Used: This parameter is used to indicate the
port used for a particular session or sub-session used for
communication. Example of port includes TCP Port, UDP Port, RTP Port
etc. It is not expected that a Data Source Device Ports would remain
constant within a communication session.
Receiver Device Ports Used: This parameter is used to indicate the
port used to communicate with the receiver for a particular session
or sub-session. Example of port includes TCP Port, UDP Port, RTP Port
etc. It is not expected that a Data Source Device Ports would remain
constant within a communication session.
Session Setup Date/Time Indicates the wallclock time when the RAQMON
packet was sent so that it may be used by the RRC to store Date/Time.
Wallclock time (absolute time) is represented using the timestamp
format of the Network Time Protocol (NTP), which is in seconds
relative to 0h UTC on 1 January 1900 [RFC1305].
Session Setup Delay: 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 as the
last DTMF button pushed to the first ring-back tone that indicates
that the far end is ringing. However as these definitions are very
specific to the type of system used and implementation details of
such 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.
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.
Session Setup Status: This parameter is intended to report status of
a session in order to support applications those need to display
status in real time. For example a debugging tool that captures the
status of a call-setup as soon as a call is established or a tool
that captures why a session failed or how many RSVP sessions failed
etc.
Round Trip End-to-End Delay: Round Trip End-to-End Delay [RFC1889],
RMON WG Expires December 2003 [Page 16]
INTERNET DRAFT RAQMON Framework June 2003
[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],[RFC1889] depending on the application needs and left upon
the implementers to select appropriate IETF and ITU methodologies to
measure End-to-End Delays appropriate for a specific application.
One Way End-to-End Delay: The One Way End-to-End Delay [RFC 2679]
allows the 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 could be used [RFC 2679] 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.
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.
RMON WG Expires December 2003 [Page 17]
INTERNET DRAFT RAQMON Framework June 2003
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 same units as Round Trip End-to-End Delay.
Inter-arrival Jitter [RFC1889]: The Inter-arrival Jitter provides a
short-term measure of congestion. The definition of Jitter is context
sensitive and measurement specific. Measurement of inter-arrival
Jitter is beyond the scope of this document. The jitter measure
indicates congestion before it leads to packet loss. Inter-arrival
jitter of underlying transport networks can be measured using various
methodologies and left upon the implementers based on their
application needs. VoIP Systems can readily acquire Inter-arrival
Jitter calculations from RTCP measurements as described in [RFC1889].
Total Number of Application Packets Received [RFC1889]: The total
number of payload packets received by the RDS since starting
transmission up until the time this RAQMON PDU was generated.
Total Number of Application Packets Sent [RFC1889]: The total number
of payload packets sent by the RDS since starting transmission up
until the time this RAQMON PDU was generated. Similar to total number
of packets received.
Total number of Application Octets Received [RFC1889]: The total
number of payload octets received in packets by the RDS since
beginning transmission up until the time this RAQMON packet was
generated.
Total number of Application Octets Sent [RFC1889]: The total number
of payload octets received in packets by the RDS since beginning
transmission up until the time this RAQMON packet was generated.
Similar to total number of octets received.
Cumulative Application Packet Loss: Packet loss tracks persistent
congestion while the jitter measure tracks transient congestion.
Since the inter-arrival jitter field is only a snapshot of the jitter
at the time of a report, packet loss indicates the network
environment as well as local device losses over time. Packet loss of
underlying transport network can be measured using various
methodologies e.g. as described in [RFC2680], [RFC1889] and local
device level packet losses ought to be captured by the local device
specific algorithms.
Packet loss in Fraction: Packet loss in Fraction represents sackets
loss as defined above but expressed in percentage.
Source Payload Type: The Source Payload Type defines payload formats
(e.g. media encodings) as sent by the data source. e.g. ITU
RMON WG Expires December 2003 [Page 18]
INTERNET DRAFT RAQMON Framework June 2003
G.711-(law, ITU G.729B, H.263, MPEG-2, ASCII etc. This document
follows the same payload type constants as defined in [RFC1890].
Destination Payload Type: 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-(law, ITU G.729B, H.263, MPEG-2,
ASCII etc. This document follows the same payload type constants as
defined in [RFC1890].
Source Layer 2 Priority: Many devices use Layer 2 technologies to
prioritize certain type of traffic in the Local Area Network
environment. For example the 1998 Edition of IEEE 802.1D [IEEE802.1D]
"Media Access Control" Bridges contains expedited traffic
capabilities to support transmission of time critical information and
many devices use the standard to mark Ethernet frames according to
IEEE 802.1p standard. Details on these can be found in IEEE 802.1Q
"Virtual Bridged LAN" specifications. 802.1p has been Incorporated
into ISO/IEC 15802-3 1998 [IEEE802.1Q]. Source Layer 2 RAQMON field
indicates Layer 2 values used by the RDS to prioritize these packets
in the Local Area Networks environment.
Source TOS/DSCP Value: Various Layer 3 technologies are in place to
prioritize certain type of traffic in the Internet. For example
traditional IP Precedence [RFC791], Type Of Service (TOS)
[RFC1349],[RFC1812] or more recent technologies like Differentiated
Service [RFC2474][RFC2475] is achieved by using the TOS octet in IPv4
and the Traffic class Octet in IPv6 are used to prioritize traffic.
Source Layer 3 RAQMON field indicates appropriate Layer 3 values used
by the Data Source to prioritize these packets.
Destination Layer 2 Priority: 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 destination has used
any Layer 2 technologies like IEEE 802.1p/Q or priority queuing etc.
Destination TOS/DSCP Value: 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 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].
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 implication on QoS
RMON WG Expires December 2003 [Page 19]
INTERNET DRAFT RAQMON Framework June 2003
implications of an end device. e.g. x % CPU busy averaged over
session duration.
Memory Utilization in Fraction: This parameter captures the IP Device
Memory usage rate to indicate current state of the local IP Device
resource, which may have very critical implication on QoS
implications of an end device. e.g. y % memory utilized over session
duration.
Application Name/version: Application Name/version parameter gives
the name and possibly version of the application associated to that
session or sub-session, e.g., "XYZ VoIP Agent 1.2". This information
may be useful for scenarios where 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 RAQMON Framework, since RRCs are computationally resourceful,
various aggregation functions are performed by the RRC and RDSs are
not burdened by statistical data processing such as
min/max/average/standard deviation etc.
The RAQMON MIB is designed to provide minimal aggregations of various
RAQMON Parameters defined in section 5.0. RAQMON MIB is designed not
to provide extensive aggregations like APM MIB [29] or 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 application
(e.g. Performance of VoIP, Video Applications).
In the RAQMON MIB, aggregation can be performed only on specific
RAQMON metrics parameters specified below:
Round Trip End-to-End Delay One Way End-to-End Delay Inter Arrival
Jitter Cumulative Packet Loss Packet Loss in Fraction CPU utilization
in Fraction Memory utilization in Fraction
The aggregation of the parameters listed above, 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.
RMON WG Expires December 2003 [Page 20]
INTERNET DRAFT RAQMON Framework June 2003
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. 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 following ways:
1. Store data in the MIB only at the end of a communication session
(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 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 usage
of these policies left at the application developer's discretion.
8. Normative References
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000
[RFC1889] Henning Schulzrinne, S. Casner, R. Frederick, and
RMON WG Expires December 2003 [Page 21]
INTERNET DRAFT RAQMON Framework June 2003
V. Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
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.
[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
[RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay
Metric for IPPM", RFC 2681, September 1999
[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)
RMON WG Expires December 2003 [Page 22]
INTERNET DRAFT RAQMON Framework June 2003
bridges:15802-3: 1998 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1998
Edition]
[RFC1349] P. Almquist, "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers" RFC1812,
June 1995
[RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC2474, December 1998
[RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and W.Weiss,
"An Architecture for Differentiated Services" RFC2475,
December 1998
[RAQMON-PDU] A. Siddiqui, S. Waldbusser, D.Romascanu, and E. Golovinsky,
"Protocol Data Units for Real-time Application Quality of
Service Monitoring (RAQMON)", Internet-Draft,
draft-ietf-raqmon-pdu-02.txt, June 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-01.txt,
June 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
RMON WG Expires December 2003 [Page 23]
INTERNET DRAFT RAQMON Framework June 2003
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
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 other in 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
Among non-existent threats is repudiation since RAQMON is assumed not
to deal with transactional data. It may be noted that it is the RRC
that will be directly affected by these RAQMON exploits due to the
unidirectional nature of the RAQMON dataflow. Indirect effects of
these threats may affect the RDS.
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
RMON WG Expires December 2003 [Page 24]
INTERNET DRAFT RAQMON Framework June 2003
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
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 IPaddresses in RAQMON PDUs.
However, when RAQMON PDU's are encrypted end-to-end that will not
be possible.
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.
RMON WG Expires December 2003 [Page 25]
INTERNET DRAFT RAQMON Framework June 2003
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.
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 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 this 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),
RMON WG Expires December 2003 [Page 26]
INTERNET DRAFT RAQMON Framework June 2003
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).
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 to 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 its 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.
11.6 Use of TCP as transport
When using TCP as the RAQMON transport, in order to meet the security
services requirement of RAQMON stream, the more ubiquitous TLS
protocol support may be made use of.
12. IANA Considerations
This memo introduces 1 new port for IANA registration. This
specification registers port YYYYY as specified in Section 2.4.1 at
http://www.iana.org/numbers.html
13. Acknowledgements
RMON WG Expires December 2003 [Page 27]
INTERNET DRAFT RAQMON Framework June 2003
The authors would like to thank Mahalingam Mani, Steven Waldbusser
and Itai Zilbershtein for interesting discussions and various direct
contributions in this problem space.
14. 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 Inc.
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com
Eugene Golovinsky
BMC Software Inc.
2101 CityWest Blvd.
Houston, Texas 77042
USA
Tel: +1 713 918-1816
Email: eugene_golovinsky@bmc.com
A. Full Copyright Statement
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
RMON WG Expires December 2003 [Page 28]
INTERNET DRAFT RAQMON Framework June 2003
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 December 2003 [Page 29]
