Internet Draft Anwar Siddiqui
Avaya Inc.
Dan Romascanu
Avaya Inc.
Eugene Golovinsky
BMC Software
3 March 2003
Real-time Application Quality of Service Monitoring (RAQMON)
Protocol Data Unit (PDU)
<draft-ietf-rmonmib-raqmon-pdu-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo defines a common protocol data unit (PDU) used between
RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report
a QOS statistics using RTCP and SNMP as Transport Protocol.
The original RAQMON draft [SIDDIQUI3] was split into 3 parts to
identify the RAQMON Framework, RAQMON QOS PDU and RAQMON MIB.
This memo defined RAQMON QOS Protocol Data Unit (PDU). This memo also
outlines mechanisms to use Real Time Transport Control Protocol
(RTCP) and Simple Network Management Protocol (SNMP) to transport
RMON WG Expires September 2003 [Page 1]
INTERNET DRAFT RAQMON PDU March 2003
these PDUs between RAQMON Data Source (RDS) and RAQMON Report
Collector (RRC) as outlined in RAQMON Charter of the RMON Workgroup.
The memo [SIDDIQUI2] defines a Real-Time Application QOS Monitoring
(RAQMON) Framework that extends the RMON Framework to allow Real-time
Application QoS information as outlined by RAQMON Charter of the RMON
Workgroup.
The memo [SIDDIQUI1] defines a portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. The document proposes an extension to the Remote
Monitoring MIB [RFC2819] to accommodate RAQMON solution.
Distribution of this memo is unlimited.
Table of Contents
Status of this Memo 1
Abstract 1
1 Introduction 2
2 RAQMON Protocol Data Unit (PDU) Design Overview 3
3 Measurement Methodology 4
4 RAQMON PDU Format 5
5 Transporting RAQMON Protocol Data Units 15
6 Normative References 19
7 Normative References 20
8 Intellectual Property 23
9 Security Considerations 24
10 IANA Considerations 25
11 Authors' Addresses 25
A Full Copyright Statement 26
1. Introduction
This memo defines a common protocol data unit (PDU) used between
RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report
a QOS statistics using RTCP and SNMP as an underlying transport
protocol as outlined in RAQMON Framework draft.
The original RAQMON draft [SIDDIQUI3] was split into 3 parts to
identify the RAQMON framework, RAQMON PDU and RAQMON MIB. This memo
takes the portion of [SIDDIQUI3] that defined RAQMON QOS PDU and
describes how various PDUs can be transported over existing
Application level transport protocol like Real Time Control Protocol
(RTCP) and Simple Network Management Protocol (SNMP) to transport
application QOS statistics between RDS and RRC.
RMON WG Expires September 2003 [Page 2]
INTERNET DRAFT RAQMON PDU March 2003
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 Protocol Data Unit (PDU) Design Overview
This memo defines a common protocol data unit (PDU) used between
RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report
a QOS statistics using RTCP and SNMP as an underlying transport
protocol as outlined in RAQMON Framework draft. RAQMON Protocol Data
Unit (PDU) provides a generic structure exchanged between RDS and RRC
to report QOS parameters in Real-time.
RAQMON continues the architecture created in the RMON[RFC2819] by
providing analysis of application performance as experienced by end-
users on a specific IP end point and correlating such performance to
its underlying transport network characteristics, application level
transactions and host performance. RAQMON protocol data units provide
a vehicle to these end points and applications to report such
statistics in real-time to a target collector within a specific
administrative domain.
RAQMON provides a framework to report QOS statistics for simplex
flows, i.e., it reports statistics only in one direction. Therefore,
within RAQMON Framework, a RAQMON PDU logically contains QOS
parameter information as perceived by the reporting end device or
applications. RAQMON operates on top of RTCP, SNMP, TCP, UDP, IPv4 or
IPv6 occupying the place of a payload specification at the
application layer in the protocol stack. However, RAQMON PDUs does
not transport application data but is rather uses existing internet
protocols like RTCP APP Packet and SNMP INFORM to be transported from
a RDS to RRC. Like the implementations of routing and management
protocols, an implementation of RAQMON will typically execute in the
background, not in the data forwarding path. RAQMON PDUs by itself is
not a transport protocol; RAQMON PDUs are designed to operate with
current and future internet transport protocols.
RAQMON Protocol Data Units (PDU) can be used by many Real-time as
well as Non-Real time Applications to report QOS statistics and
considered as an extension of RMON. Voice over IP, Fax over IP, Video
over IP, Instant Messaging, Email, ftp/tftp based downloads, e-
business style transactions, web access from handheld devices or cell
phones are few example application scenarios where such a framework
could be useful.
RAQMON PDUs are common data formats commonly understood by RDS and
RMON WG Expires September 2003 [Page 3]
INTERNET DRAFT RAQMON PDU March 2003
RRC to exchange RAQMON Statistics (i.e. "Name" and "Value" pair).
RAQMON PDUs offer an entry (a.k.a. "Name") to be filled in by
application specific software which with a specific "value" in real-
time before an RDS emits such a PDU towards a RRC.
It is out of the scope of PDU specification to either recommend or
validate specific measurement methodology used to gather a "value"
for a specified "name". These PDUs are transmitted over Real Time
Control Protocol (RTCP) or Simple Network Management Control Protocol
(SNMP) to ensure reuse of existing internet standards.
There are 2 types of PDUs within the RAQMON Framework:
BASIC PDU: A BASIC PDU provides mechanisms to report some frequently
used parameters from a pre listed parameter suit defined in table 1.
Application developers have the flexibility to make an RDS report a
sub-set of these pre-set parameters to RRC appropriate for an
application context. For example, An IP Phone developer might want to
use RAQMON BASIC PDU to report End-to-End Delay, Jitter, packet loss
etc while the Instant Message client can use the same BASIC PDU to
report only Packet Loss and End-to-End Delay.
APP PDU: Since is difficult to design a BASIC PDU that meets the
needs of all applications, RAQMON provides APP PDUs for further
extension required to convey application, vendor, device etc.
specific parameters for future usage. Additional parameters can be
defined within payload of the APP PDU as Type length Value (TLV)
pairs and defined by the application developers or vendors.
RAQMON PDUs, provides RDSs the flexibility to decide the parameters,
an end device/application is willing to report. RAQMON PDUs also
provide the RRCs the flexibility to store the parameters an
administrative domain feel important for a domain.
Following sections of this memo contains detailed RAQMON PDU
specifications.
3. Measurement Methodology
It is not the intent of this document to recommend a methodology to
measure any of the QOS parameters defined in. However a complete list
of definitions of metrics used within RAQMON PDUs are defined in
<draft-ietf-rmonmib-raqmon-framework-01.txt> through reference to
other appropriate existing IETF standards organizations' documents.
There are many different methodologies available for measuring
application performance (e.g., probe-based, client-based, synthetic-
transaction, etc.). This specification does not mandate a particular
RMON WG Expires September 2003 [Page 4]
INTERNET DRAFT RAQMON PDU March 2003
methodology - it is open to any that meet the minimum requirements.
Conformance to this specification requires that the collected data be
presented appropriately to match the RAQMON PDU semantics described
herein.
4. RAQMON PDU Format
There are 2 types of RAQMON PDUs used by the RDS to report various
QOS parameters to RRC.
BASIC PDU: For reporting monitored data from an RDS to RRC which
includes QOS parameters defined in <draft-ietf-rmonmib-raqmon-
framework-01.txt>. BASIC PDU are identified by inspecting the PDT
field within the PDU. BASIC PDUs are marked as PDT = 1
APP PDU: APP PDUs are marked as PDT = 4
Following is various RAQMON PDU formats:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P| RC | | | |X|PDT = 1| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RC X |N| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source Address {DA} |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Address (RA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Application Name (AN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Data Source Name (DN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Receiver's Name (RN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
RMON WG Expires September 2003 [Page 5]
INTERNET DRAFT RAQMON PDU March 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Session State ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round Trip End-to-End Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One Way End-to-End Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Packet Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Packets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Packets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Octets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Octets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Used | Receiver Port Used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Source Payload |Reciver Payload| CPU | Memory |
|Type | Type | Utilization | Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Setup Delay | Inter arrival Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding | Packet loss |
| | (In fraction)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Basic Protcol Data Unit
4.1 BASIC Protocol Data Unit (PDU)
version (V) : 3 bits - Identifies the version of RAQMON. This version is 1.
padding (P): 1 bit - If the padding bit is set, this RAQMON packet contains
some additional padding octets at the end which are not part of the
monitoring information. The last octet of the padding is a count of how many
padding octets should be ignored. Padding may be needed by some applications
as reporting is based on the intent of RDS to report certain parameters.
RMON WG Expires September 2003 [Page 6]
INTERNET DRAFT RAQMON PDU March 2003
record count (RC): 4 bits - Total number of records contained in this
packet. A value of zero is valid but useless.
reserved bits: 3 bits - reserved for future extensions to the RAQMON Packet.
IPversion Flag: 1 bit - While set to 1, IP Version Flag indicates that IP
addresses are IP version 6 compatible.
PDU Type (PDT): 4 bits - This indicates the type of RAQMON PDU being
sent. There are 2 types of RAQMON PDUs. BASIC PDU (PDT = 1) and APP
PDU (PDT =4).
length: 16 bits - The length of this RAQMON packet in 32-bit words minus one
which includes the header and any padding.
DSRC: 32 bits - Data Source identifier represents a unique session
descriptor that points to a specific communication session between
communicating entities. Uniqueness of DSRC is valid only within a session.
DSRC values should be randomly generated using vendor chosen algorithms. It
is not sufficient to obtain a DSRC simply by calling random() without
carefully initializing the state. It is beyond the scope of this document
define an algorithm to generate DSRC. However one could very easily use an
algorithm like the one defined in Appendix A.6 in [17]. Depending on the
choice of algorithm, there is a finite probability that two DSRCS from two
different RDSs may be same. To further reduce the probability that two RDSs
pick the same DSRC, it is recommended that an RRC or an application use Data
Source Address (DA) and Data Source Name (DN) in conjunction with a DSRC
value to reduce that probability drastically.
Each RAQMON packet consists of a DSRC followed by RC_n and RAQMON flags to
indicate presence of appropriate RAQMON parameters as defined in table 1.
RC_n: 4 bits - Record Count number to which the information in this record
pertains. Record Count number indicates a sub-session within a communication
session. A value of zero is a valid record number. Maximum number of records
that can be described in one RAQMON Packet is 16 (i.e. 0000 - 1111).
RAQMON Parameter Presence Flags (RPPF): 28 bits
Each of these flags while set represent that this RAQMON packet contains
corresponding parameters as specified in table 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P| RC | | | |X|PDT = 1| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
RMON WG Expires September 2003 [Page 7]
INTERNET DRAFT RAQMON PDU March 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RC N |8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number Presence/Absence of corresponding
Parameter within this RAQMON packet
1 Data Source Address (DA)
2 Receiver Address (RA)
3 NTP Timestamp
4 Application Name
5 Data Source Name (DN)
6 Receiver Name (RN)
7 Session Setup Status
8 Session Duration
9 End-to-End Delay (RTT)
0 End-to-End Delay (OWD)
1 Cumulative Packet Loss
2 Total number of Packets sent
3 Total number of Packets received
4 Total number of Octets sent
5 Total number of Octets received
6 Source Port Used
7 Receiver Port Used
8 S_Layer2
9 S_Layer3
0 D_Layer2
1 D_Layer3
RMON WG Expires September 2003 [Page 8]
INTERNET DRAFT RAQMON PDU March 2003
2 Source Payload Type
3 Receiver Payload Type
4 CPU Utilization
5 Memory Utilization
6 Session Setup Delay
7 Inter arrival Jitter
8 Packet loss (in fraction)
Table 2: RAQMON Parameters and corresponding RPPF
Data Source Name: - Data Source Name field starts with an 8-bit octet count
describing the length of the text and the text itself. Note that the text
can be no longer than 255 octets. The text is encoded according to the UTF-2
encoding specified in Annex F of ISO standard 10646 [ISO10646],[UNICODE].
This encoding is also known as UTF-8 or UTF-FSS. It is described in "File
System Safe UCS Transformation Format (FSS_UTF)", X/Open Preliminary
Specification, Document Number P316 and Unicode Technical Report #4.
US-ASCII is a subset of this encoding and requires no additional encoding.
The presence of multi-octet encoding is indicated by setting the most
significant bit of a character to a value of one. Text is not null
terminated because some multi-octet encoding include null octets. Data
Source Name is terminated by one or more null octets, the first of which is
interpreted as to denote the end of the string and the remainder as needed
to pad until the next 32-bit boundary. Since the Data Source Name is
expected to remain constant for the duration of the session, it is
recommended that RDS report such field only once within a communication
session to ensure efficient usage of network and system resources.
Receiver Name: - Same as Data Source Name. Data Source Name and Receiver's
Name are contiguous, i.e., items are not individually padded to a 32-bit
boundary.
Data Source Address: 32 bits - The standard ASCII representation of the end
device's numeric address on the interface used for the communication
session. The standard ASCII representation of an IP Version 4 address is
"dotted decimal", also known as dotted quad. Other address types are
expected to have ASCII representations that are mutually unique.
135.8.45.178 is an example of a valid Data Source Address. Since the Data
Source Address is expected to remain constant for the duration of the
session, it is recommended that RDS report such field only once within a
communication session to ensure efficient usage of network and system
RMON WG Expires September 2003 [Page 9]
INTERNET DRAFT RAQMON PDU March 2003
resources.
Issue: IP addresses, TCP/UDP ports information should be removed (NAT
un-friendly). One of the way to avoid this problem is to use Application
Layer Gateways (ALGs) to fill out IP Addresses on RDS's behalf.
Receiver Address: 32 bits - Same as Data Source Address
Application Name: - Application Name field starts with an 8-bit octet count
describing the length of the text and the text itself. Application name
field has same format as Data Source Name. This is a text string giving the
name and possibly version of the application associated to that session,
e.g., "XYZ VoIP Agent 1.2". This information may be useful for debugging
purposes and is similar to the Mailer or Mail-System-Version SMTP headers.
Since the Application Name is expected to remain constant for the duration
of the session, it is recommended that RDS report such field only once
within a communication session to ensure efficient usage of network and
system resources.
NTP timestamp: 64 bits - Indicates the wallclock time when the RAQMON packet
was sent so that it may be used by the RRC to store Date/Time. A Data Source
that has no notion of wallclock or time may set the NTP timestamp to zero.
However that will waste 32 bits in the packet. An RDS should set the
appropriate RAQMON flag to 0 to avoid such waste. Since NTP time stamp is
intended to provide Date/Time of a session, it is recommended that the NTP
Timestamp be used only in the first RAQMON packet to use network resources
efficiently. However such a recommendation is context sensitive and should
be enforced as deemed necessary by each application environment.
The full resolution NTP timestamp is a 64-bit unsigned fixed-point number
with the integer part in the first 32 bits and the fractional part in the
last 32 bits. In some fields where a more compact representation is
appropriate, only the middle 32 bits are used; that is, the low 16 bits of
the integer part and the high 16 bits of the fractional part. The high 16
bits of the integer part must be determined independently.
Session Setup Status: - Session State field starts with an 8-bit octet count
describing the length of the text and the text itself. This field is used to
describe appropriate communication session states e.g. Call Established
successfully, RSVP reservation failed etc.
Session Duration: 32 bits - Session Duration is an unsigned Integer
expressed in the order of seconds.
Round Trip End-to-End Delay: 32 bits - Round Trip End-to-End Delay is an
unsigned Integer expressed in the order of milliseconds.
One Way End-to-End Delay: 32 bits - One way End-to-End Delay is an unsigned
RMON WG Expires September 2003 [Page 10]
INTERNET DRAFT RAQMON PDU March 2003
Integer expressed in the order of milliseconds.
Cumulative Packet Loss: 32 bits - The total number of packets from session
RC_n that have been lost while this RAQMON packet was generated. This number
is defined to be the number of packets expected less the number of packets
actually received.
Total number of Packets sent: 32 bits - The total number of packets
transmitted within a communication session by the sender since starting
transmission up until the time this RAQMON packet was generated. This
counter is reset if the DSRC identifier is changed as it indicates a
different session.
Total number of Packets received: 32 bits - The total number of packets
transmitted within a communication session by the receiver since starting
transmission up until the time this RAQMON packet was generated. This
counter is reset if the DSRC identifier is changed as it indicates a
different session.
Total number of Octets sent: 32 bits - The total number of payload octets
(i.e., not including header or padding) transmitted in packets by the sender
within a communication session since starting transmission up until the time
this RAQMON packet was generated. This counter is reset if the DSRC
identifier is changed as it indicates a different session.
Total number of Octets received: 32 bits - The total number of payload
octets (i.e., not including header or padding) transmitted in packets by the
receiver within a communication session since starting transmission up until
the time this RAQMON packet was generated. This counter is reset if the DSRC
identifier is changed as it indicates a different session.
Source Port Used: 16 bits - Port Number used by the Data Source as used by
the application while this RAQMON Packet was generated.
Receiver Port Used: 16 bits - Same as Source Port Used
S_Layer2: 8 bits - Source Layer 2 priorities used to send packets to the
receiver by this data source during this communication session. For example
priority bits associated to IEEE 802.1p values for appropriate priorities.
For example priority bits associated to IEEE 802.1p tags value of 5 reported
via S_Layer2 parameter would indicate Video over IP from this data source is
prioritized by some Layer 2 switch.
S_Layer3: 8 bits - Layer 3 priorities used to send packets to the receiver
by this data source during this communication session. For example priority
bits associated to IP Precedence (i.e. 101XXXXX) or DiffServ PHB values (i.e
EF, AF41) etc reported via S_Layer3 parameter would indicate whether
applications from this data source is prioritized by some Layer 3 switch or
RMON WG Expires September 2003 [Page 11]
INTERNET DRAFT RAQMON PDU March 2003
not.
D_Layer2: 8 bits - Layer 2 priorities used by the receiver to send packets
to the data source during this communication session if the Data Source can
learn such information.
D_Layer3: 8 bits - Layer 3 priorities used by the receiver to send packets
to the data source during this communication session if the Data Source can
learn such information.
Source Payload Type: 8 bit - This document follows definition of Payload
Type (PT) as definition is in [RFC1890]. This 8 bit fields specify the type
of audio, video or data media used to send packets to the receiver by this
data source during a communication session. Table 3 indicates a small list
of various Payload types as defined in [RFC1890] cited here for
informational purposes. As this table indicates, if an application ought to
indicate that the Source Pay Load Type used for a session were PCMA, Source
Payload Field of the BASIC RAQMON packet ought to be 8.
PT encoding audio/video clock rate channels
name (A/V) (Hz) (audio)
_______________________________________________________________
0 PCMU A 8000 1
1 1016 A 8000 1
2 G721 A 8000 1
3 GSM A 8000 1
4 unassigned A 8000 1
5 DVI4 A 8000 1
6 DVI4 A 16000 1
7 LPC A 8000 1
8 PCMA A 8000 1
9 G722 A 8000 1
10 L16 A 44100 2
11 L16 A 44100 1
12 unassigned A
13 unassigned A
14 MPA A 90000 (see text)
15 G728 A 8000 1
16--23 unassigned A
24 unassigned V
25 CelB V 90000
26 JPEG V 90000
27 unassigned V
28 nv V 90000
29 unassigned V
30 unassigned V
31 H261 V 90000
RMON WG Expires September 2003 [Page 12]
INTERNET DRAFT RAQMON PDU March 2003
32 MPV V 90000
33 MP2T AV 90000
34--71 unassigned ?
72--76 reserved N/A N/A N/A
77--95 unassigned ?
96--127 dynamic ?
Table 3: Payload types (PT) for standard audio and video encodings
Please refer to [RFC1890] for various other Audio, Video and Data
related payload types.
CPU Utilization: 8 bits - Percentage of CPU used over a time duration.
Memory Utilization: 8 bits - Percentage of total memory over a time
duration.
Session Setup Delay: 16 bits - Indicates the duration of time required
by a network communication controller to set a media path between the
communicating entities or the end devices. This parameter is expressed
in milliseconds.
Inter-Arrival Jitter: 16 bits - An estimate of the statistical
variance of packets inter-arrival time expressed in milliseconds.
Packet Loss in Fraction: 8 bits - The fraction of packets from data
source lost since the previous RAQMON was dispatched, expressed as a
fixed point number with the binary point at the left edge of the
field. (That is equivalent to taking the integer part after
multiplying the loss fraction by 256.) This fraction is defined to be
the number of packets lost divided by the number of packets expected.
4.2 Mapping of Basic RAQMON Packet to SNMP notification
The information carried by Basic RAQMON packet MAY be delivered by SNMP notifications. This delivery mechanism works in conjunction with RAQMON Notifications defined in [SIDDIQUI1]. As described in Section 5.1, the use of SNMP Informs is RECOEMDED. Full compliance with RFC2273 to support Command Responder/Notification Originator applications is NOT REQUIRED. This is to be left up to implementer. A RAQMON device can implement either a full SNMP agent, or a subset that sends RAQMON PDUs in a format similar to SNMP Informs. The section of the draft defines mapping mechanism of information carried by Basic RAQMON Packet to SNMP notification PDU(s).
4.3 APP Protocol Data Unit (PDU)
The APP PDU is intended for experimental use as new applications and new
features are developed, without requiring packet type value registration.
APP packets with unrecognized names should be ignored. After testing and if
wider use is justified, it is recommended that each APP packet be redefined
without the subtype and name fields and registered with the Internet
Assigned Numbers Authority (IANA).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RMON WG Expires September 2003 [Page 13]
INTERNET DRAFT RAQMON PDU March 2003
| V |P| RC | | | |X|PDT = 4| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source Address {DA} |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| APP packet name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application dependent data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - RAQMON APP Protcol Data Unit
version (V), padding (P), record count (RC):
As defined for BASIC Packet.
reserved bits: 3 bits - reserved for future extensions to the RAQMON Packet.
IPversion Flag: As defined for BASIC Packet.
DSRC and DA: As defined for BASIC Packet.
subtype: 4 bits - May be used as a subtype to allow a set of APP PDUs to
be defined under one unique name, or for any application-dependent data.
pdu type (PDT): 4 bits - Contains the constant 4 to identify this as an
RAQMON APP PDU.
name: 4 octets - A name chosen by the person defining the set of APP PDUs
to be unique with respect to other APP PDUs this application might
receive. The application creator might choose to use the application name,
and then coordinate the allocation of subtype values to others who want to
define new packet types for the application. Alternatively, it is
recommended that others choose a name based on the entity they represent,
then coordinate the use of the name within that entity. The name is
interpreted as a sequence of four ASCII characters, with uppercase and
lowercase characters treated as distinct.
application-dependent data: variable length - Application-dependent data may
or may not appear in an APP packet. It is interpreted by the application and
not by the RRC itself. It must be a multiple of 32 bits long.
4.4 Byte Order, Alignment, and Time Format of RAQMON PDUs
All integer fields are carried in network byte order, that is, most
RMON WG Expires September 2003 [Page 14]
INTERNET DRAFT RAQMON PDU March 2003
significant byte (octet) first. This byte order is commonly known as
big-endian. The transmission order is described in detail in [RFC791].
Unless otherwise noted, numeric constants are in decimal (base 10).
All header data is aligned to its natural length, i.e., 16-bit fields are
aligned on even offsets, 32-bit fields are aligned at offsets divisible by
four, etc. Octets designated as padding have the value zero.
5. Transporting RAQMON Protocol Data Units
It is an inherent objective of the RAQMON Framework to re-use existing
application level transport protocols to maximize the usage of existing
installations as well as to avoid transport protocol level complexities in
the design process. As outlined in the RAQMON framework document that both
the Real-Time Transport Control Protocol and Simple Network Management
Protocol were suitable to meet the criteria of a transport protocol as
outlined in the RAQMON Charter. Section 5. 1 reflects mechanisms that uses
SNMP INFORM PDUs as transport protocol and section 5.2 elaborates a protocol
that uses RTCP APP Packets [RFC 1889] to transport RAQMON PDUs between RDS
and RRC.
5.1 SNMP INFORM PDUs as RDS/RRC Network Transport Protocol
The idea is to re-use SNMP INFORM PDU. This proposal offers that:
+ RDSs implement the capability of embedding RAQMON parameters in
SNMP INFORM Request and thus re-using well known SNMP mechanisms to
report RAQMON Statistics.
+ To keep the RDS realization simple and keep the protocol lightweight,
the RDSs will not be REQUIRED to respond to SNMP requests like get, set,
etc., as an SNMP compliant responder would.
+ If the RRC chooses to implement an SNMP manager, an SNMP INFORM
Response would be sent for each associated SNMP INFORM originated by the RDS.
+ The RDS may ignore the SNMP INFORM Responses, or, if better
reliability is required, will wait for the Inform response,
retransmitting the original Inform PDU every M seconds until it has
been sent N times.
+ The SNMP INFORM transport for RAQMON PDUs can use one of the two UDP ports assignments:
- Standard UDP port 162 used for SNMP Notifications, if full SNMP entities implementations are present in the RRC and RDS
- IANA assigned UDP port 5YYYY for RAQMON PDUs carried over SNMP, for the cases when at least one of the RRC and RDS does not support a full implementation of the SNMP entities.
The benefits of using SNMP Informs are:
RMON WG Expires September 2003 [Page 15]
INTERNET DRAFT RAQMON PDU March 2003
- Using a well-known protocol.
- Privacy and authentication are covered by SNMPv3
- Limited or no need for specific RAQMON-protocol code in the
RRC, as it can use an SNMP manager implementation to process Informs.
The drawback of this approach is the overhead SNMP puts on low-powered
RDSs, for instance - BER encoding.
5.1.1 Encoding RAQMON PDU format within a small set of MIB items.
The RAQMON PDU defined in Section 4.1 is encapsulated in the
raqmonPDUBasicPDU MIB object from the RAQMON MIB [SIDDIQUI1].
This object has a SYNTAX of an OCTET STRING variable, which encodes
the content of the data fields described in figure 2.
The Inform Request will contain this object.
5.1.2 SNMP Inform PDU Related Issues as applied to RAQMON
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 SNMPv3
However there are certain challenges in using SNMP for RAQMON too. And
they are:
- The benefit is added flexibility of the proposed by RAQMON Framework
could be constrained.
- 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.
- Sending ACKs also wastes network bandwidth. In a reasonable sized
Enterprise and Service provider systems this can be a significant
amount of load.
To get rid of the Ack as the RDS/RRC protocol which needs not be
acknowledgement oriented, SNMP Traps could be used instead of Informs.
This will allow one to use SNMP without avoiding performance related
issues as mentioned above, with the disadvantage of loss of reliability
in passing the information.
5.2 Mapping RAQMON PDUs to RTCP as RDS/RRC Network Transport Protocol
The RAQMON PDU Transfer is comprised of unidirectional exchange of PDUs between
RDSs and an RRC. The protocol data units are mapped to a
RMON WG Expires September 2003 [Page 16]
INTERNET DRAFT RAQMON PDU March 2003
connectionless datagram service (UDP).
As outlined in RFC 1889, an RTCP APP packet allows Applications to defined RTCP packets. Within RTCP framework, a RAQMON PDUs is represented as an Application Specific Report and uses RTCP APP Packets to transport RAQMON PDU.
Figure 4 below shows how RAQMON PDUs can use RTCP APP Packets to transport
RAQMON PDUs between RDS and RRC.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) = "RAQMON" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RAQMON BASIC PDU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - Using RTCP APP Packets to transport RAQMON PDUs
The RTCP APP packets are intended for experimental use as new applications
and new features are developed, without requiring packet type value
registration. To be backward compatible RTCP APP packets used by RAQMON
SHOULD be Internet Assigned Numbers Authority (IANA) Registered.
version (V), padding (P), length:
As described for the SR packet (see Section 6.3.1).
subtype: 5 bits
subtype 1 in RAQMON Specific RTCP APP packet SHOULD be used by the BASIC
RAQMON PDU and subtype 2 should be preserved for RAQMON APP PDUs.
These unique definitions will be IANA registered.
packet type (PT): 8 bits
Contains the constant 204 to identify this as an RTCP APP packet.
name: 4 octets
The name chosen by the RMON WG defining the set of APP packets will be
unique with respect to other APP packets and will be IANA Registered as
"RAQMON" with all uppercase. The name field in RTCP APP Packet is
interpreted as a sequence of four ASCII characters.
application-dependent data: variable length
RAQMON PDUs sent by the RDS in the format specified in Figure 4 will
be interpreted by the RAQMON Report Collector (RRC) and not RTP itself.
RAQMON PDUs must be a multiple of 32 bits long.
RMON WG Expires September 2003 [Page 17]
INTERNET DRAFT RAQMON PDU March 2003
+ During a monitored real-time session, the RDS emits a Report PDU
every M seconds toward the RRC as provisioned by the RDS.
+ The RRC collects the Report PDUs and correlate them with its
database.
Though this is a simple one-way send protocol, the RDSs will not be
capable of inferring whether a PDU was received by the RRC as Report
PDUs are transmitted over a lossy network.
So one uses proposed RTCP like protocol as RDS/RRC Network Transport
Protocol each Report PDU must contain enough information to uniquely
identify the PDUs and correlate to an ongoing session. RRCs could use
DSRC field and a unique device ID (i.e. like 6 Octet MAC address or IP
Address) to define a unique session.
However this will cause 6-octet overhead worth wasted bandwidth per
PDU.
5.2.1 - Pseudo code for RDS & RRC
RDS:
when (session starts} {
report.identifier = session.endpoints, session.starttime;
report.timestamp = 0;
while (session in progress) {
wait interval;
report.statistics = update statistics;
report.curtimestamp += interval;
if encryption required
report_data = encrypt(report, encrypt parameters);
else
report_data = report;
raqmon_pdu = header, report_data;
send raqmon-pdu;
}
}
RRC:
listen on raqmon port
when ( raqmon_pdu received ) {
decrypt raqmon_pdu.data if needed
if report.identifier in database
if report.current_time_stamp > last update
update session statistics from report.statistics
else
discard report
RMON WG Expires September 2003 [Page 18]
INTERNET DRAFT RAQMON PDU March 2003
}
5.2.2 Port Assignment
As specified in the previous sections that Transport of RAQMON PDUs can be
performed using various underlying network transport protocol like TCP and
UDP.
Applications operating under RAQMON Framework may use any unreserved
UDP port. For example, a session management program can allocate the
port randomly. A single fixed port cannot be required because multiple
applications using RAQMON are likely to run on the same host, and
there are some operating systems that do not allow multiple processes
to use the same UDP port with different multicast addresses.
However, port numbers 5XXX have been registered with IANA for use with
those applications that choose to use them as the default port for RAQMON
PDUs over RTCP. Hosts that run multiple applications may use this port as an
indication to have used RAQMON if they are not subject to the constraint of
the previous paragraph.
Applications need not have a default and may require that the port be
explicitly specified. The particular port number was chosen to lie in
the range above 5000 to accommodate port number allocation practice
within the Unix operating system, where privileged processes can only
use port numbers below 1024 and port numbers between 1024 and 5000 are
automatically assigned by the operating systems.
6. Normative References
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000
RMON WG Expires September 2003 [Page 19]
INTERNET DRAFT RAQMON PDU March 2003
[RFC1889] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications"
RFC 1889, January 1996.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
7. Informative References
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing SNMP Management Frameworks", RFC 2571, April
1999.
[RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets", STD
16, RFC 1155, May 1990.
[RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD
16, RFC 1212, March 1991.
[RFC1215] M. Rose, "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
RFC 2573, April 1999.
RMON WG Expires September 2003 [Page 20]
INTERNET DRAFT RAQMON PDU March 2003
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction to Version 3 of the Internet-standard Network
Management Framework", RFC 2570, April 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser,
"Remote Network Monitoring MIB Extensions for Switched
Networks, Version 1.0", RFC 2613, June 1999
[RFC1213] McCloghrie, K., and M. Rose, Editors, "Management
Information Base for Network Management of TCP/IP-based
internets: MIB-II", STD 17, RFC 1213, March 1991.
[RFC2863] McCloghrie, K., and Kastenholtz, F., "The Interfaces Group
MIB", RFC 2863, June 2000.
[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
RMON WG Expires September 2003 [Page 21]
INTERNET DRAFT RAQMON PDU March 2003
[WALDBUSSER] Steven Waldbusser, "Application Performance Measurement MIB",
draft-ietf-rmonmib-apm-mib-04.txt, July 2001
[DIETZ] Russel Dietz, Robert Cole, "Transport Performance Metrics MIB",
draft-ietf-rmonmib-tpm-mib-03.txt, July 2001
[ISO10646] International Standards Organization, "ISO/IEC DIS 10646-1:1993
information technology -- universal multiple-octet coded
character set (UCS) -- part I: Architecture and basic
multilingual plane," 1993.
[UNICODE] The Unicode Consortium, The Unicode Standard New York,
New York:Addison-Wesley, 1991.
[IEEE802.1D] Information technology-Telecommunications and information
exchange between systems--Local and metropolitan area networks-
Common Specification a--Media access control (MAC) bridges:
15802-3: 1998 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1998 Edition]
[RFC1349] P. Almquist, "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers" RFC1812,
June 1995
[RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC2474, December 1998
[RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and W.Weiss,
"An Architecture for Differentiated Services" RFC2475,
December 1998
[SIDDIQUI1] A. Siddiqui, D.Romascanu, E. Golovinsky, and R. Smith,
"Real-time Application Quality of Service Monitoring (RAQMON)
MIB", Internet-Draft, draft-ietf-rmonmib-raqmon-mib-
00.txt, January 2003
[SIDDIQUI2] A. Siddiqui, D.Romascanu, and E. Golovinsky,
"Framework for Real-time Application Quality of Service
Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon-
framework-00.txt, January 2003
[SIDDIQUI3] A. Siddiqui, D.Romascanu, E. Golovinsky, and R. Smith,
"Real-time Application Quality of Service Monitoring (RAQMON)
MIB", Internet-Draft, draft-siddiqui-rmonmib-raqmon-mib-
01.txt, March 2002
RMON WG Expires September 2003 [Page 22]
INTERNET DRAFT RAQMON PDU March 2003
8. 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.
9. Security Considerations
There are a number of management objects defined in this MIB
that have a MAX-ACCESS clause of read-write and/or read-create.
Such objects may be considered sensitive or vulnerable in some
network environments. The support for SET operations in a
non-secure environment without proper protection can have a
negative effect on network operations.
It is thus important to control even GET access to these objects
and possibly to even encrypt the values of these object when
sending them over the network via SNMP. Not all versions of
SNMP provide features for such a secure environment.
SNMPv1 by itself is not a secure environment. Even if the
network itself is secure (for example by using IPSec), even then,
there is no control as to who on the secure network is allowed
to access and GET/SET (read/change/create/delete) the objects in
this MIB.
It is RECOMMENDED that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the
use of the User-based Security Model [RFC2274] and the
View-based Access Control Model [RFC2275] is RECOMMENDED.
RMON WG Expires September 2003 [Page 23]
INTERNET DRAFT RAQMON PDU March 2003
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those
principals (users) that have legitimate rights to indeed GET or
SET (change/create/delete) them.
It is also imperative that the RAQMON framework be able to provide the
following protection mechanisms:
1. Authentication - the RRC should be able to verify that a RAQMON
report was originated by whom ever claims to have sent it.
2. Privacy - RAQMON information include identification of the parties
participating in a communication session. RAQMON framework should be
able to provide protection from eavsdropping, to prevent an
un-authorized third party from gathering potentially sensitive
information. This can be achieved by using various payload encryption
technologies like DES, 3-DES, AES
3. Protection from Denial of Service attacks directed at the RRC -
RDSs send RAQMON reports as a side effect of an external event (for
example, a phone call is being received). An attacker can try and
overwhelm the RRC (or the network) by initiating a large number of
events (i.e., calls) for the purpose of swamping the RRC with too many
RAQMON PDUs.
To prevent DoS attacks against RRC, the RDS will send the first report
for a session only after the session has been in progress for the TBD
reporting interval. Sessions shorter than that will not be reported.
4. NAT and Firewall Friendly Design: Presence for IP addresses,
TCP/UDP ports information in RAQMON PDUs may be NAT un-friendly. In
such a scenario, where NAT Friendliness is a requirement, the RDS may
opt to not to provide IP Addresses in RAQMON PDU. Another way to avoid
this problem is by using NAT Aware Application Layer Gateways (ALGs)
to fill out IP Addresses in RAQMON PDUs.
10. IANA Considerations
This memo introduces 2 new ports for IANA registration and a "name" for specific RTCP APP name == "RAQMON", as specified in Section 5.2.2, at http://www.iana.org/numbers.html
11. Authors' Addresses
Anwar A. Siddiqui
Avaya Labs
307 Middletown Lincroft Road
RMON WG Expires September 2003 [Page 24]
INTERNET DRAFT RAQMON PDU March 2003
Lincroft, New Jersey 07738
USA
Tel: +1 732 852-3200
Fax: +1 732 817-5922
E-mail: anwars@avaya.com
Dan Romascanu
Avaya Inc.
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com
Eugene Golovinsky
BMC Software
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 September 2003 [Page 25]
INTERNET DRAFT RAQMON PDU March 2003
RMON WG Expires September 2003 [Page 26]
