Internet Draft Anwar A. Siddiqui Avaya Inc. Dan Romascanu Avaya Inc. Richard Smith Avaya Inc. 12 November 2001 Real-time Application Quality of Service Monitoring (RAQMON) MIB 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 (2001). All Rights Reserved. Abstract This memo defines a portion of 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]. In particular, it describes managed objects used for realtime application monitoring that reflects "a specific end user's application Quality of Service (QOS) related parameters" on a "specific IP end point" on a "specific transport network environment". Distribution of this memo is unlimited. A. Siddiqui Expires May 2002 [Page 1] INTERNET DRAFT RAQMON MIB November 2001 Table of Contents Status of this Memo 1 Abstract 1 1 Introduction 2 2 The SNMP Management Framework 2 3 Overview 3 4 A Simple Metrics 6 5 RAQMON Framework 12 6 Definitions 23 7 References 40 8 Intellectual Property 44 9 Security Considerations 44 10 Author's Address 45 A Full Copyright Statement 45 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. This memo also includes a MIB module. This MIB module extends the list of managed objects specified in [RFC2819]. 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. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and A. Siddiqui Expires May 2002 [Page 2] INTERNET DRAFT RAQMON MIB November 2001 described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview The objective of this document is to define a framework for Realtime Application QOS Monitoring (RAQMON). 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 to its underlying transport network characteristics. For this memo it is assumed that such IP end points are producers and consumers of IP Traffic. This is further assumed that these devices could potentially run one or many 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 etc. These applications have become such a commodity in our everyday lives that A. Siddiqui Expires May 2002 [Page 3] INTERNET DRAFT RAQMON MIB November 2001 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 framework. Monitoring of applications QOS in these environments has certain specific needs: + Monitoring should be performed at the "application layer" that reflects "a specific end user experience" on a "specific IP end point" reflecting "specific transport network state". It is important to note that user experience of any of these applications running on a specific IP end point has lot to do with the type of application an user is running, local end device resources used as well as the underlying transport network capabilities. + Quality of service parameters of each communication session should be captured and stored completely. A communication session may consist of one or some combinations of transaction-oriented, throughput-oriented, or streaming-oriented transaction. For example quality-of-service definition of a Voice over IP call using IP Phones, involves some signaling for call setup that includes a transaction with a call processing server which eventually streams media between two IP end points as a result of call setup signaling using a protocol like H.323 or SIP. RAQMON draft would use the following definitions of transactions as defined in the draft-ietf-rmonmib-apm-mib-04.txt [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 and computing infrastructure. However, when the infrastructures cannot deliver data at this speed, interruption of service or degradation of service can result. A. Siddiqui Expires May 2002 [Page 4] INTERNET DRAFT RAQMON MIB November 2001 + 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 definition needs to be simple and intuitive to Application Service Providers, IT Managers, network operators, equipment vendors etc. As metrics are application-context sensitive, it is expected that proposed monitoring framework should provide a mechanism to add or drop parameters from the metrics definition list very easily to fit the need of the application-context. + Monitored statistics is reported by the IP end points at will. Though monitoring is a useful but there are various operation scenarios where monitoring could be an expensive operation and degrade the QOS of an application. There are also restrictions imposed on these devices based on the administrative domains in which these devices operate. For example, an Enterprise IP Phone user is managed by the enterprise IT manager, but the network bandwidth and Service Level Agreements are monitored and managed by the ISP. In such an environment, IP Phones may be required to report QOS Problems to various administrative authority and restricted by the administration domain policy. A. Siddiqui Expires May 2002 [Page 5] INTERNET DRAFT RAQMON MIB November 2001 Since monitoring is constrained by the end points resources and administrative policy of the end device operational environment, the monitoring framework needs to be end point driven and optimized for local IP device resources as well as it needs to be light, scalable and easy to deploy. 4. 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 a so called "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 A. Siddiqui Expires May 2002 [Page 6] INTERNET DRAFT RAQMON MIB November 2001 15. Total number of Octets Received 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 Flag (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 definition 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- A. Siddiqui Expires May 2002 [Page 7] INTERNET DRAFT RAQMON MIB November 2001 phone4630.bigcompany.com". It is recommended that the standard host's numeric address not be reported via DN parameter as Data Source 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) would 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]. A. Siddiqui Expires May 2002 [Page 8] INTERNET DRAFT RAQMON MIB November 2001 Session Setup delay: Session setup delay indicates the duration of 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 session 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 there application need. 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 A. Siddiqui Expires May 2002 [Page 9] INTERNET DRAFT RAQMON MIB November 2001 methodologies and left upon the implementers based on there 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 there 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 A. Siddiqui Expires May 2002 [Page 10] INTERNET DRAFT RAQMON MIB November 2001 indicates Layer 2 values used by the Data Source to prioritize these 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 Flag (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. 4.1 Measurement Methodology It is not the intent of this document to recommend a methodology to A. Siddiqui Expires May 2002 [Page 11] INTERNET DRAFT RAQMON MIB November 2001 measure any of the QOS parameters defined in table 1. Measurement 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. 5. RAQMON Framework RAQMON framework is based on three entities: - RAQMON Data Source (RDS) - RAQMON Report Collector (RRC) - RAQMON MIB Structure 5.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 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 and it performs following basic functionalities: + RDS is responsible for gathering statistics of (a) a particular communication session involving multiple parties (b) running a particular application (c) on a particular device (d) on specific transport network environment. + RDS reports QOS parameters defined in table 1 to a RAQMON Report Collector (RRC). It is recommended that security pre-cautions be taken while forwarding end device or a user related QOS parameters from an RDS to RRCs. Please refer to the security sections of this draft for appropriate security measures. A. Siddiqui Expires May 2002 [Page 12] INTERNET DRAFT RAQMON MIB November 2001 +----------------------+ +---------------------------+ | 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 | +------------------+ +------------------+ +-------------+ 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. + A complete set or a sub-set of QOS parameters defined in table 1 can be reported by the RDS to RRC to comply with the RAQMON Framework. What parameters from table 1 get reported by the RDS to RRC is at the discretion of the RDS and RRC implementer. This kind of RDS functionality preserves context sensitivity as deemed important by an implementer without making the application burdened with details of metrics definition. + RAQMON Framework should allow an RDS to report QOS parameters to RRC as frequently needed by an application. For example, an application can report QOS parameters like Data Source Name (DN), Data Source IP Address (DA), Session setup time, Pay load type etc at the beginning or at the end of a communication session but update the RRC with dynamic QOS parameters like End-to-End Delay, Packet loss, Inter-arrival Jitter etc. periodically. A. Siddiqui Expires May 2002 [Page 13] INTERNET DRAFT RAQMON MIB November 2001 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. It is also recommended RRC be engineered for scalability as more frequent report implies more packets to be processed by the RRC. 5.2 RAQMON Packet Format: There are 3 types of RAQMON Packets used by the RDS to report various QOS parameters to RRC. BASIC: For reporting monitored data from an RDS to RRC which includes QOS parameters defined in table 1. BASIC Packets are marked as PAT = 1 END: Indicates end of a communication session or end of some sub-sessions within a communication session. END Packets are marked as PAT = 8 APP: These APP Packets can define Application specific packets. APP packets are marked as PAT = 4 Following is various RAQMON packet formats: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |P| RC | | | |X| PT = 1| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RC X |N| | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Source Address {DA} | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Address (RA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Application Name (AN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Data Source Name (DN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Receiver's Name (RN) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Session State ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Duration | A. Siddiqui Expires May 2002 [Page 14] INTERNET DRAFT RAQMON MIB November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative Packet Loss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Packets sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Packets received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Octets sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total # Octets received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Used | Receiver Port Used | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Source Payload |Reciver Payload| CPU | Memory | |Type | Type | Utilization | Utilization | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Setup Delay | Inter arrival Jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding |x|x|x|x|x|x|x|x| Packet loss | | |x|x|x|x|x|x|x|x| (In fraction)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - Basic Packet 5.2.1 BASIC Packet: version (V) : 3 bits - Identifies the version of RAQMON. This version is 1. padding (P): 1 bit - If the padding bit is set, this RAQMON packet contains some additional padding octets at the end which are not part of the monitoring information. The last octet of the padding is a count of how many padding octets should be ignored. Padding may be needed by some applications as reporting is based on the intent of RDS to report certain parameters. record count (RC): 4 bits - Total number of records contained in this packet. A value of zero is valid but useless. reserved bits: 3 bits - reserved for future extensions to the RAQMON Packet. IPversion Flag: 1 bit - While set to 1, IP Version Flag indicates that IP addresses are IP version 6 compatible. Packet Type (PAT): 4 bits - This indicates the type of RAQMON packet being sent. There are 3 types of RAQMON Packets. BASIC Packets (PAT = 1), APP Packet (PAT =4) and END Packets (PAT=8). length: 16 bits - The length of this RAQMON packet in 32-bit words minus one which includes the header and any padding. DSRC: 32 bits - Data Source identifier represents a unique session descriptor that points to a specific communication session between communicating entities. Uniqueness of DSRC is valid only within a session. DSRC values should be randomly generated using vendor chosen algorithms. It is not sufficient to obtain a DSRC simply by calling random() without carefully initializing the state. It is beyond the scope of this document define an algorithm to generate DSRC. However one could very easily use an algorithm like the one defined in Appendix A.6 in [17]. Depending on the choice of algorithm, there is a finite probability that two DSRCS from two different RDSs may be same. To further reduce the probability that two RDSs pick the same DSRC, it is recommended that an RRC or an application use Data Source Address (DA) and Data Source Name (DN) in conjunction with a DSRC value to reduce that probability drastically. A. Siddiqui Expires May 2002 [Page 15] INTERNET DRAFT RAQMON MIB November 2001 Each RAQMON packet consists of a DSRC followed by RC_n and RAQMON flags to indicate presence of appropriate RAQMON parameters as defined in table 1. RC_n: 4 bits - Record Count number to which the information in this record pertains. Record Count number indicates a sub-session within a communication session. A value of zero is a valid record number. Maximum number of records that can be described in one RAQMON Packet is 16 (i.e. 0000 - 1111). RAQMON Parameter Presence Flags (RPPF): 28 bits Each of these flags while set represent that this RAQMON packet contains corresponding parameters as specified in table 2 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |P| RC | | | |X| PT = 1| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RC N |8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number Presence/Absence of corresponding Parameter within this RAQMON packet 1 Data Source Address (DA) 2 Receiver Address (RA) 3 NTP Timestamp 4 Application Name 5 Data Source Name (DN) 6 Receiver Name (RN) 7 Session Setup Status 8 Session Duration 9 End-to-End Delay 0 Cumulative Packet Loss 1 Total number of Packets sent 2 Total number of Packets received 3 Total number of Octets sent 4 Total number of Octets received A. Siddiqui Expires May 2002 [Page 16] INTERNET DRAFT RAQMON MIB November 2001 5 Source Port Used 6 Receiver Port Used 7 S_Layer2 8 S_Layer3 9 D_Layer2 0 D_Layer3 1 Source Payload Type 2 Receiver Payload Type 3 CPU Utilization 4 Memory Utilization 5 Session Setup Delay 6 Inter arrival Jitter 7 Packet loss (in fraction) 8 RAQMON Optional Flag (ROF) Table 2: RAQMON Parameters and corresponding RPPF Data Source Name: - Data Source Name field starts with an 8-bit octet count describing the length of the text and the text itself. Note that the text can be no longer than 255 octets. The text is encoded according to the UTF-2 encoding specified in Annex F of ISO standard 10646 [ISO10646],[UNICODE]. This encoding is also known as UTF-8 or UTF-FSS. It is described in "File System Safe UCS Transformation Format (FSS_UTF)", X/Open Preliminary Specification, Document Number P316 and Unicode Technical Report #4. US-ASCII is a subset of this encoding and requires no additional encoding. The presence of multi-octet encoding is indicated by setting the most significant bit of a character to a value of one. Text is not null terminated because some multi-octet encoding include null octets. Data Source Name is terminated by one or more null octets, the first of which is interpreted as to denote the end of the string and the remainder as needed to pad until the next 32-bit boundary. Since the Data Source Name is expected to remain constant for the duration of the session, it is recommended that RDS report such field only once within a communication session to ensure efficient usage of network and system resources. Receiver Name: - Same as Data Source Name. Data Source Name and Receiver's Name are contiguous, i.e., items are not individually padded to a 32-bit boundary. Data Source Address: 32 bits - The standard ASCII representation of the end device's numeric address on the interface used for the communication session. The standard ASCII representation of an IP Version 4 address is "dotted decimal", also known as dotted quad. Other address types are expected to have ASCII representations that are mutually unique. 135.8.45.178 is an example of a valid Data Source Address. Since the Data Source Address is expected to remain constant for the duration of the session, it is recommended that RDS report such field only once within a communication session to ensure efficient usage of network and system resources. Receiver Address: 32 bits - Same as Data Source Address Application Name: - Application Name field starts with an 8-bit octet count describing the length of the text and the text itself. Application name field has same format as Data Source Name. This is a text string giving the name and possibly version of the application associated to that session, e.g., "XYZ VoIP Agent 1.2". This information may be useful for debugging purposes and is similar to the Mailer or Mail-System-Version SMTP headers. Since the Application Name is expected to remain constant for the duration of the session, it is recommended that RDS report such field only once within a communication session to ensure efficient usage of network and system resources. NTP timestamp: 64 bits - Indicates the wallclock time when the RAQMON packet was sent so that it may be used by the RRC to store Date/Time. A Data Source that has no notion of wallclock or time may set the NTP timestamp to zero. However that will waste 32 bits in the packet. An RDS should set the appropriate RAQMON flag to 0 to avoid such waste. Since NTP time stamp is intended to provide Date/Time of a session, it is recommended that the NTP Timestamp be used only in the first RAQMON packet to use network resources efficiently. However such a recommendation is context sensitive and should be enforced as deemed necessary by each application environment. The full resolution NTP timestamp is a 64-bit unsigned fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. In some fields where a more compact representation is appropriate, only the middle 32 bits are used; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. The high 16 bits of the integer part must be determined independently. Session Setup Status: - Session State field starts with an 8-bit octet count describing the length of the text and the text itself. This field is used to describe appropriate communication session states e.g. Call Established successfully, RSVP reservation failed etc. Session Duration: 32 bits - Session Duration is an unsigned Integer expressed in the order of seconds. A. Siddiqui Expires May 2002 [Page 17] INTERNET DRAFT RAQMON MIB November 2001 End-to-End Delay: 32 bits - End-to-End Delay is an unsigned Integer expressed in the order of milliseconds. Cumulative Packet Loss: 32 bits - The total number of packets from session RC_n that have been lost while this RAQMON packet was generated. This number is defined to be the number of packets expected less the number of packets actually received. Total number of Packets sent: 32 bits - The total number of packets transmitted within a communication session by the sender since starting transmission up until the time this RAQMON packet was generated. This counter is reset if the DSRC identifier is changed as it indicates a different session. Total number of Packets received: 32 bits - The total number of packets transmitted within a communication session by the receiver since starting transmission up until the time this RAQMON packet was generated. This counter is reset if the DSRC identifier is changed as it indicates a different session. Total number of Octets sent: 32 bits - The total number of payload octets (i.e., not including header or padding) transmitted in packets by the sender within a communication session since starting transmission up until the time this RAQMON packet was generated. This counter is reset if the DSRC identifier is changed as it indicates a different session. Total number of Octets received: 32 bits - The total number of payload octets (i.e., not including header or padding) transmitted in packets by the receiver within a communication session since starting transmission up until the time this RAQMON packet was generated. This counter is reset if the DSRC identifier is changed as it indicates a different session. Source Port Used: 16 bits - Port Number used by the Data Source as used by the application while this RAQMON Packet was generated. Receiver Port Used: 16 bits - Same as Source Port Used S_Layer2: 8 bits - Source Layer 2 priorities used to send packets to the receiver by this data source during this communication session. For example priority bits associated to IEEE 802.1p values for appropriate priorities. For example priority bits associated to IEEE 802.1p tags value of 5 reported via S_Layer2 parameter would indicate Video over IP from this data source is prioritized by some Layer 2 switch. S_Layer3: 8 bits - Layer 3 priorities used to send packets to the receiver by this data source during this communication session. For example priority bits associated to IP Precedence (i.e. 101XXXXX) or DiffServ PHB values (i.e EF, AF41) etc reported via S_Layer3 parameter would indicate whether applications from this data source is prioritized by some Layer 3 switch or not. D_Layer2: 8 bits - Layer 2 priorities used by the receiver to send packets to the data source during this communication session if the Data Source can learn such information. D_Layer3: 8 bits - Layer 3 priorities used by the receiver to send packets to the data source during this communication session if the Data Source can learn such information. Source Payload Type: 8 bit - This document follows definition of Payload Type (PT) as definition is in [RFC1890]. This 8 bit fields specify the type of audio, video or data media used to send packets to the receiver by this data source during a communication session. Table 3 indicates a small list of various Payload types as defined in [RFC1890] cited here for informational purposes. As this table indicates, if an application ought to indicate that the Source Pay Load Type used for a session were PCMA, Source Payload Field of the BASIC RAQMON packet ought to be 8. PT encoding audio/video clock rate channels name (A/V) (Hz) (audio) _______________________________________________________________ 0 PCMU A 8000 1 1 1016 A 8000 1 2 G721 A 8000 1 3 GSM A 8000 1 4 unassigned A 8000 1 5 DVI4 A 8000 1 6 DVI4 A 16000 1 7 LPC A 8000 1 8 PCMA A 8000 1 9 G722 A 8000 1 10 L16 A 44100 2 11 L16 A 44100 1 12 unassigned A 13 unassigned A 14 MPA A 90000 (see text) 15 G728 A 8000 1 16--23 unassigned A 24 unassigned V A. Siddiqui Expires May 2002 [Page 18] INTERNET DRAFT RAQMON MIB November 2001 25 CelB V 90000 26 JPEG V 90000 27 unassigned V 28 nv V 90000 29 unassigned V 30 unassigned V 31 H261 V 90000 32 MPV V 90000 33 MP2T AV 90000 34--71 unassigned ? 72--76 reserved N/A N/A N/A 77--95 unassigned ? 96--127 dynamic ? Table 3: Payload types (PT) for standard audio and video encodings Please refer to [RFC1890] for various other Audio, Video and Data related payload types. CPU Utilization: 8 bits - Percentage of CPU used over a time duration. Memory Utilization: 8 bits - Percentage of total memory over a time duration. Session Setup Delay: 16 bits - Indicates the duration of time required by a network communication controller to set a media path between the communicating entities or the end devices. This parameter is expressed in milliseconds. Inter-Arrival Jitter: 16 bits - An estimate of the statistical variance of packets inter-arrival time expressed in milliseconds. Packet Loss in Fraction: 8 bits - The fraction of packets from data source lost since the previous RAQMON was dispatched, expressed as a fixed point number with the binary point at the left edge of the field. (That is equivalent to taking the integer part after multiplying the loss fraction by 256.) This fraction is defined to be the number of packets lost divided by the number of packets expected. RAQMON Optional Flag: 8 bits - These bits are open to various vendors to be used for application specific bit level signaling. 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. 5.2.2 END Packet END packets are used to indicate that a communication session or a sub-session has been ended. An END packet should be the last an RDS sends to an RRDC. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |P| RC | | | |X| PT = 8| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Source Address {DA} | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RC I | |RC I+2 | | |RC N | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V), padding (P), record count (RC): As defined for BASIC Packet. A. Siddiqui Expires May 2002 [Page 19] INTERNET DRAFT RAQMON MIB November 2001 reserved bits: 2 bits - reserved for future extensions to the RAQMON Packet. RC Flag: 1 bit - While set to 1, RC Flag indicates that all RC_n marked sub-sessions within a session have been terminated and hence it is not required to mention RC_n numbers in the BYE Packet. END Packet with RC Flag = 1: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |P| RC | | | |X| PT = 8| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Source Address {DA} | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DSRC, Data Source Address and RC_n: As defined for BASIC Packet 5.2.3 APP Packet: The APP packet is intended for experimental use as new applications and new features are developed, without requiring packet type value registration. APP packets with unrecognized names should be ignored. After testing and if wider use is justified, it is recommended that each APP packet be redefined without the subtype and name fields and registered with the Internet Assigned Numbers Authority (IANA). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V |P| RC | | | |X| PT = 4| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Source Address {DA} | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | APP packet name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application dependent data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V), padding (P), record count (RC): As defined for BASIC Packet. reserved bits: 3 bits - reserved for future extensions to the RAQMON Packet. IPversion Flag: As defined for BASIC Packet. A. Siddiqui Expires May 2002 [Page 20] INTERNET DRAFT RAQMON MIB November 2001 DSRC and DA: As defined for BASIC Packet. subtype: 4 bits - May be used as a subtype to allow a set of APP packets to be defined under one unique name, or for any application-dependent data. packet type (PAT): 4 bits - Contains the constant 4 to identify this as an RAQMON APP packet. name: 4 octets - A name chosen by the person defining the set of APP packets to be unique with respect to other APP packets this application might receive. The application creator might choose to use the application name, and then coordinate the allocation of subtype values to others who want to define new packet types for the application. Alternatively, it is recommended that others choose a name based on the entity they represent, then coordinate the use of the name within that entity. The name is interpreted as a sequence of four ASCII characters, with uppercase and lowercase characters treated as distinct. application-dependent data: variable length - Application-dependent data may or may not appear in an APP packet. It is interpreted by the application and not by the RRC itself. It must be a multiple of 32 bits long. 5.2.4 Byte Order, Alignment, and Time Format 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. 5.3 RAQMON Report Collectors (RRC) An RAQMON Report Collector (RRC) accepts RAQMON packets from various RDSs as defined in previous section and analyzes RAQMON packets to store it into RAQMON MIB. 5.3.1 Network Transport Protocol Network Transport of RAQMON packets 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 RAQMON reports, however those reliability affects are no different than other application packet transport. 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 data packets contain no length field or other delineation. It 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 packets 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. 5.3.2 Port Assignment As specified in the previous section that Transport of RAQMON data can be performed using various underlying network transport protocol including TCP and UDP. Applications operating under RAQMON Framework may use any such UDP port or TCP 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. 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. 5.3.3 Scalability A RAQMON Report collector should be designed for scalability and should be engineered for storage space depending on the type, size of RAQMON packets it is expected to receive and corresponding rate at which various RDSs forwards these packets to RRC. The rate at which an RDS forwards various RAQMON packets to an RRC is beyond the scope of this document and left to the vendor implementation. However it is recommended systems are designed and deployed such that no more than 5% aggregate network bandwidth is used for RAQMON Traffic. 5.3.4 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. A. Siddiqui Expires May 2002 [Page 21] INTERNET DRAFT RAQMON MIB November 2001 5.3.5 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 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 A. Siddiqui Expires May 2002 [Page 22] INTERNET DRAFT RAQMON MIB November 2001 Max Packet Loss in Fraction Mean CPU utilization in Fraction Min CPU utilization in Fraction 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. 5.3.6 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 (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. 6. Definitions A. Siddiqui Expires May 2002 [Page 23] INTERNET DRAFT RAQMON MIB November 2001 IMPORTS OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF mib-2, enterprises, IpAddress, Integer32, Unsigned32, Gauge32, Counter64, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI RowStatus, TEXTUAL-CONVENTION FROM SNMPv2-TC Utf8String FROM SYSAPPL-MIB; raqmon MODULE-IDENTITY LAST-UPDATED "200104061146Z" ORGANIZATION "Avaya Inc." CONTACT-INFO "Richard Smith Postal: Avaya Australia Pty Ltd 123 Epping Rd North Ryde NSW 2113 Australia Tel: +61 2 9886 8987 Email: rsmith9@avaya.com " DESCRIPTION "RAQMON MIB" ::= { mib-2 6889 } -- -- Type definitions -- Duration ::= Unsigned32 -- -- Textual conventions -- RaqmonDateAndTime ::= TEXTUAL-CONVENTION DISPLAY-HINT "2d-1d-1d,1d:1d:1d" STATUS current DESCRIPTION "A date-time specification in Coordinated Universal Time (UTC). A. Siddiqui Expires May 2002 [Page 24] INTERNET DRAFT RAQMON MIB November 2001 This definition is used rather than DateAndTime from SNMPv2-TC or ExtUTCTime from SMIv2 since a fixed length field in UTC was preferred for use as an INDEX. field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..59 For example, Tuesday May 26, 1992 at 1:30:15 UTC would be displayed as: 1992-5-26,13:30:15." SYNTAX OCTET STRING (SIZE (7)) -- -- Node definitions -- raqmonEvents OBJECT IDENTIFIER ::= { raqmon 0 } raqmonSessionAlarm NOTIFICATION-TYPE OBJECTS { raqmonParticipantAddr, raqmonParticipantName, raqmonParticipantPeerAddr, raqmonQosRTT, raqmonQosJitter, raqmonQosLostPackets, raqmonQosRcvdPackets } STATUS current DESCRIPTION "A notification generated by an entry in the raqmonSessionExceptionTable." ::= { raqmonEvents 5 } raqmonMIBObjects OBJECT IDENTIFIER ::= { raqmon 1 } raqmonSession OBJECT IDENTIFIER ::= { raqmonMIBObjects 1 } raqmonParticipantTable OBJECT-TYPE SYNTAX SEQUENCE OF RaqmonParticipantEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of information about participants in sessions. Contains both active and closed sessions. A. Siddiqui Expires May 2002 [Page 25] INTERNET DRAFT RAQMON MIB November 2001 " ::= { raqmonSession 1 } raqmonParticipantEntry OBJECT-TYPE SYNTAX RaqmonParticipantEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information from a single session participant. Rows are removed for inactive sessions when implementation specific age or space limits are reached. " INDEX { raqmonParticipantStartDate, raqmonParticipantIndex } ::= { raqmonParticipantTable 1 } RaqmonParticipantEntry ::= SEQUENCE { raqmonParticipantStartDate RaqmonDateAndTime, raqmonParticipantIndex Integer32, raqmonParticipantAddr IpAddress, raqmonParticipantSendPort INTEGER, raqmonParticipantRecvPort Integer32, raqmonParticipantSetupDelay Unsigned32, raqmonParticipantName Utf8String, raqmonParticipantTool Utf8String, raqmonParticipantQosCount Unsigned32, raqmonParticipantEndDate RaqmonDateAndTime, raqmonParticipantRcvdPT INTEGER, raqmonParticipantSentPT INTEGER, raqmonParticipantActive Integer32, raqmonParticipantPeerIndex OCTET STRING, raqmonParticipantPeerAddr A. Siddiqui Expires May 2002 [Page 26] INTERNET DRAFT RAQMON MIB November 2001 IpAddress, raqmonParticipantSrcLayer2 INTEGER, raqmonParticipantDestLayer2 INTEGER, raqmonParticipantSrcLayer3 INTEGER, raqmonParticipantDestLayer3 INTEGER, raqmonParticipantCPUMean INTEGER, raqmonParticipantCPUMin INTEGER, raqmonParticipantCPUMax INTEGER, raqmonParticipantMemoryMean INTEGER, raqmonParticipantMemoryMin INTEGER, raqmonParticipantMemoryMax INTEGER, raqmonParticipantRTTMean Gauge32, raqmonParticipantRTTMin Gauge32, raqmonParticipantRTTMax Gauge32, raqmonParticipantJitterMean Gauge32, raqmonParticipantJitterMin Gauge32, raqmonParticipantJitterMax Gauge32, raqmonParticipantPackets Counter64, raqmonParticipantLostPackets Counter64 } raqmonParticipantStartDate OBJECT-TYPE SYNTAX RaqmonDateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The date and time of this entry. It will be the date and time of the first report received." ::= { raqmonParticipantEntry 1 } A. Siddiqui Expires May 2002 [Page 27] INTERNET DRAFT RAQMON MIB November 2001 raqmonParticipantIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the conceptual row which is for SNMP purposes only and has no relation to any protocol value. There is no requirement that these rows are created or maintained sequentially. The index will be unique for a particular date and time." ::= { raqmonParticipantEntry 2 } raqmonParticipantAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "IP Address of the participant for this session." ::= { raqmonParticipantEntry 3 } raqmonParticipantSendPort OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "Port from which session data is sent." ::= { raqmonParticipantEntry 4 } raqmonParticipantRecvPort OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "Port on which session data is received." ::= { raqmonParticipantEntry 5 } raqmonParticipantSetupDelay OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Session setup time in milliseconds." ::= { raqmonParticipantEntry 6 } raqmonParticipantName OBJECT-TYPE A. Siddiqui Expires May 2002 [Page 28] INTERNET DRAFT RAQMON MIB November 2001 SYNTAX Utf8String MAX-ACCESS read-only STATUS current DESCRIPTION "The data source name for the participant." ::= { raqmonParticipantEntry 7 } raqmonParticipantTool OBJECT-TYPE SYNTAX Utf8String (SIZE (0..127)) MAX-ACCESS read-only STATUS current DESCRIPTION "A string giving the name and possibly version of the application generating the stream, e.g., videotool 1.2. This information may be useful for debugging purposes and is similar to the Mailer or Mail- System-Version SMTP headers. The tool value is expected to remain constant for the duration of the session." ::= { raqmonParticipantEntry 8 } raqmonParticipantQosCount OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of entries in the QOS history table for this participant and session." ::= { raqmonParticipantEntry 9 } raqmonParticipantEndDate OBJECT-TYPE SYNTAX RaqmonDateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The date and time of the last report received." ::= { raqmonParticipantEntry 10 } raqmonParticipantRcvdPT OBJECT-TYPE SYNTAX INTEGER (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "Payload type of received packets." ::= { raqmonParticipantEntry 11 } A. Siddiqui Expires May 2002 [Page 29] INTERNET DRAFT RAQMON MIB November 2001 raqmonParticipantSentPT OBJECT-TYPE SYNTAX INTEGER (0..127) MAX-ACCESS read-write STATUS current DESCRIPTION "Payload type of sent packets." ::= { raqmonParticipantEntry 12 } raqmonParticipantActive OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates if the session for this participant is active (open). If so this field is non-zero. If the session is closed this field contains zero. " ::= { raqmonParticipantEntry 13 } raqmonParticipantPeerIndex OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 11)) MAX-ACCESS read-only STATUS current DESCRIPTION "The index of the corresponding entry in this table for the other peer participant. If there is no such entry then the value will be a zero length string. Otherwise it will be a string of length 11 consisting of the raqmonParticipantStartDate octet string appended with an octet string of length 4 containing raqmonParticipantIndex (most significant octet first). Note, the entry may no longer exist even if the index is not zero length since the entry may have been deleted due to implementation defined limits being exceeded. " ::= { raqmonParticipantEntry 14 } raqmonParticipantPeerAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "IP address of peer endpoint." A. Siddiqui Expires May 2002 [Page 30] INTERNET DRAFT RAQMON MIB November 2001 ::= { raqmonParticipantEntry 15 } raqmonParticipantSrcLayer2 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Source Layer 2 priority" ::= { raqmonParticipantEntry 16 } raqmonParticipantDestLayer2 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Destination Layer 2 priority." ::= { raqmonParticipantEntry 17 } raqmonParticipantSrcLayer3 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "Source Layer 3 priority" ::= { raqmonParticipantEntry 18 } raqmonParticipantDestLayer3 OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "Destination Layer 3 priority" ::= { raqmonParticipantEntry 19 } raqmonParticipantCPUMean OBJECT-TYPE SYNTAX INTEGER (0..100) MAX-ACCESS read-only STATUS current DESCRIPTION "Mean CPU utilization as a percentage." ::= { raqmonParticipantEntry 20 } raqmonParticipantCPUMin OBJECT-TYPE SYNTAX INTEGER (0..100) MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum CPU utilization as a percentage." A. Siddiqui Expires May 2002 [Page 31] INTERNET DRAFT RAQMON MIB November 2001 ::= { raqmonParticipantEntry 21 } raqmonParticipantCPUMax OBJECT-TYPE SYNTAX INTEGER (0..100) MAX-ACCESS read-write STATUS current DESCRIPTION "Maximum CPU utilization as a percentage." ::= { raqmonParticipantEntry 22 } raqmonParticipantMemoryMean OBJECT-TYPE SYNTAX INTEGER (0..100) MAX-ACCESS read-only STATUS current DESCRIPTION "Mean memory utilization as a percentage." ::= { raqmonParticipantEntry 23 } raqmonParticipantMemoryMin OBJECT-TYPE SYNTAX INTEGER (0..100) MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum memory utilization as a percentage." ::= { raqmonParticipantEntry 24 } raqmonParticipantMemoryMax OBJECT-TYPE SYNTAX INTEGER (0..100) MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum memory utilization as a percentage." ::= { raqmonParticipantEntry 25 } raqmonParticipantRTTMean OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Mean round trip time (RTT) over the entire session." ::= { raqmonParticipantEntry 26 } raqmonParticipantRTTMin OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum round trip time (RTT) over the entire session." A. Siddiqui Expires May 2002 [Page 32] INTERNET DRAFT RAQMON MIB November 2001 ::= { raqmonParticipantEntry 27 } raqmonParticipantRTTMax OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum round trip time (RTT) over the entire session." ::= { raqmonParticipantEntry 28 } raqmonParticipantJitterMean OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Mean jitter over the entire session." ::= { raqmonParticipantEntry 29 } raqmonParticipantJitterMin OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Minimum jitter over the entire session." ::= { raqmonParticipantEntry 30 } raqmonParticipantJitterMax OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Maximim jitter over the entire session." ::= { raqmonParticipantEntry 31 } raqmonParticipantPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of packets received for the entire session." ::= { raqmonParticipantEntry 32 } raqmonParticipantLostPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of packets lost by this A. Siddiqui Expires May 2002 [Page 33] INTERNET DRAFT RAQMON MIB November 2001 receiver for the entire session." ::= { raqmonParticipantEntry 33 } raqmonQosTable OBJECT-TYPE SYNTAX SEQUENCE OF RaqmonQosEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of historical information about quality of service data during sessions. " ::= { raqmonSession 2 } raqmonQosEntry OBJECT-TYPE SYNTAX RaqmonQosEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information from a single RAQMON packet. Rows are removed for inactive sessions when implementation specific time or space limits are reached. " INDEX { raqmonParticipantStartDate, raqmonParticipantIndex, raqmonQosTime } ::= { raqmonQosTable 1 } RaqmonQosEntry ::= SEQUENCE { raqmonQosTime Duration, raqmonQosRTT Gauge32, raqmonQosJitter Gauge32, raqmonQosRcvdPackets Integer32, raqmonQosRcvdOctets Integer32, raqmonQosSentPackets Integer32, raqmonQosSentOctets Integer32, raqmonQosLostPackets Integer32, raqmonQosRsvpStatus INTEGER A. Siddiqui Expires May 2002 [Page 34] INTERNET DRAFT RAQMON MIB November 2001 } raqmonQosTime OBJECT-TYPE SYNTAX Duration MAX-ACCESS read-only STATUS current DESCRIPTION "Time of this entry measured from the start of the corresponding participant session." ::= { raqmonQosEntry 1 } raqmonQosRTT OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The round trip time. Will contain the previous value if there was no report for this time (or 2^32 - 1 if value never reported). " ::= { raqmonQosEntry 2 } raqmonQosJitter OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of delay variation as observed by this receiver. Will contain the previous value if there was no report for this time (or 2^32 - 1 if value never reported). " ::= { raqmonQosEntry 3 } raqmonQosRcvdPackets OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of packets received by this receiver since the last entry containing a value for this field. This is not a cumulative value since the start of the session. Set to -1 if value not reported for this time. " ::= { raqmonQosEntry 4 } A. Siddiqui Expires May 2002 [Page 35] INTERNET DRAFT RAQMON MIB November 2001 raqmonQosRcvdOctets OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of octets received by this receiver since the last entry containing a value for this field. This is not a cumulative value since the start of the session. Set to -1 if value not reported for this time. " ::= { raqmonQosEntry 5 } raqmonQosSentPackets OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of packets sent since the last entry containing a value for this field. This is not a cumulative value since the start of the session. Set to -1 if value not reported for this time. " ::= { raqmonQosEntry 6 } raqmonQosSentOctets OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of octets sent since the last entry containing a value for this field. This is not a cumulative value since the start of the session. Set to -1 if value not reported for this time. " ::= { raqmonQosEntry 7 } raqmonQosLostPackets OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of packets lost as observed by this receiver since the last entry containing a value for this field. Set to -1 if value not reported for this time." ::= { raqmonQosEntry 8 } A. Siddiqui Expires May 2002 [Page 36] INTERNET DRAFT RAQMON MIB November 2001 raqmonQosRsvpStatus OBJECT-TYPE SYNTAX INTEGER { unknown(-1), notInUse(0), disabled(1), reservationPending(2), reservationFailed(3), reservationSuccess(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The RSVP status. Will contain the previous value if there was no report for this time (or if no value was ever reported)." ::= { raqmonQosEntry 9 } raqmonParticipantAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF RaqmonParticipantAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Maps raqmonParticipantAddr to the index of the raqmonParticipantTable. This table allows management applications to find entries sorted by raqmonParticipantAddr rather than raqmonParticipantStartDate." ::= { raqmonSession 3 } raqmonParticipantAddrEntry OBJECT-TYPE SYNTAX RaqmonParticipantAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to exactly one entry in the raqmonParticipantEntry - the entry containing the index pair rraqmonParticipantStartDate, raqmonParticipantIndex." INDEX { raqmonParticipantAddr, raqmonParticipantStartDate, raqmonParticipantIndex } ::= { raqmonParticipantAddrTable 1 } RaqmonParticipantAddrEntry ::= SEQUENCE { raqmonParticipantAddrEndDate RaqmonDateAndTime A. Siddiqui Expires May 2002 [Page 37] INTERNET DRAFT RAQMON MIB November 2001 } raqmonParticipantAddrEndDate OBJECT-TYPE SYNTAX RaqmonDateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The value of raqmonParticipantEndDate for the corresponding raqmonParticipantEntry." ::= { raqmonParticipantAddrEntry 1 } raqmonException OBJECT IDENTIFIER ::= { raqmonMIBObjects 2 } raqmonSessionExceptionTable OBJECT-TYPE SYNTAX SEQUENCE OF RaqmonSessionExceptionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table creates filters so that a management station can get immediate notification of a session that has had poor quality of service." ::= { raqmonException 2 } raqmonSessionExceptionEntry OBJECT-TYPE SYNTAX RaqmonSessionExceptionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A conceptual row in the raqmonSessionExceptionTable." INDEX { raqmonSessionExceptionIndex } ::= { raqmonSessionExceptionTable 1 } RaqmonSessionExceptionEntry ::= SEQUENCE { raqmonSessionExceptionIndex INTEGER, raqmonSessionExceptionJitterThreshold Unsigned32, raqmonSessionExceptionRttThreshold Unsigned32, raqmonSessionExceptionLostPacketsThreshold Integer32, raqmonSessionExceptionRowStatus RowStatus } A. Siddiqui Expires May 2002 [Page 38] INTERNET DRAFT RAQMON MIB November 2001 raqmonSessionExceptionIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index that uniquely identifies an entry in the raqmonSessionExceptionTable." ::= { raqmonSessionExceptionEntry 2 } raqmonSessionExceptionJitterThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Threshold for jitter in units of milliseconds. The value during a session must be greater than or equal to this value for an exception to be created." ::= { raqmonSessionExceptionEntry 3 } raqmonSessionExceptionRttThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "Threshold for round trip time in units of milliseconds. The value during a session must be greater than or equal to this value for an exception to be created." ::= { raqmonSessionExceptionEntry 4 } raqmonSessionExceptionLostPacketsThreshold OBJECT-TYPE SYNTAX Integer32 (0..1000) MAX-ACCESS read-write STATUS current DESCRIPTION "Threshold for lost packets in units of tenth of a percent. The value during a session must be greater than or equal to this value for an exception to be created." ::= { raqmonSessionExceptionEntry 5 } raqmonSessionExceptionRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Value of 'active' when exceptions are being monitored by the system. A newly-created conceptual row must have the all A. Siddiqui Expires May 2002 [Page 39] INTERNET DRAFT RAQMON MIB November 2001 read-create objects initialized before becoming 'active'. A conceptual row that is in the 'notReady' or 'notInService' state MAY be removed after 5 minutes." ::= { raqmonSessionExceptionEntry 7 } raqmonConfig OBJECT IDENTIFIER ::= { raqmonMIBObjects 3 } raqmonConfigPort OBJECT-TYPE SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION "The UDP port to listen on for RAQMON reports." ::= { raqmonConfig 1 } raqmonConformance OBJECT IDENTIFIER ::= { raqmon 2 } raqmonGroups OBJECT IDENTIFIER ::= { raqmonConformance 1 } raqmonGroup OBJECT-GROUP OBJECTS { raqmonParticipantStartDate, raqmonParticipantIndex, raqmonParticipantAddr, raqmonParticipantSendPort, raqmonParticipantRecvPort, raqmonParticipantSetupDelay, raqmonParticipantName, raqmonParticipantTool, raqmonParticipantQosCount, raqmonParticipantEndDate, raqmonParticipantRcvdPT, raqmonParticipantSentPT, raqmonParticipantActive, raqmonParticipantPeerIndex, raqmonParticipantPeerAddr, raqmonParticipantSrcLayer2, raqmonParticipantDestLayer2, raqmonParticipantSrcLayer3, raqmonParticipantDestLayer3, raqmonParticipantCPUMean, raqmonParticipantCPUMin, raqmonParticipantCPUMax, raqmonParticipantMemoryMean, raqmonParticipantMemoryMin, raqmonParticipantMemoryMax, raqmonParticipantRTTMean, raqmonParticipantRTTMin, raqmonParticipantRTTMax, raqmonParticipantJitterMean, raqmonParticipantJitterMin, raqmonParticipantJitterMax, raqmonParticipantPackets, raqmonParticipantLostPackets, raqmonQosTime, raqmonQosRTT, raqmonQosJitter, raqmonQosRcvdPackets, raqmonQosRcvdOctets, raqmonQosSentPackets, raqmonQosSentOctets, raqmonQosLostPackets, raqmonQosRsvpStatus, raqmonParticipantAddrEndDate, raqmonConfigPort, raqmonSessionExceptionIndex, raqmonSessionExceptionJitterThreshold, raqmonSessionExceptionRttThreshold, raqmonSessionExceptionLostPacketsThreshold, raqmonSessionExceptionRowStatus } STATUS current DESCRIPTION "Objects used in RAQMON" ::= { raqmonGroups 2 } raqmonNotifications NOTIFICATION-GROUP NOTIFICATIONS { raqmonSessionAlarm } STATUS current DESCRIPTION "Description." ::= { raqmonGroups 3 } END 7. References A. Siddiqui Expires May 2002 [Page 40] INTERNET DRAFT RAQMON MIB November 2001 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [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. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network A. Siddiqui Expires May 2002 [Page 41] INTERNET DRAFT RAQMON MIB November 2001 Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000 [RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks, Version 1.0", RFC 2613, June 1999 [RFC1213] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [RFC2863] McCloghrie, K., and Kastenholtz, F., "The Interfaces Group MIB", RFC 2863, June 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. A. Siddiqui Expires May 2002 [Page 42] INTERNET DRAFT RAQMON MIB November 2001 [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 [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 A. Siddiqui Expires May 2002 [Page 43] INTERNET DRAFT RAQMON MIB November 2001 8. 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. 9. 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 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. A. Siddiqui Expires May 2002 [Page 44] INTERNET DRAFT RAQMON MIB November 2001 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. 10. Authors' Addresses Anwar A. Siddiqui Avaya Labs 101 Crawfords Corner Road Holmdel, New Jersey 07733 USA Tel: +1 732 817-4608 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 Richard Smith Avaya Inc. 123 Epping Rd North Ryde NSW 2113 Australia Tel: +61 2 9886 8987 Email: rsmith9@avaya.com A. Full Copyright Statement This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. A. Siddiqui Expires May 2002 [Page 45] INTERNET DRAFT RAQMON MIB November 2001 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. A. Siddiqui Expires May 2002 [Page 46]