RFC4712 日本語訳
4712 Transport Mappings for Real-time Application Quality-of-ServiceMonitoring (RAQMON) Protocol Data Unit (PDU). A. Siddiqui, D.Romascanu, E. Golovinsky, M. Rahman,Y. Kim. October 2006. (Format: TXT=109407 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Siddiquiがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4712年のD.Romascanuカテゴリ: 標準化過程Avaya E.GolovinskyはアメリカY.キムBroadcom2006年10月に論理M.ラーマン三星情報システムを警告します。
Transport Mappings for Real-time Application Quality-of-Service
Monitoring (RAQMON) Protocol Data Unit (PDU)
リアルタイムのサービスのアプリケーション品質モニターしている(RAQMON)プロトコルデータ単位輸送マッピング(PDU)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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).
このメモはRFC4710でRAQMON Data Source(RDS)からRAQMON Report Collector(RRC)までRAQMON情報を運ぶのにネイティブの輸送とSimple Network Managementプロトコル(SNMP)としてTCPを使用することで定義されたレアル-時間サービスのApplication Quality Monitoring(RAQMON)情報モデルに関する2つの輸送マッピングを指定します。
Siddiqui, et al. Standards Track [Page 1] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[1ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
Table of Contents
目次
1. Introduction ....................................................3
2. Transporting RAQMON Protocol Data Units .........................3
2.1. TCP as an RDS/RRC Network Transport Protocol ...............3
2.1.1. The RAQMON PDU ......................................5
2.1.2. The BASIC Part of the RAQMON Protocol Data Unit .....7
2.1.3. APP Part of the RAQMON Protocol Data Unit ..........14
2.1.4. Byte Order, Alignment, and Time Format of
RAQMON PDUs ........................................15
2.2. Securing RAQMON Session ...................................15
2.2.1. Sequencing of the Start TLS Operation ..............18
2.2.2. Closing a TLS Connection ...........................21
2.3. SNMP Notifications as an RDS/RRC Network Transport
Protocol ..................................................22
3. IANA Considerations ............................................38
4. Congestion-Safe RAQMON Operation ...............................38
5. Acknowledgements ...............................................39
6. Security Considerations ........................................39
6.1. Usage of TLS with RAQMON ..................................41
6.1.1. Confidentiality & Message Integrity ................41
6.1.2. TLS CipherSuites ...................................41
6.1.3. RAQMON Authorization State .........................42
7. References .....................................................43
7.1. Normative References ......................................43
7.2. Informative References ....................................44
Appendix A. Pseudocode ............................................46
1. 序論…3 2. RAQMONを輸送して、データ単位について議定書の中で述べてください…3 2.1. RDS/RRCネットワーク輸送としてのTCPは議定書を作ります…3 2.1.1. RAQMON PDU…5 2.1.2. RAQMONプロトコルデータ単位の基本的な部分…7 2.1.3. RAQMONプロトコルデータ単位の装置部分…14 2.1.4. RAQMON PDUsのバイトオーダー、整列、および時間形式…15 2.2. RAQMONにセッションを保証します…15 2.2.1. スタートTLS操作の配列…18 2.2.2. TLS接続を終えます…21 2.3. RDS/RRCネットワーク輸送としてのSNMP通知は議定書を作ります…22 3. IANA問題…38 4. 混雑安全なRAQMON操作…38 5. 承認…39 6. セキュリティ問題…39 6.1. RAQMONとTLSの使用法…41 6.1.1. 秘密性とメッセージの保全…41 6.1.2. TLS CipherSuites…41 6.1.3. RAQMON承認状態…42 7. 参照…43 7.1. 標準の参照…43 7.2. 有益な参照…44付録A.擬似コード…46
Siddiqui, et al. Standards Track [Page 2] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[2ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
1. Introduction
1. 序論
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.
リアルタイムで様々なアプリケーションモニターを実行するレアル-時間Application QoS Monitoring(RAQMON) [RFC4710]によって概説されているフレームワークはRAQMON Data Sources RDSなどの実体を定義することによって、プロトコル(RMON)のRemote Monitoringファミリーを広げる)とRAQMON Report Collectors(RRC)。 RDSの間で使用される一般的なプロトコルデータ単位(PDU)によって運ばれたRAQMONモニターとRRCがQoS統計を報告するように、[RFC4710]は関連測定基準を定義します。 このメモはRAQMON PDU構造の構文の記述を含んでいます。
The following sections of this memo contain detailed specifications for the usage of TCP and SNMP to carry RAQMON information.
このメモの以下のセクションはTCPとSNMPの使用法がRAQMON情報を運ぶ仕様詳細を含みます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Transporting RAQMON Protocol Data Units
2. RAQMONプロトコルデータ単位を輸送します。
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プロトコルData Unit(PDU)はRDSとRRCに解釈された一般的なデータの形式を利用します。 RAQMON PDUはアプリケーションデータを輸送しませんが、プロトコル・スタックの応用層でむしろペイロード仕様の場所を占領します。 また、仕様の一部として、このメモはRDSsとRRCsの間までRAQMON PDUsを運ぶためにトランスポート・プロトコルの基礎となるとTCPとSNMPの使用法を指定します。 オプションが選択に提供された2トランスポート・プロトコルが選ばれた、RDS implementersに関しては、RRCsは、TCPが輸送であると実装しなければならなくて、SNMPが輸送であると実装するかもしれません。
2.1. TCP as an RDS/RRC Network Transport Protocol
2.1. RDS/RRCネットワークトランスポート・プロトコルとしてのTCP
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などのアプリケーションを実行する様々なタイプの組み込み機器から報告するのを容易にするためにRAQMON仕様の中に含まれています、Wi-Fiの上のVoice、IPの上のファックス、IPの上のVideo、Instant Messaging(IM)、メール、ソフトウェアダウンロードアプリケーション、電子ビジネススタイル取引、コンピュータ・デバイスのワイヤードであるかワイヤレスのなどからのウェブアクセス これらのデバイスの多くのために、PDUsとTCPベースの輸送は展開の必要性に合います。
The RAQMON transport requirements for end-to-end congestion control and reliability are inherently built into TCP as a transport protocol [RFC793].
TCPは本来トランスポート・プロトコル[RFC793]として終わりからエンドへの輻輳制御と信頼性のためのRAQMON輸送要件に組み込まれます。
Siddiqui, et al. Standards Track [Page 3] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[3ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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 PDUsを輸送するのにTCPを使用するために、TCPデータとしてPDUsを送るのは十分です。 各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仕様を詳しく述べます。 1プロトコルData Unitとして伝えられますが、RAQMON PDUは2つの異なった部品に機能上分割されます: BASIC一部とアプリケーション拡大がベンダー特有の拡大[RFC4710]に必要です。 両方の機能的な部分は、現在PDUで運ばれた情報を定義した組織を特定するのに使用されるIANA http://www.iana.org/assignments/enterprise-numbers によって維持されているSMI Network Management兵士のエンタープライズコードを運びながら、野原に続きます。
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 Type(太平洋夏時間の)=1としてマークされます。 RAQMON PDUsによって運ばれたパラメタは、図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一部を使用しなければなりません、アプリケーション特定部位を使用することと対照的に。 また、ベンダーは、仕様のBASIC部分に含まれていなかったアプリケーション、ベンダー、またはデバイス特有のパラメタを伝えて、拡張相互運用性に達するように明らかに外部的にそのようなデータを発表するのにアプリケーション特有の拡張子を使用するかもしれません。
Siddiqui, et al. Standards Track [Page 4] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[4ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
2.1.1. The RAQMON PDU
2.1.1. RAQMON PDU
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |Report Type = 0| RC_N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |flag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source Address {DA} |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Address (RA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Application Name (AN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Data Source Name (DN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Receiver's Name (RN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Session State ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round-Trip End-to-End Network Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One-Way End-to-End Network Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Packet Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Application Packet Discard |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Packets sent |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |太平洋夏時間、=1|B| T|P|S|R| RC| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMIエンタープライズコード=0|レポートタイプ=0| RC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |旗の+++++++++++++++++++++++++++++++++| データ送信端末アドレスDA| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 届け先(RA)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp、最も重要な単語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP Timestamp、最も重要でない単語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| アプリケーション名(AN)… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| データ送信端末名(DN)… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| 受信機の名前(Rn)… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| セッション状態… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション持続時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 終わりから終わりへの往復のネットワーク遅延| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 終わりから終わりへの一方向ネットワーク遅延| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 累積しているパケット損失| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 累積しているアプリケーションパケット破棄| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 合計#Application Packetsは発信しました。|
Siddiqui, et al. Standards Track [Page 5] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[5ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 合計#Application Packetsは受信しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 合計#Application Octetsは発信しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 合計#Application Octetsは受信しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ポートが使用したデータ送信端末デバイス| ポートが使用した受信機デバイス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S_Layer2| S_Layer3| S_Layer2| S_Layer3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ソース有効搭載量|受信機| CPU| メモリ| |タイプ|有効搭載量タイプ| 利用| 利用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッションセットアップ遅れ| アプリケーション遅れ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPパケット遅れ変化| 間の到着Jitter| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットDiscrd| パケット損失| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMIエンタープライズコードは"xxx"と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | レポートタイプは"yyy"と等しいです。| アプリケーション部分の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アプリケーション/ベンダーの特定の拡大| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMIエンタープライズコードは"abc"と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | レポートタイプは「グーグーグー」と等しいです。| アプリケーション部分の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アプリケーション/ベンダーの特定の拡大| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RAQMON Protocol Data Unit
図1: RAQMONプロトコルデータ単位
Siddiqui, et al. Standards Track [Page 6] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[6ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
2.1.2. The BASIC Part of the RAQMON Protocol Data Unit
2.1.2. 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はタイプします(太平洋夏時間の): 5ビット--これは送られるRAQMON PDUのタイプを示します。 太平洋夏時間、= 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のBASIC一部があるのを示します。 ゼロの値は、有効であると考えられて、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一部に続くApplication特有のExtensionsの総数。 ゼロの値は、基本情報に加えるためにアプリケーションがないあるのと同じくらい多くの倍の有効な特殊情報であると考えられます。
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のBASIC一部が監視情報の一部でないPDUのBASIC一部の端にいくつかの追加詰め物八重奏を含みます。 いくつかの場合、詰め物が必要であるかもしれません、報告がRDSが、あるパラメタを報告する意図に基づいているとき。 また、いくつかのパラメタが報告セッションの始まり、例えば、Data Source Name、Receiver Name、ペイロードタイプなどで一度だけ報告されるかもしれません。 PDUのBASIC一部の端の実際の詰め物は0、8、16であるか24がPDUのBASIC一部の長さを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バージョンFlag(S): 1ビット--1に設定されている間、ソースIPバージョン旗は、PDUに含まれたSource 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バージョンFlag(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のBASIC一部に含まれた状態で記録します。 ゼロの値は有効ですが、役に立たないと考えられます、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ビット(符号のない整数)--1を引いたユニットの32ビットの単語によるRAQMON PDUのBASIC一部の長さ。 このカウントはヘッダーとどんな詰め物も含んでいます。
Siddiqui, et al. Standards Track [Page 7] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[7ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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ビット--データSource識別子はRDSとRRCとの特定の報告セッションまで指すユニークなRAQMON報告しているセッション記述子を表します。 DSRCのユニークさは単に報告セッション以内に有効です。 DSRC値は、それぞれのコミュニケーションセッションにベンダーによって選ばれたアルゴリズムを使用することで手当たりしだいに生成されるべきです。 単に慎重に状態を初期化しないで無作為の()と呼ぶことによってDSRCを入手するのは十分ではありません。 1つは、DSRCを作成するのに[RFC3550]でAppendix A.6で定義されたもののようなアルゴリズムを使用するかもしれません。 アルゴリズムの選択によって、2異なったRDSsからの2DSRCsが同じであるかもしれないという有限確率があります。 2RDSsが2つの異なった報告セッションのために同じDSRCを選ぶという確率をさらに、減少させるために、RRCがDSRC値に関連したPDUのData Source Address(DA)、Data Source Name(DN)、および層2のメディアAccess Control(MAC)アドレスのようなパラメタを使用するのは、お勧めです。 Data Source Address(DA)、Data Source Name(DN)、およびあらゆるPDUのマックーアドレスがRRCに発信しましたが、時折これらのパラメタを送るとDSRC衝突の確率が抜本的に減少するようにRDSsがパラメタを送るのは、義務的ではありません。 しかしながら、これは1PDUあたり1つの追加オーバーヘッドを引き起こすでしょう。
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(すなわち、報告するために何でもない)を構成します。 RDSsは、RDS報告セッションの終わりを示すためにRAQMON NULL PDUをRRCに送らなければなりません。 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エンタープライズCode=0の値は、RAQMON PDU形式のRMON-WG対応することのBASIC一部分を示すのに使用されます。
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エンタープライズCode=0の中の0の値はこのドキュメントによって定義されたPDUのバージョンに使用されます。
The BASIC part of each RAQMON PDU consists of Record Count Number
(RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the
presence of appropriate RAQMON parameters within a record, as
defined in Table 1.
それぞれのRAQMON PDUのBASIC一部が記録の中に適切なRAQMONパラメタの存在を示すためにRecord Count Number(RC)とRAQMON Parameter Presence Flags(RPPF)から成ります、Table1で定義されるように。
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: 8ビット--Record Count番号はコミュニケーションセッション以内にサブセッションを示します。 ゼロの値は有効な記録的な数です。 1RAQMON Packetで説明できる記録の最大数は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は指定されるとしてTable1に対応するパラメタを含んでいます。
Siddiqui, et al. Standards Track [Page 8] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[8ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
+----------------+--------------------------------------------------+ | 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 | | | |
+----------------+--------------------------------------------------+ | 噛み付いている系列| 対応するParameterの存在/不在| | 数| このRAQMON PDUの中で| +----------------+--------------------------------------------------+ | 0 | データ送信端末アドレス(DA)| | | | | 1 | 受信機アドレス(RA)| | | | | 2 | NTPタイムスタンプ| | | | | 3 | アプリケーション名| | | | | 4 | データ送信端末名(DN)| | | | | 5 | 受信機名(Rn)| | | | | 6 | セッションセットアップ状態| | | | | 7 | セッション持続時間| | | | | 8 | 終わりから終わりへの往復のネット遅れ(RTT)| | | | | 9 | 終わりから終わりへの一方向ネットワーク遅延(OWD)| | | | | 10 | 累積しているパケットの損失| | | | | 11 | 累積しているパケット破棄| | | | | 12 | App Packetsの総数は発信しました。| | | | | 13 | 受け取られたApp Packetsの総数| | | | | 14 | App Octetsの総数は発信しました。| | | | | 15 | 受け取られたApp Octetsの総数| | | | | 16 | ポートが使用したデータ送信端末デバイス| | | | | 17 | ポートが使用した受信機デバイス| | | | | 18 | ソース層2の優先権| | | | | 19 | ソース層3の優先権| | | | | 20 | 目的地層2の優先権| | | | | 21 | 目的地層3の優先権| | | |
Siddiqui, et al. Standards Track [Page 9] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[9ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
| 22 | Source Payload Type | | | | | 23 | Receiver Payload Type | | | | | 24 | CPU Utilization | | | | | 25 | Memory Utilization | | | | | 26 | Session Setup Delay | | | | | 27 | Application Delay | | | | | 28 | IP Packet Delay Variation | | | | | 29 | Inter arrival Jitter | | | | | 30 | Packet Discard (in fraction) | | | | | 31 | Packet Loss (in fraction) | +----------------+--------------------------------------------------+
| 22 | ソース有効搭載量タイプ| | | | | 23 | 受信機有効搭載量タイプ| | | | | 24 | CPU利用| | | | | 25 | メモリ使用量| | | | | 26 | セッションセットアップ遅れ| | | | | 27 | アプリケーション遅れ| | | | | 28 | IPパケット遅れ変化| | | | | 29 | 間の到着Jitter| | | | | 30 | パケットDiscard(断片の)| | | | | 31 | パケットLoss(断片の)| +----------------+--------------------------------------------------+
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): 2進法表示における32ビットか160ビット--このパラメタは[RFC4710]のセクション5.1で定義されます。 IPv6アドレスはRAQMON PDUヘッダーのソースIPバージョン旗(Sに噛み付いた)を1に設定するのによるData Source Addressに組み込んでいます。
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で定義されます。 それは、Data Source Addressと全く同じ構文に従いますが、Receiver Addressを示すのに使用されます。 IPv6アドレスはRAQMON PDUヘッダーの受信機IPバージョン旗(Rに噛み付いた)を1に設定するのによるReceiver Addressに組み込んでいます。
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.
セッションSetup Date/時間(NTPタイムスタンプ): 64ビット--このパラメタは、秒[RFC1305]に、あるNetwork Timeプロトコル(NTP)のタイムスタンプ形式を使用することで[RFC4710]のセクション5.7で定義されて、表されます。 完全な解決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で定義されます。 Application Name分野はテキスト自体がUTF-8コード化を使用することであとに続いたテキストの長さについて説明する8ビット・オクテットカウントから始まります。 Nameがさばくアプリケーションは32ビットの倍数です、そして、必要なら、詰め物は使用されるでしょう。
Siddiqui, et al. Standards Track [Page 10] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[10ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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 SHOULDをサポートしないData SourceはPDUで64ビット無駄を省く0に適切なRAQMON旗を設定しました。 NTPタイムスタンプがセッションのセットアップDate/時間を提供することを意図するので、サブセッションRCセットアップが終了した後にNTP Timestampが最初のRAQMON PDUだけで使用されるのは、RECOMMENDEDです、効率的にネットワーク資源を使用するために。
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で、定義されます。 Data Source Name分野はテキスト自体があとに続いたテキストの長さについて説明する8ビット・オクテットカウントから始まります。 詰め物は、長さとテキストコード化がPDUのDN分野の32ビットの倍数を占領するのを保証するのに使用されます。 テキストは255の八重奏より長いはずがありません。 [RFC3629]で指定されたUTF-8コード化に従って、テキストはコード化されます。 アプリケーションSHOULDは、このパラメタが報告セッションの持続時間に一定のままで残っていると予想されるときネットワーク資源の効率的な使用法を確実にするためにData Source Nameをまれに出すようRDSsに命令します。
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): これほどメートル法であることは、定義されたコネです。セクション5.4の[RFC4710。] Data Source Nameのように、Receiver Name分野はテキスト自体があとに続いたテキストの長さについて説明する8ビット・オクテットカウントから始まります。 長さの分野コード化を含むReceiver Nameは、32ビットの倍数であり、Data Source Nameへの適用されるとしての規則を水増ししながら、同じくらい続きます。 Receiver Nameが全体の報告セッションの間、一定のままで残っていると予想されて、この情報SHOULDは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.
セッションセットアップ状態: Session(サブセッションの)セットアップStatusは[RFC4710]のセクション5.10で定義されます。 この分野は8ビットの長さの野原から始まります、続いて、テキスト自体から始まります。 セッションSetup Statusは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.
セッション持続時間: Session(サブセッション)持続時間メートル法であることは、定義されたコネです。32ビット--、セクション5.9の[RFC4710。] セッションDurationは秒に表された符号のない整数です。
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ビット--終わりまでのRound-旅行End Network Delayは[RFC4710]のセクション5.11で定義されます。 この分野はRound-旅行のEndから終わりへのサブセッションRCのDelayを表します。(RCはミリセカンドで表された符号のない整数です)。
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ビット--One-道のEndから終わりへのNetwork Delayは[RFC4710]のセクション5.12で定義されます。 この分野はOne-道のEndから終わりへのサブセッションRCのDelayを表します。(RCはミリセカンドで表された符号のない整数です)。
Siddiqui, et al. Standards Track [Page 11] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[11ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
Cumulative Application Packet Loss: 32 bits - This parameter is
defined in section 5.20 of [RFC4710] as an unsigned integer,
representing the total number of packets from sub-session RC_N
that have been lost while this RAQMON PDU was generated.
累積しているアプリケーションパケット損失: 32ビット--このパラメタは[RFC4710]のセクション5.20で符号のない整数と定義されます、このRAQMON PDUが生成されていた間になくされているサブセッションRCからパケットの総数を表して。
Cumulative Application Packet Discards: 32 bits - This parameter is
defined in section 5.22 of [RFC4710] as an unsigned integer
representing the total number of packets from sub-session RC_N
that have been discarded while this RAQMON PDU was generated.
累積しているアプリケーションパケット破棄: 32ビット--このパラメタは[RFC4710]のセクション5.22でこのRAQMON PDUが生成されていた間に捨てられているサブセッションRCからパケットの総数を表す符号のない整数と定義されます。
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.
Application Packetsの総数は発信しました: 32ビット--このパラメタは[RFC4710]のセクション5.17で符号のない整数と定義されます、サブセッションRCの中で送付者によって伝えられたパケットの総数を表して。
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.
Application Packetsの総数は受けました: 32ビット--このパラメタは、[RFC4710]のセクション5.16で定義されて、パケットの総数を表す符号のない整数がサブセッションRCの中を受信機で伝わったように表されます。
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.
Application Octetsの総数は発信しました: 32ビット--このパラメタは[RFC4710]のセクション5.19で符号のない整数と定義されます、サブセッションRCの中でパケットで送付者によって伝えられたペイロード八重奏(すなわち、ヘッダーを含んでいないか、またはそっと歩かない)の総数を表して。
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.
Application Octetsの総数は受けました: 32ビット--このパラメタは[RFC4710]のセクション5.18でサブセッションRCの中でパケットで受信機によって伝えられたペイロード八重奏(すなわち、ヘッダーを含んでいないか、またはそっと歩かない)の総数を表す符号のない整数と定義されます。
Data Source Device Port Used: 16 bits - This parameter is defined in
section 5.5 of [RFC4710] and describes the port number used by the
Data Source as used by the application in RC_N session while this
RAQMON PDU was generated.
データ送信端末デバイスポートは使用しました: 16ビット--このパラメタは、このRAQMON PDUが生成されましたが、RCセッションにおけるアプリケーションで使用されるように[RFC4710]のセクション5.5で定義されて、Data Sourceによって使用されたポートナンバーについて説明します。
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ビット--それはSource Device Port Usedと同じ構文に従います。
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におけるトラフィックに関するソースのIEEE 802.1D[IEEE802.1D]優先権タグ付けに関連づけられます。 優先権がタグ付けをするIEEE802.1が長さ3ビットであるので、このパラメタの最初の3ビットはIEEE802.1タグ価値を表します、そして、最後の5ビットは0に水増しされます。
Siddiqui, et al. Standards Track [Page 12] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[12ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
S_Layer3: 8 bits - This parameter, defined in section 5.27 of
[RFC4710], represents the layer 3 QoS marking used to send packets
to the receiver by this data source during sub-session RC_N.
_S Layer3: 8ビット--[RFC4710]のセクション5.27で定義されたこのパラメタはマークがサブセッションRCの間、このデータ送信端末でパケットを受信機に送るのに使用した3QoS層を表します。
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で定義されたこのパラメタはData Sourceがそのような情報を学ぶことができるなら受信機によって使用される、サブセッションRCセッションの間、パケットをデータ送信端末に送る層2のIEEE 802.1D優先権タグを表します。 優先権がタグ付けをするIEEE802.1が長さ3ビットであるので、このパラメタの最初の3ビットはIEEE802.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ビット--このパラメタは、サブセッションRCの間、[RFC4710]のセクション5.29で定義されて、マークがパケットを送るのに受信機で使用した3QoS層をデータ送信端末に表します、Data Sourceがそのような情報を学ぶことができるなら。
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ビット--このパラメタは、[RFC3551]で定義されるように[RFC4710]のセクション5.24で定義されて、コミュニケーションサブセッションRCのデータ送信端末のペイロードタイプを指定します。
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ビット--このパラメタは、[RFC3551]で定義されるように[RFC4710]のセクション5.25で定義されて、コミュニケーションサブセッションRCの受信機ペイロードタイプを指定します。
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で定義されたこのパラメタは最後のレポートからセッションRCの間に使用されるCPUの割合をこのRAQMON PDUが生成された時まで表します。 CPU Utilizationは範囲で%で0〜100に急送されます。 値は、CPU使用率だけが進行中のセッションRCである間にRDSを実行するホストのCPU使用率のスナップを示すためにセッションまでRCにもかかわらず、実際のCPU Utilizationも関連づけたのを示すべきではありません。
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で定義されたこのパラメタはメモリがセッションRCの間にこのRAQMON PDUが生成された時まで使用した全体に占める割合を表します。 メモリ使用量は%で0〜100に言い表されます。 Memory Utilization値は、メモリ使用量だけがセッションRCが進行している間、端末装置メモリ使用量のスナップを示すためにセッションまでRCにもかかわらず、総メモリ使用量を関連づけたのを示すべきではありません。
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で定義されて、ミリセカンドで言い表されて、Session(サブセッションの)はメートル法でDelayをセットアップします。
Siddiqui, et al. Standards Track [Page 13] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[13ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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ビット--Application Delayは[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 Packet Delay Variationは[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ビット--Inter-到着Jitterは[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で定義されて、2進小数点が分野の左の縁にある状態で、固定小数点数として言い表されます。 (それ、破棄を掛けた後に整数部を取るのと同等物は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で定義されて、固定小数点数として言い表されます、2進小数点が分野の左の縁にある状態で。 メートル法は、失われたパケットの数が予想されたパケットの数を割ったということになるように定義されます。 値は分割の結果を256に掛けて、予想されたパケットの総数によって失われた(Forward Error Correctionなどのどんな誤り保護(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.
詰め物: 詰め物ビット(P)が設定されるなら、この分野は8ビットか16ビットか0ビットか24ビット、存在しているかもしれません。 PDUのBASIC一部の端の実際の詰め物は0、8、16であるか24がPDUのBASIC一部の長さを32ビットの倍数にするビットです。
2.1.3. APP Part of the RAQMON Protocol Data Unit
2.1.3. RAQMONプロトコルデータ単位の装置部分
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
ベンダーは、アプリケーション特有の拡大を設計して、発行するかもしれません。 どんなRAQMON対応することのRRC MUSTもベンダーのSMIエンタープライズCodesを認識できて、Report Type分野を使用することによって特定されたアプリケーションの特定の拡大の存在を認識しなければなりません。 図1、Report Type、およびApplication Lengthでは、表されます。
Siddiqui, et al. Standards Track [Page 14] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[14ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
fields are always located at a fixed offset relative to the start of the extension fields. There is no need for the RRC to understand the semantics of the enterprise-specific parts of the PDU.
拡大分野の始まりに比例して分野は固定オフセットでいつも位置しています。 RRCがPDUの企業特有の部分の意味論を理解する必要は全くありません。
SMI Enterprise Code: 32 bits - Vendors and application developers
should fill in appropriate SMI Enterprise IDs available at
http://www.iana.org/assignments/enterprise-numbers. A non-zero
SMI Enterprise Code indicates a vendor- or application-specific
extension.
SMIエンタープライズコード: 32ビット--ベンダーとアプリケーション開発者は http://www.iana.org/assignments/enterprise-numbers で利用可能な適切なSMIエンタープライズIDに記入するべきです。 非ゼロSMIエンタープライズCodeはベンダーかアプリケーション特有の拡大を示します。
RAQMON PDUs are capable of carrying multiple Application Parts
within a PDU.
RAQMON PDUsはPDUの中で複数のApplication Partsを運ぶことができます。
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エンタープライズCodeの中に適切なレポートタイプに記入するべきです。 ベンダーがアプリケーション特有の拡大を発行して、より良い相互運用性のためにそのようなレポートタイプを維持するのは、RECOMMENDEDです。
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のApplication Partの長さ。ものはApplication Partのヘッダーを含んでいます。
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ビットの倍数でなければならなく、必要なら、水増しされるでしょう。
2.1.4. Byte Order, Alignment, and Time Format of RAQMON PDUs
2.1.4. RAQMON PDUsのバイトオーダー、整列、および時間形式
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などで分割可能なオフセットのときに並べられます。 詰め物として指定された八重奏は値ゼロを持っています。
2.2. Securing RAQMON Session
2.2. RAQMONにセッションを保証します。
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
TCP輸送の上で開始されたRAQMONセッションはRDSクライアントからRRC(コレクタ)までRDSとRRCの間まで監視情報を運びます。 RRCはRRCにそれ自体を特定するのにRDSによって使用された様々な識別子に基づくクライアントを見分けます。
Siddiqui, et al. Standards Track [Page 15] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[15ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
(Data Source Address and Data Source Name) and the RRC (Receiver's Address and Receiver's Name).
(データ送信端末アドレスとデータ送信端末名) そして、RRC(届け先と受信機の名前)。
In order to ensure integrity of the claimed identities of RDS and RRC to each other, authentication services are required.
RDSとRRCの要求されたアイデンティティの保全を互いに保証するために、認証サービスが必要です。
Subsequently, where protection from unauthorized modification and unauthorized disclosure of RAQMON data in transit from RDS to RRC is needed, data confidentiality and message integrity services will be required. In order to prevent monitoring-misinformation due to session-recording and replay by unauthorized sources, replay protection services may be required.
次に、トランジットにおける、RAQMONデータの権限のない変更と不当開示からのRDSからRRCまでの保護が必要であるところでデータの機密性とメッセージの保全サービスが必要でしょう。 セッション録音のためモニターしている誤伝を防いで、権限のないソースで再演するために、反復操作による保護サービスが必要であるかもしれません。
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は提供します、認証の間に交渉されたciphersuiteを使用するアプリケーション・プロトコルのトランスポート層、握手プロトコルを通した必要な認証サービス、その後のデータの機密性、メッセージの保全、および反復操作による保護のときに。
The RDS client authenticates the RRC in session. The RRC optionally authenticates the RDS.
RDSクライアントはセッションのときにRRCを認証します。 RRCは任意にRDSを認証します。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PDT = 1 |B| T |P|S|R| RC | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = 0 |Report Type = | RC_N | | | TLS_REQ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |太平洋夏時間、=1|B| T|P|S|R| RC| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMIエンタープライズコード=0|レポートタイプ=| RC| | | 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は、図2のようにTLS_REQ PDUを伝えることによって、StartTLS要求を送ります。 このPDUはTLS_REQ Report Typeによって区別されます。
Following this request, the client MUST NOT send any PDUs on this connection until it receives a StartTLS response.
この要求に続いて、それがStartTLS応答を受けるまで、クライアントは少しのPDUsもこの接続に送ってはいけません。
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.
旗の分野は、ジェネリックRAQMON PDUと共にどんな意味も運んで、互換性のために存在していません。 このバージョンの旗の分野を無視しなければなりません。
Siddiqui, et al. Standards Track [Page 16] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[16ページ]RFC4712は2006年10月に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:
TLS_RESP、StartTLS要求をするとき、目標サーバ(RRC)はStartTLS応答を含むRAQMON PDUを返さなければなりません。 RAQMON TLS_RESPは以下の通り定義されます:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PDT = 1 |B| T |P|S|R| RC | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMI Enterprise Code = 0 |Report Type = | Result | | | TLS_RESP| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |太平洋夏時間、=1|B| T|P|S|R| RC| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMIエンタープライズコード=0|レポートタイプ=| 結果| | | 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は、図3のようにTLS_RESP PDUを伝えることによって、StartTLS要求に応じます。 このPDUはTLS_RESP Report Typeによって区別されます。
The Result field is an octet containing the result of the request. This field can carry one of the following values:
Result分野は要求の結果を含む八重奏です。 この分野は以下の値の1つを運ぶことができます:
+-------+------------------+----------------------------------------+ | 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. | +-------+------------------+----------------------------------------+
+-------+------------------+----------------------------------------+ | 値| ニーモニック| 結果| +-------+------------------+----------------------------------------+ | 0 | OK| 成功。 そしてサーバが望んでいる。| | | | TLSを交渉できます。 | | 1 | オプアート_は間違えます。| 配列Error、(例えば、TLS、既に|、|、|、|、確立、) | | 2 | プロト_は間違えます。| TLSのサポートしていないか不正確でないPDU| | | | 形式。 | | 3 | UNAVAIL| TLSサービス問題かRRCサーバ| | | | 落ちること。 | | 4 | CONF_REQD| 秘密性サービスが必要です。 | | | | | | 5 | 強い_AUTH_REQD| 強い認証サービス| | | | 必要。 | | 6 | 紹介| RRC Serverサポートへの紹介| | | | TLS。 | +-------+------------------+----------------------------------------+
Table 2
テーブル2
Other fields of the PDU are as specified in Figure 1.
PDUの他の分野が図1で指定されるようにあります。
Siddiqui, et al. Standards Track [Page 17] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[17ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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をサポートしないなら(デザインか現在の構成にかかわらず)、それはプロト_ERR、または、REFERRALにresultCodeを設定しなければなりません。 紹介のresultCodeを返すなら、サーバはRAQMON REFER分野に実際の紹介値を含まなければなりません。 サーバが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を返さなければなりません。 クライアントは、StartTLS操作を再試行するか、RAQMONセッションを続けるか、または接続を終えるかもしれません。
2.2.1. Sequencing of the Start TLS Operation
2.2.1. スタートTLS操作の配列
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接続の総合的なセキュリティの種々相を考慮に入れます。
2.2.1.1. Requesting to Start TLS on a RAQMON Association
2.2.1.1. RAQMON協会にTLSを始動する要求
The client MAY send the StartTLS request at any time after establishing an RAQMON (TCP) connection, except that in the following cases the client MUST NOT send a StartTLS request:
クライアントはクライアントが送ってはいけない以下の場合におけるそれを除いて、RAQMON(TCP)接続を確立した後にいつでもStartTLS要求にStartTLS要求を送るかもしれません:
o if TLS is currently established on the connection, or
o またはTLSが接続のときに現在設立されるなら。
o if RAQMON traffic is in progress on the connection.
o RAQMONトラフィックが接続のときに進行しているなら。
The result of violating any of these requirements is a Result of OP_ERR, as described above in Table 2.
これらの要件のどれかに違反するという結果はTable2で上で説明されるようにOP_ERRのResultです。
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結果でその要求を拒絶しなければなりません。 クライアントは拡張要求、またはそれが閉じるのを選ぶかもしれないStart TLSに接続を送るかもしれません。
Siddiqui, et al. Standards Track [Page 18] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[18ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
2.2.1.2. Starting TLS
2.2.1.2. 始めの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 PDUsを移すのをやめた)は、TLS交渉を始めなければならないか、または接続を終えなければなりません。 クライアントは、TLS交渉[TLS]を開始するためにTLS Recordプロトコルでサーバとの基本的な輸送接続の直接上にPDUsを送るでしょう。
2.2.1.3. TLS Version Negotiation
2.2.1.3. TLSバージョン交渉
Negotiating the version of TLS or SSL to be used is a part of the TLS Handshake Protocol, as documented in [TLS]. The reader is referred to that document for details.
使用されるためにTLSかSSLのバージョンを交渉するのは、TLS Handshakeプロトコルの一部です、[TLS]に記録されるように。 読者は詳細のためのそのドキュメントを参照されます。
2.2.1.4. Discovery of Resultant Security Level
2.2.1.4. 結果のセキュリティー・レベルの発見
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接続の保証レベルを確かめるのは、実装に依存していて、人のそれぞれの地方の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交渉が.1にセクション2.2.2を完成した直後認証か秘密性のレベルが続けることができるくらいには高くなく、それがSHOULDであることは優雅にTLS接続を終えます。
The client MAY attempt to Start TLS again, MAY disconnect, or MAY proceed to send RAQMON session data, if RRC policy permits.
RRC方針が可能にするなら、再び5月のStart TLSへのクライアント5月の試みは、切断しかけるか、またはセッションデータをRAQMONに送りかけるかもしれません。
2.2.1.5. Server Identity Check
2.2.1.5. サーバ身元確認
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.
クライアントはサーバのCertificateメッセージに示されるようにサーバのアイデンティティに対してサーバのホスト名に関する理解をチェックしなければなりません、介入者攻撃を防ぐために。
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 マッチングは大文字と小文字を区別しないです。
Siddiqui, et al. Standards Track [Page 19] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[19ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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はexample.comではなく、a.example.com、b.example.comなどに合っているでしょう。 与えられたタイプの1つ以上のアイデンティティが証明書(例えば、1つ以上の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ベースのアイデンティティに合っていないなら、自動化されたクライアントSHOULDは接続を終えます、サーバのアイデンティティが疑わしいのを示す誤りを返す、そして/または、登録して。
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.
身元確認がこのセクション、クライアントSHOULDで説明したサーバを超えて、サーバが提供するのが認可される確実にするさらなる照合にそれが提供するために観測されるサービスをするように用意してください。 クライアントは、ローカルの方針情報を利用する必要があるかもしれません。
We also refer readers to similar guidelines as applied for LDAP over TLS [RFC4513].
また、私たちはTLS[RFC4513]の上でLDAPのための適用されるとしての同様のガイドラインに読者を差し向けます。
2.2.1.6. Client Identity Check
2.2.1.6. クライアント身元確認
Anonymous TLS authentication helps establish a TLS RAQMON session that offers
匿名のTLS認証は、それが提供するTLS RAQMONセッションを確立するのを助けます。
o server-authentication in course of TLS establishment and
o そしてTLS設立のコースでのサーバ証明。
o confidentiality and replay protection of RAQMON traffic, but
o RAQMONトラフィックの秘密性と反復操作による保護だけ
o no protection against man-in-the-middle attacks during session
establishment and
o そしてセッション設立の間の介入者攻撃に対するノー・プロテクション。
o no protection from spoofing attacks by unauthorized clients.
o スプーフィングからのノー・プロテクションは権限のないクライアントに攻撃されます。
The server MUST authenticate the RDS client when deployment is susceptible to the above threats. This is done by requiring client authentication during TLS session establishment.
展開が上の脅威に影響されやすいときに、サーバはRDSクライアントを認証しなければなりません。 TLSセッション設立の間、クライアント認証を必要とすることによって、これをします。
In the TLS negotiation, the server MUST request a certificate. The client will provide its certificate to the server and MUST perform a private-key-based encryption, proving it has the private key associated with the certificate.
TLS交渉では、サーバは証明書を要求しなければなりません。 クライアントは、証明書をサーバに提供して、個人的なキーベースの暗号化を実行しなければなりません、それには証明書に関連している秘密鍵があると立証して。
As deployments will require protection of sensitive data in transit, the client and server MUST negotiate a ciphersuite that contains a bulk encryption algorithm of appropriate strength.
展開がトランジットにおける、極秘データの保護を必要とするとき、クライアントとサーバは適切な強さの大量の暗号化アルゴリズムを含むciphersuiteを交渉しなければなりません。
Siddiqui, et al. Standards Track [Page 20] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[20ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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.
サーバは、クライアントの証明書が有効であることを確かめなければなりません。 通常、サーバはクライアントの証明書チェーンの証明書のいずれも証明書が知られているカリフォルニアによって発行されて、無効であるか取り消されないのをチェックするでしょう。 サーバがこれらのチェックを実行できるいくつかの手順があります。
The server validates the certificate by the Distinguished Name of the RDS client entity in the Subject field of the certificate.
サーバは証明書のSubject分野でRDSクライアント実体のDistinguished Nameによる証明書を有効にします。
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]の使用に適用されるでしょう。
2.2.1.7. Refresh of Server Capabilities Information
2.2.1.7. サーバ能力情報をリフレッシュしてください。
The client MUST refresh any cached server capabilities information upon TLS session establishment, such as prior RRC state related to a previous RAQMON session based on another DSRC. This is necessary to protect against active-intermediary attacks, which may have altered any server capabilities information retrieved prior to TLS establishment. The server MAY advertise different capabilities after TLS establishment.
クライアントはTLSセッション設立のどんなキャッシュされたサーバ能力情報もリフレッシュしなければなりません、別のDSRCに基づいている前のRAQMONセッションに関連する先のRRC状態などのように。 これが、活発な仲介者攻撃から守るのに必要です。(攻撃はTLS設立の前に検索されたどんなサーバ能力情報も変更しました)。 サーバはTLS設立の後に異なった能力の広告を出すかもしれません。
2.2.2. Closing a TLS Connection
2.2.2. TLS接続を終えます。
2.2.2.1. Graceful Closure
2.2.2.1. 優雅な閉鎖
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.
クライアントかサーバが、RAQMONセッションのときにTLS閉鎖警戒を送ることによって、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メッセージも捨てなければなりません。 警戒の領収書に従って、それは、RAQMON PDUsをTLS RecordプロトコルPDUsを送るのをやめて、送って、受けるかもしれません。
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閉鎖警戒を伝えなければなりません。 それは、RAQMON PDUsを次に、TLS RecordプロトコルPDUsを送るのをやめて、送って、受けるかもしれません。
Siddiqui, et al. Standards Track [Page 21] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[21ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
2.2.2.2. Abrupt Closure
2.2.2.2. 突然の閉鎖
Either the client or server MAY abruptly close the entire RAQMON session and any TLS connection established on it by dropping the underlying TCP connection. It MAY be possible for RRC to send RDS a disconnection notification, which allows the client to know that the disconnection is not due to network failure. However, this message is not defined in this version.
クライアントかサーバが突然にそれで基本的なTCP接続を下げることによって確立された全体のRAQMONセッションとどんなTLS接続も終えるかもしれません。 RRCが断線通知をRDSに送るのは、可能であるかもしれません。(クライアントは通知で断線がネットワーク失敗のためでないことを知ることができます)。 しかしながら、このメッセージはこのバージョンで定義されません。
2.3. SNMP Notifications as an RDS/RRC Network Transport Protocol
2.3. RDS/RRCネットワークトランスポート・プロトコルとしてのSNMP通知
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 Frameworkの固有の目的でした。 RAQMON PDUを輸送する手段としてのSNMPの選択はRAQMON Data Sources(RDSs)として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 混雑の可能性はTCP輸送より高いです、トランスポート層のUDPの使用法のために。
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輸送の用法はSNMP輸送の上の展開でどこでも、1組のRDS/RRCに入手できるところのRECOMMENDEDです。
o The usage of Inform PDUs is RECOMMENDED.
o Inform PDUsの使用法はRECOMMENDEDです。
o The usage of Traps PDU is NOT RECOMMENDED.
o Traps PDUの使用法はNOT RECOMMENDEDです。
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サイズの限界の中で保守されるのは、RECOMMENDEDです。
If SNMP is chosen as a mechanism to transport RAQMON PDUs, the following specification applies to RAQMON-related usage of SNMP:
SNMPがRAQMON PDUsを輸送するためにメカニズムとして選ばれているなら、以下の仕様はSNMPのRAQMON関連の使用法に適用されます:
Siddiqui, et al. Standards Track [Page 22] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[22ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
o RDSs implement the capability of embedding RAQMON parameters in
SNMP Notifications, re-using well-known SNMP mechanisms to report
RAQMON Statistics. The RAQMON RDS MIB module, as specified in
2.1.1, MUST be used in order to map the RAQMON PDUs onto the SNMP
Notifications transport.
o RDSsはRAQMON Statisticsを報告するのによく知られるSNMPメカニズムを再使用して、SNMP NotificationsのRAQMONパラメタを埋め込む能力を実装します。 RAQMON RDS MIBモジュール、指定されて、2.1、.1、SNMP Notifications輸送にRAQMON PDUsを写像するのに使用しなければなりません。
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 RDSsが計算上豊かでなく、RDS実現をできるだけ軽量に保つために、GET、GETとSETコマンド以外のSETなどが[RFC3414]によって定義されたベースのUser Security Model(USM)を実装するのが必要であるようにRDSsはSNMP要求に応じないかもしれません。
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 INFORM PDUs SHOULD、混雑を満たすために要件を保護してください。使用されます。 INFORM PDUsが使用されているといけないので、RDSsはRRCsからSNMP INFORM応答を処理しなければならなくて、PDU通信速度(すなわち、PDUSの数が特定の時間間隔で送った限界)を連載しなければなりません。
o Standard UDP port 162 SHOULD be used for SNMP Notifications.
o 標準のUDPは162SHOULDを移植します。SNMP Notificationsのために、使用されます。
2.3.1. Encoding RAQMON Using the RAQMON RDS MIB Module
2.3.1. RAQMON RDS MIBモジュールを使用することでRAQMONをコード化します。
The RAQMON RDS MIB module is used to map RAQMON PDUs onto SNMP Notifications for transport purposes. The MIB module defines the objects needed for mapping the BASIC part of RAQMON PDU, defined in [RFC4710], as well as the Notifications themselves. In order to incorporate any application-specific extensions in the Application (APP) part of RAQMON PDU, as defined in [RFC4710], additional variable bindings MAY be included in RAQMON notifications as described in the MIB module.
RAQMON RDS MIBモジュールは、輸送目的のためにRAQMON PDUsをSNMP Notificationsに写像するのに使用されます。 MIBモジュールはNotifications自身と同様に[RFC4710]で定義されたRAQMON PDUのBASIC一部を写像するのに必要であるオブジェクトを定義します。 [RFC4710]で定義されるようにRAQMON PDUのApplication(APP)部分でのどんなアプリケーション特有の拡大も取り入れるために、追加変項束縛はMIBモジュールで説明されるRAQMON通知に含まれるかもしれません。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概要について、[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].
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 一般に、MIBオブジェクトはSimple Network Managementプロトコル(SNMP)を通してアクセスされます。 MIBのオブジェクトは、Management情報(SMI)のStructureで定義されたメカニズムを使用することで定義されます。 このメモはSTD58で説明されるSMIv2[RFC2578]、STD58、[RFC2579]、およびSTD58[RFC2580]に対応であるMIBモジュールを指定します。
Siddiqui, et al. Standards Track [Page 23] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[23ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
The following MIB module IMPORTS definitions from the following:
以下からの以下のMIBモジュールIMPORTS定義:
SNMPv2-SMI [RFC2578]
SNMPv2-TC [RFC2579]
SNMPv2-CONF [RFC2580]
RMON-MIB [RFC2819]
DIFFSERV-DSCP-TC [RFC3289]
SNMP-FRAMEWORK-MIB [RFC3411]
INET-ADDRESS-MIB [RFC4001]
SNMPv2-SMI[RFC2578]SNMPv2-Tc[RFC2579]SNMPv2-CONF[RFC2580]RMON-MIB[RFC2819]DIFFSERV-DSCP-Tc[RFC3289]SNMPフレームワークMIB[RFC3411]INETアドレスMIB[RFC4001]
It also uses REFERENCE clauses to refer to [RFC4710].
また、それは示すREFERENCE節[RFC4710]を使用します。
RAQMON-RDS-MIB DEFINITIONS ::= BEGIN
RAQMON-RDS-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Counter32, Unsigned32
FROM SNMPv2-SMI
SNMPv2-SMIからモジュールアイデンティティ、オブジェクト・タイプ、通知タイプ、Counter32、Unsigned32をインポートします。
DateAndTime
FROM SNMPv2-TC
SNMPv2-TcからのDateAndTime
rmon
FROM RMON-MIB
rmon FROM RMON-MIB
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
SNMPフレームワークMIBからのSnmpAdminString
InetAddressType, InetAddress, InetPortNumber
FROM INET-ADDRESS-MIB
INETアドレスMIBからのInetAddressType、InetAddress、InetPortNumber
Dscp
FROM DIFFSERV-DSCP-TC
DIFFSERV-DSCP-TcからのDscp
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF;
SNMPv2-CONFからのモジュールコンプライアンス、オブジェクトグループ、通知グループ。
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モジュールアイデンティティ最終更新日の"200610100000Z"--「WGは以下をメールする」という2006年10月10日組織「RMONワーキンググループ」コンタクトインフォメーション rmonmib@ietf.org は申し込まれます: rmonmib-request@ietf.org
MIB Editor:
Eugene Golovinsky
Postal: BMC Software, Inc.
2101 CityWest Boulevard,
MIBエディタ: ユージンGolovinsky郵便: BMCソフトウェアInc.2101CityWest並木街
Siddiqui, et al. Standards Track [Page 24] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[24ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
Houston, TX, 77094
USA
Tel: +713-918-1816
Email: egolovin@bmc.com
"
DESCRIPTION
"This is the RAQMON Data Source notification MIB Module.
It provides a mapping of RAQMON PDUs to SNMP
notifications.
ヒューストン、テキサス77094米国Tel: +713-918-1816はメールされます: egolovin@bmc.com 、「記述、「これはRAQMON Data Source通知MIB Moduleです」。 それはRAQMON PDUsに関するマッピングをSNMP通知に提供します。
Ds stands for data source.
Dsはデータ送信端末を表します。
Note that all of the object types defined in this module
are accessible-for-notify and would consequently not be
available to a browser using simple Get, GetNext, or
GetBulk requests.
そして、注意、アクセスしやすい、通知、その結果、ブラウザにおいて、簡単なGet、GetNext、またはGetBulk要求を使用することで利用可能でないでしょう。
Copyright (c) The Internet Society (2006).
Copyright(c)インターネット協会(2006)。
This version of this MIB module is part of RFC 4712;
See the RFC itself for full legal notices."
このMIBモジュールのこのバージョンはRFC4712の一部です。 「完全な法定の通知に関してRFC自身を見てください。」
REVISION "200610100000Z" -- October 10, 2006
DESCRIPTION
"Initial version, published as RFC 4712."
REVISION"200610100000Z"--「初期のバージョンであって、RFC4712として発行された」2006年10月10日記述。
::= { rmon 32 }
::= rmon32
-- This OID allocation conforms to [RFC3737]
-- このOID配分は従います。[RFC3737]
raqmonDsNotifications OBJECT IDENTIFIER ::= { raqmonDsMIB 0 }
raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDsMIB 1 }
raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDsMIB 2 }
raqmonDsNotificationsオブジェクト識別子:、:= raqmonDsMIB0raqmonDsMIBObjectsオブジェクト識別子:、:= raqmonDsMIB1raqmonDsConformanceオブジェクト識別子:、:= raqmonDsMIB2
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.
「この概念的なテーブルはRAQMON BASIC PDUに関するSNMPマッピングを提供する」raqmonDsNotificationTable OBJECT-TYPEのSYNTAX SEQUENCE OF RaqmonDsNotificationEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 それは同輩実体のRAQMON Data Source、サブセッション、およびアドレスによって索引をつけられます。
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,
度を超すのがRFC2578セクション3.5で定義したこのテーブルの物価スライド制に関する心配が全くないことに注意してください。 [RFC4710]、セクション5.1によると
Siddiqui, et al. Standards Track [Page 25] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[25ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
only IPv4 and IPv6 addresses can be reported as
participant addresses."
::= { raqmonDsMIBObjects 1 }
「関与しているアドレスとしてIPv4とIPv6アドレスしか報告できません。」 ::= raqmonDsMIBObjects1
raqmonDsNotificationEntry OBJECT-TYPE
SYNTAX RaqmonDsNotificationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The entry (row) is not retrievable and is not kept by
RDSs. It serves data organization purposes only."
INDEX { raqmonDsDSRC, raqmonDsRCN, raqmonDsPeerAddrType,
raqmonDsPeerAddr }
::= { raqmonDsNotificationTable 1 }
raqmonDsNotificationEntry OBJECT-TYPE SYNTAX RaqmonDsNotificationEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「エントリー(行)は、回収可能でなく、またRDSsによって保たれません」。 「データ編成目的だけに役立ちます。」 raqmonDsDSRC、raqmonDsRCN、raqmonDsPeerAddrType、raqmonDsPeerAddrに索引をつけてください:、:= raqmonDsNotificationTable1
RaqmonDsNotificationEntry ::= SEQUENCE {
raqmonDsDSRC Unsigned32,
raqmonDsRCN Unsigned32,
raqmonDsPeerAddrType InetAddressType,
raqmonDsPeerAddr InetAddress,
raqmonDsAppName SnmpAdminString,
raqmonDsDataSourceDevicePort InetPortNumber,
raqmonDsReceiverDevicePort InetPortNumber,
raqmonDsSessionSetupDateTime DateAndTime,
raqmonDsSessionSetupDelay Unsigned32,
raqmonDsSessionDuration Unsigned32,
raqmonDsSessionSetupStatus SnmpAdminString,
raqmonDsRoundTripEndToEndNetDelay Unsigned32,
raqmonDsOneWayEndToEndNetDelay Unsigned32,
raqmonDsApplicationDelay Unsigned32,
raqmonDsInterArrivalJitter Unsigned32,
raqmonDsIPPacketDelayVariation Unsigned32,
raqmonDsTotalPacketsReceived Counter32,
raqmonDsTotalPacketsSent Counter32,
raqmonDsTotalOctetsReceived Counter32,
raqmonDsTotalOctetsSent Counter32,
raqmonDsCumulativePacketLoss Counter32,
raqmonDsPacketLossFraction Unsigned32,
raqmonDsCumulativeDiscards Counter32,
raqmonDsDiscardsFraction Unsigned32,
raqmonDsSourcePayloadType Unsigned32,
raqmonDsReceiverPayloadType Unsigned32,
raqmonDsSourceLayer2Priority Unsigned32,
raqmonDsSourceDscp Dscp,
raqmonDsDestinationLayer2Priority Unsigned32,
raqmonDsDestinationDscp Dscp,
raqmonDsCpuUtilization Unsigned32,
raqmonDsMemoryUtilization Unsigned32 }
RaqmonDsNotificationEntry:、:= 系列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
Siddiqui, et al. Standards Track [Page 26] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[26ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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 }
「データSource識別子は実体を伝えながら、特定のセッションまで指すユニークなセッション記述子を表す」raqmonDsDSRC OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 2つの実体の間に行われたセッションのためにユニークな識別子は交信実体によって生成されます。 「ゼロは特別な意味論がなければ有効値です。」 ::= raqmonDsNotificationEntry1
raqmonDsRCN OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Record Count Number indicates a sub-session
within a communication session. A maximum number of 16
sub-sessions are supported; this limitation is
dictated by reasons of compatibility with other
transport protocols."
::= { raqmonDsNotificationEntry 2 }
raqmonDsRCN OBJECT-TYPE SYNTAX Unsigned32(0 .15)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「Record Count Numberはコミュニケーションセッション以内にサブセッションを示します」。 16のサブセッションの最大数はサポートされます。 「この制限は他のトランスポート・プロトコルとの互換性の理由によって書き取られます。」 ::= raqmonDsNotificationEntry2
raqmonDsPeerAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of the Internet address of the peer participant
for this session."
REFERENCE
"Section 5.2 of [RFC4710]"
::= { raqmonDsNotificationEntry 3 }
「インターネットのタイプはこのセッションのために同輩関係者に扱う」raqmonDsPeerAddrType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「[RFC4710]のセクション5.2」という参照:、:= raqmonDsNotificationEntry3
raqmonDsPeerAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Internet Address of the peer participant for this
session."
REFERENCE
"Section 5.2 of [RFC4710]"
::= { raqmonDsNotificationEntry 4 }
raqmonDsPeerAddr OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このセッションのための同輩関係者のインターネットAddress。」 「[RFC4710]のセクション5.2」という参照:、:= raqmonDsNotificationEntry4
raqmonDsAppName OBJECT-TYPE
raqmonDsAppNameオブジェクト・タイプ
Siddiqui, et al. Standards Track [Page 27] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[27ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
SYNTAX SnmpAdminString
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"This is a text string giving the name and possibly the
version of the application associated with that session,
e.g., 'XYZ VoIP Agent 1.2'."
REFERENCE
"Section 5.28 of [RFC4710]"
::= { raqmonDsNotificationEntry 5 }
SYNTAX SnmpAdminStringマックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「これはそのセッションと共に名前とことによるとアプリケーションのバージョンを関連しているのに与えるテキスト文字列、例えば、'XYZ VoIPエージェント1.2'です。」 「[RFC4710]のセクション5.28」という参照:、:= raqmonDsNotificationEntry5
raqmonDsDataSourceDevicePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The port number from which data for this session was sent
by the Data Source device."
REFERENCE
"Section 5.5 of [RFC4710]"
::= { raqmonDsNotificationEntry 6 }
raqmonDsDataSourceDevicePort OBJECT-TYPE SYNTAX InetPortNumberマックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「Data Sourceデバイスはこのセッションのためのどのデータからポートナンバーを送りました」。 「[RFC4710]のセクション5.5」という参照:、:= raqmonDsNotificationEntry6
raqmonDsReceiverDevicePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The port number where the data for this session was
received."
REFERENCE
"Section 5.6 of [RFC4710]"
::= { raqmonDsNotificationEntry 7 }
raqmonDsReceiverDevicePort OBJECT-TYPE SYNTAX InetPortNumberマックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「このセッションのためのデータが受け取られたポートナンバー。」 「[RFC4710]のセクション5.6」という参照:、:= raqmonDsNotificationEntry7
raqmonDsSessionSetupDateTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The time when session was initiated."
REFERENCE
"Section 5.7 of [RFC4710]"
::= { raqmonDsNotificationEntry 8 }
raqmonDsSessionSetupDateTime OBJECT-TYPE SYNTAX DateAndTimeマックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「セッションが開始された時間」。 「[RFC4710]のセクション5.7」という参照:、:= raqmonDsNotificationEntry8
raqmonDsSessionSetupDelay OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
raqmonDsSessionSetupDelay OBJECT-TYPE SYNTAX Unsigned32(0 .65535)UNITS「ミリセカンド」マックス-ACCESS、アクセスしやすい、通知、STATUS海流
Siddiqui, et al. Standards Track [Page 28] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[28ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
DESCRIPTION
"Session setup time."
REFERENCE
"Section 5.8 of [RFC4710]"
::= { raqmonDsNotificationEntry 9 }
記述「セッション準備時間。」 「[RFC4710]のセクション5.8」という参照:、:= raqmonDsNotificationEntry9
raqmonDsSessionDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session duration, including setup time. The SYNTAX of
this object allows expression of the duration of sessions
that do not exceed 4660 hours and 20 minutes."
REFERENCE
"Section 5.9 of [RFC4710]"
::= { raqmonDsNotificationEntry 10 }
raqmonDsSessionDuration OBJECT-TYPE SYNTAX Unsigned32 UNITS「秒」マックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「準備時間を含むセッション持続時間。」 「このオブジェクトのSYNTAXは4660時間と20分を超えていないセッションの持続時間の式を許容します。」 「[RFC4710]のセクション5.9」という参照:、:= raqmonDsNotificationEntry10
raqmonDsSessionSetupStatus OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Describes appropriate communication session states, e.g.,
Call Established successfully, RSVP reservation
failed, etc."
REFERENCE
"Section 5.10 of [RFC4710]"
::= { raqmonDsNotificationEntry 11 }
raqmonDsSessionSetupStatus OBJECT-TYPE SYNTAX SnmpAdminStringマックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述は「適切なコミュニケーションセッション州、例えば首尾よく、RSVPの予約が失敗したCall Establishedについて説明しますなど」。 「[RFC4710]のセクション5.10」という参照:、:= raqmonDsNotificationEntry11
raqmonDsRoundTripEndToEndNetDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Most recent available information about the
round-trip end-to-end network delay."
REFERENCE
"Section 5.11 of [RFC4710]"
::= { raqmonDsNotificationEntry 12}
raqmonDsRoundTripEndToEndNetDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS「ミリセカンド」マックス-ACCESS、アクセスしやすい、通知、「終わりから終わりへの往復のネットワークに関する最新の入手可能な情報は遅らせる」STATUSの現在の記述。 「[RFC4710]のセクション5.11」という参照:、:= raqmonDsNotificationEntry12
raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE SYNTAX Unsigned32 UNITS「ミリセカンド」マックス-ACCESS、アクセスしやすい、通知、STATUS海流
Siddiqui, et al. Standards Track [Page 29] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[29ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
DESCRIPTION
"Most recent available information about the
one-way end-to-end network delay."
REFERENCE
"Section 5.12 of [RFC4710]"
::= { raqmonDsNotificationEntry 13}
「終わりから終わりへの一方向ネットワークに関する最新の入手可能な情報は遅らせる」記述。 「[RFC4710]のセクション5.12」という参照:、:= raqmonDsNotificationEntry13
raqmonDsApplicationDelay OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Most recent available information about the
application delay."
REFERENCE
"Section 5.13 of [RFC4710"
::= { raqmonDsNotificationEntry 14}
raqmonDsApplicationDelay OBJECT-TYPE SYNTAX Unsigned32(0 .65535)UNITS「ミリセカンド」マックス-ACCESS、アクセスしやすい、通知、「アプリケーションに関する最新の入手可能な情報は遅らせる」STATUSの現在の記述。 参照、「5.13を区分する、[RFC4710、」 : : =raqmonDsNotificationEntry14
raqmonDsInterArrivalJitter OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the inter-arrival jitter."
REFERENCE
"Section 5.14 of [RFC4710]"
::= { raqmonDsNotificationEntry 15}
raqmonDsInterArrivalJitter OBJECT-TYPE SYNTAX Unsigned32(0 .65535)UNITS「ミリセカンド」マックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「相互到着ジターの見積り。」 「[RFC4710]のセクション5.14」という参照:、:= raqmonDsNotificationEntry15
raqmonDsIPPacketDelayVariation OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the inter-arrival delay variation."
REFERENCE
"Section 5.15 of [RFC4710]"
::= { raqmonDsNotificationEntry 16}
raqmonDsIPPacketDelayVariation OBJECT-TYPE SYNTAX Unsigned32(0 .65535)UNITS「ミリセカンド」マックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「相互到着遅れ変化の見積り。」 「[RFC4710]のセクション5.15」という参照:、:= raqmonDsNotificationEntry16
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 Counter32 UNITS「パケット」マックス-ACCESS、アクセスしやすい、通知、「パケットの数はコミュニケーションの中で伝えた」STATUSの現在の記述
Siddiqui, et al. Standards Track [Page 30] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[30ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
session by the receiver since the start of the session."
REFERENCE
"Section 5.16 of [RFC4710]"
::= { raqmonDsNotificationEntry 17 }
「セッションの始まり以来の受信機によるセッション。」 「[RFC4710]のセクション5.16」という参照:、:= raqmonDsNotificationEntry17
raqmonDsTotalPacketsSent OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packets transmitted within a communication
session by the sender since the start of the session."
REFERENCE
"Section 5.17 of [RFC4710]"
::= { raqmonDsNotificationEntry 18 }
raqmonDsTotalPacketsSent OBJECT-TYPE SYNTAX Counter32 UNITS「パケット」マックス-ACCESS、アクセスしやすい、通知、「セッションの始まり以来パケットの数は送付者によるコミュニケーションセッション以内に伝えた」STATUSの現在の記述。 「[RFC4710]のセクション5.17」という参照:、:= raqmonDsNotificationEntry18
raqmonDsTotalOctetsReceived OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The total number of payload octets (i.e., not including
header or padding octets) transmitted in packets by the
receiver within a communication session since the start
of the session."
REFERENCE
"Section 5.18 of [RFC4710]"
::= { raqmonDsNotificationEntry 19 }
raqmonDsTotalOctetsReceived OBJECT-TYPE SYNTAX Counter32 UNITS「八重奏」マックス-ACCESS、アクセスしやすい、通知、「セッションの始まり以来ペイロード八重奏(すなわち、ヘッダーを含んでいないか、または八重奏を水増ししない)の総数はコミュニケーションセッション以内にパケットで受信機で伝えた」STATUSの現在の記述。 「[RFC4710]のセクション5.18」という参照:、:= raqmonDsNotificationEntry19
raqmonDsTotalOctetsSent OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of payload octets (i.e., not including headers
or padding) transmitted in packets by the sender within
a communication sub-session since the start of the
session."
REFERENCE
"Section 5.19 of [RFC4710]"
::= { raqmonDsNotificationEntry 20 }
raqmonDsTotalOctetsSent OBJECT-TYPE SYNTAX Counter32 UNITS「八重奏」マックス-ACCESS、アクセスしやすい、通知、「ペイロード八重奏(すなわち、ヘッダーを含んでいないか、またはそっと歩かない)の数はセッションの始まり以来のサブセッションのコミュニケーションの中でパケットで送付者で伝えた」STATUSの現在の記述。 「[RFC4710]のセクション5.19」という参照:、:= raqmonDsNotificationEntry20
raqmonDsCumulativePacketLoss OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
raqmonDsCumulativePacketLossオブジェクト・タイプ構文Counter32ユニット「パケット」
Siddiqui, et al. Standards Track [Page 31] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[31ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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 }
マックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「セッションの始まり以来損失が検出されていたこのセッションからのパケットの数。」 「[RFC4710]のセクション5.20」という参照:、:= raqmonDsNotificationEntry21
raqmonDsPacketLossFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The percentage of lost packets with respect to the
overall packets sent. This is defined to be 100 times
the number of packets lost divided by the number of
packets expected."
REFERENCE
"Section 5.21 of [RFC4710]"
::= { raqmonDsNotificationEntry 22 }
raqmonDsPacketLossFraction OBJECT-TYPE SYNTAX Unsigned32(0 .100)UNITS「送られたパケットの割合」マックス-ACCESS、アクセスしやすい、通知、「総合的なパケットに関する無くなっているパケットの割合は送った」STATUSの現在の記述。 「これはパケットの数が失った予想されたパケットの数が割られた100回になるように定義されます。」 「[RFC4710]のセクション5.21」という参照:、:= raqmonDsNotificationEntry22
raqmonDsCumulativeDiscards OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packet discards detected since the
start of the session."
REFERENCE
"Section 5.22 of [RFC4710]"
::= { raqmonDsNotificationEntry 23 }
raqmonDsCumulativeDiscards OBJECT-TYPE SYNTAX Counter32 UNITS「パケット」マックス-ACCESS、アクセスしやすい、通知、「セッションの始まり以来パケット破棄の数は検出した」STATUSの現在の記述。 「[RFC4710]のセクション5.22」という参照:、:= raqmonDsNotificationEntry23
raqmonDsDiscardsFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The percentage of discards with respect to the overall
packets sent. This is defined to be 100 times the number
of discards divided by the number of packets expected."
REFERENCE
"Section 5.23 of [RFC4710]"
::= { raqmonDsNotificationEntry 24 }
raqmonDsDiscardsFraction OBJECT-TYPE SYNTAX Unsigned32(0 .100)UNITS「送られたパケットの割合」マックス-ACCESS、アクセスしやすい、通知、「総合的なパケットに関する破棄の割合は送った」STATUSの現在の記述。 「これは予想されたパケットの数が割られた数の100倍の破棄になるように定義されます。」 「[RFC4710]のセクション5.23」という参照:、:= raqmonDsNotificationEntry24
Siddiqui, et al. Standards Track [Page 32] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[32ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
raqmonDsSourcePayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet sent by this RDS."
REFERENCE
"RFC 1890, Section 5.24 of [RFC4710] "
::= { raqmonDsNotificationEntry 25 }
raqmonDsSourcePayloadType OBJECT-TYPE SYNTAX Unsigned32(0 .127)マックス-ACCESS、アクセスしやすい、通知、「パケットのペイロードタイプはこのRDSで送った」STATUSの現在の記述。 「RFC1890、[RFC4710]のセクション5.24」という参照:、:= raqmonDsNotificationEntry25
raqmonDsReceiverPayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet received by this RDS."
REFERENCE
"RFC 1890, Section 5.25 of [RFC4710] "
::= { raqmonDsNotificationEntry 26 }
raqmonDsReceiverPayloadType OBJECT-TYPE SYNTAX Unsigned32(0 .127)マックス-ACCESS、アクセスしやすい、通知、「パケットのペイロードタイプはこのRDSで受けた」STATUSの現在の記述。 「RFC1890、[RFC4710]のセクション5.25」という参照:、:= raqmonDsNotificationEntry26
raqmonDsSourceLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Source Layer 2 priority used by the data source to send
packets to the receiver by this data source during this
communication session."
REFERENCE
"Section 5.26 of [RFC4710]"
::= { raqmonDsNotificationEntry 27 }
raqmonDsSourceLayer2Priority OBJECT-TYPE SYNTAX Unsigned32(0 .7)マックス-ACCESS、アクセスしやすい、通知、「ソースLayer2優先権はこのコミュニケーションセッションの間、このデータ送信端末でパケットを受信機に送るのにデータ送信端末で使用した」STATUSの現在の記述。 「[RFC4710]のセクション5.26」という参照:、:= raqmonDsNotificationEntry27
raqmonDsSourceDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Layer 3 TOS/DSCP values used by the Data Source to
prioritize traffic sent."
REFERENCE
"Section 5.27 of [RFC4710]"
::= { raqmonDsNotificationEntry 28 }
raqmonDsSourceDscp OBJECT-TYPE SYNTAX Dscpマックス-ACCESS、アクセスしやすい、通知、「層3のTOS/DSCP値は送られたトラフィックを最優先させるのにData Sourceで使用した」STATUSの現在の記述。 「[RFC4710]のセクション5.27」という参照:、:= raqmonDsNotificationEntry28
raqmonDsDestinationLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
raqmonDsDestinationLayer2Priority OBJECT-TYPE SYNTAX Unsigned32(0 .7)マックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述
Siddiqui, et al. Standards Track [Page 33] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[33ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
"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 }
「目的地Layer2優先権。」 「これは同輩交信実体によって使用される、パケットをデータ送信端末に送る優先権です。」 「[RFC4710]のセクション5.28」という参照:、:= raqmonDsNotificationEntry29
raqmonDsDestinationDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Layer 3 TOS/DSCP values used by the
peer communicating entity to prioritize traffic
sent to the source."
REFERENCE
"Section 5.29 of [RFC4710]"
::= { raqmonDsNotificationEntry 30 }
raqmonDsDestinationDscp OBJECT-TYPE SYNTAX Dscpマックス-ACCESS、アクセスしやすい、通知、「層3のTOS/DSCP値はソースに送られたトラフィックを最優先させるのに同輩交信実体で使用した」STATUSの現在の記述。 「[RFC4710]のセクション5.29」という参照:、:= raqmonDsNotificationEntry30
raqmonDsCpuUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Latest available information about the total CPU
utilization."
REFERENCE
"Section 5.30 of [RFC4710]"
::= { raqmonDsNotificationEntry 31 }
raqmonDsCpuUtilization OBJECT-TYPE SYNTAX Unsigned32(0 .100)UNITS「パーセント」マックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「総CPU使用率に関する最新の入手可能な情報。」 「[RFC4710]のセクション5.30」という参照:、:= raqmonDsNotificationEntry31
raqmonDsMemoryUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Latest available information about the total memory
utilization."
REFERENCE
"Section 5.31 of [RFC4710]"
::= { raqmonDsNotificationEntry 32 }
raqmonDsMemoryUtilization OBJECT-TYPE SYNTAX Unsigned32(0 .100)UNITS「パーセント」マックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「総メモリ使用量に関する最新の入手可能な情報。」 「[RFC4710]のセクション5.31」という参照:、:= raqmonDsNotificationEntry32
-- definitions of the notifications
--
-- raqmonDsAppName is the only object that MUST be sent by an
-- RDS every time the static notification is generated.
-- 通知の定義--、--、raqmonDsAppNameがそれを送らなければならない唯一のオブジェクトである--、RDS、毎回、静的な通知は発生しています。
Siddiqui, et al. Standards Track [Page 34] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[34ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
-- raqmonDsTotalPacketsReceived is the only object that MUST be
-- sent by an RD every time the dynamic notification is generated.
-- raqmonDsTotalPacketsReceivedはそれは唯一のオブジェクトであるに違いありません--RDで、ダイナミックな通知が発生しているときはいつも、発信します。
-- 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からの他のオブジェクトはそうです--変項束縛リストでは、含まれています。 通知が情報を提供するMIBオブジェクトを含むという明確にアプリケーションセッションを特徴付ける測定基準の周りのraqmon
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 OBJECTS raqmonDsAppName、STATUSの現在の記述、「この通知はBASIC RAQMON PDUの静的なパラメタをSNMP輸送に写像します」。 セッション、または新しいサブセッションが開始されるときに時一度この通知が送られると予想されます。 以下のオブジェクトはraqmonDsStaticNotificationによって運ばれるかもしれません:
raqmonDsDataSourceDevicePort,
raqmonDsReceiverDevicePort,
raqmonDsSessionSetupDateTime,
raqmonDsSessionSetupDelay,
raqmonDsSessionDuration,
raqmonDsSourcePayloadType,
raqmonDsReceiverPayloadType,
raqmonDsSourceLayer2Priority,
raqmonDsSourceDscp,
raqmonDsDestinationLayer2Priority,
raqmonDsDestinationDscp
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 }
「それは断片化を避けるためにMTUサイズ限界の中に通知のサイズを保つRECOMMENDEDです。」 ::= raqmonDsNotifications1
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 OBJECTS raqmonDsTotalPacketsReceived、STATUSの現在の記述、「この通知はBASIC RAQMON PDUの動的パラメータをSNMP輸送に写像します」。
The following objects MAY be carried by the
raqmonDsDynamicNotification:
以下のオブジェクトはraqmonDsDynamicNotificationによって運ばれるかもしれません:
raqmonDsRoundTripEndToEndNetDelay,
raqmonDsOneWayEndToEndNetDelay,
raqmonDsRoundTripEndToEndNetDelay、raqmonDsOneWayEndToEndNetDelay
Siddiqui, et al. Standards Track [Page 35] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[35ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
raqmonDsApplicationDelay,
raqmonDsInterArrivalJitter,
raqmonDsIPPacketDelayVariation,
raqmonDsTotalPacketsSent,
raqmonDsTotalOctetsReceived,
raqmonDsTotalOctetsSent,
raqmonDsCumulativePacketLoss,
raqmonDsPacketLossFraction,
raqmonDsCumulativeDiscards,
raqmonDsDiscardsFraction,
raqmonDsCpuUtilization,
raqmonDsMemoryUtilization
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サイズ限界の中に通知のサイズを保つRECOMMENDEDです。」
::= { raqmonDsNotifications 2 }
::= raqmonDsNotifications2
raqmonDsByeNotification NOTIFICATION-TYPE
OBJECTS { raqmonDsAppName }
STATUS current
DESCRIPTION
"The BYE Notification. This Notification is the
equivalent of the RAQMON NULL PDU, which signals the
end of a RAQMON session."
::= { raqmonDsNotifications 3 }
raqmonDsByeNotification NOTIFICATION-TYPE OBJECTS raqmonDsAppName、STATUSの現在の記述、「さようなら通知。」 「このNotificationはRAQMON NULL PDUの同等物です。」(RAQMON NULL PDUはRAQMONセッションの終わりに合図します)。 ::= raqmonDsNotifications3
--
-- conformance information
raqmonDsCompliance OBJECT IDENTIFIER ::=
{ raqmonDsConformance 1 }
raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 }
-- -- 順応情報raqmonDsCompliance OBJECT IDENTIFIER:、:= raqmonDsConformance1raqmonDsGroupsオブジェクト識別子:、:= raqmonDsConformance2
raqmonDsBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities that
implement this MIB module.
raqmonDsBasicCompliance MODULE-COMPLIANCE STATUSの現在の記述、「このMIBモジュールを実装するSNMP実体のための承諾声明。」
There are a number of INDEX objects that cannot be
represented in the form of OBJECT clauses in SMIv2, but
for which we have the following compliance requirements,
expressed in OBJECT clause form in this description
clause:
SMIv2の私たちがこの記述節のOBJECT節フォームで言い表された以下の承諾要件を持っている、OBJECT節の形に表すことができない多くのINDEXオブジェクトがあります:
-- OBJECT raqmonDsPeerAddrType
-- SYNTAX InetAddressType { ipv4(1), ipv6(2) }
-- オブジェクトraqmonDsPeerAddrType--構文InetAddressTypeipv4(1)、ipv6(2)
Siddiqui, et al. Standards Track [Page 36] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[36ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
-- 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 }
-- このMIBがグローバルなIPv4だけに支持を要するという記述とIPv6はタイプに演説します。 -- -- SYNTAX InetAddress(SIZE(4|16))--記述--このMIBがグローバルなIPv4だけに支持を要するというOBJECT raqmonDsPeerAddrとIPv6はタイプに演説します。 -- 「MODULE--、このモジュールMANDATORY-GROUPS、raqmonDsNotificationGroup、raqmonDsPayloadGroup:、:、」= raqmonDsCompliance1
raqmonDsNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { raqmonDsStaticNotification,
raqmonDsDynamicNotification,
raqmonDsByeNotification }
STATUS current
DESCRIPTION
"Standard RAQMON Data Source Notification group."
::= { raqmonDsGroups 1 }
raqmonDsNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS、raqmonDsStaticNotification、raqmonDsDynamicNotification、raqmonDsByeNotification、STATUSの現在の記述「標準のRAQMON Data Source Notificationグループ。」 ::= raqmonDsGroups1
raqmonDsPayloadGroup OBJECT-GROUP
OBJECTS { raqmonDsAppName,
raqmonDsDataSourceDevicePort,
raqmonDsReceiverDevicePort,
raqmonDsSessionSetupDateTime,
raqmonDsSessionSetupDelay,
raqmonDsSessionDuration,
raqmonDsSessionSetupStatus,
raqmonDsRoundTripEndToEndNetDelay,
raqmonDsOneWayEndToEndNetDelay,
raqmonDsApplicationDelay,
raqmonDsInterArrivalJitter,
raqmonDsIPPacketDelayVariation,
raqmonDsTotalPacketsReceived,
raqmonDsTotalPacketsSent,
raqmonDsTotalOctetsReceived,
raqmonDsTotalOctetsSent,
raqmonDsCumulativePacketLoss,
raqmonDsPacketLossFraction,
raqmonDsCumulativeDiscards,
raqmonDsDiscardsFraction,
raqmonDsSourcePayloadType,
raqmonDsReceiverPayloadType,
raqmonDsPayloadGroupオブジェクト群対象、raqmonDsAppName、raqmonDsDataSourceDevicePort、raqmonDsReceiverDevicePort、raqmonDsSessionSetupDateTime、raqmonDsSessionSetupDelay、raqmonDsSessionDuration、raqmonDsSessionSetupStatus、raqmonDsRoundTripEndToEndNetDelay、raqmonDsOneWayEndToEndNetDelay、raqmonDsApplicationDelay; raqmonDsInterArrivalJitter、raqmonDsIPPacketDelayVariation、raqmonDsTotalPacketsReceived、raqmonDsTotalPacketsSent、raqmonDsTotalOctetsReceived、raqmonDsTotalOctetsSent、raqmonDsCumulativePacketLoss、raqmonDsPacketLossFraction、raqmonDsCumulativeDiscards、raqmonDsDiscardsFraction、raqmonDsSourcePayloadType、raqmonDsReceiverPayloadType
Siddiqui, et al. Standards Track [Page 37] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[37ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
raqmonDsSourceLayer2Priority,
raqmonDsSourceDscp,
raqmonDsDestinationLayer2Priority,
raqmonDsDestinationDscp,
raqmonDsCpuUtilization,
raqmonDsMemoryUtilization }
STATUS current
DESCRIPTION
"Standard RAQMON Data Source payload MIB objects group."
::= { raqmonDsGroups 2 }
raqmonDsSourceLayer2Priority、raqmonDsSourceDscp、raqmonDsDestinationLayer2Priority、raqmonDsDestinationDscp、raqmonDsCpuUtilization、raqmonDsMemoryUtilization 「標準のRAQMON Data SourceペイロードMIBオブジェクトは分類する」STATUSの現在の記述。 ::= raqmonDsGroups2
END
終わり
3. IANA Considerations
3. IANA問題
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を使用するアプリケーションが単一の固定ポートを必要とします。 デフォルトポートとしてのTCPの上のRAQMON PDUsの使用のためにIANAと共に示されたNo.7744を移植してください。 複数のアプリケーションを実行するホストは支給のRAQMONを使用した指示としてのこのポートかRAQMON RDSに食糧を供給する一部としての別々のTCPポートとRAQMON Collectorを使用するかもしれません。
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.
指定港番号はUnixオペレーティングシステムの中にポートナンバー配分練習を収容するために範囲に5000年より上で横たわるために選ばれて、特権があるプロセスがどこで1024より下でポートナンバーを使用できるだけであるか、そして、1024年と5000年の間ときのポートナンバーがオペレーティングシステムで自動的に割り当てられるということでした。
The OID assignment for the raqmonDsMIB MODULE-IDENTITY is made according to [RFC3737], and there is no need for any IANA action on this respect.
[RFC3737]に従ってraqmonDsMIB MODULE-IDENTITYのためのOID課題をします、そして、この敬意へのどんなIANA動作の必要も全くありません。
4. Congestion-Safe RAQMON Operation
4. 混雑安全なRAQMON操作
As outlined in earlier sections, the TCP congestion control mechanism provides inherent congestion safety features when TCP is implemented as transport to carry RAQMON PDU.
TCPがRAQMON PDUを運ぶために輸送として実装されるとき、以前のセクションで概説されているように、TCP混雑制御機構は固有の混雑安全機能を提供します。
To ensure congestion safety, clearly the best thing to do is to use a congestion-safe transport protocol such as TCP. If this is not feasible, it may be necessary to fall back to UDP since SNMP over UDP is a widely deployed transport protocol.
混雑安全を確実にするために、明確にする中で最も良いことはTCPなどの混雑安全輸送プロトコルを使用することです。 これが可能でないなら、UDPへ後ろへ下がるのが、UDPの上のSNMPが広く配布しているトランスポート・プロトコルであるので、必要であるかもしれません。
When SNMP is chosen as RAQMON PDU Transport, implementers MUST follow section 3 of [RFC4710], which outlines measures that MUST be taken to use RAQMON in a congestion-safe manner. Congestion safety
SNMPがRAQMON PDU Transportとして選ばれているとき、implementersは[RFC4710]のセクション3に従わなければなりません。(]は混雑安全な方法でRAQMONを使用するために実施されなければならない対策を概説します)。 混雑安全
Siddiqui, et al. Standards Track [Page 38] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[38ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
requirements in section 3 of [RFC4710] would ensure that a RAQMON implementation using SNMP over UDP does not lead to congestion under heavy network load.
[RFC4710]のセクション3の要件は、UDPの上でSNMPを使用するRAQMON実装が重いネットワーク負荷の下での混雑につながらないのを確実にするでしょう。
5. Acknowledgements
5. 承認
The authors would like to thank Bill Walker and Joseph Mastroguilio from Avaya and Bin Hu from Motorola for their discussions. The authors would also like to extend special thanks to Randy Presuhn, who reviewed this document for spelling and formatting purposes, and who provided a deep review of the technical content. We also would like to thank Bert Wijnen for the permanent coaching during the evolution of this document and the detailed review of its final versions. The Security Considerations section was reviewed by Sam Hartman and Kurt D. Zeilenga and almost completely re-written by Mahalingam Mani.
作者は彼らの議論についてAvayaとビン・胡からモトローラからビル・ウォーカーとジョゼフMastroguilioに感謝したがっています。 また、作者はランディPresuhnに特別な感謝を表したがっています。(Presuhnはスペルと形式目的のためのこのドキュメントを再検討して、技術的な内容の深いレビューを提供しました)。 また、発展の間のこのドキュメントの永久的なコーチと最終版の詳細なレビューについてバートWijnenに感謝申し上げます。 Security Considerations部は、サム・ハートマンとカートD.Zeilengaによって見直されて、Mahalingamマニによってほぼ完全に書き直されました。
6. Security Considerations
6. セキュリティ問題
[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 SHOULD、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展開SHOULD、盗聴から保護を前提として、権限のない第三者が潜在的に機密の情報を集めるのを防ぐことができてください。 DES(データ暗号化規格)や、[3DES]や、AES(エー・イー・エス)[AES]などの暗号技術に基づく秘密性をサポートする安全なトランスポート・プロトコルを使用することによって、これを達成できます。
3. Protection from DoS attacks directed at the RRC: RDSs send RAQMON
reports as a side effect of external events (for example, receipt
of a phone call). An attacker can try to overwhelm the RRC (or
the network) by initiating a large number of events in order to
swamp the RRC with excessive numbers of RAQMON PDUs.
3. DoS攻撃からの保護はRRCを向けました: RDSsは外部のイベント(例えば、電話の領収書)の副作用としてレポートをRAQMONに送ります。 攻撃者は、RAQMON PDUsの過度の数でRRCを圧倒するために多くのイベントを開始することによって、RRC(または、ネットワーク)を圧倒しようとすることができます。
Siddiqui, et al. Standards Track [Page 39] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[39ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
To prevent DoS attacks against the RRC, the RDS will send the
first report for a session only after the session has been
established, so that the session set-up process is not affected.
セッションが確立された後にだけRRCに対してDoS攻撃を防ぐために、RDSはセッションの最初のレポートを送るでしょう、セッションセットアッププロセスが影響を受けないように。
4. NAT and Firewall Friendly Design: The presence of IP addresses
and TCP/UDP port information in RAQMON PDUs may be NAT-
unfriendly. Where NAT-friendliness is a requirement, the RDS MAY
omit IP address information from the RAQMON PDU. Another way to
avoid this problem is by using NAT-Aware Application Layer
Gateways (ALGs) to ensure that correct IP addresses appear in
RAQMON PDUs.
4. NATとファイアウォールの好意的なデザイン: RAQMON PDUsのIPアドレスとTCP/UDPポート情報の存在はNAT無愛想であるかもしれません。 NAT友情が要件であるところでは、RDS MAYはRAQMON PDUからのIPアドレス情報を省略します。 この問題を避ける別の方法は、NAT意識しているApplication Layer Gateways(ALGs)を使用することです正しいIPアドレスがRAQMON PDUsに現れるのを保証するために。
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 MUSTの使用法、使用されて、トランスポート層セキュリティを提供してください。 セクション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:
また、このメモはRAQMON PDUsをSNMP Notificationsに写像する目的で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.
それがマックス-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モジュール(すなわち、アクセスしやすくないのを除いたマックス-ACCESSがあるオブジェクト)によるいくつかの読み込み可能なオブジェクトがいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 SNMPを通してネットワークの上にそれらを送るとき、その結果、GET、そして/または、これらのオブジェクトへのNOTIFYアクセスさえ制御して、ことによるとこれらのオブジェクトの値を暗号化するのさえ重要です。 これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です:
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を使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが安全なネットワークにこのMIBモジュールでだれに許容されているかに関してコントロールが全くありません。
Siddiqui, et al. Standards Track [Page 40] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[40ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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).
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは([RFC3410]を見てください、セクション8)、RECOMMENDEDです、SNMPv3の暗号のメカニズム(認証と秘密性のための)の全面的な支援を含んでいて。
It is a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
このMIBモジュールのインスタンスへのアクセスを与えるSNMP実体が本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
6.1. Usage of TLS with RAQMON
6.1. RAQMONとTLSの使用法
6.1.1. Confidentiality & Message Integrity
6.1.1. 秘密性とメッセージの保全
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-アドレス: RRC ip RDS_ポート/アドレス: RRCが移植するtupleによって特定されます。
6.1.2. TLS CipherSuites
6.1.2. TLS CipherSuites
Several issues should be considered when selecting TLS ciphersuites that are appropriate for use in a given circumstance. These issues include the following:
与えられた状況における使用に、適切なTLS ciphersuitesを選択するとき、いくつかの問題が考えられるべきです。 これらの問題は以下を含んでいます:
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.
パスワードと他のデータのための適切な秘密性保護を提供するciphersuiteの性能は輸送接続を移動しました。 クライアントとサーバimplementersは、いくつかのTLS ciphersuitesが秘密性保護を全く提供しないと認めるはずです、秘密性保護を提供する他のciphersuitesは力任せのメソッドを使用することで割られるのに被害を受け易いかもしれませんが、特に減少するCPU速度を絶えず増強すること時間が首尾よくそのような攻撃を仕掛けるのに必要であったの観点から。
Client and server implementers should carefully consider the value of the password or data being protected versus the level of confidentiality protection provided by the ciphersuite to ensure that the level of protection afforded by the ciphersuite is appropriate.
クライアントとサーバimplementersは、ciphersuiteによって提供された秘密性保護のレベルに対して保護されるパスワードかデータの値がciphersuiteによって提供された保護のレベルが確実に適切になるようにすると慎重に考えるはずです。
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.
中の男性へのciphersuiteの脆弱性(または、それの不足)、-、-中央は攻撃されます。 介入者攻撃SHOULD NOTに被害を受け易いCiphersuitesがパスワードか極秘データを保護するのに使用されて、中央の男性の危険が攻撃されるのは、ネットワーク・コンフィギュレーションがそのようなものでないなら取るにたらないです。
Siddiqui, et al. Standards Track [Page 41] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[41ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
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セッションの意図している使用に、交渉されたciphersuiteによって提供されたセキュリティー・サービスが適切であることを独自に確かめるべきです。 そうでなければ、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だけがクライアント認証なしで交渉されるとき、クライアントのアイデンティティは決して確立されません。 これで、どんな終わり実体も容易にTLSによって機密保護されたRAQMON接続をRRCに確立できます。 これは正統のRDSがクライアントであると偽造して、したがってRRCのモニターしているデータの保全に感染する機会を提供するだけではなく、RRCを氾濫データでDoSを発射するために本物のRDS実体のふりをしている権限のないクライアントまで開きもします。 RAQMON展開方針は、TLSセッション設立の間、RDSクライアント認証を必要とすると考えなければなりません、特に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ソースアドレスの合法化はSHOULDを扱います。そのような試みを検出するのが実行されます。
6.1.3. RAQMON Authorization State
6.1.3. RAQMON承認状態
Every RAQMON session (between RDS and RRC) has an associated authorization state. This state is comprised of numerous factors such as what (if any) authorization state has been established, how it was established, and what security services are in place. Some factors may be determined and/or affected by protocol events (e.g., StartTLS, or TLS closure), and some factors may be determined by external events (e.g., time of day or server load).
あらゆるRAQMONセッション(RDSとRRCの間の)には、関連承認状態があります。 この状態はどんな(もしあれば)承認状態を設置してあるか、そして、それがどのように設立されたか、そして、どんなセキュリティー・サービスが適所にあるかなどの多数の要素から成ります。 プロトコルイベント(例えば、StartTLS、またはTLS閉鎖)で、いくつかの要素が、決定する、そして/または、影響を受けるかもしれません、そして、外部のイベント(例えば、時刻かサーバ負荷)でいくつかの要素が決定するかもしれません。
While it is often convenient to view authorization state in simplistic terms (as we often do in this technical specification) such as "an anonymous state", it is noted that authorization systems in RAQMON implementations commonly involve many factors that interrelate.
それがしばしば「匿名の状態」などの安易な用語(私たちがこの技術仕様書でしばしばするように)による視点承認状態に便利である間、RAQMON実装における承認システムが一般的に相互に関係づける多くの要素にかかわることに注意されます。
Authorization in RAQMON is a local matter. One of the key factors in making authorization decisions is authorization identity. The initial session establishment defined in Section 2.2 allows information to be exchanged between the client and server to establish an authorization identity for the RAQMON session. The RRC is not to allow any RDS-transactions-related traffic through for processing until the client authentication is complete, unless anonymous authentication mode is negotiated.
RAQMONの承認は地域にかかわる事柄です。 承認決定をすることにおける主要因の1つは承認のアイデンティティです。 セクション2.2で定義された初期のセッション設立は、情報がRAQMONセッションのために承認のアイデンティティを証明するためにクライアントとサーバの間で交換されるのを許容します。 RRCがいずれも許容することになっていない、RDS、トランザクション関連、処理においてクライアント認証まで終えたトラフィックは完全です、匿名の認証モードが交渉されない場合。
Siddiqui, et al. Standards Track [Page 42] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[42ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
Upon initial establishment of the RAQMON session, the session has an anonymous authorization identity. Among other things, this implies that the client need not send a TLSStartRequired in the first PDU of the RAQMON message. The client may send any operation request prior to binding RDS to any authentication, and the RRC MUST treat it as if it had been performed after an anonymous RAQMON session start.
RAQMONセッションの当初設定のときに、セッションには、匿名の認可のアイデンティティがあります。 特に、これは、クライアントがRAQMONメッセージの最初のPDUでTLSStartRequiredを送る必要はないのを含意します。 クライアントは拘束力があるRDSの前でどんな操作要求もどんな認証にも送るかもしれません、そして、まるでそれが匿名のRAQMONセッション始めの後に実行されたかのようにRRC MUSTはそれを扱います。
The RDS automatically is placed in an unauthorized state upon RRC sending a TLSstart request to the RRC.
RDSは、TLSstart要求をRRCに送りながら、自動的にRRCの権限のない状態に置かれます。
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への外部の出来事に関する例です。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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)の構造」、STD58、RFC2578(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"、STD58、RFC2579、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"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000.
[RFC2819]Waldbusser(S.、「リモートネットワーク監視管理情報ベース」、STD59、RFC2819)は2000がそうするかもしれません。
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management
Information Base for the Differentiated Services
Architecture", RFC 3289, May 2002.
[RFC3289]ベイカー(F.とチェン、K.とA.スミス、「微分されたサービス構造のための管理情報ベース」RFC3289)は2002がそうするかもしれません。
Siddiqui, et al. Standards Track [Page 43] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[43ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
[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)管理枠組みについて説明するための構造」、STD62、RFC3411(2002年12月)。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwalder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwalder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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、「リアルタイムサービスのApplication Quality Monitoring(RAQMON)」、RFC4710 2006年10月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[TLS] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
7.2. Informative References
7.2. 有益な参照
[3DES] Americation National Standards Institute, "Triple Data
Encryption Algorithm Modes of Operation", ANSI
X9.52-1998.
Americation国家規格が設ける[3DES]、「三重のデータ暗号化アルゴリズム運転モード」、ANSI X9.52-1998。
[AES] Federal Information Processing Standard (FIPS),
"Specifications for the ADVANCED ENCRYPTION
STANDARD(AES)", Publication 197, November 2001.
[AES]連邦情報処理基準(FIPS)、「エー・イー・エスのための仕様(AES)」、公表197、2001年11月。
[IEEE802.1D] "Information technology-Telecommunications and
information exchange between systems--Local and
metropolitan area networks-Common Specification
a--Media access control (MAC) bridges:15802-3:
1998(ISO/IEC)", [ANSI/IEEE Std 802.1D Edition], 1998.
[IEEE802.1D] 「システムの間の情報交換--地方的、そして、メトロポリタンエリアネットワーク一般的なSpecification a--情報技術テレコミュニケーションとメディアアクセスは(MAC)橋: 15802-3を制御します」。 「1998(ISO/IEC)」、[ANSI/IEEE Std 802.1D版]、1998。
[RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305,
March 1992.
[RFC1305]工場(D.)は「1992年3月に時間プロトコルバージョン3インチ、RFC1305をネットワークでつなぎます」。
[RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321,
April 1992.
[RFC1321] Rivest、R.、「メッセージダイジェストアルゴリズムMD5"、RFC1321、1992年4月。」
Siddiqui, et al. Standards Track [Page 44] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[44ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
[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.スチュワート、「インターネット標準の管理枠組みのための序論と適用性声明」、RFC3410(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.
[RFC3414]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC3414、2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、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プロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日
[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、「Remote Monitoring(RMON)MIBモジュールのRegistryのためのIANA Guidelines」、RFC3737、2004年4月。
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security
Mechanisms", RFC 4513, June 2006.
[RFC4513] ハリソン、R.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日
[TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, December 2005.
[TLS-PSK]EronenとP.とH.Tschofenig、「トランスポート層セキュリティ(TLS)のためのあらかじめ共有された主要なCiphersuites」、RFC4279、2005年12月。
Siddiqui, et al. Standards Track [Page 45] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[45ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
Appendix A. Pseudocode
付録A.擬似コード
The implementation notes included in Appendix are for informational purposes only and are meant to clarify the RAQMON specification.
Appendixに含まれていた実現注意は、情報の目的だけのためにあって、RAQMON仕様をはっきりさせることになっています。
Pseudocode for RDS & RRC
RDS&RRCのための擬似コード
We provide examples of pseudocode for aspects of RDS and RRC. There may be other implementation methods that are faster in particular operating environments or have other advantages.
私たちはRDSとRRCの局面に擬似コードに関する例を提供します。 環境を特に操作しながら、より速いか、または他の利点を持っている他の実現方法があるかもしれません。
RDS:
when (session starts} {
report.identifier = session.endpoints, session.starttime;
report.timestamp = 0;
while (session in progress) {
wait interval;
report.statistics = update statistics;
report.curtimestamp += interval;
if encryption required
report_data = encrypt(report, encrypt parameters);
else
report_data = report;
raqmon_pdu = header, report_data;
send raqmon-pdu;
}
}
RDS: いつ、(セッション始め{report.identifierはsession.endpointsと等しいです、session.starttime; 間隔を待ってください; 暗号化がデータ=がコード化するレポート_を必要としたなら(報告してください、そして、パラメタをコード化してください)report.statisticsがアップデート統計(report.curtimestamp+=間隔)と等しい; レポート_データ=はほかの報告します; raqmon_pduはヘッダーと等しいです、レポート_データ; raqmon-pduを送ってください;(進行中におけるセッション)である間のreport.timestamp=0}
RRC:
listen on raqmon port
when ( raqmon_pdu received ) {
decrypt raqmon_pdu.data if needed
RRC: (raqmon_pdu受け取られている)であるときにはraqmonポートの上で聴いてください、必要であるなら、raqmon_がpdu.dataであると解読してください。
if report.identifier in database
if report.current_time_stamp > last update
update session statistics from report.statistics
else
discard report
}
データベースのreport.identifierであるなら、report.statisticsからのほかのreport.current_時間_スタンプ>アップデートアップデートセッション統計が捨てられるなら、報告してください。
Siddiqui, et al. Standards Track [Page 46] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[46ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
Authors' Addresses
作者のアドレス
Anwar Siddiqui Avaya 307 Middletown Lincroft Road Lincroft, NJ 80302 USA
ミドルタウンLincroft道路Lincroft、アンウォーSiddiqui Avaya307ニュージャージー80302米国
Phone: +1 732 852-3200 EMail: anwars@avaya.com
以下に電話をしてください。 +1 732 852-3200 メールしてください: anwars@avaya.com
Dan Romascanu Avaya Atidim Technology Park, Bldg #3 Tel Aviv, 61131 Israel
ダンRomascanu Avaya Atidim技術公園、Bldg#3テルアビブ、61131イスラエル
Phone: +972-3-645-8414 EMail: dromasca@avaya.com
以下に電話をしてください。 +972-3-645-8414 メールしてください: dromasca@avaya.com
Eugene Golovinsky Alert Logic
ユージンGolovinskyは論理を警告します。
Phone: +1 713 918-1816 EMail: gene@alertlogic.net
以下に電話をしてください。 +1 713 918-1816 メールしてください: gene@alertlogic.net
Mahfuzur Rahman Samsung Information Systems America 75 West Plumeria Drive San Jose, CA 95134 USA
西Plumeria Drive Mahfuzurラーマン・三星情報システムアメリカ75カリフォルニア95134サンノゼ(米国)
Phone: +1 408 544-5559
以下に電話をしてください。 +1 408 544-5559
Yongbum Yong Kim Broadcom 3151 Zanker Road San Jose, CA 95134 USA
YongbumヤングキムBroadcom3151Zanker Roadカリフォルニア95134サンノゼ(米国)
Phone: +1 408 501-7800 EMail: ybkim@broadcom.com
以下に電話をしてください。 +1 408 501-7800 メールしてください: ybkim@broadcom.com
Siddiqui, et al. Standards Track [Page 47] RFC 4712 Transport Mappings for RAQMON PDU October 2006
Siddiqui、他 標準化過程[47ページ]RFC4712は2006年10月にRAQMON PDUのためのマッピングを輸送します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Siddiqui, et al. Standards Track [Page 48]
Siddiqui、他 標準化過程[48ページ]
一覧
スポンサーリンク
