Network Working Group A. Siddiqui
Request for Comments: 4710 D. Romascanu
Category: Standards Track Avaya
E. Golovinsky
Alert Logic
October 2006
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
实时应用程序服务质量监控（RAQMON）框架
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
需要监控终端设备，如IP电话、寻呼机、即时消息客户端、移动电话和各种其他手持计算设备。本备忘录扩展了远程网络监控（RMON）系列规范，以允许对这些设备上运行的各种应用程序进行实时服务质量（QoS）监控，并允许使用简单网络管理协议（SNMP）将此信息与RMON系列集成。本备忘录定义了应用程序实时QoS监控的框架、体系结构、相关指标和传输要求。
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
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
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].
随着互联网的发展和嵌入式技术的进步，智能IP设备（如IP电话、寻呼机、即时消息客户端、移动电话、无线手持设备和各种其他计算设备）已成为我们日常运营的组成部分。企业运营商、信息技术（IT）经理、应用程序服务提供商、网络服务提供商等需要监控这些应用程序和设备类型，以确保满足最终用户服务质量（QoS）目标。本备忘录描述了这些环境的监控解决方案，扩展了远程网络监控（RMON）规范系列[RFC2819]。这些扩展支持对上述终端设备上运行的典型应用程序进行实时QoS监控，并允许通过SNMP[RFC3416]使用熟悉的RMON规范系列集成这些信息。
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.
实时应用程序QoS监控框架（RAQMON）允许终端设备和应用程序实时报告QoS统计信息。许多实时应用程序（以及在RMON规范系列中管理的非实时应用程序）可以使用本备忘录中概述的RAQMON框架实时报告应用程序级QoS统计信息。一些可能的应用场景包括IP语音、IP传真、IP视频、即时消息（IM）、电子邮件、软件下载应用程序、电子商务风格的交易、手持计算设备的web访问等应用。
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.
在IP终端设备上运行的应用程序的用户体验取决于用户正在运行的应用程序类型以及该应用程序可用的周围资源。端到端应用程序QoS体验是各种应用程序级事务和可用网络和主机资源的复合效应。例如，IP语音（VoIP）呼叫的端到端用户体验取决于建立呼叫所需的总时间以及媒体相关性能参数，如端到端网络延迟、抖动、数据包丢失和呼叫中使用的编解码器类型。VoIP呼叫的性能还受到网络协议行为的影响，如保留协议（RSVP）、区分服务中的显式标记（DiffServ）[RFC2475]或IEEE 802.1[IEEE802.1D]，以及呼叫进行时其他应用程序使用的可用主机资源，如设备CPU或内存。
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
端到端应用程序服务质量（QoS）体验是应用程序上下文敏感的。例如，IP电话应用程序报告的参数类型对于其他应用程序（如即时消息传递）可能并不真正需要。RAQMON框架
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.
通过提供从预定义列表中报告度量子集的机制，提供了一种报告适合于特定应用程序上下文的端到端QoS体验的机制。
In order to facilitate a complete end-to-end view, RAQMON correlates statistics that involve:
为了促进完整的端到端视图，RAQMON将涉及以下内容的统计数据关联起来：
i. "User, Application, Session"-specific parameters (e.g., session setup time, session duration parameters based on application context).
i. “用户、应用程序、会话”-特定参数（例如，会话设置时间、基于应用程序上下文的会话持续时间参数）。
ii. "IP end-device"-specific parameters during a session (e.g., CPU usage, memory usage).
二、“IP终端设备”-会话期间的特定参数（例如CPU使用率、内存使用率）。
iii. "Transport network"-specific parameters during a session (e.g., end-to-end delay, one-way delay, jitter, packet loss etc).
iii.“传输网络”-会话期间的特定参数（例如，端到端延迟、单向延迟、抖动、数据包丢失等）。
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:
在任何给定点，这些设备上的应用程序都可以关联这些不同的数据并报告端到端性能。本备忘录中指定的RAQMON框架提供了一种报告这种端到端QoS视图的机制，并将这种视图集成到RMON规范系列中。具体而言，RAQMON框架规定了以下内容：
a. A set of basic metrics sent as reports between the RAQMON entities using for transport existing Internet Protocols such as TCP or SNMP.
a. 在RAQMON实体之间作为报告发送的一组基本指标，用于传输现有的Internet协议，如TCP或SNMP。
b. Requirements to be met by the underlying transport protocols that carry the RAQMON reports.
b. 承载RAQMON报告的基础传输协议需要满足的要求。
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.
c. 管理信息库（MIB）的一部分，作为RMON MIB模块的扩展，用于Internet社区中的网络管理协议。
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.
本备忘录提供了RAQMON功能架构、RAQMON实体定义和要求、传输协议要求、一组指标以及RAQMON报告的信息模型。
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).
补充备忘录将描述基本RAQMON指标到不同传输协议的映射。在PDU协议的简单网络传输（RFU）和PDU协议的简单网络传输（RFU）定义的示例中，提供了PDU协议的简单网络传输（RFU）定义。
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.
RAQMON MIB[RFC4711]备忘录描述了在Internet社区中与SNMP协议一起使用的管理信息库（MIB）。该文件建议对远程监控MIB[RFC2819]进行扩展，以适应RAQMON解决方案。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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框架通过提供最终用户体验到的应用程序性能信息，扩展了在RMON MIB[RFC2819]中创建的体系结构。RAQMON体系结构基于以下三个功能组件：
- RAQMON Data Source (RDS)
- RAQMON数据源（RDS）
- RAQMON Report Collector (RRC)
- RAQMON报告收集器（RRC）
- RAQMON MIB Structure
- RAQMON-MIB结构
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.
RAQMON数据源（RDS）是一个功能组件，用作监控目的的数据源。IP电话、手机和寻呼机等终端设备，以及即时消息客户端、PC中的软电话等应用程序客户端，都被设想为RAQMON框架中的RDS。
+----------------------+ +---------------------------+
| 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|
+------------------+ +------------------+ +------------+
+----------------------+ +---------------------------+
| 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-RAQMON框架。
(1) Communication Session between real-time applications
(1) 实时应用程序之间的通信会话
(2) Context-Sensitive Metrics
(2) 上下文敏感度量
(3) Device State Specific Metrics
(3) 设备状态特定度量
(4) Reporting session - RAQMON metrics transmitted over specified interfaces (Specific Protocol Interface, IP Address, port)
(4) 报告会话-通过指定接口（特定协议接口、IP地址、端口）传输的RAQMON度量
(5) Management Application - RRC interaction using the RAQMON MIB
(5) 管理应用程序-使用RAQMON MIB的RRC交互
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.
RAQMON报表收集器（RRC）从多个RDS收集统计信息，对其进行分析，并适当地存储这些信息。RRC被设想为一个网络服务器，服务于网络管理员定义的管理域。RAQMON体系结构的RRC组件被设想为计算资源丰富。只有RRC应该实现RAQMON MIB模块。
The RAQMON Management Information Base (RAQMON MIB) extends the Remote Monitoring MIB [RFC2819] to accommodate the RAQMON Framework and exposes End-to-End Application QoS information to Network Management Applications.
RAQMON管理信息库（RAQMON MIB）扩展了远程监控MIB[RFC2819]以适应RAQMON框架，并向网络管理应用程序公开端到端应用程序QoS信息。
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".
RAQMON数据源（RDS）是用于监控目的的数据源。RDS监控功能在通信会话期间实时执行。RDS实体捕获此类通信会话的QoS属性，并在RAQMON“报告会话”中报告它们。
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.
RDS主要负责抽象RAQMON体系结构中的IP端设备和应用程序。它收集特定通信会话的参数，并将其转发给相应的RAQMON报告收集器（RRC）。由于预期RDS功能将通过编写运行在潜在小型、低功耗终端设备上的固件/软件来实现，因此RDS元件的设计为此进行了优化。与路由和管理协议的实现类似，终端设备中的RDS实现通常在后台执行，而不是在数据转发路径中执行。
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.
RDS使用推送机制来报告QoS参数。当运行在RDS上的应用程序决定适用于应用程序上下文的PDU内容时，RDS异步向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.
PDU从RDS发送到RRC的速率由应用程序的管理域策略控制。虽然此机制提供了收集IT经理和系统管理员所需的详细端到端经验的灵活性，但应遵循某些步骤以拥塞安全的方式操作RAQMON。第3节介绍了拥塞安全操作所需的步骤。
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.
RDS报告单工流的QoS统计信息。在给定实例中，来自RDS的报告在逻辑上被视为与报告RDS感知的通信会话相关联的QoS参数的集合。例如，如果两个IP电话用户Alice和John参与通信会话，则IP电话用户Alice所经历的端到端延迟可能与IP电话用户John所经历的端到端延迟不同，原因有多种。因此，来自Alice IP电话的报告表示驻留在Alice IP电话中的RDS感知到的该呼叫的QoS性能。
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.
1. RAQMON数据源应从该设备中的多个应用程序收集报告，并在给定时刻发送与多个通信会话相关的复合QoS报告。
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.
示例包括承载多个不同会议呼叫的会议桥或由音频/视频会话组成的两方视频呼叫。在每种情况下，RDS都可以发送一份RAQMON报告，该报告由多个子报告组成，这些子报告与音频和视频会话或每个电话会议的子报告相关。
2. RAQMON Data Sources MUST implement the TCP transport and MAY implement the SNMP transport.
2. RAQMON数据源必须实现TCP传输，并且可以实现SNMP传输。
In order to report statistics to RAQMON Report Collectors, RDSs will need to be configured with the following parameters:
为了向RAQMON报告收集器报告统计信息，需要使用以下参数配置RDS：
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.
1. RAQMON PDU之间的时间间隔。必须配置此参数，以避免在连续传输之间PDU内的任何RAQMON参数溢出。
2. The IP address and port of target RRC.
2. 目标RRC的IP地址和端口。
An RDS may use manual configuration for the RDS configuration parameters using command line interface (CLI), Telephone User Interface (TUI), etc.
RDS可以使用命令行界面（CLI）、电话用户界面（TUI）等手动配置RDS配置参数。
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.
- RDS充当普通文件传输协议（TFTP）客户端，下载文本脚本以读取参数。-RDS充当动态主机配置协议（DHCP）客户端，并作为DHCP选项获取RRC寻址信息。-RDS充当DNS客户端并从DNS服务器获取目标收集器信息。-RDS充当LDAP客户端并使用目录查找。
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.
确定要使用的DHCP选项和结构、在DNS中定义配置信息的结构或定义LDAP模式可以作为未来工作的一部分进行探讨。
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.
遵守RAQMON规范不需要使用上述任何特定配置机制。留给实现者为系统选择合适的供应机制。
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.
RAQMON报告收集器（RRC）从多个RDS接收RAQMON PDU，并在RAQMON MIB中分析和存储信息。RRC被设想为计算资源丰富，为一组RDS提供存储和聚合点。
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.
由于RDS可以属于单独的管理域，RAQMON框架允许RDS向单独的RRC报告QoS参数。供应商可以开发一个管理应用程序，以跨多个管理域关联驻留在不同RRC中的信息，以表示一个通信会话。但是，这种应用程序级规范超出了本备忘录的范围。
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).
1. RAQMON报告收集器必须支持[RFC4712]中定义的RAQMON信息模型在TCP上的强制映射，以便从RAQMON数据源（RDS）接收RAQMON报告。
2. RAQMON Report Collectors MAY support the optional mapping over SNMP notifications of the RAQMON information model defined in [RFC4712].
2. RAQMON报告收集器可能支持[RFC4712]中定义的RAQMON信息模型的SNMP通知上的可选映射。
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.
3. RAQMON报表收集器必须实现会话超时机制，以假定在合理的时间段内未报告的RDS的报告结束。此类超时参数应在供应商实现中配置，作为部署时的可编程参数。
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.
4. RAQMON报告收集器必须支持RAQMON-MIB模块，并满足[RFC4711]中所述的raqmonCompliance module-compliance定义的合规性要求。带有性能监视信息的RAQMON MIB的填充独立于传输协议，或用于在rds和rrc之间传输信息的协议。
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.
RAQMON定义了一组描述应用程序QoS的基本指标，如RAQMON数据源所报告的。本备忘录第5节定义了这组基本指标。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.
特定的应用程序、新型的网络设备或测量和描述应用程序QoS的新方法要求信息模型具有可扩展性。为了满足这一需求，设计了信息模型，以便供应商可以通过添加新的度量来扩展它。
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].
尽管RAQMON一致性不需要信息模型的扩展，但它可以为特定的应用程序提供有用的信息。可以扩展基本RAQMON信息模型的一个度量示例是[RFC3611]中定义的VoIP度量报告块中包含的VoIP媒体监控和呼叫质量的详细度量。
The RAQMON Information model is expressed by defining a conceptual RAQMON Protocol Data Unit (PDU).
RAQMON信息模型通过定义概念上的RAQMON协议数据单元（PDU）来表示。
A RAQMON Protocol Data Unit (PDU) is a common data format understood by RDSs and RRCs. A RAQMON PDU does not transport application data but rather occupies the place of a payload specification at the application layer of the protocol stack. 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.
RAQMON协议数据单元（PDU）是RDS和RRCs可以理解的通用数据格式。RAQMON PDU不传输应用程序数据，而是在协议栈的应用程序层占据有效负载规范的位置。不同的传输映射可用于在RDS和RRC之间传输RAQMON PDU。本备忘录第2.4节定义了运输协议要求。
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.
虽然RAQMON PDU在概念上是作为单个PDU构建的，但在功能上分为两个不同的部分。它们是应用程序、供应商和设备特定扩展所需的基本部分和特定于应用程序的扩展。
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
RAQMON PDU的基本部分：RAQMON PDU的基本部分遵循SMI网络管理私有企业代码0，表示IETF标准构造。RAQMON PDU基本部分提供了第5节中定义的QoS参数预定义列表中的条目类型，并允许应用程序为这些参数填写适当的值。应用程序开发人员还可以灵活地生成RDS报告，该报告仅包含中列出的参数子集
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.
第5节。无需在每个PDU中携带所有指标；此外，建议仅在启动会话或应用程序时，然后以较大的时间间隔发送给定会话或应用程序的静态或伪静态度量，这些度量不会改变或很少改变。
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.
RAQMON PDU的应用程序部分：由于很难构建满足所有应用程序需求的基本部分，RAQMON提供了扩展功能，以传递应用程序、供应商和设备特定参数，供将来使用。应用程序开发人员或供应商可以在PDU的应用程序部分的有效负载中定义其他参数。RAQMON PDU应用程序部分定义的所有者由中定义的供应商SMI网络管理私有企业代码表示http://www.iana.org/assignments/enterprise-numbers. 此类特定于应用程序的扩展应由应用程序供应商维护和发布。
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).
尽管RDS和RRC被设计为在整个报告会话中是无状态的，但框架需要报告结束的指示。为此，RDS必须发送RAQMON NULL PDU。空PDU是包含所有空值（即，无需报告）的RAQMON PDU。
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.
RAQMON PDU依赖于基础协议来提供传输功能和传输协议的其他属性，例如，传输可靠性、重新传输、纠错、长度指示、拥塞安全、碎片/碎片整理，RAQMON数据包的最大长度仅受底层协议的限制。
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.
1. 传输协议应允许RDS轻量级实现。RDS将在设备资源有限的低功耗嵌入式设备上实现。
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.
2. 可伸缩性-由于RRC需要与大量（数十个、数百个或更多）的RDS交互，因此需要传输协议的可伸缩性。
3. Congestion safety - as per [RFC2914]. See also Section 3.
3. 拥塞安全-根据[RFC2914]。另见第3节。
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.
4. 安全性-由于RAQMON统计数据可能携带敏感的系统信息，需要在传输过程中防止未经授权的披露和修改，因此需要一种提供强安全模式或允许应用数据加密和完整性的传输协议。
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.
5. NAT友好-传输协议应符合[RFC3235]，以便RDS可以通过防火墙/网络地址转换设备与RRC通信。
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.
6. 传输协议可以实现会话超时机制，以假设在合理的持续时间内没有报告的RDS的报告结束。此类超时参数应在供应商实施中可配置，在部署时可编程。
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.
7. 可靠性-RAQMON框架期望PDU在有损网络中运行。但是，为了保持设计的简单性，RAQMON框架中不包括重传。如果需要重新传输，RAQMON可以通过传输协议（如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.
将来，如果RAQMON PDU要在提供连续八位组流而不是消息（数据包）抽象的基础协议中进行，则必须定义RAQMON数据包的封装以提供成帧机制。如果基础协议包含填充，因此无法确定RAQMON有效负载的范围，则还需要帧。本文件中未定义任何框架机制。在一个网络或传输数据包中携带多个RAQMON数据包可以减少报头开销。
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).
类似[RFC4712]的进一步备忘录描述了如何通过传输控制协议（TCP）或简单网络管理协议（SNMP）等现有协议传输PDU。
RAQMON PDUs can be transmitted over multiple transport protocols. The RAQMON Framework will be congestion safe, if a RAQMON PDU is transported over TCP.
RAQMON PDU可以通过多种传输协议传输。如果RAQMON PDU通过TCP传输，则RAQMON框架将是拥塞安全的。
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.
拥塞感知问题的一个解决方案是完全不鼓励RAQMON使用UDP。尽管RAQMON PDU可以通过TCP传输，但在实际部署中，像TCP上的SNMP这样的传输并不常见。
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.
UDP的使用本质上增加了网络拥塞问题的风险，因为UDP本身没有定义拥塞预防、避免、检测或纠正机制。UDP的基本问题是，它没有提供反馈机制，允许发送方根据网络的实际性能调整传输速度。虽然这往往对极低容量的发送方-接收方对没有显著影响，但高容量关系对网络的影响可能非常严重。这个问题可能会因UDP级别上的大型RAQMON PDU碎片化而进一步恶化。诸如DCCP之类的传输协议也可以用作底层RAQMON PDU传输，它提供了具有拥塞控制的UDP样式数据报传输的灵活性。
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:
应注意的是，拥塞问题不仅存在于RDS和RRC对之间，而且只要扇入率较高，就会发生拥塞（例如，许多RDS向RRC报告）。在使用UDP作为传输的RAQMON框架内，可以通过以下方式实现拥塞安全：
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.
1. 恒定传输速率：在管理良好的网络中，恒定传输速率策略（例如，每N秒每个设备1个RAQMON PDU）将确保拥塞安全，因为设备以受控方式引入网络。例如，在企业网络中，IP电话是以受控的方式添加的，恒定的传输速率策略足以确保拥塞安全运行。配置的速率需要与设备的预期峰值数相关。最坏的情况是，如果RDS强制执行管理策略，其中最大PDU传输速率不超过每两分钟一个RAQMON PDU，则基于UDP的实现可以与基于TCP的实现一样具有拥塞安全性。这样的策略可以在配置RDS时强制实施，并且恒定速率的计时器需要随机抖动。
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
2. 单个未完成的请求：这种方法要求在应用程序级别发送请求，然后等待某种响应，表明在发送任何其他请求之前已收到请求。这产生了一种被一些人称为“乒乓球”的效果：流量在两个节点之间来回反弹，就像比赛中的乒乓球一样。由于在任何给定的时间内，任何两名球员之间只有一个球在打球，因此大多数可能出现的拥挤级联现象都被消除了。出于可靠性和效率的原因，此技术必须包括回退重传。例如，如果通过UDP使用SNMP INFORM PDU传输RAQMON PDU，则RDS应处理来自RRC的SNMP响应以实现此机制。[RFC4712]指定
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.
如果实现了SNMP通知传输映射机制，建议使用INFORM PDU，而不建议使用Trap PDU。
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.
这种调整或序列化方法的副作用是显著降低最大吞吐量，因为一次只能在一个方向上进行传输，并且传输之间至少存在2xRTT（往返时间）延迟。已经开发了更复杂的算法（如TCP和流控制传输协议（SCTP）中的算法）来解决这个问题，在应用程序级别重复这项工作是不合适的。因此，如果需要比这种简单方法更高的效率，那么实现者应该使用TCP、SCTP或其他类似协议。但是，如果必须使用UDP，这种方法是有效的。它还被用于其他应用场景，如UDP上的SIP。
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.
3. 通过将传输限制为最大传输单元（MTU）大小：RDS可能会面临使用UDP作为传输的大型消息传递请求。这类消息的碎片化在几个方面存在问题。任何片段的丢失都需要超时并重新传输消息。片段通常以本地接口（通常是LAN）速率从接口传输出去，而不知道干预的网络条件。由于这些原因，通常认为通过UDP发送大型PDU是一种不好的做法。如果已知MTU大小，作为一种实现，RDS不应允许应用程序通过限制UDP上传输的大小来减少碎片的影响，从而发送更多信息。作为替代方案，RDS还可以通过多个RAQMON PDU向RRC发送参数，但将其标识为具有完全相同的网络时间协议（NTP）[RFC1305]时间戳的同一RAQMON报告会话的一部分。
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.
虽然链路的实际MTU可能未知，但通常的实践似乎表明RDS本地接口MTU可能是合理的“近似值”。如果实际路径MTU已知，则应使用该值。
4. Irrespective of choice of transport protocol, it is also RECOMMENDED that no more than 10% network bandwidth be used for RDS/RRC reporting. More frequent reports from an RDS to RRC would imply requirements for higher network bandwidth usage.
4. 无论选择何种传输协议，也建议RDS/RRC报告使用不超过10%的网络带宽。RDS向RRC更频繁地报告意味着需要更高的网络带宽使用率。
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节中定义的任何QoS参数。测量算法留给实施者和设备供应商选择。有许多不同的测量方法可用于测量应用程序性能。这些方法包括基于探针、基于客户端、合成事务和其他方法。本规范不强制规定特定的方法，并对满足最低要求的任何方法开放。为了符合本规范，要求收集的数据与本文描述的语义相匹配。但是，建议供应商尽可能使用IETF定义的和国际电信联盟（ITU）指定的方法来测量参数。
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.
RAQMON PDU的基本部分提供了应用程序经常使用的预定义参数列表，用于描述端到端应用程序的服务质量。本节通过参考现有IETF、ITU和其他标准组织的文件，定义了RAQMON PDU基本部分中包含的一组简单指标。度量定义中包括适当的IETF或ITU参考。
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.
如前所述，RAQMON PDU还包含一个特定于应用程序的部件，其中未包含在基本部件中的特定于应用程序和供应商的信息可以作为<Name，Value>对或变量绑定列表添加。这些由供应商或其他组织独立管理的扩展应该发布以实现更广泛的互操作性。
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.
应用程序不需要报告本节中提到的所有参数，但应该能够灵活地报告适用于应用程序上下文的这些参数的子集。备忘录进一步确定了RDS需要包含在所有PDU中以符合要求的参数，以及RDS可能根据需要报告的可选参数。此处给出的定义旨在为实施者提供指导，并为每个度量提供IETF度量定义参考。应用程序开发人员应选择适合其应用程序需求的度量标准。[RFC4712]规范中提供了此处确定的参数的语法表示。
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].
数据源地址（DA）是数据源的地址。这可以是全局唯一的IPv4或IPv6地址，也可以是[RFC1918]中定义的专用IPv4分配地址。
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.
预期DA将在给定通信会话内保持恒定。RDS应避免在RAQMON报告中过于频繁地发送这些参数，以确保网络资源的有效利用。
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].
接收方地址（RA）采用与数据源地址（DA）相同的形式，但表示接收方地址。在通信会话中，报告RDS应填写另一方的地址作为接收方地址。与数据源地址一样，这可以是全局唯一的IPv4或IPv6地址，也可以是[RFC1918]中定义的专用IPv4地址。
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.
预期接收器地址（RA）将在给定通信会话内保持恒定。RDS应避免在RAQMON报告中过于频繁地发送这些参数，以确保网络资源的有效利用。
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:
数据源名称（DN）项可以是应用程序所需的各种格式。DN可以采用的形式包括但不限于：
- "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.
- "user@host，或“主机”，如果用户名在单用户系统上不可用。对于这两种格式，“主机”是有效负载来源主机的完全限定域名，按照[RFC1034]、[RFC1035]和[RFC1123]第2.1节中规定的规则进行格式化。使用的示例名称是“大”-guy@example.com或者“大”-guy@192.0.2.178“对于多用户系统。在没有用户名的系统上，例如“ip-phone4630.example.com”。建议不要通过DN参数报告标准主机的数字地址，因为DA参数用于此目的。
- 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.
- DN的另一个实例可以是有效的E.164电话号码、SIPURI或任何其他形式的电话或寻呼机号码。电话号码的格式应为加号，以取代国际接入码。例如：“+44-116-496-0348”表示英国的数字。
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.
DN值应在会话期间保持不变。RDS应避免在RAQMON报告中过于频繁地发送这些参数，以确保网络资源的有效利用。
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.
接收方名称（RN）的形式与DN相同，但表示接收方的名称。在通信会话中，应用程序应提供与之通信的另一方的名称作为RN。
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.
RN值预计在会话期间保持不变。RDS应避免在RAQMON报告中过于频繁地发送这些参数，以确保网络资源的有效利用。
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.
此参数表示应用程序在通信中用于特定会话或子会话的源端口。端口的示例包括TCP端口或UDP端口，如会话启动协议（SIP）、利用即时消息和状态扩展的SIP（SIMPLE）、H.323、RTP、超文本传输协议（HTTP）等通信应用程序协议所使用的端口。
This parameter MUST be sent in the first RAQMON PDU.
此参数必须在第一个RAQMON PDU中发送。
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.
此参数表示应用程序用于特定会话或子会话的接收器端口。端口的示例包括TCP端口，或通信应用程序协议（如SIP、SIMPLE、H.323、RTP、HTTP等）使用的UDP端口。
This parameter MUST be sent in the first RAQMON PDU.
此参数必须在第一个RAQMON PDU中发送。
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].
如果应用程序有设置阶段，则此参数提供启动设置的时间；如果不存在此设置阶段，则提供启动会话的时间。时间使用网络时间协议（NTP）的时间戳格式表示，相对于1900年1月1日的0h UTC（协调世界时），时间以秒为单位[RFC1305]。
This parameter SHOULD be sent only in the first RAQMON PDU, after the session setup is completed.
此参数应仅在会话设置完成后的第一个RAQMON PDU中发送。
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.
会话设置延迟度量报告从主机/端点发起的发起请求到建立的媒体路径（或从远程主机/端点接收的会话进度指示）所花费的时间，以毫秒为单位。例如，在VoIP系统中，会话设置时间可以测量为从最后一个DTMF（双音多频）按钮按下到第一个回铃音（指示远端正在振铃）之间的间隔。另一个例子是SIP呼叫的会话设置延迟，该延迟被测量为从用户代理生成INVITE到接收到200ok之间经过的时间。
This parameter SHOULD be sent only in the first RAQMON PDU, after the session setup is completed.
此参数应仅在会话设置完成后的第一个RAQMON PDU中发送。
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.
会话持续时间度量报告会话或子会话持续的时间。此度量是应用程序上下文敏感的。例如，VoIP呼叫会话持续时间可以测量为呼叫拾取和呼叫终止之间的经过时间，包括会话设置时间。
This parameter SHOULD be sent only in the first RAQMON PDU, after the session is terminated.
此参数应仅在会话终止后的第一个RAQMON PDU中发送。
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.
会话设置状态度量用于报告会话的通信状态。其值标识适当的通信会话状态，例如呼叫进行、呼叫成功建立、“尝试”、“振铃”、“重新尝试”、“RSVP保留失败”等。
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.
会话设置状态在应用程序上下文中是有意义的。因此，应用程序应将此指标与第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.
此参数应在会话状态的每次更改后发送。
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.
在[RFC3550]中为通过RTP运行的应用程序定义的往返端到端网络延迟，以及在[RFC2681]中为所有其他IP应用程序定义的往返端到端网络延迟，是应用程序QoS监控的关键指标。如果主机之间的端到端延迟相对于某个阈值较大，则某些应用程序的性能不好（或根本不好）。延迟值的不稳定变化使其难以（或不可能）支持许多实时应用，如IP语音、IP视频、IP传真等。
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.
底层传输网络的往返端到端网络延迟使用[RFC3550]中描述的RTP方法和[RFC2681]中描述的其他IP应用方法进行测量。
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.
注意，在一些方法中用于测量的数据包可能与用于媒体的数据包类型不同（例如，ICMP而不是RTP），因此可能在路由和队列优先级方面有所不同。这可能导致测量的延迟与介质路径上经历的延迟不同。此度量的一致性要求使用实际的应用程序数据包或相同应用程序类型的数据包。
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).
对RTP的支持可以通过运行应用程序的主机中的RTP MIB[RFC2959]的支持来确定，或者通过在应用程序名称的开头包含字符串“RTP”（第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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
单向端到端网络延迟[RFC2679]度量报告从源到目标网络接口的通信遇到的单向端到端延迟。IP性能度量（IPPM）工作组[RFC2679]确定的单向延迟测量将用于测量单向端到端网络延迟。
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.
对这种度量的需要源于这样一个事实，即从源到目的地的路径可能不同于从目的地返回到源的路径（“非对称路径”），从而不同的路由器序列用于正向和反向路径。因此，往返测量实际上同时测量两条不同路径的性能。
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).
独立测量每条路径突出了两条路径之间的性能差异，这两条路径可能穿越不同的互联网服务提供商，甚至是完全不同类型的网络（例如，研究网络与商品网络，或ATM（异步传输模式）与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 than on the direction in which acknowledgements travel.
即使这两条路径是对称的，由于非对称排队，它们也可能具有完全不同的性能特征。应用程序的性能可能主要取决于一个方向上的性能。例如，使用TCP的文件传输可能更多地取决于数据流动方向的性能，而不是确认的传播方向。
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.
在支持QoS的网络中，一个方向的供应可能与反向的供应完全不同，因此QoS保证不同。独立测量路径可以验证两种保证。
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).
RAQMON不应通过假设互联网路径是对称的（即，将往返延迟除以二）来推导单向端到端网络延迟。
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.
注意，在一些方法中用于测量的数据包可能与用于媒体的数据包类型不同（例如，ICMP而不是RTP），因此可能在路由和队列优先级方面有所不同。这可能导致测量的延迟与介质路径上经历的延迟不同。此度量的一致性要求使用实际的应用程序数据包或相同应用程序类型的数据包。
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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
如第5.11和5.12节所述，各种网络延迟版本不包括终端设备中与缓冲、播放、分组排序、编码/解码等相关的延迟。本节中定义的应用程序延迟度量旨在捕获所有此类延迟参数，从而提供总的应用程序端点延迟。
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,
应用程序延迟可以表示为网络接口和应用程序级表示之间引入的时间延迟。由于很难想象各种应用程序的使用情况，
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.
很容易认识到，在IP设备上运行的应用程序可能会经历相同的网络延迟，但与应用程序相关的延迟值不同。因此，与特定应用相关联的用户体验可能不同，而对于这两个应用，网络延迟值保持相同。
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.
在网络延迟和应用程序延迟测量可用的情况下，管理应用程序可以将最终用户在应用程序级别经历的延迟表示为网络延迟和从端点报告的应用程序延迟的总和。但是，此类管理应用程序的规范不在RAQMON规范的范围内。
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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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).
到达间抖动度量提供了网络拥塞的短期度量[RFC3550]。抖动度量可能在导致分组丢失之前指示拥塞。到达间抖动字段仅是生成RAQMON PDU时抖动的快照，不打算按照[RFC3550]中的指示进行量化。相反，它旨在比较一个接收机随时间的到达间抖动。此类到达间抖动信息对于理解某些应用（如IP语音、IP视频等）的行为非常有用。对于需要定期传送数据包（例如，语音或视频播放）的应用，到达间抖动信息还用于调整播放缓冲区的大小。
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).
在[RFC3550]中，选择函数隐式地应用于连续分组对，并且通过应用具有参数1/16的指数滤波器来计算“抖动估计”，以生成估计（即，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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
[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.
[RFC3393]为几个绝对抖动参数提供指导。RAQMON对数据包流中的数据包使用IP数据包延迟变化（ipdv）的[RFC3393]定义。IP延迟变化度量用于确定网络（或路由器）内队列的动态，其中延迟变化的变化可以链接到给定链路或链路组合处队列长度过程的变化。这样的参数提供了IP网络内的可视性，并更好地理解与IP网络性能相关的应用程序级性能问题。
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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
此度量报告自上次RAQMON PDU发送以来，RDS作为此会话的一部分接收的应用程序有效负载数据包的数量，直到生成此RAQMON PDU为止。
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.
此参数表示一个非常简单的递增计数器，用于统计RDS已接收的“应用程序”数据包的数量。应用分组可以包括信令分组。由于此计数是时间上的快照，取决于应用程序类型，它也根据应用程序状态而变化，例如，应用程序会话中的RDS将报告在信令设置、接收的媒体包、会话终止等期间发送的应用程序包的聚合数量。
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.
例如，在IP语音或IP视频会话设置期间，该计数器表示已接收到的信令会话相关分组的数量，这些分组将从相关应用信令协议栈（如SIP或H.323，SIMPLE）中导出，以及应用程序用于建立通信会话的各种其他信令协议。
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.
然而，在通信实体之间建立媒体的时段期间，该计数器将指示自上次PDU发送以来已发送给通信方的RTP帧的数目。RTCP SR/RR报告[RFC3550]中描述的计算RTP帧的方法将应用于应用程序使用RTP的任何地方。这是一个累积计数器，应用程序需要考虑计数器溢出和从零开始重新开始计数的可能性。
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).
对RTP的支持可以通过运行应用程序的主机中的RTP MIB[RFC2959]的支持来确定，或者通过在应用程序名称的开头包含字符串“RTP”（第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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
此度量报告自上次RAQMON PDU发送到生成此RAQMON PDU为止，作为此会话一部分的RDS发送的信令和有效负载数据包的数量。应用分组可以包括信令分组。与第5.16节中的“接收的应用程序数据包总数”参数类似，此计数是一个时间快照。根据应用类型，计数器还根据各种应用状态而变化，包括信令设置、媒体建立、会话终止状态等的分组计数。这是一个累积计数器，应用程序需要考虑计数器溢出和从零开始重新开始计数的可能性。
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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
此度量报告自发送最后一个RAQMON PDU以来，直到生成此RAQMON数据包为止，作为此会话的一部分，RDS在数据包中接收的信令和有效负载八位字节总数。应用八位字节可以包括信令八位字节。[RFC3550]描述的方法将应用于应用程序使用RTP的任何地方。这是一个累积计数器，应用程序需要考虑计数器溢出和从零开始重新开始计数的可能性。
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).
对RTP的支持可以通过运行应用程序的主机中的RTP MIB[RFC2959]的支持来确定，或者通过在应用程序名称的开头包含字符串“RTP”（第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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
此度量报告自发送最后一个RAQMON PDU以来，直到生成此RAQMON数据包为止，作为此会话的一部分，RDS在数据包中接收的信令和有效负载八位字节总数。这类似于接收到的应用程序八位字节总数度量。应用八位字节可以包括信令八位字节。[RFC3550]描述的方法将应用于应用程序使用RTP的任何地方。这是一个累积计数器，应用程序需要考虑计数器溢出和从零开始重新开始计数的可能性。
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).
对RTP的支持可以通过运行应用程序的主机中的RTP MIB[RFC2959]的支持来确定，或者通过在应用程序名称的开头包含字符串“RTP”（第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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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
对于RTP流量，应使用[RFC3550]中描述的方法测量底层传输网络的数据包丢失，对于其他IP流量，应使用[RFC2680]中描述的方法测量。预期的数据包数定义为所接收的扩展的最后一个序列号，定义如下
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].
接下来，减去接收到的初始序列号。对于RTP流量，可使用[RFC3550]附录A.3中所示的技术计算。
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].
对于RTP流量，应使用[RFC3550]中描述的方法测量底层传输网络的数据包丢失，对于其他IP流量，应使用[RFC2680]中描述的方法测量。预期的数据包数定义为接收到的扩展的最后一个序列号，如下面定义的，减去接收到的初始序列号。对于RTP流量，可使用[RFC3550]附录A.3中所示的技术计算。
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).
对RTP的支持可以通过运行应用程序的主机中的RTP MIB[RFC2959]的支持来确定，或者通过在应用程序名称的开头包含字符串“RTP”（第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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
RAQMON框架允许应用程序区分网络丢失的数据包和由于抖动和其他应用程序级错误而丢弃的数据包。尽管数据包丢失和丢弃对应用程序的质量具有同等的影响，但对数据包丢失和丢弃进行单独计数有助于确定质量下降的根源。
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.
数据包丢弃度量表示设备随时间在本地丢弃的数据包。Local device level packet discard（本地设备级数据包丢弃）被捕获为自接收开始以来由于延迟或提前到达、接收抖动缓冲区运行不足或溢出或任何其他特定于应用程序的原因而丢弃的源应用程序级数据包的总数。
If the RDS cannot tell the difference between discards and lost packets, then it MUST report only lost packets and MUST NOT report discards.
如果RDS无法区分丢弃和丢失的数据包，则必须仅报告丢失的数据包，不得报告丢弃。
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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
源有效负载类型报告数据源发送的有效负载格式（如媒体编码），如ITU g.711、ITU g.729B、H.263、MPEG-2、ASCII等。本备忘录遵循[RFC3551]中有效负载类型（PT）的定义。例如，为了指示用于会话的源有效负载类型是PCMA（具有a律缩放的脉冲码调制），相应会话的源有效负载字段的值将为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.
源有效负载类型值在会话期间保持不变，动态编解码器更改等事件除外。RDS应避免在RAQMON报告中发送这些参数的频率超过必要的频率（例如，在动态编解码器更改时），以确保有效利用网络资源。
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.
如果使用动态类型（根据[RFC3551]，值96到127）来标识源有效负载类型，则可以定义RAQMON扩展参数来指示MIME子类型。在RDS确实发送记录动态编解码器更改的报告的情况下，可能存在仅在编解码器更改之前或之后使用此扩展参数的实例，因为源有效负载可能在动态和静态类型之间移动。
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].
接收器有效载荷类型报告由另一通信方发送回源的有效载荷格式（例如，媒体编码），例如ITU g.711、ITU g.729B、H.263、MPEG-2、ASCII等。本文档遵循[RFC3551]中有效载荷类型（PT）的定义。
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.
例如，为了指示用于会话的目的地有效负载类型是PCMA，相应会话的目的地有效负载类型字段将为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.
预期目标有效负载类型值在会话期间保持不变，动态编解码器更改等事件除外。RDS应避免在RAQMON报告中发送这些参数的频率超过必要的频率（例如，在动态编解码器更改时），以确保有效利用网络资源。
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.
如果使用动态类型（根据[RFC3551]的值96到127）来标识目标有效负载类型，则可以定义RAQMON扩展参数来指示MIME子类型。在RDS确实发送记录动态编解码器更改的报告的情况下，可能存在仅在编解码器更改之前或之后使用此扩展参数的实例，因为目标有效负载可能在动态和静态类型之间移动。
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.
许多设备使用第2层技术对局域网环境中的某些类型的流量进行优先级排序。例如，1998年版的IEEE 802.1D[IEEE802.1D]“媒体访问控制网桥”包含支持传输时间关键信息的快速通信能力。根据IEEE P802.1p标准，许多设备使用该标准来标记以太网帧。有关这些方面的详细信息，请参见[IEEE802.1D]，其中包含P802.1p。Source Layer 2 Priority RAQMON字段表示运行RDS的主机在局域网环境中使用了哪些Layer 2值来对这些数据包进行优先级排序。
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.
在会话期间，源层2优先级值应保持不变。运行RDS的主机应避免在RAQMON报告中过于频繁地发送这些参数，以确保网络资源的有效利用。
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.
各种第3层技术已到位，以优先考虑互联网中的流量。例如，传统的IP优先级[RFC791]和服务类型（TOS）[RFC1812]或更新的技术，如差异化服务[RFC2474][RFC2475]，在IPv4中使用TOS八位组，而流量类八位组用于在IPv6中对流量进行优先级排序。源层TOS/DCP RAQMON字段报告数据源用于对这些数据包进行优先级排序的适当第3层值。
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.
在会话期间，源TOS/DSCP值应保持不变。运行RDS的主机应避免在RAQMON报告中过于频繁地发送这些参数，以确保网络资源的有效利用。
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.
目的层2优先级报告通信接收器在局域网环境中向数据源发送通信量时用于对分组进行优先级排序的层2值。与源层2优先级一样，目标层2优先级可以指示目标是否使用了层2技术（如IEEE P802.1p）进行优先级排队。
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.
预期目标层2优先级值在会话期间保持不变。运行RDS的主机应避免在RAQMON报告中过于频繁地发送这些参数，以确保网络资源的有效利用。
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].
目标TOS/DSCP RAQMON字段报告数据接收器用于对源接收的这些数据包进行优先级排序的值。与源第3层优先级类似，目标第3层优先级指示目标是否使用了任何第3层技术，如IP优先级[RFC791]和服务类型（TOS）[RFC1812]，或更近期的技术，如差异化服务[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.
预期目标TOS/DSCP值在会话期间保持不变。运行RDS的主机应避免在RAQMON报告中过于频繁地发送这些参数，以确保网络资源的有效利用。
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.
此参数捕获运行RDS的主机的CPU使用情况，这可能对终端设备的QoS有非常关键的影响。它被计算为自上次报告间隔以来的平均值，并对应于CPU繁忙时间的百分比。
In the case of multiple CPU hosts, the maximum utilization among the different CPUs MUST be reported.
对于多个CPU主机，必须报告不同CPU之间的最大利用率。
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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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).
此参数捕获运行RDS的主机的内存使用情况，这可能对终端设备的QoS有非常关键的影响。它作为自上次报告间隔以来的平均值进行计算，并对应于该时间间隔内所用应用程序的关键总内存空间的平均百分比（例如，主CPU RAM、缓冲区）。
In the case of multiple CPU hosts, the maximum memory utilization among the different CPUs MUST be reported.
对于多个CPU主机，必须报告不同CPU之间的最大内存利用率。
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.
如果RDS能够确定其值，并且该参数与应用程序相关，则应在每个RAQMON PDU中发送该参数。
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.
Application Name/Version参数提供与该会话或子会话关联的应用程序的名称和版本（可选），例如“XYZ VoIP代理1.2”。此信息对于终端设备运行具有不同优先级的多个应用程序的场景可能非常有用，并且对于调试目的可能非常方便。
If the application is using RTP [RFC3550], the Application Name SHOULD begin with the string 'RTP'.
如果应用程序正在使用RTP[RFC3550]，则应用程序名称应以字符串“RTP”开头。
This parameter MUST be sent in the first RAQMON PDU.
此参数必须在第一个RAQMON PDU中发送。
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.
在RAQMON框架内，RRC预计比RDS具有更大的计算资源。因此，各种聚合函数由RRC执行，而RDS不受统计数据处理（如计算最小值、最大值、平均值、标准偏差等）的负担。
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).
RAQMON MIB提供上面定义的RAQMON参数的最小聚合。RAQMON MIB的设计目的不是提供广泛的聚合，如应用程序性能度量（APM）MIB[RFC3729]或传输性能度量（TPM）MIB[RFC4150]。应使用APM和TPM MIB根据协议（例如HTTP、RTP的性能）或应用程序（例如VoIP、视频应用程序的性能）聚合参数。
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:
在RAQMON MIB中，只能对特定的RAQMON度量参数执行聚合。根据以下定义，聚合始终产生统计平均值/最小值/最大值：
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.
平均值：平均值定义为通信会话期间度量的统计平均值。例如，如果RDS报告的端到端延迟度量在通信会话中出现N次，则可以通过将这些N个报告值相加，然后除以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.
Min:Min定义为通信会话持续时间内度量的统计最小值。例如，如果RDS报告了N次通信会话中的终端设备的端到端延迟度量，则最小端到端延迟是报告的N个端到端延迟度量值中的最小值。
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.
Max:Max定义为通信会话期间度量的统计最大值。例如，如果RDS报告了N次通信会话中的端到端设备的端到端延迟度量，则最大端到端延迟是报告的N个端到端延迟度量值中的最大值。
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.
从文档中可以明显看出，需要管理RAQMON MIB数据以优化存储空间。在通信会话中收集的大量数据可以针对存储空间进行优化，如果需要，只执行和存储聚合的历史RAQMON度量。
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.
1. 仅在通信会话结束时，即收到空PDU时，通过MIB使数据可用。可以使用RAQMON MIB作为平均值、最大值或最小值条目来提供聚合数据，并将其保存以用于历史目的。
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.
2. 使用基于时间的算法，该算法在通信会话中的特定时间段内聚合数据，因此需要较少的条目，以减少存储空间需求。例如，如果RDS每10秒发送一次数据，并且RRC每分钟更新一次RAQMON MIB，则每6个数据点将有一个MIB条目。
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.
3. 根据管理策略定期删除历史数据。这种政策的一个例子是删除超过60天的历史数据。这些策略的实施由应用程序开发人员自行决定，它们的使用是一个操作问题。
Security considerations associated with the RAQMON Framework are discussed below, and in greater detail in other RAQMON memos as is appropriate.
与RAQMON框架相关的安全注意事项将在下文讨论，并在其他RAQMON备忘录（视情况而定）中进行更详细的讨论。
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:
与RAQMON框架相关的漏洞是与底层（直至传输层）相关的漏洞和可能利用RAQMON有效负载的漏洞的组合。RAQMON有效载荷的可能利用属于以下类别：
1. Unauthorized examination of sensitive information in the payload in transit.
1. 未经授权检查运输中有效载荷中的敏感信息。
2. Unauthorized modification of payload contents in transit, leading to:
2. 未经授权修改运输中的有效载荷内容，导致：
a. Mis-identification of information from one RAQMON reporting session as belonging to another destined to the same RRC;
a. 错误识别来自一个RAQMON报告会话的信息属于另一个发送至同一RRC的信息；
b. Mismapping of RAQMON sessions;
b. RAQMON会话映射错误；
c. Various forms of session-level denial-of-service (DoS) attacks;
c. 各种形式的会话级拒绝服务（DoS）攻击；
d. DoS through modification of RAQMON parameter values and statistics;
d. DoS通过修改RAQMON参数值和统计信息；
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.
e. 无效的时间戳，导致对被监控数据的错误解释，影响呼叫记录信息，并使监控事件难以在其适当的时间上下文中放置。
3. Malformed payloads, permitting the exploitation of potential implementation weaknesses to compromise an RRC.
3. 格式不正确的有效负载，允许利用潜在的实现弱点危害RRC。
4. Unauthorized disclosure of sensitive data carried by application PDUs, leading to a breach of confidentiality.
4. 未经授权泄露应用程序PDU携带的敏感数据，导致违反保密性。
Consequently, threats based on unauthorized disclosure or modification of payloads or headers will have to be assumed.
因此，必须假设基于未经授权披露或修改有效负载或报头的威胁。
In order to preserve integrity of the RAQMON PDU against these threats, the RAQMON model must provide for cryptographically strong security services.
为了保护RAQMON PDU的完整性以抵御这些威胁，RAQMON模型必须提供加密功能强大的安全服务。
Consequently, the RAQMON framework must be able to provide for the following protections:
因此，RAQMON框架必须能够提供以下保护：
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.
1. 身份验证-RRC应该能够验证RAQMON PDU实际上是由声称发送它的RDS发起的。
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.
2. 隐私-由于RAQMON信息包括参与通信会话的各方的身份，RAQMON框架应能够提供防止窃听的保护，以防止未经授权的第三方收集潜在的敏感信息。这可以通过使用各种有效负载加密技术来实现，如数据加密标准（DES）、3-DES、高级加密标准（AES）等。
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.
3. 防止针对RRC的DoS攻击-RDS发送RAQMON报告作为外部事件的副作用（例如，正在接收电话）。攻击者可以尝试通过发起大量事件（即调用）来压倒RRC（或网络），目的是用过多的RAQMON PDU淹没RRC。
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.
为防止针对RRC的DoS攻击，RDS将仅在会话已进行五秒钟的报告间隔后才发送会话的第一次报告。短于此的会话应存储在RDS中，并仅在该间隔过期后报告。
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.
RAQMON体系结构允许使用多种传输协议。其中大多数支持安全的操作模式。依赖于传输协议层提供的安全性有很多优点。
1. Transport-protocol-level security can generally protect the payload with end-to-end authentication, confidentiality, message integrity, and replay protection services.
1. 传输协议级别的安全性通常可以通过端到端身份验证、机密性、消息完整性和重播保护服务来保护有效负载。
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.
2. 一个好的加密安全协议总是有一个相关的密钥管理协议。传输协议安全性的使用依赖于其密钥管理，不需要开发其他机制。
3. When transport protocol security is already enabled between the RDS and RRC, additional encryption and message authentication at the application level is avoided.
3. 当RDS和RRC之间已启用传输协议安全性时，可以避免在应用程序级别进行额外的加密和消息身份验证。
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.
1. 当需要对RDS-RRC对的不同RAQMON会话进行会话级隔离时，需要打开单独的传输协议实例。然而，这种情况可能很少见。
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.
2. 由于RAQMON框架不提供安全服务，因此缺少传输或较低的协议安全性意味着缺少RAQMON安全性。
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.
作者要感谢Andy Bierman、Alan Clark、Mahalingam Mani、Colin Perkins、Steve Waldbusser、Magnus Westerlund和Itai Zilbershtein为本文件提供的宝贵建议和真实贡献。作者还想特别感谢Randy Presohn，他为拼写和格式目的审查了本文件，并对技术内容进行了深入审查。我们还要感谢Bert Wijnen在本文件编写过程中提供的长期指导以及对最终版本的详细审查。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 2680，1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的往返延迟度量”，RFC 2681，1999年9月。
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000.
[RFC2819]Waldbusser，S.，“远程网络监控管理信息库”，STD 59，RFC 2819，2000年5月。
[RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time Transport Protocol Management Information Base", RFC 2959, October 2000.
[RFC2959]Baugher，M.，Strahm，B.，和I.Suconick，“实时传输协议管理信息库”，RFC 2959，2000年10月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]Demichelis，C.和P.Chimento，“IP性能度量的IP数据包延迟变化度量（IPPM）”，RFC 3393，2002年11月。
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416]Presohn，R.，Ed.“简单网络管理协议（SNMP）的协议操作第2版”，STD 62，RFC 3416，2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC1305，1992年3月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[RFC3235]Senie，D.，“网络地址转换器（NAT）-友好的应用程序设计指南”，RFC 32352002年1月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004.
[RFC3729]Waldbusser，S.，“应用程序性能度量MIB”，RFC 37292004年3月。
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005.
[RFC4150]Dietz，R.和R.Cole，“传输性能指标MIB”，RFC 4150，2005年8月。
[RFC4711] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON) MIB", RFC 4711, October 2006.
[RFC4711]Siddiqui，A.，Romascanu，D.，和E.Golovinsky，“实时应用程序服务质量监控（RAQMON）MIB”，RFC 47112006年10月。
[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.
[RFC4712]Siddiqui，A.，Romascanu，D.，Golovinsky，E.，Rahmman，M.，和Y.Kim，“实时应用服务质量监控（RAQMON）协议数据单元（PDU）的传输映射”，RFC 4712，2006年10月。
[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]
[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
美国新泽西州林克罗夫特市米德尔顿林克罗夫特路307号安瓦尔A.西迪基·阿瓦亚实验室，邮编：07738
Phone: +1 732 852-3200
EMail: anwars@avaya.com
Phone: +1 732 852-3200
EMail: anwars@avaya.com
Dan Romascanu Avaya Atidim Technology Park, Building #3 Tel Aviv, 61131 Israel
以色列特拉维夫3号楼Dan Romascanu Avaya Atidim科技园，61131
Phone: +972-3-645-8414
EMail: dromasca@avaya.com
Phone: +972-3-645-8414
EMail: dromasca@avaya.com
Eugene Golovinsky
尤金·戈洛文斯基
EMail: gene@alertlogic.net
EMail: gene@alertlogic.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。