Internet Draft Anwar Siddiqui Avaya Inc. Dan Romascanu Avaya Inc. Eugene Golovinsky BMC Software 10 September 2003 Real-time Application Quality of Service Monitoring (RAQMON) Protocol Data Unit (PDU) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines a common protocol data unit (PDU) used between a RAQMON Data Source (RDS) and a RAQMON Report Collector (RRC) to report application level QOS statistics required for extensions of the RMON Framework. 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) and the RAQMON Report Collector (RRC). Distribution of this memo is unlimited. RMON WG Expires March 2004 [Page 1] INTERNET DRAFT RAQMON PDU September 2003 Table of Contents Status of this Memo 1 Abstract 1 1 Introduction 2 2 RAQMON PDU Format 3 3 Transporting RAQMON Protocol Data Units 14 4 Congestion Safe RAQMON Operation 28 5 Normative References 28 6 Informative References 29 7 Intellectual Property 30 8 Appendix 31 9 Security Considerations 32 10 IANA Considerations 33 11 Authors' Addresses 33 A Full Copyright Statement 34 1. Introduction There is a need to extend the RMON framework [RFC2819] to monitor end devices such as IP phones, pagers, Instant 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 RDS and RRC. A RAQMON PDU does not transport application data but rather occupies the place of a payload specification at the application layer of the protocol stack. Mechanisms outlined in this draft can be used by many real-time and non-real time applications managed within the RMON Framework which allows network entities 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 potentially use 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 RMON WG Expires March 2004 [Page 2] INTERNET DRAFT RAQMON PDU September 2003 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 RDS and RRC. Such functionality is achieved by NULL PDUs as defined within RAQMON Framework [RAQMON-Framework]. A syntactical specification of NULL PDU 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 Parameters carried by RAQMON PDUs and their usages are defined in sub section 5 of [RAQMON-FRAMEWORK] by reference to existing IETF, ITU and other standards organizations' documents. RMON WG Expires March 2004 [Page 3] INTERNET DRAFT RAQMON PDU September 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |PDT = 1|B| T |P|I| RC | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = 0 | Report Type = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Source Address {DA} | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Address (RA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Application Name (AN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Data Source Name (DN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Receiver's Name (RN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Session State ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Duration | RMON WG Expires March 2004 [Page 4] INTERNET DRAFT RAQMON PDU September 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Round Trip End-to-End Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One Way End-to-End Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative Packet Loss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Packets sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Packets received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Octets sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Octets received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Used | Receiver Port Used | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Source Payload |Reciver Payload| CPU | Memory | |Type | Type | Utilization | Utilization | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Setup Delay | Inter arrival Jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | Packet loss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - RAQMON Protocol Data Unit RMON WG Expires March 2004 [Page 5] INTERNET DRAFT RAQMON PDU September 2003 version (V) : 2 bits - Identifies the version of RAQMON. The number of this version is 1. PDU type (PDT): 4 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 the basic part of the RAQMON PDU. A value of zero is considered to be valid as it may constitute a RAQMON NULL PDU. trailer (T) : 3 bits - Total number of Application Specific Extension that trails 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 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. IP version (I): 1 bit - While set to 1, IP Version Flag indicates that IP addresses contained in the PDU are IP version 6 compatible. record count (RC): 4 bits - The 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 - The data source identifier represents a unique RAQMON reporting session descriptor that points to a specific reporting session between RDS and RRC. The uniqueness of DSRC is valid only within a reporting session. DSRC values should be randomly generated using vendor chosen algorithms for each communication session. It is not sufficient to obtain a DSRC simply by calling random() without carefully initializing the state. One could use an algorithm like the one defined in Appendix A.6 in [17] to create a DSRC. Depending on the choice of algorithm, there is a finite probability that two DSRCs from two different RDSs may be 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 RMON WG Expires March 2004 [Page 6] INTERNET DRAFT RAQMON PDU September 2003 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 the every PDU sent to RRC, but sending these parameters occasionally will reduce the probability of DSRC collision drastically. However this will cause an additional overhead per PDU. A RAQMON PDU must contain V, PDT, B, T, P, I, RC, length and DSRC fields at all times. A value of zero for basic (B) bit and trailer (T) bits set constitutes a RAQMON NULL PDU (i.e. nothing to report). RDSs MUST send a RAQMON NULL PDU to RRC to indicate the end of the RDS reporting session. All other parameters listed in the PDU described below are optionally used when RDSs have some information to send to RRC. 2.1 The basic part of RAQMON Protocol Data Unit: SMI Enterprise Code: 16 bits. A value of SMI Enterprise Code = 0 is used to indicate RMON WG compliant basic part of the RAQMON PDU format. The basic part of the RAQMON PDU must trail behind the SMI Enterprise Code = 0 to ensure interoperability. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |PDT = 1|B| T |P|I| RC | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = 0 | Report Type = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - RAQMON Parameter Presence Flag in RAQMON PDU Report Type: 16 bits - These bits are reserved by the IETF RMON Work Group. A value of 0 within SMI Enterprise Code = 0 is used for this version of the PDU. 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: 4 bits - Record Count number to which the information in this record pertains. Record Count number indicates a sub-session within a communication session. A value of zero is a valid record number. The RMON WG Expires March 2004 [Page 7] INTERNET DRAFT RAQMON PDU September 2003 maximum number of records that can be described in one RAQMON Packet is 16 (i.e. 0000 - 1111). RAQMON Parameter Presence Flags (RPPF): 28 bits Each of these flags while set represent that this RAQMON PDU contains corresponding parameters as specified in table 1. Sequence Number Presence/Absence of corresponding Parameter within this RAQMON PDU 1 Data Source Address (DA) 2 Receiver Address (RA) 3 NTP Timestamp 4 Application Name 5 Data Source Name (DN) 6 Receiver Name (RN) 7 Session Setup Status 8 Session Duration 9 End-to-End Delay (RTT) 0 End-to-End Delay (OWD) 1 Cumulative Packet Loss 2 Total number of Packets sent 3 Total number of Packets received 4 Total number of Octets sent 5 Total number of Octets received 6 Source Port Used 7 Receiver Port Used 8 S_Layer2 9 S_Layer3 0 D_Layer2 1 D_Layer3 2 Source Payload Type 3 Receiver Payload Type 4 CPU Utilization 5 Memory Utilization 6 Session Setup Delay 7 Inter arrival Jitter 8 Packet loss (in fraction) Table 1: RAQMON Parameters and corresponding RPPF Data Source 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 RMON WG Expires March 2004 [Page 8] INTERNET DRAFT RAQMON PDU September 2003 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 follows the same padding rules as apply to Data Source Name. As Data Source Name and Receiver's Name are contiguous, i.e., items are not individually padded to a 32-bit boundary. 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 reaching a RRC and also conserve network bandwidth. RMON WG Expires March 2004 [Page 9] INTERNET DRAFT RAQMON PDU September 2003 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 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 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 efficient usage of network resources. Session Setup Date/Time (NTP timestamp): 64 bits - This metrics 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. 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 NTP time stamp is intended to provide Date/Time of a session, it is recommended that the NTP Timestamp be used only in the first RAQMON 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 expressed in milliseconds. Session Duration: 32 bits - Session Setup Delay metrics is defined in section 5.9 of [RAQMON-FRAMEWORK]. Session Duration from 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 RMON WG Expires March 2004 [Page 10] INTERNET DRAFT RAQMON PDU September 2003 ensure 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 Round Trip End-to-End Delay of 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 One Way End-to-End Delay of sub session RC_N which is an unsigned Integer expressed in the order of milliseconds. Inter-Arrival Jitter: 16 bits - Inter-Arrival Jitter is defined in section 5.13 of [RAQMON-FRAMEWORK] expressed in milliseconds. Total number of application packets received: 32 bits - This parameter is defined in section 5.14 of [RAQMON-FRAMEWORK] as an unsigned integer representing 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.15 of [RAQMON-FRAMEWORK] as an unsigned integer representing 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) 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.17 of [RAQMON-FRAMEWORK] as an unsigned integer representing 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.18 of [RAQMON-FRAMEWORK] as 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.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. RMON WG Expires March 2004 [Page 11] INTERNET DRAFT RAQMON PDU September 2003 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 data source of communication sub session RC_N per definition of [RFC 1890]. Since the Source Payload type does not vary frequently during reporting sessions, applications should avoid sending these parameters within RAQMON PDU too often to ensure efficient usage of network resources. 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 efficient usage of network resources. S_Layer2: 8 bits - This parameter defined in section 5.22 of [RAQMON- FRAMEWORK] is an 8-bit field associated to the source's IEEE 802.1p values of communication sub session RC_N. Since IEEE 802.1p value is 3 bits, the first 3 bits of this parameter represents IEEE 802.1p value and the last 5 bits are padded to 0. Since this parameter is expected to remain constant most of the time during entire reporting sessions, applications should avoid sending these parameters too often to ensure efficient usage of network resources. S_Layer3: 8 bits - This parameter defined in section 5.23 of [RAQMON- FRAMEWORK] is an 8-bit field which 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 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 layer 2 priorities 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.1p value is 3 bits, the first 3 bits of this parameter represents IEEE 802.1p 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 efficient usage of network resources. D_Layer3: 8 bits - This parameter defined in section 5.25 of [RAQMON- FRAMEWORK] is an 8-bit field which 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 RMON WG Expires March 2004 [Page 12] INTERNET DRAFT RAQMON PDU September 2003 during entire reporting sessions, applications should avoid sending these parameters within a PDU too often to ensure efficient usage of network resources. CPU Utilization: 8 bits - This parameter defined in section 5.26 of [RAQMON-FRAMEWORK] represents the percentage of CPU used during session RC_N up until the time this RAQMON PDU was generated. CPU Utilization value should indicate not only CPU Utilization associated to a session RC_N but also actual CPU Utilization, to indicate a snapshot of end device Memory Utilization while session RC_N 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 session RC_N up until the time this RAQMON PDU was generated. Memory Utilization value should indicate not only Memory Utilization associated to a session RC_N but also actual Memory Utilization, to indicate a snapshot of end device memory utilization while session RC_N in progress. 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 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. RMON WG Expires March 2004 [Page 13] INTERNET DRAFT RAQMON PDU September 2003 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. 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 Real-Time Transport Control Protocol (RTCP) and the Simple Network Management Protocol (SNMP) can RMON WG Expires March 2004 [Page 14] INTERNET DRAFT RAQMON PDU September 2003 be used as a transport protocol. Section 3.1 specifies RTCP APP Packets [RFC 1889] to carry RAQMON PDUs between RDS and RRC and section 3.2.reflects usage of SNMP INFORM PDUs as transport protocol. It is left upon the vendors to choose either RTCP or SNMP to transport RAQMON PDU as it 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 unidirectional exchange of PDUs between RDSs and an RRC. The protocol data units are mapped to an APP Packet (i.e. PT = 204) in Real-Time Transport Control Protocol (RTCP). As outlined in RFC 1889, an RTCP APP packet allows applications to define new RTCP packets. The RTCP APP packets are intended for use as new applications and new features such as RAQMON are developed, without requiring packet type value registration. RAQMON Framework makes use of such extension to provide backward compatibility to existing deployment. Within the RTCP framework, a RAQMON PDU is represented as an Application Specific Report. RTCP APP packets used by RMON MUST be Internet Assigned Numbers Authority (IANA) Registered, by assigning the string "RMON" as ASCII name. Figure 3 below shows how RAQMON PDUs are mapped into RTCP APP Packets to transport PDUs between RDS and RRC. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| subtype | PT=APP=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name (ASCII) = "RMON" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RAQMON PDU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - Using RTCP APP Packets to transport RAQMON PDUs version (V), padding (P), length: As described for the SR packet subtype: 5 bits subtype 1 MUST be used by the RAQMON PDU. These unique definitions will be IANA registered. RMON WG Expires March 2004 [Page 15] INTERNET DRAFT RAQMON PDU September 2003 packet type (PT): 8 bits Contains the constant 204 to identify this as an RTCP APP packet. name: 4 octets The name chosen by the RMON WG defining the set of APP packets will be unique with respect to other APP packets and will be IANA Registered as "RMON" with all uppercase. The name field in RTCP APP Packet is interpreted as a sequence of ASCII characters. application-dependent data: variable length RAQMON PDUs sent by the RDS in the format specified in Figure 3 will be interpreted by the RAQMON Report Collector (RRC) and not RTP/RTCP itself. RAQMON PDUs must be a multiple of 32 bits long. 3.1.1 Port Assignment As specified in the previous sections the transport of RAQMON PDUs can be performed using various underlying network transport protocols like TCP and UDP. Applications using RAQMON Framework may use any unreserved UDP port. For example, a session management program can allocate the port randomly. A single fixed port cannot be required because multiple applications within a host sharing a RDS implementation may encounter difficulties as there are some operating systems that do not allow multiple processes to use the same UDP port with different multicast addresses. However, port numbers 5XXX have been registered with IANA for use as the default port for RAQMON PDUs over RTCP. Hosts that run multiple applications may use this port as an indication to have used RAQMON if they are not subject to the constraint of the previous paragraph. RRCs may also use this port as a default to receive RAQMON PDUs carried over RTCP which will reduce configuration needs for RDSs. Applications need not have a default and may require that the port be explicitly specified. The particular port number was chosen to lie in the range above 5000 to accommodate port number allocation practice within the Unix operating system, where privileged processes can only use port numbers below 1024 and port numbers between 1024 and 5000 are automatically assigned by the operating systems. 3.2 SNMP INFORM PDUs as RDS/RRC Network Transport Protocol The idea is to re-use SNMP INFORM PDU. If SNMP is chosen as a mechanism to transport RAQMON PDU, the following specification applies: RMON WG Expires March 2004 [Page 16] INTERNET DRAFT RAQMON PDU September 2003 + RDSs implement the capability of embedding RAQMON parameters in SNMP INFORM Request and thus re-using well known SNMP mechanisms to report RAQMON Statistics. The RAQMON RDS MIB as identified in 3.2.1 MUST be used in order to map the RAQMON PDUs on SNMP Notifications transport. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. + Since RDSs are not computationally rich and to keep the RDS realization lightweight, it is not required that RDSs fully implement an SNMP-based Internet Management framework. Specifically RDSs MAY NOT respond to SNMP requests like GET, SET, etc., as an SNMP compliant responder would. + Since RRCs are computationally rich, RRCs SHOULD implement a SNMP manager. RRCS should send an SNMP INFORM Response for each associated SNMP INFORM originated by the RDS. + 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, RMON WG Expires March 2004 [Page 17] INTERNET DRAFT RAQMON PDU September 2003 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32 FROM SNMPv2-SMI raqmon, RaqmonDateAndTime FROM RAQMON-MIB Utf8String FROM SYSAPPL-MIB Dscp FROM DIFFSERV-DSCP-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; raqmonDs MODULE-IDENTITY LAST-UPDATED "200308251150Z" -- August 25, 2003 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 Blvd, Houston, TX, 77094 USA Tel: +713-918-1816 Email: egolovin@bmc.com " DESCRIPTION "This is RAQMON Data Source notification Module. It provides mapping of RAQMON PDU to SNMP Notification. Ds is for data source. Note that all of the object types defined in this module are accessible-for-notify, and would consequently not be available to a browser using simple Get, GetNext, or GetBulk requests. This is a branch of the RAQMON module. " REVISION "200308251150Z" -- August 25, 2003 DESCRIPTION "Changes after the 57th IETF." ::= { raqmon 3 } RMON WG Expires March 2004 [Page 18] INTERNET DRAFT RAQMON PDU September 2003 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 " ::= { 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 RaqmonDateAndTime, raqmonSessionSetupDelay Unsigned32, raqmonSessionDuration RMON WG Expires March 2004 [Page 19] INTERNET DRAFT RAQMON PDU September 2003 Unsigned32, raqmonSessionSetupStatus Utf8String, raqmonRoundTripEndtoEndDelay Unsigned32, raqmonOneWayEndtoEndDelay Unsigned32, raqmonInterArrivalJitter Unsigned32, raqmonTotalPacketsReceived Counter32, raqmonTotalPacketsSent Counter32, 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 } RMON WG Expires March 2004 [Page 20] INTERNET DRAFT RAQMON PDU September 2003 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 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 RaqmonDateAndTime MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The time when session was initiated." REFERENCE RMON WG Expires March 2004 [Page 21] INTERNET DRAFT RAQMON PDU September 2003 "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 } 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 RMON WG Expires March 2004 [Page 22] INTERNET DRAFT RAQMON PDU September 2003 STATUS current DESCRIPTION "One way end to end delay in milliseconds." REFERENCE "Section 5.12 of the [RAQMON FRAMEWORK]" ::= { raqmonDsNotificationEntry 11} raqmonInterArrivalJitter OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "An estimate of the statistical variance of packets inter-arrival time expressed in milliseconds." REFERENCE "Section 5.13 of the [RAQMON FRAMEWORK]" ::= { raqmonDsNotificationEntry 12} 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 13 } 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 14 } raqmonTotalOctetsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS accessible-for-notify STATUS current RMON WG Expires March 2004 [Page 23] INTERNET DRAFT RAQMON PDU September 2003 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 15 } 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 16 } raqmonCumulativePacketLoss OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The total number of packets from session that have been lost while this notification was generated. This number is expected to be less the number of packets actually received." REFERENCE "Section 5.18 of the [RAQMON FRAMEWORK]" ::= { raqmonDsNotificationEntry 17 } 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 18 } RMON WG Expires March 2004 [Page 24] INTERNET DRAFT RAQMON PDU September 2003 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 19 } 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 20 } 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 21 } 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 22 } raqmonSourceDscp OBJECT-TYPE SYNTAX Dscp MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Source DSCP value." RMON WG Expires March 2004 [Page 25] INTERNET DRAFT RAQMON PDU September 2003 REFERENCE "Section 5.23 of the [RAQMON FRAMEWORK]" ::= { raqmonDsNotificationEntry 23 } 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 24 } 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 25 } 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 26 } -- -- 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 March 2004 [Page 26] INTERNET DRAFT RAQMON PDU September 2003 "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 March 2004 [Page 27] INTERNET DRAFT RAQMON PDU September 2003 raqmonSessionSetupDateTime, raqmonSessionSetupDelay, raqmonSessionDuration, raqmonSessionSetupStatus, raqmonRoundTripEndtoEndDelay, raqmonOneWayEndtoEndDelay, raqmonInterArrivalJitter, raqmonTotalPacketsReceived, raqmonTotalPacketsSent, raqmonTotalOctetsReceived, raqmonTotalOctetsSent, raqmonCumulativePacketLoss, raqmonPacketLossFraction, raqmonSourcePayloadType, raqmonReceiverPayloadType, raqmonSourceLayer2Priority, raqmonDestinationLayer2Priority, raqmonSourceDscp, raqmonDestinationDscp, raqmonCpuUtilization, raqmonMemoryUtilization } STATUS current DESCRIPTION "These objects are required for entities claiming conformance to this MIB. " ::= { raqmonDsGroups 2 } END 4.0 Congestion Safe RAQMON Operation: RAQMON PDU can be transmitted over multiple transport protocols. 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 SCTP, 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. 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. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., RMON WG Expires March 2004 [Page 28] INTERNET DRAFT RAQMON PDU September 2003 Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000 [RFC1889] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications" RFC 1889, January 1996. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RAQMON-Framework] A. Siddiqui, D.Romascanu, and E. Golovinsky, "Framework for Real-time Application Quality of Service Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon- framework-03.txt, September 2003 6. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control" RFC 1890, January 1996. [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, March 1992. [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", RFC 1597, March 1994. [RFC2679] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Delay RMON WG Expires March 2004 [Page 29] INTERNET DRAFT RAQMON PDU September 2003 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 licenses to be made available, or the result of an attempt made to RMON WG Expires March 2004 [Page 30] INTERNET DRAFT RAQMON PDU September 2003 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 March 2004 [Page 31] INTERNET DRAFT RAQMON PDU September 2003 9. Security Considerations The [RAQMON-Framework] memo outlined a threat model associated to RAQMON and some security considerations taken into account within RAQMON specification to alleviate those threats. It is imperative that the RAQMON PDU implementations be able to provide the following protection mechanisms to attain end-to-end security: 1. Authentication - the RRC SHOULD be able to verify that a RAQMON report was originated by the RDS 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. 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 RMON WG Expires March 2004 [Page 32] INTERNET DRAFT RAQMON PDU September 2003 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 memo introduces a port for usage of RTCP as transport protocol, a "name" for specific RTCP APP name == "RMON", and mandates the use of subtype 1 for RAQMON PDUs, as specified in Section 3.1, at http://www.iana.org/numbers.html 11. Authors' Addresses Anwar A. Siddiqui Avaya Labs 307 Middletown Lincroft Road Lincroft, New Jersey 07738 USA Tel: +1 732 852-3200 E-mail: anwars@avaya.com Dan Romascanu Avaya Inc. RMON WG Expires March 2004 [Page 33] INTERNET DRAFT RAQMON PDU September 2003 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 March 2004 [Page 34]