Internet Draft Anwar Siddiqui draft-ietf-rmonmib-raqmon-pdu-11.txt Avaya Labs. Category: Standards Track Dan Romascanu Expires June 2006 Avaya Inc Mahfuzur Rahman Panasonic Eugene Golovinsky BMC Software Yong Kim Broadcom 25 December 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, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. 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 information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). RMON WG Expires June 2006 [Page 1]
INTERNET DRAFT RAQMON PDU December 2005 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.................................30 4 Normative References.............................................31 5 Informative References...........................................31 6 Intellectual Property............................................33 7 Acknowledgements.................................................34 8 Appendix.........................................................34 9 Security Considerations..........................................35 10 Authors' Addresses..............................................37 Full Copyright Statement...........................................37 RMON WG Expires June 2006 [Page 2]
INTERNET DRAFT RAQMON PDU December 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 the relevant metrics for RAQMON monitoring carried by the 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 the TCP transport and MAY implement the SNMP transport. 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 June 2006 [Page 3]
INTERNET DRAFT RAQMON PDU December 2005 divided into two different parts, namely the basic part and application extensions required for vendor specific extension [RAQMON-FRAMEWORK]. Both functional parts trail a field carrying a SMI Network Management Private Enterprise code currently maintained by IANA http://www.iana.org/assignments/enterprise-numbers, which is used to identify the organization that defined the information carried in the PDU. A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1. The parameters carried by RAQMON PDUs are shown in figure 1 and 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |flag +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 June 2006 [Page 4]
INTERNET DRAFT RAQMON PDU December 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Discrd | Packet loss | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = "xxx" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Report Type = "yyy" | Length of Application Part | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application/vendor specific extension | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............... | RMON WG Expires June 2006 [Page 5]
INTERNET DRAFT RAQMON PDU December 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 defined in this document. 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. RMON WG Expires June 2006 [Page 6]
INTERNET DRAFT RAQMON PDU December 2005 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. record count (RC): 4 bits - Total number of application records contained in the Basic part of the PDU. A value of zero is considered to be valid but Useless, with the exception of the case of a NULL PDU indicating the end of a RDS reporting session. length: 16 bits (unsigned integer) - The length of the Basic Part of the RAQMON PDU in units of 32-bit words minus one, count 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 the 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), layer 2 Media Access Control (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. A NULL PDU ends with the DSRC field. 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. 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 the version of the PDU defined by this document. The basic part of each RAQMON PDU consists of Record Count Number (RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the RMON WG Expires June 2006 [Page 7]
INTERNET DRAFT RAQMON PDU December 2005 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. Bit 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 Net Delay (RTT) 9 One Way End-to-End Network Delay (OWD) 10 Cumulative Packets Loss 11 Cumulative Packets Discards 12 Total number of App Packets sent 13 Total number of App Packets received 14 Total number of App Octets sent 15 Total number of App Octets received 16 Data Source Device Port Used 17 Receiver Device Port Used 18 Source Layer 2 Priority 19 Source Layer 3 Priority 20 Destination Layer 2 Priority 21 Destination Layer 3 Priority 22 Source Payload Type 23 Receiver Payload Type 24 CPU Utilization 25 Memory Utilization 26 Session Setup Delay 27 Application Delay 28 IP Packet Delay Variation 29 Inter arrival Jitter 30 Packet loss (in fraction) RMON WG Expires June 2006 [Page 8]
INTERNET DRAFT RAQMON PDU December 2005 31 Packet Discard (in fraction) Table 1: RAQMON Parameters and corresponding RPPF Data Source Address (DA): 32 bits or 160 bits in binary representation - This parameter 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 parameter is defined in section 5.2 of [RAQMON-FRAMEWORK]. Follows exact same syntax as Data Source Address but used to indicate a Receiver 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): - 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. Padding is being used to ensure that the length and text encoding occupy a multiple of 32 bit in the DN field of the PDU. The text MUST NOT be 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 including the length field encoding 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 reaching a RRC and also conserve network bandwidth. Data Source Device Port Used: 16 bits - This parameter 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. RMON WG Expires June 2006 [Page 9]
INTERNET DRAFT RAQMON PDU December 2005 Receiver Device Port Used: 16 bits - This parameter 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 parameter 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 PDU after sub-session RC_N setup is completed, in order to use network resources efficiently. Session Setup Delay: 16 bits - The Session (sub-session) Setup Delay metric is defined in section 5.8 of [RAQMON-FRAMEWORK] and expressed in milliseconds. Session Duration: 32 bits - The Session (sub-session) 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 (sub-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 sub-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. 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 RMON WG Expires June 2006 [Page 10]
INTERNET DRAFT RAQMON PDU December 2005 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. 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. RMON WG Expires June 2006 [Page 11]
INTERNET DRAFT RAQMON PDU December 2005 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 [RFC3551]. 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 as defined in [RFC3551]. 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 session RC_N from the last report 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 RMON WG Expires June 2006 [Page 12]
INTERNET DRAFT RAQMON PDU December 2005 indicate a snapshot of the CPU utilization of the host running the RDS 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 using UTF-8 encoding. Application Name field is multiple of 32 bits, and padding will be used if necessary. 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 to accommodate extensions for new applications in a modular manner and 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 MUST recognize the presence of application specific extensions identified by using Report Type fields. As represented in figure 1, the Report Type and Application Length fields are always located at a fixed offset relative to the start of the extension fields. 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 June 2006 [Page 13]
INTERNET DRAFT RAQMON PDU December 2005 is RECOMMENDED that vendors publish application specific extensions and maintain such report types for better interoperability. Length of the Application Part: 16 bits (unsigned integer) - 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, and will be padded if necessary. 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 June 2006 [Page 14]
INTERNET DRAFT RAQMON PDU December 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 the intent of using existing installed based of devices implementing SNMP agents as RAQMON Data Sources (RDS). There are some potential problems with the usage of SNMP as a transport mapping protocol: + The potential of congestion is higher than with the TCP transport, because of the usage of UDP at the transport layer. + The encoding of the information is less efficient and this results in bigger message size, which again may impact negatively congestion conditions and memory size requirements in the devices. In order to avoid these potential problems, the following recommendations are made: + Usage of the TCP transport is RECOMMENDED in deployment over the SNMP transport wherever available for a pair of RDS/RRC. + The usage of Inform PDUs is RECOMMENDED. + The usage of Traps PDU is NOT RECOMMENDED. + It is RECOMMENDED that information carried by notifications be maintained within the limits of the MTU size in order to avoid fragmentation. 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. + 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 MUST serialize the PDU transmission rate, i.e. limit the number of PDUS sent RMON WG Expires June 2006 [Page 15]
INTERNET DRAFT RAQMON PDU December 2005 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 module 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. For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. 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). This memo 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, Unsigned32 FROM SNMPv2-SMI DateAndTime FROM SNMPv2-TC rmon FROM RMON-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB RMON WG Expires June 2006 [Page 16]
INTERNET DRAFT RAQMON PDU December 2005 Dscp FROM DIFFSERV-DSCP-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; raqmonDsMIB MODULE-IDENTITY LAST-UPDATED "200512220000Z" -- December 22, 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. 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 "200512220000Z" -- December 22, 2005 DESCRIPTION "Changes following Area Director review." REVISION "200501310000Z" -- January 31, 2005 DESCRIPTION "Changes following second WG Last Call Comments." RMON WG Expires June 2006 [Page 17]
INTERNET DRAFT RAQMON PDU December 2005 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] raqmonDsNotifications 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. 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 RMON WG Expires June 2006 [Page 18]
INTERNET DRAFT RAQMON PDU December 2005 RDSs. It serves data organization purpose only. " INDEX { raqmonDsDSRC, raqmonDsRCN, raqmonDsPeerAddrType, raqmonDsPeerAddr } ::= { raqmonDsNotificationTable 1 } RaqmonDsNotificationEntry ::= SEQUENCE { raqmonDsDSRC Unsigned32, raqmonDsRCN Unsigned32, raqmonDsPeerAddrType InetAddressType, raqmonDsPeerAddr InetAddress, raqmonDsAppName SnmpAdminString, raqmonDsDataSourceDevicePort InetPortNumber, raqmonDsReceiverDevicePort InetPortNumber, raqmonDsSessionSetupDateTime DateAndTime, raqmonDsSessionSetupDelay Unsigned32, raqmonDsSessionDuration Unsigned32, raqmonDsSessionSetupStatus SnmpAdminString, raqmonDsRoundTripEndToEndNetDelay Unsigned32, raqmonDsOneWayEndToEndNetDelay Unsigned32, raqmonDsApplicationDelay Unsigned32, raqmonDsInterArrivalJitter Unsigned32, raqmonDsIPPacketDelayVariation Unsigned32, raqmonDsTotalPacketsReceived Counter32, raqmonDsTotalPacketsSent Counter32, raqmonDsTotalOctetsReceived Counter32, raqmonDsTotalOctetsSent Counter32, raqmonDsCumulativePacketLoss Counter32, raqmonDsPacketLossFraction Unsigned32, raqmonDsCumulativeDiscards Counter32, raqmonDsDiscardsFraction Unsigned32, raqmonDsSourcePayloadType Unsigned32, raqmonDsReceiverPayloadType Unsigned32, raqmonDsSourceLayer2Priority Unsigned32, raqmonDsSourceDscp Dscp, raqmonDsDestinationLayer2Priority Unsigned32, raqmonDsDestinationDscp Dscp, raqmonDsCpuUtilization Unsigned32, raqmonDsMemoryUtilization Unsigned32 } raqmonDsDSRC OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Data Source identifier represents a unique session descriptor that points to a specific session between communicating entities. Identifiers unique for RMON WG Expires June 2006 [Page 19]
INTERNET DRAFT RAQMON PDU December 2005 sessions conducted between two entities are generated by the communicating entities." ::= { raqmonDsNotificationEntry 1 } raqmonDsRCN OBJECT-TYPE SYNTAX Unsigned32 (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 } raqmonDsPeerAddrType 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 } raqmonDsPeerAddr 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]" ::= { raqmonDsNotificationEntry 4 } raqmonDsAppName 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]" RMON WG Expires June 2006 [Page 20]
INTERNET DRAFT RAQMON PDU December 2005 ::= { raqmonDsNotificationEntry 5 } raqmonDsDataSourceDevicePort OBJECT-TYPE SYNTAX InetPortNumber 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 } raqmonDsReceiverDevicePort OBJECT-TYPE SYNTAX InetPortNumber 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 } raqmonDsSessionSetupDateTime 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 } raqmonDsSessionSetupDelay OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "Session setup time." REFERENCE "Section 5.8 of [RAQMON-FRAMEWORK]" ::= { raqmonDsNotificationEntry 9 } raqmonDsSessionDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" RMON WG Expires June 2006 [Page 21]
INTERNET DRAFT RAQMON PDU December 2005 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 } raqmonDsSessionSetupStatus 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 } raqmonDsRoundTripEndToEndNetDelay 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} raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" 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} raqmonDsApplicationDelay OBJECT-TYPE SYNTAX Unsigned32 (0..65535) RMON WG Expires June 2006 [Page 22]
INTERNET DRAFT RAQMON PDU December 2005 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} raqmonDsInterArrivalJitter OBJECT-TYPE SYNTAX Unsigned32 (0..65535) 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} raqmonDsIPPacketDelayVariation OBJECT-TYPE SYNTAX Unsigned32 (0..65535) 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} raqmonDsTotalPacketsReceived 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 receiver from the begining of the sub- session until the time this RAQMON PDU was generated. " REFERENCE "Section 5.16 of [RAQMON-FRAMEWORK]" ::= { raqmonDsNotificationEntry 17 } raqmonDsTotalPacketsSent OBJECT-TYPE SYNTAX Counter32 RMON WG Expires June 2006 [Page 23]
INTERNET DRAFT RAQMON PDU December 2005 UNITS "packets" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The number of packets transmitted within a communication session by the sender from the beginning of the sub- session until the time this RAQMON PDU was generated. " REFERENCE "Section 5.17 of [RAQMON-FRAMEWORK]" ::= { raqmonDsNotificationEntry 18 } raqmonDsTotalOctetsReceived 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 from the beginning of the sub-session until the time this RAQMON PDU was generated. " REFERENCE "Section 5.18 of [RAQMON-FRAMEWORK]" ::= { raqmonDsNotificationEntry 19 } raqmonDsTotalOctetsSent 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 sub-session from the beginning of the sub-session until the time this RAQMON notification was generated." REFERENCE "Section 5.19 of [RAQMON-FRAMEWORK]" ::= { raqmonDsNotificationEntry 20 } raqmonDsCumulativePacketLoss OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS accessible-for-notify STATUS current RMON WG Expires June 2006 [Page 24]
INTERNET DRAFT RAQMON PDU December 2005 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 } raqmonDsPacketLossFraction 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 } raqmonDsCumulativeDiscards 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 } raqmonDsDiscardsFraction OBJECT-TYPE SYNTAX Unsigned32 (0..100) UNITS "percentage of packets sent" MAX-ACCESS accessible-for-notify STATUS current 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 } raqmonDsSourcePayloadType OBJECT-TYPE RMON WG Expires June 2006 [Page 25]
INTERNET DRAFT RAQMON PDU December 2005 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 } raqmonDsReceiverPayloadType 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 } raqmonDsSourceLayer2Priority 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 } raqmonDsSourceDscp 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." REFERENCE "Section 5.27 of [RAQMON-FRAMEWORK]" ::= { raqmonDsNotificationEntry 28 } raqmonDsDestinationLayer2Priority OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION RMON WG Expires June 2006 [Page 26]
INTERNET DRAFT RAQMON PDU December 2005 "Destination Layer 2 priority. This is the priority used by the peer communicating entity to send packets to the data source. " REFERENCE "Section 5.28 of [RAQMON-FRAMEWORK]" ::= { raqmonDsNotificationEntry 29 } raqmonDsDestinationDscp 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 } raqmonDsCpuUtilization 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 } raqmonDsMemoryUtilization 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 "Section 5.31 of [RAQMON-FRAMEWORK]" ::= { raqmonDsNotificationEntry 32 } -- definitions of the notifications -- -- raqmonDsAppName is the only object that MUST be sent by an -- RDS every time the static notification is generated. RMON WG Expires June 2006 [Page 27]
INTERNET DRAFT RAQMON PDU December 2005 -- raqmonDsTotalPacketsReceived is the only object that MUST be -- sent by an RD every time the dynamic notification is generated. -- Other objects from the raqmonDsNotificationTable may be -- included in the variable binding list. Specifically, a raqmon -- notification will include MIB objects that provide information -- about metrics that characterize the application session -- It is RECOMMENDED to keep the size of a notification within -- the MTU size limits in order to avoid fragmentation -- raqmonDsStaticNotification NOTIFICATION-TYPE OBJECTS { raqmonDsAppName } STATUS current DESCRIPTION "This notification maps the static parameters in the Basic RAQMON PDU onto an SNMP transport. This notification is expected to be sent once per session, or when a new sub-session is initiated. The following objects MAY be carried by the raqmonDsStaticNotification: raqmonDsDataSourceDevicePort, raqmonDsReceiverDevicePort, raqmonDsSessionSetupDateTime, raqmonDsSessionSetupDelay, raqmonDsSessionDuration, raqmonDsSourcePayloadType, raqmonDsReceiverPayloadType, raqmonDsSourceLayer2Priority, raqmonDsSourceDscp, raqmonDsDestinationLayer2Priority, raqmonDsDestinationDscp " ::= { raqmonDsNotifications 1 } raqmonDsDynamicNotification NOTIFICATION-TYPE OBJECTS { raqmonDsTotalPacketsReceived } STATUS current DESCRIPTION "This notification maps the dynamic parameters in the Basic RAQMON PDU onto an SNMP transport. The following objects MAY be carried by the raqmonDsDynamicNotification: raqmonDsRoundTripEndToEndNetDelay, RMON WG Expires June 2006 [Page 28]
INTERNET DRAFT RAQMON PDU December 2005 raqmonDsOneWayEndToEndNetDelay, raqmonDsApplicationDelay, raqmonDsInterArrivalJitter, raqmonDsIPPacketDelayVariation, raqmonDsTotalPacketsSent, raqmonDsTotalOctetsReceived, raqmonDsTotalOctetsSent, raqmonDsCumulativePacketLoss, raqmonDsPacketLossFraction, raqmonDsCumulativeDiscards, raqmonDsDiscardsFraction, raqmonDsCpuUtilization, raqmonDsMemoryUtilization " ::= { raqmonDsNotifications 2 } raqmonDsByeNotification NOTIFICATION-TYPE OBJECTS { raqmonDsAppName } STATUS current DESCRIPTION "The BYE Notification. This Notification is the equivalent of the RAQMON NULL PDU, which signals the end of a RAQMON session. " ::= { raqmonDsNotifications 3 } -- -- 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 { raqmonDsStaticNotification, raqmonDsDynamicNotification, RMON WG Expires June 2006 [Page 29]
INTERNET DRAFT RAQMON PDU December 2005 raqmonDsByeNotification } STATUS current DESCRIPTION "Standard RAQMON Data Source Notification group." ::= { raqmonDsGroups 1 } raqmonDsPayloadGroup OBJECT-GROUP OBJECTS { raqmonDsAppName, raqmonDsDataSourceDevicePort, raqmonDsReceiverDevicePort, raqmonDsSessionSetupDateTime, raqmonDsSessionSetupDelay, raqmonDsSessionDuration, raqmonDsSessionSetupStatus, raqmonDsRoundTripEndToEndNetDelay, raqmonDsOneWayEndToEndNetDelay, raqmonDsApplicationDelay, raqmonDsInterArrivalJitter, raqmonDsIPPacketDelayVariation, raqmonDsTotalPacketsReceived, raqmonDsTotalPacketsSent, raqmonDsTotalOctetsReceived, raqmonDsTotalOctetsSent, raqmonDsCumulativePacketLoss, raqmonDsPacketLossFraction, raqmonDsCumulativeDiscards, raqmonDsDiscardsFraction, raqmonDsSourcePayloadType, raqmonDsReceiverPayloadType, raqmonDsSourceLayer2Priority, raqmonDsSourceDscp, raqmonDsDestinationLayer2Priority, raqmonDsDestinationDscp, raqmonDsCpuUtilization, raqmonDsMemoryUtilization } STATUS current DESCRIPTION "Standard RAQMON Data Source payload MIB objects group." ::= { raqmonDsGroups 2 } END 3. Congestion-Safe RAQMON Operation RMON WG Expires June 2006 [Page 30]
INTERNET DRAFT RAQMON PDU December 2005 As outlined in earlier sections, TCP congestion control mechanism provides inherent congestion safety features when TCP is implemented 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 a 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3289] Baker, F., Chan, K. and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3411] Harrington, D., Preshun, R. and B. Wijnen, "An RMON WG Expires June 2006 [Page 31]
INTERNET DRAFT RAQMON PDU December 2005 Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC4001] Daniele, M., Haberman, B., Routhier, S. And J. Schoenwalder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 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-12.txt, December 2005. 5. Informative References [RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992. [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 RMON WG Expires June 2006 [Page 32]
INTERNET DRAFT RAQMON PDU December 2005 Applications", RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [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 [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. RMON WG Expires June 2006 [Page 33]
INTERNET DRAFT RAQMON PDU December 2005 [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. 6. IPR Disclosure Acknowledgement 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. 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. 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. We also would like to thank Bert Wijnen for the permanent coaching during the evolution of this document and the detailed review of its final versions. 8.Appendix RMON WG Expires June 2006 [Page 34]
INTERNET DRAFT RAQMON PDU December 2005 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: 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 RMON WG Expires June 2006 [Page 35]
INTERNET DRAFT RAQMON PDU December 2005 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 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 MUST be used to provide transport layer security. 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. RMON WG Expires June 2006 [Page 36]
INTERNET DRAFT RAQMON PDU December 2005 Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: raqmonDsNotificationTable The objects in this table contain user 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 RMON WG Expires June 2006 [Page 37]
INTERNET DRAFT RAQMON PDU December 2005 Eugene Golovinsky BMC Software 2101 CityWest Blvd. Houston, Texas 77042 USA Tel: +1 713 918-1816 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 (2005). 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 RMON WG Expires June 2006 [Page 38]
INTERNET DRAFT RAQMON PDU December 2005 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. 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 June 2006 [Page 39]
