One document matched: draft-ietf-rmonmib-raqmon-pdu-09.txt
Differences from draft-ietf-rmonmib-raqmon-pdu-08.txt
Internet Draft Anwar Siddiqui
draft-ietf-rmonmib-raqmon-pdu-09.txt Avaya Labs.
Category: Standards Track Dan Romascanu
Expires July 2005 Avaya Inc
Mahfuzur Rahman
Panasonic
Eugene Golovinsky
BMC Software
Yong Kim
Broadcom
6 January 2005
Transport Mappings for Real-time Application Quality of Service
Monitoring (RAQMON) Protocol Data Unit (PDU)
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This memo specifies two transport mappings of the Real-time
Application Quality of Service Monitoring (RAQMON) information model
defined in [RAQMON-FRAMEWORK] using TCP as a native transport and the
Simple Network Management Protocol (SNMP) to carry the RAQMON
RMON WG Expires July 2005 [Page 1]
INTERNET DRAFT RAQMON PDU January 2005
information from a RAQMON Data Source (RDS) to a RAQMON Report
Collector (RRC).
Distribution of this memo is unlimited.
Table of Contents
Status of this Memo..................................................1
Abstract.............................................................1
1 Introduction.......................................................3
2 Transporting RAQMON Protocol Data Units............................3
3 Congestion Safe RAQMON Operation..................................29
4 Normative References..............................................29
5 Informative References............................................30
6 Intellectual Property.............................................32
7 Acknowledgements..................................................32
8 Appendix..........................................................32
9 Security Considerations...........................................33
10 Authors' Addresses...............................................35
Full Copyright Statement............................................36
RMON WG Expires July 2005 [Page 2]
INTERNET DRAFT RAQMON PDU January 2005
1. Introduction
The Real-Time Application QoS Monitoring (RAQMON) Framework as
outlined by [RAQMON-FRAMEWORK] extends the Remote Monitoring family
of protocols (RMON) by defining entities such as RAQMON Data Sources
(RDS) and RAQMON Report Collectors (RRC) to perform various
application monitoring in real time. [RAQMON-FRAMEWORK] defines an
information model in the format of 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.
The following sections of this memo contain detailed specifications
for the usage of TCP and SNMP to carry RAQMON information.
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. Transporting RAQMON Protocol Data Units
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. As
part of the specification, this memo also specifies the usage of TCP
and SNMP as underlying transport protocols to carry RAQMON PDUs
between RDSs and RRCs. While two transport protocol choices have been
provided as options to chose from for RDS implementers, RRCs MUST
implement both transport options defined by this document to ensure
interoperability.
2.1 TCP as an RDS/RRC Network Transport Protocol
A transport binding using TCP is included within the RAQMON
specification to facilitate reporting from various types of embedded
devices that run applications such as Voice over IP, Voice over Wi-
Fi, Fax over IP, Video over IP, Instant Messaging (IM), E-mail,
software download applications, e-business style transactions, web
access from wired or wireless computing devices etc. For many of
these devices PDUs and a TCP-based transport fit the deployment
needs.
The RAQMON transport requirements for end-to-end congestion control
and reliability are inherently built into TCP as a transport
protocol.
The following section details the RAQMON PDU specifications. Though
transmitted as one Protocol Data Unit, a RAQMON PDU is functionally
RMON WG Expires July 2005 [Page 3]
INTERNET DRAFT RAQMON PDU January 2005
divided into two different parts, namely the basic part and
application extensions required for vendor specific extension
[RAQMON-FRAMEWORK]. Both functional parts trail SMI Network
Management Private Enterprise Codes currently maintained by IANA
http://www.iana.org/assignments/enterprise-numbers.
A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1.
The parameters carried by RAQMON PDUs as shown in figure 1 and their
semantics are defined in section 5 of [RAQMON-FRAMEWORK].
Vendors MUST use the Basic part of the PDU to report parameters pre-
listed here in the specification for interoperability as opposed to
using the application specific portion. Vendors MAY also use
application specific extensios to convey application, vendor, or
device specific parameters not included in the Basic part of the
specification, and explicitly publish such data externally to attain
extended interoperability.
2.1.1 The RAQMON PDU
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| 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) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RMON WG Expires July 2005 [Page 4]
INTERNET DRAFT RAQMON PDU January 2005
| Length | Receiver's Name (RN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Session State ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round Trip End-to-End Network Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One Way End-to-End Network Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Packet Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Application Packet Discard |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Packets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Packets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Octets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Octets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source Device Port Used | Receiver Device Port Used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Source Payload |Receiver | CPU | Memory |
|Type |Payload Type | Utilization | Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Setup Delay | Application Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Packet Delay Variation | Inter arrival Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding | Packet Discrd | Packet loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "xxx" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Type = "yyy" | Length of Application Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
RMON WG Expires July 2005 [Page 5]
INTERNET DRAFT RAQMON PDU January 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "abc" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Type = "zzz" | Length of Application Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - RAQMON Protocol Data Unit
2.1.2 The Basic Part of the RAQMON Protocol Data Unit
A RAQMON PDU must contain the following basic part fields at all
times:
PDU type (PDT): 5 bits - This indicates the type of RAQMON PDU being
sent. PDT = 1 is used for the current RAQMON PDU version.
basic (B): 1 bit - While set to 1, the basic flag indicates that the
PDU has basic part of the RAQMON PDU. A value of zero is considered
to be valid and indicates a RAQMON NULL PDU.
trailer (T) : 3 bits - Total number of Application Specific
Extensions that trail the BASIC Part of RAQMON PDU. 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, 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. Padding may be needed in some cases as reporting is
based on the intent of a 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.
Source IP version Flag (S): 1 bit - While set to 1, the source IP
version flag indicates that the Source IP address contained in the
PDU is a IPv6 address.
Receiver IP version Flag (R): 1 bit - While set to 1, the receiver IP
version flag indicates that the receiver IP address contained in the
PDU is a IPv6 address.
RMON WG Expires July 2005 [Page 6]
INTERNET DRAFT RAQMON PDU January 2005
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 the Basic Part of the 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 [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 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. 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 RRC, but sending these parameters
occasionally will reduce the probability of DSRC collision
drastically. However this will cause an additional overhead per PDU.
A value of zero for basic (B) bit and trailer (T) bits 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 new information to send to RRC.
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
RMON WG Expires July 2005 [Page 7]
INTERNET DRAFT RAQMON PDU January 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - RAQMON Parameter Presence Flag in RAQMON PDU
Report Type: 8 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.
The basic part of Each RAQMON PDU consists of 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: 8 bits - The Record Count number indicates a sub-session within
a communication session. A value of zero is a valid record number.
The maximum number of records that can be described in one RAQMON
Packet is 256.
RAQMON Parameter Presence Flags (RPPF): 32 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
Parameter within this RAQMON PDU
0 Data Source Address (DA)
1 Receiver Address (RA)
2 NTP Timestamp
3 Application Name
4 Data Source Name (DN)
5 Receiver Name (RN)
6 Session Setup Status
7 Session Duration
8 Round Trip End-to-End Network Delay (RTT)
9 One Way End-to-End Network Delay (OWD)
0 Cumulative Packets Loss
1 Cumulative Packets Discards
2 Total number of Application Packets sent
3 Total number of Application Packets received
4 Total number of Application Octets sent
5 Total number of Application Octets received
6 Data Source Device Port Used
7 Receiver Device Port Used
8 Source Layer 2 Priority
9 Source Layer 3 Priority
RMON WG Expires July 2005 [Page 8]
INTERNET DRAFT RAQMON PDU January 2005
0 Destination Layer 2 Priority
1 Destination Layer 3 Priority
2 Source Payload Type
3 Receiver Payload Type
4 CPU Utilization
5 Memory Utilization
6 Session Setup Delay
7 Application Delay
8 IP Packet Delay Variation
9 Inter arrival Jitter
0 Packet loss (in fraction)
1 Packet Discard (in fraction)
Table 1: RAQMON Parameters and corresponding RPPF
Data Source Address (DA): 32 bits or 160 bits in binary
representation - This metrics is defined in section 5.1 of [RAQMON-
FRAMEWORK]. IP version 6 addresses are incorporated in Data Source
Address by setting the source IP version flag (S bit) of the RAQMON
PDU header to 1.
Receiver Address (RA): 32 bits or 160 bits - This metrics is defined
in section 5.2 of [RAQMON-FRAMEWORK]. Follows exact same syntax as
Data Source Address but used to indicate a Receiver's Address. IP
version 6 addresses are incorporated in Receiver Address by setting
the receiver IP version flag (R bit) of the RAQMON PDU header to 1.
Data Source Name (DN): - This metric 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 followed by 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. Applications SHOULD instruct RDSs to send
out the Data Source Name infrequently 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 metric 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
followed by the text itself. The Receiver Name is a multiple of 32
bits and follows the same padding rules as applied to the Data Source
Name. 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 success of
RMON WG Expires July 2005 [Page 9]
INTERNET DRAFT RAQMON PDU January 2005
reaching a RRC and also conserve network bandwidth.
Data Source Device Port Used: 16 bits - This metric 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 RC_N session while
this RAQMON PDU was generated.
Receiver Device Port Used: 16 bits - This metric 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 Device Port Used.
Session Setup Date/Time (NTP timestamp): 64 bits - This metric is
defined in section 5.7 of [RAQMON-FRAMEWORK] 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.
A Data Source that does not support NTP 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 the setup 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.
Session Setup Delay: 16 bits - The Session Setup Delay metric is
defined in section 5.8 of [RAQMON-FRAMEWORK] and expressed in
milliseconds.
Session Duration: 32 bits - The Session Setup Duration metric is
defined in section 5.9 of [RAQMON-FRAMEWORK]. Session Duration is an
unsigned integer expressed in seconds.
Session Setup Status: - The Session Setup Status is defined in
section 5.10 of [RAQMON-FRAMEWORK]. This field starts with an 8-bit
length field followed by the text itself. Session Setup Status is a
multiple of 32 bits.
Round Trip End-to-End Network Delay: 32 bits - The Round Trip End-to-
End Network Delay is defined in section 5.11 of [RAQMON-FRAMEWORK].
This field represents the Round Trip End-to-End Delay of session
RC_N, which is an unsigned integer, expressed in milliseconds.
One Way End-to-End Network Delay: 32 bits - The One Way End-to-End
Network 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 milliseconds.
RMON WG Expires July 2005 [Page 10]
INTERNET DRAFT RAQMON PDU January 2005
Application Delay: 16 bits - The Application Delay is defined in
section 5.13 of [RAQMON-FRAMEWORK] and is represented as an unsigned
integer expressed in milliseconds
Inter-Arrival Jitter: 16 bits - The Inter-Arrival Jitter is defined
in section 5.14 of [RAQMON-FRAMEWORK] and is represented as an
unsigned integer expressed in milliseconds.
IP Packet Delay Variation: 16 bits - The IP Packet Delay Variation is
defined in section 5.15 of [RAQMON-FRAMEWORK] and is represented as
an unsigned integer expressed in milliseconds.
Total number of Application Packets received: 32 bits - This
parameter is defined in section 5.16 of [RAQMON-FRAMEWORK] and is
represented as an unsigned integer, representing the total number of
packets transmitted within sub-session RC_N by the receiver.
Total number of Application Packets sent: 32 bits - This parameter is
defined in section 5.17 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.18 of [RAQMON-FRAMEWORK] as an unsigned
integer representing the total number of payload octets (i.e., not
including header or padding) transmitted 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.19 of [RAQMON-FRAMEWORK] as an unsigned integer,
representing the total number of payload octets (i.e., not including
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.20 of [RAQMON-FRAMEWORK] as an unsigned integer,
representing the total number of packets from sub-session RC_N that
have been lost while this RAQMON PDU was generated.
Packet Loss in Fraction: 8 bits - This parameter is defined in
section 5.21 of [RAQMON-FRAMEWORK] expressed as a fixed-point number,
with the binary point at the left edge of the field. The metric is
defined to be the number of packets lost divided by the number of
packets expected. The value is calculated by dividing the total
number of packets lost (after the effects of applying any error
protection such as FEC) by the total number of packets expected,
multiplying the result of the division by 256, limiting the maximum
value to 255 (to avoid overflow), and taking the integer part.
RMON WG Expires July 2005 [Page 11]
INTERNET DRAFT RAQMON PDU January 2005
Cumulative Application Discards: 32 bits - This parameter is defined
in section 5.22 of [RAQMON-FRAMEWORK] as an unsigned integer
representing the total number of packets from sub-session RC_N that
have been discarded while this RAQMON PDU was generated.
Packet Discard in Fraction: 8 bits - This parameter is defined in
section 5.23 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 discard
fraction by 256.) This metric is defined to be the number of packets
discarded divided by the total number of packets.
Source Payload Type: 8 bit - This parameter is defined in section
5.24 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the
payload type of the data source of the communication sub-session RC_N
as defined in [RFC 3550].
Receiver Payload Type: 8 bit - This parameter is defined in section
5.25 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the
receiver payload type of the communication sub-session RC_N.
S_Layer2: 8 bits - This parameter defined in section 5.26 of [RAQMON-
FRAMEWORK] is a 8-bit field associated to source's IEEE 802.1D
priority tagging of traffic in the communication sub-session RC_N.
Since IEEE 802.1 priority tags are 3 bits-long, the first 3 bits of
this parameter represent the IEEE 802.1 tag value and the last 5 bits
are padded to 0.
S_Layer3: 8 bits - This parameter defined in section 5.27 of [RAQMON-
FRAMEWORK] is a 8-bit field which represents the layer 3 QoS marking
used to send packets to the receiver by this data source during sub-
session RC_N.
D_Layer2: 8 bits - This parameter defined in section 5.28 of [RAQMON-
FRAMEWORK] is a 8-bit field which represents layer 2 IEEE 802.1D
priority tags 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 IEEE 802.1 priority tags are 3 bits-long, the
first 3 bits of this parameter represent the IEEE 802.1 priority tag
value and the last 5 bits are padded to 0.
D_Layer3: 8 bits - This parameter defined in section 5.29 of [RAQMON-
FRAMEWORK] is a 8-bit field which represents the 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.
CPU Utilization: 8 bits - This parameter defined in section 5.30 of
[RAQMON-FRAMEWORK] represents the percentage of CPU used during
RMON WG Expires July 2005 [Page 12]
INTERNET DRAFT RAQMON PDU January 2005
session RC_N up until the time this RAQMON PDU was generated. The CPU
Utilization is expressed in percents in the range 0 to 100. The value
should indicate not only CPU utilization associated to a session RC_N
but also actual CPU Utilization, to indicate a snapshot of the end
device CPU utilization while session RC_N in progress.
Memory Utilization: 8 bits - This parameter defined in section 5.31
of [RAQMON-FRAMEWORK] represents the percentage of total memory used
during session RC_N up until the time this RAQMON PDU was generated.
The memory utilization is expressed in percents 0 to 100. The Memory
Utilization value should indicate not only the memory utilization
associated to a session RC_N but the total memory utilization, to
indicate a snapshot of end device memory utilization while session
RC_N in progress.
Application Name: - This parameter is defined in section 5.32 of
[RAQMON-FRAMEWORK]. The Application Name field starts with an 8-bit
octet count describing the length of the text followed the text
itself. Application Name field is multiple of 32 bits.
padding: 0, 8, 16 or 24 bits - If the padding bit (P) is set , then
this field may be present. The actual padding at the end of the Basic
part of the PDU is 0,8, 16 or 24 bits to make the basic part of the
PDU multiple of 32 bits long.
2.1.3 APP Part of RAQMON Protocol Data Unit
The APP part of the RAQMON PDU is intended for experimental use as
new applications and new features are developed, without requiring a
PDU type value registration.
Vendors may design and publish application specific extensions. Any
RAQMON compliant RRC MUST be able to recognize vendors SMI Enterprise
Code and Report Type fields, and MUST recognize the presence of
application specific extensions that trail behind these fileds. 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 at
http://www.iana.org/assignments/enterprise-numbers. A Non-Zero SMI
Enterprise Code indicates a vendor or application specific extension.
RAQMON PDUs are capable of carrying multiple Application Parts within
a PDU.
Report Type: 16 bits - Vendors and Application developers should fill
in appropriate Report type within a specified SMI Enterprise Code. It
RMON WG Expires July 2005 [Page 13]
INTERNET DRAFT RAQMON PDU January 2005
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 in 32-bit words minus one, which
includes the header of the Application Part.
application-dependent data: variable length - Application/vendor-
dependent data is 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.1.4 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.
2.1.5 IANA Considerations
Applications using RAQMON Framework requires a single fixed port.
Port numbers 7XXX have been registered with IANA for use as the
default port for RAQMON PDUs over TCP. Hosts that run multiple
applications may use this port as an indication to have used RAQMON
or provision a separate TCP port as part of provisioning RAQMON RDS
and RAQMON Collector.
[editor note - 7XXX will be completely specified at RFC release,
after IANA allocates the number, and this note will be removed]
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.
2.2 SNMP Notifications as an RDS/RRC Network Transport Protocol
RMON WG Expires July 2005 [Page 14]
INTERNET DRAFT RAQMON PDU January 2005
It was 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. Choice of SNMP as a means
to transport RAQMON PDU was motivated by that intent.
If SNMP is chosen as a mechanism to transport RAQMON PDUs, the
following specification applies to RAQMON related usage of SNMP:
+ RDSs implement the capability of embedding RAQMON parameters in
SNMP Notifications, re-using well known SNMP mechanisms to
report RAQMON Statistics. The RAQMON RDS MIB module as
specified in 2.1.1 MUST be used in order to map the RAQMON PDUs
onto 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].
+ Since RDSs are not computationally rich and to keep the RDS
realization as lightweight as possible, RDSs MAY fail to
respond to SNMP requests like GET, SET, etc., with the
exception of the GET and SET commands required to implement the
User-Based Security Model (USM) defined by [RFC 3414].
+ In order to meet congestion safety requirements, SNMP INFORM
PDUs SHOULD be used. In case INFORM PDUs are used, RDSs MUST
process the SNMP INFORM responses from RRCs, and MAY serialize
the PDU transmission rate, i.e. limit the number of PDUS sent
in a specific time interval.
+ Standard UDP port 162 SHOULD be used for SNMP Notifications.
2.2.1 Encoding RAQMON PDUs using the RAQMON RDS MIB module
The RAQMON RDS MIB module is used to map RAQMON PDUs onto SNMP
Notifications for transport purposes. The MIB modules defines the
objects needed for mapping the Basic part of RAQMON PDU defined in
[RAQMON-FRAMEWOK] as well as the Notifications themselves. In order
to incorporate any application-specific extensions in the Application
(APP) part of RAQMON PDU as defined in [RAQMON-FRAMEWOK], additional
variable bindings MAY be included in RAQMON notifications as
described in the MIB module.
RMON WG Expires July 2005 [Page 15]
INTERNET DRAFT RAQMON PDU January 2005
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
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Counter32, Integer32, Unsigned32
FROM SNMPv2-SMI
DateAndTime
FROM SNMPv2-TC
rmon
FROM RMON-MIB
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB
Dscp
FROM DIFFSERV-DSCP-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF;
raqmonDsMIB MODULE-IDENTITY
LAST-UPDATED "200501060000Z" -- January 6, 2005
ORGANIZATION "RMON Working Group"
CONTACT-INFO
"WG EMail: rmonmib@ietf.org
Subscribe: rmonmib-request@ietf.org
MIB Editor:
Eugene Golovinsky
Postal: BMC Software, Inc.
2101 CityWest Boulevard,
Houston, TX, 77094
USA
Tel: +713-918-1816
Email: egolovin@bmc.com
"
DESCRIPTION
"This is the RAQMON Data Source notification MIB Module. It
provides a mapping of RAQMON PDUs to SNMP Notifications.
RMON WG Expires July 2005 [Page 16]
INTERNET DRAFT RAQMON PDU January 2005
Ds stands 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 (2005).
-- RFC EDITOR: please replace yyyy with actual number
This version of this MIB module is part of RFC yyyy; See the
RFC itself for full legal notices.
"
REVISION "200501060000Z" -- January 6, 2005
DESCRIPTION
"Changes following WG Last Call Comments."
REVISION "200410140000Z" -- October 14, 2004
DESCRIPTION
"Changes after the 60th IETF."
REVISION "200406150000Z" -- June 15, 2004
DESCRIPTION
"Changes after the 59th IETF."
REVISION "200311111150Z" -- November 11, 2003
DESCRIPTION
"Changes after the 58th IETF."
::= { rmon 32 }
-- This OID allocation conforms to [RFC3737]
raqmonDsEvents OBJECT IDENTIFIER ::= { raqmonDsMIB 0 }
raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDsMIB 1 }
raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDsMIB 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. It is indexed by the RAQMON Data Source,
sub-session, and address of the peer entity.
RMON WG Expires July 2005 [Page 17]
INTERNET DRAFT RAQMON PDU January 2005
Note that there is no concern about the indexation of this
table exceeding the limits defined by RFC 2578 Section 3.5.
According to [RAQMON-FRAMEWORK], Section 5.1, only IPv4 and
IPv6 addresses can be reported as participant addresses.
"
::= { 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, raqmonPeerAddrType,
raqmonPeerAddr }
::= { raqmonDsNotificationTable 1 }
RaqmonDsNotificationEntry ::= SEQUENCE {
raqmonDSRC Unsigned32,
raqmonRCN Integer32,
raqmonPeerAddrType InetAddressType,
raqmonPeerAddr InetAddress,
raqmonAppName SnmpAdminString,
raqmonDataSourceDevicePort Unsigned32,
raqmonReceiverDevicePort Unsigned32,
raqmonSessionSetupDateTime DateAndTime,
raqmonSessionSetupDelay Unsigned32,
raqmonSessionDuration Unsigned32,
raqmonSessionSetupStatus SnmpAdminString,
raqmonRoundTripEndToEndNetDelay Unsigned32,
raqmonOneWayEndToEndNetDelay Unsigned32,
raqmonApplicationDelay Unsigned32,
raqmonInterArrivalJitter Unsigned32,
raqmonIPPacketDelayVariation Unsigned32,
raqmonTotalPacketsReceived Counter32,
raqmonTotalPacketsSent Counter32,
raqmonTotalOctetsReceived Counter32,
raqmonTotalOctetsSent Counter32,
raqmonCumulativePacketLoss Counter32,
raqmonPacketLossFraction Unsigned32,
raqmonCumulativeDiscards Counter32,
raqmonDiscardsFraction Unsigned32,
raqmonSourcePayloadType Unsigned32,
raqmonReceiverPayloadType Unsigned32,
raqmonSourceLayer2Priority Unsigned32,
raqmonSourceDscp Dscp,
RMON WG Expires July 2005 [Page 18]
INTERNET DRAFT RAQMON PDU January 2005
raqmonDestinationLayer2Priority Unsigned32,
raqmonDestinationDscp Dscp,
raqmonCpuUtilization Unsigned32,
raqmonMemoryUtilization Unsigned32 }
raqmonDSRC OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Data Source identifier represents a unique session
descriptor that points to a specific communication session
between communicating entities. Identifiers unique for
sessions conducted between two entities are
generated by the communicating entities."
::= { raqmonDsNotificationEntry 1 }
raqmonRCN OBJECT-TYPE
SYNTAX Integer32 (0..15)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Record Count Number indicates a sub-session
within a communication session. A maximum number of 16
sub-sessions are supported - this limitation is dictated
by reasons of compatibility with other transport protocols."
::= { raqmonDsNotificationEntry 2 }
raqmonPeerAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of the Internet address of the peer participant
for this session."
REFERENCE
"Section 5.2 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 3 }
raqmonPeerAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Internet Address of the peer participant for this
session."
REFERENCE
"Section 5.2 of [RAQMON-FRAMEWORK]"
RMON WG Expires July 2005 [Page 19]
INTERNET DRAFT RAQMON PDU January 2005
::= { raqmonDsNotificationEntry 4 }
raqmonAppName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"This is a text string giving the name and possibly version
of the application associated with that session,
e.g., 'XYZ VoIP Agent 1.2'."
REFERENCE
"Section 5.28 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 5 }
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
by the Data Source device."
REFERENCE
"Section 5.5 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 6 }
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 [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 7 }
raqmonSessionSetupDateTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The time when session was initiated."
REFERENCE
"Section 5.7 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 8 }
raqmonSessionSetupDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
RMON WG Expires July 2005 [Page 20]
INTERNET DRAFT RAQMON PDU January 2005
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session setup time."
REFERENCE
"Section 5.8 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 9 }
raqmonSessionDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session duration, including setup time. The SYNTAX of this
object allows to express the duration of sessions that do
not exceed 4660 hours and 20 minutes."
REFERENCE
"Section 5.9 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 10 }
raqmonSessionSetupStatus OBJECT-TYPE
SYNTAX SnmpAdminString
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 [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 11 }
raqmonRoundTripEndToEndNetDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Most recent available information about the
round trip end to end network delay."
REFERENCE
"Section 5.11 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 12}
raqmonOneWayEndToEndNetDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
RMON WG Expires July 2005 [Page 21]
INTERNET DRAFT RAQMON PDU January 2005
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
" Most recent available information about the
one way end to end network delay."
REFERENCE
"Section 5.12 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 13}
raqmonApplicationDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
" Most recent available information about the
application delay."
REFERENCE
"Section 5.13 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 14}
raqmonInterArrivalJitter OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the inter-arrival jitter."
REFERENCE
"Section 5.14 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 15}
raqmonIPPacketDelayVariation OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the inter-arrival delay variation."
REFERENCE
"Section 5.15 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 16}
raqmonTotalPacketsReceived OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
RMON WG Expires July 2005 [Page 22]
INTERNET DRAFT RAQMON PDU January 2005
DESCRIPTION
"The number of packets transmitted within a communication
session by the receiver since starting transmission up until
the time this RAQMON PDU was generated.
"
REFERENCE
"Section 5.16 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 17 }
raqmonTotalPacketsSent OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packets transmitted within a communication
session by the sender since starting transmission up until
the time this RAQMON PDU was generated.
"
REFERENCE
"Section 5.17 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 18 }
raqmonTotalOctetsReceived OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The total number of payload octets (i.e., not including
header or padding octets) transmitted in packets by the
receiver within a communication session since starting
transmission up until the time this RAQMON PDU was
generated.
"
REFERENCE
"Section 5.18 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 19 }
raqmonTotalOctetsSent OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of payload octets (i.e., not including headers
or padding) transmitted in packets by the sender within
a communication session since starting transmission up
RMON WG Expires July 2005 [Page 23]
INTERNET DRAFT RAQMON PDU January 2005
until the time this RAQMON notification was generated."
REFERENCE
"Section 5.19 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 20 }
raqmonCumulativePacketLoss OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packets from this session whose loss had been
detected when this notification was generated.
"
REFERENCE
"Section 5.20 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 21 }
raqmonPacketLossFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The percentage of lost packets with respect to the overall
packets sent. This is defined to be 100 times the number
of packets lost divided by the number of packets expected."
REFERENCE
"Section 5.21 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 22 }
raqmonCumulativeDiscards OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packet discards
detected when this notification was generated."
REFERENCE
"Section 5.22 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 23 }
raqmonDiscardsFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
RMON WG Expires July 2005 [Page 24]
INTERNET DRAFT RAQMON PDU January 2005
DESCRIPTION
"The percentage of discards with respect to the overall
packets sent. This is defined to be 100 times the number
of discards divided by the number of packets expected."
REFERENCE
"Section 5.23 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 24 }
raqmonSourcePayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet sent by this RDS."
REFERENCE
"RFC 1890, Section 5.24 of [RAQMON-FRAMEWORK] "
::= { raqmonDsNotificationEntry 25 }
raqmonReceiverPayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet received by this RDS."
REFERENCE
"RFC 1890, Section 5.25 of [RAQMON-FRAMEWORK] "
::= { raqmonDsNotificationEntry 26 }
raqmonSourceLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Source Layer 2 priority used by the sata source to send
packets to the receiver by this data source during this
communication session.
"
REFERENCE
"Section 5.26 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 27 }
raqmonSourceDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Layer 3 TOS/DSCP values used by the Data Source to
prioritize traffic sent."
RMON WG Expires July 2005 [Page 25]
INTERNET DRAFT RAQMON PDU January 2005
REFERENCE
"Section 5.27 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 28 }
raqmonDestinationLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Destination Layer 2 priority. This is the priority use by
the peer communicating entity to send packets to the data
source.
"
REFERENCE
"Section 5.28 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 29 }
raqmonDestinationDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Layer 3 TOS/DSCP values used by the
peer communicating entiy to prioritize traffic
sent to the source."
REFERENCE
"Section 5.29 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 30 }
raqmonCpuUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Latest available information about the total CPU utilization."
REFERENCE
"Section 5.30 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 31 }
raqmonMemoryUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Latest available information about the total memory utilization."
REFERENCE
RMON WG Expires July 2005 [Page 26]
INTERNET DRAFT RAQMON PDU January 2005
"Section 5.31 of [RAQMON-FRAMEWORK]"
::= { raqmonDsNotificationEntry 32 }
-- definitions of the notifications
--
-- raqmonAppName is the only object that MUST be sent by an
-- RD every time the notification is generated.
-- Other objects from the raqmonDsNotificationTable may be included
-- in the variable binding list. Specifically, a raqmonDsNotification
-- will include MIB objects that provide information about metrics
-- that characterize the application session
--
raqmonDsNotification NOTIFICATION-TYPE
OBJECTS { raqmonAppName }
STATUS current
DESCRIPTION
"This notification maps the Basic RAQMON PDU onto an SNMP
transport.
"
::= { raqmonDsEvents 1 }
raqmonDsByeNotification NOTIFICATION-TYPE
OBJECTS { raqmonAppName }
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,
RMON WG Expires July 2005 [Page 27]
INTERNET DRAFT RAQMON PDU January 2005
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 { raqmonAppName,
raqmonDataSourceDevicePort,
raqmonReceiverDevicePort,
raqmonSessionSetupDateTime,
raqmonSessionSetupDelay,
raqmonSessionDuration,
raqmonSessionSetupStatus,
raqmonRoundTripEndToEndNetDelay,
raqmonOneWayEndToEndNetDelay,
raqmonApplicationDelay,
raqmonInterArrivalJitter,
raqmonIPPacketDelayVariation,
raqmonTotalPacketsReceived,
raqmonTotalPacketsSent,
raqmonTotalOctetsReceived,
raqmonTotalOctetsSent,
raqmonCumulativePacketLoss,
raqmonPacketLossFraction,
raqmonCumulativeDiscards,
raqmonDiscardsFraction,
raqmonSourcePayloadType,
raqmonReceiverPayloadType,
raqmonSourceLayer2Priority,
raqmonSourceDscp,
raqmonDestinationLayer2Priority,
raqmonDestinationDscp,
raqmonCpuUtilization,
raqmonMemoryUtilization }
STATUS current
DESCRIPTION
"These objects are required for entities claiming conformance
to this MIB."
::= { raqmonDsGroups 2 }
RMON WG Expires July 2005 [Page 28]
INTERNET DRAFT RAQMON PDU January 2005
END
3. Congestion-Safe RAQMON Operation
As outlined in earlier sections, TCP congestion control mechanism
provides inherent congestion safety features when TCP is implemnted
as transport to carry RAQMON PDU.
To ensure congestion safety, clearly the best thing to do is to use a
congestion-safe transport protocol such as TCP. If this is not
feasible, it may be necessary to fall back to UDP since SNMP over UDP
is more widely deployed transport protocol.
When SNMP is chosen as RAQMON PDU Transport, implementers MUST follow
section 3.0 of [RAQMON-FRAMEWORK] guidelines that outlines measures
that MUST be taken to use RAQMON in congestion safe manner.
Congestion safety requirements in section 3.0 of [RAQMON-FRAMEWORK]
would ensure that a RAQMON implementation using SNMP over UDP does
not lead to congestion under heavy network load.
4. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000.
RMON WG Expires July 2005 [Page 29]
INTERNET DRAFT RAQMON PDU January 2005
[RAQMON-FRAMEWORK] Siddiqui, A., Romascanu, D. and E. Golovinsky,
"Framework for Real-time Application Quality of Service
Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon-
framework-10.txt, January 2005.
5. Informative References
[RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321,
April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] H. Schulzrinne, "RTP Profile for Audio and Video
Conferences with Minimal Control" RFC 3550, July 2003.
[RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305,
March 1992.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de
Groot, "Address Allocation for Private Internets", RFC
1597, March 1994.
[RFC2679] G. Almes, S.Kalidindi and M.Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999
[RFC2680] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999
[RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay
Metric for IPPM", RFC 2681, September 1999
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, July 2003.
[ISO10646] International Standards Organization, "ISO/IEC DIS
10646-1:1993information technology -- universal multiple-
octet coded character set (UCS) -- part I: Architecture
RMON WG Expires July 2005 [Page 30]
INTERNET DRAFT RAQMON PDU January 2005
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
[RFC3291] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder "Textual Conventions for Internet Network
Addresses", RFC 3291, May 2002.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3414] Blumenthal U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 3414, December 2002.
[RFC3737] Wijnen B., and A.Bierman "IANA Guidelines for the
Registry of Remote Monitoring (RMON) MIB modules", RFC
3737, April 2004.
[3DES] American National Standards Institute, ANSI X9.52-1998,
"Triple Data Encryption Algorithm Modes of Operation"
1998.
[AES] Federal Information Processing Standard (FIPS),
"Specification for the ADVANCED ENCRYPTION
STANDARD(AES)", Publication 197, November 2001.
RMON WG Expires July 2005 [Page 31]
INTERNET DRAFT RAQMON PDU January 2005
6. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed,
and any of which we become aware will be disclosed, in accordance
with RFC 3668.
7. Acknowledgements
The authors would like to thank Bill Walker and Joseph Mastroguilio
from Avaya and Bin Hu from Motorola for their discussions. The
authors would also like to extend special thanks to Randy Presuhn,
who reviewed this document for spelling and formatting purposes, as
well as for a deep review of the technical content.
8.Appendix
The implementation notes included in Appendix are for informational
purposes only and are meant to clarify the RAQMON specification.
Pseudo code for RDS & RRC
We provide examples of Psuedo 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:
RMON WG Expires July 2005 [Page 32]
INTERNET DRAFT RAQMON PDU January 2005
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
}
9. Security Considerations
[RAQMON-FRAMEWORK] outlines a threat model associated with RAQMON and
security considerations to be taken into account in the RAQMON
specification to mitigate against those threats. It is imperative
that RAQMON PDU implementations be able to provide the following
protection mechanisms in order to attain end-to-end security:
1. Authentication - the RRC SHOULD be able to verify that a RAQMON
report was originated by the RDS claiming to have sent it. At
minimum, an RDS/RRC pair MUST use a digest-based authentication
procedure to authenticate, like the one defined in [RFC 1321].
2. Privacy - RAQMON information includes identification of the
parties participating in a communication session. RAQMON
deployments SHOULD be able to provide protection from
RMON WG Expires July 2005 [Page 33]
INTERNET DRAFT RAQMON PDU January 2005
eavesdropping, and to prevent an unauthorized third party from
gathering potentially sensitive information. This can be achieved
by using payload encryption technologies such as DES (Data
Encryption Standard), 3-DES [3DES], and AES (Advanced Encryption
Standard) [AES].
3. Protection from Denial of Service attacks directed at the RRC -
RDSs send RAQMON reports as a side effect of external events (for
example, receipt of a phone call). An attacker can try to
overwhelm the RRC (or the network) by initiating a large number of
events in order to swamp the RRC with excessive numbers of RAQMON
PDUs.
To prevent DoS (denial-of-service) attacks against the RRC, the
RDS will send the first report for a session only after the
session has been established, so that the session set-up process
is not affected.
4. NAT and Firewall Friendly Design: the presence of IP addresses and
TCP/UDP port information in RAQMON PDUs may be NAT unfriendly.
Where NAT-friendliness is a requirement, the RDS MAY omit IP
address information from the RAQMON PDU. Another way to avoid
this problem is by using NAT-Aware Application Layer Gateways
(ALGs) to ensure that correct IP addresses appear in RAQMON PDUs.
For the usage of TCP, TLS SHOULD be used to provide transport layer
security.
Following SNMP Specific guidelines SHOULD be followed to ensure a
secure implementation:
This memo also defines an RDS SNMP MIB module 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 module
design:
There are no management objects defined in this MIB module that have
a MAX-ACCESS clause of read-write and/or read-create. Consequently,
if this MIB module is implemented correctly, 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
RMON WG Expires July 2005 [Page 34]
INTERNET DRAFT RAQMON PDU January 2005
sensitivity/vulnerability:
raqmonDsNotificationTable
The objects in this table contain user session 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).
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. Authors' Addresses
Anwar A. Siddiqui
Avaya Labs
307 Middletown Lincroft Road
Lincroft, New Jersey 07738
USA
Tel: +1 732 852-3200
E-mail: anwars@avaya.com
Dan Romascanu
Avaya
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
Tel: +972-3-645-8414
Email: dromasca@avaya.com
Eugene Golovinsky
BMC Software
2101 CityWest Blvd.
Houston, Texas 77042
USA
Tel: +1 713 918-1816
RMON WG Expires July 2005 [Page 35]
INTERNET DRAFT RAQMON PDU January 2005
Email: eugene_golovinsky@bmc.com
Mahfuzur Rahman
Panasonic Digital Networking Lab
Two Research Way
Princeton, NJ 08540
Tel: +1 609 734 7332
Email: mahfuz@research.panasonic.com
Yongbum "Yong" Kim
Broadcom
3151 Zanker Road
San Jose, CA 95134
Tel: +1 408 501 7800
E-mail: ybkim@broadcom.com
A. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
RMON WG Expires July 2005 [Page 36]
INTERNET DRAFT RAQMON PDU January 2005
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement:
Funding for the RFC Editor function is currently provided by the
Internet Society.
RMON WG Expires July 2005 [Page 37]
| PAFTECH AB 2003-2026 | 2026-04-24 04:48:08 |