Internet Draft Anwar Siddiqui Avaya Inc. Dan Romascanu Avaya Inc. Eugene Golovinsky BMC Software 22 Oct 2002 Real-time Application Quality of Service Monitoring (RAQMON) Framework 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract There is a need to extend the RMON framework [RFC2819] to monitor end devices such as IP phones, pagers, Instant Message Clients, mobile phones, and PDA devices. This memo proposes an extension of RMON Framework to allow Real-time Application QoS information of these types of end devices to be retrieved with SNMP, independent of the technology used to perform the measurements. An end-to-end user experience of the quality of service (QoS) and performance for such an application is a combination of device performance, transport network performance and specific application context. The memo also defines a common framework to identify a set of application QoS parameters and a reporting mechanism using a common Anwar Siddiqui Expires April 2003 [Page 1] INTERNET DRAFT RAQMON Framework October 2002 protocol data unit (PDU) format used between RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report QOS statistics using RTCP and SNMP as underlying transport protocol. The original RAQMON draft is split into 3 parts namely RAQMON Framework, RAQMON QOS PDU and RAQMON MIB. This memo only defines the RAQMON Framework along with companion drafts that defines a portion of the Management Information Base (MIB) and that defines RAQMON PDUs. Distribution of this memo is unlimited. Table of Contents Status of this Memo 1 Abstract 1 1 Introduction 2 2 RAQMON Framework Overview 3 3 A Simple Metrics 7 4 RAQMON Framework 13 5 References 22 6 Intellectual Property 24 7 Security Considerations 24 8 IANA Considerations 26 9 Authors' Addresses 26 A Full Copyright Statement 26 1. Introduction There is a need to extend the RMON framework [RFC2819] to monitor end devices such as IP Phones, pagers, Instant Message Clients, Cell Phones, and PDA devices. This memo proposes an extension of RMON Framework to allow Real-time Application QoS information of these types of end devices to be retrieved with SNMP, independent of the technology used to perform the measurements. An end-to-end user experience of the quality of service (QoS) and performance for such an application is a combination of device performance, transport network performance and specific application context. This memo defines a Real-Time Application QOS Monitoring (RAQMON) Framework that extends the RMON Framework to allow Real-time Application QoS information of these types of end devices as outlined by RAQMON Charter of the RMON Workgroup. The original RAQMON draft [SIDDIQUI1] is split into 3 parts to identify the RAQMON Framework, RAQMON QOS PDU and RAQMON MIB. Anwar Siddiqui Expires April 2003 [Page 2] INTERNET DRAFT RAQMON Framework October 2002 The memo [SIDDIQUI2] takes a portion of [SIDDIQUI1] that defined RAQMON QOS PDU and describes how various PDUs can be transported over existing Application level transport protocol like the Real Time Communication protocol (RTCP) and the Simple Network Management Protocol (SNMP) to transport statistics between RDS and RRC. The memo [SIDDIQUI3] updates [SIDDIQUI1] that defined the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB [RFC2819] to accommodate RAQMON solution. 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 Framework Overview This document continues the architecture created in the RMON MIB [RFC2819] by providing analysis of application performance as experienced by end-users on a specific IP end point and correlating such performance statistics to its underlying transport network characteristics. This memo is written with following assumptions: + All IP end points and applications are producers and consumers of IP Traffic. + The design of the RAQMON QOS PDUs are such that, it can be used by many Real-Time Applications like Voice over IP, Fax over IP, Video over IP, IP Short Messaging Services (SMS), Instant Messaging, Email, chats, ftp/tftp based downloads, e-business style transactions, web access etc. + RAQMON Framework is agnostic to the underlying measurement methodology used to quantify a PDU parameter. RAQMON PDUs offer an entry (a.k.a. "Name") to be filled in by application specific software which with a specific "value". Since RAQMON PDUs are common data formats commonly understood by RDS and RRC to exchange RAQMON Statistics (i.e. "Name" and "Value" pair), measurement methodologies are out of the scope of RAQMON specification. It is also out of the scope of PDU specification to validate specific measurement methodology used to gather a "value". However set of "Name" entries specified in RAQMON PDU in this draft can be filled in with a "value" using IPPM WG recommended measurement methodologies. Anwar Siddiqui Expires April 2003 [Page 3] INTERNET DRAFT RAQMON Framework October 2002 + In order to facilitate complete End-to-End view and to portray end user experience, the RAQMON Framework SHOULD be able to handle statistics that relate to: i. "User, Application, Session" specific parameters - e.g. Instant Message vs. VoIP ii. "IP end device" specific parameters during a session (e.g. CPU Usage) iii. "Transport network" specific parameter during a session (e.g. End-to-End Delay, Jitter) User experience of an application running on a specific IP end point has lot to do with the type of application an user is running, local end device resources available as well as the underlying transport network capabilities. + RAQMON "Names" are selectable by the RDS and Application implementation. End-to-End QOS view is sensitive to application type, device and transport network. Though RAQMON PDUs are capable of carrying various pre-specified parameters but, it is expected that proposed PDUs MUST provide options to select a sub-set of those parameters from the metrics definition list, to fit the needs of the application-context. The Application implementer controlling the RDS will be responsible for choosing a set of parameters, as "monitoring context" is application specific. For example an IP Soft Phone application running on a PC probably be willing to report "Jitter" to RRC however an Email Application running on the same host may not use the "Jitter" parameter to report to RRC as Jitter is deemed to be not so critical for E-mail Application. + List of "Names" used by the RAQMON PDU MUST be extensible to accommodate application and vendor specific implementations. + Monitored statistics is reported by the RAQMON Data Source (RDS) at will. Content Parameters, Transmission timing, frequency of RAQMON PDUs etc. will be completely controlled by the RDSs to provide ease of administration Though monitoring is a useful function but there are various operation scenarios where monitoring could be expensive and degrade Anwar Siddiqui Expires April 2003 [Page 4] INTERNET DRAFT RAQMON Framework October 2002 the QOS of an application. There are also restrictions imposed on end devices based on the administrative domains. For example, an Enterprise IP Phone user is managed by the enterprise Telecom manager, but the Service Level Agreements is monitored by the Enterprise and ISP IT Managers. In such an environment, IP Phones may be required to report QOS Problems to various administrative authorities restricted by the administration domain policy. A RDS Driven reporting mechanism allows enough flexibility to accommodate various administrative constraints. + Quality of service parameters of each communication session should be captured and stored "completely". A communication session may consist of one or more combinations of transaction-oriented, throughput-oriented, or streaming-oriented operations. For example, the quality-of-service definition of a Video over IP call using Video Phones involves: - Caller Video Phone signaling for call setup that includes a transaction with a session processing server which locates/connects the callee using a protocols like SIP, H.323 or MGCP. - Eventually the video phone source/sinks media streams between two IP end points using RTP as a result of successful session setup transaction In this particular application scenario, the session set up timing is as critical as the end-to-end delay per packet of media streams. The RAQMON PDUs should provide a capability to capture such session specific data. RAQMON draft would use the following definitions of transactions as defined in the APM MIB [WALDBUSSER]: Transaction-Oriented: These transactions have a fairly constant workload to perform for all transactions. The responsiveness metric for transaction-oriented applications is application response time, the elapsed time between the user's request for service (e.g. pushing the submit button or pressing DTMF in IP Phones) and the completion of the request (e.g. displaying the results or getting a ring back). Throughput-Oriented: These transactions have widely varying workloads based on the amount of data requested. The metric for throughput- oriented applications are expressed in is Kilobits per second (Kbps) or Mega bits per second (Mbps). Streaming-Oriented: These transactions deliver data at a constant metered rate of speed regardless of excess capacity in the networking Anwar Siddiqui Expires April 2003 [Page 5] INTERNET DRAFT RAQMON Framework October 2002 and computing infrastructure. However, when the infrastructures cannot deliver data at this speed, interruption of service or degradation of service can result. + A report on a communication session between users should capture the entire session by keeping records of all the sub-sessions performed within that session. A generic communication session between two users can be modeled as multiple sub-sessions within a communication session. For example a video call between two users would capture Quality of Service parameters of a session for Audio, Video and Data separately but within one compound report as it reflects the true nature of the communication session. It is easier for an end device to correlate between these sub-sessions and report the End-to-End QOS parameters of that session in a compound report. + The monitoring functionality must run in real-time during each communication session and consume very minimal device resources. Many of the IP end points that runs applications like Voice over IP, Fax over IP, Video over IP, Short Messaging Services (SMS), Instant Messaging, Email, chats, ftp/tftp based downloads, e-business style transactions, web access are embedded devices with resources constraints. Monitoring of these devices and applications is performed for all communication session as QOS of each session is dependent on the time when monitoring was performed. + RAQMON Framework requires a simple, easy to understand and simple to implement metrics definition. Metrics definitions need to be simple and intuitive to Application Service Providers, IT Managers, network operators, equipment vendors etc. + RAQMON Framework design should be embedded device friendly. The applications covered under the RAQMON Charter have become such a commodity in our everyday lives that there are lots of simple embedded smart devices being developed by various vendors at an enormous rate. Application Service Providers, Network Service Providers, Enterprise operators, IT Managers etc. have an inherent need to gather QOS Reports of these devices and applications to manage there networks and services. It is the objective of this draft to deliver a simple but easy to deploy monitoring solution. Anwar Siddiqui Expires April 2003 [Page 6] INTERNET DRAFT RAQMON Framework October 2002 + RAQMON MIB is agnostic to the transport protocol used to carry RAQMON PDUs between RDS and RRC. 3. A Simple Metrics The objectives set in the previous section dictates that the RAQMON framework ought to provide a simple metrics definition. It is an extremely challenging task to define "appropriate metrics" as metrics are context-sensitive. However one can also notice that there are enough commonalities between the various QOS parameters associated to various applications such that the task of defining a "simple metrics" is feasible. This document defines a simple metric that in essence captures the performance and associated quality-of-service parameters of a communication session. RAQMON framework also provides a mechanism to add and drop various parameters to this metrics as defined in Table 1 below to accommodate application context sensitivity: 1. Data Source Name (DN) 2. Receiver Name (RN) 3. Data Source Address (DA) 4. Receiver Address (RA) 5. Data Source Device Port used 6. Receiver Device Port used 7. Session Setup Date/Time 8. Session Setup delay 9. Session duration 10. Session Setup Status 11. End-to-End Delay 12. Inter Arrival Jitter 13. Total number of Packets Received 14. Total number of Packets Sent 15. Total number of Octets Received Anwar Siddiqui Expires April 2003 [Page 7] INTERNET DRAFT RAQMON Framework October 2002 16. Total number of Octets Sent 17. Cumulative Packet Loss 18. Packet Loss in Fraction 19. Source Payload Type 20. Receiver Payload Type 21. Source Layer 2 Priority 22. Destination Layer 2 Priority 23. Source Layer 3 Priority 24. Destination Layer 3 Priority 25. CPU utilization in Fraction 26. Memory utilization in Fraction 27. Application Name/version 28. RAQMON Optional Flags (ROF) Table 1: RAQMON Metrics Definition Various parameters listed in table 1 are defined below. The definition presented here is meant to provide guidance to implementers. No claim is made that the definitions presented here are appropriate for a particular application need. Data Source Name (DN): The DN item could be of various formats as needed by the application. Few instances of DN could be but not restricting to * "user@host", or "host" if a user name is not available as on single-user systems. For both formats, "host" is either the fully qualified domain name of the host from which the payload originates, formatted according to the rules specified in [RFC1034], [RFC1035] and Section 2.1 of [RFC1123]; The DN value is expected to remain constant for the duration of a session. Examples are "big-guy@ip- phone.bigcompany.com" or "big-guy@135.8.45.178" for a multi-user system. On a system with no user name, examples would be "ip- phone4630.bigcompany.com". It is recommended that the standard host's numeric address not be reported via DN parameter as Data Source Anwar Siddiqui Expires April 2003 [Page 8] INTERNET DRAFT RAQMON Framework October 2002 Address (DA) parameter is used for that purpose. * Another instance of a DN could a valid E.164 phone number, a SIP URI or any other form of telephone or pager numbers. It is recommended that the phone number should be formatted with the plus sign replacing the international access code. For example, "+88 02 123 45678" for a number in Bangladesh. It is expected that a Data Source Name (DN) will remain constant within a communication session. Receiver Name (RN): Same as Data Source Name (DN). Data Source Address (DA): Data Source Address (DA) parameter should be represented as the standard ASCII representation of the host's numeric address. This could be an IPv4 Address, IPv6 Address, network address assignments such as the Net-10 assignment proposed in [RFC1597] or any other form of numeric address represented in ASCII. It is expected that a Data Source Name (DN) would remain constant within a communication session. DN and DA are intended to give the application writers an opportunity to uniquely identify a record associated to a session. However application writers should be aware that private network address assignments such as the Net-10 assignment may create network addresses that are not globally unique. To handle this case, the burden is on the application either by converting private addresses to public addresses if necessary to keep private addresses from being exposed or by creating an application specific extension. Receiver Address (RA): Same as Data Source Address Data Source Device Ports used: This parameter is used to indicate the port used for a particular session or sub-session used for communication. Example of port includes TCP Port, UDP Port, RTP Port etc. It is not expected that a Data Source Device Ports would remain constant within a communication session. Receiver Device Ports used: Same as Data Source Device Ports used. Session Setup Date/Time Indicates the wallclock time when the RAQMON packet was sent so that it may be used by the RRC to store Date/Time. Wallclock time (absolute time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900 [RFC1305]. Session Setup delay: Session setup delay indicates the duration of Anwar Siddiqui Expires April 2003 [Page 9] INTERNET DRAFT RAQMON Framework October 2002 time required by a network communication controller to set a media path between the communicating entities or the end devices. For example in VoIP systems a session setup time can be measured as the last DTMF button pushed to the first ring back tone that indicates that the far end is ringing. However as these definitions are very specific to the type of system used and implementation details of such system, no claim is made about the definition presented here are appropriate for a particular application need and left upon the implementers to define. Session duration: This parameter describes how long a session or a sub-session lasted. Session Setup Status: This parameter is intended to report status of a session in order to support applications those need to display status in realtime. For example a debugging tool that captures the status of a call setup as soon as a call is established or a tool that captures why a session failed or how many RSVP sessions failed etc. End-to-End Delay: End-to-End delay is a key parameter for Application QOS Monitoring. Some applications do not perform well (or at all) if end-to-end delay between hosts is large relative to some threshold value. Erratic variation in delay makes it difficult (or impossible) to support many real-time applications like Voice over IP, Video over IP, Fax over IP etc. There are many measurement methodologies available to fill this parameter but this parameter is intended to capture the End-to-End delay as observed by the IP devices at the application layer pertaining to a specific operation environment. While appropriate, it is recommended that specific application layer delays like play out delay, packet sequencing delays, coding, decoding delays be added to transport network delay to report End-to-End delay under RAQMON Framework. End-to-End delay of underlying transport network can be measured using various methodologies as described in [RFC2681], [RFC2679], [RFC1889] depending on the application needs and left upon the implementers based on their applications. Inter-arrival Jitter: Inter-arrival jitter field provides a short- term measure of congestion. The definition of Jitter is context sensitive and measurement specific. Measurement of inter-arrival Jitter is beyond the scope of this document. The jitter measure indicates congestion before it leads to packet loss. Inter-arrival jitter of underlying transport network can be measured using various methodologies and left upon the implementers based on there Anwar Siddiqui Expires April 2003 [Page 10] INTERNET DRAFT RAQMON Framework October 2002 application need. VoIP Systems can readily acquire Inter-arrival Jitter calculations from RTCP measurements as described in [RFC1889]. Total number of Packets Received: The total number of packets received by the data source since starting transmission up until the time this RAQMON packet was generated. Total number of Packets Sent: Similar to total number of packets received. Total number of Octets Received: The total number of payload octets received in packets by the sender since starting transmission up until the time this RAQMON packet was generated. Total number of Octets Sent: Similar to total number of octets received. Cumulative Packet Loss: Packet loss tracks persistent congestion while the jitter measure tracks transient congestion. Since the interarrival jitter field is only a snapshot of the jitter at the time of a report, packet loss indicates the network environment as well as local device losses over time. Packet loss of underlying transport network can be measured using various methodologies e.g. as described in [RFC2680], [RFC1889] and local device level packet losses ought to be captured by the local device specific algorithms. Measurement methodologies are left upon the implementers based on their application need. Packet loss in Fraction: Same as Packets loss but expressed in percentage Source Payload Type: Defines payload formats (e.g. media encodings) as sent by the data source. e.g. ITU G.711-(law, ITU G.729B, H.263, MPEG-2, ASCII etc. This document follows the same payload type constants as defined in [RFC1890]. Destination Payload Type: Similar to Source Payload Type. Source Layer 2 Priority: Many devices use Layer 2 technologies to prioritize certain type of traffic in the Local Area Network environment. For example the 1998 Edition of IEEE 802.1D [IEEE802.1D] "Media Access Control" Bridges contains expedited traffic capabilities to support transmission of time critical information and many devices use the standard to mark Ethernet frames according to IEEE 802.1p standard. Details on these can be found in IEEE 802.1Q "Virtual Bridged LAN" specifications. 802.1p has been Incorporated into ISO/IEC 15802-3 1998 [IEEE802.1Q]. Source Layer 2 RAQMON field indicates Layer 2 values used by the Data Source to prioritize these Anwar Siddiqui Expires April 2003 [Page 11] INTERNET DRAFT RAQMON Framework October 2002 packets in the Local Area Networks environment. Source Layer 3 Priority: Various Layer 3 technologies are in place to prioritize certain type of traffic in the internet. For example traditional IP Precedence [RFC791], Type Of Service (TOS) [RFC1349],[RFC1812] or more recent technologies like Differentiated Service [RFC2474][RFC2475] is achieved by using the TOS octet in IPv4 and the Traffic class Octet in IPv6 are used to prioritize traffic. Source Layer 3 RAQMON field indicates appropriate Layer 3 values used by the Data Source to prioritize these packets. Destination Layer 2 Priority: Same as Source Layer 2 Priority. Destination Layer 3 Priority: Same as Source Layer 3 Priority. CPU utilization in Fraction: This parameter captures the IP Device CPU usage rate to indicate current state of the local IP Device resource which has a very critical implications on QOS implications of an end device. e.g. x % CPU busy averaged over session duration. Memory utilization in Fraction: This parameter captures the IP Device Memory usage rate to indicate current state of the local IP Device resource which has a very critical implications on QOS implications of an end device. e.g. y % memory utilized over session duration. Application Name/version Application Name/version parameter gives the name and possibly version of the application associated to that session or sub-session, e.g., "XYZ VoIP Agent 1.2". This information may be useful for scenarios where end device is running multiple applications with various priorities and could be very handy for debugging purposes. RAQMON Optional Flags (ROF): These flags are open to various vendors to be used for application specific bit level signaling. For example RDS can report various numeric status code to RRCs using these bits. For example, the end devices that support RSVP to setup a communication session would be successful in acquiring RSVP reservation in one direction but not the other. A specific 8-bit failure code can be used to indicate each failure code. One could also use these bits to indicate RAQMON packet sequence number. These 8-bit Optional Flags are interpreted by the application, not by the RRC and usage of these left at the application developer's discretion. 3.1 Measurement Methodology It is not the intent of this document to recommend a methodology to measure any of the QOS parameters defined in table 1. Measurement Anwar Siddiqui Expires April 2003 [Page 12] INTERNET DRAFT RAQMON Framework October 2002 algorithms are left upon the implementers and equipment vendors to choose. There are many different measurement methodologies available for measuring application performance (e.g., probe-based, client- based, synthetic-transaction, etc.). This specification does not mandate a particular methodology - it is open to any that meet the minimum requirements. Conformance to this specification requires that the collected data match the semantics described herein. 4. RAQMON Framework RAQMON framework is based on three entities: - RAQMON Data Source (RDS) - RAQMON Report Collector (RRC) - RAQMON MIB Structure In addition, the framework contains requirements for a protocol by which RDS exchange RAQMON information with the RRC. Several proposals for protocols which can fulfill this role. Few of these options have been rolled out in this draft to evaluate feasibility of a protocol between the RDS and RRC. +----------------------+ +---------------------------+ | IP End Device | | IP End Device >----+ | |+--------------------+| |+--------------------+ | | || APPLICATION || || APPLICATION | | | || -Voice over IP <----(1)----> -Voice over IP >- + | | || -Instant Messaging|| || -Instant Messaging| | 3 | || -Email || || -Email | 2 | | |+--------------------+| |+--------------------+ | | | | | | | | | | | | +------------------+ | | | +----------------------+ | |RAQMON Data Source|<-+ | | | | (RDS) |<---+ | | +------------------+ | +-----------|---------------+ | 4 | +----------------------------+ | | |/ |/ +------------------+ +------------------+ +-------------+ |RAQMON Report | .. |RAQMON Report | |Network Alarm| |Collector (RRC) #n| |Collector (RRC) #1|<--5-->| Manager | +------------------+ +------------------+ +-------------+ Anwar Siddiqui Expires April 2003 [Page 13] INTERNET DRAFT RAQMON Framework October 2002 Figure 1 - RAQMON Framework. (1) Communication Session between IP end devices/apps affected by underlying transport network (2) Context-Sensitive transport network Specific Metrics (3) Device State Specific Metrics (4) RAQMON packets transmitted over this interface (IP Address, port) (5) RAQMON MIB sent within SNMP notifications. 4.1 RAQMON Data Source (RDS) RAQMON Data Source is "a source of data for monitoring purposes". This term is used exactly as defined in the RMON-2 MIB [RFC2021]. In the RAQMON Framework, RDS is an element that may or may not co-reside on an IP end point depending on the architecture. However RDS is primarily responsible for abstracting IP end-devices for the purpose of monitoring. The RDS gathers the parameters defined in table 1 for a particular communication session, and forwards them to the RRC. It is envisioned that the RDS function can be implemented on a (potentially small, low powered) end device. Under this framework it is required that an RDS be configured with the following parameters: 1. The interval in which to send report PDUs 2. The RRC address 3. The encryption/authentication scheme required and its parameters ( if used). Such configuration can be performed either by administering the devices manually or statically updating them with some configuration files that uses web style user interface or by using some distributed protocols like tftp or DHCP. However it is beyond the scope of this draft to describe a configuration mechanism. 4.2 RAQMON Report Collector (RRC) A RAQMON Report Collector (RRC) receives RAQMON statistics from multiple RDSs, analyzes it, and stores it in RAQMON MIB. Anwar Siddiqui Expires April 2003 [Page 14] INTERNET DRAFT RAQMON Framework October 2002 The RRC is envisioned as a device of some power, providing a storage and aggregation point for a set of RDSs. A high-level management application will analyze information retrieved using SNMP from RAQMON MIBs on multiple RRCs. 4.3 RAQMON Protocol Data Unit There are 2 types of RAQMON PDUs used by the RDS to report various QOS parameters to RRC. BASIC: For reporting monitored data from an RDS to RRC which include QOS parameters defined in table 1. Application developers have the flexibility to report a sub-set of these pre-set parameters to RRC appropriate for an application context. APP: These APP PDUs can define Application specific information and provided for further extension required to convey Application specific or vendor specific parameters for future extension. 4.4 RDS/RRC Network Transport Protocol interface Network Transport of RAQMON PDUs from RDS to RRC is network and transport protocol agnostic. Though the choice of network and transport protocol would have affects on the reliability of these PDUs. This section describes issues specific to carrying RAQMON packets within particular network and transport protocols. The following rules apply unless superseded by protocol-specific definitions outside this specification. RAQMON PDUs relies on the underlying protocol(s) to provide a length indication. The maximum length of the RAQMON data packet is limited only by the underlying protocols. If RAQMON PDUs from RDS to RRC are to be carried in an underlying protocol that provides the abstraction of a continuous octet stream rather than messages (packets), an encapsulation of the RAQAMON packets must be defined to provide a framing mechanism. Framing is also needed if the underlying protocol may contain padding so that the extent of the RAQMON payload cannot be determined. The framing mechanism is not defined in this document. Carrying several RAQMON packets in one network or transport packet reduces header overhead. The memo [SIDDIQUI2] defines the RAQMON QOS PDU and describes how various PDUs can be transported over existing Application level transport protocol Anwar Siddiqui Expires April 2003 [Page 15] INTERNET DRAFT RAQMON Framework October 2002 like Real Time Communication protocol (RTCP) and Simple Network Management Protocol (SNMP) between RDS and RRC. 4.4.1 Design Considerations for the RDS/RRC Network Transport Protocol interface The Protocol should be: 1. Lightweight - RDSs will be implemented on low powered embedded devices with limited device resources such as IP Phones, Hand held computing devices, cellular phones, pagers etc. It is a requirement that the protocol be simple and flexible. 2. Scalable - Since RRCs need to interact with very large number of RDSs, it is a requirement that the protocol be highly scalable. 3. Security - Since RAQMON statistics may contain sensitive system information it is imperative that the protocol provides a strong security solution. 4. It is recommended that no more than 10% network bandwidth in a system be used for RDS/RRC reporting. More frequent reports from an RDS to RRC would imply requirements for higher network bandwidth usage. 5. NAT Friendly - Comply with [RFC3235], so that an RDS could communicate with an RRC through a Firewall/Network Address Translation device. 6. The protocol may be lossy, as RAQMON deals with getting statistics rather than billing type critical functionalities. 4.5 Mapping RAQMON PDUs in existing Transport Protocol Both RTCP and SNMP can be used as an underlying transport protocol to carry RAQMON PDUs between RDS and RRC. Section 5.4.1 describes a transport protocol that uses SNMP Inform PDUs and section 5.4.2 borrows heavily from RTCP-like reports to carry RAQMON PDUs. 4.5.1 SNMP Inform PDUs as RDS/RRC Network Transport Protocol The idea is to re-use SNMP INFORM PDU. This proposal suggest that: + RDSs implement the capability of embedding RAQMON information in SNMP INFORM and thus re-using well-known SNMP mechanisms to report RAQMON statistics. Anwar Siddiqui Expires April 2003 [Page 16] INTERNET DRAFT RAQMON Framework October 2002 + To keep the RDS realization simple and keep the protocol lightweight, the RDSs will not be REQUIRED to respond to SNMP requests like get, set, etc., as an SNMP compliant responder would. + If the RRC chooses to implement an SNMP manager, an SNMP INFORM Response could be sent for each associated SNMP INFORM originated by the RDS. + The RDS may ignore the SNMP INFORM Responses, or, if better reliability is required, will wait for the Inform response, retransmitting the original Inform PDU every M seconds until it has been sent N times. + The SNMP INFORM transport for RAQMON PDUs can use one of the two UDP ports assignments: - Standard UDP port 162 used for SNMP Notifications, if full SNMP entities implementations are present in the RRC and RDS - IANA assigned UDP port 5YYYY for RAQMON PDUs carried over SNMP, for the cases when at least one of the RRC and RDS does not support a full implementation of the SNMP entities. The benefits of using SNMP Informs are: - Using a well-known protocol. - Privacy and authentication are covered by SNMPv3 - Limited or no need for specific RAQMON-protocol code in the RRC, as it can use an SNMP manager implementation to process Informs. The drawback of this approach is the overhead SNMP puts on low-powered RDSs, for instance - BER encoding. 4.5.2 RTCP like protocol as RDS/RRC Network Transport Protocol The protocol is comprised of unidirectional exchange of PDUs between RDSs and an RRC. The protocol data units are mapped to a connectionless datagram service (UDP). RRC interface of RTCP based transport need to deal with one simple RDS Report (i.e. like RTCP reports). + During a monitored real-time session, the RDS emits a Report PDU every M seconds toward the RRC as provisioned by the RDS. + Since the PDUs are required to carry "complete" set of information, the reporting between RDS and RRC is stateless. Though this is a simple one-way send protocol, the RDSs will not be capable Anwar Siddiqui Expires April 2003 [Page 17] INTERNET DRAFT RAQMON Framework October 2002 of inferring whether a PDU was received by the RRC as Report PDUs are transmitted over a lossy network. So one uses proposed RTCP like protocol as RDS/RRC Network Transport Protocol each Report PDU must contain enough information to uniquely Identify the PDUs and correlate to an ongoing session. RRCs could use DSRC field and a unique device ID (i.e. like 6 Octet MAC address or IP Address) to define a unique session. However this will cause 6-octet overhead worth wasted bandwidth per PDU which could result in a significant wasted bandwidth. 4.5.2.1 - Pseudo code for RDS & RRC RDS: when (session starts} { report.identifier = session.endpoints, session.starttime; report.timestamp = 0; while (session in progress) { wait interval; report.statistics = update statistics; report.curtimestamp += interval; if encryption required report_data = encrypt(report, encrypt parameters); else report_data = report; raqmon_pdu = header, report_data; send raqmon-pdu; } } RRC: listen on raqmon port when ( raqmon_pdu received ) { decrypt raqmon_pdu.data if needed if report.identifier in database if report.current_time_stamp > last update update session statistics from report.statistics else discard report } 4.5.2.2 Port Assignment Anwar Siddiqui Expires April 2003 [Page 18] INTERNET DRAFT RAQMON Framework October 2002 As specified in the previous sections that Transport of RAQMON PDUs can be performed using various underlying network transport protocol like TCP and UDP. Applications operating under 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 using RAQMON are likely to run on the same host, and there are some operating systems that do not allow multiple processes to use the same UDP port with different multicast addresses. However, port numbers 5XXX have been registered with IANA for use with those applications that choose to use them as the default port for RAQMON PDUs over RTCP. Hosts that run multiple applications may use this port as an indication to have used RAQMON if they are not subject to the constraint of the previous paragraph. 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. 4.5.2.3 Reliability RAQMON framework will allow an RDS to report QOS Parameters to multiple RRCs. Such mechanism would allow better chances of backup and restore QOS parameters. However backup, synchronization of multiple RRCs are beyond the scope of this document is left to the discretion of system designers and implementers. 4.6 Report Aggregation and Statistical Data processing The RAQMON MIB is designed to provide very simple and minimal aggregations of various RAQMON Parameters defined in table 1. RAQMON MIB is designed to not to provide extensive aggregations like APM MIB [29] or TPM MIB [30] and one should use APM and TPM MIBs to aggregate based on protocols (e.g. Performance of HTTP, RTP) or based on application (e.g. Performance of VoIP, Video Applications). In RAQMON Framework, RDSs are not burdened by statistical data processing as RDSs may be co-resident in end-devices and could be resource constrained. Various aggregations are performed by the RRC. Aggregation of RAQMON parameters collected over a period of time is Anwar Siddiqui Expires April 2003 [Page 19] INTERNET DRAFT RAQMON Framework October 2002 dependent on aggregation algorithms. In the RAQMON MIB, aggregation can be performed only on specific RAQMON metrics parameters specified below: End-to-End Delay Inter Arrival Jitter Cumulative Packet Loss Packet Loss in Fraction CPU utilization in Fraction Memory utilization in Fraction The aggregation always results in the following statistics: Mean End-to-End Delay Min End-to-End Delay Max End-to-End Delay Mean Inter Arrival Jitter Min Inter Arrival Jitter Max Inter Arrival Jitter Mean Cumulative Packet Loss Min Cumulative Packet Loss Max Cumulative Packet Loss Mean Packet Loss in Fraction Min Packet Loss in Fraction Max Packet Loss in Fraction Mean CPU utilization in Fraction Min CPU utilization in Fraction Anwar Siddiqui Expires April 2003 [Page 20] INTERNET DRAFT RAQMON Framework October 2002 Max CPU utilization in Fraction Mean Memory utilization in Fraction Min Memory utilization in Fraction Max Memory utilization in Fraction For this document following aggregation definitions are used: Mean: Mean is defined as the statistical average of a metric over the duration of a communication session. For example if End-to-End delay metric of an end device within a communication session is reported N times by the RDS, then the Mean End-to-End Delay is the average End-to-End Delay metric over N entries. Min: Min is defined as the statistical minimum of a metric over the duration of a communication session. For example if End-to-End delay metric of an end device within a communication session is reported N times by the RDS, then the Min End-to-End Delay is the minimum of all N End-to-End Delay metric entries in the table. Max: Max is defined as the statistical maximum of a metric over the duration of a communication session. For example if End-to-End delay metric of an end device within a communication session is reported N times by the RDS, then the Max End-to-End Delay is the maximum of all N End-to-End Delay metric entries in the table. 4.7 Keeping Historical Data and Storage It is evident from the document that, RAQMON MIB data need to be managed to optimize storage space. Enormous volume of data gathered in a communication session could be optimized for storage space by performing and storing only aggregated RAQMON metrics for history if required. Such storage space optimization can be performed in following ways: 1. Store data in the MIB only at the end of a communication session Anwar Siddiqui Expires April 2003 [Page 21] INTERNET DRAFT RAQMON Framework October 2002 (i.e. after receiving an END packet), the aggregated data could be stored in RAQMON MIB as Mean, Max or Min entry and saved for historical purposes. This will minimize storage space requirement, as instead of a column in a table, only few scalars will be used to store a metric. 2. A time based algorithms that aggregate data over a specific period of time within a communication session (i.e. thus requiring less entries) also reduces storage space requirements. For example, if RDS sends data out every 10 seconds and RRC writes to the RAQMON MIB once every minute, for every 6 data points there will be one MIB entry. 3. Clearing up historical data periodically over a calendar time using administration policy can perform further storage space optimization. For example, an administrator could create a policy such that all historical data get cleared up every 60 days. Such policies are interpreted by the application, not by the RRC and usage of these policies left at the application developer's discretion. 5. References [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000 [RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control" RFC 1890, January 1996. [RFC1889] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications" RFC 1889, 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. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [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. Anwar Siddiqui Expires April 2003 [Page 22] INTERNET DRAFT RAQMON Framework October 2002 [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 [WALDBUSSER] Steven Waldbusser, "Application Performance Measurement MIB", draft-ietf-rmonmib-apm-mib-04.txt, July 2001 [DIETZ] Russel Dietz, Robert Cole, "Transport Performance Metrics MIB", draft-ietf-rmonmib-tpm-mib-03.txt, July 2001 [ISO10646] International Standards Organization, "ISO/IEC DIS 10646-1:1993 information 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 [SIDDIQUI1] A. Siddiqui, D.Romascanu, E. Golovinsky, and R. Smith, "Real-time Application Quality of Service Monitoring (RAQMON) MIB", Internet-Draft, draft-siddiqui-rmonmib-raqmon-mib-01.txt, February 2002 [SIDDIQUI2] A. Siddiqui, S. Waldbusser, D.Romascanu, and E. Golovinsky, Anwar Siddiqui Expires April 2003 [Page 23] INTERNET DRAFT RAQMON Framework October 2002 "Protocol Data Units for Real-time Application Quality of Service Monitoring (RAQMON)", Internet-Draft, draft-siddiqui-raqmon-pdu- 00.txt, October 2002 [SIDDIQUI3] A. Siddiqui, D.Romascanu, E. Golovinsky, and R. Smith, "Real-time Application Quality of Service Monitoring (RAQMON) MIB", Internet-Draft, draft-siddiqui-rmonmib-raqmon-mib-02.txt, October 2002 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the Anwar Siddiqui Expires April 2003 [Page 24] INTERNET DRAFT RAQMON Framework October 2002 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. It is RECOMMENDED that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [RFC2274] and the View-based Access Control Model [RFC2275] is RECOMMENDED. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, 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. It is also imperative that the RAQMON framework be able to provide the following protection mechanisms: 1. Authentication - the RRC should be able to verify that a RAQMON report was originated by whom ever claims to have sent it. 2. Privacy - RAQMON information include identification of the parties participating in a communication session. RAQMON framework should be able to provide protection from eavsdropping, to prevent an un-authorized third party from gathering potentially sensitive information. This can be achieved by using various payload encryption technologies like DES, 3-DES, AES 3. Protection from denial of service attacks directed at the RRC - RDSs send RAQMON reports as a side effect of an external event (for example, a phone call is being received). An attacker can try and overwhelm the RRC (or the network) by initiating a large number of events (i.e., calls) for the purpose of swamping the RRC with too many RAQMON PDUs. To prevent DoS attacks against RRC, the RDS will send the first report for a session only after the session has been in progress for the TBD reporting interval. Sessions shorter than that will not be reported. 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. Anwar Siddiqui Expires April 2003 [Page 25] INTERNET DRAFT RAQMON Framework October 2002 8. IANA Considerations This memo introduces 2 new ports for IANA registration. This specification registers port 5YYYY as specified in Section 4.5.1 and Port 5XXX as specified in section 4.5.2.2. at http://www.iana.org/numbers.html 9. Authors' Addresses Anwar A. Siddiqui Avaya Labs 307 Middletown Lincroft Road Lincroft, New Jersey 07738 USA Tel: +1 732 852-3200 Fax: +1 732 817-5922 E-mail: anwars@avaya.com Dan Romascanu Avaya Inc. Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Tel: +972-3-645-8414 Email: dromasca@avaya.com Eugene Golovinsky BMC Software Inc. 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 Anwar Siddiqui Expires April 2003 [Page 26] INTERNET DRAFT RAQMON Framework October 2002 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. Anwar Siddiqui Expires April 2003 [Page 27]