Internet Draft Anwar Siddiqui Avaya Inc. Dan Romascanu Avaya Inc. Eugene Golovinsky BMC Software 8 September 2003 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 (2003). All Rights Reserved. Abstract There is a need to extend the RMON framework 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 Framework 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 RMON Framework via SNMP. Distribution of this memo is unlimited. Table of Contents RMON WG Expires March 2004 [Page 1] INTERNET DRAFT RAQMON Framework September 2003 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 13 6 Report Aggregation and Statistical Data processing 20 7 Keeping Historical Data and Storage 21 8 Normative References 22 9 Informative References 22 10 Intellectual Property 24 11 Security Considerations 24 12 Acknowledgements 28 13 Authors' Addresses 28 A Full Copyright Statement 29 1. Introduction With the growth of Internet and advancement of 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 framework [RFC2819]. This memo extends the RMON Framework 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 RMON Framework via SNMP. 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 RMON Framework 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. User experience of an application running on an IP end device depends upon the type of application a 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 applications level transactions and available network and host RMON WG Expires March 2004 [Page 2] INTERNET DRAFT RAQMON Framework September 2003 resources. For example, end-to-end user experience of a Voice over IP (VoIP) call depends on total time required to set up the call as much as media related performance such as end-to-end Delay, Jitter, Packet Loss, the type of codec used in a call. Network protocols like DiffServ, RSVP, IEEE 802.1p/Q tags 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. An 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. Real-Time Application QoS Monitoring (RAQMON) Framework offers a mechanism to report end-to-end QoS experience appropriate for a specific application context by providing mechanisms to report a sub set of metrics from a pre- defined list metrics. In order to facilitate 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 parameter 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 view to RMON Framework. 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 RMON MIB Modules for use with network management protocols in the Internet community. This memo provides RAQMON functional architecture, RAQMON entity definitions, behavior of various RAQMON entities and definition of various parameters carried within RAQMON PDU. RMON WG Expires March 2004 [Page 3] INTERNET DRAFT RAQMON Framework September 2003 The RAQMON QoS PDU [RAQMON-PDU] memo provides definitions of syntactical PDU structure and use case scenarios of transmission of such PDU over Real-Time Transport Control Protocol (RTCP) and Simple Network Management Protocol (SNMP). The RAQMON MIB [RAQMON-MIB] memo describes the Management Information Base (MIB) for use with network management protocol in the Internet community. The document proposes an extension to the Remote Monitoring MIB [RFC2819] to accommodate RAQMON solution. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. RAQMON Functional Architecture RAQMON Framework extends the architecture created in the RMON MIB [RFC2819] by providing application performance 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 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 | | |+--------------------+| |+--------------------+ | | | | | | | | | | | | +------------------+ | | | +----------------------+ | |RAQMON Data Source|<-+ | | | | (RDS) |<---+ | | +------------------+ | +-----------|---------------+ RMON WG Expires March 2004 [Page 4] INTERNET DRAFT RAQMON Framework September 2003 | (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 interface (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 to Network Management Applications. 2.1 RAQMON Data Source (RDS) A RAQMON Data Source (RDS) is a source of data for monitoring purposes. RDS monitoring function is performed in real-time during each communication session. RDS and RRC entities capture QoS attributes of such communication sessions and report such within a RAQMON "reporting session". RMON WG Expires March 2004 [Page 5] INTERNET DRAFT RAQMON Framework September 2003 A RDS is primarily responsible for abstracting IP end-devices and applications within 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 an RDS residing in an IP end device is cable of gathering report from multiple applications residing in that device and sending out compound QoS reports associated with multiple communication sessions at a given moment. For example a conference bridge hosting few 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 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 RDS to RRC 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 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, end-to-end delay experienced by IP Phone user Alice could be different than 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) 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. RMON WG Expires March 2004 [Page 6] INTERNET DRAFT RAQMON Framework September 2003 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 commonly 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. Either TCP or UDP could be used as a transport layer protocol within the protocol stack. 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 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 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 RMON WG Expires March 2004 [Page 7] INTERNET DRAFT RAQMON Framework September 2003 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, 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 end or 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 RAQMON PDUs can be found in [RAQMON-PDU]. 2.4 RDS/RRC Network Transport Protocol Interface 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 Real-Time Transport Control Protocol (RTCP) and Simple Network Management Protocol (SNMP). Carrying RAQMON PDUs over existing protocols like RTCP or SNMP has 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 of RDSs, scalability of 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 RMON WG Expires March 2004 [Page 8] INTERNET DRAFT RAQMON Framework September 2003 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 PDU can be transported over RTCP as well as SNMP, it is not mandatory for RDSs to support both transport protocols 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) 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 deployment 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 section describes the usage of RTCP and SNMP to carry RAQMON PDU: 2.4.1 Usage of RTCP to carry RAQMON PDUs The RAQMON Framework is comprised of a unidirectional exchange of PDUs between The RDS/RRC pair. The protocol data units are mapped to an existing transport protocol such as Real-Time Transport Control Protocol (RTCP). To accommodate RTCP as RAQMON PDU Transport, the RRC-RTCP interface needs to minimally recognize RTCP APP reports as defined in RFC 1889. + During a monitored communication session, the RDSs will send a RAQMON PDU to a target RRC as a payload to RTCP APP Packet [RFC 1889]. 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 RAQMON Framework. It should be noted that RAQMON is designed to operate over a lossy RMON WG Expires March 2004 [Page 9] INTERNET DRAFT RAQMON Framework September 2003 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 PDU over RTCP - see Section 10 in [RAQMON-PDU]. 2.4.2 SNMP Notifications as 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- 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 RMON WG Expires March 2004 [Page 10] INTERNET DRAFT RAQMON Framework September 2003 In order to report statistics to RAQMON Report Collector, RDSs will need to be configured with the following parameters: 1. The time interval between RAQMON PDUs 2. The RRC 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 address 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 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 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 problem might be to deprecate UDP entirely for RAQMON. Though RAQMON PDU over RTCP can be transported over TCP, SNMP over TCP is not commonly practiced in practical deployment. Moreover there are legitimate 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 RMON WG Expires March 2004 [Page 11] INTERNET DRAFT RAQMON Framework September 2003 relationships on the network can be severe. This problem could be further aggravated by large RAQMON PDU fragmented at the UDP level. It should be noted that the congestion problem is not just between RDS and RRC pair, but whenever there is high fan-in ratio, congestion would occur. e.g. many RDSs reporting to a RRC. RAQMON Framework using UDP as a transport can attain congestion safety 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 Maximum PDU Transmission rate is no more 1 RAQMON PDU every 2 minutes, a UDP based implementation can be as congestion safe as 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 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 PDU is transported over RTCP/UDP; RRC does not provide any acknowledgement that RDS can rely on. RMON WG Expires March 2004 [Page 12] INTERNET DRAFT RAQMON Framework September 2003 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 PDU 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 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. 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 RMON WG Expires March 2004 [Page 13] INTERNET DRAFT RAQMON Framework September 2003 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 extension should be managed by the vendors independently and published for wider interoperability. Applications are not required to report all of the parameters mentioned in the section but rather have the flexibility to report a subset of these parameters 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 chose 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. These could be either globally unique IPv4 or IPv6 addresses, or privately allocated addresses as defined in [RFC1597]. It is expected that a Data Source Address (DA) would remain constant within a communication session. 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 addresses, 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 RMON WG Expires March 2004 [Page 14] INTERNET DRAFT RAQMON Framework September 2003 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 DN parameter, as 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. For example, "+88 02 123 45678" for a number in Bangladesh. It is expected that a Data Source Name (DN) will remain constant within a communication session. 5.4 Receiver Name (RN) 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 Ports 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. 5.6 Receiver Device Ports 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 RMON WG Expires March 2004 [Page 15] INTERNET DRAFT RAQMON Framework September 2003 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 as 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. 5.11 Round Trip End-to-End Delay Round Trip End-to-End Delay [RFC1889], [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. RMON WG Expires March 2004 [Page 16] INTERNET DRAFT RAQMON Framework September 2003 The 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 up to the implementers to select 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 could be used [RFC2679] 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. 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 Inter-Arrival Jitter Inter-arrival jitter 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 networks can be measured using various methodologies, left to the implementers RMON WG Expires March 2004 [Page 17] INTERNET DRAFT RAQMON Framework September 2003 based on their application needs. VoIP Systems can readily acquire inter-arrival jitter calculations from RTCP measurements as described in [RFC1889]. 5.14 Total Number of Application Packets Received The total number of payload packets received by the RDS as part of this session, since starting transmission up until the time this RAQMON PDU was generated. This metrics could be measured in different ways, including the methodology described by [RFC1889]. 5.15 Total Number of Application Packets Sent The total number of payload packets sent by the RDS as part of this session since starting transmission up until the time this RAQMON PDU was generated. Similar to total number of packets received. This metrics could be measured in different ways, including the methodology described by [RFC1889]. 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 beginning transmission up until the time this RAQMON packet was generated. This metrics could be measured in different ways, including the methodology described by [RFC1889]. 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 beginning transmission 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 [RFC1889]. 5.18 Cumulative Application Packet Loss Packet loss tracks persistent congestion while jitter measures tracks transient congestion. Since an inter-arrival 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 RMON WG Expires March 2004 [Page 18] INTERNET DRAFT RAQMON Framework September 2003 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 the TOS octet in IPv4, while the Traffic class Octet is used to RMON WG Expires March 2004 [Page 19] INTERNET DRAFT RAQMON Framework September 2003 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 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 March 2004 [Page 20] INTERNET DRAFT RAQMON Framework September 2003 Within 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 min/max/average/standard deviation etc. The RAQMON MIB is designed to provide minimal aggregations of various RAQMON parameters defined in section 5.0. RAQMON MIB is designed not to provide extensive aggregations like APM MIB [29] or 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 application (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 March 2004 [Page 21] INTERNET DRAFT RAQMON Framework September 2003 (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 usage of these policies 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. [RFC1889] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 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. [RFC1035] Mockapetris, P., "Domain Names - Implementation and RMON WG Expires March 2004 [Page 22] INTERNET DRAFT RAQMON Framework September 2003 Specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", RFC 1597, March 1994. [RFC2679] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999 [RFC2680] G. Almes, S.Kalidindi and M.Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999 [RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay Metric for IPPM", RFC 2681, September 1999 [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 [RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and W.Weiss, "An Architecture for Differentiated Services" RFC2475, December 1998 RMON WG Expires March 2004 [Page 23] INTERNET DRAFT RAQMON Framework September 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-03.txt, September 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-02.txt, September 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 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 RMON WG Expires March 2004 [Page 24] INTERNET DRAFT RAQMON Framework September 2003 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 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 - RMON WG Expires March 2004 [Page 25] INTERNET DRAFT RAQMON Framework September 2003 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 IPaddresses in RAQMON PDUs. However, when RAQMON PDU's are encrypted end-to-end that will not be possible. 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. 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. RMON WG Expires March 2004 [Page 26] INTERNET DRAFT RAQMON Framework September 2003 2. When security services are not self-contained within 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). 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. RMON WG Expires March 2004 [Page 27] INTERNET DRAFT RAQMON Framework September 2003 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 Inc. Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel Tel: +972-3-645-8414 Email: dromasca@avaya.com Eugene Golovinsky BMC Software Inc. 2101 CityWest Blvd. Houston, Texas 77042 USA Tel: +1 713 918-1816 RMON WG Expires March 2004 [Page 28] INTERNET DRAFT RAQMON Framework September 2003 Email: eugene_golovinsky@bmc.com A. Full Copyright Statement This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. RMON WG Expires March 2004 [Page 29]