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)
Protocol Data Unit (PDU)
<draft-ietf-rmonmib-raqmon-pdu-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."
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 a
RAQMON Data Source (RDS) and a RAQMON Report Collector (RRC) to
report QOS statistics using RTCP and SNMP as Transport Protocols.
This memo also outlines mechanisms to use the Real Time Transport
Control Protocol (RTCP) and the Simple Network Management Protocol
(SNMP) to transport these PDUs between RAQMON Data Source (RDS) and
RAQMON Report Collector (RRC).
Distribution of this memo is unlimited.
RMON WG Expires December 2003 [Page 1]
INTERNET DRAFT RAQMON PDU June 2003
Table of Contents
Status of this Memo 1
Abstract 1
1 Introduction 2
2 RAQMON PDU Format 3
3 Transporting RAQMON Protocol Data Units 15
4 Congestion Safe RAQMON Operation 29
5 Normative References 29
6 Informative References 30
7 Intellectual Property 31
8 Security Considerations 32
9 IANA Considerations 33
10 Authors' Addresses 34
A Full Copyright Statement 34
1. Introduction
There is a need to extend the RMON framework [RFC2819] to monitor end
devices such as IP Phones, Pagers, Instant Message Clients, Mobile
Phones, and various other Hand held computing devices. Real-Time
Application QoS Monitoring (RAQMON) Framework as outlined by [RAQMON-
framework] extends RMON by defining entities such as RAQMON Data
Source (RDS) and RAQMON Report Collector (RRC) to perform various
application monitoring in Real-time. This memo defines a common
protocol data unit (PDU) used between a RAQMON Data Source (RDS) and
a RAQMON Report Collector (RRC) to report a QoS statistics. This memo
contains detailed RAQMON PDU specification and specifies usage of
RTCP and SNMP as an underlying transport protocols to carry RAQMON
PDUs. Either RTCP or SNMP is used to carry RAQMON PDU between RDS and
RRC.
The RAQMON Protocol Data Unit (PDU) is a common data format (i.e.
"Name" and "Value" pair) understood by RDS and RRC. 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.
Mechanisms outlined in this draft can be used by many Real-Time
Applications as well as for non-real time applications managed within
RMON Framework and allows network entities to report application
level QoS parameters in Realtime. 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 are few examples of applications that can
potentially use RAQMON Framework for monitoring purposes.
Though transmitted as one Protocol Data Unit, RAQMON PDU is
functionally divided into two different parts namely Basic Part and
RMON WG Expires December 2003 [Page 2]
INTERNET DRAFT RAQMON PDU June 2003
an Application specific extensions required for vendor specific
extension. Both functional parts trail behind SMI Network Management
Private Enterprise Codes and currently maintained by IANA
http://www.iana.org/assignments/enterprise-numbers.
BASIC Part of RAQMON PDU: The basic part of the RAQMON PDU trails
behind the SMI Network Management Private Enterprise Code 0 -
reserved by convention for use by the IETF RMON Working Group. 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 report only a
sub-set of the parameters listed in table 1 as discussed in later
sections.
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) pairs and defined by the application developers or
vendors. Application part of the RAQMON PDU trails behind the SMI
Network Management Private Enterprise Codes of the vendor found in
http://www.iana.org/assignments/enterprise-numbers. Such application
specific extensions should be maintained and published by the
application vendor.
Though RDS and RRC are designed to be mostly stateless for an entire
reporting session, the framework would require an indication for end
of reporting session between RDS and RRC. In order to achieve this
functionality, the RDS should send a RAQMON PDU with all NULL values
to indicate end of reporting session to RRC. A NULL PDU is a RAQMON
PDU with containing ALL NULL values (i.e. nothing to report) and a
NULL PDU specification is available in section 2.
Following sections of this memo contains detailed RAQMON PDU
specifications and usage of RTCP and SNMP to carry a RAQMON PDU.
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 PDU Format
Parameters carried by RAQMON PDUs are defined in [RAQMON-Framework]
through reference to existing IETF, ITU and other standards
organizations' documents.
RMON WG Expires December 2003 [Page 3]
INTERNET DRAFT RAQMON PDU June 2003
The RAQMON PDU format is specified in this memo provides syntax and
structure within a RAQMON PDU to report those parameters. A RAQMON
PDU in the current version is marked as PDU Type (PDT) = 1.
A RAQMON PDU has two parts i.e. Basic Part and an Application
specific Part. The applications vendors should use the Basic part of
the PDU to report statistics pre-listed here in the specification
which will ensure basic interoperability between multiple vendor and
application developers. It is also envisioned that vendors would use
application specific extension while needed to convey application-,
vendor-, device- etc. specific parameters not included in the Basic
part of the specification and publish such data to attain extended
interoperability.
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 |PDT = 1|B|T|P|I| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 | Report Type = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RC_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) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Session State ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RMON WG Expires December 2003 [Page 4]
INTERNET DRAFT RAQMON PDU June 2003
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "xxx" | Report Type = "yyy" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - RAQMON Protocol Data Unit
version (V) : 4 bits - Identifies the version of RAQMON. This version
is 1.
PDU type (PDT): 4 bits - This indicates the type of RAQMON PDU being
sent. PDT = 1 is used for current RAQMON PDU version.
RMON WG Expires December 2003 [Page 5]
INTERNET DRAFT RAQMON PDU June 2003
basic (B): 1 bit - While set to 1, basic flag indicates that the PDU
has Basic part of the RAQMON PDU. A value of zero is considered to be
valid as it may constitute a RAQMON NULL PDU.
trailer (T) : 1 bit - While set to 1, trailer flag indicates that the
PDU has Application specific extension. A value of zero is considered
to be valid as it may constitute a RAQMON NULL PDU.
padding (P): 1 bit - If the padding bit is set, this RAQMON PDU
contains some additional padding octets at the end of the Basic Part
of the PDU which are not part of the monitoring information as
padding may be needed by some applications as reporting is based on
the intent of RDS to report certain parameters. Also some parameters
may be reported only once at the beginning of the reporting session
e.g. Data Source Name, Receiver Name, Pay Load type etc. Actual
padding at the end of the Basic part of the PDU, is either 0,8, 16 or
24 bits to make the basic part of the PDU multiple of 32 bits long.
IP version (I): 1 bit - While set to 1, IP Version Flag indicates
that IP addresses contained in the PDU are IP version 6 compatible.
record count (RC): 4 bits - Total number of records contained in the
Basic part of the PDU. A value of zero is considered to be valid but
useless.
length: 16 bits - The length of this RAQMON PDU in 32-bit words minus
one which includes the header and any padding.
DSRC: 32 bits - Data Source identifier represents a unique RAQMON
reporting session descriptor that points to a specific reporting
session between RDS and RRC. Uniqueness of DSRC is valid only within
a reporting session. DSRC values should be randomly generated using
vendor chosen algorithms for each communication session. It is not
sufficient to obtain a DSRC simply by calling random() without
carefully initializing the state. One could use an algorithm like
the one defined in Appendix A.6 in [17] to create a DSRC. 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 for two different
reporting session, it is recommended that an RRC use parameters like
Data Source Address (DA), Data Source Name (DN), MAC Address in the
PDU in conjunction with a DSRC value. Though it is not mandatory for
RDSs to send parameters like Data Source Address (DA), Data Source
Name (DN), MAC Address in the every PDU sent to RRC, but sending
these parameters occasionally will reduce the probability of DSRC
collision drastically. However this will cause an additional overhead
per PDU.
RMON WG Expires December 2003 [Page 6]
INTERNET DRAFT RAQMON PDU June 2003
A RAQMON PDU must contain V, PDT, B, T, P, I, RC, length and DSRC
fields at all times. A value of zero for basic (B) bit and trailer
(T) bit set constitutes a RAQMON NULL PDU (i.e. nothing to report).
RDSs MUST send a RAQMON NULL PDU to RRC to indicate end of RDS
reporting session. All other parameters listed in the PDU described
below are optionally used when RDSs have some information to send to
RRC.
2.1 BASIC part of RAQMON Protocol Data Unit:
SMI Enterprise Code: 16 bits. A value of SMI Enterprise Code = 0 is
used to indicate RMON WG compliant Basic part of the RAQMON PDU
format. http://www.iana.org/assignments/enterprise-numbers. Basic
Part of the RAQMON PDU must trail behind the SMI Enterprise Code = 0
to ensure interoperability.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |PDT = 1|B|T|P|I| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 | Report Type = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - RAQMON Parameter Presence Flag in RAQMON PDU
Report Type: 16 bits - These bits are reserved by the IETF RMON Work
Group. A value of 0 within SMI Enterprise Code = 0 is used for this
version of the PDU.
Basic part of Each RAQMON PDU consists of Record Count Number (RC_N)
and RAQMON Parameter Presence Flags (RPPF) to indicate presence of
appropriate RAQMON parameters within a record 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 PDU contains
corresponding parameters as specified in table 1.
Sequence Number Presence/Absence of corresponding
RMON WG Expires December 2003 [Page 7]
INTERNET DRAFT RAQMON PDU June 2003
Parameter within this RAQMON PDU
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
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 1: RAQMON Parameters and corresponding RPPF
Data Source Name (DN): - The 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. If the
RMON WG Expires December 2003 [Page 8]
INTERNET DRAFT RAQMON PDU June 2003
network is known to be lossless, Applications should instruct a RDS
to send out parameters like this only once to ensure efficient usage
of network resources as this parameter is expected to remain constant
for the duration of the reporting session. However if RDSs are
operating in a lossy environment, this information should be sent out
occasionally over random time intervals to maximize success of
reaching a RRC.
Receiver Name (RN): - The Receiver Name is multiple of 32 bits.
Follows the same padding rules as applies to Data Source Name. As
Data Source Name and Receiver's Name are contiguous, i.e., items are
not individually padded to a 32-bit boundary. If the network is known
to be lossless, applications should instruct a RDS to send out
parameters like this only once to ensure efficient usage of network
resources as this parameter is expected to remain constant for the
duration of the reporting session. However if RDSs are operating in a
lossy environment, this information should be sent out occasionally
over random time intervals to maximize success of reaching a RRC.
Data Source Address (DA): 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 resources. If the network is
known to be lossless, Applications should instruct a RDS to send out
parameters like this only once to ensure efficient usage of network
resources as this parameter is expected to remain constant for the
duration of the reporting session. However if RDSs are operating in a
lossy environment, this information should be sent out occasionally
over random time intervals to maximize success of reaching a RRC.
IP addresses, TCP/UDP ports information should be removed (NAT un-
friendly). One of the ways to avoid this problem is to use
Application Layer Gateways (ALGs) to fill out IP Addresses on RDS's
behalf.
Receiver Address (RA): 32 bits - Follows exact same syntax as Data
Source Address but used to indicate a Receiver's Address. If the
network is known to be lossless, applications should instruct a RDS
to send out parameters like this only once to ensure efficient usage
of network resources as this parameter is expected to remain constant
for the duration of the reporting session. However if RDSs are
operating in a lossy environment, this information should be sent out
RMON WG Expires December 2003 [Page 9]
INTERNET DRAFT RAQMON PDU June 2003
occasionally over random time intervals t0 maximize the chances of
reaching a RRC.
Application Name: - The 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. If the network is known to be lossless,
Applications should instruct a RDS to send out parameters like this
only once to ensure efficient usage of network resources as this
parameter is expected to remain constant for the duration of the
reporting session. However if RDSs are operating in a lossy
environment, this information should be sent out occasionally over
random time intervals to maximize success of reaching a RRC.
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 Progressing, Call Established successfully, RSVP
reservation failed and various other status codes but encoded as a
text strings. If the network is known to be lossless, Applications
should instruct a RDS to send out parameters like this only once to
ensure efficient usage of network resources as this parameter is
RMON WG Expires December 2003 [Page 10]
INTERNET DRAFT RAQMON PDU June 2003
expected to remain constant for the duration of the reporting
session. However if RDSs are operating in a lossy environment, this
information should be sent out occasionally over random time
intervals to maximize success of reaching a RRC.
Session Duration: 32 bits - Session Duration from session RC_N is an
unsigned Integer expressed in the order of seconds.
Round Trip End-to-End Delay: 32 bits - Round Trip End-to-End Delay
from session RC_N is an unsigned Integer expressed in the order of
milliseconds.
One Way End-to-End Delay: 32 bits - One way End-to-End Delay from
session RC_N is an unsigned 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 session RC_N 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 session RC_N 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 session RC_N since starting transmission up
until the time this RAQMON PDU 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 session RC_N since starting
transmission up until the time this RAQMON PDU 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
RMON WG Expires December 2003 [Page 11]
INTERNET DRAFT RAQMON PDU June 2003
used by the application in RC_N session while this RAQMON PDU was
generated. If the network is known to be lossless, Applications
should instruct a RDS to send out parameters like this only once to
ensure efficient usage of network resources as this parameter may
remain constant for the duration of the reporting session. However if
RDSs are operating in a lossy environment, this information should be
sent out occasionally over random time intervals to maximize success
of reaching a RRC.
Receiver Port Used: 16 bits - Receiver port used by the application
to communicate to the receiver. Follows same syntax as as Source Port
Used. If the network is known to be lossless, Applications should
instruct a RDS to send out parameters like this only once to ensure
efficient usage of network resources as this parameter may remain
constant for the duration of the reporting session. However if RDSs
are operating in a lossy environment, this information should be sent
out occasionally over random time intervals to maximize success of
reaching a RRC.
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 tag value of 5 reported via S_Layer2 parameter would indicate
Video over IP from this data source prioritized by some Layer 2
switch. If the network is known to be lossless, Applications should
instruct a RDS to send out parameters like this only once to ensure
efficient usage of network resources as this parameter may remain
constant for the duration of the reporting session. However if RDSs
are operating in a lossy environment, this information should be sent
out occasionally over random time intervals to maximize success of
reaching a RRC.
S_Layer3: 8 bits - Layer 3 QoS marking 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 router or not. If the network is known to be
lossless, Applications should instruct a RDS to send out parameters
like this only once to ensure efficient usage of network resources as
this parameter may remain constant for the duration of the reporting
session. However if RDSs are operating in a lossy environment, this
information should be sent out occasionally over random time
intervals to maximize success of reaching a RRC.
D_Layer2: 8 bits - Layer 2 priorities used by the receiver to send
packets to the data source during this RC_N session if the Data
RMON WG Expires December 2003 [Page 12]
INTERNET DRAFT RAQMON PDU June 2003
Source can learn such information. If the network is known to be
lossless, Applications should instruct a RDS to send out parameters
like this only once to ensure efficient usage of network resources as
this parameter may remain constant for the duration of the reporting
session. However if RDSs are operating in a lossy environment, this
information should be sent out occasionally over random time
intervals to maximize success of reaching a RRC.
D_Layer3: 8 bits - Layer 3 QoS marking used by the receiver to send
packets to the data source during this communication session if the
Data Source can learn such information. If the network is known to be
lossless, Applications should instruct a RDS to send out parameters
like this only once to ensure efficient usage of network resources as
this parameter may remain constant for the duration of the reporting
session. However if RDSs are operating in a lossy environment, this
information should be sent out occasionally over random time
intervals to maximize success of reaching a RRC.
Source Payload Type: 8 bit - This document follows definition of
Payload Type (PT) as in [RFC1890]. This 8-bit field specifies the
type of audio, video or data media used to send packets to the
receiver by this data source during communication session RC_N. To
give an example, if an application ought to indicate that the Source
Pay Load Type used for a session were PCMA, Source Payload Field for
RC_N ought to be 8. Please refer to [RFC1890] for various other
Audio, Video and Data related payload types.
CPU Utilization: 8 bits - The percentage of CPU used during session
RC_N up until the time this RAQMON PDU was generated. CPU Utilization
value should indicate not only CPU Utilization associated to a
session RC_N but also actual CPU Utilization, to indicate a snapshot
of end device Memory Utilization while session RC_N in progress.
Memory Utilization: 8 bits - The percentage of total memory used
during session RC_N up until the time this RAQMON PDU was generated.
Memory Utilization value should indicate not only Memory Utilization
associated to a session RC_N but also actual Memory Utilization, to
indicate a snapshot of end device Memory Utilization while session
RC_N in progress.
Session Setup Delay: 16 bits - This parameter is expressed in
milliseconds. Indicates the duration of time required by a network
communication controller to set a media path between the
communicating entities or the end devices. Session Setup Delay is
Application context sensitive. For example Session Setup Delay of a
SIP call is measured as the elapsed time between an INVITE generated
from a User Agent to reception of a 200 OK. If the network is known
to be lossless, Applications should instruct a RDS to send out
RMON WG Expires December 2003 [Page 13]
INTERNET DRAFT RAQMON PDU June 2003
parameters like this only once to ensure efficient usage of network
resources as this parameter is expected to remain constant for the
duration of the reporting session. However if RDSs are operating in a
lossy environment, this information should be sent out occasionally
over random time intervals to maximize success of reaching a RRC.
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.
padding: 0, 8, 16 or 24 bits - As described earlier in this section
that if the padding bit (P) is set , the actual padding at the end of
the Basic part of the PDU is either 0,8, 16 or 24 bits to make the
basic part of the PDU multiple of 32 bits long.
2.2 APP part of RAQMON Protocol Data Unit (PDU):
The APP part of the RAQMON PDU is intended for experimental use as
new applications and new features are developed, without requiring
PDU type value registration.
Vendors are responsible for designing RDSs with appropriate SMI
Enterprise Code and publishing App specific extensions. Any RAQMON
compliant RRC must be able to recognize vendors SMI Enterprise Code
and Report Type but should be able to operate without recognizing
Application specific extensions that trails behind vendors specific
SMI Enterprise Code and Report Type.
SMI Enterprise Code: 16 bits - Vendors and Application developers
should fill in appropriate SMI Enterprise IDs available here
http://www.iana.org/assignments/enterprise-numbers. A Non-Zero SMI
Enterprise Code MUST be treated as a vendor or application specific
extension.
Report Type: 16 bits - Vendors and Application developers should fill
in appropriate Report type within a specified SMI Enterprise Code. It
is recommended that vendors publish app specific extensions and
maintain such report types for better interoperability.
application-dependent data: variable length - Application/vendor-
dependent data to be defined by the application developers. It is
interpreted by the vendor specific application and not by the RRC
RMON WG Expires December 2003 [Page 14]
INTERNET DRAFT RAQMON PDU June 2003
itself. It must be a multiple of 32 bits long.
2.3 Byte Order, Alignment, and Time Format of RAQMON PDUs
All integer fields are carried in network byte order, that is, most
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.
3. 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. 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. As
outlined in the RAQMON framework document both Real-Time Transport
Control Protocol (RTCP) and the Simple Network Management Protocol
(SNMP) can be used as a transport protocol. Section 3.1 specifies
RTCP APP Packets [RFC 1889] to carry RAQMON PDUs between RDS and RRC
and section 3.2.reflects usage of SNMP INFORM PDUs as transport
protocol. It is left upon the vendors to choose either RTCP or SNMP
to transport RAQMON PDU as it fit the deployment need. Guidance in
the form of Pros and cons of using each protocol has been provided in
appropriate sections.
3.1 Mapping RAQMON PDUs to RTCP as 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
an APP Packet (i.e. PT = 204) in Real-Time Transport Control Protocol
(RTCP). As outlined in RFC 1889, an RTCP APP packet allows
applications to define new RTCP packets. The RTCP APP packets are
intended for use as new applications and new features such as RAQMON
are developed, without requiring packet type value registration.
RAQMON Framework makes use of such extension to provide backward
compatibility to existing deployment. Within the RTCP framework, a
RAQMON PDU is represented as an Application Specific Report.
To be backward compatible RTCP APP packets used by RAQMON SHOULD be
Internet Assigned Numbers Authority (IANA) Registered.
RMON WG Expires December 2003 [Page 15]
INTERNET DRAFT RAQMON PDU June 2003
Figure 3 below shows how RAQMON framework can use RTCP APP Packets to
transport RAQMON PDUs between RDS/RRC pairs.
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 PDU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Using RTCP APP Packets to transport RAQMON PDUs
version (V), padding (P), length: As described for the SR packet
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 ASCII characters.
application-dependent data: variable length RAQMON PDUs sent by the
RDS in the format specified in Figure 3 will be interpreted by the
RAQMON Report Collector (RRC) and not RTP/RTCP itself. RAQMON PDUs
must be a multiple of 32 bits long.
+ During a monitored real-time session, the RDS emits a Report PDU
toward the RRC per configured transmission rate as provisioned by the
RDS. Such transmission is unidirectional in nature and follows
congestion safety guidelines outlined in RAQMON Framework
Specification.
+ The RRC collects the RAQMON PDUs and correlate them with its
database.
Though this is a simple one-way send protocol, the RDSs will not be
RMON WG Expires December 2003 [Page 16]
INTERNET DRAFT RAQMON PDU June 2003
capable of inferring whether a PDU was received by the RRC as RAQMON
PDUs could be transmitted over a lossy network. As outlined in RAQMON
Framework, RDS/RRC pairs rely on underlying transport protocol to
attain transport reliability.
3.1.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
}
3.1.2 Port Assignment
As specified in the previous sections the transport of RAQMON PDUs
can be performed using various underlying network transport protocols
like TCP and UDP.
Applications using 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 within a host sharing a RDS implementation may encounter
RMON WG Expires December 2003 [Page 17]
INTERNET DRAFT RAQMON PDU June 2003
difficulties as 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. RRCs may also
use this port as a default to receive RAQMON PDUs carried over RTCP
which will reduce configuration needs for RDSs.
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.
3.2 SNMP INFORM PDUs as RDS/RRC Network Transport Protocol
The idea is to re-use SNMP INFORM PDU. If SNMP is chosen as a
mechanism to transport RAQMON PDU, following specification applies:
+ RDSs implement the capability of embedding RAQMON parameters in
SNMP INFORM Request and thus re-using well known SNMP mechanisms to
report RAQMON Statistics. The RAQMON RDS MIB as identified in 3.2.1
should be used in order to map the RAQMON PDUs on SNMP Notifications
transport.
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). For a detailed overview of
the documents that describe the current Internet-Standard Management
Framework, please refer to section 7 of RFC 3410 [RFC3410].
+ Since RDSs are not computationally rich and to keep the RDS
realization lightweight, it is not required that RDSs fully implement
an SNMP-based Internet Management framework. Specifically RDSs MAY
NOT respond to SNMP requests like GET, SET, etc., as an SNMP
compliant responder would.
+ Since RRCs are computationally rich, RRCs should implement a SNMP
manager. RRCS should send an SNMP INFORM Response for each associated
SNMP INFORM originated by the RDS.
RMON WG Expires December 2003 [Page 18]
INTERNET DRAFT RAQMON PDU June 2003
+ RDSs may ignore the SNMP INFORM Responses in a network where
congestion may not be a critical need. However per RAQMON Framework
Specification, if better congestion safety is required, RDSs should
serialize PDU transmission rate by using these SNMP INFORM responses
from RRC.
+ Standard UDP port 162 shall be used for SNMP Notifications.
3.2.1 Encoding RAQMON PDU by using the RAQMON RDS MIB
The RAQMON RDS MIB will be used in order to map the RAQMON PDUs on
SNMP Notifications transport. The MIB defines the objects needed for
Basic part of RAQMON PDU mapping, as well as the Notification. In
order to incorporate any Application specific extensions in APP part
of RAQMON PDU, varbinds may be included in the RAQMON notifications
described in the MIB.
This section specifies a MIB module that is compliant to the SMIv2,
which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579
[RFC2579] and STD 58, RFC 2580 [RFC2580].
RAQMON-RDS-MIB DEFINITIONS ::= BEGIN
IMPORTS
enterprises,
Unsigned32,
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE
FROM SNMPv2-SMI
DateAndTime
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
raqmon, RaqmonDateAndTime
FROM RAQMON-MIB
Utf8String
FROM SYSAPPL-MIB
Dscp
FROM DIFFSERV-DSCP-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF;
raqmonDs MODULE-IDENTITY
LAST-UPDATED "200304021150Z" -- April 2, 2003
ORGANIZATION "RMON Working Group"
CONTACT-INFO
"
WG EMail: rmonmib@ietf.org
RMON WG Expires December 2003 [Page 19]
INTERNET DRAFT RAQMON PDU June 2003
Subscribe: rmonmib-request@ietf.org
MIB Editor:
Eugene Golovinsky
Postal: BMC Software, Inc.
2101 CityWest Blvd,
Houston, TX, 77094
USA
Tel: +713-918-1816
Email: egolovin@bmc.com
"
DESCRIPTION
"This is RAQMON Data Source notification Module.
It provides mapping of RAQMON PDU to SNMP Notification.
Ds is for data source.
Note that all of the object types defined in this
module are accessible-for-notify, and would consequently
not be available to a browser using simple Get, GetNext,
or GetBulk requests.
This is a branch of the RAQMON module.
"
REVISION "200304021150Z" -- April 2, 2003
::= { raqmon 3 }
raqmonDsEvents OBJECT IDENTIFIER ::= { raqmonDs 0 }
raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDs 1 }
raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDs 2 }
raqmonDsNotificationTable OBJECT-TYPE
SYNTAX SEQUENCE OF RaqmonRdsNotificationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This conceptual table provides the SNMP mapping
of the RAQMON Basic PDU.
Indexed by RAQMON session
"
::= { raqmonDsMIBObjects 1 }
raqmonDsNotificationEntry OBJECT-TYPE
SYNTAX RaqmonRdsNotificationEntry
MAX-ACCESS not-accessible
RMON WG Expires December 2003 [Page 20]
INTERNET DRAFT RAQMON PDU June 2003
STATUS current
DESCRIPTION
"The entry (row) is not retrievable and is not kept
by RDSs.
It serves data organization purpose only.
"
INDEX { raqmonDSRC }
::= { raqmonDsNotificationTable 1 }
RaqmonDsNotificationEntry ::=
SEQUENCE {
raqmonDSRC
Unsigned32
raqmonAppName
Utf8String
raqmonDataSourceDevicePort
Unsigned32
raqmonReceiverDevicePort
Unsigned32
raqmonSessionSetupDateTime
RaqmonDateAndTime
raqmonSessionSetupDelay
Unsigned32
raqmonSessionDuration
Unsigned32
raqmonSessionSetupStatus
Utf8String
raqmonRoundTripEndtoEndDelay
Unsigned32
raqmonOneWayEndtoEndDelay
Unsigned32
raqmonInterArrivalJitter
Unsigned32
raqmonTotalPacketsReceived
Counter32
raqmonTotalPacketsSent
Counter32
raqmonTotalOctetsReceived
Counter32
raqmonTotalOctetsSent
Counter32
raqmonCumulativePacketLoss
Counter32
raqmonPacketLossFraction
Unsigned32
raqmonSourcePayloadType
Unsigned32
RMON WG Expires December 2003 [Page 21]
INTERNET DRAFT RAQMON PDU June 2003
raqmonReceiverPayloadType
Unsigned32
raqmonSourceLayer2Priority
Unsigned32
raqmonDestinationLayer2Priority
Unsigned32
raqmonSourceDscp
Dscp
raqmonDestinationDscp
Dscp
raqmonCpuUtilization
Unsigned32
raqmonMemoryUtilization
Unsigned32
}
raqmonDSRC OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Data Source identifier represents a unique session
descriptor that points to a specific communication session
between communicating entities."
::= { raqmonDsNotificationEntry 1 }
raqmonAppName OBJECT-TYPE
SYNTAX Utf8String
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"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."
::= { raqmonDsNotificationEntry 2 }
raqmonDataSourceDevicePort OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The port number from which data for this session was sent."
::= { raqmonDsNotificationEntry 3 }
raqmonReceiverDevicePort OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS accessible-for-notify
STATUS current
RMON WG Expires December 2003 [Page 22]
INTERNET DRAFT RAQMON PDU June 2003
DESCRIPTION
"The port number where the data for this session was received."
::= { raqmonDsNotificationEntry 4 }
raqmonSessionSetupDateTime OBJECT-TYPE
SYNTAX RaqmonDateAndTime
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The time when session was initiated."
::= { raqmonDsNotificationEntry 5 }
raqmonSessionSetupDelay OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session setup time in milliseconds."
::= { raqmonDsNotificationEntry 6 }
raqmonSessionDuration OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session duration in seconds."
::= { raqmonDsNotificationEntry 7 }
raqmonSessionSetupStatus OBJECT-TYPE
SYNTAX Utf8String
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Describes appropriate communication session states e.g.
Call Established successfully, RSVP reservation
failed etc."
::= { raqmonDsNotificationEntry 8 }
raqmonRoundTripEndtoEndDelay OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Round trip end to end delay in milliseconds."
::= { raqmonDsNotificationEntry 9}
raqmonOneWayEndtoEndDelay OBJECT-TYPE
SYNTAX Unsigned32
RMON WG Expires December 2003 [Page 23]
INTERNET DRAFT RAQMON PDU June 2003
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"One way end to end delay in milliseconds."
::= { raqmonDsNotificationEntry 10}
raqmonInterArrivalJitter OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the statistical variance of packets
inter-arrival time expressed in milliseconds."
::= { raqmonDsNotificationEntry 11}
raqmonTotalPacketsReceived OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"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."
::= { raqmonDsNotificationEntry 12 }
raqmonTotalPacketsSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"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."
::= { raqmonDsNotificationEntry 13 }
raqmonTotalOctetsReceived OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"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."
::= { raqmonDsNotificationEntry 14 }
RMON WG Expires December 2003 [Page 24]
INTERNET DRAFT RAQMON PDU June 2003
raqmonTotalOctetsSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"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."
::= { raqmonDsNotificationEntry 15 }
raqmonCumulativePacketLoss OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The total number of packets from session
that have been lost while this notification was generated.
This number is expected to be less the number of packets
actually received."
::= { raqmonDsNotificationEntry 16 }
raqmonPacketLossFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The percentage of lost packets with respect to the overall packets
sent. This fraction is defined to be the number of packets lost
divided by the number of packets expected."
::= { raqmonDsNotificationEntry 17 }
raqmonSourcePayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet sent by this RD."
REFERENCE
"RFC 1890"
::= { raqmonDsNotificationEntry 18 }
raqmonReceiverPayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet received by this RD."
RMON WG Expires December 2003 [Page 25]
INTERNET DRAFT RAQMON PDU June 2003
REFERENCE
"RFC 1890"
::= { raqmonDsNotificationEntry 19 }
raqmonSourceLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Source Layer 2 priorities used to send packets to the
receiver by this data source during this communication
session."
::= { raqmonDsNotificationEntry 20 }
raqmonDestinationLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Destination Layer 2 priority."
::= { raqmonDsNotificationEntry 21 }
raqmonSourceDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Source DSCP value."
::= { raqmonDsNotificationEntry 22 }
raqmonDestinationDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Destination DSCP value."
::= { raqmonDsNotificationEntry 23 }
raqmonCpuUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Percentage of total CPU utilization over a time duration."
::= { raqmonDsNotificationEntry 24 }
raqmonMemoryUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
RMON WG Expires December 2003 [Page 26]
INTERNET DRAFT RAQMON PDU June 2003
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Percentage of total memory utilization over a time duration."
::= { raqmonDsNotificationEntry 25 }
--
-- definitions of the notifications
-- The object list includes only the OBJECTS that will be send by a
-- RD in any notification.
-- Other objects from the raqmonDsNotificationTable may be included
-- in the varbind.
raqmonDsNotification NOTIFICATION-TYPE
OBJECTS {
raqmonDSRC,
raqmonOneWayEndtoEndDelay,
raqmonInterArrivalJitter,
raqmonPacketLossFraction
}
STATUS current
DESCRIPTION
"This notification maps basic RAQMON PDU into SNMP transport."
::= { raqmonDsEvents 1 }
--
-- conformance information
-- These don't show up on the wire, so they only need to be unique.
--
raqmonDsCompliances OBJECT IDENTIFIER ::= { raqmonDsConformance 1 }
raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 }
raqmonDsBasicCompliances MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which
implement this MIB module."
MODULE -- this module
MANDATORY-GROUPS { raqmonDsNotificationGroup,
raqmonDsPayloadGroup }
::= { raqmonDsCompliances 1 }
raqmonDsNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { raqmonDsNotification }
STATUS current
DESCRIPTION
"The notifications implemented by an SNMP entity
claiming conformance to this MIB.
RMON WG Expires December 2003 [Page 27]
INTERNET DRAFT RAQMON PDU June 2003
"
::= { raqmonDsGroups 1 }
raqmonDsPayloadGroup OBJECT-GROUP
OBJECTS {
raqmonDSRC,
raqmonAppName,
raqmonDataSourceDevicePort,
raqmonReceiverDevicePort,
raqmonSessionSetupDateTime,
raqmonSessionSetupDelay,
raqmonSessionDuration,
raqmonSessionSetupStatus,
raqmonRoundTripEndtoEndDelay,
raqmonOneWayEndtoEndDelay,
raqmonInterArrivalJitter,
raqmonTotalPacketsReceived,
raqmonTotalPacketsSent,
raqmonTotalOctetsReceived,
raqmonTotalOctetsSent,
raqmonCumulativePacketLoss,
raqmonPacketLossFraction,
raqmonSourcePayloadType,
raqmonReceiverPayloadType,
raqmonSourceLayer2Priority,
raqmonDestinationLayer2Priority,
raqmonSourceDscp,
raqmonDestinationDscp,
raqmonCpuUtilization,
raqmonMemoryUtilization
}
STATUS current
DESCRIPTION
"These objects are required for entities
claiming conformance to this MIB.
"
::= { raqmonDsGroups 2 }
END
3.2.2 Pros and Cons of using SNMP Inform as RAQMON PDU Transport
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. Usage of SNMP to
carry RAQMON PDU, further reduces the need for specific RAQMON code
in the RRC, as it can use an SNMP manager implementation to process
Informs. However there are certain challenges in using SNMP for
RMON WG Expires December 2003 [Page 28]
INTERNET DRAFT RAQMON PDU June 2003
RAQMON as well.
i. 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.
ii. SNMP uses UDP only transport. Hence the only way to achieve
congestion safety is by serializing PDUs based on INFORM Responses in
RRC, resulting in reduced throughput inefficiency as transport layer
functionality provided by TCP or SCTP can never be used.
iii. 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.
iv. While a good mechanism to serialize RAQMON PDU Transmission, ACKs
for SNMP I NFORM from RRC also wastes network bandwidth and cause
throughput inefficiency. In a reasonable sized Enterprise and Service
provider systems this can be a significant amount of load.
As an alternate, SNMP Traps could be used to avoid such ACKs. This
will allow usage of SNMP without avoiding performance related issues
as mentioned above, but with the added disadvantage of reduced
congestion safety functionality.
4.0 Congestion Safe RAQMON Operation:
RAQMON PDU can be transmitted over multiple transport protocols. 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. To ensure congestion safety clearly the best thing to
do is to use a transport protocol like TCP or SCTP, etc. If this is
not feasible, it may be necessary to fall back to UDP. Implementers
should follow section 3.0 of [RAQMON-Framework] guidelines that
outlines measures that can be taken to use RAQMON in congestion safe
manner.
5. 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
RMON WG Expires December 2003 [Page 29]
INTERNET DRAFT RAQMON PDU June 2003
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
[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.
[RAQMON-Framework] A. Siddiqui, D.Romascanu, and E. Golovinsky,
"Framework for Real-time Application Quality of Service
Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon-
framework-02.txt, May 2003
6. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
RMON WG Expires December 2003 [Page 30]
INTERNET DRAFT RAQMON PDU June 2003
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:1993information 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
7. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
RMON WG Expires December 2003 [Page 31]
INTERNET DRAFT RAQMON PDU June 2003
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
8. Security Considerations
[RAQMON-Framework] memo outlined a threat model associated to RAQMON
and some security considerations taken into account within RAQMON
specification to alleviate those threats. It is imperative that the
RAQMON PDU implementations be able to provide the following
protection mechanisms to attain end-to-end security:
1. Authentication - the RRC should be able to verify that a RAQMON
report was originated by the RDS whom ever claims to have sent it. At
minimal, a RDS/RRC pairs could use a digest based authentication
procedure to authenticate.
2. Privacy - RAQMON information include identification of the parties
participating in a communication session. RAQMON framework should be
able to provide protection from eavesdropping, to prevent an
unauthorized 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.
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
RMON WG Expires December 2003 [Page 32]
INTERNET DRAFT RAQMON PDU June 2003
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.
This memo also defines a RDS SNMP MIB with the purpose of mapping the
RAQMON PDUs into SNMP Notifications. To attain end to end security
following measures has bee taken in RDS MIB implementation:
There are no management objects defined in this MIB module that have
a MAX-ACCESS clause of read-write and/or read-create. So, if this
MIB module is implemented correctly, then there is no risk that an
intruder can alter or create any management objects of this MIB
module via direct SNMP SET operations.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) 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 the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
raqmonDsNotificationTable
The objects in this table contain user sessions information, and
their disclosure may be sensitive in some environments.
SNMP versions prior to SNMPv3 did not include adequate security. Even
if the network itself is secure (for example by using IPSec), even
then, there is no control as to who on the secure network is allowed
to access and GET/SET (read/change/create/delete) the objects in this
MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Though not mandatory for RAQMON compliance, it is RECOMMENDED to
deploy SNMPv3 and to enable cryptographic security for RAQMON PDUs.
It is 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.
9. IANA Considerations
RMON WG Expires December 2003 [Page 33]
INTERNET DRAFT RAQMON PDU June 2003
This memo introduces one new port 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
10. 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
2101 CityWest Blvd.
Houston, Texas 77042
USA
Tel: +1 713 918-1816
Email: eugene_golovinsky@bmc.com
A. Full Copyright Statement
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
RMON WG Expires December 2003 [Page 34]
INTERNET DRAFT RAQMON PDU June 2003
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RMON WG Expires December 2003 [Page 35]
