Internet Draft Anwar Siddiqui Avaya Inc. Dan Romascanu Avaya Eugene Golovinsky BMC Software 9 February 2004 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 made obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract There is a need to extend the RMON family of specifications to monitor end devices such as IP Phones, Pagers, Instant Message Clients, Mobile Phones, and various other hand-held computing devices. This memo extends the RMON family of specifications to allow QoS monitoring in real-time of various applications that run on these types of end devices and allows such information to be integrated with the RMON family of specifications via SNMP. Distribution of this memo is unlimited. RMON WG Expires August 2004 [Page 1] INTERNET DRAFT RAQMON Framework February 2004 Table of Contents Status of this Memo 1 Abstract 1 1 Introduction 2 2 RAQMON Functional Architecture 4 3 RAQMON Operation in Congestion Safe Mode 11 4 Measurement Methodology 13 5 A Simple list of Metrics pre-defined in BASIC PDU 14 6 Report Aggregation and Statistical Data processing 21 7 Keeping Historical Data and Storage 22 8 Normative References 23 9 Informative References 23 10 Intellectual Property 25 11 Security Considerations 25 12 Acknowledgements 29 13 Authors' Addresses 29 A Full Copyright Statement 30 1. Introduction With the growth of the Internet and the advancements in embedded technologies, smart IP devices such as IP phones, pagers, instant message clients, mobile phones, wireless hand-helds and various other computing devices have become an integral part of our day-to-day operations. Enterprise Operators, IT Managers, Application Service Providers, Network Service Providers etc. have an inherent need to monitor these types of applications and devices to assure end user quality of service. It is the objective of this draft to deliver a monitoring solution for such environment by extending the RMON family of specifications [RFC2819]. This memo extends the RMON family of specifications to allow real-time QoS Monitoring of various applications that run on these types of end-devices and allows such information to be integrated with the RMON family of specifications via SNMP. The Real-Time Application QoS Monitoring Framework (RAQMON) allows end devices and applications to report QoS statistics in real-time. Many real-time applications as well as non-real time applications managed within the RMON family of specifications can report application level QoS statistics in real-time using the RAQMON Framework outlined in this draft. Some possible applications scenarios include applications such as Voice over IP, Fax over IP, Video over IP, Instant Messaging (IM), Email, software download applications, e-business style transactions, web access from handheld computing devices, etc. The user experience of an application running on an IP end device RMON WG Expires August 2004 [Page 2] INTERNET DRAFT RAQMON Framework February 2004 depends upon the type of application the user is running and the surrounding resources available to that application. An end-to-end application quality of service (QoS) experience is a compound effect of various application level transactions and available network and host resources. For example, the end-to-end user experience of a Voice over IP (VoIP) call depends on the total time required to set up the call as much as on media related performance parameters such as end-to-end Delay, Jitter, Packet Loss, the type of codec used in a call. Behavior of network protocols like RSVP, explicit tags in DiffServ or IEEE 802.1p/Q, along with available host resources such as Device CPU or memory utilized by other applications while the call is ongoing also influence the performance of a VoIP call. End-to-end application quality of service (QoS) experience is application context sensitive. For example, the kinds of parameters reported by an IP telephony application may not really be needed for other applications such as Instant Messaging. The Real-Time Application QoS Monitoring (RAQMON) Framework offers a mechanism to report the end-to-end QoS experience appropriate for a specific application context by providing mechanisms to report a subset of metrics from a pre-defined list. In order to facilitate a complete end-to-end view, RAQMON correlates statistics that involve: i. "User, Application, Session" specific parameters - e.g. session setup time, session duration parameters based on application context. ii. "IP end device" specific parameters during a session - e.g. CPU usage, memory usage. iii. "Transport network" specific parameters during a session - e.g. end-to-end delay, one way delay, jitter, packet loss etc. At any given point, it's the applications at these devices that can correlate such diverse data and report end-to-end performance. The RAQMON Framework specified in this memo offers a mechanism to report such end-to-end QoS view and integrate such a view into the RMON family of specifications. In particular, the RAQMON Framework standardizes the following: a. A RAQMON Protocol Data Unit (PDU) exchanged between RAQMON entities using existing Internet Transport Protocols such as RTCP and SNMP. b. A portion of the Management Information Base (MIB) as an extension of the RMON MIB Modules for use with network management protocols in the Internet community. RMON WG Expires August 2004 [Page 3] INTERNET DRAFT RAQMON Framework February 2004 This memo provides the RAQMON functional architecture, RAQMON entity definitions, behavior of various RAQMON entities and definition of various parameters carried within the RAQMON PDU. The RAQMON PDU [RAQMON-PDU] memo provides definitions of syntactical PDU structure and use case scenarios of transmission of such PDUs over the Real-Time Transport Control Protocol (RTCP) and the Simple Network Management Protocol (SNMP). The RAQMON MIB [RAQMON-MIB] memo describes the Management Information Base (MIB) for use with the SNMP protocol in the Internet community. The document proposes an extension to the Remote Monitoring MIB [RFC2819] to accommodate RAQMON solutions. 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 Functional Architecture The RAQMON Framework extends the architecture created in the RMON MIB [RFC2819] by providing application performance information as experienced by end-users. The RAQMON architecture is based on three functional components named below: - RAQMON Data Source (RDS) - RAQMON Report Collector (RRC) - RAQMON MIB Structure A RAQMON Data Source (RDS) is a functional component that acts as a source of data for monitoring purposes. End-devices like IP phones, cell phones, pagers, application clients like instant message clients, soft phones in PCs, etc. are envisioned to act as RDSs within the RAQMON Framework. +----------------------+ +---------------------------+ | IP End-Device | | IP End-Device >----+ | |+--------------------+| |+--------------------+ | | || APPLICATION || || APPLICATION | | | || -Voice over IP <----(1)----> -Voice over IP >- + | | || -Instant Messaging|| || -Instant Messaging| | 3 | || -Email || || -Email | 2 | | |+--------------------+| |+--------------------+ | | | | | | | | | | | | +------------------+ | | | RMON WG Expires August 2004 [Page 4] INTERNET DRAFT RAQMON Framework February 2004 +----------------------+ | |RAQMON Data Source|<-+ | | | | (RDS) |<---+ | | +------------------+ | +-----------|---------------+ | (4) RAQMON PDU transported over RTCP APP Packet or SNMP Notifications | +----------------------------+ | | |/ |/ +------------------+ +------------------+ +-------------+ |RAQMON Report | .. |RAQMON Report | |Network Mngmt| |Collector (RRC) #n| |Collector (RRC) #1|<--5-->| Application | +------------------+ +------------------+ +-------------+ Figure 1 - RAQMON Framework. (1) Communication Session between applications (2) Context-Sensitive Metrics (3) Device State Specific Metrics (4) RAQMON metrics transmitted over specified interfaces (Specific Protocol Interface, IP Address, port) (5) Management Application - RRC interaction using the RAQMON MIB A RAQMON Report Collector (RRC) collects statistics from multiple RDSs, analyzes them, and stores such information appropriately. A RAQMON Report Collector (RRC) is envisioned to be a network server, serving an administrative domain defined by the network administrator. The RRC component of the RAQMON architecture is envisioned to be computationally resourceful. Only RRCs should implement the RAQMON MIB. The RAQMON Management Information Base (RAQMON MIB) extends the Remote Monitoring MIB [RFC2819] to accommodate the RAQMON Framework and exposes End-to-End Application QoS information to Network Management Applications. 2.1 RAQMON Data Source (RDS) A RAQMON Data Source (RDS) is a source of data for monitoring purposes. The RDS monitoring function is performed in real-time RMON WG Expires August 2004 [Page 5] INTERNET DRAFT RAQMON Framework February 2004 during each communication session. The RDS and RRC entities capture QoS attributes of such communication sessions and report them within a RAQMON "reporting session". A RDS is primarily responsible for abstracting IP end-devices and applications within the RAQMON Architecture. It gathers the parameters for a particular communication session and forwards them to the appropriate RAQMON Report Collector (RRC). Since it is envisioned that the RDS functionality will be realized by writing firmware/software running on potentially small, low-powered end- devices, the design of the RDS element is optimized towards that end. Like the implementations of routing and management protocols, an implementation of RDS in an end device will typically execute in the background, not in the data-forwarding path. It is further envisioned that a RDS residing in an IP end device is cable of gathering reports from multiple applications residing in that device and of sending out compound QoS reports associated with multiple communication sessions at a given moment. Examples are a conference bridge hosting several different conference calls or a two party video call consisting of audio/video sessions. In each case a RDS could send out one single RAQMON report that consists of multiple sub-reports associated with audio and video sessions or sub-reports for each conference call. RDSs use a PUSH mechanism to report QoS parameters. While the applications running on the RDS decide about the content of the PDU appropriate for an application context, a RAQMON Data Source (RDS) asynchronously sends out reports to RRC. The rate at which PDUs are sent from RDSs to RRCs is controlled by the applications' administrative domain policy. While this mechanism provides flexibility to gather a detailed end-to-end experience required by IT Managers and System Administrators, certain steps should be followed to operate RAQMON in congestion safe manner. Section 3 addresses steps required for congestion-safe operation. A RAQMON Data Source (RDS) reports QoS statistics for simplex flows. At a given instance, a report from RDS is logically viewed as a collection of QoS parameters associated with a communication session as perceived by the reporting RDS. If two IP Phone users for example Alice and John, are involved in a communication session, the end-to- end delay experienced by the IP Phone user Alice could be different than the one experienced by the IP Phone user John for a variety of reasons. Hence a report from Alice's IP Phone represents the QoS performance of that call as perceived by the RDS that resides in Alice's IP phone. 2.2 RAQMON Report Collector (RRC) RMON WG Expires August 2004 [Page 6] INTERNET DRAFT RAQMON Framework February 2004 A RAQMON Report Collector (RRC) receives RAQMON PDUs from multiple RDSs, and analyzes and stores the information in the RAQMON MIB. The RRC is envisioned to be computationally resourceful, providing a storage and aggregation point for a set of RDSs. Since RDSs can belong to separate administrative domains, the RAQMON Framework allows RDSs to report QoS parameters to separate RRCs. Vendors can develop a management application to correlate information residing in different RRCs across multiple administrative domains to represent one communication session. However such application level specification in RRC is beyond the scope of this memo. 2.3 RAQMON Protocol Data Unit (PDU) A RAQMON Protocol Data Unit (PDU) is a common data format understood by RDSs and RRCs. A RAQMON PDU does not transport application data but rather occupies the place of a payload specification at the application layer of the protocol stack. Either RTCP or SNMP is used to carry RAQMON PDU between RDSs and RRCs. So any transport layer protocol that supports RTCP and SNMP such as TCP, UDP, DCCP can be used to carry RAQMON PDUs. Though transmitted as one Protocol Data Unit, the RAQMON PDU is functionally divided into two different parts namely the Basic Part and the Application Specific Extensions required for vendor specific extensions. Both functional parts trail behind SMI Network Management Private Enterprise Codes and are currently maintained by IANA at http://www.iana.org/assignments/enterprise-numbers. The BASIC Part of the RAQMON PDU: The Basic part of the RAQMON PDU trails behind the SMI Network Management Private Enterprise Code 0 - indicating an IETF standard construct. The RAQMON PDU basic part offers an entry-type from a pre-defined list of QoS parameters defined in Section 5 and allows applications to fill in appropriate values for those parameters. Application developers also have the flexibility to make a RDS report built only of a sub-set of the parameters listed in Section 5. The Application Part of RAQMON PDU: Since it is difficult to structure a BASIC Part that meets the needs of all applications, RAQMON provides extension capabilities to convey application-, vendor-, device- etc. specific parameters for future use. Additional parameters can be defined within payload of the APP part of the PDU as Type Length Value (TLV) triplets or varbinds by the application developers or vendors. The Application part of the RAQMON PDU trails behind a vendor's SMI Network Management Private Enterprise Codes found in http://www.iana.org/assignments/enterprise-numbers. Such application specific extensions should be maintained and published by RMON WG Expires August 2004 [Page 7] INTERNET DRAFT RAQMON Framework February 2004 the application vendor. Though RDSs and RRCs are designed to be stateless for an entire reporting session, the framework would require an indication for the end of the reporting. For this purpose a RDS MUST send a RAQMON NULL PDU. A NULL PDU is a RAQMON PDU containing ALL NULL values (i.e. nothing to report) and a syntactical definition of NULL PDU specification is available in [RAQMON-PDU]. Though the RAQMON Framework expects PDUs to operate in lossy networks, retransmission is not included in the RAQMON framework, to keep the design simple. If retransmission is a necessity RAQMON MAY operate over transport protocols like TCP. In order to ensure that the RRCs know the state of reporting, the following measures SHOULD be taken to deal with the potential loss of NULL PDUs: - Lower level indications such as RTCP BYE packets from RDS to RRC to indicate the end of a reporting session. - Session time out mechanisms to assume end of reporting for RDSs that have been out of reporting for a reasonable duration of time. Such time out parameters SHOULD be configurable in vendor implementations, programmable at deployment. Further specification of the RAQMON PDUs can be found in [RAQMON- PDU]. 2.4 RDS/RRC Network Transport Protocol Interface The RAQMON PDUs rely on the underlying protocol(s) to provide transport functionalities and other attributes of a transport protocol. e.g. transport reliability, re-transmission, error correction, length indication, congestion safety, fragmentation/defragmentation etc. The maximum length of the RAQMON data packet is limited only by the underlying protocols. The memo [RAQMON-PDU] defines the structure of the RAQMON PDU and describes how the PDU is transported over existing application level protocols like the Real-Time Transport Control Protocol (RTCP) and the Simple Network Management Protocol (SNMP). Carrying RAQMON PDUs over existing protocols like RTCP or SNMP has the following advantages: 1. Lightweight - RDSs will be implemented on low powered embedded devices with limited device resources. 2. Scalable - since RRCs need to interact with a very large number RMON WG Expires August 2004 [Page 8] INTERNET DRAFT RAQMON Framework February 2004 of RDSs, scalability of the transport protocol is a requirement. 3. Congestion safety - as per [RFC2914] 4. Security - Since RAQMON statistics may carry sensitive system information requiring protection from unauthorized disclosure and modification in transit, a transport protocol that provides strong secure modes is a requirement - met by RTCP and SNMP. 5. NAT Friendly - Comply with [RFC3235], so that an RDS could communicate with an RRC through a Firewall/Network Address Translation device. Though RAQMON PDUs can be transported over RTCP as well as SNMP, it is not mandatory for RDSs to support both transport protocol interfaces. However, since RRCs are computationally resourceful, it is RECOMMENDED that RRCs support both RTCP and SNMP interfaces to accommodate RDSs running either protocol. Choice of an appropriate network transport protocol (i.e. TCP or UDP or DCCP) also depends upon the specific implementation as it fits the deployment need. Readers should note that if SNMP is used to carry RAQMON PDU, practical deployments may dictate UDP as the only viable choice. In the future, if RAQMON PDUs 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 contains 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 following sections describe the usage of RTCP and SNMP to carry RAQMON PDU: 2.4.1 Usage of RTCP to carry RAQMON PDUs The RAQMON Framework includes a unidirectional transmission of PDUs with RDS/RRC pairs. The protocol data units are mapped to an existing transport protocol such as the Real-Time Transport Control Protocol (RTCP). To accommodate RTCP as the RAQMON PDU Transport, the RRC-RTCP interface needs to minimally recognize RTCP APP reports as defined in [RFC3550]. + During a monitored communication session, the RDSs will send a RAQMON PDU to a target RRC as a payload of a RTCP APP Packet RMON WG Expires August 2004 [Page 9] INTERNET DRAFT RAQMON Framework February 2004 [RFRC3550]. The RAQMON PDU transport over RTCP constitutes a simple one-way send protocol. The transport protocol used to carry RAQMON PDUs would have effects on the overall operation and deployment of the RAQMON Framework. It should be noted that RAQMON is designed to operate over a lossy network and retransmission, error detection or recovery are not supported within the RAQMON framework. + Session termination SHOULD be indicated in RTCP by sending an RTCP BYE packet as defined in Section 2.3. + IANA Port XXXX has been reserved as a default port to carry RAQMON PDUs over RTCP - see Section 10 in [RAQMON-PDU]. 2.4.2 SNMP Notifications as the RDS/RRC Network Transport Protocol SNMP Notifications are used to transport RAQMON PDUs in the following manner: + RDSs embed the RAQMON PDU information in SNMP Notifications to report RAQMON information. The MIB used to define the mapping of the RAQMON PDU information to SNMP is defined in [RAQMON-PDU]. + 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. + RRCs MUST send an SNMP INFORM Response for each associated SNMP INFORM originated by the RDS, as defined in [RFC3416]. However sending out acknowledgements from RRCs to RDSs can create bottleneck as additional RDS load is created, specially when the RRCs will be receving many Inform PDUs from many RRCs. As an alternate, SNMP Traps could be used to avoid such ACKs; however that diminishes any possibility of using SNMP in a congestion-safe manner in practical deployments. Congestion safety related issues are discussed in section 3.0 of this memo. + The RDS may ignore the SNMP INFORM Responses. + The SNMP Notifications transport for RAQMON PDUs will use the standard UDP port 162 used for SNMP Notifications. Using SNMP INFORM PDUs for RAQMON has all the advantages offered by a well-known protocol like SNMP. Privacy and authentication issues related to RAQMON are "mostly" covered by SNMP framework. One of the drawbacks of using SNMP is the associated overhead SNMP puts on low- RMON WG Expires August 2004 [Page 10] INTERNET DRAFT RAQMON Framework February 2004 powered RDSs, for instance - BER encoding, SNMP INFORM Responses sent from RRC to RDS etc. As a result added flexibility of the proposed RAQMON Framework could be constrained in a real life deployment scenario depending on the use case. 2.5 Configuring RAQMON Data Sources In order to report statistics to RAQMON Report Collectors, RDSs will need to be configured with the following parameters: 1. The time interval between RAQMON PDUs. This parameter MUST be configured such that overflow of any RAQMON parameter within a PDU between consecutive transmissions is avoided. 2. The IP address and port of target RRC. A RDS can use one or more of the following mechanisms to gain access to configuration parameters: - RDS acts as a tftp client and downloads text scripts to read the parameters - RDS acts as a DHCP Client and gets RRC addressing information as a DHCP option - RDS acts as a DNS client and gets target collector information from a DNS Server - RDS acts as a LDAP Client and uses directory look-ups - RDS is manually configured using command line interface (CLI), Telephone User Interface (TUI) etc. Compliance to the RAQMON specification does not require usage of any specific configuration mechanisms mentioned above. It is left to the implementers to choose appropriate provisioning mechanisms for a system. 3. RAQMON Operation in Congestion-Safe Mode RAQMON PDUs can be transmitted over multiple transport protocols, including UDP, DCCP and TCP. The RAQMON Framework will be congestion safe, if a RAQMON PDU is transported over TCP. To ensure congestion safety clearly the best thing to do is to use a transport protocol like TCP or SCTP. If this is not feasible, it may be necessary to fall back on UDP. A RAQMON PDU from RDS to RRC either over RTCP or SNMP allows the use of UDP for transport, which might lead to network congestion under heavy network load. One solution to the congestion awareness problem could have been to deprecate UDP entirely for RAQMON. Though RAQMON PDU can be transported over TCP, either SNMP or RTCP over TCP are not commonly practiced in practical deployments. Moreover there are legitimate RMON WG Expires August 2004 [Page 11] INTERNET DRAFT RAQMON Framework February 2004 places where UDP appears to be quite useful such as tiny mobile phones, pagers, various other hand held computing devices, RAQMON Report Collectors where extremely high-volume RDSs connect over dedicated networks, etc. The use of UDP inherently increases the risks of network congestion problems, as UDP itself does not define congestion prevention, avoidance, detection, or correction mechanisms. The fundamental problem with UDP is that it provides no feedback mechanism to allow a sender to pace its transmissions against the real performance of the network. While this tends to have no significant effect on extremely low-volume sender-receiver pairs, the impact of high-volume relationships on the network can be severe. This problem could be further aggravated by large RAQMON PDU fragmented at the UDP level. Transport protocols such as DCCP can also be used as underlying RAQMON PDU transport, which provides flexibility of UDP style datagram transmission with congestion control. It should be noted that the congestion problem is not just between RDS and RRC pairs, but whenever there is a high fan-in ratio, congestion would occur. e.g. many RDSs reporting to a RRC. Within the RAQMON Framework using UDP as a transport congestion safety can be achieved in following ways: 1. Constant Transmission Rate: In a well-managed network a constant transmission rate policy (e.g. 1 RAQMON PDU per device every N seconds) will ensure congestion safety as devices are introduced into the network in a controlled manner. For example, in an Enterprise Network, IP Phones are added in a controlled manner and a constant transmission rate policy can be sufficient to ensure congestion safe operation. As a worst-case scenario, if the RDSs enforce an administrative policy where the maximum PDU transmission rate is no more 1 RAQMON PDU every 2 minutes, a UDP based implementation can be as congestion safe as a TCP based implementation. Such policies can be enforced while configuring a RDS. 2. Retransmission timers with back offs: This approach requires that a request be sent at the application level, then there is a wait for some sort of response indicating that the request was received before sending anything else. This produces an effect described by some as "ping-ponging" -- traffic bounces back and forth between two nodes like a ping-pong ball in a match. Since there's only one ball in play between any two players at any given time, most of the potential for congestion cascades is eliminated. For example if RAQMON PDU is transported using SNMP INFORM PDUs over UDP, a SNMP response from the RRC SHOULD be processed by the RDS to implement this mechanism. This pacing or serialization approach has the side-effect of RMON WG Expires August 2004 [Page 12] INTERNET DRAFT RAQMON Framework February 2004 significantly reducing the maximum throughput, as transmission occurs in only one direction at a time and there is at least a 2xRTT delay between transmissions. More sophisticated algorithms such as those in TCP and SCTP have been developed to address this, and it would be inappropriate to duplicate that work at the application level. Consequently, if greater efficiency is required than that provided by this simple approach, implementers SHOULD use TCP, SCTP, or another such protocol. But if one absolutely must use UDP, this approach works. It has been also used in other application scenarios like SIP over UDP. Retransmission timers with back offs will not be useful if RAQMON PDUs are transported over RTCP/UDP; RRCs do not provide any acknowledgement that RDS can rely on. 3. By restricting transmission to MTU Size: A RDS may be faced with a request to deliver a large message using UDP as a transport. Fragmentation of such messages is problematic in several ways. Loss of any fragment requires time-out and retransmission of the message. The fragments are commonly transmitted out of the interface at local interface (usually LAN) rates, without awareness of the intervening network conditions. For these reasons, it is generally considered a bad practice to send large PDUs over UDP. If the MTU size is known, as an implementation, a RDS should not allow an application to send more information by limiting the size of transmissions over UDP to reduce the effects of fragmentation. As an alternate, a RDS MAY also send parameters to RRC over multiple RAQMON PDUs but identify them as the same RAQMON reporting session with exactly the same NTP time stamp. While the actual MTU of a link may not be known, common practice seems to indicate that the RDS local interface MTU is likely to be a reasonable "approximation". Where the actual path MTU is known, that value SHOULD be used instead. 4. Irrespective of choice of transport protocol, it is also RECOMMENDED that no more than 10% network bandwidth be used for RDS/RRC reporting. More frequent reports from an RDS to RRC would imply requirements for higher network bandwidth usage. 4. 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 algorithms are left to 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 RMON WG Expires August 2004 [Page 13] INTERNET DRAFT RAQMON Framework February 2004 mandate a particular methodology - it is open to any methodology that meets the minimum requirements. Conformance to this specification requires that the collected data match the semantics described herein. However it is recommended that vendors use IETF defined and ITU specified methodologies to measure parameters when possible. 5. A Simple list of Metrics pre-defined in the BASIC PDU The BASIC part of the RAQMON PDU provides a list of pre-defined parameters frequently used by the applications to indicate end-to-end application Quality of Service. This section defines a set of simple metrics to be contained in the basic part of the RAQMON PDU through reference to existing IETF, ITU and other standards organizations' documents. Appropriate IETF or ITU references are included in the metrics definitions. As mentioned earlier, the RAQMON PDU also contains an application specific part where application and vendor specific information not included in basic part, can be added as Name Value pairs, or varbind list. Such extensions should be managed by the vendors independently and published for wider interoperability. For example one such extension can be derived out of subset of RTCP extended reports [RFC3611] to further extend the voice "media" related information already provided in the BASIC part of the RAQMON PDU. Applications are not required to report all the parameters mentioned in the section but should rather have the flexibility to report a subset of these parameters as appropriate for an application context. The [RAQMON-PDU] memo further identifies the parameters that RDSs are required to include in all PDUs for compliance as well as application optional parameters that that RDSs report as needed. The definitions presented here are meant to provide guidance to implementers, and IETF metrics definitions are reference for each of the specific metrics. Application developers should choose the metrics specific to their application needs. Syntactical representations of the parameters identified here, are standardized in the [RAQMON-PDU] specification. 5.1 Data Source Address (DA) The Data Source Address (DA) is the address of the data source. This could be either a globally unique IPv4 or IPv6 address, or a privately allocated address as defined in [RFC1597]. It is expected that a Data Source Address (DA) would remain constant within a communication session. RMON WG Expires August 2004 [Page 14] INTERNET DRAFT RAQMON Framework February 2004 5.2 Receiver Source Address (RA) The Receiver Source Address (RA) takes the same form as the Data Source Address (DA) but represents the Receiver's Source Address. In a communication session the reporting RDSs SHOULD fill in the other party's address as a Receiver Source Address. Like the Data Source Address, this could be either a globally unique IPv4 or IPv6 address, or a privately allocated address as defined in [RFC1597]. 5.3 Data Source Name (DN) The DN item could be of various formats as needed by the application. A few instances of DN could include but are not restricted to * "user@host", or "host" if a user name is not available as on single-user systems. For both formats, "host" is 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.avaya.com" or "big-guy@135.8.45.178" for a multi-user system. On a system with no user name, an example would be "ip-phone4630.bigcompany.com". It is RECOMMENDED that the standard host's numeric address not be reported via the DN parameter, as the Data Source Address (DA) parameter is used for that purpose. * Another instance of a DN could be a valid E.164 phone number, a SIP URI or any other form of telephone or pager number. It is recommended that the phone number SHOULD be formatted with the plus sign replacing the international access code. 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. 5.4 Receiver Name (RN) The Receiver Name (RN) takes the same form as Data Source Name (DN) but represents the Receiver's name. In a communication session applications should fill in the other party's name that they are communicating with as a Receiver Name. 5.5 Data Source Device Port Used This parameter indicates the source port used by the application for a particular session or sub-session in communication. Examples of ports include TCP Ports, or UDP Ports used by communication application protocols such as SIP, SIMPLE, H.323, RTP, HTTP, etc. RMON WG Expires August 2004 [Page 15] INTERNET DRAFT RAQMON Framework February 2004 5.6 Receiver Device Port Used This parameter indicates the receiver port used by the application for a particular session or sub-session. Examples of ports include TCP Ports, or UDP Ports used by communication application protocols such as SIP, SIMPLE, H.323, RTP, HTTP, etc. 5.7 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]. 5.8 Session Setup Delay The 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 since the last DTMF button pushed to the first ring-back tone that indicates that the far end is ringing. Another example would be the Session Setup Delay of a SIP call, which is measured as the elapsed time between an INVITE generated from a User Agent and the reception of a 200 OK. However as these definitions are very specific to the type of system used and the implementation details of such systems, no claim is made on the appropriateness of the definition presented here; for a particular application need it is left to the implementers to define as appropriate. 5.9 Session Duration This parameter describes how long a session or a sub-session lasted. This parameter is application context sensitive. For example a VoIP Call Session Duration can be measured as the elapsed time between the establishment of the call pick up to call termination. 5.10 Session Setup Status This parameter is intended to report communication status of a session. This field is used to describe appropriate communication session states e.g. Call Progressing, Call Established successfully, "trying", "ringing", "re-trying", RSVP reservation failed, and various other status. This information could be used by network management systems to calculate parameters such as call success rate, call failure rate etc., or a debugging tool that captures the status of a call-setup as soon as a call is established. RMON WG Expires August 2004 [Page 16] INTERNET DRAFT RAQMON Framework February 2004 5.11 Round Trip End-to-End Delay Round Trip End-to-End Delay [RFC 3550], [RFC2681], [RFC2679] 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 such as 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, and coding/decoding delays be added to network transport delay to report end-to-end delay. The End-to-End delay of underlying transport network can be measured using various methodologies as described in [RFC2681], [RFC2679], [RFC 3550] depending on the application needs and left up to the implementers to select the appropriate IETF and ITU methodologies to measure end-to-end Delays appropriate for a specific application. 5.12 One Way End-to-End Delay The One Way End-to-End Delay [RFC2679] allows applications to reflect the end-to-end delay as experienced by the source application to reach the destination application. One Way Delay measurements identified by the IPPM Working Group [RFC2679] could be used to measure one way end-to-end delay. The need for such a metrics is derived from the fact that the path from a source to a destination may be different than the path from the destination back to the source ("asymmetric paths"), such that different sequences of routers are used for the forward and reverse paths. Therefore round-trip measurements actually measure the performance of two distinct paths together. Measuring each path independently highlights the performance difference between the two paths that may traverse different Internet service providers, and even radically different types of networks (for example, research versus commodity networks, or ATM versus Packet-over-SONET). Even when the two paths are symmetric, they may have radically different performance characteristics due to asymmetric queuing. Performance of an application may depend mostly on the performance in one direction. For example, a file transfer using TCP may depend more on the performance in the direction that data flows, rather than the direction in which acknowledgements travel. RMON WG Expires August 2004 [Page 17] INTERNET DRAFT RAQMON Framework February 2004 In quality-of-service (QoS) enabled networks, provisioning in one direction may be radically different than provisioning in the reverse direction, and thus the QoS guarantees differ. Measuring the paths independently allows the verification of both guarantees. It is outside the scope of this document to say precisely which applications would use one way end-to-end delay. One way end-to-end delay is expressed in the same units as round trip end-to-end Delay. 5.13 Jitter The variation in packet delay is called "jitter" [RFC 3393]. The definition of jitter is context sensitive and measurement specific. One important use of jitter is the sizing of play-out buffers for applications requiring the regular delivery of packets (for example, voice or video play-out). Other uses of a delay variation metric are, for example, to determine the dynamics of queues within a network (or router) where the changes in delay variation can be linked to changes in the queue length process at a given link or a combination of links. [RFC 3393] provides guidance to several absolute jitter parameters. An alternate, but related, way of computing an estimate of jitter is given in RFC 3550. The selection function there is implicitly consecutive packet pairs, and the "jitter estimate" is computed by taking the absolute values of the ipdv sequence (as defined in RFC 3393) and applying an exponential filter with parameter 1/16 to generate the estimate (i.e., j_new = 15/16* j_old + 1/16*j_new). Inter-arrival jitter provides a short-term measure of congestion [RFC 3550]. The jitter measure indicates congestion before it leads to packet loss. 5.14 Total Number of Application Packets Received The total number of application payload packets received by the RDS as part of this session, since the last RAQMON PDU was sent up until the time this RAQMON PDU was generated. This parameter represents a very simple incremental counter that counts the number of "application" packets that an RDS has received. Since this count is a snapshot in time, depending on application type, it also varies based on the application states e.g. a RDS within an application session will report number of application packet that were sent out during signaling setup, media packets received, session termination etc. For example, during Voice over IP or Video over IP session this RMON WG Expires August 2004 [Page 18] INTERNET DRAFT RAQMON Framework February 2004 counter represents the number of signaling session related packets that have been received which will be derived from the relevant application signaling protocol stack such as SIP or H.323, SIMPLE and various other signaling protocols used by the application to establish the communication session. However during a period when media is established between the communicating entities, this counter will be indicative of the number of RTP Frames that have been sent out to the communicating party since last PDU was sent out. The methodology described within RTCP SR/RR reports [RFC 3550] to count RTP frames can be one of the ways to measure media related application packet received, applicable for the scenarios described above. 5.15 Total Number of Application Packets Sent The total number of payload packets sent by the RDS as part of this session since the last RAQMON PDU was sent up until the time this RAQMON PDU was generated. Similar to total number of application packets parameter in section 5.14, this count is a snapshot in time. Depending on application type, the counter also varies based on various application states i.e. signaling setup, media establishment, session termination states etc. 5.16 Total number of Application Octets Received The total number of payload octets received in packets by the RDS as part of this session since the last RAQMON PDU was sent up until the time this RAQMON packet was generated. This metrics could be measured in different ways, including the methodology described by [RFC 3550]. 5.17 Total number of Application Octets Sent The total number of payload octets received in packets by the RDS as part of this session since the last RAQMON PDU was sent up until the time this RAQMON packet was generated. Similar to total number of octets received. This metrics could be measured in different ways, including the methodology described by [RFC 3550]. 5.18 Cumulative Application Packet Loss Packet loss tracks persistent congestion while jitter measures tracks transient congestion. Packet loss metric SHOULD indicate loss associated to 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], RMON WG Expires August 2004 [Page 19] INTERNET DRAFT RAQMON Framework February 2004 [RFC 3550] and local device level packet losses should to be captured by the local device specific algorithms. 5.19 Packet loss in Fraction Packet loss in Fraction represents packet loss as defined above but expressed in percentage. 5.20 Source Payload Type The source payload type defines payload formats (e.g. media encodings) as sent by the data source. e.g. ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII etc. This document follows the definition of Payload Type (PT) as in [RFC1890]. To give an example, if an application ought to indicate that the Source Payload Type used for a session were PCMA, source payload field for the respective session ought to be 8. 5.21 Destination Payload Type Destination payload type defines payload formats (e.g. media encodings) as sent by the other communicating party to the source. e.g. ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII etc. This document follows the definition of payload type (PT) as in [RFC1890]. To give an example, if an application ought to indicate that the source payload type used for a session were PCMA, Source Payload Field for the respective session ought to be 8. 5.22 Source Layer 2 Priority Many devices use Layer 2 technologies to prioritize certain types 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 RDS to prioritize these packets in the Local Area Networks environment. 5.23 Source TOS/DSCP Value Various Layer 3 technologies are in place to prioritize certain types 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] are using RMON WG Expires August 2004 [Page 20] INTERNET DRAFT RAQMON Framework February 2004 the TOS octet in IPv4, while the Traffic class Octet is used to prioritize traffic in Ipv6. Source Layer 3 RAQMON field indicates appropriate Layer 3 values used by the Data Source to prioritize these packets. 5.24 Destination Layer 2 Priority The Destination Layer 2 RAQMON indicates Layer 2 values used by the communication receiver to prioritize these packets while sending traffic to the data source in the Local Area Networks environment. Like Source Layer 2 Priority, Destination Layer 2 Priority could indicate if the destination has used any Layer 2 technologies like IEEE 802.1p/Q or priority queuing etc. 5.25 Destination TOS/DSCP Value The Destination Layer 3 RAQMON field indicates appropriate Layer 3 values used by the Data Receiver to prioritize these packets received by the source. Similar to Source Layer 3 Priority, Destination Layer 3 Priority indicates if destination has used any Layer 3 technologies like IP Precedence [RFC791], Type Of Service (TOS) [RFC1349], [RFC1812] or more recent technologies like Differentiated Service [RFC2474], [RFC2475]. 5.26 CPU Utilization in Fraction This parameter captures the IP Device CPU usage rate to indicate the current state of the local IP Device resource, which may have very critical implications for QoS of an end device. e.g. x % CPU busy averaged over session duration. 5.27 Memory Utilization in Fraction This parameter captures the IP Device Memory usage rate to indicate current state of the local IP Device resource, which may have very critical implications for QoS of an end device. e.g. y % memory utilized over session duration. 5.28 Application Name/version The Application Name/version parameter gives the name and possibly version of the application associated with that session or sub- session, e.g., "XYZ VoIP Agent 1.2". This information may be useful for scenarios where the end device is running multiple applications with various priorities and could be very handy for debugging purposes. 6. Report Aggregation and Statistical Data processing RMON WG Expires August 2004 [Page 21] INTERNET DRAFT RAQMON Framework February 2004 Within the RAQMON Framework, since RRCs are computationally resourceful, various aggregation functions are performed by the RRCs while RDSs are not burdened by statistical data processing such as computation of min/max/average/standard deviation etc. The RAQMON MIB is designed to provide minimal aggregations of various RAQMON parameters defined in section 5.0. The RAQMON MIB is designed not to provide extensive aggregations like the APM MIB [29] or the TPM MIB [30] and one should use APM and TPM MIBs to aggregate parameters based on protocols (e.g. performance of HTTP, RTP) or based on applications (e.g. performance of VoIP, Video Applications). In the RAQMON MIB, aggregation can be performed only on specific RAQMON metrics parameters. Aggregation always results in statistics Mean/Min/Max values. The following aggregation definitions are used in this document: Mean: Mean is defined as the statistical average of a metric over the duration of a communication session. For example if an RDS reported End-to-End delay metric N times within a communication session, 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. 7. Keeping Historical Data and Storage It is evident from the document that the RAQMON MIB data need to be managed to optimize storage space. The large 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 the following ways: 1. Store data in the MIB only at the end of a communication session RMON WG Expires August 2004 [Page 22] INTERNET DRAFT RAQMON Framework February 2004 (i.e. a NULL PDU or an RTCP BYE 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 a few scalars will be used to store a metric. 2. A time-based algorithm that aggregates 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 an 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 the usage of these policies is left to the application developer's discretion. 8. Normative References [RFC3416] Presuhn, R., "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 61, RFC 3416, December 2002. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. [RFC 3550] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFRC 3550, July 2003. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 9. Informative References [RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control" RFC 1890, January 1996. [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, March 1992. [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. RMON WG Expires August 2004 [Page 23] INTERNET DRAFT RAQMON Framework February 2004 [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", RFC 1597, March 1994. [RFC2679] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999 [RFC2680] G. Almes, S.Kalidindi and M.Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999 [RFC 3393] C.Demichelis and P.Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002 [RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay Metric for IPPM", RFC 2681, September 1999 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000 [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 RMON WG Expires August 2004 [Page 24] INTERNET DRAFT RAQMON Framework February 2004 [RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and W.Weiss, "An Architecture for Differentiated Services", RFC2475, December 1998 [RFC3235] D. Senie, "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC3235, January 2002 [RFC3611] T. Friedman, R. Caceres and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", November 2003 [RAQMON-PDU] A. Siddiqui, D.Romascanu, and E. Golovinsky, "Protocol Data Units for Real-time Application Quality of Service Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon-pdu-05.txt, February 2003 [RAQMON-MIB] A. Siddiqui, D.Romascanu, E. Golovinsky, and R. Smith, "Real-time Application Quality of Service Monitoring (RAQMON) MIB", Internet-Draft, draft-ietf-rmonmib-raqmon-mib-03.txt, November 2003 [SRTCP] Bauer, McGrew, Oran, Blom, Carrara, Naslund, Norrman, "Secure Real Time Transport Protocol", Internet Draft, draft-ietf-avt-srtp-06.txt, April 2003 10. 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. 11. Security Considerations RMON WG Expires August 2004 [Page 25] INTERNET DRAFT RAQMON Framework February 2004 11.1 The RAQMON Threat Model The vulnerabilities associated with the RAQMON Framework are a combination of those associated with the underlying layers up to the transport layer and possible exploits of RAQMON payload. A discussion of RAQMON specific threat model is discussed within this memo. A series of security considerations are also recommended in this memo as well as in other RAQMON memos when appropriate. Possible exploits of RAQMON payloads can fall within the class of 1. Unauthorized examination of sensitive information in the payload (in transit) 2. Unauthorized modification of payload contents (in transit) leading to: a. Redirection of one RAQMON reporting session to another destined to the same RRC b. Mismapping of RAQMON sessions c. Various forms of session-level DoS attacks d. DoS by way of incorrect and modified RAQMON parameter values and statistics e. Invalid timestamps 3. Malforming payload - leading to exploit of potential implementation weaknesses to compromise RRC. 4. Unauthorized disclosure of sensitive data (in application PDU's) leading to threat to confidentiality Since no assumptions can be made about the transport media, threats based on unauthorized disclosure and modification of payload and headers will have to be assumed. 11.2 The RAQMON Security Requirements & Assumptions In order to preserve the sanity and integrity of the RAQMON PDU against such classes of threats RAQMON model must provide for cryptographically strong security services. It is, therefore, 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 RMON WG Expires August 2004 [Page 26] INTERNET DRAFT RAQMON Framework February 2004 PDU was originated by which ever RDS claims to have sent it. 2. Privacy - RAQMON information includes identification of the parties participating in a communication session. RAQMON framework should be able to provide protection from eavesdropping, 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 etc. 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 should be stored in the RDS and will be reported only after such duration. 4. NAT and Firewall Friendly Design - Presence of 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 provide IP addresses in the RAQMON PDU. Another way to avoid this problem is by supporting NAT-aware RAQMON Application Layer Gateways (ALGs) to translate IP addresses in RAQMON PDUs. However, this will not be possible when RAQMON PDUs are encrypted end-to-end. 11.3 RAQMON Security Model The RAQMON architecture provides for using a wide range of transport protocols most of which also carry an associable secure mode of operation. There are advantages to relying on the security provided at the transport protocol layer. 1. Besides affording transport protocol level security, the payload is protected by available end-to-end authentication, confidentiality, message integrity and replay protection services. 2. Good cryptographic security protocol always has an associated key management protocol. Use of transport protocol security relies on its key management. 3. When transport protocol security is already enabled between RDS & RRC, additional encryption and message authentication is avoided at application level. RMON WG Expires August 2004 [Page 27] INTERNET DRAFT RAQMON Framework February 2004 However, there are also shortcomings to be noted in relying on transport protocol security. 1. When session-level isolation is required of different RAQMON sessions between the same RDS-RRC pair it will be required to open separate transport protocol instances. Such cases, however, may be rare. 2. When security services are not self-contained within the RAQMON framework, the absence of transport or lower protocol security implies absence of RAQMON security. 3. When full transport protocol implementations are unavailable in either RRC or RDS, such as when using SNMP or RTCP, secure mode implementations such as SNMPv3 or SRTCP will be unavailable. 11.4 Use of SNMP as the transport protocol RAQMON uses SNMP to transport RAQMON PDUs over SNMP, and defines an SNMP MIB to provide the PDU encoding. Another MIB module is defined to retrieve RAQMON information from the collectors. There are a number of management objects defined in these MIB modules with a MAX- ACCESS clause of read-write. 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. The other RAQMON documents [RAQMON-PDU, RAQMON-MIB] define in their Security Considerations sections the objects whose setting to incorrect values can result in improper operation, excessive number of notifications, or may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt their values when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). RMON WG Expires August 2004 [Page 28] INTERNET DRAFT RAQMON Framework February 2004 Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only of those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 11.5 Use of RTCP as Transport In using RTCP as a transport, it is customary for RDSs as endpoints to have RTCP protocol implementation with their communicating peers. Thus, e.g., an IP phone endpoint may be communicating to its peer or media gateway over RTCP. The RTCP protocol security is defined in Secure RTCP [SRTCP], a draft-in-progress. When the communicating parties are the RDS & RRC as well, the RAQMON stream will work within the existing framework of [SRTCP]. It must be noted, however, that the two SRTCP sessions will need to be different and be using separate sets of keys and re-key independently. However, they may share the same master key. However, in case the target RRC or RDS are different than either party, the RDS and/or RRC will need to implement SRTCP in order to secure the protocol. 12. Acknowledgements The authors would like to thank Mahalingam Mani, Steven Waldbusser, Alan Clark, Robert Cole, and Itai Zilbershtein for interesting discussions and various direct contributions in this problem space. 13. Authors' Addresses Anwar A. Siddiqui Avaya Labs 307 Middletown Lincroft Road Lincroft, New Jersey 07738 USA Tel: +1 732 852-3200 E-mail: anwars@avaya.com Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Tel: +972-3-645-8414 RMON WG Expires August 2004 [Page 29] INTERNET DRAFT RAQMON Framework February 2004 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 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. RMON WG Expires August 2004 [Page 30]