Internet Draft Anwar Siddiqui
Avaya Inc.
Dan Romascanu
Avaya
Eugene Golovinsky
BMC Software
9 February 2004
Real-time Application Quality of Service Monitoring (RAQMON)
Protocol Data Unit (PDU)
<draft-ietf-rmonmib-raqmon-pdu-05.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or 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 (2004). All Rights Reserved.
Abstract
This memo defines a common protocol data unit (PDU) used between a
Real-Time Application QoS Monitoring (RAQMON) Data Source (RDS) and a
RAQMON Report Collector (RRC) to report application level Quality of
Service (QOS) statistics which allows to monitoring of end devices
such as IP phones, pagers, Instant Messaging clients, mobile phones,
and various other hand-held computing devices within the Remote
Monitoring (RMON) family of specifications.
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 the RAQMON Data Source (RDS)
RMON WG Expires August 2004 [Page 1]
INTERNET DRAFT RAQMON PDU February 2004
and the RAQMON Report Collector (RRC).
Distribution of this memo is unlimited.
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 Appendix 32
9 Security Considerations 33
10 IANA Considerations 34
11 Authors' Addresses 34
A Full Copyright Statement 35
1. Introduction
There is a need to add mechanisms within RMON [RFC2819] family of
specifications to monitor end devices such as IP phones, pagers,
Instant Messaging clients, mobile phones, and various other hand-held
computing devices. The 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 RDS and
RRC to report QoS statistics. This memo contains a syntactical
description of the RAQMON PDU structure and of the usage of RTCP and
SNMP as underlying transport protocols to carry RAQMON PDUs. Either
RTCP or SNMP can be used to carry RAQMON PDUs between RDSs and RRCs.
The RAQMON Protocol Data Unit (PDU) utilizes a common data format
understood by the RDS and the 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 and
non-real-time applications managed within the RMON family of
specifications which allows network appliances to report application
level QoS parameters in real time. Voice over IP, Fax over IP, Video
over IP, Instant Messaging (IM), Email, software download
applications, e-business style transactions, web access from
computing devices are a few examples of applications that can
RMON WG Expires August 2004 [Page 2]
INTERNET DRAFT RAQMON PDU February 2004
potentially use the RAQMON Framework for monitoring purposes.
Though transmitted as one Protocol Data Unit, a RAQMON PDU is
functionally divided into two different parts, namely the basic part
and the application extensions required for vendor specific
extensions. Both functional parts trail SMI Network Management
Private Enterprise Codes that are currently maintained by IANA at
http://www.iana.org/assignments/enterprise-numbers.
The Basic Part of RAQMON PDU: The basic part of the RAQMON PDU trails
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.
The Application Part of RAQMON PDU: Application and vendor specific
extensibility of RAQMON PDU is provided by the application part of
the RAQMON PDU to convey application-, vendor-, and device- specific
parameters for future use. Additional parameters can be defined by
application developers within the payload of the APP part of the PDU
as Type Length Value (TLV) tuples. The 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. RAQMON PDUs are also capable
of carrying multiple application parts within a PDU that trails
multiple SMI Network Management Private Enterprise Codes of the
vendor.
Though RDS and RRC are designed to be stateless for RAQMON reporting
sessions, the framework requires a graceful termination of reporting
sessions between RDSs and RRCs. Such functionality is achieved by
NULL PDUs as defined within the RAQMON Framework [RAQMON-FRAMEWORK].
A syntactical specification of the NULL PDUs is available in section
2 of this memo.
The following sections of this memo contain 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
RMON WG Expires August 2004 [Page 3]
INTERNET DRAFT RAQMON PDU February 2004
Parameters carried by RAQMON PDUs and their usages are defined in
Section 5 of [RAQMON-FRAMEWORK] by reference to existing IETF, ITU
and other standards organizations' documents.
The RAQMON PDU format 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.
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.
Vendors SHOULD also use application specific extension to convey
application-, vendor-, device- etc. specific parameters not included
in the basic part of the specification and publish such data
externally 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | RT = 0 | RC |I|P| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 August 2004 [Page 4]
INTERNET DRAFT RAQMON PDU February 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |j| Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding | Packet loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "xxx" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Type = "yyy" | Length of Application Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "abc" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Type = "zzz" | Length of Application Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RMON WG Expires August 2004 [Page 5]
INTERNET DRAFT RAQMON PDU February 2004
| ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - RAQMON Protocol Data Unit
DSRC: 32 bits - The data source identifier represents a unique RAQMON
reporting session descriptor that points to a specific reporting
session between the RDS and the RRC. The uniqueness of DSRC is valid
only within a reporting session between a RDS and RRC pair. 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
[RFC3550] to create a DSRC. Depending on the choice of algorithm,
there is a finite probability that two DSRCs from two different RDSs
may be the same. To further reduce the probability that two RDSs pick
the same DSRC for two different reporting sessions, it is recommended
that an RRC use parameters like Data Source Address (DA), Data Source
Name (DN), and MAC Address in the PDU in conjunction with a DSRC
value. It is not mandatory for RDSs to send parameters like Data
Source Address (DA), Data Source Name (DN), MAC Address in every PDU
sent to an RRC, but sending these parameters occasionally will reduce
the probability of DSRC collision drastically.
2.1 The basic part of RAQMON Protocol Data Unit:
SMI Enterprise Code: 32 bits. A value of SMI Enterprise Code = 0 is
used to indicate the RMON WG compliant basic part of the RAQMON PDU
format. The basic part of the RAQMON PDU must trail behind the SMI
Enterprise Code = 0 to ensure interoperability.
version (V) : 2 bits - Identifies the version of RAQMON Basic Part
that follows SMI Enterprise Code = 0. The number of this version is
1.
Report Type(RT): 8 bits - Reserved by the RMON WG to define
appropriate Report type within RMON SMI Enterprise Code = 0. The
number of this report type is 0.
record count (RC): 4 bits - The total number of records contained in
the basic part of the PDU which reflects a sub-session within a
communication session. A value of zero is considered to be valid as
it constitutes a NULL PDU.
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. A
value of 0 indicates that IP addresses contained in the PDU are IP
RMON WG Expires August 2004 [Page 6]
INTERNET DRAFT RAQMON PDU February 2004
version 4 compatible.
padding (P): 1 bit - If the padding bit is set, the basic part of the
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 because
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 a
multiple of 32 bits long.
length: 16 bits - The length of the basic part of the RAQMON PDU in
32-bit words minus one which includes the header and any padding.
A RAQMON PDU MUST contain DSRC, SMI Enterprise Code = 0, V, RT, RC,
I, P and Length fields at all times. A value of zero for Record Count
(RC) constitutes a RAQMON NULL PDU (i.e. nothing to report). RDSs
MUST send a RAQMON NULL PDU to RRC to indicate the end of reporting
session for a given DSRC. All other header parameters listed in the
PDU described below are optionally used when RDSs have some
information to send to RRCs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | RT = 0 | RC |I|P| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - RAQMON Parameter Presence Flag in RAQMON PDU
The basic part of each RAQMON PDU that trails behind SMI Enterprise
Code = 0 consists of a Record Count Number (RC_N) and RAQMON
Parameter Presence Flags (RPPF) to indicate the 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. Since a report from a RDS to a RRC may contain
information about sub-sessions within a communication session (e.g. a
Multimedia Call), Record Count Number (RC_N) serves as a sub-session
index within a reporting session for a given DSRC. A value of zero is
RMON WG Expires August 2004 [Page 7]
INTERNET DRAFT RAQMON PDU February 2004
a valid record number. The 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 means that sub-session RC_N contains
corresponding parameters as specified in table 1 within a sub-
session.
A value of ALL zeros is considered to be valid as it constitutes a
NULL sub-session (i.e. nothing to report within sub-session RC_N). A
RDS MUST send a NULL sub-session (i.e. RPPF = 0) to a RRC to indicate
that reporting on a particular sub-session has ended. RRCs MUST not
treat a NULL sub-session as end of a reporting session; rather an
explicit Record Count = 0 is used to indicate end of a reporting
session for a given DSRC.
Sequence Number Presence/Absence of corresponding
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 Jitter
8 Packet loss (in fraction)
RMON WG Expires August 2004 [Page 8]
INTERNET DRAFT RAQMON PDU February 2004
Table 1: RAQMON Parameters and corresponding RPPF
Data Source Address (DA): 32 bits or 160 bits - This metrics is
defined in section 5.1 of [RAQMON-FRAMEWORK]. The standard [RFC 3291]
octet string representation is used to represent the end device's
numeric address on the interface used for the communication session.
The standard representation of an IP Version 4 address is "dotted
decimal", also known as dotted quad. 135.8.45.178 is an example of a
valid Data Source Address. IP version 6 addresses are incorporated in
Data Source Address by setting the IP version flag (I bit) of the
RAQMON PDU header to 1. Since the Data Source Address is expected to
remain constant during the entire reporting session, applications
should avoid sending these parameters too often to ensure efficient
usage of network resources.
Receiver Address (RA): 32 bits or 160 bits - This metrics is defined
in section 5.2 of [RAQMON-FRAMEWORK]. It follows the exact same
syntax as Data Source Address but is used to indicate a receiver's
address. Since the Receiver Address is expected to remain constant
during entire reporting sessions, applications should avoid sending
these parameters too often to ensure efficient usage of network
resources.
Data Source Name (DN): - This metrics is defined in section 5.3 of
[RAQMON-FRAMEWORK]. 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 to denote the end of the string and the
remainder as needed to pad until the next 32-bit boundary.
Applications SHOULD instruct a RDS to send out parameters not too
frequently to ensure efficient usage of network resources as this
parameter is expected to remain constant for the duration of the
reporting session.
Receiver Name (RN): - This metrics is defined in section 5.4 of
[RAQMON-FRAMEWORK]. Like Data Source Name, the Receiver Name field
starts with an 8-bit octet count describing the length of the text
and the text itself. The Receiver Name is multiple of 32 bits. It
RMON WG Expires August 2004 [Page 9]
INTERNET DRAFT RAQMON PDU February 2004
follows the same padding rules that apply to Data Source Name. As
Data Source Name and Receiver Name are contiguous, items are not
individually padded to a 32-bit boundary. Since the Receiver name is
expected to remain constant during entire reporting sessions, this
information SHOULD be sent out occasionally over random time
intervals to maximize the chances of reaching a RRC and also conserve
network bandwidth.
Source Port Used: 16 bits - This metrics is defined in section 5.5 of
[RAQMON-FRAMEWORK] and describes the port number used by the Data
Source as used by the application in the RC_N session while this
RAQMON PDU was generated. Since sometimes the Source Port Used will
remain constant during entire reporting sessions, applications in
that case SHOULD avoid sending these parameters too often to ensure
an efficient usage of network resources.
Receiver Port Used: 16 bits - This metrics is defined in section 5.6
of [RAQMON-FRAMEWORK] and describes the receiver port used by the
application to communicate to the receiver. It follows same syntax as
Source Port Used. Since sometimes the Receiver Port Used will remain
constant during entire reporting sessions, applications in that case
SHOULD avoid sending these parameters too often to ensure an
efficient usage of network resources.
Session Setup Date/Time (NTP timestamp): 64 bits - This metrics is
defined in section 5.7 of [RAQMON-FRAMEWORK] and is represented using
the timestamp format of the Network Time Protocol (NTP), which is in
seconds [RFC 1305]. 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.
A Data Source that has no notion of wallclock or time SHOULD set the
appropriate RAQMON flag to 0 to avoid wasting 64 bits in the PDU.
Since the NTP time stamp is intended to provide Date/Time of a
session, it is RECOMMENDED that the NTP time stamp be used only in
the first RAQMON pdu in order to use network resources efficiently.
However such a recommendation is context sensitive and should be
enforced as deemed necessary by each application environment.
Session Setup Delay: 16 bits - Session Setup Delay metrics is defined
in section 5.8 of [RAQMON-FRAMEWORK] and is expressed in
milliseconds.
Session Duration: 32 bits - Session Setup Delay metrics is defined in
RMON WG Expires August 2004 [Page 10]
INTERNET DRAFT RAQMON PDU February 2004
section 5.9 of [RAQMON-FRAMEWORK]. Session Duration from sub-session
RC_N is an unsigned integer expressed in seconds.
Session Setup Status: - Session Setup Status is defined in section
5.10 of [RAQMON-FRAMEWORK]. This field starts with an 8-bit octet
count describing the length of the text and the text itself. Session
Setup Status is a multiple of 32 bits. Since the Session Setup Status
is expected to remain constant during entire reporting sessions,
applications SHOULD avoid sending these parameters too often to
ensure an efficient usage of network resources.
Round Trip End-to-End Delay: 32 bits - Round Trip End-to-End Delay is
defined in section 5.11 of [RAQMON-FRAMEWORK]. This field represents
the Round Trip End-to-End Delay of sub-session RC_N, which 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
defined in section 5.12 of [RAQMON-FRAMEWORK]. This field represents
the One Way End-to-End Delay of sub session RC_N, which is an
unsigned Integer, expressed in the order of milliseconds.
Jitter: 16 bits - Jitter is defined in section 5.13 of [RAQMON-
FRAMEWORK] and is expressed in milliseconds. Out of 16 bits, the
first 15 bits represent the value of jitter measured in the RDS. The
16th bit within the jitter field otherwise known as the j bit, while
set to 0 indicates that the jitter measurement within a PDU reflects
Inter-Arrival Jitter, and while set to 1 indicates that the jitter
measurement within a PDU reflects Absolute Jitter.
Total number of application packets received: 32 bits - This
parameter is defined in section 5.14 of [RAQMON-FRAMEWORK] as an
unsigned integer representing the total number of packets received
within sub session RC_N by the receiver.
Total number of application packets sent: 32 bits - This parameter is
defined in section 5.15 of [RAQMON-FRAMEWORK] as an unsigned integer
representing the total number of packets transmitted within sub
session RC_N by the sender.
Total number of application octets received: 32 bits - This parameter
is defined in section 5.16 of [RAQMON-FRAMEWORK] as an unsigned
integer representing total number of payload octets (i.e., not
including header or padding) received in packets by the receiver
within sub session RC_N.
Total number of application octets sent: 32 bits - This parameter is
defined in section 5.17 of [RAQMON-FRAMEWORK] as an unsigned integer
representing total number of payload octets (i.e., not including
RMON WG Expires August 2004 [Page 11]
INTERNET DRAFT RAQMON PDU February 2004
header or padding) transmitted in packets by the sender within sub
session RC_N.
Cumulative application packet Loss: 32 bits - This parameter is
defined in section 5.18 of [RAQMON-FRAMEWORK] as an unsigned integer
representing the total number of packets that has been lost from the
beginning of sub-session RC_N till this RAQMON PDU was generated.
This counter reflects cumulative packet loss within a sub-session
RC_N.
Packet Loss in Fraction: 8 bits - This parameter is defined in
section 5.19 of [RAQMON-FRAMEWORK] 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 metrics is defined to be the number of
packets lost divided by the number of packets expected.
Source Payload Type: 8 bit - This parameter is defined in section
5.20 of [RAQMON-FRAMEWORK]. It is an 8-bit field that specifies the
payload type of the data source of communication in sub session RC_N
as defined in [RFC 1890]. Since the Source Payload type does not vary
frequently during reporting sessions, applications SHOULD avoid
sending these parameters within RAQMON PDUs too often to ensure an
efficient usage of network resources. However applications such as
Voice over IP or Video over IP may go through various application
states as users activate features payload types may change. Example
of such scenario may include but not limited to call transferred to
another party, joining a conference bridge or even changing network
condition (i.e. a VoIP phone call using 64 kbps G.711 codec may have
to fall back to 8kbps G.729a codec as network bandwidth just became
scarce) etc. Changes in source payload type driven by various
application state MUST be reported within a RAQMON PDU.
Receiver Payload Type: 8 bit - This parameter is defined in section
5.21 of [RAQMON-FRAMEWORK]. This 8-bit field specifies receiver
payload type of communication sub session RC_N. Since the Receiver
Payload type does not vary frequently during reporting sessions,
applications SHOULD avoid sending these parameters within RAQMON PDU
too often to ensure an efficient usage of network resources. Changes
in receiver payload type driven by various application state as
described in earlier paragraph MUST be reported within a RAQMON PDU.
S_Layer2: 8 bits - This parameter defined in section 5.22 of [RAQMON-
FRAMEWORK] is an 8-bit field associated to the source's value of the
IEEE 802.1Q tag priority field in sub session RC_N. Since the
priority value is 3 bits, the first 3 bits of this parameter
represents priority value and the last 5 bits are padded to 0. Since
this parameter is expected to remain constant most of the time during
RMON WG Expires August 2004 [Page 12]
INTERNET DRAFT RAQMON PDU February 2004
entire reporting sessions, applications SHOULD avoid sending these
parameters too often to ensure an efficient usage of network
resources.
S_Layer3: 8 bits - This parameter defined in section 5.23 of [RAQMON-
FRAMEWORK] is an 8-bit field that represents layer 3 QoS marking used
to send packets to the receiver by this data source during sub-
session RC_N. Since most of the time the Source Layer 3 used in sub
session RC_N will remain constant, applications SHOULD avoid sending
these parameters within a PDU too often to ensure an efficient usage
of network resources.
D_Layer2: 8 bits - This parameter defined in section 5.24 of [RAQMON-
FRAMEWORK] is an 8-bit field, which represents the value of the IEEE
802.1Q tag priority field used by the receiver to send packets to the
data source during sub session RC_N session if the Data Source can
learn such information. Since the priority value is 3 bits, the first
3 bits of this parameter represents priority value and the last 5
bits are padded to 0. Since most of the time the Destination Layer 2
used will remain constant during entire reporting sessions,
applications SHOULD avoid sending these parameters within a PDU too
often to ensure an efficient usage of network resources.
D_Layer3: 8 bits - This parameter defined in section 5.25 of [RAQMON-
FRAMEWORK] is an 8-bit field that represents layer 3 QoS marking used
by the receiver to send packets to the data source during sub session
RC_N if the Data Source can learn such information. Since most of the
time the Destination Layer 3 used will remain constant during entire
reporting sessions, applications SHOULD avoid sending these
parameters within a PDU too often to ensure an efficient usage of
network resources.
CPU Utilization: 8 bits - This parameter defined in section 5.26 of
[RAQMON-FRAMEWORK] represents total CPU usage by an end device while
sub-session RC_N is in progress. This parameter represent a time
average of total CPU utilization from the last RAQMON PDU was sent
until the time this RAQMON PDU was generated. CPU Utilization value
SHOULD NOT be limited to CPU utilization associated to sub-session
RC_N, rather it SHOULD represent total CPU Utilization of the end
device while sub-session RC_N is in progress.
Memory Utilization: 8 bits - This parameter defined in section 5.27
of [RAQMON-FRAMEWORK] represents the percentage of total memory used
during sub-session RC_N up until the time this RAQMON PDU was
generated. Memory Utilization value SHOULD NOT be limited to memory
utilization associated to sub-session RC_N, rather it SHOULD
represent total memory Utilization of the end device while sub-
session RC_N is in progress.
RMON WG Expires August 2004 [Page 13]
INTERNET DRAFT RAQMON PDU February 2004
Application Name: - This parameter is defined in section 5.28 of
[RAQMON-FRAMEWORK]. The Application Name field starts with an 8-bit
octet count describing the length of the text and the text itself.
The Application Name field is multiple of 32 bits. Since the
Application Name is expected to remain constant during entire
reporting sessions, applications SHOULD avoid sending these
parameters within a PDU too often to ensure an efficient usage of
network resources.
padding: 0, 8, 16 or 24 bits - As described earlier in this section,
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 application specific extensions. Any
RAQMON compliant RRC MUST be able to recognize vendors SMI Enterprise
Code and Report Type, and MUST recognize the presence of application
specific extensions that trail behind vendors specific SMI Enterprise
Code and Report Type. There is no need for the RRC to understand the
semantics of the Enterprise specific parts of the PDU.
SMI Enterprise Code: 32 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.
RAQMON PDUs are capable of carrying multiple Application Parts within
a PDU that trails multiple SMI Network Management Private Enterprise
Codes of the vendor.
Report Type: 16 bits - Vendors and Application developers SHOULD fill
in the appropriate Report type within a specified SMI Enterprise
Code. It is RECOMMENDED that vendors publish application specific
extensions and maintain such report types for better
interoperability.
Length of the Application Part: 16 bits - The length of the
Application Part of the RAQMON PDU is 32-bit words minus one, which
includes the header of the Application Part.
RMON WG Expires August 2004 [Page 14]
INTERNET DRAFT RAQMON PDU February 2004
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
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, with
the 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 [RAQMON-FRAMEWORK] both the 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 3550] 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 fits 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 a unidirectional transfer of
a PDU from a RDS to a RRC. The protocol data units are mapped to an
APP Packet in Real-Time Transport Control Protocol (RTCP). The RTCP
APP packets are intended for use as new application layer protocols
such as RAQMON are developed. As recommended in RFC 3550, an RTCP APP
packet is redefined as follows for RAQMON usage and registered with
IANA using an RTCP packet type. The RAQMON Framework makes use of
such an extension to provide backward compatibility to existing
deployment. RTCP APP packets for the purpose of RAQMON usage do not
include the subtype and name fields as recommended in [RFC3550].
RMON WG Expires August 2004 [Page 15]
INTERNET DRAFT RAQMON PDU February 2004
Figure 3 below shows how RAQMON PDUs are mapped into RTCP APP
Packets.
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| XXXXX | PT=RMON=20X | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC = "DSRC" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "Part of RAQMON PDU that trails behind 32 bit DSRC" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Using RTCP APP Packets to transport RAQMON PDUs
version (V): 2 bits As described for the RTCP SR packet in RFC 3550.
padding (P): 1 bit If the padding bit is set, this RTCP APP packet
contains some additional padding octets at the end. The semantics of
this field are identical to the semantics of the padding field in the
SR packet, as defined by the RTP/RTCP specification [RFC 3550].
reserved: 5 bits This field is reserved for future definition. In
the absence of such definition, the bits in this field MUST be set to
zero and MUST be ignored by the receiver.
packet type (PT): 8 bits Contains the constant 20X to identify this
as an RTCP Packet carrying RAQMON PDUs. This value is registered
with the Internet Assigned Numbers Authority (IANA).
length: 16 bits As described for the RTCP Sender Report (SR) packet.
It indicates the length of this RAQMON PDU contained within this RTCP
packet in 32-bit words minus one, including the RAQMON PDU header and
any padding.
SSRC: 32 bits As defined in RFC 3550 SR Packet. While mapping RAQMON
PDU to RTCP, further optimization MAY be accomplished by re-using
DSRC values as SSRC for RTCP session.
RAQMON PDU: variable length The RAQMON Report Collector (RRC) and not
RTP/RTCP stack will interpret RAQMON PDUs sent by the RDS in the
format specified in Figure 3. RAQMON PDUs must be a multiple of 32
bits long.
3.1.1 Port Assignment
RMON WG Expires August 2004 [Page 16]
INTERNET DRAFT RAQMON PDU February 2004
As specified in the previous sections, RAQMON PDUs can be transported
using any underlying network transport protocols used by RTCP or
SNMP. Examples of such transport protocols are TCP, UDP and DCCP.
Applications using the 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
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 number 5XXX has been registered with IANA for use 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 described in the previous
paragraph. RRCs MAY also use this port as a default to receive RAQMON
PDUs carried over RTCP, which will reduce the amount of configuration
for RDSs.
Applications need not have a default port and may require that the
port be explicitly specified. The particular port number was chosen
to lie in the range above 5000 to accommodate the 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
If SNMP is chosen as a mechanism to transport RAQMON PDUs, the
following specification applies:
+ RDSs implement the capability of embedding RAQMON parameters in
SNMP INFORM Requests, re-using well known SNMP mechanisms to report
RAQMON Statistics. The RAQMON RDS MIB as specified in 3.2.1 MUST be
used in order to map the RAQMON PDUs on the 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].
RMON WG Expires August 2004 [Page 17]
INTERNET DRAFT RAQMON PDU February 2004
+ 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.
+ In order to meet congestion safety requirements, RDSs MUST process
the SNMP INFORM responses from RRCs, and MUST serialize the PDU
transmission rate.
+ 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
the basic part of RAQMON PDU mapping, as well as the Notification. In
order to incorporate any application specific extensions in the 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
Unsigned32,
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32
FROM SNMPv2-SMI
DateAndTime
FROM SNMPv2-TC
rmon
FROM RMON-MIB
Utf8String
FROM SYSAPPL-MIB
Dscp
FROM DIFFSERV-DSCP-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF;
raqmonDs MODULE-IDENTITY
LAST-UPDATED "200311111150Z" -- November 11, 2003
ORGANIZATION "RMON Working Group"
CONTACT-INFO
RMON WG Expires August 2004 [Page 18]
INTERNET DRAFT RAQMON PDU February 2004
"
WG EMail: rmonmib@ietf.org
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.
Copyright (c) The Internet Society (2003). This version of this MIB module is part of RFC yyyy; See the RFC itself for full legal notices.
"
REVISION "200311111150Z" -- November 11, 2003
DESCRIPTION
"Changes after the 58th IETF."
::= { rmon 32 }
raqmonDsEvents OBJECT IDENTIFIER ::= { raqmonDs 0 }
raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDs 1 }
raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDs 2 }
raqmonDsNotificationTable OBJECT-TYPE
SYNTAX SEQUENCE OF RaqmonDsNotificationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This conceptual table provides the SNMP mapping
of the RAQMON Basic PDU.
Indexed by RAQMON session
"
RMON WG Expires August 2004 [Page 19]
INTERNET DRAFT RAQMON PDU February 2004
::= { raqmonDsMIBObjects 1 }
raqmonDsNotificationEntry OBJECT-TYPE
SYNTAX RaqmonDsNotificationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The entry (row) is not retrievable and is not kept
by RDSs.
It serves data organization purpose only.
"
INDEX { raqmonDSRC,
raqmonRCN }
::= { raqmonDsNotificationTable 1 }
RaqmonDsNotificationEntry ::=
SEQUENCE {
raqmonDSRC
Unsigned32,
raqmonRCN
Integer32,
raqmonAppName
Utf8String,
raqmonDataSourceDevicePort
Unsigned32,
raqmonReceiverDevicePort
Unsigned32,
raqmonSessionSetupDateTime
DateAndTime,
raqmonSessionSetupDelay
Unsigned32,
raqmonSessionDuration
Unsigned32,
raqmonSessionSetupStatus
Utf8String,
raqmonRoundTripEndtoEndDelay
Unsigned32,
raqmonOneWayEndtoEndDelay
Unsigned32,
raqmonJitterType
INTEGER,
raqmonJitterValue
Unsigned32,
raqmonTotalPacketsReceived
Counter32,
raqmonTotalPacketsSent
Counter32,
RMON WG Expires August 2004 [Page 20]
INTERNET DRAFT RAQMON PDU February 2004
raqmonTotalOctetsReceived
Counter32,
raqmonTotalOctetsSent
Counter32,
raqmonCumulativePacketLoss
Counter32,
raqmonPacketLossFraction
Unsigned32,
raqmonSourcePayloadType
Unsigned32,
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 }
raqmonRCN OBJECT-TYPE
SYNTAX Integer32 (0..15)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The Record Count Number indicates a sub-session
within a communication session."
::= { raqmonDsNotificationEntry 2 }
raqmonAppName OBJECT-TYPE
SYNTAX Utf8String
MAX-ACCESS accessible-for-notify
RMON WG Expires August 2004 [Page 21]
INTERNET DRAFT RAQMON PDU February 2004
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."
REFERENCE
"Section 5.28 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 3 }
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."
REFERENCE
"Section 5.5 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 4 }
raqmonReceiverDevicePort OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The port number where the data for this session was received."
REFERENCE
"Section 5.6 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 5 }
raqmonSessionSetupDateTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The time when session was initiated."
REFERENCE
"Section 5.7 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 6 }
raqmonSessionSetupDelay OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session setup time in milliseconds."
REFERENCE
"Section 5.8 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 7 }
RMON WG Expires August 2004 [Page 22]
INTERNET DRAFT RAQMON PDU February 2004
raqmonSessionDuration OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session duration in seconds."
REFERENCE
"Section 5.9 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 8 }
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."
REFERENCE
"Section 5.10 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 9 }
raqmonRoundTripEndtoEndDelay OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Round trip end to end delay in milliseconds."
REFERENCE
"Section 5.10 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 10}
raqmonOneWayEndtoEndDelay OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"One way end to end delay in milliseconds."
REFERENCE
"Section 5.12 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 11}
raqmonJitterType OBJECT-TYPE
SYNTAX INTEGER
{
interArrival(1),
absolute(2)
}
RMON WG Expires August 2004 [Page 23]
INTERNET DRAFT RAQMON PDU February 2004
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The type of the jitter measurement as reported by the RDS."
REFERENCE
"Section 5.13 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 12}
raqmonJitterValue OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the jitter expressed in milliseconds."
REFERENCE
"Section 5.13 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 13}
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."
REFERENCE
"Section 5.14 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 14 }
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."
REFERENCE
"Section 5.15 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 15 }
raqmonTotalOctetsReceived OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS accessible-for-notify
STATUS current
RMON WG Expires August 2004 [Page 24]
INTERNET DRAFT RAQMON PDU February 2004
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."
REFERENCE
"Section 5.16 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 16 }
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."
REFERENCE
"Section 5.17 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 17 }
raqmonCumulativePacketLoss OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The total number of packets from session
those have been lost while this notification was generated.
This number is expected to be less the number of packets
actually received."
REFERENCE
"Section 5.18 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 18 }
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."
REFERENCE
"Section 5.19 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 19 }
RMON WG Expires August 2004 [Page 25]
INTERNET DRAFT RAQMON PDU February 2004
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, Section 5.20 of the [RAQMON FRAMEWORK] "
::= { raqmonDsNotificationEntry 20 }
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."
REFERENCE
"RFC 1890, Section 5.21 of the [RAQMON FRAMEWORK] "
::= { raqmonDsNotificationEntry 21 }
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."
REFERENCE
"Section 5.22 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 22 }
raqmonDestinationLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Destination Layer 2 priority."
REFERENCE
"Section 5.24 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 23 }
raqmonSourceDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Source DSCP value."
RMON WG Expires August 2004 [Page 26]
INTERNET DRAFT RAQMON PDU February 2004
REFERENCE
"Section 5.23 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 24 }
raqmonDestinationDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Destination DSCP value."
REFERENCE
"Section 5.25 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 25 }
raqmonCpuUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Percentage of total CPU utilization over a time duration."
REFERENCE
"Section 5.26 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 26 }
raqmonMemoryUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Percentage of total memory utilization over a time duration."
REFERENCE
"Section 5.27 of the [RAQMON FRAMEWORK]"
::= { raqmonDsNotificationEntry 27 }
--
-- 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,
raqmonRCN
}
STATUS current
DESCRIPTION
RMON WG Expires August 2004 [Page 27]
INTERNET DRAFT RAQMON PDU February 2004
"This notification maps basic RAQMON PDU into SNMP transport."
::= { raqmonDsEvents 1 }
raqmonDsByeNotification NOTIFICATION-TYPE
OBJECTS {
raqmonDSRC }
STATUS current
DESCRIPTION
"The BYE Notification. This Notification is the equivalent
of the RAQMON BYE PDU, which signals the end of a RAQMON
session."
::= { raqmonDsEvents 2 }
--
-- 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,
raqmonDsByeNotification }
STATUS current
DESCRIPTION
"The notifications implemented by an SNMP entity
claiming conformance to this MIB.
"
::= { raqmonDsGroups 1 }
raqmonDsPayloadGroup OBJECT-GROUP
OBJECTS {
raqmonDSRC,
raqmonRCN,
raqmonAppName,
raqmonDataSourceDevicePort,
raqmonReceiverDevicePort,
RMON WG Expires August 2004 [Page 28]
INTERNET DRAFT RAQMON PDU February 2004
raqmonSessionSetupDateTime,
raqmonSessionSetupDelay,
raqmonSessionDuration,
raqmonSessionSetupStatus,
raqmonRoundTripEndtoEndDelay,
raqmonOneWayEndtoEndDelay,
raqmonJitterType,
raqmonJitterValue,
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
4.0 Congestion Safe RAQMON Operation:
RAQMON PDU can be transmitted over multiple transport protocols. As specified in an earlier section, the transport of RAQMON PDUs can be performed using any underlying network transport protocols that is used by RTCP and SNMP. Examples of transport such protocols are TCP, UDP and DCCP.
A RAQMON PDU allows the usage of UDP as 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 DCCP, etc. If this is not feasible, it may be necessary to fall back to UDP. Implementers MUST follow section 3.0 of [RAQMON-FRAMEWORK] guidelines that outlines measures that MUST be taken to use RAQMON in congestion safe manner specially when using UDP for network transport that lacks congestion safety functionality at the transport layer.
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
SMIv2", STD 58, RFC 2579, April 1999.
RMON WG Expires August 2004 [Page 29]
INTERNET DRAFT RAQMON PDU February 2004
[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
[RFC 3550] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications"
RFC 3550, July 2003.
[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-05.txt, February 2004
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
1994.
RMON WG Expires August 2004 [Page 30]
INTERNET DRAFT RAQMON PDU February 2004
[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
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
RMON WG Expires August 2004 [Page 31]
INTERNET DRAFT RAQMON PDU February 2004
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. Appendix
The implementation notes included in this Appendix are for
informational purposes only and are meant to clarify the RAQMON
specification.
Pseudo code for RDS & RRC
We provide examples of Pseudo code for aspects of RDS and RRC. There
may be other implementation methods that are faster in particular
operating environments or have other advantages.
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 August 2004 [Page 32]
INTERNET DRAFT RAQMON PDU February 2004
}
9. Security Considerations
The [RAQMON-FRAMEWORK] memo outlines a threat model associated to
RAQMON and some security considerations taken into account within the
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 who claims to have sent it. At
minimum, a RDS/RRC pair MUST use a digest based authentication
procedure to authenticate.
2. Privacy - RAQMON information includes identification of the
parties participating in a communication session. RAQMON deployment
SHOULD be able to provide protection from eavesdropping, and to
prevent an unauthorized third party from gathering potentially
sensitive information. This can be achieved by using 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 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.
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.
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
The following measures have been 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.
RMON WG Expires August 2004 [Page 33]
INTERNET DRAFT RAQMON PDU February 2004
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.
10. IANA Considerations
This document defines a new RTCP packet type, within the existing
Internet Assigned Numbers Authority (IANA) registry of RTP RTCP
Control Packet Types at http://www.iana.org/numbers.html. RTCP Packet
constant PT=20X as specified in Section 3.1 is reserved for RAQMON
usage.
This document also introduces a port for RAQMON usage of RTCP as
transport protocol.
11. Authors' Addresses
Anwar A. Siddiqui
Avaya Labs
RMON WG Expires August 2004 [Page 34]
INTERNET DRAFT RAQMON PDU February 2004
307 Middletown Lincroft Road
Lincroft, New Jersey 07738
USA
Tel: +1 732 852-3200
E-mail: anwars@avaya.com
Dan Romascanu
Avaya
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
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 August 2004 [Page 35]
INTERNET DRAFT RAQMON PDU February 2004
RMON WG Expires August 2004 [Page 36]
