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)
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).
このメモはRAQMONからRAQMON情報を運ぶためにネイティブの輸送および簡易ネットワーク管理プロトコル（SNMP）としてTCPを使用して、RFC 4710で定義されたリアルタイムアプリケーションサービス品質のモニタリング（RAQMON）情報モデルの2つのトランスポートマッピングを指定しますRAQMONレポートコレクタ（RRC）へのデータソース（RDS）。
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
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]で概説として、（RAQMON）フレームワークを監視するリアルタイムアプリケーションのQoS、）などRAQMONデータソースRDSなどのエンティティを定義することにより、プロトコルのリモートモニタリングファミリー（RMON）を拡張し、RAQMONレポートコレクター（RRC）、各種アプリケーションを実行しますリアルタイムで監視。 [RFC4710]はQoS統計を報告するためにRDSとRRCとの間で使用される一般的なプロトコルデータユニット（PDU）によって運ばRAQMON監視に関連するメトリックを定義します。このメモはRAQMON PDUの構造の構文の記述が含まれています。
The following sections of this memo contain detailed specifications for the usage of TCP and SNMP to carry RAQMON information.
このメモの次のセクションでは、RAQMON情報を運ぶためにTCPおよびSNMPの使用方法の詳細な仕様が含まれています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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は、アプリケーションデータを転送ではなく、プロトコル・スタックのアプリケーション層でペイロード仕様の位置を占めていません。仕様の一部として、このメモはまた、RDSにとRRCs間RAQMON PDUを運ぶために基礎となるトランスポートプロトコルとしてTCPおよびSNMPの使用方法を指定します。 2つのトランスポート・プロトコルの選択は、RDSの実装のために選んだのためのオプションとして提供されているが、RRCsは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.
TCPを用いた結合の輸送は、ボイスオーバーIP、のWi-Fi経由での音声、IPオーバーファックス、IP上のビデオ、インスタントメッセージング（IM）、Eなどのアプリケーションを実行する組み込み機器の様々なタイプから報告を容易にするために、RAQMON仕様の範囲内に含まれています-mail、ソフトウェアダウンロードアプリケーション、eビジネススタイルの取引、これらのデバイスの多くにとって、有線または無線のコンピューティングデバイスなどからのウェブアクセス、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輸送要件は、本質的に、トランスポートプロトコル[RFC793]としてTCPに組み込まれています。
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.
RAQMON PDUを転送するためにTCPを使用するには、TCPデータとしてPDUを送信するのに十分です。各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の仕様を詳しく説明しています。ベンダ固有の拡張[RFC4710]のために必要な基本的な部分とアプリケーションの拡張：一つのプロトコルデータユニットとして送信するのに、RAQMON PDUは、機能的に2つの異なる部分に分割されます。両方の機能部は、PDUで運ばれる情報を定義した組織を識別するために使用される現在IANA http://www.iana.org/assignments/enterprise-numbersによって維持SMIネットワーク管理プライベートエンタープライズコードを運ぶフィールドをたどります。
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）= RAQMONのPDUによって運ばれる1パラメータとしてマークされているが、図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の基本的な部分を使用しなければなりません。ベンダーはまた用途向け、ベンダーを伝えるために、アプリケーション固有の拡張機能を使用したり、デバイス固有のパラメータは、仕様のBASIC一部に含まれており、明示的に拡張された相互運用性を達成するために外部からそのようなデータを公開していません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RAQMON Protocol Data Unit
図1：RAQMONプロトコルデータユニット
A RAQMON PDU must contain the following BASIC part fields at all times:
RAQMON PDUは、すべての回で、次のBASIC一部のフィールドが含まれている必要があります
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のBASIC一部に従うアプリケーション固有の拡張の合計数。基本的な情報に追加するアプリケーション固有の情報が存在しないようにゼロの値が何回も有効と考えられています。
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
パディング（P）：1ビット - パディングビットがセットされている場合、RAQMON PDUの基本的な部分は、監視情報に含まれていないPDUの基本的な部分の端部にいくつかの追加のパディングオクテットを含んでいます。報告は、特定のパラメータを報告するRDSの意図に基づいているパディングは、いくつかのケースで必要になる場合があります。また、いくつかのパラメータは、例えば、報告セッションの開始時に一度だけ報告されてもよい、PDUのBASIC一部の最後にデータソース名、レシーバー名、ペイロードタイプ、など実際のパディングは、0、8、16ですPDUの基本的な部分の長さを作る、または24ビット、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バージョンフラグ（S）：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の基本的な部分に含まれるアプリケーション・レコードの合計数。ゼロの値は、RDS報告セッションの終了を示すNULLのPDUの場合を除いて、有効しかし無駄であると考えられます。
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ビット（符号なし整数） - 32ビットワード単位でRAQMON PDUのBASIC一部の長さから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ビット - データソース識別子RDSとRRCとの間の特定の報告セッションを指し示す一意RAQMON報告セッション記述子を表します。 DSRCの一意性は、報告セッション内で有効です。 DSRC値は、ランダムに、各通信セッションのベンダー選択アルゴリズムを用いて生成されなければなりません。単に慎重に状態を初期化せずに（）を呼び出すことによってランダムDSRCを得るのに十分ではありません。一つは、DSRCを作成するために、[RFC3550]の付録A.6で定義されたもののようなアルゴリズムを使用することができます。アルゴリズムの選択に応じて、二つの異なるRDSにから2 DSRCsが同じであってもよいという有限の可能性があります。さらに、2つのRDSには、2つの異なる報告セッションに対して同じDSRCを選ぶ確率を減らすために、それはRRCは、データの送信元アドレス（DA）のようなパラメータを使用することが推奨され、データソース名（DN）、およびレイヤ2のメディアアクセス制御（MAC） DSRC値と併せてPDU内のアドレス。 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には、RDS報告セッションの終了を示すために、RRCにRAQMON NULL PDUを送らなければなりません。 NULL 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エンタープライズコード= 0の値はRAQMON PDUフォーマットのRMON-WG準拠基本的な部分を示すために使用されます。
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エンタープライズコード= 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の基本的な部分は、表1で定義されるように、レコード内の適切なRAQMONパラメータの存在を示すために番号（RC_N）とRAQMONパラメータ存在フラグ（RPPF）をカウントレコードから成ります。
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ビット - レコードカウント数が通信セッション内のサブセッションを示しています。ゼロの値が有効なレコード番号です。 1 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 |
| | |
| 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で定義されています。 IPv6アドレスが1にRAQMON PDUヘッダの送信元IPバージョンフラグ（Sビット）を設定することにより、データソースアドレスに組み込まれています。
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で定義されています。これは、データ・ソース・アドレスとまったく同じ構文に従いますが、レシーバのアドレスを示すために使用されます。 IPv6アドレスが1にRAQMON PDUヘッダの受信IPバージョンフラグ（Rビット）を設定することによって、受信機アドレスに組み込まれています。
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で定義された秒[RFC1305]にあるネットワークタイムプロトコル（NTP）のタイムスタンプ形式を使用して表されています。フル解像度NTPタイムスタンプは、最初の32ビットの整数部と最後の32ビットに小数部分を有する64ビットの符号なしの固定小数点数です。
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に定義されています。アプリケーション名フィールドには、UTF-8エンコーディングを使用して、テキスト自体に続くテキストの長さを記述し、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をサポートしていないデータソースは、PDUで64ビットの浪費を避けるために0に適切なRAQMONフラグを設定する必要があります。 NTPタイムスタンプは、セッションのセットアップ日付/時刻を提供することを意図しているので、サブセッションRC_Nのセットアップが完了した後にNTPタイムスタンプは、ネットワークリソースを効率的に使用するためには、最初のRAQMON PDUでのみ使用することを推奨しています。
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で定義されています。データソース名と同じように、受信者名]フィールドには、テキスト自体に続くテキストの長さを表す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ビット - このパラメータは、このRAQMON PDUを生成している間に失われたサブセッションRC_Nからのパケットの総数を表し、符号なし整数として[RFC4710]のセクション5.20に定義されています。
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ビット - このパラメータは、このRAQMON PDUを生成している間に廃棄されているサブセッションRC_Nからパケットの合計数を表す符号無し整数として[RFC4710]のセクション5.22に定義されています。
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ビット - このパラメータは、送信者によってサブセッションRC_N内で送信されたパケットの合計数を表す、符号なし整数として、[RFC4710]のセクション5.17に定義されています。
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に定義されている（すなわち、ヘッダやパディングを含まない）ペイロードのオクテットの総数は、サブ内の送信者がパケットで送信表します-session 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.
このパラメータは、[RFC4710]のセクション5.5で定義され、このRAQMON PDUを生成している間RC_Nセッション内のアプリケーションによって使用されるデータ・ソースが使用するポート番号を記載している - 16ビット：データソースデバイスポートが使用します。
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.
このパラメータは、[RFC4710]のセクション5.6で定義され、受信機に通信するためにアプリケーションによって使用される受信機ポートを記述する - 16ビット：受信装置ポートが使用します。これは、使用するソース・デバイス・ポートと同じ構文に従います。
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で定義されたが、3つのQoSがサブセッションRC_N中にこのデータ・ソースによって受信機にパケットを送信するために使用されるマーキング層を表します。
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で定義されたが、データ・ソースがそのような情報を知ることができれば、サブセッションRC_Nセッション中にデータ・ソースにパケットを送信するために受信機によって使用されるレイヤ2個のIEEE 802.1Dのプライオリティタグを表します。 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使用率は、値がセッションながらRDSを実行しているホストのCPU使用率のスナップショットを示すために、セッションRC_Nに関連するCPU使用率だけでなく、実際のCPU使用率だけではないことを示すべきである100の範囲0におけるパーセントで表されるRC_N進行中。
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アップ中に使用されるメモリの合計の割合を表します。メモリ使用率、メモリ使用率の値は、セッションRC_Nが、合計メモリ使用率に関連するだけでなく、メモリの使用率を示すべきセッションRC_Nの進行中に、エンドデバイスメモリの使用率のスナップショットを示すように0〜100パーセントで表されます。
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に定義され、フィールドの左端にバイナリ点で、固定小数点数として表現されます。メトリックが期待されたパケットの数で割った失われたパケットの数であると定義されます。値は制限、パケットの総数は256で除算した結果を乗算、期待パケットの総数（例えば、前方誤り訂正（FEC）のような任意のエラー保護を適用することの効果の後に）失わ割ることによって計算されます最大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の基本的な部分の端部における実際のパディングPDUのBASIC一部32ビットの倍数の長さを作る0、8、16、または24ビットです。
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のAPP部分は、モジュール方式および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 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.
ベンダーは、アプリケーション固有の拡張機能を設計し、出版することができます。どれRAQMON準拠のRRCは、ベンダーのSMIエンタープライズコードを認識できなければならないとレポートタイプのフィールドを使用して識別されたアプリケーション固有の拡張の存在を認識しなければなりません。図1に示すように、レポートタイプとアプリケーション長さフィールドは、常に一定の拡張フィールドのスタートに対してオフセットに配置されています。 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ビット（符号なし整数） - 32ビットワードでRAQMON PDUのアプリケーション部の長さから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).
すべての整数フィールドは、最上位バイト（オクテット）最初、つまり、ネットワークバイト順に搬送されます。このバイト順は、一般的にビッグエンディアンとして知られています。送信順序は、[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 (Data Source Address and Data Source Name) and the RRC (Receiver's Address and Receiver's Name).
RDSとRRC間のTCPトランスポート上で開始RAQMONセッションは、RRC、コレクタにRDSクライアントからの監視情報を運びます。 RRCは、RRC（データソースアドレスとデータソース名）とRRC（受信者のアドレスと受信者の名前）に自分自身を識別するために、RDSで使用される様々な識別子に基づいてクライアントを区別します。
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| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RAQMON StartTLS Request - TLS_REQ
図2：RAQMON StartTLSを要求 - TLS_REQ
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は、このPDUがTLS_REQレポートタイプによって区別され、図2のようTLS_REQ PDUを送信することによって、StartTLSを要求を送信します。
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| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RAQMON StartTLS Response - TLS_RESP
図3：RAQMON StartTLSをレスポンス - TLS_RESP
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は、このPDUがTLS_RESPレポートタイプによって区別される、図3のようTLS_RESP PDUを送信することによりStartTLSを要求に応答します。
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. |
+-------+------------------+----------------------------------------+
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をサポートしていない場合（設計によって、または現在の構成によるかどうか）、それはPROTO_ERRかの参照にするのresultCodeを設定しなければなりません。サーバは、紹介のにresultCodeを返した場合、フィールドをREFER RAQMONの実際の紹介値を含まなければなりません。サーバが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接続を確立できない場合、サーバーはUNAVAILを返さなければならない、またはサーバーがシャットダウン中である場合。クライアントはRAQMONセッションに進むことができ、StartTLSを操作を再試行したり、接続を終えるかもしれません。
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:
クライアントは、クライアントがStartTLSをリクエストを送ってはいけません、次のような場合にことを除いて、RAQMON（TCP）接続を確立した後、任意の時点でのStartTLS要求を送信することができます。
o if TLS is currently established on the connection, or
TLSは、現在の接続で確立された場合、O、または
o if RAQMON traffic is in progress on the connection.
RAMONトラフィックのoは、接続で進行中です。
The result of violating any of these requirements is a Result of OP_ERR, as described above in Table 2.
表2に上述したように、これらの要件のいずれかに違反した結果は、OP_ERRの結果です。
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を交渉することができる場合、サーバは成功のresultCodeが持つ拡張応答を返します。それができない場合には、上記文書その他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] TLSネゴシエーションを開始するために、サーバーへの基礎となるトランスポート接続を介して直接TLSレコードプロトコルでPDUを送信します。
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]に記載されているように使用するTLSまたはSSLのバージョンを交渉することは、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.
TLS接続がRAQMON接続の上に確立された後、双方の当事者が個別に達成し、セキュリティ保証レベルに基づいて継続するかどうかを決定する必要があります。 TLS接続の保証レベルを確認することは実装依存であり、1つのそれぞれのローカル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ポリシー許せば、RAQMONセッションのデータを送信するために進むことができ、再びTLSを起動しようとすることができます。
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.
man-in-the-middle攻撃を防ぐために、サーバーの証明書メッセージに提示されたクライアントは、サーバーのIDに対するサーバーのホスト名のその理解をチェックしなければなりません。
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ベースのIDと一致しない場合は、自動化されたクライアントは、接続を閉じ返却および/またはサーバのアイデンティティが疑わしいことを示すエラーをログに記録すべきです。
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 [RFC4513]の上にLDAPのため適用されるように我々はまた、同様のガイドラインに読者を参照してください。
Anonymous TLS authentication helps establish a TLS RAQMON session that offers
匿名TLS認証を提供していますTLS RAQMONセッションを確立するのに役立ちます
o server-authentication in course of TLS establishment and
TLS設立の過程でOサーバ認証と
o confidentiality and replay protection of RAQMON traffic, but
RAQMONトラフィックの機密性およびリプレイ保護Oが、
o no protection against man-in-the-middle attacks during session establishment and
Oセッション確立時のman-in-the-middle攻撃に対する保護と
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.
クライアントは、そのような別のDSRCに基づいて、以前のRAQMONセッションに関連する先行RRC状態として、TLSセッション確立時にキャッシュされたサーバ機能の情報を更新する必要があります。これは、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.
クライアントまたはサーバのどちらかが突然全体RAQMONセッションと基本的なTCP接続をドロップすることによって、その上に確立任意の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フレームワークの固有の目的でした。 RAQMON PDUを輸送するための手段としてSNMPの選択はRAQMONデータソース（のRDS）としてSNMPエージェントを実装する既存のインストールされたデバイスを使用しての意図によって動機付けました。
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 TCPトランスポートの使用方法は、RDS / RRCのペアのためにどこでも利用できるSNMPトランスポート上の展開で推奨されます。
o The usage of Inform PDUs is RECOMMENDED.
O 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: 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.
SNMPはRAQMON PDUを搬送するための機構として選択される場合、以下の明細書は、SNMPのRAQMON関連使用に適用：のRDS oをRAQMON統計情報を報告するために、再使用して、周知のSNMPメカニズムをSNMP通知にRAQMONパラメータを埋め込む機能を実現します。 RAQMON RDS MIBモジュール、2.1.1で指定されるように、SNMP通知輸送にRAQMON PDUをマッピングするために使用されなければなりません。
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には、実装するために必要なGETとSETコマンドを除き、などGET、SET、などのSNMP要求に応答に失敗することがあります[RFC3414]で定義されたユーザベースセキュリティモデル（USM）。
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が使用されているINFORM場合、のRDSは、SNMPはRRCsからの応答を通知し、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モジュールは、輸送のためにSNMP通知にRAQMON PDUをマッピングするために使用されます。 MIBモジュールは、[RFC4710]で定義されたRAQMON PDUのBASIC一部をマッピングするために必要とされるオブジェクト、ならびに通知自体を定義します。 MIBモジュールに記載されているように、アプリケーション内の任意のアプリケーション固有の拡張（APP）RAQMON PDUの一部を組み込むために、[RFC4710]で定義されるように、追加の変数バインディングはRAQMON通知に含まれるかもしれ。
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）の構造で定義されたメカニズムを使用して定義されています。このメモは、STD 58、[RFC2578]、STD 58、[RFC2579]とSTD 58、[RFC2580]に記載されているSMIv2のに準拠しているMIBモジュールを指定します。
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]
It also uses REFERENCE clauses to refer to [RFC4710].
また、[RFC4710]を参照するためにREFERENCE句を使用しています。
RAQMON-RDS-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Unsigned32 FROM SNMPv2-SMI
SNMPv2の-SMIからの輸入MODULE-IDENTITY、OBJECT-TYPE、NOTIFICATION-TYPE、Counter32の、Unsigned32の
DateAndTime
FROM SNMPv2-TC
rmon FROM RMON-MIB
RMON-MIBで、RMON
SnmpAdminString FROM SNMP-FRAMEWORK-MIB
SNMP-FRAMEWORK-MIBかられるSnmpAdminString
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;
MODULE-COMPLIANCE、OBJECT-GROUP、NOTIFICATION-GROUPのSNMPv2-CONF FROM;
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 MODULE-IDENTITY LAST-UPDATED "200610100000Z" - 2006年10月10日ORGANIZATION "RMONワーキンググループ" CONTACT-INFO「WGメール：rmonmib@ietf.org購読：rmonmib-request@ietf.org
MIB Editor:
Eugene Golovinsky
Postal: BMC Software, Inc.
2101 CityWest Boulevard,
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.
ヒューストン、TX、77094 USA電話：+ 713-918-1816 Eメール：egolovin@bmc.com "DESCRIPTION" これはRAQMONデータソースの通知MIBモジュールです。これは、SNMPの通知にRAQMON PDUのマッピングを提供します。
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.
このモジュールで定義されたオブジェクトタイプのすべてにアクセス-通知のためにあり、その結果、単純な取得、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."
REVISION "200610100000Z" - 2006年10月10日DESCRIPTION "RFC 4712として公開初期バージョン、"
::= { 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 }
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.
RaqmonDsNotificationEntry MAX-ACCESSステータス現在の説明のraqmonDsNotificationTable OBJECT-TYPE構文配列は「この概念テーブルはRAQMON BASIC 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,
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 ::= 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 }
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 }
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のOBJECT-TYPE
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 }
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 }
raqmonDsSessionSetupDelay OBJECT-TYPE SYNTAX Unsigned32 (0..65535) UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current
raqmonDsSessionSetupDelayのOBJECT-TYPE構文Unsigned32（0 65535）UNITS "ミリ秒" MAX-ACCESSアクセス可能-FOR-通知STATUSの現在
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 }
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}
raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS accessible-for-notify STATUS current
raqmonDsOneWayEndToEndNetDelayのOBJECT-TYPE構文Unsigned32 UNITSの "ミリ秒" MAX-ACCESSアクセス可能-FOR-通知STATUSの現在
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}
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}
raqmonDsTotalPacketsReceived OBJECT-TYPE SYNTAX Counter32 UNITS "packets" MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The number of packets transmitted within a communication
raqmonDsTotalPacketsReceived OBJECT-TYPE SYNTAXカウンタユニット「パケット」MAX-ACCESSアクセス可能のため、通知ステータス現在の説明「通信内に送信されたパケットの数
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 }
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 }
raqmonDsCumulativePacketLoss OBJECT-TYPE SYNTAX Counter32 UNITS "packets"
raqmonDsCumulativePacketLoss OBJECT-TYPE SYNTAX Counter32ユニット "パケット"
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 }
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 }
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 }
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 }
raqmonDsDestinationLayer2Priority OBJECT-TYPE SYNTAX Unsigned32 (0..7) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION
raqmonDsDestinationLayer2PriorityのOBJECT-TYPE構文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 }
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 }
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.
- 通知の定義 - - RDS静的な通知が生成されるたびに、 - raqmonDsAppNameにより送信されなければならない唯一の目的です。
-- raqmonDsTotalPacketsReceived is the only object that MUST be -- sent by an RD every time the dynamic notification is generated.
- RDによって動的通知が生成されるたびに送信された - raqmonDsTotalPacketsReceivedでなければならない唯一のオブジェクトです。
-- 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
- raqmonDsNotificationTableからの他の目的は、することができる - 変数バインディングリストに含まれています。具体的には、RAQMON - アプリケーションセッションを特徴付けるメトリクスについて - 通知情報を提供するMIBオブジェクトを含みます
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のNOTIFICATION-TYPEオブジェクト{raqmonDsAppName}ステータス現在の説明は「この通知は、SNMP輸送にBASIC RAQMON PDUにおける静的パラメータをマッピングする。この通知は、セッションごとに一度送信されることが予想される、または新しいサブセッションが開始されたとき。ザ次のオブジェクトがraqmonDsStaticNotificationによって行うことができます。
raqmonDsDataSourceDevicePort,
raqmonDsReceiverDevicePort,
raqmonDsSessionSetupDateTime,
raqmonDsSessionSetupDelay,
raqmonDsSessionDuration,
raqmonDsSourcePayloadType,
raqmonDsReceiverPayloadType,
raqmonDsSourceLayer2Priority,
raqmonDsSourceDscp,
raqmonDsDestinationLayer2Priority,
raqmonDsDestinationDscp
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 NOTIFICATION-TYPEオブジェクト{raqmonDsTotalPacketsReceived}ステータス現在の説明は「この通知は、SNMP輸送にBASIC RAQMON PDUの動的パラメータをマッピングします。
The following objects MAY be carried by the
raqmonDsDynamicNotification:
raqmonDsRoundTripEndToEndNetDelay, raqmonDsOneWayEndToEndNetDelay, raqmonDsApplicationDelay, raqmonDsInterArrivalJitter, raqmonDsIPPacketDelayVariation, raqmonDsTotalPacketsSent, raqmonDsTotalOctetsReceived, raqmonDsTotalOctetsSent, raqmonDsCumulativePacketLoss, raqmonDsPacketLossFraction, raqmonDsCumulativeDiscards, raqmonDsDiscardsFraction, raqmonDsCpuUtilization, raqmonDsMemoryUtilization
raqmonDsRoundTripEndToEndNetDelay、raqmonDsOneWayEndToEndNetDelay、raqmonDsApplicationDelay、raqmonDsInterArrivalJitter、raqmonDsIPPacketDelayVariation、raqmonDsTotalPacketsSent、raqmonDsTotalOctetsReceived、raqmonDsTotalOctetsSent、raqmonDsCumulativePacketLoss、raqmonDsPacketLossFraction、raqmonDsCumulativeDiscards、raqmonDsDiscardsFraction、raqmonDsCpuUtilization、raqmonDsMemoryUtilization
It is RECOMMENDED to keep the size of a notification within the MTU size limits in order to avoid fragmentation."
断片化を避けるために、MTUサイズの制限内での通知のサイズを維持することをお勧めします。」
::= { 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 }
--
-- 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ステータス現在の説明は「この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:
-- OBJECT raqmonDsPeerAddrType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) }
- オブジェクトraqmonDsPeerAddrType - 構文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 }
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, 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 Frameworkを使用するアプリケーションは、単一の固定ポートが必要です。ポート番号7744は、TCP上のRAQMON PDUのためのデフォルトポートとして使用するためにIANAに登録されています。複数のアプリケーションを実行するホストはRAQMON RDSとRAQMONコレクタプロビジョニングの一部としてRAQMON又は提供別の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.
特定のポート番号は特権プロセスのみが1024未満のポート番号を使用することができ、1024から5000の間のポート番号が自動的にオペレーティングシステムによって割り当てられているのUnixオペレーティングシステム内のポート番号の割り当て練習を収容するために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のMODULE-IDENTITYの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上のSNMPは、広く展開されているトランスポートプロトコルであるため、戻ってUDPに落下する必要があるかもしれません。
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 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.
SNMPはRAQMON PDUのトランスポートとして選択された場合、実装者は、輻輳安全な方法でRAQMONを使用するように注意しなければならない措置を概説[RFC4710]のセクション3に従わなければなりません。 [RFC4710]のセクション3で輻輳安全要件は、UDP上でSNMPを使用して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.
著者は、彼らの議論のためにモトローラからアバイアとビン胡からビル・ウォーカーとヨセフMastroguilioに感謝したいと思います。著者らはまた、スペルや書式の目的のために、この文書を検討し、技術的な内容の深いレビューを提供ランディPresuhn、に特別な感謝を拡張したいと思います。また、このドキュメントの進化とその最終版の詳細なレビュー中に永久コーチングのためのバートWijnenに感謝したいと思います。 Security Considerations部はサム・ハートマンとクルトD. Zeilengaによってレビューとほぼ完全にMahalingamマニによって再書かれました。
[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（Data Encryption Standard）などの暗号化技術に基づく守秘義務をサポートするセキュアなトランスポートプロトコルを使用することによって達成することができ、[3DES]、およびAES（のAdvanced Encryption Standard）[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.
RRCに向けDoS攻撃からの保護3：RDSには（例えば、電話の受信を）外部イベントの副作用としてRAQMONレポートを送信。攻撃者はRAQMON PDUの過剰な数でRRCを圧倒するために、多数のイベントを開始することによって、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.
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アドレス情報を省略することができます。この問題を回避する別の方法は、正しいIPアドレスがRAQMON PDUの中に表示されることを保証するために、NAT対応のアプリケーションレイヤゲートウェイ（のALG）を使用することです。
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節はRAQMONとTLSの使用方法について説明します。
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:
また、このメモはSNMP通知にRAQMON PDUをマッピングする目的でRAQMON-RDS-MIBモジュールを定義します。エンドツーエンドのセキュリティを実現するには、以下の対策が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.
読み書きおよび/またはリード作成のMAX-ACCESS節を持っているこのMIBモジュールで定義された管理オブジェクトがありません。このMIBモジュールが正しく実装されている場合そのため、侵入者が変更またはダイレクトSNMP SET操作を経て、この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持つオブジェクト）は、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。 GETおよび/またはこれらのオブジェクトへのアクセスを通知し、おそらく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を使って、例えば）安全であっても、その後も、安全なネットワーク上で/ SETにアクセスし、GETだれに許容されているかのように何の制御（読み取り/変更/作成/削除）この内のオブジェクトが存在しません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フレームワークで提供するようにセキュリティ機能を考えることが推奨される（認証及び機密性のために）SNMPv3の暗号化メカニズムの完全なサポートを含む、（[RFC3410]セクション8を参照）。
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実体が適切にのみプリンシパル（ユーザ）にオブジェクトへのアクセス権を与えるように構成されていることを保証するために、顧客/オペレータ責任実際にGETまたはSET（変更/への正当な権利を有することです）それらを作成/削除。
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アドレス：RDS_port / RRCのIPアドレス：RRCポート}。
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.
トランスポート接続を介して送信されるパスワードやその他のデータのための適切な機密保護を提供するために、暗号スイートの能力。クライアントとサーバーの実装者は、機密性の保護を提供しない他の暗号スイートは特にに成功したのに必要な時間を短縮増え続けるCPU速度の光の中で、ブルートフォースメソッドを使用してクラックの発生に対して脆弱である可能性がある一方で、いくつかのTLS暗号スイートは、何の機密性保護を提供しないことを認識すべきですこのような攻撃をマウントします。
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.
man-in-the-middle攻撃への暗号スイートの脆弱性（またはその欠如）。 man-in-the-middle攻撃に対して脆弱暗号スイートは、ネットワーク構成がman-in-the-middle攻撃の危険性が無視できるようなものである場合を除き、パスワードや機密データを保護するために使用しないでください。
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モニタリングデータの整合性を危うくする機会を提供していますが、また洪水データによるDoS攻撃を起動するための本物のRDSエンティティを装った不正なクライアントまでRRCを開くだけではなく。 RAQMON展開ポリシーは、RDSクライアントが保護されていないインターネットを介して通信する場合は特に、TLSセッション確立中にRDSクライアント認証を必要と考慮しなければなりません。
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接続は別の1つの信頼できるクライアントによるスプーフィング攻撃に開放されています。 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).
（RDSとRRC間の）すべてのRAQMONセッションが関連付けられている許可ステートを持っています。この状態は、このような許可ステート確立されています（もしあれば）、それが確立された方法をどのよう多くの要素で構成され、そしてどのようなセキュリティサービスが整っています。いくつかの要因が決定および/またはプロトコル・イベントによって影響を受ける（例えば、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での認可は、ローカルの問題です。承認の意思決定の重要な要因の一つは、認可IDです。 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セッションの初期確立時に、セッションは、匿名の認可IDを持っています。とりわけ、これは、クライアントがRAQMONメッセージの最初のPDUでTLSStartRequiredを送信する必要がないことを意味します。クライアントは、任意の認証にRDSを結合する前に、すべての操作要求を送信することができ、そしてそれは匿名RAQMONセッション開始後に実行されたかのようにRRCは、それを扱わなければなりません。
The RDS automatically is placed in an unauthorized state upon RRC sending a TLSstart request to the RRC.
RDSは自動的RRCは、RRCにTLSstart要求を送信する際に不正な状態に置かれます。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、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.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、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.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS. Waldbusser、 "SMIv2のための適合性宣言"、STD 58、RFC 2580、1999年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]ベイカー、F.、チャン、K.、およびA.スミス、 "差別化サービスアーキテクチャのための管理情報ベース"、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]ハリントン、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]ダニエル、M.、ハーバーマン、B.、Routhier、S.、およびJ. Schoenwalder、 "インターネットネットワークアドレスのためのテキストの表記法"、RFC 4001、2005年2月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 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 4710、2006年10月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[3DES] Americation National Standards Institute, "Triple Data Encryption Algorithm Modes of Operation", ANSI X9.52-1998.
[3DES] Americation規格協会、「操作のトリプルデータ暗号化アルゴリズムモード」、ANSI X9.52-1998。
[AES] Federal Information Processing Standard (FIPS), "Specifications for the ADVANCED ENCRYPTION STANDARD(AES)", Publication 197, November 2001.
[AES]連邦情報処理標準（FIPS）、出版物197、2001年11月 "のAdvanced Encryption Standard（AES）の仕様"。
[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]「情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - メディアアクセス制御（MAC）ブリッジ：1998（ISO / IEC）：15802-3」、[ANSI / IEEE 802.1D STD版]、1998。
[RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコルバージョン3"、RFC 1305、1992年3月。
[RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "メッセージダイジェストアルゴリズムMD5"、RFC 1321、1992年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]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年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.
、RFC 3414、2002年12月 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）" [RFC3414]ブルーメンソール、U.とB. Wijnenの、。
[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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 3550、2003年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、RFC 3737、2004年4月 "リモートモニタリング（RMON）MIBモジュールの登録のためのIANAガイドライン"。
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]ハリソン、R.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：認証方法とセキュリティメカニズム"、RFC 4513、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、RFC 4279、2005年12月 "事前共有鍵暗号の組み合わせトランスポート層セキュリティ（TLS）のために"。
Appendix A. Pseudocode
付録A.擬似コード
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;
}
}
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
}
Authors' Addresses
著者のアドレス
Anwar Siddiqui Avaya 307 Middletown Lincroft Road Lincroft, NJ 80302 USA
アンワルSiddiquiはアバイア307ミドルリンクロフト道路リンクロフト、NJ 80302 USA
Phone: +1 732 852-3200 EMail: anwars@avaya.com
電話：+1 732 852-3200 Eメール：anwars@avaya.com
Dan Romascanu Avaya Atidim Technology Park, Bldg #3 Tel Aviv, 61131 Israel
、61131イスラエルテルアビブダンRomascanu AvayaのATIDテクノロジーパーク、ビルの＃3
Phone: +972-3-645-8414 EMail: dromasca@avaya.com
電話：+ 972-3-645-8414 Eメール：dromasca@avaya.com
Eugene Golovinsky Alert Logic
ユージンGolovinskyアラート・ロジック
Phone: +1 713 918-1816 EMail: gene@alertlogic.net
電話：+1 713 918-1816 Eメール：gene@alertlogic.net
Mahfuzur Rahman Samsung Information Systems America 75 West Plumeria Drive San Jose, CA 95134 USA
マファチュール・ラーマンサムスンインフォメーションシステムズアメリカ75西プルメリアドライブサンノゼ、CA 95134 USA
Phone: +1 408 544-5559
電話：+1 408 544-5559
Yongbum Yong Kim Broadcom 3151 Zanker Road San Jose, CA 95134 USA
Yongbumヨン・キムのBroadcom 3151 Zanker道サンノゼ、CA 95134 USA
Phone: +1 408 501-7800 EMail: ybkim@broadcom.com
電話：+1 408 501-7800 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。