diff options
Diffstat (limited to 'doc/rfc/rfc4710.txt')
| -rw-r--r-- | doc/rfc/rfc4710.txt | 2019 |
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc4710.txt b/doc/rfc/rfc4710.txt new file mode 100644 index 0000000..ebf1f1b --- /dev/null +++ b/doc/rfc/rfc4710.txt @@ -0,0 +1,2019 @@ + + + + + + +Network Working Group A. Siddiqui +Request for Comments: 4710 D. Romascanu +Category: Standards Track Avaya + E. Golovinsky + Alert Logic + October 2006 + + + Real-time Application Quality-of-Service + Monitoring (RAQMON) Framework + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + There is a need to monitor end-devices such as IP phones, pagers, + Instant Messaging clients, mobile phones, and various other handheld + computing devices. This memo extends the remote network monitoring + (RMON) family of specifications to allow real-time quality-of-service + (QoS) monitoring of various applications that run on these devices + and allows this information to be integrated with the RMON family + using the Simple Network Management Protocol (SNMP). This memo + defines the framework, architecture, relevant metrics, and transport + requirements for real-time QoS monitoring of applications. + +Table of Contents + + 1. Introduction ....................................................2 + 2. RAQMON Functional Architecture ..................................4 + 3. RAQMON Operation in Congestion-Safe Mode .......................11 + 4. Measurement Methodology ........................................14 + 5. Metrics Pre-Defined for the BASIC Part of the RAQMON PDU .......14 + 6. Report Aggregation and Statistical Data processing .............28 + 7. Keeping Historical Data and Storage ............................29 + 8. Security Considerations ........................................30 + 9. Acknowledgements ...............................................32 + 10. Normative References ..........................................33 + 11. Informative References ........................................34 + + + +Siddiqui, et al. Standards Track [Page 1] + +RFC 4710 RAQMON Framework October 2006 + + +1. Introduction + + With the growth of the Internet and advancements in embedded + technologies, smart IP devices (such as IP phones, pagers, instant + message clients, mobile phones, wireless handhelds, and various other + computing devices) have become an integral part of our day-to-day + operations. Enterprise operators, information technology (IT) + managers, application service providers, network service providers, + and so on, need to monitor these application and device types in + order to ensure that end user quality-of-service (QoS) objectives are + met. This memo describes a monitoring solution for these + environments, extending the remote network monitoring (RMON) family + of specifications [RFC2819]. These extensions support real-time QoS + monitoring of typical applications that run on end-devices mentioned + above, and they allow this information to be integrated using the + familiar RMON family of specifications via SNMP [RFC3416]. + + The Real-time Application QoS Monitoring Framework (RAQMON) allows + end-devices and applications to report QoS statistics in real time. + Many real-time applications (as well as non-real-time applications + managed within the RMON family of specifications) can report + application-level QoS statistics in real time using the RAQMON + Framework outlined in this memo. Some possible applications + scenarios include applications such as Voice over IP, Fax over IP, + Video over IP, Instant Messaging (IM), Email, software download + applications, e-business style transactions, web access from handheld + computing devices, etc. + + The user experience of an application running on an IP end-device + depends upon the type of application the user is running and the + surrounding resources available to that application. An end-to-end + application QoS experience is a compound effect of various + application-level transactions and available network and host + resources. For example, the end-to-end user experience of a Voice + over IP (VoIP) call depends on the total time required to set up the + call as much as on media-related performance parameters such as end- + to-end network delay, jitter, packet loss, and the type of codec used + in a call. The performance of a VoIP call is also influenced by + behavior of network protocols like the Reservation Protocol (RSVP), + explicit tags in differentiated services (DiffServ) [RFC2475] or IEEE + 802.1 [IEEE802.1D] along with available host resources such as device + CPU or memory utilized by other applications while the call is + ongoing. + + The end-to-end application quality of service (QoS) experience is + application context sensitive. For example, the kinds of parameters + reported by an IP telephony application may not really be needed for + other applications such as Instant Messaging. The RAQMON Framework + + + +Siddiqui, et al. Standards Track [Page 2] + +RFC 4710 RAQMON Framework October 2006 + + + offers a mechanism to report the end-to-end QoS experience + appropriate for a specific application context by providing + mechanisms to report a subset of metrics from a pre-defined list. + + In order to facilitate a complete end-to-end view, RAQMON correlates + statistics that involve: + + i. "User, Application, Session"-specific parameters (e.g., + session setup time, session duration parameters based on + application context). + + ii. "IP end-device"-specific parameters during a session (e.g., + CPU usage, memory usage). + + iii. "Transport network"-specific parameters during a session + (e.g., end-to-end delay, one-way delay, jitter, packet loss + etc). + + At any given point, the applications at these devices can correlate + such diverse data and report end-to-end performance. The RAQMON + Framework specified in this memo offers a mechanism to report such + end-to-end QoS view and integrate such a view into the RMON family of + specifications. In particular, the RAQMON Framework specifies the + following: + + a. A set of basic metrics sent as reports between the RAQMON + entities using for transport existing Internet Protocols such + as TCP or SNMP. + + b. Requirements to be met by the underlying transport protocols + that carry the RAQMON reports. + + c. A portion of the Management Information Base (MIB) as an + extension of the RMON MIB Modules for use with network + management protocols in the Internet community. + + This memo provides the RAQMON functional architecture, RAQMON entity + definitions and requirements, requirements for the transport + protocols, a set of metrics, and an information model for the RAQMON + reports. + + Supplementary memos will describe the mapping of the basic RAQMON + metrics onto different transport protocols. For example, the RAQMON + PDU [RFC4712] memo provides definitions of syntactical PDU structure + and use case scenarios of transmission of such PDUs over the + Transmission Control Protocol (TCP) and the Simple Network Management + Protocol (SNMP). + + + + +Siddiqui, et al. Standards Track [Page 3] + +RFC 4710 RAQMON Framework October 2006 + + + The RAQMON MIB [RFC4711] memo describes the Management Information + Base (MIB) for use with the SNMP protocol in the Internet community. + The document proposes an extension to the Remote Monitoring MIB + [RFC2819] to accommodate RAQMON solutions. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. RAQMON Functional Architecture + + The RAQMON Framework extends the architecture created in the RMON MIB + [RFC2819] by providing application performance information as + experienced by end-users. The RAQMON architecture is based on three + functional components named below: + + - RAQMON Data Source (RDS) + + - RAQMON Report Collector (RRC) + + - RAQMON MIB Structure + + A RAQMON Data Source (RDS) is a functional component that acts as a + source of data for monitoring purposes. End-devices like IP phones, + cell phones, and pagers, and application clients like instant + messaging clients, soft phones in PCs, etc., are envisioned to act as + RDSs within the RAQMON Framework. + + + + + + + + + + + + + + + + + + + + + + + + +Siddiqui, et al. Standards Track [Page 4] + +RFC 4710 RAQMON Framework October 2006 + + + + +----------------------+ +---------------------------+ + | IP End-Device | | IP End-Device >----+ | + |+--------------------+| |+--------------------+ | | + || APPLICATION || || APPLICATION | | | + || -Voice over IP <----(1)----> -Voice over IP >- + | | + || -Instant Messaging|| || -Instant Messaging| | 3 | + || -Email || || -Email | 2 | | + |+--------------------+| |+--------------------+ | | | + | | | | | | + | | | +------------------+ | | | + +----------------------+ | |RAQMON Data Source|<-+ | | + | | (RDS) |<---+ | + | +------------------+ | + +-----------|---------------+ + | + (4) RAQMON PDU transported + over TCP or SNMP Notifications + | + +----------------------------+ + | | + |/ |/ + +------------------+ +------------------+ +------------+ + |RAQMON Report | .. |RAQMON Report | | Management | + |Collector (RRC) #n| |Collector (RRC) #1|<--5-->| Application| + +------------------+ +------------------+ +------------+ + + + Figure 1 - RAQMON Framework. + + (1) Communication Session between real-time applications + + (2) Context-Sensitive Metrics + + (3) Device State Specific Metrics + + (4) Reporting session - RAQMON metrics transmitted over specified + interfaces (Specific Protocol Interface, IP Address, port) + + (5) Management Application - RRC interaction using the RAQMON MIB + + A RAQMON Report Collector (RRC) collects statistics from multiple + RDSs, analyzes them, and stores such information appropriately. 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 module. + + + + +Siddiqui, et al. Standards Track [Page 5] + +RFC 4710 RAQMON Framework October 2006 + + + The RAQMON Management Information Base (RAQMON MIB) extends the + Remote Monitoring MIB [RFC2819] to accommodate the RAQMON Framework + and exposes End-to-End Application QoS information to Network + Management Applications. + +2.1. RAQMON Data Source (RDS) + +2.1.1. RAQMON Data Source (RDS) Functional Architecture + + A RAQMON Data Source (RDS) is a source of data for monitoring + purposes. The RDS monitoring function is performed in real time + during communication sessions. The RDS entities capture QoS + attributes of such communication sessions and report them within a + RAQMON "reporting session". + + An RDS is primarily responsible for abstracting IP end-devices and + applications within the RAQMON architecture. It gathers the + parameters for a particular communication session and forwards them + to the appropriate RAQMON Report Collector (RRC). Since it is + envisioned that the RDS functionality will be realized by writing + firmware/software running on potentially small, low-powered end- + devices, the design of the RDS element is optimized towards that end. + Like the implementations of routing and management protocols, an + implementation of RDS in an end-device will typically execute in the + background, not in the data-forwarding path. + + RDSs use a PUSH mechanism to report QoS parameters. While the + applications running on the RDS decide about the content of the PDU + appropriate for an application context, an RDS asynchronously sends + out reports to RRC. + + The rate at which PDUs are sent from RDSs to RRCs is controlled by + the applications' administrative domain policy. While this mechanism + provides flexibility to gather a detailed end-to-end experience + required by IT managers and system administrators, certain steps + should be followed to operate RAQMON in congestion-safe manner. + Section 3 addresses steps required for congestion-safe operation. + + An RDS reports QoS statistics for simplex flows. At a given + instance, a report from RDS is logically viewed as a collection of + QoS parameters associated with a communication session as perceived + by the reporting RDS. For example, if two IP phone users, Alice and + John, are involved in a communication session, the end-to-end delay + experienced by the IP phone user Alice could be different from the + one experienced by the IP phone user John for a variety of reasons. + Hence, a report from Alice's IP phone represents the QoS performance + of that call as perceived by the RDS that resides in Alice's IP + phone. + + + +Siddiqui, et al. Standards Track [Page 6] + +RFC 4710 RAQMON Framework October 2006 + + +2.1.2. RAQMON Data Source (RDS) Requirements + + 1. RAQMON Data Sources SHALL gather reports from multiple + applications residing in that device and SHALL send out + compound QoS reports associated with multiple communication + sessions at a given moment. + + Examples include a conference bridge hosting several different + conference calls or a two-party video call consisting of + audio/video sessions. In each case an 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. + + 2. RAQMON Data Sources MUST implement the TCP transport and MAY + implement the SNMP transport. + +2.1.3. Configuring RAQMON Data Sources + + In order to report statistics to RAQMON Report Collectors, RDSs will + need to be configured with the following parameters: + + 1. The time interval between RAQMON PDUs. This parameter MUST be + configured such that overflow of any RAQMON parameter within a + PDU between consecutive transmissions is avoided. + + 2. The IP address and port of target RRC. + + An RDS may use manual configuration for the RDS configuration + parameters using command line interface (CLI), Telephone User + Interface (TUI), etc. + + One of the following mechanisms to gain access to configuration + parameters can also be considered: + + - RDS acts as a trivial file transfer protocol (TFTP) client and + downloads text scripts to read the parameters. + - RDS acts as a Dynamic Host Configuration Protocol (DHCP) Client + and gets RRC addressing information as a DHCP option. + - RDS acts as a DNS client and gets target collector information + from a DNS Server. + - RDS acts as a LDAP Client and uses directory look-ups. + + Identifying the DHCP option and structure to use, defining the + structure of the configuration information in DNS, or defining a LDAP + schema could be explored as items of future work. + + + + + +Siddiqui, et al. Standards Track [Page 7] + +RFC 4710 RAQMON Framework October 2006 + + + Compliance to the RAQMON specification does not require usage of any + specific configuration mechanisms mentioned above. It is left to the + implementers to choose appropriate provisioning mechanisms for a + system. + +2.2. RAQMON Report Collector (RRC) + +2.2.1. RAQMON Report Collector (RRC) Functional Architecture + + A RAQMON Report Collector (RRC) receives RAQMON PDUs from multiple + RDSs and analyzes and stores the information in the RAQMON MIB. The + RRC is envisioned to be computationally resourceful, providing a + storage and aggregation point for a set of RDSs. + + Since RDSs can belong to separate administrative domains, the RAQMON + Framework allows RDSs to report QoS parameters to separate RRCs. + Vendors can develop a management application to correlate information + residing in different RRCs across multiple administrative domains to + represent one communication session. However, such an application- + level specification is beyond the scope of this memo. + +2.2.2. RAQMON Report Collector (RRC) Requirements + + 1. RAQMON Report Collectors MUST support the mandatory mapping + over TCP of the RAQMON information model defined in [RFC4712] + with the purpose of receiving RAQMON reports from RAQMON Data + Sources (RDS). + + 2. RAQMON Report Collectors MAY support the optional mapping over + SNMP notifications of the RAQMON information model defined in + [RFC4712]. + + 3. RAQMON Report Collectors MUST implement session timeout + mechanisms to assume end of reporting for RDSs that have been + out of reporting for a reasonable duration of time. Such + timeout parameters SHOULD be configurable in vendor + implementations, as programmable parameters at deployment. + + 4. RAQMON Report Collectors MUST support the RAQMON-MIB module and + meet the compliance requirements of the raqmonCompliance + MODULE-COMPLIANCE definition as described in [RFC4711]. The + population of the RAQMON MIB with performance monitoring + information is independent of the transport protocol, or + protocols used to carry the information between RDSs and RRCs. + + + + + + + +Siddiqui, et al. Standards Track [Page 8] + +RFC 4710 RAQMON Framework October 2006 + + +2.3. Information Model and RAQMON Protocol Data Unit (PDU) + +2.3.1. RAQMON Information Model + + RAQMON defines a set of basic metrics that characterize the QoS of + applications, as reported by RAQMON Data Sources. This basic set of + metrics is defined in Section 5 of this memo. There is no minimal + requirement for a mandatory set of metrics to be supported by an RDS. + + Specific applications, new types of network appliances or new methods + to measure and characterize the QoS of applications lead to the + requirement for the information model to be extensible. To answer + this need, the information model is designed so that vendors can + extend it by adding new metrics. + + Although NOT REQUIRED for RAQMON conformance, extensions of the + information model can offer useful information for specific + applications. An example of metrics that can extend the basic RAQMON + information model are the detailed metrics for VoIP media monitoring + and call quality included in the VoIP Metrics Report Block defined in + [RFC3611]. + + The RAQMON Information model is expressed by defining a conceptual + RAQMON Protocol Data Unit (PDU). + +2.3.2. RAQMON Protocol Data Unit + + A RAQMON Protocol Data Unit (PDU) is a common data format understood + by RDSs and RRCs. A RAQMON PDU does not transport application data + but rather occupies the place of a payload specification at the + application layer of the protocol stack. Different transport + mappings may be used to carry RAQMON PDU between RDSs and RRCs. + Transport protocol requirements are being defined in Section 2.4 of + this memo. + + Though architected conceptually as a single PDU, the RAQMON PDU is + functionally divided into two different parts. They are the BASIC + part, and the Application-Specific Extensions, required for + application-, vendor-, and device-specific extensions. + + The BASIC part of the RAQMON PDU: + The BASIC part of the RAQMON PDU follows 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 an RDS + report built only of a subset of the parameters listed in + + + +Siddiqui, et al. Standards Track [Page 9] + +RFC 4710 RAQMON Framework October 2006 + + + Section 5. There is no need to carry all metrics in every PDU; + moreover, it is RECOMMENDED that static or pseudo-static metrics + that do not change or seldom change for a given session or + application will be send only when the session or application are + initiated, and then at large time intervals. + + 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-, and device-specific parameters + for future use. Additional parameters can be defined within + payload of the APP part of the PDU by the application developers + or vendors. The owner of the definition of the application part + of the RAQMON PDU is indicated by a vendor's SMI Network + Management Private Enterprise Code defined 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 requires an indication for the end + of the reporting. For this purpose, an RDS MUST send a RAQMON NULL + PDU. A NULL PDU is a RAQMON PDU containing ALL NULL values (i.e., + nothing to report). + +2.4. RDS/RRC Network Transport Protocol Requirements + + The RAQMON PDUs rely on the underlying protocol(s) to provide + transport functionalities and other attributes of a transport + protocol, e.g., transport reliability, re-transmission, error + correction, length indication, congestion safety, + fragmentation/defragmentation, etc. The maximum length of the RAQMON + data packet is limited only by the underlying protocols. + + The following requirements MUST be met by the transport protocols: + + 1. The transport protocol SHOULD allow for RDS lightweight + implementations. RDSs will be implemented on low-powered + embedded devices with limited device resources. + + 2. Scalability - Since RRCs need to interact with a very large + number (many tens, many hundreds, or more) of RDSs, scalability + of the transport protocol is REQUIRED. + + 3. Congestion safety - as per [RFC2914]. See also Section 3. + + + + + + +Siddiqui, et al. Standards Track [Page 10] + +RFC 4710 RAQMON Framework October 2006 + + + 4. Security - Since RAQMON statistics may carry sensitive system + information requiring protection from unauthorized disclosure + and modification in transit, a transport protocol that provides + strong secure modes or allows for data encryption and integrity + to be applied is REQUIRED. + + 5. NAT-Friendly - The transport protocol SHOULD comply with + [RFC3235], so that an RDS could communicate with an RRC through + a Firewall/Network Address Translation device. + + 6. The transport protocol MAY implement session timeout mechanisms + to assume end of reporting for RDSs that have been out of + reporting for a reasonable duration of time. Such timeout + parameters SHOULD be configurable in vendor implementations, + programmable at deployment. + + 7. Reliability - The RAQMON Framework expects PDUs to operate in + lossy networks. However, retransmission is not included in the + RAQMON framework, in order to keep the design simple. If + retransmission is a necessity, RAQMON MAY operate over + transport protocols, such as TCP. + + 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 for the RAQMON + 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. No framing + mechanism is defined in this document. Carrying several RAQMON + packets in one network or transport packet reduces header overhead. + + Further memos like [RFC4712] describe how the PDU is transported over + existing protocols like the Transmission Control Protocol (TCP) or + the Simple Network Management Protocol (SNMP). + +3. RAQMON Operation in Congestion-Safe Mode + + RAQMON PDUs can be transmitted over multiple transport protocols. + The RAQMON Framework will be congestion safe, if a RAQMON PDU is + transported over TCP. + + One solution to the congestion awareness problem could have been to + discourage the use of UDP entirely for RAQMON. Though RAQMON PDUs + can be transported over TCP, some transports like SNMP over TCP are + not commonly practiced in practical deployments. + + + + + + +Siddiqui, et al. Standards Track [Page 11] + +RFC 4710 RAQMON Framework October 2006 + + + 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 PDUs fragmented at the UDP level. + Transport protocols such as DCCP can also be used as underlying + RAQMON PDU transport, which provides flexibility of UDP style + datagram transmission with congestion control. + + It should be noted that the congestion problem is not just between + RDS and RRC pairs, but whenever there is a high fan-in ratio, + congestion could occur (e.g., many RDSs reporting to an RRC). Within + the RAQMON Framework using UDP as a transport, congestion safety can + be achieved in following ways: + + 1. Constant Transmission Rate: In a well-managed network, a + constant transmission rate policy (e.g., 1 RAQMON PDU per + device every N seconds) will ensure congestion safety as + devices are introduced into the network in a controlled manner. + For example, in an enterprise network, IP Phones are added in a + controlled manner, and a constant transmission rate policy can + be sufficient to ensure congestion-safe operation. The + configured rate needs to be related to the expected peak number + of devices. As a worst-case scenario, if the RDSs enforce an + administrative policy where the maximum PDU transmission rate + is no more than one RAQMON PDU every two minutes, a UDP-based + implementation can be as congestion safe as a TCP-based + implementation. Such policies can be enforced while + configuring RDSs, and the timers for the constant rate need to + be randomly jittered. + + 2. Single outstanding requests: 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 reliability and efficiency reasons, this + technique must include backed-off retransmissions. For + example, if RAQMON PDUs are transported using SNMP INFORM PDUs + over UDP, a SNMP response from the RRC SHOULD be processed by + the RDS to implement this mechanism. [RFC4712] specifies that + + + +Siddiqui, et al. Standards Track [Page 12] + +RFC 4710 RAQMON Framework October 2006 + + + if the SNMP notifications transport mapping mechanism is + implemented, it is RECOMMENDED to use INFORM PDUs, and it is + NOT RECOMMENDED to use Trap PDUs. + + 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 (round-trip time) delay between transmissions. More + sophisticated algorithms (such as those in TCP and Stream + Control Transmission Protocol (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. + + 3. By restricting transmission to a maximum transmission unit + (MTU) size: An 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, an 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, an RDS MAY also + send parameters to RRC over multiple RAQMON PDUs but identify + them as part of the same RAQMON reporting session with exactly + the same Network Time Protocol (NTP) [RFC1305] 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. + + + + + + + +Siddiqui, et al. Standards Track [Page 13] + +RFC 4710 RAQMON Framework October 2006 + + +4. Measurement Methodology + + It is not the intent of this document to recommend a methodology to + measure any of the QoS parameters defined in Section 5. Measurement + algorithms are left to the implementers and equipment vendors to + choose. There are many different measurement methodologies available + for measuring application performance. These include probe-based, + client-based, synthetic-transaction, and other approaches. This + specification does not mandate a particular methodology and is open + to any methodology that meets the minimum requirements. For + conformance to this specification, it is REQUIRED that the collected + data match the semantics described herein. However, it is + RECOMMENDED that vendors use IETF-defined and International + Telecommunication Union (ITU)-specified methodologies to measure + parameters when possible. + +5. Metrics Pre-Defined for the BASIC Part of the RAQMON PDU + + The BASIC part of the RAQMON PDU provides for a list of pre-defined + parameters frequently used by applications to characterize end-to-end + application Quality of Service. This section defines a set of simple + metrics to be contained in the BASIC part of the RAQMON PDU, through + reference to existing IETF, ITU, and other standards organizations' + documents. Appropriate IETF or ITU references are included in the + metrics definitions. + + As mentioned earlier, the RAQMON PDU also contains an application- + specific part, where application- and vendor-specific information not + included in BASIC part can be added as <Name, Value> pairs, or as a + variable binding list. These extensions, managed independently by + vendors or other organizations, should be published for wider + interoperability. + + Applications are not required to report all the parameters mentioned + in this section, but should have the flexibility to report a subset + of these parameters appropriate to an application context. The memo + further identifies the parameters that RDSs are required to include + in all PDUs for compliance, as well as optional parameters that RDSs + may report as needed. The definitions presented here are meant to + provide guidance to implementers, and IETF metric definition + references are provided for each metric. Application developers + should choose the metrics appropriate to their applications' needs. + Syntactical representations of the parameters identified here are + provided in the [RFC4712] specification. + + + + + + + +Siddiqui, et al. Standards Track [Page 14] + +RFC 4710 RAQMON Framework October 2006 + + +5.1. Data Source Address (DA) + + The Data Source Address (DA) is the address of the data source. This + could be either a globally unique IPv4 or IPv6 address, or a + privately IPv4 allocated address as defined in [RFC1918]. + + It is expected that the DA would remain constant within a given + communication session. RDSs SHOULD avoid sending these parameters + within RAQMON reports too often to ensure an efficient usage of + network resources. + +5.2. Receiver Address (RA) + + The Receiver Address (RA) takes the same form as the Data Source + Address (DA) but represents the Receiver's Address. In a + communication session, the reporting RDSs SHOULD fill in the other + party's address as a Receiver Address. Like the Data Source Address, + this could be either a globally unique IPv4 or IPv6 address, or a + privately allocated IPv4 address as defined in [RFC1918]. + + It is expected that the Receiver Address (RA) would remain constant + within a given communication session. RDSs SHOULD avoid sending + these parameters within RAQMON reports too often in order to ensure + an efficient usage of network resources. + +5.3. Data Source Name (DN) + + The Data Source Name (DN) item could be of various formats as needed + by the application. Forms the DN could take include, but are not + restricted to: + + - "user@host", or "host" if a user name is not available as on + single-user systems. For both of these formats, "host" is the + fully qualified domain name of the host from which the payload + originates, formatted according to the rules specified in + [RFC1034], [RFC1035], and Section 2.1 of [RFC1123]. Use example + names are "big-guy@example.com" or "big-guy@192.0.2.178" for a + multi-user system. On a system with no user name, an example + would be "ip-phone4630.example.com". It is RECOMMENDED that the + standard host's numeric address not be reported via the DN + parameter, as the 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. The + phone number SHOULD be formatted with a plus sign replacing the + international access code. Example: "+44-116-496-0348" for a + number in the UK. + + + + +Siddiqui, et al. Standards Track [Page 15] + +RFC 4710 RAQMON Framework October 2006 + + + The DN value is expected to remain constant for the duration of a + session. RDSs SHOULD avoid sending these parameters within RAQMON + reports too often in order to ensure an efficient usage of network + resources. + +5.4. Receiver Name (RN) + + The Receiver Name (RN) takes the same form as DN, but represents the + Receiver's name. In a communication session, an application SHOULD + supply as an RN the name of the other party with which it is + communicating. + + The RN value is expected to remain constant for the duration of a + session. RDSs SHOULD avoid sending these parameters within RAQMON + reports too often in order to ensure an efficient usage of network + resources. + +5.5. Data Source Device Port Used + + This parameter indicates the source port used by the application for + a particular session or sub-session in communication. Examples of + ports include TCP Ports or UDP Ports, as used by communication + application protocols such as Session Initiation Protocol (SIP), SIP + for Instant Messaging and Presence Leveraging Extensions (SIMPLE), + H.323, RTP, HyperText Transport Protocol (HTTP), and so on. + + This parameter MUST be sent in the first RAQMON PDU. + +5.6. Receiver Device Port Used + + This parameter indicates the receiver port used by the application + for a particular session or sub-session. Examples of ports include + TCP Ports, or UDP Ports used by communication application protocols + such as SIP, SIMPLE, H.323, RTP, HTTP, etc. + + This parameter MUST be sent in the first RAQMON PDU. + +5.7. Session Setup Date/Time + + This parameter gives the time when the setup was initiated, if the + application has a setup phase, or when the session was started, if + such a setup phase does not exist. The time is represented using the + timestamp format of the Network Time Protocol (NTP), which is in + seconds relative to 0h UTC (Coordinated Universal Time) on 1 January + 1900 [RFC1305]. + + This parameter SHOULD be sent only in the first RAQMON PDU, after the + session setup is completed. + + + +Siddiqui, et al. Standards Track [Page 16] + +RFC 4710 RAQMON Framework October 2006 + + +5.8. Session Setup Delay + + The Session Setup Delay metric reports the time taken from an + origination request being initiated by a host/endpoint to the media + path being established (or a session progress indication being + received from the remote host/endpoint), expressed in milliseconds. + For example, in VoIP systems, a session setup time can be measured as + the interval from the last DTMF (dual-tone multi-frequency) 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 when an INVITE is + generated by a User Agent and when the 200 OK is received. + + This parameter SHOULD be sent only in the first RAQMON PDU, after the + session setup is completed. + +5.9. Session Duration + + The Session Duration metric reports how long a session or a sub- + session lasted. This metric is application context sensitive. For + example, a VoIP Call Session Duration can be measured as the elapsed + time between call pickup and call termination, including session + setup time. + + This parameter SHOULD be sent only in the first RAQMON PDU, after the + session is terminated. + +5.10. Session Setup Status + + The Session Setup Status metric is intended to report the + communication status of a session. Its values identify appropriate + communication session states, such as Call Progressing, Call + Established successfully, "trying", "ringing", "re-trying", "RSVP + reservation failed", and so on. + + Session setup status is meaningful in the context of applications. + For this reason, applications SHOULD use this metric together with + the application/name metrics defined in Section 5.32. + + This information could be used by network management systems to + calculate parameters such as call success rate, call failure rate, + etc., or by a debugging tool that captures the status of a call's + setup phase as soon as a call is established. + + This parameter SHOULD be sent after each change in the session + status. + + + + + +Siddiqui, et al. Standards Track [Page 17] + +RFC 4710 RAQMON Framework October 2006 + + +5.11. Round-Trip End-to-End Network Delay + + The Round-Trip End-to-End Network Delay, defined in [RFC3550] for + applications running over RTP and in [RFC2681] for all other IP + applications, is a key metric for Application QoS Monitoring. Some + applications do not perform well (or at all) if the end-to-end delay + between hosts is large relative to some threshold value. Erratic + variation in delay values makes it difficult (or impossible) to + support many real-time applications such as Voice over IP, Video over + IP, Fax over IP etc. + + The Round-Trip End-to-End Network delay of the underlying transport + network is measured using methodologies described in [RFC3550] for + RTP and in [RFC2681] for other IP applications. + + Note that the packets used for measurement in some methodologies may + be of a different type from those used for media (e.g., ICMP instead + of RTP) and hence may differ in terms of route and queue priority. + This may result in measured delays being different from those + experienced on the media path. Conformance for this metric requires + that actual application packets, or packets of the same application + type, be used. + + Support for RTP can be determined by the support of the RTP MIB + [RFC2959] in the hosts running the applications or by inclusion of + the string 'RTP' at the beginning of the Application Name (Section + 5.32). + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.12. One-Way End-to-End Network Delay + + The One-Way End-to-End Network Delay [RFC2679] metric reports the + One-Way End-to-End delay encountered by traffic from the source to + the destination network interface. One-Way Delay measurements + identified by the IP Performance Metrics (IPPM) Working Group + [RFC2679] will be used to measure one-way end-to-end network delay. + + The need for such a metric is derived from the fact that the path + from a source to a destination may be different from 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. + + + + + +Siddiqui, et al. Standards Track [Page 18] + +RFC 4710 RAQMON Framework October 2006 + + + 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 + (Asynchronous Transfer Mode) versus Packet-over-SONET (Synchronous + Optical) transport networks). + + 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 than on the + direction in which acknowledgements travel. + + In QoS-enabled networks, provisioning in one direction may be + radically different from provisioning in the reverse direction, and + thus the QoS guarantees differ. Measuring the paths independently + allows the verification of both guarantees. + + RAQMON SHOULD NOT derive One-Way End-to-End Network Delay by assuming + Internet paths are symmetric (i.e., dividing Round-Trip Delay by + two). + + Note that the packets used for measurement in some methodologies may + be of a different type from those used for media (e.g., ICMP instead + of RTP) and hence may differ in terms of route and queue priority. + This may result in measured delays being different from those + experienced on the media path. Conformance for this metric requires + that actual application packets, or packets of the same application + type, be used. + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.13. Application Delay + + Various Network Delay versions, as outlined in Sections 5.11 and + 5.12, do not include delays associated with buffering, play-out, + packet-sequencing, coding/decoding, etc., in the end-devices. The + Application Delay metric defined in this section is targeted to + capture all such delay parameters, providing a total application + endpoint delay. + + Application delay can be expressed as the time delay introduced + between the network interface and the application-level presentation. + Since it is difficult to envision usage of all sorts of applications, + + + + +Siddiqui, et al. Standards Track [Page 19] + +RFC 4710 RAQMON Framework October 2006 + + + the following guidance is provided to the implementers to measure the + application delay: + + - The sending end contribution to application delay is defined as the + sum of sample sequencing, accumulation, and encoding delay. + + - The receiving end contribution to application delay is calculated + as the sum of delays associated with buffering, play-out, packet- + sequencing, and decoding associated with the receiving direction, + if relevant. + + The endpoint application delay is defined as the sum of the receiving + and sending contributions to delay measured or estimated within the + endpoint that is generating this report. + + It is easy to recognize that applications running on an IP device can + experience same network delay but have different application- + associated delay values. As such, the user experience associated + with specific applications may vary while the network delay value + remains same for both the applications. + + Having network delay and application delay measurements available, a + management application can represent the delay experienced by the end + user at the application level as a sum of network delay and the + application delays reported from the endpoints. However, the + specification of such a management application is outside the scope + of the RAQMON specification. + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.14. Inter-Arrival Jitter + + The Inter-Arrival Jitter metric provides a short-term measure of + network congestion [RFC3550]. The jitter measure may indicate + congestion before it leads to packet loss. The inter-arrival jitter + field is only a snapshot of the jitter at the time when a RAQMON PDU + is generated and is not intended to be taken quantitatively as + indicated in [RFC3550]. Rather, it is intended for comparison of + inter-arrival jitter from one receiver over time. Such inter-arrival + jitter information is extremely useful to understand the behavior of + certain applications such as Voice over IP, Video over IP, etc. + Inter-arrival jitter information is also used in the sizing of play- + out buffers for applications requiring the regular delivery of + packets (for example, voice or video play-out). + + + + + +Siddiqui, et al. Standards Track [Page 20] + +RFC 4710 RAQMON Framework October 2006 + + + In [RFC3550], the selection function is implicitly applied to + consecutive packet pairs, and the "jitter estimate" is computed by + applying an exponential filter with parameter 1/16 to generate the + estimate (i.e., j_new = 15/16* j_old + 1/16*j_new). + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.15. IP Packet Delay Variation + + [RFC3393] provides guidance to several absolute jitter parameters. + RAQMON uses the [RFC3393] definition of the IP Packet Delay Variation + (ipdv) for packets inside a stream of packets. The IP Delay + Variation metric is used to determine the dynamics of queues within a + network (or router) where the changes in delay variation can be + linked to changes in the queue length processes at a given link or a + combination of links. Such a parameter provides visibility within an + IP Network and a better understanding of application-level + performance problems as it relates to IP Network performance. + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.16. Total Number of Application Packets Received + + This metric reports the number of application payload packets + received by the RDS as part of this session since the last RAQMON PDU + was sent up until the time this RAQMON PDU was generated. + + This parameter represents a very simple incremental counter that + counts the number of "application" packets that an RDS has received. + Application packets MAY include signaling packets. Since this count + is a snapshot in time, depending on application type, it also varies + based on the application states, e.g., an RDS within an application + session will report the aggregated number of application packets that + were sent out during signaling setup, media packets received, session + termination, etc. + + For example, during Voice over IP or Video over IP sessions setup, + this counter represents the number of signaling-session-related + packets that have been received that will be derived from the + relevant application signaling protocol stack such as SIP or H.323, + SIMPLE, and various other signaling protocols used by the application + to establish the communication session. + + + + + +Siddiqui, et al. Standards Track [Page 21] + +RFC 4710 RAQMON Framework October 2006 + + + However, during a period when media is established between the + communicating entities, this counter will be indicative of the number + of RTP Frames that have been sent out to the communicating party + since last PDU was sent out. The methodology described within RTCP + SR/RR reports [RFC3550] to count RTP frames will be applied wherever + applications use RTP. This being a cumulative counter, applications + need to take into consideration the possibility of the counter + overflowing and restarting counting from zero. + + Support for RTP can be determined by the support of the RTP MIB + [RFC2959] in the hosts running the applications or by inclusion of + the string 'RTP' at the beginning of the Application Name (Section + 5.32). + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.17. Total Number of Application Packets Sent + + This metric reports the number of signaling and payload packets sent + by the RDS as part of this session since the last RAQMON PDU was sent + until the time this RAQMON PDU was generated. Applications packets + MAY include signaling packets. Similar to the total number of + application packets received parameter in Section 5.16, this count is + a snapshot in time. Depending on the application type, the counter + also varies based on various application states, including packet + counts for signaling setup, media establishment, session termination + states, and so on. This being a cumulative counter, applications + need to take into consideration the possibility of the counter + overflowing and restarting counting from zero. + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.18. Total Number of Application Octets Received + + This metric reports the total number of signaling and payload octets + received in packets by the RDS as part of this session since the last + RAQMON PDU was sent, up until the time this RAQMON packet was + generated. Applications octets MAY include signaling octets. The + methodology described by [RFC3550] will be applied wherever + applications use RTP. This being a cumulative counter, applications + need to take into consideration the possibility of the counter + overflowing and restarting counting from zero. + + + + + +Siddiqui, et al. Standards Track [Page 22] + +RFC 4710 RAQMON Framework October 2006 + + + Support for RTP can be determined by the support of the RTP MIB + [RFC2959] in the hosts running the applications or by inclusion of + the string 'RTP' at the beginning of the Application Name (Section + 5.32). + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.19. Total Number of Application Octets Sent + + This metric reports the total number of signaling and payload octets + received in packets by the RDS as part of this session since the last + RAQMON PDU was sent, up until the time this RAQMON packet was + generated. This is similar to the Total Number of Application Octets + Received metric. Applications octets MAY include signaling octets. + The methodology described by [RFC3550] will be applied wherever + applications use RTP. This being a cumulative counter, applications + need to take into consideration the possibility of the counter + overflowing and restarting counting from zero. + + Support for RTP can be determined by the support of the RTP MIB + [RFC2959] in the hosts running the applications or by inclusion of + the string 'RTP' at the beginning of the Application Name (Section + 5.32). + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.20. Cumulative Packet Loss + + The cumulative packet loss metric indicates the loss associated with + the network as well as local device losses over time. This parameter + is counted as the total number of application packets from the source + that have been lost since the beginning of the session. This number + is defined to be the number of packets expected less the number of + packets actually received, where the number of packets received + includes the count of packets that are late or duplicates. If a + packet is discarded due to late arrival, then it MUST be counted as + either lost or discarded but MUST NOT be counted as both. + + Packet loss by the underlying transport network SHALL be measured + using the methodologies described in [RFC3550] for RTP traffic and + [RFC2680] for other IP traffic. The number of packets expected is + defined to be the extended last sequence number received, as defined + + + + + +Siddiqui, et al. Standards Track [Page 23] + +RFC 4710 RAQMON Framework October 2006 + + + next, less the initial sequence number received. For RTP traffic, + this may be calculated using techniques such as those shown in + Appendix A.3 of [RFC3550]. + + Packet loss by the underlying transport network SHALL be measured + using the methodologies described in [RFC3550] for RTP traffic and + [RFC2680] for other IP traffic. The number of packets expected is + defined to be the extended last sequence number received, as defined + next, less the initial sequence number received. For RTP traffic, + this may be calculated using techniques such as those shown in + Appendix A.3 of [RFC3550]. + + Support for RTP can be determined by the support of the RTP MIB + [RFC2959] in the hosts running the applications or by inclusion of + the string 'RTP' at the beginning of the Application Name (Section + 5.32). + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.21. Packet Loss in Fraction + + The Packet Loss in Fraction metric represents the packet loss as + defined above, but expressed as a fraction of the total traffic over + time. + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.22. Cumulative Application Packet Discards + + The RAQMON Framework allows applications to distinguish between + packets lost by the network and those discarded due to jitter and + other application-level errors. Though packet loss and discards have + an equal effect on the quality of the application, having separate + counts for packet loss and discards helps identify the source of + quality degradation. + + The packet discard metric indicates packets discarded locally by the + device over time. Local device-level packet discard is captured as + the total number of application-level packets from the source that + have been discarded since the beginning of reception, due to late or + early arrival, under-run or overflow at the receiving jitter buffer, + or any other application-specific reasons. + + + + + +Siddiqui, et al. Standards Track [Page 24] + +RFC 4710 RAQMON Framework October 2006 + + + If the RDS cannot tell the difference between discards and lost + packets, then it MUST report only lost packets and MUST NOT report + discards. + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.23. Packet Discards in Fraction + + The packet discards in fraction metric represents packets from the + source that have been discarded since the beginning of the reception + but expressed as a fraction of the total traffic over time. + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.24. Source Payload Type + + The source payload type reports payload formats (e.g., media + encoding) as sent by the data source, e.g., ITU G.711, ITU G.729B, + H.263, MPEG-2, ASCII, etc. This memo follows the definition of + Payload Type (PT) in [RFC3551]. For example, to indicate that the + source payload type used for a session is PCMA (pulse-code modulation + with A-law scaling), the value of the source payload field for the + respective session will be 8. + + The source payload type value is expected to remain constant for the + duration of a session, with the exception of events like dynamic + codec changes. RDSs SHOULD avoid sending these parameters within + RAQMON reports more often than necessary (e.g., at dynamic codec + changes) to ensure an efficient usage of network resources. + + If dynamic types (values 96 to 127, according to [RFC3551]) are being + used to identify the source payload type, a RAQMON extension + parameter MAY be defined to indicate the MIME subtypes. In the case + where the RDS does send reports noting dynamic codec changes, there + may be instances where this extension parameter is used only before + or after the codec change, as the source payload may shift between + the dynamic and static types. + +5.25. Receiver Payload Type + + The receiver payload type reports payload formats (e.g., media + encodings) as sent by the other communicating party back 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) in [RFC3551]. + + + +Siddiqui, et al. Standards Track [Page 25] + +RFC 4710 RAQMON Framework October 2006 + + + For example, to indicate that the destination payload type used for a + session is PCMA, the destination payload type field for the + respective session will be 8. + + The destination payload type value is expected to remain constant for + the duration of a session, with the exception of events like dynamic + codec changes. RDSs SHOULD avoid sending these parameters within + RAQMON reports more often than necessary (e.g., at dynamic codec + changes) to ensure an efficient usage of network resources. + + If dynamic types (values 96 to 127, according to [RFC3551]) are being + used to identify the destination payload type, a RAQMON extension + parameter MAY be defined to indicate the MIME subtypes. In the case + where the RDS does send reports noting dynamic codec changes, there + may be instances where this extension parameter is used only before + or after the codec change, as the destination payload may shift + between the dynamic and static types. + +5.26. 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. Many devices use that standard to mark + Ethernet frames according to IEEE P802.1p standard. Details on these + can be found in [IEEE802.1D], which incorporates P802.1p. The Source + Layer 2 Priority RAQMON field indicates what Layer 2 values were used + by the host running the RDS to prioritize these packets in the Local + Area Network environment. + + The Source Layer 2 Priority value is expected to remain constant for + the duration of a session. Hosts running the RDSs SHOULD avoid + sending these parameters within RAQMON reports too often in order to + ensure an efficient usage of network resources. + +5.27. Source TOS/DSCP Value + + Various Layer 3 technologies are in place to prioritize traffic in + the Internet. For example, the traditional IP Precedence [RFC791] + and Type of Service (TOS) [RFC1812], or more recent technologies like + Differentiated Services [RFC2474] [RFC2475], use the TOS octet in + IPv4, whereas the traffic class octet is used to prioritize traffic + in IPv6. Source Layer TOS/DCP RAQMON field reports the appropriate + Layer 3 values used by the Data Source to prioritize these packets. + + + + + + +Siddiqui, et al. Standards Track [Page 26] + +RFC 4710 RAQMON Framework October 2006 + + + The Source TOS/DSCP value is expected to remain constant for the + duration of a session. Hosts running the RDSs SHOULD avoid sending + these parameters within RAQMON reports too often in order to ensure + an efficient usage of network resources. + +5.28. Destination Layer 2 Priority + + The Destination Layer 2 Priority reports the Layer 2 value used by + the communication receiver to prioritize 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 whether the destination has used Layer 2 technologies like + IEEE P802.1p for priority queuing. + + The Destination Layer 2 Priority value is expected to remain constant + for the duration of a session. Hosts running the RDSs SHOULD avoid + sending these parameters within RAQMON reports too often in order to + ensure an efficient usage of network resources. + +5.29. Destination TOS/DSCP Value + + The Destination TOS/DSCP RAQMON field reports the 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 whether the destination has used any Layer 3 technologies + like IP Precedence [RFC791] and Type of Service (TOS) [RFC1812], or + more recent technologies like Differentiated Service [RFC2474] + [RFC2475]. + + The Destination TOS/DSCP value is expected to remain constant for the + duration of a session. Hosts running the RDSs SHOULD avoid sending + these parameters within RAQMON reports too often in order to ensure + an efficient usage of network resources. + +5.30. CPU Utilization in Fraction + + This parameter captures the CPU usage of the hosts running the RDSs + that may have very critical implications for QoS of an end-device. + It is computed as an average since the last reporting interval, and + corresponds to the percentage of that time that the CPU was busy. + + In the case of multiple CPU hosts, the maximum utilization among the + different CPUs MUST be reported. + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + + + + +Siddiqui, et al. Standards Track [Page 27] + +RFC 4710 RAQMON Framework October 2006 + + +5.31. Memory Utilization in Fraction + + This parameter captures the memory usage of the hosts running the + RDSs that may have very critical implications for QoS of an end- + device. It is computed as an average since the last reporting + interval and corresponds to the average percentage of the total + memory space critical for the applications in use during that time + interval (e.g., primary CPU RAM, buffers). + + In the case of multiple CPU hosts, the maximum memory utilization + among the different CPUs MUST be reported. + + This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the + capability of determining its value and if the parameter is relevant + for the application. + +5.32. Application Name/Version + + The Application Name/Version parameter gives the name and, + optionally, the 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. + + If the application is using RTP [RFC3550], the Application Name + SHOULD begin with the string 'RTP'. + + This parameter MUST be sent in the first RAQMON PDU. + +6. Report Aggregation and Statistical Data processing + + Within the RAQMON Framework, RRCs are expected to have significantly + greater computational resources than RDSs. Consequently, various + aggregation functions are performed by the RRCs, while RDSs are not + burdened by statistical data processing such as computation of + minima, maxima, averages, standard deviations, etc. + + The RAQMON MIB provides minimal aggregation of the RAQMON parameters + defined above. The RAQMON MIB is not designed to provide extensive + aggregation like the Application Performance Measurement (APM) MIB + [RFC3729] or the Transport Performance Metrics (TPM) MIB [RFC4150]. + One should use APM and TPM MIBs to aggregate parameters based on + protocols (e.g., performance of HTTP, RTP) or applications (e.g., + performance of VoIP, Video Applications). + + + + + + +Siddiqui, et al. Standards Track [Page 28] + +RFC 4710 RAQMON Framework October 2006 + + + In the RAQMON MIB, aggregation can be performed only on specific + RAQMON metric parameters. Aggregation always results in statistical + Mean/Min/Max values, according to these definitions: + + 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 can be + computed by summing of these N reported values, and then + dividing by N. + + Min: Min is defined as the statistical minimum of a metric over + the duration of a communication session. For example, if + the 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 smallest of the N end-to-end + delay metric values reported. + + Max: Max is defined as the statistical maximum of a metric over + the duration of a communication session. For example, if + the 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 largest of the N End-to-End + Delay metric values reported. + +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. + + Examples of how such storage space optimization can be performed + include: + + 1. Make data available through the MIB only at the end of a + communication session, i.e., upon receipt of a NULL PDU. The + aggregated data could be made available using the RAQMON MIB as + Mean, Max, or Min entries and saved for historical purposes. + + 2. Use a time-based algorithm that aggregates data over a specific + period of time within a communication session, thus requiring + fewer entries, to reduce storage space requirements. For + example, if an RDS sends data out every 10 seconds and the RRC + updates the RAQMON MIB once every minute, for every 6 data + points there would be one MIB entry. + + + + +Siddiqui, et al. Standards Track [Page 29] + +RFC 4710 RAQMON Framework October 2006 + + + 3. Periodically delete historical data in accordance with an + administrative policy. An example of such a policy would be to + delete historical data older than 60 days. The implementation + of such policies is left to the application developer's + discretion, and their use is an operational concern. + +8. Security Considerations + + Security considerations associated with the RAQMON Framework are + discussed below, and in greater detail in other RAQMON memos as is + appropriate. + +8.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 of possible exploits of RAQMON payload. + Possible exploits of RAQMON payloads fall within these classes: + + 1. Unauthorized examination of sensitive information in the + payload in transit. + + 2. Unauthorized modification of payload contents in transit, + leading to: + + a. Mis-identification of information from one RAQMON reporting + session as belonging to another destined to the same RRC; + + b. Mismapping of RAQMON sessions; + + c. Various forms of session-level denial-of-service (DoS) + attacks; + + d. DoS through modification of RAQMON parameter values and + statistics; + + e. Invalid timestamps, leading to false interpretation of the + monitored data, affecting call records information, and + making difficult to place monitoring events in their + appropriate temporal context. + + 3. Malformed payloads, permitting the exploitation of potential + implementation weaknesses to compromise an RRC. + + 4. Unauthorized disclosure of sensitive data carried by + application PDUs, leading to a breach of confidentiality. + + + + + +Siddiqui, et al. Standards Track [Page 30] + +RFC 4710 RAQMON Framework October 2006 + + + Consequently, threats based on unauthorized disclosure or + modification of payloads or headers will have to be assumed. + +8.2. The RAQMON Security Requirements and Assumptions + + In order to preserve integrity of the RAQMON PDU against these + threats, the RAQMON model must provide for cryptographically strong + security services. + + Consequently, the RAQMON framework must be able to provide for the + following protections: + + 1. Authentication - the RRC should be able to verify that a RAQMON + PDU was in fact originated by the RDS that claims to have sent + it. + + 2. Privacy - Since RAQMON information includes identification of + the parties participating in a communication session, the + RAQMON framework should be able to provide for protection from + eavesdropping, to prevent an unauthorized third party from + gathering potentially sensitive information. This can be + achieved by using various payload encryption technologies, such + as Data Encryption Standard (DES), 3-DES, Advanced Encryption + Standard (AES), etc. + + 3. Protection from DoS 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 + to 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 five-second reporting interval. Sessions + shorter than that should be stored in the RDS and will be + reported only after that interval has expired. + +8.3. RAQMON Security Model + + The RAQMON architecture permits the use of multiple transport + protocols. Most of these support a secure mode of operation. There + are advantages to relying on the security provided at the transport + protocol layer. + + 1. Transport-protocol-level security can generally protect the + payload with end-to-end authentication, confidentiality, + message integrity, and replay protection services. + + + +Siddiqui, et al. Standards Track [Page 31] + +RFC 4710 RAQMON Framework October 2006 + + + 2. A good cryptographic security protocol always has an associated + key management protocol. Use of transport protocol security + relies on its key management and does not require development + of another mechanism. + + 3. When transport protocol security is already enabled between the + RDS and RRC, additional encryption and message authentication + at the application level is avoided. + + However, there are also shortcomings to be noted in relying on + transport protocol security. + + 1. When session-level isolation of the different RAQMON sessions + of an RDS-RRC pair is required, it will be necessary to open + separate transport protocol instances. Such cases, however, + may be rare. + + 2. Since security services are not provided by the RAQMON + framework, the absence of transport or lower protocol security + implies the absence of RAQMON security. + +9. Acknowledgements + + The authors would like to thank Andy Bierman, Alan Clark, Mahalingam + Mani, Colin Perkins, Steve Waldbusser, Magnus Westerlund, and Itai + Zilbershtein for the precious advices and real contributions brought + to this document. The authors would also like to extend special + thanks to Randy Presuhn, who reviewed this document for spelling and + formatting purposes, and who provided a deep review of the technical + content. We also would like to thank Bert Wijnen for the permanent + coaching during the evolution of this document and the detailed + review of its final versions. + + + + + + + + + + + + + + + + + + + +Siddiqui, et al. Standards Track [Page 32] + +RFC 4710 RAQMON Framework October 2006 + + +10. Normative References + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC + 1812, June 1995. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, December + 1998. + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., + and W. Weiss, "An Architecture for Differentiated + Service", RFC 2475, December 1998. + + [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way + Delay Metric for IPPM", RFC 2679, September 1999. + + [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way + Packet Loss Metric for IPPM", RFC 2680, September 1999. + + [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round- + trip Delay Metric for IPPM", RFC 2681, September 1999. + + [RFC2819] Waldbusser, S., "Remote Network Monitoring Management + Information Base", STD 59, RFC 2819, May 2000. + + [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time + Transport Protocol Management Information Base", RFC + 2959, October 2000. + + [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay + Variation Metric for IP Performance Metrics (IPPM)", RFC + 3393, November 2002. + + [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations + for the Simple Network Management Protocol (SNMP)", STD + 62, RFC 3416, December 2002. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + + + +Siddiqui, et al. Standards Track [Page 33] + +RFC 4710 RAQMON Framework October 2006 + + + [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio + and Video Conferences with Minimal Control", STD 65, RFC + 3551, July 2003. + +11. Informative References + + [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. + + [RFC1305] Mills, D., "Network Time Protocol (Version 3) + Specification, Implementation and Analysis", RFC 1305, + March 1992. + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, + G., and E. Lear, "Address Allocation for Private + Internets", BCP 5, RFC 1918, February 1996. + + [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC + 2914, September 2000. + + [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly + Application Design Guidelines", RFC 3235, January 2002. + + [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control + Protocol Extended Reports (RTCP XR)", RFC 3611, November + 2003. + + [RFC3729] Waldbusser, S., "Application Performance Measurement + MIB", RFC 3729, March 2004. + + [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics + MIB", RFC 4150, August 2005. + + [RFC4711] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real- + time Application Quality-of-Service Monitoring (RAQMON) + MIB", RFC 4711, October 2006. + + [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Ramhman, + M., and Y. Kim, "Transport Mappings for Real-time + Application Quality-of-Service Monitoring (RAQMON) + Protocol Data Unit (PDU)", RFC 4712, October 2006. + + + + +Siddiqui, et al. Standards Track [Page 34] + +RFC 4710 RAQMON Framework October 2006 + + + [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). Revision. This is a revision of ISO/IEC + 10038: 1993, 802.1j-1992 and 802.6k-1992. It + incorporates P802.11c, P802.1p and P802.12e [ANSI/IEEE + Std 802.1D, 1998 Edition] + +Authors' Addresses + + Anwar A. Siddiqui + Avaya Labs + 307 Middletown Lincroft Road + Lincroft, New Jersey 07738 + USA + + Phone: +1 732 852-3200 + EMail: anwars@avaya.com + + + Dan Romascanu + Avaya + Atidim Technology Park, Building #3 + Tel Aviv, 61131 + Israel + + Phone: +972-3-645-8414 + EMail: dromasca@avaya.com + + + Eugene Golovinsky + + EMail: gene@alertlogic.net + + + + + + + + + + + + + + + + + +Siddiqui, et al. Standards Track [Page 35] + +RFC 4710 RAQMON Framework October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Siddiqui, et al. Standards Track [Page 36] + |