Internet Draft Anwar Siddiqui Avaya Inc. Dan Romascanu Avaya Inc. Eugene Golovinsky BMC Software 9 June 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 obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 RMON Framework to allow Real-time QoS Monitoring of various Applications that run on these types of end devices and allows such information be integrated with RMON Framework via SNMP. Distribution of this memo is unlimited. Table of Contents RMON WG Expires December 2003 [Page 1] INTERNET DRAFT RAQMON Framework June 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 14 5 A Simple list of Metrics pre-defined in BASIC PDU 14 6 Report Aggregation and Statistical Data processing 20 7 Keeping Historical Data and Storage 21 8 Normative References 21 9 Informative References 22 10 Intellectual Property 23 11 Security Considerations 24 12 IANA Considerations 27 13 Acknowledgements 27 14 Authors' Addresses 28 A Full Copyright Statement 28 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 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 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 Realtime using 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 has lot to do with 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 RMON WG Expires December 2003 [Page 2] INTERNET DRAFT RAQMON Framework June 2003 host 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 influences such 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 an 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. Real- Time Application QoS Monitoring (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, 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 December 2003 [Page 3] INTERNET DRAFT RAQMON Framework June 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 PC, 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 December 2003 [Page 4] INTERNET DRAFT RAQMON Framework June 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 it, 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. RRC component of the RAQMON architecture is envisioned to be computationally resourceful. 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 entity captures QoS attributes of such communication session and report that within a RAQMON "reporting session". A RDS is primarily responsible for abstracting IP end-devices and RMON WG Expires December 2003 [Page 5] INTERNET DRAFT RAQMON Framework June 2003 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- device, the design of RDS element is optimized towards that. 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 send out compound QoS reports associated to multiple communication session 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 to audio and video session 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 the 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 to a communication session as perceived by the reporting RDS. For example if two IP Phone users namely 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 variety of reasons. Hence a report from Alice's IP Phone RDS represents QoS performance of that call as perceived by Alice. 2.2 RAQMON Report Collector (RRC) A RAQMON Report Collector (RRC) receives RAQMON PDUs from multiple RDSs, analyzes and stores it 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 RMON WG Expires December 2003 [Page 6] INTERNET DRAFT RAQMON Framework June 2003 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 (i.e. "Name" and "Value" pair) 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 Basic Part and Application specific extensions required for vendor specific extensions. Both functional parts trail behind SMI Network Management Private Enterprise Codes and 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 (a.k.a. "Name") from a pre-defined list of QoS parameters defined in table 1 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 table 1 by identifying appropriate "Name", "Value" pairs to the RDS. 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 mostly stateless for an entire reporting session, the framework would require an indication for the end of the reporting MAY send a RAQMON PDU with all NULL RMON WG Expires December 2003 [Page 7] INTERNET DRAFT RAQMON Framework June 2003 values to indicate the end of the reporting session to the RRC. 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 RAQMON Framework expects RAQMON PDUs to operate in lossy networks, retransmission is not included in RAQMON design as it is viewed as transport layer capability. However not having retransmission and acknowledgements between RDS/RRC pair not only make RAQMON Framework suffer from loss of PDUs, but it complicates the problem further in the case RAQMON NULL PDUs since NULL PDUs define end of reporting session. So to avoid having RRCs not knowing the state of reporting, following measures are taken to deal with the loss of NULL PDU gracefully, in case NULL PDUs are lost: - RRCs should also use other lower level indications such as RRCs receiving an RTCP BYE Packet from a RDS to interpret "end or reporting session" which will help RRCs. - RRCs must use session time out mechanisms to "assume" end of reporting for RDSs which has been out of reporting for a reasonable duration of time. Such time out parameters should be a configurable parameter in vendor implementations and should be assigned during deployment. Further specification of RAQMON PDUs can be found in [RAQMON-PDU] memo. 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. RMON WG Expires December 2003 [Page 8] INTERNET DRAFT RAQMON Framework June 2003 2. Scalable - since RRCs need to interact with a very large number of RDSs, scalability of transport protocol is a requirement. 3. 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. 4. 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 required 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) is also left 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 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 may contain padding so that the extent of the RAQMON payload cannot be determined. The framing mechanism is not defined in this document. Carrying several RAQMON packets in one network or transport packet reduces header overhead. The 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 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]. RMON WG Expires December 2003 [Page 9] INTERNET DRAFT RAQMON Framework June 2003 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. The RDSs will not be capable of inferring successful delivery of PDUs over a lossy network since the RAQMON PDU is expected to operate in lossy network environments. However if required, RAQMON PDUs can be carried over RTCP/TCP as oppose to RTCP/UDP to ensure transport reliability. + The RAQMON reporting session between RDS and RRC is mostly stateless. If RTCP is used as transport, RDSs should also send a RTCP BYE Packet after having sent a RAQMON NULL PDU within RTCP APP Packet to indicate the end of a reporting session. Such measures will increase the probability of reaching a RRC in a lossy network environment. + RRCs should implement session timers to timeout a RDS that has not sent a report within that timeout period. In the case of a lossy network (e.g. RAQMON PDU over RTCP/UDP), such measures will ensure that RRCs do not wait for ever for another PDU from RDS which might have been lost in the network. RRCs, along with unique session IDs, could also use specific fields within a RAQMON PDU like the 6-octet MAC address, the IPv4/IPv6 Address, the Application name or an address to correlate a received RAQMON PDU to an ongoing session. + IANA Port XXXX has been reserved as a default port to carry RAQMON PDU over RTCP. 2.4.2 SNMP Notifications as RDS/RRC Network Transport Protocol SNMP Notifications (Trap or Inform) PDUs are used to transport RAQMON PDUs in the following way: + RDSs embed the RAQMON PDU information in SNMP Notifications to report RAQMON statistics. The MIB used to define the mapping of the RAQMON PDU information in 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 implemented as an SNMP manager, must send an SNMP INFORM Response could for each associated SNMP INFORM originated by the RDS. However sending out Acknowledgements from RRCs to RDSs can create RMON WG Expires December 2003 [Page 10] INTERNET DRAFT RAQMON Framework June 2003 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 diimishes any possibility of using SNMP in 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 real life deployment scenario depending on the use case. 2.5 Configuring RAQMON Data Sources 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, RMON WG Expires December 2003 [Page 11] INTERNET DRAFT RAQMON Framework June 2003 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 to 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 connecting 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. It should be noted that 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 at the application level to send a request, then 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- RMON WG Expires December 2003 [Page 12] INTERNET DRAFT RAQMON Framework June 2003 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. 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 the interface at local interface (usually LAN) rates, without awareness of the intervening network conditions. For these reason, it is considered in general 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 identifying them as 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. RMON WG Expires December 2003 [Page 13] INTERNET DRAFT RAQMON Framework June 2003 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 upon the implementers and equipment vendors to choose. There are many different measurement methodologies available for measuring application performance (e.g., probe-based, client- based, synthetic-transaction, etc.). This specification does not mandate a particular methodology - it is open to any that meet the minimum requirements. Conformance to this specification requires that the collected data match the semantics described herein. 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, ITU Referenced are included in 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. [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 it fit the need. The definition presented here is meant to provide guidance to implementers. No claim is made that the definitions presented here are appropriate for a particular application need. Syntactical representations of the parameters identified here, are standardized in [RAQMON-PDU] specification. Data Source Name (DN): The DN item could be of various formats as needed by the application. A few instances of DN could be but not restricted to * "user@host", or "host" if a user name is not available as on RMON WG Expires December 2003 [Page 14] INTERNET DRAFT RAQMON Framework June 2003 single-user systems. For both formats, "host" is either the fully qualified domain name of the host from which the payload originates, formatted according to the rules specified in [RFC1034], [RFC1035] and Section 2.1 of [RFC1123]. The DN value is expected to remain constant for the duration of a session. Examples are "big-guy@ip- phone.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 a valid E.164 phone number, a SIP URI or any other form of telephone or pager numbers. It is recommended that the phone number should be formatted with the plus sign replacing the international access code. For example, "+88 02 123 45678" for a number in Bangladesh. It is expected that a Data Source Name (DN) will remain constant within a communication session. Receiver Name (RN): Receiver Name (RN) takes the same form like 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. Data Source Address (DA): The Data Source Address (DA) parameter should be represented as the standard ASCII representation of the host's numeric address. This could be an IPv4 Address, IPv6 Address, network address assignments such as the Net-10 assignment proposed in [RFC1597] or any other form of numeric addresses represented in ASCII. It is expected that a Data Source Address (DA) would remain constant within a communication session. DN and DA are intended to give the application writers an opportunity to uniquely identify a record associated to a session. However application writers should be aware that private network address assignments such as the Net-10 assignment might create network addresses that are not globally unique. To handle this case, the burden is on the application either to convert private addresses to public addresses if necessary to keep private addresses from being exposed or to create an application specific extension. Receiver Source Address (RA): Receiver Source Address (RA) takes the same form like Data Source Address (DA) but represents the Receiver's Source Address. In a communication session applications should fill in the other party's address that they are communicating with as a RMON WG Expires December 2003 [Page 15] INTERNET DRAFT RAQMON Framework June 2003 Receiver Source Address. Like Data Source Address, this could be an IPv4 Address, IPv6 Address, network address assignments such as the Net-10 assignment proposed in [RFC1597] or any other form of numeric address represented in ASCII. Data Source Device Ports Used: This parameter is used to indicate the port used for a particular session or sub-session used for communication. Example of port includes TCP Port, UDP Port, RTP Port etc. It is not expected that a Data Source Device Ports would remain constant within a communication session. Receiver Device Ports Used: This parameter is used to indicate the port used to communicate with the receiver for a particular session or sub-session. Example of port includes TCP Port, UDP Port, RTP Port etc. It is not expected that a Data Source Device Ports would remain constant within a communication session. Session Setup Date/Time Indicates the wallclock time when the RAQMON packet was sent so that it may be used by the RRC to store Date/Time. Wallclock time (absolute time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900 [RFC1305]. Session Setup Delay: 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. However as these definitions are very specific to the type of system used and 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. 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. Session Setup Status: This parameter is intended to report status of a session in order to support applications those need to display status in real time. For example a debugging tool that captures the status of a call-setup as soon as a call is established or a tool that captures why a session failed or how many RSVP sessions failed etc. Round Trip End-to-End Delay: Round Trip End-to-End Delay [RFC1889], RMON WG Expires December 2003 [Page 16] INTERNET DRAFT RAQMON Framework June 2003 [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],[RFC1889] depending on the application needs and left upon the implementers to select appropriate IETF and ITU methodologies to measure End-to-End Delays appropriate for a specific application. One Way End-to-End Delay: The One Way End-to-End Delay [RFC 2679] allows the 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 [RFC 2679] 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. RMON WG Expires December 2003 [Page 17] INTERNET DRAFT RAQMON Framework June 2003 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 same units as Round Trip End-to-End Delay. Inter-arrival Jitter [RFC1889]: The 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 and left upon the implementers based on their application needs. VoIP Systems can readily acquire Inter-arrival Jitter calculations from RTCP measurements as described in [RFC1889]. Total Number of Application Packets Received [RFC1889]: The total number of payload packets received by the RDS since starting transmission up until the time this RAQMON PDU was generated. Total Number of Application Packets Sent [RFC1889]: The total number of payload packets sent by the RDS since starting transmission up until the time this RAQMON PDU was generated. Similar to total number of packets received. Total number of Application Octets Received [RFC1889]: The total number of payload octets received in packets by the RDS since beginning transmission up until the time this RAQMON packet was generated. Total number of Application Octets Sent [RFC1889]: The total number of payload octets received in packets by the RDS since beginning transmission up until the time this RAQMON packet was generated. Similar to total number of octets received. Cumulative Application Packet Loss: Packet loss tracks persistent congestion while the jitter measure tracks transient congestion. Since the 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 device specific algorithms. Packet loss in Fraction: Packet loss in Fraction represents sackets loss as defined above but expressed in percentage. Source Payload Type: The Source Payload Type defines payload formats (e.g. media encodings) as sent by the data source. e.g. ITU RMON WG Expires December 2003 [Page 18] INTERNET DRAFT RAQMON Framework June 2003 G.711-(law, ITU G.729B, H.263, MPEG-2, ASCII etc. This document follows the same payload type constants as defined in [RFC1890]. Destination Payload Type: 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-(law, ITU G.729B, H.263, MPEG-2, ASCII etc. This document follows the same payload type constants as defined in [RFC1890]. Source Layer 2 Priority: Many devices use Layer 2 technologies to prioritize certain type of traffic in the Local Area Network environment. For example the 1998 Edition of IEEE 802.1D [IEEE802.1D] "Media Access Control" Bridges contains expedited traffic capabilities to support transmission of time critical information and many devices use the standard to mark Ethernet frames according to IEEE 802.1p standard. Details on these can be found in IEEE 802.1Q "Virtual Bridged LAN" specifications. 802.1p has been Incorporated into ISO/IEC 15802-3 1998 [IEEE802.1Q]. Source Layer 2 RAQMON field indicates Layer 2 values used by the RDS to prioritize these packets in the Local Area Networks environment. Source TOS/DSCP Value: Various Layer 3 technologies are in place to prioritize certain type of traffic in the Internet. For example traditional IP Precedence [RFC791], Type Of Service (TOS) [RFC1349],[RFC1812] or more recent technologies like Differentiated Service [RFC2474][RFC2475] is achieved by using the TOS octet in IPv4 and the Traffic class Octet in IPv6 are used to prioritize traffic. Source Layer 3 RAQMON field indicates appropriate Layer 3 values used by the Data Source to prioritize these packets. Destination Layer 2 Priority: 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 destination has used any Layer 2 technologies like IEEE 802.1p/Q or priority queuing etc. Destination TOS/DSCP Value: 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 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]. 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 implication on QoS RMON WG Expires December 2003 [Page 19] INTERNET DRAFT RAQMON Framework June 2003 implications of an end device. e.g. x % CPU busy averaged over session duration. Memory Utilization in Fraction: This parameter captures the IP Device Memory usage rate to indicate current state of the local IP Device resource, which may have very critical implication on QoS implications of an end device. e.g. y % memory utilized over session duration. Application Name/version: Application Name/version parameter gives the name and possibly version of the application associated to that session or sub-session, e.g., "XYZ VoIP Agent 1.2". This information may be useful for scenarios where 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 Within RAQMON Framework, since RRCs are computationally resourceful, various aggregation functions are performed by the RRC and 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 specified below: Round Trip End-to-End Delay One Way End-to-End Delay Inter Arrival Jitter Cumulative Packet Loss Packet Loss in Fraction CPU utilization in Fraction Memory utilization in Fraction The aggregation of the parameters listed above, 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. RMON WG Expires December 2003 [Page 20] INTERNET DRAFT RAQMON Framework June 2003 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. 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 following ways: 1. Store data in the MIB only at the end of a communication session (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 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 at the application developer's discretion. 8. Normative References [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000 [RFC1889] Henning Schulzrinne, S. Casner, R. Frederick, and RMON WG Expires December 2003 [Page 21] INTERNET DRAFT RAQMON Framework June 2003 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 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 [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) RMON WG Expires December 2003 [Page 22] INTERNET DRAFT RAQMON Framework June 2003 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 [RAQMON-PDU] A. Siddiqui, S. Waldbusser, D.Romascanu, and E. Golovinsky, "Protocol Data Units for Real-time Application Quality of Service Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon-pdu-02.txt, June 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-01.txt, June 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 RMON WG Expires December 2003 [Page 23] INTERNET DRAFT RAQMON Framework June 2003 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 other in 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 Among non-existent threats is repudiation since RAQMON is assumed not to deal with transactional data. It may be noted that it is the RRC that will be directly affected by these RAQMON exploits due to the unidirectional nature of the RAQMON dataflow. Indirect effects of these threats may affect the RDS. 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 RMON WG Expires December 2003 [Page 24] INTERNET DRAFT RAQMON Framework June 2003 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 - 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. RMON WG Expires December 2003 [Page 25] INTERNET DRAFT RAQMON Framework June 2003 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. 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 this 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), RMON WG Expires December 2003 [Page 26] INTERNET DRAFT RAQMON Framework June 2003 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 to 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 its 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. 11.6 Use of TCP as transport When using TCP as the RAQMON transport, in order to meet the security services requirement of RAQMON stream, the more ubiquitous TLS protocol support may be made use of. 12. IANA Considerations This memo introduces 1 new port for IANA registration. This specification registers port YYYYY as specified in Section 2.4.1 at http://www.iana.org/numbers.html 13. Acknowledgements RMON WG Expires December 2003 [Page 27] INTERNET DRAFT RAQMON Framework June 2003 The authors would like to thank Mahalingam Mani, Steven Waldbusser and Itai Zilbershtein for interesting discussions and various direct contributions in this problem space. 14. 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 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. RMON WG Expires December 2003 [Page 28] INTERNET DRAFT RAQMON Framework June 2003 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 December 2003 [Page 29]