Network Working Group A. Siddiqui
Request for Comments: 4712 D. Romascanu
Category: Standards Track Avaya
E. Golovinsky
Alert Logic
M. Rahman
Samsung Information Systems America
Y. Kim
Broadcom
October 2006
Network Working Group A. Siddiqui
Request for Comments: 4712 D. Romascanu
Category: Standards Track Avaya
E. Golovinsky
Alert Logic
M. Rahman
Samsung Information Systems America
Y. Kim
Broadcom
October 2006
Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)
实时应用程序服务质量监控（RAQMON）协议数据单元（PDU）的传输映射
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
摘要
This memo specifies two transport mappings of the Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC).
此备忘录指定了RFC 4710中定义的实时应用程序服务质量监控（RAQMON）信息模型的两个传输映射，使用TCP作为本机传输，并使用简单网络管理协议（SNMP）将RAQMON信息从RAQMON数据源（RDS）传输到RAQMON报告采集器（RRC）。
Table of Contents
目录
1. Introduction ....................................................3
2. Transporting RAQMON Protocol Data Units .........................3
2.1. TCP as an RDS/RRC Network Transport Protocol ...............3
2.1.1. The RAQMON PDU ......................................5
2.1.2. The BASIC Part of the RAQMON Protocol Data Unit .....7
2.1.3. APP Part of the RAQMON Protocol Data Unit ..........14
2.1.4. Byte Order, Alignment, and Time Format of
RAQMON PDUs ........................................15
2.2. Securing RAQMON Session ...................................15
2.2.1. Sequencing of the Start TLS Operation ..............18
2.2.2. Closing a TLS Connection ...........................21
2.3. SNMP Notifications as an RDS/RRC Network Transport
Protocol ..................................................22
3. IANA Considerations ............................................38
4. Congestion-Safe RAQMON Operation ...............................38
5. Acknowledgements ...............................................39
6. Security Considerations ........................................39
6.1. Usage of TLS with RAQMON ..................................41
6.1.1. Confidentiality & Message Integrity ................41
6.1.2. TLS CipherSuites ...................................41
6.1.3. RAQMON Authorization State .........................42
7. References .....................................................43
7.1. Normative References ......................................43
7.2. Informative References ....................................44
Appendix A. Pseudocode ............................................46
1. Introduction ....................................................3
2. Transporting RAQMON Protocol Data Units .........................3
2.1. TCP as an RDS/RRC Network Transport Protocol ...............3
2.1.1. The RAQMON PDU ......................................5
2.1.2. The BASIC Part of the RAQMON Protocol Data Unit .....7
2.1.3. APP Part of the RAQMON Protocol Data Unit ..........14
2.1.4. Byte Order, Alignment, and Time Format of
RAQMON PDUs ........................................15
2.2. Securing RAQMON Session ...................................15
2.2.1. Sequencing of the Start TLS Operation ..............18
2.2.2. Closing a TLS Connection ...........................21
2.3. SNMP Notifications as an RDS/RRC Network Transport
Protocol ..................................................22
3. IANA Considerations ............................................38
4. Congestion-Safe RAQMON Operation ...............................38
5. Acknowledgements ...............................................39
6. Security Considerations ........................................39
6.1. Usage of TLS with RAQMON ..................................41
6.1.1. Confidentiality & Message Integrity ................41
6.1.2. TLS CipherSuites ...................................41
6.1.3. RAQMON Authorization State .........................42
7. References .....................................................43
7.1. Normative References ......................................43
7.2. Informative References ....................................44
Appendix A. Pseudocode ............................................46
The Real-Time Application QoS Monitoring (RAQMON) Framework, as outlined by [RFC4710], extends the Remote Monitoring family of protocols (RMON) by defining entities such as RAQMON Data Sources RDS) and RAQMON Report Collectors (RRC) to perform various application monitoring in real time. [RFC4710] defines the relevant metrics for RAQMON monitoring carried by the common protocol data unit (PDU) used between a RDS and RRC to report QoS statistics. This memo contains a syntactical description of the RAQMON PDU structure.
[RFC4710]概述的实时应用程序QoS监控（RAQMON）框架通过定义诸如RAQMON数据源（RDS）和RAQMON报告采集器（RRC）等实体来实时执行各种应用程序监控，从而扩展了远程监控协议系列（RMON）。[RFC4710]定义了RDS和RRC之间使用的公共协议数据单元（PDU）用于报告QoS统计数据的RAQMON监控的相关指标。本备忘录包含RAQMON PDU结构的语法描述。
The following sections of this memo contain detailed specifications for the usage of TCP and SNMP to carry RAQMON information.
本备忘录的以下部分包含使用TCP和SNMP传输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 Protocol Data Unit (PDU) utilizes a common data format understood by the RDS and the RRC. 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. As part of the specification, this memo also specifies the usage of TCP and SNMP as underlying transport protocols to carry RAQMON PDUs between RDSs and RRCs. While two transport protocol choices have been provided as options to chose from for RDS implementers, RRCs MUST implement the TCP transport and MAY implement the SNMP transport.
RAQMON协议数据单元（PDU）使用RDS和RRC可以理解的通用数据格式。RAQMON PDU不传输应用程序数据，而是在协议栈的应用程序层占据有效负载规范的位置。作为规范的一部分，本备忘录还规定了TCP和SNMP作为底层传输协议的使用，以在RDS和RRC之间传输RAQMON PDU。虽然提供了两种传输协议选项作为RDS实施者的选择，但RRC必须实现TCP传输，并且可以实现SNMP传输。
A transport binding using TCP is included within the RAQMON specification to facilitate reporting from various types of embedded devices that run applications such as Voice over IP, Voice over Wi-Fi, Fax over IP, Video over IP, Instant Messaging (IM), E-mail, software download applications, e-business style transactions, web access from wired or wireless computing devices etc. For many of these devices, PDUs and a TCP-based transport fit the deployment needs.
RAQMON规范中包含使用TCP的传输绑定，以便于从运行应用程序（如IP语音、Wi-Fi语音、IP传真、IP视频、即时消息（IM）、电子邮件、软件下载应用程序、电子商务风格事务、，从有线或无线计算设备等进行web访问。对于许多此类设备，PDU和基于TCP的传输适合部署需要。
The RAQMON transport requirements for end-to-end congestion control and reliability are inherently built into TCP as a transport protocol [RFC793].
端到端拥塞控制和可靠性的RAQMON传输要求作为传输协议固有地内置于TCP中[RFC793]。
To use TCP to transport RAQMON PDUs, it is sufficient to send the PDUs as TCP data. As each PDU carries its length, the receiver can determine the PDU boundaries.
要使用TCP传输RAQMON PDU，只需将PDU作为TCP数据发送即可。由于每个PDU承载其长度，接收器可以确定PDU边界。
The following section details the RAQMON PDU specifications. Though transmitted as one Protocol Data Unit, a RAQMON PDU is functionally divided into two different parts: the BASIC part and application extensions required for vendor-specific extension [RFC4710]. Both functional parts follow a field carrying a SMI Network Management Private Enterprise code currently maintained by IANA http://www.iana.org/assignments/enterprise-numbers, which is used to identify the organization that defined the information carried in the PDU.
以下部分详细介绍了RAQMON PDU规范。尽管作为一个协议数据单元传输，RAQMON PDU在功能上分为两个不同的部分：基本部分和供应商特定扩展所需的应用程序扩展[RFC4710]。这两个功能部分都遵循一个字段，该字段包含当前由IANA维护的SMI网络管理私有企业代码http://www.iana.org/assignments/enterprise-numbers，用于标识定义PDU中携带的信息的组织。
A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1. The parameters carried by RAQMON PDUs are shown in Figure 1 and are defined in section 5 of [RFC4710].
当前版本中的RAQMON PDU标记为PDU类型（PDT）=1。RAQMON PDU携带的参数如图1所示，并在[RFC4710]第5节中定义。
Vendors MUST use the BASIC part of the PDU to report parameters pre-listed here in the specification for interoperability, as opposed to using the application-specific portion. Vendors MAY also use application-specific extensions to convey application-, vendor-, or device-specific parameters not included in the BASIC part of the specification and explicitly publish such data externally to attain extended interoperability.
供应商必须使用PDU的基本部分来报告互操作性规范中在此预先列出的参数，而不是使用特定于应用程序的部分。供应商还可以使用特定于应用程序的扩展来传递规范基本部分中未包含的特定于应用程序、供应商或设备的参数，并在外部明确发布此类数据，以实现扩展的互操作性。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |Report Type = 0| RC_N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |flag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source Address {DA} |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Address (RA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Application Name (AN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Data Source Name (DN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Receiver's Name (RN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Session State ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round-Trip End-to-End Network Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One-Way End-to-End Network Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Packet Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Application Packet Discard |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Packets sent |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |Report Type = 0| RC_N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |flag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source Address {DA} |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Address (RA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Application Name (AN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Data Source Name (DN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Receiver's Name (RN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Session State ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round-Trip End-to-End Network Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One-Way End-to-End Network Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Packet Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Application Packet Discard |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Packets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Packets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Octets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Octets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source Device Port Used | Receiver Device Port Used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Source Payload |Receiver | CPU | Memory |
|Type |Payload Type | Utilization | Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Setup Delay | Application Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Packet Delay Variation | Inter arrival Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Discrd | Packet loss | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "xxx" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Type = "yyy" | Length of Application Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "abc" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Type = "zzz" | Length of Application Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Packets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Octets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Octets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source Device Port Used | Receiver Device Port Used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Source Payload |Receiver | CPU | Memory |
|Type |Payload Type | Utilization | Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Setup Delay | Application Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Packet Delay Variation | Inter arrival Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Discrd | Packet loss | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "xxx" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Type = "yyy" | Length of Application Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "abc" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Type = "zzz" | Length of Application Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RAQMON Protocol Data Unit
图1:RAQMON协议数据单元
A RAQMON PDU must contain the following BASIC part fields at all times:
RAQMON PDU必须始终包含以下基本零件字段：
PDU type (PDT): 5 bits - This indicates the type of RAQMON PDU being sent. PDT = 1 is used for the current RAQMON PDU version defined in this document.
PDU类型（PDT）：5位-表示发送的RAQMON PDU的类型。PDT=1用于本文档中定义的当前RAQMON PDU版本。
basic (B): 1 bit - While set to 1, the basic flag indicates that the PDU has BASIC part of the RAQMON PDU. A value of zero is considered valid and indicates a RAQMON NULL PDU.
基本（B）：1位-设置为1时，基本标志表示PDU具有RAQMON PDU的基本部分。零的值被认为是有效的，表示RAQMON NULL PDU。
trailer (T): 3 bits - Total number of Application-Specific Extensions that follow the BASIC part of RAQMON PDU. A value of zero is considered valid as many times as there is no application-specific information to add to the basic information.
拖车（T）：3位-遵循RAQMON PDU基本部分的特定于应用程序的扩展的总数。如果没有特定于应用程序的信息添加到基本信息中，则零的值被视为有效。
padding (P): 1 bit - If the padding bit is set, the BASIC part of the RAQMON PDU contains some additional padding octets at the end of the BASIC part of the PDU that are not part of the monitoring information. Padding may be needed in some cases, as reporting is based on the intent of a RDS to report certain parameters. Also, some parameters may be reported only once at the beginning of the reporting session, e.g., Data Source Name, Receiver Name, payload type, etc. Actual padding at the end of the BASIC part of the PDU is 0, 8, 16, or 24 bits to make the length of the BASIC part of the PDU a multiple of 32 bits
padding（P）：1位-如果设置了padding位，则RAQMON PDU的基本部分在PDU的基本部分末尾包含一些额外的padding八位字节，这些八位字节不属于监控信息的一部分。在某些情况下可能需要填充，因为报告基于RDS报告某些参数的意图。此外，一些参数可以在报告会话开始时仅报告一次，例如，数据源名称、接收器名称、有效负载类型等。PDU基本部分末尾的实际填充为0、8、16或24位，以使PDU基本部分的长度为32位的倍数
Source IP version Flag (S): 1 bit - While set to 1, the source IP version flag indicates that the Source IP address contained in the PDU is an IPv6 address.
源IP版本标志：1位-设置为1时，源IP版本标志表示PDU中包含的源IP地址是IPv6地址。
Receiver IP version Flag (R): 1 bit - While set to 1, the receiver IP version flag indicates that the receiver IP address contained in the PDU is an IPv6 address.
接收器IP版本标志（R）：1位-设置为1时，接收器IP版本标志表示PDU中包含的接收器IP地址是IPv6地址。
record count (RC): 4 bits - Total number of application records contained in the BASIC part of the PDU. A value of zero is considered valid but useless, with the exception of the case of a NULL PDU indicating the end of a RDS reporting session.
记录计数（RC）：4位—PDU基本部分中包含的应用程序记录总数。零的值被认为是有效的，但没有用处，但空PDU表示RDS报告会话结束的情况除外。
length: 16 bits (unsigned integer) - The length of the BASIC part of the RAQMON PDU in units of 32-bit words minus one; this count includes the header and any padding.
长度：16位（无符号整数）-RAQMON PDU基本部分的长度，以32位字减去1为单位；此计数包括页眉和任何填充。
DSRC: 32 bits - Data Source identifier represents a unique RAQMON reporting session descriptor that points to a specific reporting session between RDS and RRC. Uniqueness of DSRC is valid only within a reporting session. DSRC values should be randomly generated using vendor-chosen algorithms for each communication session. It is not sufficient to obtain a DSRC simply by calling random() without carefully initializing the state. One could use an algorithm like the one defined in Appendix A.6 in [RFC3550] to create a DSRC. Depending on the choice of algorithm, there is a finite probability that two DSRCs from two different RDSs may be the same. To further reduce the probability that two RDSs pick the same DSRC for two different reporting sessions, it is recommended that an RRC use parameters like Data Source Address (DA), Data Source Name (DN), and layer 2 Media Access Control (MAC) Address in the PDU in conjunction with a DSRC value. It is not mandatory for RDSs to send parameters like Data Source Address (DA), Data Source Name (DN), and MAC Address in every PDU sent to RRC, but occasionally sending these parameters will reduce the probability of DSRC collision drastically. However, this will cause an additional overhead per PDU.
DSRC:32位-数据源标识符表示唯一的RAQMON报告会话描述符，该描述符指向RDS和RRC之间的特定报告会话。DSRC的唯一性仅在报告会话中有效。DSRC值应使用供应商为每个通信会话选择的算法随机生成。仅通过调用random（）而不仔细初始化状态是不够的。可以使用[RFC3550]附录A.6中定义的算法来创建DSRC。根据算法的选择，来自两个不同RDS的两个DSRC可能相同的概率是有限的。为了进一步降低两个RDS为两个不同报告会话选择相同DSRC的可能性，建议RRC在PDU中结合DSRC值使用数据源地址（DA）、数据源名称（DN）和第2层媒体访问控制（MAC）地址等参数。RDS不必在发送给RRC的每个PDU中发送数据源地址（DA）、数据源名称（DN）和MAC地址等参数，但偶尔发送这些参数将大大降低DSRC冲突的概率。但是，这将导致每个PDU的额外开销。
A value of zero for basic (B) bit and trailer (T) bits constitutes a RAQMON NULL PDU (i.e., nothing to report). RDSs MUST send a RAQMON NULL PDU to RRC to indicate the end of the RDS reporting session. A NULL PDU ends with the DSRC field.
基本（B）位和尾（T）位的值为零构成RAQMON NULL PDU（即，无需报告）。RDS必须向RRC发送RAQMON NULL PDU，以指示RDS报告会话的结束。空PDU以DSRC字段结尾。
SMI Enterprise Code: 16 bits. A value of SMI Enterprise Code = 0 is used to indicate the RMON-WG-compliant BASIC part of the RAQMON PDU format.
SMI企业代码：16位。SMI Enterprise Code=0的值用于指示符合RMON WG的RAQMON PDU格式的基本部分。
Report Type: 8 bits - These bits are reserved by the IETF RMON Working Group. A value of 0 within SMI Enterprise Code = 0 is used for the version of the PDU defined by this document.
报告类型：8位-这些位由IETF RMON工作组保留。SMI Enterprise Code=0中的值0用于本文档定义的PDU版本。
The BASIC part of each RAQMON PDU consists of Record Count Number (RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the presence of appropriate RAQMON parameters within a record, as defined in Table 1.
每个RAQMON PDU的基本部分由记录计数编号（RC_N）和RAQMON参数存在标志（RPPF）组成，以指示记录中是否存在适当的RAQMON参数，如表1所示。
RC_N: 8 bits - The Record Count number indicates a sub-session within a communication session. A value of zero is a valid record number. The maximum number of records that can be described in one RAQMON Packet is 256.
RC_N:8位-记录计数编号表示通信会话中的子会话。值为零是有效的记录编号。一个RAQMON数据包中可以描述的最大记录数为256。
RAQMON Parameter Presence Flags (RPPF): 32 bits
RAQMON参数存在标志（RPPF）：32位
Each of these flags, while set, represents that this RAQMON PDU contains corresponding parameters as specified in Table 1.
设置这些标志时，每个标志表示此RAQMON PDU包含表1中指定的相应参数。
+----------------+--------------------------------------------------+
| Bit Sequence | Presence/Absence of corresponding Parameter |
| Number | within this RAQMON PDU |
+----------------+--------------------------------------------------+
| 0 | Data Source Address (DA) |
| | |
| 1 | Receiver Address (RA) |
| | |
| 2 | NTP Timestamp |
| | |
| 3 | Application Name |
| | |
| 4 | Data Source Name (DN) |
| | |
| 5 | Receiver Name (RN) |
| | |
| 6 | Session Setup Status |
| | |
| 7 | Session Duration |
| | |
| 8 | Round-Trip End-to-End Net Delay (RTT) |
| | |
| 9 | One-Way End-to-End Network Delay (OWD) |
| | |
| 10 | Cumulative Packets Loss |
| | |
| 11 | Cumulative Packets Discards |
| | |
| 12 | Total number of App Packets sent |
| | |
| 13 | Total number of App Packets received |
| | |
| 14 | Total number of App Octets sent |
| | |
| 15 | Total number of App Octets received |
| | |
| 16 | Data Source Device Port Used |
| | |
| 17 | Receiver Device Port Used |
| | |
| 18 | Source Layer 2 Priority |
| | |
| 19 | Source Layer 3 Priority |
| | |
| 20 | Destination Layer 2 Priority |
| | |
| 21 | Destination Layer 3 Priority |
| | |
+----------------+--------------------------------------------------+
| Bit Sequence | Presence/Absence of corresponding Parameter |
| Number | within this RAQMON PDU |
+----------------+--------------------------------------------------+
| 0 | Data Source Address (DA) |
| | |
| 1 | Receiver Address (RA) |
| | |
| 2 | NTP Timestamp |
| | |
| 3 | Application Name |
| | |
| 4 | Data Source Name (DN) |
| | |
| 5 | Receiver Name (RN) |
| | |
| 6 | Session Setup Status |
| | |
| 7 | Session Duration |
| | |
| 8 | Round-Trip End-to-End Net Delay (RTT) |
| | |
| 9 | One-Way End-to-End Network Delay (OWD) |
| | |
| 10 | Cumulative Packets Loss |
| | |
| 11 | Cumulative Packets Discards |
| | |
| 12 | Total number of App Packets sent |
| | |
| 13 | Total number of App Packets received |
| | |
| 14 | Total number of App Octets sent |
| | |
| 15 | Total number of App Octets received |
| | |
| 16 | Data Source Device Port Used |
| | |
| 17 | Receiver Device Port Used |
| | |
| 18 | Source Layer 2 Priority |
| | |
| 19 | Source Layer 3 Priority |
| | |
| 20 | Destination Layer 2 Priority |
| | |
| 21 | Destination Layer 3 Priority |
| | |
| 22 | Source Payload Type |
| | |
| 23 | Receiver Payload Type |
| | |
| 24 | CPU Utilization |
| | |
| 25 | Memory Utilization |
| | |
| 26 | Session Setup Delay |
| | |
| 27 | Application Delay |
| | |
| 28 | IP Packet Delay Variation |
| | |
| 29 | Inter arrival Jitter |
| | |
| 30 | Packet Discard (in fraction) |
| | |
| 31 | Packet Loss (in fraction) |
+----------------+--------------------------------------------------+
| 22 | Source Payload Type |
| | |
| 23 | Receiver Payload Type |
| | |
| 24 | CPU Utilization |
| | |
| 25 | Memory Utilization |
| | |
| 26 | Session Setup Delay |
| | |
| 27 | Application Delay |
| | |
| 28 | IP Packet Delay Variation |
| | |
| 29 | Inter arrival Jitter |
| | |
| 30 | Packet Discard (in fraction) |
| | |
| 31 | Packet Loss (in fraction) |
+----------------+--------------------------------------------------+
Table 1: RAQMON Parameters and Corresponding RPPF
表1:RAQMON参数和相应的RPPF
Data Source Address (DA): 32 bits or 160 bits in binary representation - This parameter is defined in section 5.1 of [RFC4710]. IPv6 addresses are incorporated in Data Source Address by setting the source IP version flag (S bit) of the RAQMON PDU header to 1.
数据源地址（DA）：二进制表示的32位或160位-此参数在[RFC4710]第5.1节中定义。通过将RAQMON PDU头的源IP版本标志（S位）设置为1，IPv6地址合并到数据源地址中。
Receiver Address (RA): 32 bits or 160 bits - This parameter is defined in section 5.2 of [RFC4710]. It follows the exact same syntax as Data Source Address but is used to indicate a Receiver Address. IPv6 addresses are incorporated in Receiver Address by setting the receiver IP version flag (R bit) of the RAQMON PDU header to 1.
接收器地址（RA）：32位或160位-此参数在[RFC4710]第5.2节中定义。它遵循与数据源地址完全相同的语法，但用于指示接收器地址。通过将RAQMON PDU头的接收器IP版本标志（R位）设置为1，IPv6地址合并到接收器地址中。
Session Setup Date/Time (NTP timestamp): 64 bits - This parameter is defined in section 5.7 of [RFC4710] and represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds [RFC1305]. The full resolution NTP timestamp is a 64-bit unsigned fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits.
会话设置日期/时间（NTP时间戳）：64位-此参数在[RFC4710]第5.7节中定义，并使用网络时间协议（NTP）的时间戳格式表示，以秒为单位[RFC1305]。全分辨率NTP时间戳是一个64位无符号定点数字，整数部分在前32位，小数部分在后32位。
Application Name: This parameter is defined in section 5.32 of [RFC4710]. The Application Name field starts with an 8-bit octet count describing the length of the text followed by the text itself using UTF-8 encoding. Application Name field is a multiple of 32 bits, and padding will be used if necessary.
应用名称：此参数在[RFC4710]的第5.32节中定义。Application Name字段以描述文本长度的8位八位组计数开始，后跟使用UTF-8编码的文本本身。应用程序名称字段是32位的倍数，如有必要，将使用填充。
A Data Source that does not support NTP SHOULD set the appropriate RAQMON flag to 0 to avoid wasting 64 bits in the PDU. Since the NTP time stamp is intended to provide the setup Date/Time of a session, it is RECOMMENDED that the NTP Timestamp be used only in the first RAQMON PDU after sub-session RC_N setup is completed, in order to use network resources efficiently.
不支持NTP的数据源应将适当的RAQMON标志设置为0，以避免在PDU中浪费64位。由于NTP时间戳旨在提供会话的设置日期/时间，因此建议仅在子会话RC_N设置完成后的第一个RAQMON PDU中使用NTP时间戳，以便有效使用网络资源。
Data Source Name (DN): Defined in section 5.3 of [RFC4710]. The Data Source Name field starts with an 8-bit octet count describing the length of the text followed by the text itself. Padding is used to ensure that the length and text encoding occupy a multiple of 32 bits in the DN field of the PDU. The text MUST NOT be longer than 255 octets. The text is encoded according to the UTF-8 encoding specified in [RFC3629]. Applications SHOULD instruct RDSs to send out the Data Source Name infrequently to ensure efficient usage of network resources as this parameter is expected to remain constant for the duration of the reporting session.
数据源名称（DN）：在[RFC4710]第5.3节中定义。数据源名称字段以描述文本长度的8位八位组计数开始，后跟文本本身。填充用于确保长度和文本编码在PDU的DN字段中占用32位的倍数。文本长度不得超过255个八位字节。根据[RFC3629]中规定的UTF-8编码对文本进行编码。应用程序应指示RDS不经常发送数据源名称，以确保有效利用网络资源，因为此参数预计在报告会话期间保持不变。
Receiver Name (RN): This metric is defined in section 5.4 of [RFC4710]. Like Data Source Name, the Receiver Name field starts with an 8-bit octet count describing the length of the text, followed by the text itself. The Receiver Name, including the length field encoding, is a multiple of 32 bits and follows the same padding rules as applied to the Data Source Name. Since the Receiver Name is expected to remain constant during the entire reporting session, this information SHOULD be sent out occasionally over random time intervals to maximize success of reaching a RRC and also conserve network bandwidth.
接收方名称（RN）：该指标在[RFC4710]第5.4节中定义。与数据源名称一样，Receiver Name字段以描述文本长度的8位八位组计数开始，然后是文本本身。接收器名称（包括长度字段编码）是32位的倍数，并遵循应用于数据源名称的相同填充规则。由于预计在整个报告会话期间接收器名称将保持不变，因此应在随机时间间隔内偶尔发送此信息，以最大限度地成功达到RRC，并节省网络带宽。
Session Setup Status: The Session (sub-session) Setup Status is defined in section 5.10 of [RFC4710]. This field starts with an 8-bit length field followed by the text itself. Session Setup Status is a multiple of 32 bits.
会话设置状态：会话（子会话）设置状态在[RFC4710]第5.10节中定义。此字段以8位长度字段开头，后跟文本本身。会话设置状态是32位的倍数。
Session Duration: 32 bits - The Session (sub-session) Duration metric is defined in section 5.9 of [RFC4710]. Session Duration is an unsigned integer expressed in seconds.
会话持续时间：32位-会话（子会话）持续时间度量在[RFC4710]第5.9节中定义。会话持续时间是以秒为单位的无符号整数。
Round-Trip End-to-End Network Delay: 32 bits - The Round-Trip End-to-End Network Delay is defined in section 5.11 of [RFC4710]. This field represents the Round-Trip End-to-End Delay of sub-session RC_N, which is an unsigned integer expressed in milliseconds.
往返端到端网络延迟：32位-往返端到端网络延迟在[RFC4710]第5.11节中定义。此字段表示子会话RC_N的往返端到端延迟，它是以毫秒表示的无符号整数。
One-Way End-to-End Network Delay: 32 bits - The One-Way End-to-End Network Delay is defined in section 5.12 of [RFC4710]. This field represents the One-Way End-to-End Delay of sub-session RC_N, which is an unsigned integer expressed in milliseconds.
单向端到端网络延迟：32位-单向端到端网络延迟在[RFC4710]第5.12节中定义。此字段表示子会话RC_N的单向端到端延迟，它是以毫秒表示的无符号整数。
Cumulative Application Packet Loss: 32 bits - This parameter is defined in section 5.20 of [RFC4710] as an unsigned integer, representing the total number of packets from sub-session RC_N that have been lost while this RAQMON PDU was generated.
累计应用程序数据包丢失：32位-此参数在[RFC4710]第5.20节中定义为无符号整数，表示生成此RAQMON PDU时从子会话RC_N丢失的数据包总数。
Cumulative Application Packet Discards: 32 bits - This parameter is defined in section 5.22 of [RFC4710] as an unsigned integer representing the total number of packets from sub-session RC_N that have been discarded while this RAQMON PDU was generated.
累积应用程序数据包丢弃：32位-此参数在[RFC4710]第5.22节中定义为无符号整数，表示生成此RAQMON PDU时从子会话RC_N丢弃的数据包总数。
Total number of Application Packets sent: 32 bits - This parameter is defined in section 5.17 of [RFC4710] as an unsigned integer, representing the total number of packets transmitted within sub-session RC_N by the sender.
发送的应用程序数据包总数：32位-此参数在[RFC4710]第5.17节中定义为无符号整数，表示发送方在子会话RC_N内传输的数据包总数。
Total number of Application Packets received: 32 bits - This parameter is defined in section 5.16 of [RFC4710] and is represented as an unsigned integer representing the total number of packets transmitted within sub-session RC_N by the receiver.
接收的应用程序数据包总数：32位-此参数在[RFC4710]第5.16节中定义，并表示为一个无符号整数，表示接收器在子会话RC_N内传输的数据包总数。
Total number of Application Octets sent: 32 bits - This parameter is defined in section 5.19 of [RFC4710] as an unsigned integer, representing the total number of payload octets (i.e., not including header or padding) transmitted in packets by the sender within sub-session RC_N.
发送的应用程序八位字节总数：32位-此参数在[RFC4710]第5.19节中定义为无符号整数，表示发送方在子会话RC_N内以数据包传输的有效负载八位字节总数（即，不包括头或填充）。
Total number of Application Octets received: 32 bits - This parameter is defined in section 5.18 of [RFC4710] as an unsigned integer representing the total number of payload octets (i.e., not including header or padding) transmitted in packets by the receiver within sub-session RC_N.
接收的应用程序八位字节总数：32位-此参数在[RFC4710]第5.18节中定义为一个无符号整数，表示子会话RC\N内接收器在数据包中传输的有效负载八位字节总数（即，不包括报头或填充）。
Data Source Device Port Used: 16 bits - This parameter is defined in section 5.5 of [RFC4710] and describes the port number used by the Data Source as used by the application in RC_N session while this RAQMON PDU was generated.
使用的数据源设备端口：16位-此参数在[RFC4710]的第5.5节中定义，并描述了在生成此RAQMON PDU时，数据源使用的端口号，以及应用程序在RC_N会话中使用的端口号。
Receiver Device Port Used: 16 bits - This parameter is defined in section 5.6 of [RFC4710] and describes the receiver port used by the application to communicate to the receiver. It follows same syntax as Source Device Port Used.
使用的接收器设备端口：16位-此参数在[RFC4710]的第5.6节中定义，并描述应用程序用于与接收器通信的接收器端口。它遵循与所使用的源设备端口相同的语法。
S_Layer2: 8 bits - This parameter, defined in section 5.26 of [RFC4710], is associated to the source's IEEE 802.1D [IEEE802.1D] priority tagging of traffic in the communication sub-session RC_N. Since IEEE 802.1 priority tags are 3 bits long, the first 3 bits of this parameter represent the IEEE 802.1 tag value, and the last 5 bits are padded to 0.
S_Layer2:8位-此参数在[RFC4710]第5.26节中定义，与通信子会话RC_N中通信量的源IEEE 802.1D[IEEE802.1D]优先级标记相关。由于IEEE 802.1优先级标记的长度为3位，因此此参数的前3位表示IEEE 802.1标记值，最后5位被填充为0。
S_Layer3: 8 bits - This parameter, defined in section 5.27 of [RFC4710], represents the layer 3 QoS marking used to send packets to the receiver by this data source during sub-session RC_N.
S_Layer3:8位-此参数在[RFC4710]第5.27节中定义，表示用于在子会话RC_N期间通过此数据源向接收器发送数据包的第3层QoS标记。
D_Layer2: 8 bits - This parameter, defined in section 5.28 of [RFC4710], represents layer 2 IEEE 802.1D priority tags used by the receiver to send packets to the data source during sub-session RC_N session if the Data Source can learn such information. Since IEEE 802.1 priority tags are 3 bits long, the first 3 bits of this parameter represent the IEEE 802.1 priority tag value, and the last 5 bits are padded to 0.
D_Layer2:8位-此参数在[RFC4710]第5.28节中定义，表示第2层IEEE 802.1D优先级标记，如果数据源可以学习此类信息，则接收器在子会话RC_N会话期间用于向数据源发送数据包。由于IEEE 802.1优先级标记的长度为3位，因此此参数的前3位表示IEEE 802.1优先级标记值，最后5位填充为0。
D_Layer3: 8 bits - This parameter is defined in section 5.29 of [RFC4710] and represents the layer 3 QoS marking used by the receiver to send packets to the data source during sub-session RC_N, if the Data Source can learn such information.
D_Layer3:8位-此参数在[RFC4710]的第5.29节中定义，表示接收方在子会话RC_N期间向数据源发送数据包时使用的第3层QoS标记，前提是数据源可以了解此类信息。
Source Payload Type: 8 bits - This parameter is defined in section 5.24 of [RFC4710] and specifies the payload type of the data source of the communication sub-session RC_N as defined in [RFC3551].
源有效负载类型：8位-此参数在[RFC4710]第5.24节中定义，并指定[RFC3551]中定义的通信子会话RC_N数据源的有效负载类型。
Receiver Payload Type: 8 bits - This parameter is defined in section 5.25 of [RFC4710] and specifies the receiver payload type of the communication sub-session RC_N as defined in [RFC3551].
接收器有效负载类型：8位-此参数在[RFC4710]第5.25节中定义，并指定[RFC3551]中定义的通信子会话RC_N的接收器有效负载类型。
CPU Utilization: 8 bits - This parameter, defined in section 5.30 of [RFC4710], represents the percentage of CPU used during session RC_N from the last report until the time this RAQMON PDU was generated. The CPU Utilization is expressed in percents in the range 0 to 100. The value should indicate not only CPU utilization associated to a session RC_N but also actual CPU Utilization, to indicate a snapshot of the CPU utilization of the host running the RDS while session RC_N in progress.
CPU利用率：8位-此参数在[RFC4710]第5.30节中定义，表示从上次报告到生成此RAQMON PDU期间会话RC\N期间使用的CPU百分比。CPU利用率以百分比表示，范围为0到100。该值不仅应指示与会话RC\N相关的CPU利用率，还应指示实际CPU利用率，以指示会话RC\N进行时运行RDS的主机的CPU利用率快照。
Memory Utilization: 8 bits - This parameter, defined in section 5.31 of [RFC4710], represents the percentage of total memory used during session RC_N up until the time this RAQMON PDU was generated. The memory utilization is expressed in percents 0 to 100. The Memory Utilization value should indicate not only the memory utilization associated to a session RC_N but the total memory utilization, to indicate a snapshot of end-device memory utilization while session RC_N is in progress.
内存利用率：8位-此参数在[RFC4710]第5.31节中定义，表示在生成此RAQMON PDU之前，会话RC_N期间使用的总内存百分比。内存利用率以百分比0到100表示。Memory Utilization（内存利用率）值不仅应指示与会话RC\N相关联的内存利用率，还应指示总内存利用率，以指示会话RC\N进行时终端设备内存利用率的快照。
Session Setup Delay: 16 bits - The Session (sub-session) Setup Delay metric is defined in section 5.8 of [RFC4710] and expressed in milliseconds.
会话设置延迟：16位-会话（子会话）设置延迟度量在[RFC4710]第5.8节中定义，并以毫秒表示。
Application Delay: 16 bits - The Application Delay is defined in section 5.13 of [RFC4710] and is represented as an unsigned integer expressed in milliseconds.
应用程序延迟：16位-应用程序延迟在[RFC4710]第5.13节中定义，表示为以毫秒为单位的无符号整数。
IP Packet Delay Variation: 16 bits - The IP Packet Delay Variation is defined in section 5.15 of [RFC4710] and is represented as an unsigned integer expressed in milliseconds.
IP数据包延迟变化：16位-IP数据包延迟变化在[RFC4710]第5.15节中定义，表示为以毫秒为单位的无符号整数。
Inter-Arrival Jitter: 16 bits - The Inter-Arrival Jitter is defined in section 5.14 of [RFC4710] and is represented as an unsigned integer expressed in milliseconds.
到达间抖动：16位-到达间抖动在[RFC4710]第5.14节中定义，表示为以毫秒为单位的无符号整数。
Packet Discard in Fraction: 8 bits - This parameter is defined in section 5.23 of [RFC4710] and is expressed as a fixed-point number with the binary point at the left edge of the field. (That is equivalent to taking the integer part after multiplying the discard fraction by 256.) This metric is defined to be the number of packets discarded, divided by the total number of packets.
数据包丢弃分数：8位-此参数在[RFC4710]的第5.23节中定义，并表示为一个固定点数，二进制点位于字段的左边缘。（这相当于在丢弃分数乘以256后取整数部分。）此度量定义为丢弃的数据包数除以数据包总数。
Packet Loss in Fraction: 8 bits - This parameter is defined in section 5.21 of [RFC4710] and is expressed as a fixed-point number, with the binary point at the left edge of the field. The metric is defined to be the number of packets lost divided by the number of packets expected. The value is calculated by dividing the total number of packets lost (after the effects of applying any error protection, such as Forward Error Correction (FEC)) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part.
分组丢失分数：8位-此参数在[RFC4710]的第5.21节中定义，并表示为一个定点数字，二进制点位于字段的左边缘。该度量定义为丢失的数据包数除以预期的数据包数。通过将丢失的数据包总数（在应用任何错误保护（如前向纠错（FEC））后）除以预期的数据包总数，将除法结果乘以256，将最大值限制为255（以避免溢出），并取整数部分来计算该值。
padding: 0, 8, 16, or 24 bits - If the padding bit (P) is set, then this field may be present. The actual padding at the end of the BASIC part of the PDU is 0, 8, 16, or 24 bits to make the length of the BASIC part of the PDU a multiple of 32 bits.
填充：0、8、16或24位-如果设置了填充位（P），则可能存在此字段。PDU基本部分末端的实际填充为0、8、16或24位，以使PDU基本部分的长度为32位的倍数。
The APP part of the RAQMON PDU is intended to accommodate extensions for new applications in a modular manner and without requiring a PDU type value registration.
RAQMON PDU的应用程序部分旨在以模块化方式容纳新应用程序的扩展，而无需PDU类型值注册。
Vendors may design and publish application-specific extensions. Any RAQMON-compliant RRC MUST be able to recognize vendors' SMI Enterprise Codes and MUST recognize the presence of application-specific extensions identified by using Report Type fields. As represented in Figure 1, the Report Type and Application Length
供应商可以设计和发布特定于应用程序的扩展。任何符合RAQMON的RRC必须能够识别供应商的SMI企业代码，并且必须识别通过使用报告类型字段识别的应用程序特定扩展的存在。如图1所示，报告类型和应用程序长度
fields are always located at a fixed offset relative to the start of the extension fields. There is no need for the RRC to understand the semantics of the enterprise-specific parts of the PDU.
字段始终位于相对于扩展字段起点的固定偏移处。RRC不需要理解PDU的企业特定部分的语义。
SMI Enterprise Code: 32 bits - Vendors and application developers should fill in appropriate SMI Enterprise IDs available at http://www.iana.org/assignments/enterprise-numbers. A non-zero SMI Enterprise Code indicates a vendor- or application-specific extension.
SMI企业代码：32位-供应商和应用程序开发人员应填写适当的SMI企业ID，网址为http://www.iana.org/assignments/enterprise-numbers. 非零SMI企业代码表示特定于供应商或应用程序的扩展。
RAQMON PDUs are capable of carrying multiple Application Parts within a PDU.
RAQMON PDU能够在PDU内承载多个应用程序部件。
Report Type: 16 bits - Vendors and application developers should fill in the appropriate report type within a specified SMI Enterprise Code. It is RECOMMENDED that vendors publish application-specific extensions and maintain such report types for better interoperability.
报告类型：16位-供应商和应用程序开发人员应在指定的SMI企业代码中填写适当的报告类型。建议供应商发布特定于应用程序的扩展，并维护此类报告类型，以实现更好的互操作性。
Length of the Application Part: 16 bits (unsigned integer) - The length of the Application Part of the RAQMON PDU in 32-bit words minus one, which includes the header of the Application Part.
应用程序部分的长度：16位（无符号整数）-RAQMON PDU的应用程序部分的长度（32位字减去1），其中包括应用程序部分的头。
Application-dependent data: variable length - Application/ vendor-dependent data is defined by the application developers. It is interpreted by the vendor-specific application and not by the RRC itself. Its length must be a multiple of 32 bits and will be padded if necessary.
应用程序相关数据：可变长度-应用程序/供应商相关数据由应用程序开发人员定义。它由特定于供应商的应用程序解释，而不是由RRC本身解释。其长度必须是32位的倍数，如有必要，将进行填充。
All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is commonly known as big-endian. The transmission order is described in detail in [RFC791]. Unless otherwise noted, numeric constants are in decimal (base 10).
所有整数字段都是按网络字节顺序进行的，也就是说，最高有效字节（八位字节）排在第一位。这种字节顺序通常称为big-endian。[RFC791]中详细描述了传输顺序。除非另有说明，否则数值常量为十进制（以10为基数）。
All header data is aligned to its natural length, i.e., 16-bit fields are aligned on even offsets, 32-bit fields are aligned at offsets divisible by four, etc. Octets designated as padding have the value zero.
所有报头数据都与其自然长度对齐，即16位字段按偶数偏移对齐，32位字段按可被4整除的偏移对齐，等等。指定为填充的八位字节的值为零。
The RAQMON session, initiated over TCP transport, between an RDS and an RRC carries monitoring information from an RDS client to the RRC, the collector. The RRC distinguishes between clients based on various identifiers used by the RDS to identify itself to the RRC
RDS和RRC之间通过TCP传输启动的RAQMON会话将监控信息从RDS客户端传送到RRC（收集器）。RRC基于RDS用于向RRC标识自身的各种标识符来区分客户端
(Data Source Address and Data Source Name) and the RRC (Receiver's Address and Receiver's Name).
（数据源地址和数据源名称）和RRC（接收方地址和接收方名称）。
In order to ensure integrity of the claimed identities of RDS and RRC to each other, authentication services are required.
为了确保RDS和RRC各自声明的身份的完整性，需要身份验证服务。
Subsequently, where protection from unauthorized modification and unauthorized disclosure of RAQMON data in transit from RDS to RRC is needed, data confidentiality and message integrity services will be required. In order to prevent monitoring-misinformation due to session-recording and replay by unauthorized sources, replay protection services may be required.
随后，如果需要保护从RDS传输到RRC的RAQMON数据免受未经授权的修改和未经授权的披露，则需要数据保密和消息完整性服务。为了防止由于会话记录和未经授权的来源的重播而导致的监控错误信息，可能需要重播保护服务。
TLS provides, at the transport layer, the required authentication services through the handshake protocol and subsequent data confidentiality, message integrity, and replay protection of the application protocol using a ciphersuite negotiated during authentication.
TLS通过握手协议在传输层提供所需的身份验证服务，随后使用身份验证期间协商的密码套件对应用协议进行数据保密性、消息完整性和重播保护。
The RDS client authenticates the RRC in session. The RRC optionally authenticates the RDS.
RDS客户端在会话中验证RRC。RRC可选地对RDS进行身份验证。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |Report Type = | RC_N |
| | TLS_REQ| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |Report Type = | RC_N |
| | TLS_REQ| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RAQMON StartTLS Request - TLS_REQ
图2:RAQMON StartTLS请求-TLS_请求
The protection of a RAQMON session starts with the RDS client's StartTLS request upon successful establishment of the TCP session. The RDS sends the StartTLS request by transmitting the TLS_REQ PDU as in Figure 2. This PDU is distinguished by TLS_REQ Report Type.
RAQMON会话的保护从成功建立TCP会话后RDS客户端的StartTLS请求开始。RDS通过发送TLS_REQ PDU发送StartTLS请求，如图2所示。此PDU通过TLS_REQ报告类型进行区分。
Following this request, the client MUST NOT send any PDUs on this connection until it receives a StartTLS response.
在此请求之后，客户端在收到StartTLS响应之前，不得在此连接上发送任何PDU。
Other fields of the PDU are as specified in Figure 1.
PDU的其他字段如图1所示。
The flags field do not carry any significance and exist for compatibility with the generic RAQMON PDU. The flags field in this version MUST be ignored.
flags字段不具有任何意义，其存在是为了与通用RAQMON PDU兼容。必须忽略此版本中的标志字段。
When a StartTLS request is made, the target server, RRC, MUST return a RAQMON PDU containing a StartTLS response, TLS_RESP. A RAQMON TLS_RESP is defined as follows:
发出StartTLS请求时，目标服务器RRC必须返回包含StartTLS响应TLS_RESP的RAQMON PDU。RAQMON TLS_RESP的定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |Report Type = | Result |
| | TLS_RESP| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |Report Type = | Result |
| | TLS_RESP| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RAQMON StartTLS Response - TLS_RESP
图3:RAQMON StartTLS响应-TLS_响应
The RRC responds to the StartTLS request by transmitting the TLS_RESP PDU as in Figure 3. This PDU is distinguished by TLS_RESP Report Type.
RRC通过传输TLS_RESP PDU响应StartTLS请求，如图3所示。此PDU通过TLS_RESP报告类型进行区分。
The Result field is an octet containing the result of the request. This field can carry one of the following values:
结果字段是包含请求结果的八位字节。此字段可以携带以下值之一：
+-------+------------------+----------------------------------------+
| Value | Mnemonic | Result |
+-------+------------------+----------------------------------------+
| 0 | OK | Success. The server is willing and |
| | | able to negotiate TLS. |
| 1 | OP_ERR | Sequencing Error (e.g., TLS already |
| | | established). |
| 2 | PROTO_ERR | TLS not supported or incorrect PDU |
| | | format. |
| 3 | UNAVAIL | TLS service problem or RRC server |
| | | going down. |
| 4 | CONF_REQD | Confidentiality Service Required. |
| | | |
| 5 | STRONG_AUTH_REQD | Strong Authentication Service |
| | | Required. |
| 6 | REFERRAL | Referral to a RRC Server supporting |
| | | TLS. |
+-------+------------------+----------------------------------------+
+-------+------------------+----------------------------------------+
| Value | Mnemonic | Result |
+-------+------------------+----------------------------------------+
| 0 | OK | Success. The server is willing and |
| | | able to negotiate TLS. |
| 1 | OP_ERR | Sequencing Error (e.g., TLS already |
| | | established). |
| 2 | PROTO_ERR | TLS not supported or incorrect PDU |
| | | format. |
| 3 | UNAVAIL | TLS service problem or RRC server |
| | | going down. |
| 4 | CONF_REQD | Confidentiality Service Required. |
| | | |
| 5 | STRONG_AUTH_REQD | Strong Authentication Service |
| | | Required. |
| 6 | REFERRAL | Referral to a RRC Server supporting |
| | | TLS. |
+-------+------------------+----------------------------------------+
Table 2
表2
Other fields of the PDU are as specified in Figure 1.
PDU的其他字段如图1所示。
The server MUST return OP_ERR if the client violates any of the StartTLS operation sequencing requirements described in the section below.
如果客户端违反以下部分中描述的任何StartTLS操作顺序要求，服务器必须返回OP_ERR。
If the server does not support TLS (whether by design or by current configuration), it MUST set the resultCode to PROTO_ERR or to REFERRAL. The server MUST include an actual referral value in the RAQMON REFER field if it returns a resultCode of referral. The client's current session is unaffected if the server does not support TLS. The client MAY proceed with RAQMON session, or it MAY close the connection.
如果服务器不支持TLS（无论是设计还是当前配置），它必须将resultCode设置为PROTO_ERR或REFERRAL。如果服务器返回引用的resultCode，则必须在RAQMON Reference字段中包含实际引用值。如果服务器不支持TLS，则客户端的当前会话不受影响。客户端可以继续RAQMON会话，也可以关闭连接。
The server MUST return UNAVAIL if it supports TLS but cannot establish a TLS connection for some reason, e.g., if the certificate server not responding, if it cannot contact its TLS implementation, or if the server is in process of shutting down. The client MAY retry the StartTLS operation, MAY proceed with RAQMON session, or MAY close the connection.
如果服务器支持TLS但由于某种原因无法建立TLS连接，例如，如果证书服务器没有响应，如果服务器无法联系其TLS实现，或者如果服务器正在关闭，则服务器必须返回UNVAIL。客户端可能会重试StartTLS操作，可能会继续RAQMON会话，或者可能会关闭连接。
This section describes the overall procedures clients and servers MUST follow for TLS establishment. These procedures take into consideration various aspects of the overall security of the RAQMON connection including discovery of resulting security level.
本节描述了客户机和服务器建立TLS必须遵循的总体程序。这些程序考虑了RAQMON连接整体安全性的各个方面，包括发现产生的安全级别。
The client MAY send the StartTLS request at any time after establishing an RAQMON (TCP) connection, except that in the following cases the client MUST NOT send a StartTLS request:
在建立RAQMON（TCP）连接后，客户端可随时发送StartTLS请求，但在以下情况下，客户端不得发送StartTLS请求：
o if TLS is currently established on the connection, or
o 如果当前已在连接上建立TLS，或
o if RAQMON traffic is in progress on the connection.
o 如果RAQMON通信正在连接上进行。
The result of violating any of these requirements is a Result of OP_ERR, as described above in Table 2.
如表2所述，违反这些要求的结果是操作错误的结果。
If the client did not establish a TLS connection before sending any other requests, and the server requires the client to establish a TLS connection before performing a particular request, the server MUST reject that request with a CONF_REQD or STRONG_AUTH_REQD result. The client MAY send a Start TLS extended request, or it MAY choose to close the connection.
如果客户端在发送任何其他请求之前未建立TLS连接，并且服务器要求客户端在执行特定请求之前建立TLS连接，则服务器必须使用CONF_REQD或STRONG_AUTH_REQD结果拒绝该请求。客户端可以发送启动TLS扩展请求，也可以选择关闭连接。
The server will return an extended response with the resultCode of success if it is willing and able to negotiate TLS. It will return other resultCodes, documented above, if it is unable.
如果服务器愿意并且能够协商TLS，它将返回一个扩展响应，结果代码为success。如果无法返回，它将返回上面记录的其他resultCodes。
In the successful case, the client, which has ceased to transfer RAQMON PDUs on the connection, MUST either begin a TLS negotiation or close the connection. The client will send PDUs in the TLS Record Protocol directly over the underlying transport connection to the server to initiate TLS negotiation [TLS].
在成功的情况下，已停止在连接上传输RAQMON PDU的客户端必须开始TLS协商或关闭连接。客户端将通过底层传输连接直接向服务器发送TLS记录协议中的PDU，以启动TLS协商[TLS]。
Negotiating the version of TLS or SSL to be used is a part of the TLS Handshake Protocol, as documented in [TLS]. The reader is referred to that document for details.
协商要使用的TLS或SSL版本是TLS握手协议的一部分，如[TLS]中所述。读者可参考该文件了解详情。
After a TLS connection is established on a RAQMON connection, both parties MUST individually decide whether or not to continue based on the security assurance level achieved. Ascertaining the TLS connection's assurance level is implementation dependent and is accomplished by communicating with one's respective local TLS implementation.
在RAQMON连接上建立TLS连接后，双方必须根据达到的安全保证级别分别决定是否继续。确定TLS连接的保证级别取决于实现，并通过与各自的本地TLS实现进行通信来完成。
If the client or server decides that the level of authentication or confidentiality is not high enough for it to continue, it SHOULD gracefully close the TLS connection immediately after the TLS negotiation has completed Section 2.2.2.1.
如果客户机或服务器确定身份验证或保密级别不足以继续，则应在TLS协商完成第2.2.2.1节后立即正常关闭TLS连接。
The client MAY attempt to Start TLS again, MAY disconnect, or MAY proceed to send RAQMON session data, if RRC policy permits.
如果RRC策略允许，客户端可以尝试再次启动TLS、断开连接或继续发送RAQMON会话数据。
The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks.
客户端必须对照服务器证书消息中显示的服务器标识检查其对服务器主机名的理解，以防止中间人攻击。
Matching is performed according to these rules:
根据以下规则执行匹配：
o The client MUST use the server dnsNAME in the subjectAltName field to validate the server certificate presented. The server dnsName MUST be part of subjectAltName of the server.
o 客户端必须使用subjectAltName字段中的服务器dnsNAME来验证提供的服务器证书。服务器dnsName必须是服务器的subjectAltName的一部分。
o Matching is case-insensitive.
o 匹配不区分大小写。
o The "*" wildcard character is allowed. If present, it applies only to the left-most name component.
o 允许使用“*”通配符。如果存在，则仅适用于最左侧的名称组件。
For example, *.example.com would match a.example.com, b.example.com, etc., but not example.com. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name), a match in any one of the set is considered acceptable.
例如，*.example.com将匹配a.example.com、b.example.com等，但不匹配example.com。如果证书中存在给定类型的多个标识（例如，多个dNSName名称），则可以接受集合中任何一个的匹配。
If the hostname does not match the dNSName-based identity in the certificate per the above check, automated clients SHOULD close the connection, returning and/or logging an error indicating that the server's identity is suspect.
如果根据上述检查，主机名与证书中基于dNSName的标识不匹配，则自动客户端应关闭连接，返回和/或记录一个错误，指示服务器的标识可疑。
Beyond the server identity checks described in this section, clients SHOULD be prepared to do further checking to ensure that the server is authorized to provide the service it is observed to provide. The client MAY need to make use of local policy information.
除了本节所述的服务器身份检查之外，客户机还应准备进行进一步检查，以确保服务器有权提供其所提供的服务。客户可能需要使用本地策略信息。
We also refer readers to similar guidelines as applied for LDAP over TLS [RFC4513].
我们还向读者介绍了适用于TLS上的LDAP的类似指南[RFC4513]。
Anonymous TLS authentication helps establish a TLS RAQMON session that offers
匿名TLS身份验证有助于建立提供
o server-authentication in course of TLS establishment and
o TLS建立过程中的服务器身份验证
o confidentiality and replay protection of RAQMON traffic, but
o RAQMON流量的机密性和重播保护，但是
o no protection against man-in-the-middle attacks during session establishment and
o 在会话建立和恢复期间，没有针对中间人攻击的保护
o no protection from spoofing attacks by unauthorized clients.
o 无法防止未经授权的客户端进行欺骗攻击。
The server MUST authenticate the RDS client when deployment is susceptible to the above threats. This is done by requiring client authentication during TLS session establishment.
当部署容易受到上述威胁时，服务器必须对RDS客户端进行身份验证。这是通过在TLS会话建立期间要求客户端身份验证来实现的。
In the TLS negotiation, the server MUST request a certificate. The client will provide its certificate to the server and MUST perform a private-key-based encryption, proving it has the private key associated with the certificate.
在TLS协商中，服务器必须请求证书。客户端将向服务器提供其证书，并且必须执行基于私钥的加密，以证明其具有与证书关联的私钥。
As deployments will require protection of sensitive data in transit, the client and server MUST negotiate a ciphersuite that contains a bulk encryption algorithm of appropriate strength.
由于部署需要保护传输中的敏感数据，客户端和服务器必须协商一个包含适当强度的批量加密算法的密码套件。
The server MUST verify that the client's certificate is valid. The server will normally check that the certificate is issued by a known CA, and that none of the certificates on the client's certificate chain are invalid or revoked. There are several procedures by which the server can perform these checks.
服务器必须验证客户端的证书是否有效。服务器通常会检查证书是否由已知CA颁发，以及客户端证书链上的证书是否无效或已吊销。服务器可以通过几个过程执行这些检查。
The server validates the certificate by the Distinguished Name of the RDS client entity in the Subject field of the certificate.
服务器通过证书主题字段中RDS客户端实体的可分辨名称验证证书。
A corresponding set of guidelines will apply to use of TLS-PSK modes [TLS-PSK] using pre-shared keys instead of client certificates.
一套相应的指南将适用于使用预共享密钥而不是客户端证书的TLS-PSK模式[TLS-PSK]。
The client MUST refresh any cached server capabilities information upon TLS session establishment, such as prior RRC state related to a previous RAQMON session based on another DSRC. This is necessary to protect against active-intermediary attacks, which may have altered any server capabilities information retrieved prior to TLS establishment. The server MAY advertise different capabilities after TLS establishment.
客户端必须在TLS会话建立时刷新任何缓存的服务器功能信息，例如与基于另一个DSRC的前一个RAQMON会话相关的前一个RRC状态。这对于防止主动中介攻击是必要的，因为主动中介攻击可能会改变TLS建立之前检索到的任何服务器功能信息。TLS建立后，服务器可能会公布不同的功能。
Either the client or server MAY terminate the TLS connection on an RAQMON session by sending a TLS closure alert. This will leave the RAQMON connection intact.
客户端或服务器都可以通过发送TLS关闭警报来终止RAQMON会话上的TLS连接。这将保持RAQMON连接完好无损。
Before closing a TLS connection, the client MUST wait for any outstanding RAQMON transmissions to complete. This happens naturally when the RAQMON client is single-threaded and synchronous.
在关闭TLS连接之前，客户端必须等待任何未完成的RAQMON传输完成。当RAQMON客户端是单线程和同步的时，这种情况会自然发生。
After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It will cease to send TLS Record Protocol PDUs and, following the receipt of the alert, MAY send and receive RAQMON PDUs.
关闭的发起人发送关闭警报后，必须丢弃任何TLS消息，直到收到另一方的警报。它将停止发送TLS记录协议PDU，并且在收到警报后，可以发送和接收RAQMON PDU。
The other party, if it receives a closure alert, MUST immediately transmit a TLS closure alert. It will subsequently cease to send TLS Record Protocol PDUs and MAY send and receive RAQMON PDUs.
另一方如果收到关闭警报，必须立即发送TLS关闭警报。随后将停止发送TLS记录协议PDU，并可发送和接收RAQMON PDU。
Either the client or server MAY abruptly close the entire RAQMON session and any TLS connection established on it by dropping the underlying TCP connection. It MAY be possible for RRC to send RDS a disconnection notification, which allows the client to know that the disconnection is not due to network failure. However, this message is not defined in this version.
客户机或服务器可能会通过断开底层TCP连接突然关闭整个RAQMON会话和在其上建立的任何TLS连接。RRC可能会向RDS发送断开连接通知，这允许客户端知道断开连接不是由于网络故障造成的。但是，此版本中未定义此消息。
It was an inherent objective of the RAQMON Framework to re-use existing application-level transport protocols to maximize the usage of existing installations as well as to avoid transport-protocol-level complexities in the design process. Choice of SNMP as a means to transport RAQMON PDU was motivated by the intent of using existing installed devices implementing SNMP agents as RAQMON Data Sources (RDSs).
RAQMON框架的一个固有目标是重用现有的应用程序级传输协议，以最大限度地利用现有安装，并避免设计过程中传输协议级的复杂性。选择SNMP作为传输RAQMON PDU的手段的动机是将实现SNMP代理的现有安装设备用作RAQMON数据源（RDS）。
There are some potential problems with the usage of SNMP as a transport mapping protocol:
将SNMP用作传输映射协议存在一些潜在问题：
o The potential of congestion is higher than with the TCP transport, because of the usage of UDP at the transport layer.
o 由于在传输层使用UDP，拥塞的可能性高于TCP传输。
o The encoding of the information is less efficient, and this results in bigger message size, which again may negatively impact congestion conditions and memory size requirements in the devices.
o 信息的编码效率较低，这会导致更大的消息大小，这可能会再次对设备中的拥塞情况和内存大小要求产生负面影响。
In order to avoid these potential problems, the following recommendations are made:
为了避免这些潜在问题，提出以下建议：
o Usage of the TCP transport is RECOMMENDED in deployment over the SNMP transport wherever available for a pair of RDS/RRC.
o 建议在通过SNMP传输进行部署时使用TCP传输，只要对RDS/RRC可用。
o The usage of Inform PDUs is RECOMMENDED.
o 建议使用Inform PDU。
o The usage of Traps PDU is NOT RECOMMENDED.
o 不建议使用陷阱PDU。
o It is RECOMMENDED that information carried by notifications be maintained within the limits of the MTU size in order to avoid fragmentation.
o 建议将通知携带的信息保持在MTU大小的限制范围内，以避免碎片。
If SNMP is chosen as a mechanism to transport RAQMON PDUs, the following specification applies to RAQMON-related usage of SNMP:
如果选择SNMP作为传输RAQMON PDU的机制，则以下规范适用于与RAQMON相关的SNMP使用：
o RDSs implement the capability of embedding RAQMON parameters in SNMP Notifications, re-using well-known SNMP mechanisms to report RAQMON Statistics. The RAQMON RDS MIB module, as specified in 2.1.1, MUST be used in order to map the RAQMON PDUs onto the SNMP Notifications transport.
o RDS实现了在SNMP通知中嵌入RAQMON参数的功能，重新使用众所周知的SNMP机制来报告RAQMON统计信息。必须使用2.1.1中指定的RAQMON RDS MIB模块，以便将RAQMON PDU映射到SNMP通知传输。
o Since RDSs are not computationally rich, and in order to keep the RDS realization as lightweight as possible, RDSs MAY fail to respond to SNMP requests like GET, SET, etc., with the exception of the GET and SET commands required to implement the User-Based Security Model (USM) defined by [RFC3414].
o 由于RDS的计算能力不强，为了使RDS实现尽可能轻量级，RDS可能无法响应SNMP请求，如GET、SET等，但实现[RFC3414]定义的基于用户的安全模型（USM）所需的GET和SET命令除外。
o In order to meet congestion safety requirements, SNMP INFORM PDUs SHOULD be used. In case INFORM PDUs are used, RDSs MUST process the SNMP INFORM responses from RRCs and MUST serialize the PDU transmission rate, i.e., limit the number of PDUS sent in a specific time interval.
o 为了满足拥塞安全要求，应使用SNMP通知PDU。如果使用了INFORM PDU，RDS必须处理来自RRC的SNMP INFORM响应，并且必须序列化PDU传输速率，即限制在特定时间间隔内发送的PDU数量。
o Standard UDP port 162 SHOULD be used for SNMP Notifications.
o 标准UDP端口162应用于SNMP通知。
The RAQMON RDS MIB module is used to map RAQMON PDUs onto SNMP Notifications for transport purposes. The MIB module defines the objects needed for mapping the BASIC part of RAQMON PDU, defined in [RFC4710], as well as the Notifications themselves. In order to incorporate any application-specific extensions in the Application (APP) part of RAQMON PDU, as defined in [RFC4710], additional variable bindings MAY be included in RAQMON notifications as described in the MIB module.
RAQMON RDS MIB模块用于将RAQMON PDU映射到SNMP通知，以便于传输。MIB模块定义了映射[RFC4710]中定义的RAQMON PDU基本部分所需的对象以及通知本身。为了在[RFC4710]中定义的RAQMON PDU的应用程序（APP）部分中纳入任何特定于应用程序的扩展，可在RAQMON通知中包括附加变量绑定，如MIB模块中所述。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410].
有关描述当前互联网标准管理框架的文件的详细概述，请参阅[RFC3410]第7节。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580].
托管对象通过虚拟信息存储（称为管理信息库或MIB）进行访问。MIB对象通常通过简单网络管理协议（SNMP）进行访问。MIB中的对象是使用管理信息结构（SMI）中定义的机制定义的。本备忘录规定了符合SMIv2的MIB模块，如STD 58、[RFC2578]、STD 58、[RFC2579]和STD 58、[RFC2580]所述。
The following MIB module IMPORTS definitions from the following:
以下MIB模块从以下位置导入定义：
SNMPv2-SMI [RFC2578]
SNMPv2-TC [RFC2579]
SNMPv2-CONF [RFC2580]
RMON-MIB [RFC2819]
DIFFSERV-DSCP-TC [RFC3289]
SNMP-FRAMEWORK-MIB [RFC3411]
INET-ADDRESS-MIB [RFC4001]
SNMPv2-SMI [RFC2578]
SNMPv2-TC [RFC2579]
SNMPv2-CONF [RFC2580]
RMON-MIB [RFC2819]
DIFFSERV-DSCP-TC [RFC3289]
SNMP-FRAMEWORK-MIB [RFC3411]
INET-ADDRESS-MIB [RFC4001]
It also uses REFERENCE clauses to refer to [RFC4710].
它还使用引用子句来引用[RFC4710]。
RAQMON-RDS-MIB DEFINITIONS ::= BEGIN
RAQMON-RDS-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Unsigned32 FROM SNMPv2-SMI
从SNMPv2 SMI导入模块标识、对象类型、通知类型、计数器32、未签名32
DateAndTime FROM SNMPv2-TC
来自SNMPv2 TC的日期和时间
rmon FROM RMON-MIB
来自rmon-MIB的rmon
SnmpAdminString FROM SNMP-FRAMEWORK-MIB
SNMP-FRAMEWORK-MIB中的snmpadmin安装
InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB
INET-ADDRESS-MIB中的InetAddressType、InetAddress、InetPortNumber
Dscp FROM DIFFSERV-DSCP-TC
来自DIFFSERV-Dscp-TC的Dscp
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF;
来自SNMPv2 CONF的MODULE-COMPLIANCE、OBJECT-GROUP、NOTIFICATION-GROUP；
raqmonDsMIB MODULE-IDENTITY LAST-UPDATED "200610100000Z" -- October 10, 2006 ORGANIZATION "RMON Working Group" CONTACT-INFO "WG EMail: rmonmib@ietf.org Subscribe: rmonmib-request@ietf.org
raqmonDsMIB模块标识最后一次更新“20061010000Z”--2006年10月10日组织“RMON工作组”联系方式工作组电子邮件：rmonmib@ietf.org订阅：rmonmib-request@ietf.org
MIB Editor: Eugene Golovinsky Postal: BMC Software, Inc. 2101 CityWest Boulevard,
MIB编辑：尤金·戈洛文斯基邮政：BMC软件公司，城市西大街2101号，
Houston, TX, 77094 USA Tel: +713-918-1816 Email: egolovin@bmc.com " DESCRIPTION "This is the RAQMON Data Source notification MIB Module. It provides a mapping of RAQMON PDUs to SNMP notifications.
德克萨斯州休斯顿77094美国电话：+713-918-1816电子邮件：egolovin@bmc.com“说明”这是RAQMON数据源通知MIB模块。它提供RAQMON PDU到SNMP通知的映射。
Ds stands for data source.
Ds代表数据源。
Note that all of the object types defined in this module are accessible-for-notify and would consequently not be available to a browser using simple Get, GetNext, or GetBulk requests.
请注意，此模块中定义的所有对象类型都可用于notify，因此浏览器无法使用简单的Get、GetNext或GetBulk请求。
Copyright (c) The Internet Society (2006).
版权所有（c）互联网协会（2006年）。
This version of this MIB module is part of RFC 4712; See the RFC itself for full legal notices."
此版本的MIB模块是RFC 4712的一部分；有关完整的法律通知，请参见RFC本身。”
REVISION "200610100000Z" -- October 10, 2006 DESCRIPTION "Initial version, published as RFC 4712."
修订版“20061010000Z”-2006年10月10日描述“初始版本，作为RFC 4712出版。”
::= { rmon 32 }
::= { rmon 32 }
-- This OID allocation conforms to [RFC3737]
--此OID分配符合[RFC3737]
raqmonDsNotifications OBJECT IDENTIFIER ::= { raqmonDsMIB 0 }
raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDsMIB 1 }
raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDsMIB 2 }
raqmonDsNotifications OBJECT IDENTIFIER ::= { raqmonDsMIB 0 }
raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDsMIB 1 }
raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDsMIB 2 }
raqmonDsNotificationTable OBJECT-TYPE SYNTAX SEQUENCE OF RaqmonDsNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This conceptual table provides the SNMP mapping of the RAQMON BASIC PDU. It is indexed by the RAQMON Data Source, sub-session, and address of the peer entity.
raqmonDsNotificationTable RaqmonDsNotificationEntry MAX-ACCESS不可访问状态当前描述的对象类型语法序列“此概念表提供RAQMON基本PDU的SNMP映射。它由RAQMON数据源、子会话和对等实体的地址索引。
Note that there is no concern about the indexation of this table exceeding the limits defined by RFC 2578 Section 3.5. According to [RFC4710], Section 5.1,
请注意，本表的指数化不会超过RFC 2578第3.5节规定的限值。根据[RFC4710]第5.1节，
only IPv4 and IPv6 addresses can be reported as
participant addresses."
::= { raqmonDsMIBObjects 1 }
only IPv4 and IPv6 addresses can be reported as
participant addresses."
::= { raqmonDsMIBObjects 1 }
raqmonDsNotificationEntry OBJECT-TYPE
SYNTAX RaqmonDsNotificationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The entry (row) is not retrievable and is not kept by
RDSs. It serves data organization purposes only."
INDEX { raqmonDsDSRC, raqmonDsRCN, raqmonDsPeerAddrType,
raqmonDsPeerAddr }
::= { raqmonDsNotificationTable 1 }
raqmonDsNotificationEntry OBJECT-TYPE
SYNTAX RaqmonDsNotificationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The entry (row) is not retrievable and is not kept by
RDSs. It serves data organization purposes only."
INDEX { raqmonDsDSRC, raqmonDsRCN, raqmonDsPeerAddrType,
raqmonDsPeerAddr }
::= { raqmonDsNotificationTable 1 }
RaqmonDsNotificationEntry ::= SEQUENCE {
raqmonDsDSRC Unsigned32,
raqmonDsRCN Unsigned32,
raqmonDsPeerAddrType InetAddressType,
raqmonDsPeerAddr InetAddress,
raqmonDsAppName SnmpAdminString,
raqmonDsDataSourceDevicePort InetPortNumber,
raqmonDsReceiverDevicePort InetPortNumber,
raqmonDsSessionSetupDateTime DateAndTime,
raqmonDsSessionSetupDelay Unsigned32,
raqmonDsSessionDuration Unsigned32,
raqmonDsSessionSetupStatus SnmpAdminString,
raqmonDsRoundTripEndToEndNetDelay Unsigned32,
raqmonDsOneWayEndToEndNetDelay Unsigned32,
raqmonDsApplicationDelay Unsigned32,
raqmonDsInterArrivalJitter Unsigned32,
raqmonDsIPPacketDelayVariation Unsigned32,
raqmonDsTotalPacketsReceived Counter32,
raqmonDsTotalPacketsSent Counter32,
raqmonDsTotalOctetsReceived Counter32,
raqmonDsTotalOctetsSent Counter32,
raqmonDsCumulativePacketLoss Counter32,
raqmonDsPacketLossFraction Unsigned32,
raqmonDsCumulativeDiscards Counter32,
raqmonDsDiscardsFraction Unsigned32,
raqmonDsSourcePayloadType Unsigned32,
raqmonDsReceiverPayloadType Unsigned32,
raqmonDsSourceLayer2Priority Unsigned32,
raqmonDsSourceDscp Dscp,
raqmonDsDestinationLayer2Priority Unsigned32,
raqmonDsDestinationDscp Dscp,
raqmonDsCpuUtilization Unsigned32,
raqmonDsMemoryUtilization Unsigned32 }
RaqmonDsNotificationEntry ::= SEQUENCE {
raqmonDsDSRC Unsigned32,
raqmonDsRCN Unsigned32,
raqmonDsPeerAddrType InetAddressType,
raqmonDsPeerAddr InetAddress,
raqmonDsAppName SnmpAdminString,
raqmonDsDataSourceDevicePort InetPortNumber,
raqmonDsReceiverDevicePort InetPortNumber,
raqmonDsSessionSetupDateTime DateAndTime,
raqmonDsSessionSetupDelay Unsigned32,
raqmonDsSessionDuration Unsigned32,
raqmonDsSessionSetupStatus SnmpAdminString,
raqmonDsRoundTripEndToEndNetDelay Unsigned32,
raqmonDsOneWayEndToEndNetDelay Unsigned32,
raqmonDsApplicationDelay Unsigned32,
raqmonDsInterArrivalJitter Unsigned32,
raqmonDsIPPacketDelayVariation Unsigned32,
raqmonDsTotalPacketsReceived Counter32,
raqmonDsTotalPacketsSent Counter32,
raqmonDsTotalOctetsReceived Counter32,
raqmonDsTotalOctetsSent Counter32,
raqmonDsCumulativePacketLoss Counter32,
raqmonDsPacketLossFraction Unsigned32,
raqmonDsCumulativeDiscards Counter32,
raqmonDsDiscardsFraction Unsigned32,
raqmonDsSourcePayloadType Unsigned32,
raqmonDsReceiverPayloadType Unsigned32,
raqmonDsSourceLayer2Priority Unsigned32,
raqmonDsSourceDscp Dscp,
raqmonDsDestinationLayer2Priority Unsigned32,
raqmonDsDestinationDscp Dscp,
raqmonDsCpuUtilization Unsigned32,
raqmonDsMemoryUtilization Unsigned32 }
raqmonDsDSRC OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Data Source identifier represents a unique session
descriptor that points to a specific session
between communicating entities. Identifiers unique for
sessions conducted between two entities are
generated by the communicating entities. Zero is a
valid value, with no special semantics."
::= { raqmonDsNotificationEntry 1 }
raqmonDsDSRC OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Data Source identifier represents a unique session
descriptor that points to a specific session
between communicating entities. Identifiers unique for
sessions conducted between two entities are
generated by the communicating entities. Zero is a
valid value, with no special semantics."
::= { raqmonDsNotificationEntry 1 }
raqmonDsRCN OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Record Count Number indicates a sub-session
within a communication session. A maximum number of 16
sub-sessions are supported; this limitation is
dictated by reasons of compatibility with other
transport protocols."
::= { raqmonDsNotificationEntry 2 }
raqmonDsRCN OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Record Count Number indicates a sub-session
within a communication session. A maximum number of 16
sub-sessions are supported; this limitation is
dictated by reasons of compatibility with other
transport protocols."
::= { raqmonDsNotificationEntry 2 }
raqmonDsPeerAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of the Internet address of the peer participant
for this session."
REFERENCE
"Section 5.2 of [RFC4710]"
::= { raqmonDsNotificationEntry 3 }
raqmonDsPeerAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of the Internet address of the peer participant
for this session."
REFERENCE
"Section 5.2 of [RFC4710]"
::= { raqmonDsNotificationEntry 3 }
raqmonDsPeerAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Internet Address of the peer participant for this
session."
REFERENCE
"Section 5.2 of [RFC4710]"
::= { raqmonDsNotificationEntry 4 }
raqmonDsPeerAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Internet Address of the peer participant for this
session."
REFERENCE
"Section 5.2 of [RFC4710]"
::= { raqmonDsNotificationEntry 4 }
raqmonDsAppName OBJECT-TYPE
raqmonDsAppName对象类型
SYNTAX SnmpAdminString
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"This is a text string giving the name and possibly the
version of the application associated with that session,
e.g., 'XYZ VoIP Agent 1.2'."
REFERENCE
"Section 5.28 of [RFC4710]"
::= { raqmonDsNotificationEntry 5 }
SYNTAX SnmpAdminString
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"This is a text string giving the name and possibly the
version of the application associated with that session,
e.g., 'XYZ VoIP Agent 1.2'."
REFERENCE
"Section 5.28 of [RFC4710]"
::= { raqmonDsNotificationEntry 5 }
raqmonDsDataSourceDevicePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The port number from which data for this session was sent
by the Data Source device."
REFERENCE
"Section 5.5 of [RFC4710]"
::= { raqmonDsNotificationEntry 6 }
raqmonDsDataSourceDevicePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The port number from which data for this session was sent
by the Data Source device."
REFERENCE
"Section 5.5 of [RFC4710]"
::= { raqmonDsNotificationEntry 6 }
raqmonDsReceiverDevicePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The port number where the data for this session was
received."
REFERENCE
"Section 5.6 of [RFC4710]"
::= { raqmonDsNotificationEntry 7 }
raqmonDsReceiverDevicePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The port number where the data for this session was
received."
REFERENCE
"Section 5.6 of [RFC4710]"
::= { raqmonDsNotificationEntry 7 }
raqmonDsSessionSetupDateTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The time when session was initiated."
REFERENCE
"Section 5.7 of [RFC4710]"
::= { raqmonDsNotificationEntry 8 }
raqmonDsSessionSetupDateTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The time when session was initiated."
REFERENCE
"Section 5.7 of [RFC4710]"
::= { raqmonDsNotificationEntry 8 }
raqmonDsSessionSetupDelay OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current
raqmonDsSessionSetupDelay对象类型语法Unsigned32（0..65535）单位“毫秒”最大访问权限可用于notify STATUS current
DESCRIPTION
"Session setup time."
REFERENCE
"Section 5.8 of [RFC4710]"
::= { raqmonDsNotificationEntry 9 }
DESCRIPTION
"Session setup time."
REFERENCE
"Section 5.8 of [RFC4710]"
::= { raqmonDsNotificationEntry 9 }
raqmonDsSessionDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session duration, including setup time. The SYNTAX of
this object allows expression of the duration of sessions
that do not exceed 4660 hours and 20 minutes."
REFERENCE
"Section 5.9 of [RFC4710]"
::= { raqmonDsNotificationEntry 10 }
raqmonDsSessionDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session duration, including setup time. The SYNTAX of
this object allows expression of the duration of sessions
that do not exceed 4660 hours and 20 minutes."
REFERENCE
"Section 5.9 of [RFC4710]"
::= { raqmonDsNotificationEntry 10 }
raqmonDsSessionSetupStatus OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Describes appropriate communication session states, e.g.,
Call Established successfully, RSVP reservation
failed, etc."
REFERENCE
"Section 5.10 of [RFC4710]"
::= { raqmonDsNotificationEntry 11 }
raqmonDsSessionSetupStatus OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Describes appropriate communication session states, e.g.,
Call Established successfully, RSVP reservation
failed, etc."
REFERENCE
"Section 5.10 of [RFC4710]"
::= { raqmonDsNotificationEntry 11 }
raqmonDsRoundTripEndToEndNetDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Most recent available information about the
round-trip end-to-end network delay."
REFERENCE
"Section 5.11 of [RFC4710]"
::= { raqmonDsNotificationEntry 12}
raqmonDsRoundTripEndToEndNetDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Most recent available information about the
round-trip end-to-end network delay."
REFERENCE
"Section 5.11 of [RFC4710]"
::= { raqmonDsNotificationEntry 12}
raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current
RaqMondsonWayendToEndNetDelay对象类型语法无符号32个单位“毫秒”最大访问可用于当前通知状态
DESCRIPTION
"Most recent available information about the
one-way end-to-end network delay."
REFERENCE
"Section 5.12 of [RFC4710]"
::= { raqmonDsNotificationEntry 13}
DESCRIPTION
"Most recent available information about the
one-way end-to-end network delay."
REFERENCE
"Section 5.12 of [RFC4710]"
::= { raqmonDsNotificationEntry 13}
raqmonDsApplicationDelay OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Most recent available information about the
application delay."
REFERENCE
"Section 5.13 of [RFC4710"
::= { raqmonDsNotificationEntry 14}
raqmonDsApplicationDelay OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Most recent available information about the
application delay."
REFERENCE
"Section 5.13 of [RFC4710"
::= { raqmonDsNotificationEntry 14}
raqmonDsInterArrivalJitter OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the inter-arrival jitter."
REFERENCE
"Section 5.14 of [RFC4710]"
::= { raqmonDsNotificationEntry 15}
raqmonDsInterArrivalJitter OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the inter-arrival jitter."
REFERENCE
"Section 5.14 of [RFC4710]"
::= { raqmonDsNotificationEntry 15}
raqmonDsIPPacketDelayVariation OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the inter-arrival delay variation."
REFERENCE
"Section 5.15 of [RFC4710]"
::= { raqmonDsNotificationEntry 16}
raqmonDsIPPacketDelayVariation OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the inter-arrival delay variation."
REFERENCE
"Section 5.15 of [RFC4710]"
::= { raqmonDsNotificationEntry 16}
raqmonDsTotalPacketsReceived OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The number of packets transmitted within a communication
RaqMondsTotalPackets接收到的对象类型语法计数器32个单元“数据包”MAX-ACCESS ACCESS for notify STATUS current DESCRIPTION“通信中传输的数据包数
session by the receiver since the start of the session."
REFERENCE
"Section 5.16 of [RFC4710]"
::= { raqmonDsNotificationEntry 17 }
session by the receiver since the start of the session."
REFERENCE
"Section 5.16 of [RFC4710]"
::= { raqmonDsNotificationEntry 17 }
raqmonDsTotalPacketsSent OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packets transmitted within a communication
session by the sender since the start of the session."
REFERENCE
"Section 5.17 of [RFC4710]"
::= { raqmonDsNotificationEntry 18 }
raqmonDsTotalPacketsSent OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packets transmitted within a communication
session by the sender since the start of the session."
REFERENCE
"Section 5.17 of [RFC4710]"
::= { raqmonDsNotificationEntry 18 }
raqmonDsTotalOctetsReceived OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The total number of payload octets (i.e., not including
header or padding octets) transmitted in packets by the
receiver within a communication session since the start
of the session."
REFERENCE
"Section 5.18 of [RFC4710]"
::= { raqmonDsNotificationEntry 19 }
raqmonDsTotalOctetsReceived OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The total number of payload octets (i.e., not including
header or padding octets) transmitted in packets by the
receiver within a communication session since the start
of the session."
REFERENCE
"Section 5.18 of [RFC4710]"
::= { raqmonDsNotificationEntry 19 }
raqmonDsTotalOctetsSent OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of payload octets (i.e., not including headers
or padding) transmitted in packets by the sender within
a communication sub-session since the start of the
session."
REFERENCE
"Section 5.19 of [RFC4710]"
::= { raqmonDsNotificationEntry 20 }
raqmonDsTotalOctetsSent OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of payload octets (i.e., not including headers
or padding) transmitted in packets by the sender within
a communication sub-session since the start of the
session."
REFERENCE
"Section 5.19 of [RFC4710]"
::= { raqmonDsNotificationEntry 20 }
raqmonDsCumulativePacketLoss OBJECT-TYPE SYNTAX Counter32 UNITS "packets"
RaqMondsculativePacketLoss对象类型语法计数器32个单位“数据包”
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packets from this session whose loss
had been detected since the start of the session."
REFERENCE
"Section 5.20 of [RFC4710]"
::= { raqmonDsNotificationEntry 21 }
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packets from this session whose loss
had been detected since the start of the session."
REFERENCE
"Section 5.20 of [RFC4710]"
::= { raqmonDsNotificationEntry 21 }
raqmonDsPacketLossFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The percentage of lost packets with respect to the
overall packets sent. This is defined to be 100 times
the number of packets lost divided by the number of
packets expected."
REFERENCE
"Section 5.21 of [RFC4710]"
::= { raqmonDsNotificationEntry 22 }
raqmonDsPacketLossFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The percentage of lost packets with respect to the
overall packets sent. This is defined to be 100 times
the number of packets lost divided by the number of
packets expected."
REFERENCE
"Section 5.21 of [RFC4710]"
::= { raqmonDsNotificationEntry 22 }
raqmonDsCumulativeDiscards OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packet discards detected since the
start of the session."
REFERENCE
"Section 5.22 of [RFC4710]"
::= { raqmonDsNotificationEntry 23 }
raqmonDsCumulativeDiscards OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packet discards detected since the
start of the session."
REFERENCE
"Section 5.22 of [RFC4710]"
::= { raqmonDsNotificationEntry 23 }
raqmonDsDiscardsFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The percentage of discards with respect to the overall
packets sent. This is defined to be 100 times the number
of discards divided by the number of packets expected."
REFERENCE
"Section 5.23 of [RFC4710]"
::= { raqmonDsNotificationEntry 24 }
raqmonDsDiscardsFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The percentage of discards with respect to the overall
packets sent. This is defined to be 100 times the number
of discards divided by the number of packets expected."
REFERENCE
"Section 5.23 of [RFC4710]"
::= { raqmonDsNotificationEntry 24 }
raqmonDsSourcePayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet sent by this RDS."
REFERENCE
"RFC 1890, Section 5.24 of [RFC4710] "
::= { raqmonDsNotificationEntry 25 }
raqmonDsSourcePayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet sent by this RDS."
REFERENCE
"RFC 1890, Section 5.24 of [RFC4710] "
::= { raqmonDsNotificationEntry 25 }
raqmonDsReceiverPayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet received by this RDS."
REFERENCE
"RFC 1890, Section 5.25 of [RFC4710] "
::= { raqmonDsNotificationEntry 26 }
raqmonDsReceiverPayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet received by this RDS."
REFERENCE
"RFC 1890, Section 5.25 of [RFC4710] "
::= { raqmonDsNotificationEntry 26 }
raqmonDsSourceLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Source Layer 2 priority used by the data source to send
packets to the receiver by this data source during this
communication session."
REFERENCE
"Section 5.26 of [RFC4710]"
::= { raqmonDsNotificationEntry 27 }
raqmonDsSourceLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Source Layer 2 priority used by the data source to send
packets to the receiver by this data source during this
communication session."
REFERENCE
"Section 5.26 of [RFC4710]"
::= { raqmonDsNotificationEntry 27 }
raqmonDsSourceDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Layer 3 TOS/DSCP values used by the Data Source to
prioritize traffic sent."
REFERENCE
"Section 5.27 of [RFC4710]"
::= { raqmonDsNotificationEntry 28 }
raqmonDsSourceDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Layer 3 TOS/DSCP values used by the Data Source to
prioritize traffic sent."
REFERENCE
"Section 5.27 of [RFC4710]"
::= { raqmonDsNotificationEntry 28 }
raqmonDsDestinationLayer2Priority OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION
RaqMondsDestinationLayer2优先级对象类型语法Unsigned32（0..7）MAX-ACCESS可用于通知状态当前描述
"Destination Layer 2 priority. This is the priority used
by the peer communicating entity to send packets to the
data source."
REFERENCE
"Section 5.28 of [RFC4710]"
::= { raqmonDsNotificationEntry 29 }
"Destination Layer 2 priority. This is the priority used
by the peer communicating entity to send packets to the
data source."
REFERENCE
"Section 5.28 of [RFC4710]"
::= { raqmonDsNotificationEntry 29 }
raqmonDsDestinationDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Layer 3 TOS/DSCP values used by the
peer communicating entity to prioritize traffic
sent to the source."
REFERENCE
"Section 5.29 of [RFC4710]"
::= { raqmonDsNotificationEntry 30 }
raqmonDsDestinationDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Layer 3 TOS/DSCP values used by the
peer communicating entity to prioritize traffic
sent to the source."
REFERENCE
"Section 5.29 of [RFC4710]"
::= { raqmonDsNotificationEntry 30 }
raqmonDsCpuUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Latest available information about the total CPU
utilization."
REFERENCE
"Section 5.30 of [RFC4710]"
::= { raqmonDsNotificationEntry 31 }
raqmonDsCpuUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Latest available information about the total CPU
utilization."
REFERENCE
"Section 5.30 of [RFC4710]"
::= { raqmonDsNotificationEntry 31 }
raqmonDsMemoryUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Latest available information about the total memory
utilization."
REFERENCE
"Section 5.31 of [RFC4710]"
::= { raqmonDsNotificationEntry 32 }
raqmonDsMemoryUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Latest available information about the total memory
utilization."
REFERENCE
"Section 5.31 of [RFC4710]"
::= { raqmonDsNotificationEntry 32 }
-- definitions of the notifications
--
-- raqmonDsAppName is the only object that MUST be sent by an
-- RDS every time the static notification is generated.
-- definitions of the notifications
--
-- raqmonDsAppName is the only object that MUST be sent by an
-- RDS every time the static notification is generated.
-- raqmonDsTotalPacketsReceived is the only object that MUST be
-- sent by an RD every time the dynamic notification is generated.
-- raqmonDsTotalPacketsReceived is the only object that MUST be
-- sent by an RD every time the dynamic notification is generated.
-- Other objects from the raqmonDsNotificationTable may be
-- included in the variable binding list. Specifically, a raqmon
-- notification will include MIB objects that provide information
-- about metrics that characterize the application session
-- Other objects from the raqmonDsNotificationTable may be
-- included in the variable binding list. Specifically, a raqmon
-- notification will include MIB objects that provide information
-- about metrics that characterize the application session
raqmonDsStaticNotification NOTIFICATION-TYPE OBJECTS { raqmonDsAppName } STATUS current DESCRIPTION "This notification maps the static parameters in the BASIC RAQMON PDU onto an SNMP transport. This notification is expected to be sent once per session, or when a new sub-session is initiated. The following objects MAY be carried by the raqmonDsStaticNotification:
raqmonDsStaticNotification-TYPE对象{raqmonDsAppName}状态当前描述“此通知将基本RAQMON PDU中的静态参数映射到SNMP传输。此通知预期在每个会话中发送一次，或者在启动新的子会话时发送一次。raqmonDsStaticNotification可携带以下物品：
raqmonDsDataSourceDevicePort, raqmonDsReceiverDevicePort, raqmonDsSessionSetupDateTime, raqmonDsSessionSetupDelay, raqmonDsSessionDuration, raqmonDsSourcePayloadType, raqmonDsReceiverPayloadType, raqmonDsSourceLayer2Priority, raqmonDsSourceDscp, raqmonDsDestinationLayer2Priority, raqmonDsDestinationDscp
raqmonDsDataSourceDevicePort、RaqMondsReceiveDevicePort、RaqMondsessionSetupDateTime、RaqMondsessionSetupDelay、RaqMondsessionDuration、RaqMondsourcePayloadType、RaqMondsReceivePayloadType、RaqMondsourceayer2优先级、RaqMondsourcedSCP、RaqMondsDestinationLayer2优先级、raqmonDsDestinationDscp
It is RECOMMENDED to keep the size of a notification
within the MTU size limits in order to avoid
fragmentation."
::= { raqmonDsNotifications 1 }
It is RECOMMENDED to keep the size of a notification
within the MTU size limits in order to avoid
fragmentation."
::= { raqmonDsNotifications 1 }
raqmonDsDynamicNotification NOTIFICATION-TYPE OBJECTS { raqmonDsTotalPacketsReceived } STATUS current DESCRIPTION "This notification maps the dynamic parameters in the BASIC RAQMON PDU onto an SNMP transport.
raqmonDsDynamicNotification通知类型对象{raqmonDsTotalPacketsReceived}状态当前描述“此通知将基本RAQMON PDU中的动态参数映射到SNMP传输。
The following objects MAY be carried by the raqmonDsDynamicNotification:
raqmonDsDynamicNotification可携带以下物体：
raqmonDsRoundTripEndToEndNetDelay, raqmonDsOneWayEndToEndNetDelay,
raqmonDsRoundTripEndToEndNetDelay，RaqMondsOnWayendToEndNetDelay，
raqmonDsApplicationDelay, raqmonDsInterArrivalJitter, raqmonDsIPPacketDelayVariation, raqmonDsTotalPacketsSent, raqmonDsTotalOctetsReceived, raqmonDsTotalOctetsSent, raqmonDsCumulativePacketLoss, raqmonDsPacketLossFraction, raqmonDsCumulativeDiscards, raqmonDsDiscardsFraction, raqmonDsCpuUtilization, raqmonDsMemoryUtilization
RaqMondApplicationDelay、RaqMondSinterarivalJitter、raqmonDsIPPacketDelayVariation、RaqMondStotalPacketSent、raqmonDsTotalOctetsReceived、raqmonDsTotalOctetsSent、RaqMondSimulativePacketLoss、RaqMondPacketLoss分数、RaqMondSculativeDiscards、RaqMondScpu利用率、raqmonDsMemoryUtilization
It is RECOMMENDED to keep the size of a notification within the MTU size limits in order to avoid fragmentation."
建议将通知的大小保持在MTU大小限制内，以避免碎片。”
::= { raqmonDsNotifications 2 }
::= { raqmonDsNotifications 2 }
raqmonDsByeNotification NOTIFICATION-TYPE
OBJECTS { raqmonDsAppName }
STATUS current
DESCRIPTION
"The BYE Notification. This Notification is the
equivalent of the RAQMON NULL PDU, which signals the
end of a RAQMON session."
::= { raqmonDsNotifications 3 }
raqmonDsByeNotification NOTIFICATION-TYPE
OBJECTS { raqmonDsAppName }
STATUS current
DESCRIPTION
"The BYE Notification. This Notification is the
equivalent of the RAQMON NULL PDU, which signals the
end of a RAQMON session."
::= { raqmonDsNotifications 3 }
--
-- conformance information
raqmonDsCompliance OBJECT IDENTIFIER ::=
{ raqmonDsConformance 1 }
raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 }
--
-- conformance information
raqmonDsCompliance OBJECT IDENTIFIER ::=
{ raqmonDsConformance 1 }
raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 }
raqmonDsBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement this MIB module.
raqmonDsBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION“实现此MIB模块的SNMP实体的符合性声明。
There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which we have the following compliance requirements, expressed in OBJECT clause form in this description clause:
有许多索引对象无法在SMIv2中以对象条款的形式表示，但我们对其有以下符合性要求，在本说明条款中以对象条款的形式表示：
-- OBJECT raqmonDsPeerAddrType
-- SYNTAX InetAddressType { ipv4(1), ipv6(2) }
-- OBJECT raqmonDsPeerAddrType
-- SYNTAX InetAddressType { ipv4(1), ipv6(2) }
-- DESCRIPTION
-- This MIB requires support for only global IPv4
-- and IPv6 address types.
--
-- OBJECT raqmonDsPeerAddr
-- SYNTAX InetAddress (SIZE(4|16))
-- DESCRIPTION
-- This MIB requires support for only global IPv4
-- and IPv6 address types.
--
"
MODULE -- this module
MANDATORY-GROUPS { raqmonDsNotificationGroup,
raqmonDsPayloadGroup }
::= { raqmonDsCompliance 1 }
-- DESCRIPTION
-- This MIB requires support for only global IPv4
-- and IPv6 address types.
--
-- OBJECT raqmonDsPeerAddr
-- SYNTAX InetAddress (SIZE(4|16))
-- DESCRIPTION
-- This MIB requires support for only global IPv4
-- and IPv6 address types.
--
"
MODULE -- this module
MANDATORY-GROUPS { raqmonDsNotificationGroup,
raqmonDsPayloadGroup }
::= { raqmonDsCompliance 1 }
raqmonDsNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { raqmonDsStaticNotification,
raqmonDsDynamicNotification,
raqmonDsByeNotification }
STATUS current
DESCRIPTION
"Standard RAQMON Data Source Notification group."
::= { raqmonDsGroups 1 }
raqmonDsNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { raqmonDsStaticNotification,
raqmonDsDynamicNotification,
raqmonDsByeNotification }
STATUS current
DESCRIPTION
"Standard RAQMON Data Source Notification group."
::= { raqmonDsGroups 1 }
raqmonDsPayloadGroup OBJECT-GROUP OBJECTS { raqmonDsAppName, raqmonDsDataSourceDevicePort, raqmonDsReceiverDevicePort, raqmonDsSessionSetupDateTime, raqmonDsSessionSetupDelay, raqmonDsSessionDuration, raqmonDsSessionSetupStatus, raqmonDsRoundTripEndToEndNetDelay, raqmonDsOneWayEndToEndNetDelay, raqmonDsApplicationDelay, raqmonDsInterArrivalJitter, raqmonDsIPPacketDelayVariation, raqmonDsTotalPacketsReceived, raqmonDsTotalPacketsSent, raqmonDsTotalOctetsReceived, raqmonDsTotalOctetsSent, raqmonDsCumulativePacketLoss, raqmonDsPacketLossFraction, raqmonDsCumulativeDiscards, raqmonDsDiscardsFraction, raqmonDsSourcePayloadType, raqmonDsReceiverPayloadType,
raqmonDsPayloadGroup对象组对象{raqmonDsAppName、raqmonDsDataSourceDevicePort、RaqMondsReceiveDevicePort、RaqMondsessionSetupDateTime、RaqMondsessionSetupDelay、RaqMondsessionDuration、RaqMondsSetupStatus、raqmonDsRoundTripEndToEndNetDelay、RaqMondsOnWayendNetDelay、raqmonDsApplicationDelay、RaqMondsInTerravalJitter、raqmonDsIPPacketDelayVariation、raqmonDsT收到的总包裹，收到的包裹，收到的包裹，收到的包裹，收到的包裹，收到的包裹，收到的包裹，收到的包裹，收到的包裹，
raqmonDsSourceLayer2Priority,
raqmonDsSourceDscp,
raqmonDsDestinationLayer2Priority,
raqmonDsDestinationDscp,
raqmonDsCpuUtilization,
raqmonDsMemoryUtilization }
STATUS current
DESCRIPTION
"Standard RAQMON Data Source payload MIB objects group."
::= { raqmonDsGroups 2 }
raqmonDsSourceLayer2Priority,
raqmonDsSourceDscp,
raqmonDsDestinationLayer2Priority,
raqmonDsDestinationDscp,
raqmonDsCpuUtilization,
raqmonDsMemoryUtilization }
STATUS current
DESCRIPTION
"Standard RAQMON Data Source payload MIB objects group."
::= { raqmonDsGroups 2 }
END
终止
Applications using the RAQMON Framework require a single fixed port. Port number 7744 is registered with IANA for use as the default port for RAQMON PDUs over TCP. Hosts that run multiple applications may use this port as an indication to have used RAQMON or provision a separate TCP port as part of provisioning RAQMON RDS and RAQMON Collector.
使用RAQMON框架的应用程序需要一个固定端口。端口号7744已向IANA注册，用作TCP上RAQMON PDU的默认端口。运行多个应用程序的主机可以使用此端口作为已使用RAQMON的指示，或者在设置RAQMON RDS和RAQMON Collector时提供单独的TCP端口。
The particular port number was chosen to lie in the range above 5000 to accommodate port number allocation practice within the Unix operating system, where privileged processes can only use port numbers below 1024 and port numbers between 1024 and 5000 are automatically assigned by the operating systems.
选择的特定端口号在5000以上的范围内，以适应Unix操作系统中的端口号分配实践，其中特权进程只能使用1024以下的端口号，1024和5000之间的端口号由操作系统自动分配。
The OID assignment for the raqmonDsMIB MODULE-IDENTITY is made according to [RFC3737], and there is no need for any IANA action on this respect.
raqmonDsMIB模块标识的OID分配根据[RFC3737]进行，不需要IANA在这方面采取任何行动。
As outlined in earlier sections, the TCP congestion control mechanism provides inherent congestion safety features when TCP is implemented as transport to carry RAQMON PDU.
如前几节所述，当TCP实现为携带RAQMON PDU的传输时，TCP拥塞控制机制提供了固有的拥塞安全特性。
To ensure congestion safety, clearly the best thing to do is to use a congestion-safe transport protocol such as TCP. If this is not feasible, it may be necessary to fall back to UDP since SNMP over UDP is a widely deployed transport protocol.
为了确保拥塞安全，显然最好的办法是使用拥塞安全传输协议，如TCP。如果这不可行，则可能需要退回到UDP，因为UDP上的SNMP是一种广泛部署的传输协议。
When SNMP is chosen as RAQMON PDU Transport, implementers MUST follow section 3 of [RFC4710], which outlines measures that MUST be taken to use RAQMON in a congestion-safe manner. Congestion safety
当选择SNMP作为RAQMON PDU传输时，实施者必须遵循[RFC4710]的第3节，该节概述了以拥塞安全方式使用RAQMON必须采取的措施。拥挤安全
requirements in section 3 of [RFC4710] would ensure that a RAQMON implementation using SNMP over UDP does not lead to congestion under heavy network load.
[RFC4710]第3节中的要求将确保使用SNMP over UDP的RAQMON实现不会在重网络负载下导致拥塞。
The authors would like to thank Bill Walker and Joseph Mastroguilio from Avaya and Bin Hu from Motorola for their discussions. 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. The Security Considerations section was reviewed by Sam Hartman and Kurt D. Zeilenga and almost completely re-written by Mahalingam Mani.
作者要感谢来自Avaya的Bill Walker和Joseph Mastrogilio以及来自Motorola的Bin Hu的讨论。作者还想特别感谢Randy Presohn，他为拼写和格式目的审查了本文件，并对技术内容进行了深入审查。我们还要感谢Bert Wijnen在本文件编写过程中提供的长期指导以及对最终版本的详细审查。安全考虑部分由Sam Hartman和Kurt D.Zeilenga审查，几乎完全由Mahalingam Mani重新编写。
[RFC4710] outlines a threat model associated with RAQMON and security considerations to be taken into account in the RAQMON specification to mitigate against those threats. It is imperative that RAQMON PDU implementations be able to provide the following protection mechanisms in order to attain end-to-end security:
[RFC4710]概述了与RAQMON相关的威胁模型，以及RAQMON规范中要考虑的安全注意事项，以缓解这些威胁。RAQMON PDU实现必须能够提供以下保护机制，以实现端到端安全性：
1. Authentication: The RRC SHOULD be able to verify that a RAQMON report was originated by the RDS claiming to have sent it. At minimum, an RDS/RRC pair MUST use a digest-based authentication procedure to authenticate, like the one defined in [RFC1321].
1. 身份验证：RRC应能够验证RAQMON报告是否由声称已发送该报告的RDS发起。至少，RDS/RRC对必须使用基于摘要的身份验证过程进行身份验证，如[RFC1321]中定义的过程。
2. Privacy: RAQMON information includes identification of the parties participating in a communication session. RAQMON deployments SHOULD be able to provide protection from eavesdropping, and to prevent an unauthorized third party from gathering potentially sensitive information. This can be achieved by using secure transport protocols supporting confidentiality based on encryption technologies such as DES (Data Encryption Standard), [3DES], and AES (Advanced Encryption Standard) [AES].
2. 隐私：RAQMON信息包括参与通信会话的各方的身份。RAQMON部署应能够提供防止窃听的保护，并防止未经授权的第三方收集潜在的敏感信息。这可以通过使用支持基于加密技术（如DES（数据加密标准）、[3DES]和AES（高级加密标准）[AES]的保密性的安全传输协议来实现。
3. Protection from DoS attacks directed at the RRC: RDSs send RAQMON reports as a side effect of external events (for example, receipt of a phone call). An attacker can try to overwhelm the RRC (or the network) by initiating a large number of events in order to swamp the RRC with excessive numbers of RAQMON PDUs.
3. 防止针对RRC的DoS攻击：RDS发送RAQMON报告作为外部事件的副作用（例如，收到电话）。攻击者可以尝试通过启动大量事件来压倒RRC（或网络），以便用过多的RAQMON PDU淹没RRC。
To prevent DoS attacks against the RRC, the RDS will send the first report for a session only after the session has been established, so that the session set-up process is not affected.
为了防止针对RRC的DoS攻击，RDS将仅在会话建立后发送会话的第一次报告，这样会话设置过程不会受到影响。
4. NAT and Firewall Friendly Design: The presence of IP addresses and TCP/UDP port information in RAQMON PDUs may be NAT-unfriendly. Where NAT-friendliness is a requirement, the RDS MAY omit IP address information from the RAQMON PDU. Another way to avoid this problem is by using NAT-Aware Application Layer Gateways (ALGs) to ensure that correct IP addresses appear in RAQMON PDUs.
4. NAT和防火墙友好设计：RAQMON PDU中的IP地址和TCP/UDP端口信息可能对NAT不友好。在需要NAT友好性的情况下，RDS可以从RAQMON PDU中省略IP地址信息。避免此问题的另一种方法是使用NAT感知的应用层网关（ALG），以确保RAQMON PDU中显示正确的IP地址。
For the usage of TCP, TLS MUST be used to provide transport layer security. Section 6.1 describes the usage of TLS with RAQMON.
对于TCP的使用，必须使用TLS来提供传输层安全性。第6.1节描述了TLS与RAQMON的使用。
This memo also defines the RAQMON-RDS-MIB module with the purpose of mapping the RAQMON PDUs into SNMP Notifications. To attain end-to-end security, the following measures have been taken in the RAQMON-RDS-MIB module design:
本备忘录还定义了RAQMON-RDS-MIB模块，用于将RAQMON PDU映射到SNMP通知中。为了实现端到端的安全性，在RAQMON-RDS-MIB模块设计中采取了以下措施：
There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. Consequently, if this MIB module is implemented correctly, there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations.
此MIB模块中未定义具有读写和/或读创建MAX-ACCESS子句的管理对象。因此，如果正确实现此MIB模块，则入侵者不会通过直接的SNMP设置操作更改或创建此MIB模块的任何管理对象。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
在某些网络环境中，此MIB模块中的某些可读对象（即具有MAX-ACCESS而非not ACCESS的对象）可能被视为敏感或易受攻击。因此，在通过SNMP通过网络发送这些对象时，控制甚至获取和/或通知对这些对象的访问，甚至可能加密这些对象的值，这一点非常重要。以下是表和对象及其敏感度/漏洞：
raqmonDsNotificationTable
raqmonDsNotificationTable
The objects in this table contain user session information, and their disclosure may be sensitive in some environments.
此表中的对象包含用户会话信息，在某些环境中，这些对象的公开可能很敏感。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv3之前的SNMP版本未包含足够的安全性。即使网络本身是安全的（例如通过使用IPsec），即使如此，也无法控制安全网络上的谁可以访问和获取/设置（读取/更改/创建/删除）此MIB模块中的对象。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and confidentiality).
建议实施者考虑SNMPv3框架所提供的安全特性（参见[RCFC310]，第8节），包括对SNMPv3加密机制的完全支持（用于身份验证和机密性）。
It is a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
客户/运营商有责任确保授予访问此MIB模块实例权限的SNMP实体正确配置为仅授予具有确实获取或设置（更改/创建/删除）对象的合法权限的主体（用户）访问对象。
The subsequently authorized RAQMON data flow itself is protected by the same TLS security association that protects the client-side exchange. This standard TLS channel is now bound to the server through the above client-side authentication. The session itself is identified by the tuple {RDS ip-address:RDS_port / RRC ip-address: RRC port}.
随后授权的RAQMON数据流本身受保护客户端交换的同一TLS安全关联的保护。此标准TLS通道现在通过上述客户端身份验证绑定到服务器。会话本身由元组{RDS ip address:RDS_port/RRC ip address:RRC port}标识。
Several issues should be considered when selecting TLS ciphersuites that are appropriate for use in a given circumstance. These issues include the following:
在选择适用于特定环境的TLS密码套件时，应考虑几个问题。这些问题包括：
The ciphersuite's ability to provide adequate confidentiality protection for passwords and other data sent over the transport connection. Client and server implementers should recognize that some TLS ciphersuites provide no confidentiality protection, while other ciphersuites that do provide confidentiality protection may be vulnerable to being cracked using brute force methods, especially in light of ever-increasing CPU speeds that reduce the time needed to successfully mount such attacks.
密码套件能够为通过传输连接发送的密码和其他数据提供充分的保密保护。客户机和服务器实现者应认识到，某些TLS密码套件不提供保密保护，而其他提供保密保护的密码套件可能容易被暴力破解，特别是考虑到CPU速度不断提高，从而缩短了成功实施此类攻击所需的时间。
Client and server implementers should carefully consider the value of the password or data being protected versus the level of confidentiality protection provided by the ciphersuite to ensure that the level of protection afforded by the ciphersuite is appropriate.
客户端和服务器实现者应该仔细考虑密码或数据的保护值，而不是密码组提供的机密保护级别，以确保密码组提供的保护级别是合适的。
The ciphersuite's vulnerability (or lack thereof) to man-in-the-middle attacks. Ciphersuites vulnerable to man-in-the-middle attacks SHOULD NOT be used to protect passwords or sensitive data, unless the network configuration is such that the danger of a man-in-the-middle attack is negligible.
密码套件对中间人攻击的脆弱性（或缺乏脆弱性）。易受中间人攻击的密码套件不应用于保护密码或敏感数据，除非网络配置使得中间人攻击的危险可以忽略不计。
After a TLS negotiation (either initial or subsequent) is completed, both protocol peers should independently verify that the security services provided by the negotiated ciphersuite are adequate for the intended use of the RAQMON session. If not, the TLS layer should be closed.
TLS协商（初始协商或后续协商）完成后，两个协议对等方应独立验证协商后的密码套件提供的安全服务是否足以满足RAQMON会话的预期用途。否则，应关闭TLS层。
Spoofing Attacks: When anonymous TLS alone is negotiated without client authentication, the client's identity is never established. This easily allows any end-entity to establish a TLS-secured RAQMON connection to the RRC. This not only offers an opportunity to spoof legitimate RDS clients and hence compromise the integrity of RRC monitoring data, but also opens the RRC up to unauthorized clients posing as genuine RDS entities to launch a DoS by flooding data. RAQMON deployment policy MUST consider requiring RDS client authentication during TLS session establishment, especially when RDS clients communicate across unprotected internet.
欺骗攻击：当匿名TLS在没有客户端身份验证的情况下单独协商时，客户端的身份永远不会建立。这很容易让任何终端实体建立到RRC的TLS安全RAQMON连接。这不仅提供了欺骗合法RDS客户端的机会，从而损害RRC监控数据的完整性，而且还使RRC向冒充真实RDS实体的未经授权客户端开放，以通过洪泛数据启动DoS。RQMON部署策略必须考虑在TLS会话建立期间需要RDS客户端身份验证，特别是当RDS客户端在无保护Internet上通信时。
Insider attacks: Even client-authenticated TLS connections are open to spoofing attacks by one trusted client on another. Validation of RDS source address against RDS TLS-session source address SHOULD be performed to detect such attempts.
内部攻击：即使是经过客户端验证的TLS连接也会受到一个受信任客户端对另一个受信任客户端的欺骗攻击。应根据RDS TLS会话源地址验证RDS源地址，以检测此类尝试。
Every RAQMON session (between RDS and RRC) has an associated authorization state. This state is comprised of numerous factors such as what (if any) authorization state has been established, how it was established, and what security services are in place. Some factors may be determined and/or affected by protocol events (e.g., StartTLS, or TLS closure), and some factors may be determined by external events (e.g., time of day or server load).
每个RAQMON会话（RDS和RRC之间）都有一个相关的授权状态。该状态由许多因素组成，如已建立了什么（如果有的话）授权状态、如何建立授权状态以及有哪些安全服务。一些因素可能由协议事件（例如StartTLS或TLS关闭）确定和/或影响，而一些因素可能由外部事件（例如一天中的时间或服务器负载）确定。
While it is often convenient to view authorization state in simplistic terms (as we often do in this technical specification) such as "an anonymous state", it is noted that authorization systems in RAQMON implementations commonly involve many factors that interrelate.
虽然用简单的术语（正如我们在本技术规范中经常做的那样）查看授权状态（如“匿名状态”）通常很方便，但需要注意的是，RAQMON实现中的授权系统通常涉及许多相互关联的因素。
Authorization in RAQMON is a local matter. One of the key factors in making authorization decisions is authorization identity. The initial session establishment defined in Section 2.2 allows information to be exchanged between the client and server to establish an authorization identity for the RAQMON session. The RRC is not to allow any RDS-transactions-related traffic through for processing until the client authentication is complete, unless anonymous authentication mode is negotiated.
RAQMON的授权是本地事务。做出授权决策的关键因素之一是授权标识。第2.2节中定义的初始会话建立允许在客户端和服务器之间交换信息，以建立RAQMON会话的授权标识。除非协商匿名身份验证模式，否则RRC不允许任何与RDS事务相关的流量通过进行处理，直到客户端身份验证完成。
Upon initial establishment of the RAQMON session, the session has an anonymous authorization identity. Among other things, this implies that the client need not send a TLSStartRequired in the first PDU of the RAQMON message. The client may send any operation request prior to binding RDS to any authentication, and the RRC MUST treat it as if it had been performed after an anonymous RAQMON session start.
在初始建立RAQMON会话时，会话具有匿名授权标识。除其他事项外，这意味着客户端不需要在RAQMON消息的第一个PDU中发送TLSStartRequired。客户端可以在将RDS绑定到任何身份验证之前发送任何操作请求，RRC必须将其视为在匿名RAQMON会话启动后执行的操作请求。
The RDS automatically is placed in an unauthorized state upon RRC sending a TLSstart request to the RRC.
RRC向RRC发送TLSstart请求时，RDS会自动处于未经授权状态。
It is noted that other events both internal and external to RAQMON may result in the authentication and authorization states being moved to an anonymous one. For instance, the establishment, change, or closure of data security services may result in a move to an anonymous state, or the user's credential information (e.g., certificate) may have expired. The former is an example of an event internal to RAQMON, whereas the latter is an example of an event external to RAQMON.
需要注意的是，RAQMON内部和外部的其他事件可能会导致身份验证和授权状态移动到匿名状态。例如，数据安全服务的建立、更改或关闭可能导致移动到匿名状态，或者用户的凭证信息（例如，证书）可能已过期。前者是RAQMON内部事件的示例，而后者是RAQMON外部事件的示例。
[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月。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.，和S.Waldbusser，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.，和S.Waldbusser，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.，和S.Waldbusser，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000.
[RFC2819]Waldbusser，S.，“远程网络监控管理信息库”，STD 59，RFC 2819，2000年5月。
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
[RFC3289]Baker，F.，Chan，K.和A.Smith，“差异化服务体系结构的管理信息库”，RFC 3289，2002年5月。
[RFC3411] Harrington, D., Preshun, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Preshun，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwalder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001]Daniele，M.，Haberman，B.，Routhier，S.，和J.Schoenwalder，“互联网网络地址的文本约定”，RFC 4001，2005年2月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON)", RFC 4710, October 2006.
[RFC4710]Siddiqui，A.，Romascanu，D.，和E.Golovinsky，“实时应用程序服务质量监控（RAQMON）”，RFC 47102006年10月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[3DES] Americation National Standards Institute, "Triple Data Encryption Algorithm Modes of Operation", ANSI X9.52-1998.
[3DES]美国国家标准协会，“三重数据加密算法操作模式”，ANSI X9.52-1998。
[AES] Federal Information Processing Standard (FIPS), "Specifications for the ADVANCED ENCRYPTION STANDARD(AES)", Publication 197, November 2001.
[AES]联邦信息处理标准（FIPS），“高级加密标准（AES）规范”，第197号出版物，2001年11月。
[IEEE802.1D] "Information technology-Telecommunications and information exchange between systems--Local and metropolitan area networks-Common Specification a--Media access control (MAC) bridges:15802-3: 1998(ISO/IEC)", [ANSI/IEEE Std 802.1D Edition], 1998.
[IEEE802.1D]“系统间信息技术电信和信息交换——局域网和城域网通用规范a——媒体访问控制（MAC）网桥：15802-3:1998（ISO/IEC）”，[ANSI/IEEE标准802.1D版]，1998年。
[RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议版本3”，RFC1305，1992年3月。
[RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“消息摘要算法MD5”，RFC13211992年4月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, December 2002.
[RFC3414]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”，RFC 34142002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3737] Wijnen, B. and A. Bierman, "IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules", RFC 3737, April 2004.
[RFC3737]Wijnen，B.和A.Bierman，“远程监控（RMON）MIB模块注册的IANA指南”，RFC 3737，2004年4月。
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]Harrison，R.，“轻量级目录访问协议（LDAP）：认证方法和安全机制”，RFC4513，2006年6月。
[TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[TLS-PSK]Eronen，P.和H.Tschofenig，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月。
The implementation notes included in Appendix are for informational purposes only and are meant to clarify the RAQMON specification.
附录中的实施说明仅供参考，旨在澄清RAQMON规范。
Pseudocode for RDS & RRC
RDS和RRC的伪代码
We provide examples of pseudocode for aspects of RDS and RRC. There may be other implementation methods that are faster in particular operating environments or have other advantages.
我们提供了RDS和RRC方面的伪代码示例。在特定的操作环境中，可能有其他更快的实现方法，或者具有其他优势。
RDS:
when (session starts} {
report.identifier = session.endpoints, session.starttime;
report.timestamp = 0;
while (session in progress) {
wait interval;
report.statistics = update statistics;
report.curtimestamp += interval;
if encryption required
report_data = encrypt(report, encrypt parameters);
else
report_data = report;
raqmon_pdu = header, report_data;
send raqmon-pdu;
}
}
RDS:
when (session starts} {
report.identifier = session.endpoints, session.starttime;
report.timestamp = 0;
while (session in progress) {
wait interval;
report.statistics = update statistics;
report.curtimestamp += interval;
if encryption required
report_data = encrypt(report, encrypt parameters);
else
report_data = report;
raqmon_pdu = header, report_data;
send raqmon-pdu;
}
}
RRC: listen on raqmon port when ( raqmon_pdu received ) { decrypt raqmon_pdu.data if needed
RRC：在（接收到raqmon_pdu）{解密raqmon_pdu.data（如果需要）时侦听raqmon端口
if report.identifier in database if report.current_time_stamp > last update update session statistics from report.statistics else discard report }
数据库中的if report.identifier if report.current_time_stamp>上次更新更新会话统计信息from report.statistics else discard report}
Authors' Addresses
作者地址
Anwar Siddiqui Avaya 307 Middletown Lincroft Road Lincroft, NJ 80302 USA
美国新泽西州林克罗夫特市林克罗夫特中路307号安瓦尔·西迪基·阿瓦亚80302
Phone: +1 732 852-3200
EMail: anwars@avaya.com
Phone: +1 732 852-3200
EMail: anwars@avaya.com
Dan Romascanu Avaya Atidim Technology Park, Bldg #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 Alert Logic
尤金·戈洛文斯基警报逻辑
Phone: +1 713 918-1816
EMail: gene@alertlogic.net
Phone: +1 713 918-1816
EMail: gene@alertlogic.net
Mahfuzur Rahman Samsung Information Systems America 75 West Plumeria Drive San Jose, CA 95134 USA
Mahfuzur Rahman三星信息系统美国加利福尼亚州圣何塞市西普洛玛丽亚大道75号，邮编95134
Phone: +1 408 544-5559
电话：+1408 544-5559
Yongbum Yong Kim Broadcom 3151 Zanker Road San Jose, CA 95134 USA
Yongbum Yong Kim Broadcom美国加利福尼亚州圣何塞市赞克路3151号，邮编95134
Phone: +1 408 501-7800
EMail: ybkim@broadcom.com
Phone: +1 408 501-7800
EMail: ybkim@broadcom.com
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）提供。