Network Working Group A. Siddiqui
Request for Comments: 4710 D. Romascanu
Category: Standards Track Avaya
E. Golovinsky
Alert Logic
October 2006
Real-time Application Quality-of-Service
Monitoring (RAQMON) Framework
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
There is a need to monitor end-devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications.
IP電話、ポケットベル、インスタントメッセージングクライアント、携帯電話、および様々な他のハンドヘルドコンピューティングデバイスなどのエンドデバイスを監視する必要があります。このメモは、これらのデバイス上で動作する様々なアプリケーションのリアルタイムのサービス品質（QoS）の監視を可能にするために、リモートネットワーク監視仕様の（RMON）ファミリーを拡張し、この情報が簡易ネットワークを使用してRMONファミリーと統合することを可能にします管理プロトコル（SNMP）。このメモは、アプリケーションのリアルタイムのQoSモニタリングのためのフレームワーク、アーキテクチャ、関連する評価指標、および輸送の要件を定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. RAQMON Functional Architecture ..................................4
3. RAQMON Operation in Congestion-Safe Mode .......................11
4. Measurement Methodology ........................................14
5. Metrics Pre-Defined for the BASIC Part of the RAQMON PDU .......14
6. Report Aggregation and Statistical Data processing .............28
7. Keeping Historical Data and Storage ............................29
8. Security Considerations ........................................30
9. Acknowledgements ...............................................32
10. Normative References ..........................................33
11. Informative References ........................................34
With the growth of the Internet and advancements in embedded technologies, smart IP devices (such as IP phones, pagers, instant message clients, mobile phones, wireless handhelds, and various other computing devices) have become an integral part of our day-to-day operations. Enterprise operators, information technology (IT) managers, application service providers, network service providers, and so on, need to monitor these application and device types in order to ensure that end user quality-of-service (QoS) objectives are met. This memo describes a monitoring solution for these environments, extending the remote network monitoring (RMON) family of specifications [RFC2819]. These extensions support real-time QoS monitoring of typical applications that run on end-devices mentioned above, and they allow this information to be integrated using the familiar RMON family of specifications via SNMP [RFC3416].
組み込み技術のインターネットと進歩の増加に伴い、（IP電話、ポケットベル、インスタントメッセージクライアント、携帯電話、ワイヤレスハンドヘルド機器、および様々な他のコンピューティングデバイスなど）、スマートIPデバイスは、私たちの一日対の不可欠な一部となっています日常業務。エンタープライズ事業者、情報技術（IT）管理者、アプリケーションサービスプロバイダ、ネットワーク・サービス・プロバイダー、およびように、サービス品質、エンド・ユーザーを確保するために、これらのアプリケーションやデバイスの種類を監視する必要があります（QoS）の目的が満たされています。このメモは仕様[RFC2819]のリモートネットワークモニタリング（RMON）ファミリーを拡張、これらの環境の監視ソリューションを記述する。これらの拡張機能は、前述したエンドデバイス上で動作する代表的なアプリケーションのリアルタイムのQoSモニタリングをサポートし、彼らがこの情報はSNMP [RFC3416]を経由して仕様のおなじみのRMONファミリを使用して統合することができます。
The Real-time Application QoS Monitoring Framework (RAQMON) allows end-devices and applications to report QoS statistics in real time. Many real-time applications (as well as non-real-time applications managed within the RMON family of specifications) can report application-level QoS statistics in real time using the RAQMON Framework outlined in this memo. Some possible applications scenarios include applications such as Voice over IP, Fax over IP, Video over IP, Instant Messaging (IM), Email, software download applications, e-business style transactions, web access from handheld computing devices, etc.
リアルタイムアプリケーションのQoS監視フレームワーク（RAQMON）は、エンドデバイスやアプリケーションをリアルタイムでQoS統計を報告することができます。多くのリアルタイムアプリケーション（だけでなく、仕様のRMONファミリー内で管理非リアルタイム・アプリケーション）はこのメモで概説RAQMON Frameworkを使用してリアルタイムでアプリケーションレベルのQoS統計情報を報告することができます。シナリオはなどボイスオーバーIP、IP、IP上のビデオの上ファックス、インスタントメッセージング（IM）、電子メール、ソフトウェアダウンロードアプリケーション、eビジネススタイルの取引、ハンドヘルドコンピューティングデバイスからのWebアクセスなどのアプリケーションが含まれるいくつかの可能なアプリケーション
The user experience of an application running on an IP end-device depends upon the type of application the user is running and the surrounding resources available to that application. An end-to-end application QoS experience is a compound effect of various application-level transactions and available network and host resources. For example, the end-to-end user experience of a Voice over IP (VoIP) call depends on the total time required to set up the call as much as on media-related performance parameters such as end-to-end network delay, jitter, packet loss, and the type of codec used in a call. The performance of a VoIP call is also influenced by behavior of network protocols like the Reservation Protocol (RSVP), explicit tags in differentiated services (DiffServ) [RFC2475] or IEEE 802.1 [IEEE802.1D] along with available host resources such as device CPU or memory utilized by other applications while the call is ongoing.
IPエンドデバイス上で動作するアプリケーションのユーザーエクスペリエンスは、そのアプリケーションが利用できるユーザーが実行しているアプリケーションの種類や周囲のリソースに依存します。エンドツーエンドのアプリケーションのQoSの経験は、様々なアプリケーションレベルのトランザクションと、利用可能なネットワークとホストリソースの化合物の効果です。例えば、ボイスオーバーIP（VoIP）のコールのエンドツーエンドのユーザーエクスペリエンスは、エンドツーエンドのネットワーク遅延などのメディア関連の性能パラメータに限り、コールを設定するために必要な総時間に依存しますジッタ、パケット損失、およびコールに使用するコーデックのタイプ。 VoIP通話のパフォーマンスはまた、デバイスのCPUとして利用できるホストリソースと一緒に予約プロトコル（RSVP）のようなネットワークプロトコル、差別化サービス（DiffServの）内の明示的なタグの動作[RFC2475]またはIEEE 802.1 [IEEE802.1D]の影響を受けていますまたはコールが進行中である間、他のアプリケーションが利用するメモリ。
The end-to-end application quality of service (QoS) experience is application context sensitive. For example, the kinds of parameters reported by an IP telephony application may not really be needed for other applications such as Instant Messaging. The RAQMON Framework offers a mechanism to report the end-to-end QoS experience appropriate for a specific application context by providing mechanisms to report a subset of metrics from a pre-defined list.
サービス（QoS）の経験のエンドツーエンドのアプリケーションの品質は、アプリケーションコンテキストに敏感です。例えば、IP電話アプリケーションによって報告されたパラメータの種類は、実際に、このようなインスタントメッセージングなどの他のアプリケーションのために必要とされないことがあります。 RAQMON Frameworkは、事前に定義されたリストからのメトリックのサブセットを報告する仕組みを提供することにより、特定のアプリケーションコンテキストのエンドツーエンドのQoS体験適切に報告するためのメカニズムを提供しています。
In order to facilitate a complete end-to-end view, RAQMON correlates statistics that involve:
完全なエンドツーエンドのビューを容易にするために、RAQMONは関与統計を相関します：
i. "User, Application, Session"-specific parameters (e.g., session setup time, session duration parameters based on application context).
私。 「ユーザ、アプリケーション、セッション」特異的パラメータ（例えば、セッションセットアップ時間、アプリケーション・コンテキストに基づいて、セッション継続時間パラメータ）。
ii. "IP end-device"-specific parameters during a session (e.g., CPU usage, memory usage).
II。 「IPエンドデバイス」セッション中に特異的パラメータ（例えば、CPU使用率、メモリ使用量）。
iii. "Transport network"-specific parameters during a session (e.g., end-to-end delay, one-way delay, jitter, packet loss etc).
III。セッション中に「トランスポートネットワーク」特異的パラメータ（例えば、エンドツーエンド遅延、一方向遅延、ジッター、パケット損失など）。
At any given point, the applications at these devices can correlate such diverse data and report end-to-end performance. The RAQMON Framework specified in this memo offers a mechanism to report such end-to-end QoS view and integrate such a view into the RMON family of specifications. In particular, the RAQMON Framework specifies the following:
任意の時点で、これらのデバイスでのアプリケーションは、このような多様なデータを相関し、エンドツーエンドのパフォーマンスを報告することができます。このメモで指定されたRAQMONフレームワークは、エンド・ツー・エンドのQoSビューを報告し、仕様のRMONファミリーに、このようなビューを統合するためのメカニズムを提供しています。特に、RAQMON Frameworkは、以下を指定します。
a. A set of basic metrics sent as reports between the RAQMON entities using for transport existing Internet Protocols such as TCP or SNMP.
A。輸送のために、このようなTCPやSNMPなど、既存のインターネットプロトコルを使用してRAQMONエンティティ間でレポートとして送信される基本的なメトリックのセット。
b. Requirements to be met by the underlying transport protocols that carry the RAQMON reports.
B。 RAQMONレポートを運ぶ基本的なトランスポートプロトコルが満たすべき要件。
c. A portion of the Management Information Base (MIB) as an extension of the RMON MIB Modules for use with network management protocols in the Internet community.
C。インターネットコミュニティでのネットワーク管理プロトコルで使用するためにRMON MIBモジュールの拡張として管理情報ベース（MIB）の一部。
This memo provides the RAQMON functional architecture, RAQMON entity definitions and requirements, requirements for the transport protocols, a set of metrics, and an information model for the RAQMON reports.
このメモは、RAQMON機能アーキテクチャを提供RAQMONエンティティ定義と要件、トランスポートプロトコルのための要件、メトリックのセット、およびRAQMONのための情報モデルを報告します。
Supplementary memos will describe the mapping of the basic RAQMON metrics onto different transport protocols. For example, the RAQMON PDU [RFC4712] memo provides definitions of syntactical PDU structure and use case scenarios of transmission of such PDUs over the Transmission Control Protocol (TCP) and the Simple Network Management Protocol (SNMP).
補足メモは、異なるトランスポートプロトコル上に基本的なRAQMONメトリックのマッピングを記述します。例えば、RAQMON PDU [RFC4712]メモは、伝送制御プロトコル（TCP）および簡易ネットワーク管理プロトコル（SNMP）を超えるようなPDUの送信の構文PDU構造とユースケースシナリオの定義を提供します。
The RAQMON MIB [RFC4711] memo describes the Management Information Base (MIB) for use with the SNMP protocol in the Internet community. The document proposes an extension to the Remote Monitoring MIB [RFC2819] to accommodate RAQMON solutions.
RAQMON MIB [RFC4711]メモは、インターネットコミュニティでのSNMPプロトコルで使用するための管理情報ベース（MIB）について説明します。文書はRAQMONソリューションに対応するために、リモートモニタリングMIB [RFC2819]への拡張を提案しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The RAQMON Framework extends the architecture created in the RMON MIB [RFC2819] by providing application performance information as experienced by end-users. The RAQMON architecture is based on three functional components named below:
RAQMONフレームワークは、エンドユーザが経験するように、アプリケーションのパフォーマンス情報を提供することにより、RMON MIB [RFC2819]で作成したアーキテクチャを拡張します。 RAQMONアーキテクチャは以下という名前の3つの機能コンポーネントに基づいています。
- RAQMON Data Source (RDS)
- RAQMONデータソース（RDS）
- RAQMON Report Collector (RRC)
- RAQMONレポートコレクタ（RRC）
- RAQMON MIB Structure
- RAQMON MIB構造
A RAQMON Data Source (RDS) is a functional component that acts as a source of data for monitoring purposes. End-devices like IP phones, cell phones, and pagers, and application clients like instant messaging clients, soft phones in PCs, etc., are envisioned to act as RDSs within the RAQMON Framework.
RAQMONデータソース（RDS）監視目的のためのデータのソースとして作用する機能部品です。などのインスタントメッセージングクライアント、PCのソフトフォン、などのIP電話、携帯電話、ポケットベル、およびアプリケーション・クライアントなどのエンドデバイスは、RAQMONフレームワーク内のRDSにとして機能することが想定されています。
+----------------------+ +---------------------------+
| IP End-Device | | IP End-Device >----+ |
|+--------------------+| |+--------------------+ | |
|| APPLICATION || || APPLICATION | | |
|| -Voice over IP <----(1)----> -Voice over IP >- + | |
|| -Instant Messaging|| || -Instant Messaging| | 3 |
|| -Email || || -Email | 2 | |
|+--------------------+| |+--------------------+ | | |
| | | | | |
| | | +------------------+ | | |
+----------------------+ | |RAQMON Data Source|<-+ | |
| | (RDS) |<---+ |
| +------------------+ |
+-----------|---------------+
|
(4) RAQMON PDU transported
over TCP or SNMP Notifications
|
+----------------------------+
| |
|/ |/
+------------------+ +------------------+ +------------+
|RAQMON Report | .. |RAQMON Report | | Management |
|Collector (RRC) #n| |Collector (RRC) #1|<--5-->| Application|
+------------------+ +------------------+ +------------+
Figure 1 - RAQMON Framework.
図1 - RAQMONフレームワーク。
(1) Communication Session between real-time applications
（1）リアルタイムアプリケーションの間の通信セッションを
(2) Context-Sensitive Metrics
（2）コンテキスト依存メトリック
(3) Device State Specific Metrics
（3）デバイス状態固有メトリック
(4) Reporting session - RAQMON metrics transmitted over specified interfaces (Specific Protocol Interface, IP Address, port)
（4）報告セッション - 指定されたインタフェースを介して送信RAQMONメトリック（特定のプロトコルインタフェース、IPアドレス、ポート）
(5) Management Application - RRC interaction using the RAQMON MIB
（5）管理アプリケーション - RAQMON MIBを使用してRRCとの対話
A RAQMON Report Collector (RRC) collects statistics from multiple RDSs, analyzes them, and stores such information appropriately. RRC is envisioned to be a network server, serving an administrative domain defined by the network administrator. The RRC component of the RAQMON architecture is envisioned to be computationally resourceful. Only RRCs should implement the RAQMON MIB module.
RAQMONレポートコレクター（RRC）は、複数のRDSからの統計情報を収集し、それらを分析し、適切に保存するような情報。 RRCは、ネットワーク管理者によって定義された管理ドメインにサービスを提供する、ネットワーク・サーバであることを想定しています。 RAQMONアーキテクチャのRRC成分を計算機知であると想定されます。唯一のRRCsはRAQMON MIBモジュールを実装する必要があります。
The RAQMON Management Information Base (RAQMON MIB) extends the Remote Monitoring MIB [RFC2819] to accommodate the RAQMON Framework and exposes End-to-End Application QoS information to Network Management Applications.
RAQMON管理情報ベース（RAQMON MIB）はRAQMONフレームワークに対応するために、リモートモニタリングMIB [RFC2819]を拡張し、ネットワーク管理アプリケーションへのエンドツーエンドのアプリケーションQoS情報を公開します。
A RAQMON Data Source (RDS) is a source of data for monitoring purposes. The RDS monitoring function is performed in real time during communication sessions. The RDS entities capture QoS attributes of such communication sessions and report them within a RAQMON "reporting session".
RAQMONデータソース（RDS）は、監視目的のためのデータのソースです。 RDS監視機能は、通信セッション中にリアルタイムで行われます。 RDSエンティティは、QoSは、通信セッションの属性をキャプチャして、RAQMON「セッションの報告」の中にそれらを報告します。
An RDS is primarily responsible for abstracting IP end-devices and applications within the RAQMON architecture. It gathers the parameters for a particular communication session and forwards them to the appropriate RAQMON Report Collector (RRC). Since it is envisioned that the RDS functionality will be realized by writing firmware/software running on potentially small, low-powered end-devices, the design of the RDS element is optimized towards that end. Like the implementations of routing and management protocols, an implementation of RDS in an end-device will typically execute in the background, not in the data-forwarding path.
RDSはRAQMONアーキテクチャ内のIPエンドデバイスとアプリケーションを抽象化の主な原因です。これは、特定の通信セッションのパラメータを収集し、適切なRAQMONレポートコレクター（RRC）に転送します。それはRDS機能が潜在的に小型、低電力エンドデバイス上で動作するファームウェア/ソフトウェアを書き込むことによって実現されることが想定されているので、RDS要素の設計は、その終わりに向かって最適化されています。ルーティング及び管理プロトコルの実装のように、エンドデバイスにおけるRDSの実装では、典型的には、データ転送経路に、バックグラウンドで実行されます。
RDSs use a PUSH mechanism to report QoS parameters. While the applications running on the RDS decide about the content of the PDU appropriate for an application context, an RDS asynchronously sends out reports to RRC.
RDSには、QoSパラメータを報告するPUSHメカニズムを使用します。アプリケーションは、RDSアプリケーションコンテキストのためのPDUの適切な内容について決める上で実行されているものの、RDSは、非同期RRCにレポートを送信します。
The rate at which PDUs are sent from RDSs to RRCs is controlled by the applications' administrative domain policy. While this mechanism provides flexibility to gather a detailed end-to-end experience required by IT managers and system administrators, certain steps should be followed to operate RAQMON in congestion-safe manner. Section 3 addresses steps required for congestion-safe operation.
PDUはRRCsへのRDSから送信される速度は、アプリケーションの管理ドメインポリシーによって制御されています。この機構は、IT管理者やシステム管理者によって必要とされる詳細なエンドツーエンドの経験を収集するための柔軟性を提供するが、特定のステップは、輻輳安全な方法でRAQMONを動作させるために従うべきです。混雑安全な動作に必要な第3のアドレスステップ。
An RDS reports QoS statistics for simplex flows. At a given instance, a report from RDS is logically viewed as a collection of QoS parameters associated with a communication session as perceived by the reporting RDS. For example, if two IP phone users, Alice and John, are involved in a communication session, the end-to-end delay experienced by the IP phone user Alice could be different from the one experienced by the IP phone user John for a variety of reasons. Hence, a report from Alice's IP phone represents the QoS performance of that call as perceived by the RDS that resides in Alice's IP phone.
RDSは単純フローのQoS統計情報を報告します。特定のインスタンスでは、RDSからのレポートは、論理的に報告RDSによって知覚される通信セッションに関連付けられたQoSパラメータの集合と見られています。 2人のIP電話ユーザ、アリス及びジョンは、通信セッションに関与している場合、例えば、IP電話ユーザが経験するエンドツーエンド遅延は、アリスは、様々なIP電話ユーザーJohnが経験するものとは異なる可能性が理由の。 AliceのIP電話に存在するRDSによって知覚されるため、アリスのIP電話からの報告書は、そのコールのQoSの性能を表しています。
1. RAQMON Data Sources SHALL gather reports from multiple
applications residing in that device and SHALL send out
compound QoS reports associated with multiple communication
sessions at a given moment.
Examples include a conference bridge hosting several different conference calls or a two-party video call consisting of audio/video sessions. In each case an RDS could send out one single RAQMON report that consists of multiple sub-reports associated with audio and video sessions or sub-reports for each conference call.
例としては、いくつかの異なる会議通話やオーディオ/ビデオセッションからなる二パーティのビデオ通話をホストしている会議ブリッジが含まれています。それぞれのケースでRDSは、オーディオとビデオセッションまたは各電話会議のためのサブレポートに関連付けられた複数のサブレポートで構成されて1つのRAQMONレポートを送信することができます。
2. RAQMON Data Sources MUST implement the TCP transport and MAY implement the SNMP transport.
2. RAQMONデータソースは、TCPトランスポートを実装しなければならないし、SNMPの輸送を実施することができます。
In order to report statistics to RAQMON Report Collectors, RDSs will need to be configured with the following parameters:
RAQMONレポートコレクターに統計を報告するためには、RDSには、以下のパラメータを設定する必要があります。
1. The time interval between RAQMON PDUs. This parameter MUST be configured such that overflow of any RAQMON parameter within a PDU between consecutive transmissions is avoided.
RAQMON PDUの間の1時間間隔。このパラメータは、連続する送信間のPDU内の任意のRAQMONパラメータのオーバーフローが回避されるように構成されなければなりません。
An RDS may use manual configuration for the RDS configuration parameters using command line interface (CLI), Telephone User Interface (TUI), etc.
RDSは、コマンドラインインターフェイス（CLI）、電話ユーザーインターフェイス（TUI）、等を使用して、RDS設定パラメータの手動設定を使用することができます
One of the following mechanisms to gain access to configuration parameters can also be considered:
設定パラメータへのアクセスを得るために、以下の機構の1つは考えることもできます。
- RDS acts as a trivial file transfer protocol (TFTP) client and downloads text scripts to read the parameters. - RDS acts as a Dynamic Host Configuration Protocol (DHCP) Client and gets RRC addressing information as a DHCP option. - RDS acts as a DNS client and gets target collector information from a DNS Server. - RDS acts as a LDAP Client and uses directory look-ups.
- RDSパラメータを読み取るために些細なファイル転送プロトコル（TFTP）クライアントとダウンロードテキストスクリプトとして機能します。 - RDS動的ホスト構成プロトコル（DHCP）クライアントとして機能し、DHCPオプションとしてRRCアドレス情報を取得します。 - RDS DNSクライアントとして動作し、DNSサーバーからターゲット・コレクタ情報を取得します。 - RDS LDAPクライアントとして動作し、ディレクトリルックアップを使用しています。
Identifying the DHCP option and structure to use, defining the structure of the configuration information in DNS, or defining a LDAP schema could be explored as items of future work.
、使用するDHCPオプションと構造を特定するDNS構成情報の構造を定義する、またはLDAPスキーマを定義することは、将来の仕事の項目として探求することができます。
Compliance to the RAQMON specification does not require usage of any specific configuration mechanisms mentioned above. It is left to the implementers to choose appropriate provisioning mechanisms for a system.
RAQMON仕様への準拠は、上述の任意の具体的な構成メカニズムの使用を必要としません。システムのための適切なプロビジョニングメカニズムを選択する実装に任されています。
A RAQMON Report Collector (RRC) receives RAQMON PDUs from multiple RDSs and analyzes and stores the information in the RAQMON MIB. The RRC is envisioned to be computationally resourceful, providing a storage and aggregation point for a set of RDSs.
RAQMON報告コレクタ（RRC）は、複数のRDSからRAQMON PDUを受信し、RAQMON MIB内の情報を解析し、格納します。 RRCは、のRDSのセットのストレージおよび集約ポイントを提供する、計算機知であると想定されます。
Since RDSs can belong to separate administrative domains, the RAQMON Framework allows RDSs to report QoS parameters to separate RRCs. Vendors can develop a management application to correlate information residing in different RRCs across multiple administrative domains to represent one communication session. However, such an application-level specification is beyond the scope of this memo.
RDSには、管理ドメインを分離するために属することができるので、RAQMON Frameworkは、RDSにはRRCsを分離するためにQoSパラメータを報告することができます。ベンダーは、一つの通信セッションを表すために複数の管理ドメイン間で異なるRRCsに存在する情報を相関させる管理アプリケーションを開発することができます。しかしながら、そのようなアプリケーションレベルの仕様は、このメモの範囲を超えています。
1. RAQMON Report Collectors MUST support the mandatory mapping
over TCP of the RAQMON information model defined in [RFC4712]
with the purpose of receiving RAQMON reports from RAQMON Data
Sources (RDS).
2. RAQMON Report Collectors MAY support the optional mapping over SNMP notifications of the RAQMON information model defined in [RFC4712].
2. RAQMONレポートコレクターは、[RFC4712]で定義されたRAQMON情報モデルのSNMP通知の上にオプションのマッピングをサポートするかもしれません。
3. RAQMON Report Collectors MUST implement session timeout mechanisms to assume end of reporting for RDSs that have been out of reporting for a reasonable duration of time. Such timeout parameters SHOULD be configurable in vendor implementations, as programmable parameters at deployment.
3. RAQMONレポートコレクターは時間の合理的な期間の報告のうち、されているRDSに報告のための終わりを想定するセッションタイムアウトメカニズムを実装しなければなりません。そのようなタイムアウトパラメータは、展開でプログラム可能なパラメータとして、ベンダの実装で構成可能であるべきです。
4. RAQMON Report Collectors MUST support the RAQMON-MIB module and meet the compliance requirements of the raqmonCompliance MODULE-COMPLIANCE definition as described in [RFC4711]. The population of the RAQMON MIB with performance monitoring information is independent of the transport protocol, or protocols used to carry the information between RDSs and RRCs.
4. RAQMONレポートコレクターはRAQMON-MIBモジュールをサポートして、[RFC4711]で説明したようにraqmonCompliance MODULEコンプライアンス定義のコンプライアンス要件を満たす必要があります。性能監視情報とRAQMON MIBの集団のRDSとRRCsの間で情報を運ぶために使用されるトランスポートプロトコル、またはプロトコルとは無関係です。
RAQMON defines a set of basic metrics that characterize the QoS of applications, as reported by RAQMON Data Sources. This basic set of metrics is defined in Section 5 of this memo. There is no minimal requirement for a mandatory set of metrics to be supported by an RDS.
RAQMONはRAQMONデータソースによって報告されるように、アプリケーションのQoSを特徴づける基本的なメトリックのセットを定義します。このメトリック・基本セットは、このメモのセクション5で定義されています。 RDSによってサポートされるメトリックの必須セットのための最小限の要件はありません。
Specific applications, new types of network appliances or new methods to measure and characterize the QoS of applications lead to the requirement for the information model to be extensible. To answer this need, the information model is designed so that vendors can extend it by adding new metrics.
アプリケーションのQoSを測定し、特徴付けるための具体的な用途として、ネットワーク機器や新しいメソッドの新しいタイプは、拡張可能であることを情報モデルの必要性につながります。ベンダーが新しいメトリックを追加することによって、それを拡張できるように、このニーズに答えるために、情報モデルが設計されています。
Although NOT REQUIRED for RAQMON conformance, extensions of the information model can offer useful information for specific applications. An example of metrics that can extend the basic RAQMON information model are the detailed metrics for VoIP media monitoring and call quality included in the VoIP Metrics Report Block defined in [RFC3611].
RAQMON適合のために必須ではありませんが、情報モデルの拡張は、特定の用途に有用な情報を提供することができます。基本RAQMON情報モデルを拡張することができる指標の例は、[RFC3611]で定義されたVoIPメトリックレポートブロックに含まれるVoIPメディア監視及び通話品質のための詳細な指標です。
The RAQMON Information model is expressed by defining a conceptual RAQMON Protocol Data Unit (PDU).
RAQMON情報モデルは、概念RAQMONプロトコルデータユニット（PDU）を定義することによって表現されます。
A RAQMON Protocol Data Unit (PDU) is a common data format understood by RDSs and RRCs. A RAQMON PDU does not transport application data but rather occupies the place of a payload specification at the application layer of the protocol stack. Different transport mappings may be used to carry RAQMON PDU between RDSs and RRCs. Transport protocol requirements are being defined in Section 2.4 of this memo.
RAQMONプロトコルデータユニット（PDU）は、のRDSとRRCsによって理解される共通のデータフォーマットです。 RAQMON PDUは、アプリケーションデータを転送ではなく、プロトコル・スタックのアプリケーション層でペイロード仕様の位置を占めていません。異なるトランスポートマッピングがRDSにとRRCs間RAQMON PDUを運ぶために使用することができます。トランスポートプロトコル要件は、このメモのセクション2.4で定義されています。
Though architected conceptually as a single PDU, the RAQMON PDU is functionally divided into two different parts. They are the BASIC part, and the Application-Specific Extensions, required for application-, vendor-, and device-specific extensions.
単一のPDUとして概念的アーキテクチャも、RAQMON PDUは、機能的に2つの異なる部分に分割されます。彼らは用途向け、ベンダー、およびデバイス固有の拡張のために必要な基本的な部分、およびアプリケーション固有の拡張、です。
The BASIC part of the RAQMON PDU: The BASIC part of the RAQMON PDU follows the SMI Network Management Private Enterprise Code 0, indicating an IETF standard construct. The RAQMON PDU BASIC part offers an entry-type from a pre-defined list of QoS parameters defined in Section 5 and allows applications to fill in appropriate values for those parameters. Application developers also have the flexibility to make an RDS report built only of a subset of the parameters listed in
RAQMON PDUのBASIC一部：RAQMON PDUのBASIC一部は、IETF標準の構造を示す、SMIネットワーク管理プライベートエンタープライズコード0をたどります。 RAQMON PDU BASIC部はセクション5で定義されたQoSパラメータの事前定義されたリストからエントリタイプを提供し、アプリケーションは、これらのパラメータの適切な値を入力することを可能にします。アプリケーション開発者はまた、唯一に記載されているパラメータのサブセットで建てRDSレポートを作成するための柔軟性を持っています
Section 5. There is no need to carry all metrics in every PDU; moreover, it is RECOMMENDED that static or pseudo-static metrics that do not change or seldom change for a given session or application will be send only when the session or application are initiated, and then at large time intervals.
第5節すべてのPDU内のすべてのメトリックを持ち歩く必要はありません。しかも、変わらないか、めったに与えられたセッションまたはアプリケーションに変更されない静的または擬似静的メトリクスは大きな時間間隔で、セッションまたはアプリケーションが開始されたときにのみ送信し、されることが推奨されます。
The Application part of RAQMON PDU: Since it is difficult to structure a BASIC part that meets the needs of all applications, RAQMON provides extension capabilities to convey application-, vendor-, and device-specific parameters for future use. Additional parameters can be defined within payload of the APP part of the PDU by the application developers or vendors. The owner of the definition of the application part of the RAQMON PDU is indicated by a vendor's SMI Network Management Private Enterprise Code defined in http://www.iana.org/assignments/enterprise-numbers. Such application-specific extensions should be maintained and published by the application vendor.
RAQMON PDUのアプリケーション部分は：それはすべてのアプリケーションのニーズを満たす基本的な部分を構成することは困難であるため、RAQMONは用途向け、ベンダ、および将来の使用のための装置固有のパラメータを伝達するために拡張機能を提供します。追加のパラメータは、アプリケーション開発者またはベンダーによってPDUのAPPの一部のペイロード内で定義することができます。 RAQMON PDUのアプリケーション部分の定義の所有者がhttp://www.iana.org/assignments/enterprise-numbersで定義されたベンダーのSMIネットワーク管理プライベートエンタープライズコードで示されています。このようなアプリケーション固有の拡張機能を維持し、アプリケーションベンダーによって公開されなければなりません。
Though RDSs and RRCs are designed to be stateless for an entire reporting session, the framework requires an indication for the end of the reporting. For this purpose, an RDS MUST send a RAQMON NULL PDU. A NULL PDU is a RAQMON PDU containing ALL NULL values (i.e., nothing to report).
RDSにとRRCs全体報告セッションのステートレスになるように設計されているが、フレームワークは、報告の終わりのための表示を必要とします。この目的のために、RDSはRAQMON NULL PDUを送らなければなりません。 NULL PDUはすべてのNULL値（即ち、何も報告しないように）を含むRAQMON PDUです。
The RAQMON PDUs rely on the underlying protocol(s) to provide transport functionalities and other attributes of a transport protocol, e.g., transport reliability, re-transmission, error correction, length indication, congestion safety, fragmentation/defragmentation, etc. The maximum length of the RAQMON data packet is limited only by the underlying protocols.
RAQMON PDUは、トランスポート機能とトランスポートプロトコル、例えば、搬送の信頼性、再送信、誤り訂正、等長指示、輻輳安全性、フラグメンテーション/デフラグ、最大長さの他の属性を提供するために、基本的なプロトコル（単数または複数）に依存していますRAQMONデータパケットの基本的なプロトコルによってのみ制限されます。
The following requirements MUST be met by the transport protocols:
次の要件は、トランスポートプロトコルによって満たされる必要があります。
1. The transport protocol SHOULD allow for RDS lightweight implementations. RDSs will be implemented on low-powered embedded devices with limited device resources.
1.トランスポートプロトコルは、RDS軽量な実装を可能にしなければなりません。 RDSには、限定されたデバイスのリソースを持つ低電力組み込み機器に実装されます。
2. Scalability - Since RRCs need to interact with a very large number (many tens, many hundreds, or more) of RDSs, scalability of the transport protocol is REQUIRED.
2.スケーラビリティ - RRCsはのRDSの非常に多数（数十、数百、またはそれ以上）と相互作用する必要があるため、トランスポートプロトコルのスケーラビリティが必要です。
4. Security - Since RAQMON statistics may carry sensitive system information requiring protection from unauthorized disclosure and modification in transit, a transport protocol that provides strong secure modes or allows for data encryption and integrity to be applied is REQUIRED.
4.セキュリティ - RAQMON統計が運ぶことができるので、輸送中に、不正な開示および改変から保護を必要とする重要なシステム情報、強いセキュアなモードを提供するか、適用されるデータの暗号化および整合性を可能にするトランスポート・プロトコルが必要です。
5. NAT-Friendly - The transport protocol SHOULD comply with [RFC3235], so that an RDS could communicate with an RRC through a Firewall/Network Address Translation device.
5. NAT-フレンドリー - RDSファイアウォール/ネットワークアドレス変換装置を介してRRCと通信できるように、トランスポートプロトコルは、[RFC3235]に準拠します。
6. The transport protocol MAY implement session timeout mechanisms to assume end of reporting for RDSs that have been out of reporting for a reasonable duration of time. Such timeout parameters SHOULD be configurable in vendor implementations, programmable at deployment.
6.トランスポートプロトコルは、時間の合理的な期間のレポートの外にされていることをRDSに報告のための終わりを想定するセッションタイムアウトメカニズムを実装してもよいです。このようなタイムアウトパラメータは、ベンダー実装、展開でプログラマブルに設定可能であるべきです。
7. Reliability - The RAQMON Framework expects PDUs to operate in lossy networks. However, retransmission is not included in the RAQMON framework, in order to keep the design simple. If retransmission is a necessity, RAQMON MAY operate over transport protocols, such as TCP.
7.信頼性 - RAQMON Frameworkは、PDUが損失の多いネットワークで動作するように期待しています。しかし、再送がデザインをシンプルに保つために、RAQMONフレームワークに含まれていません。再送が必要である場合は、RAQMONは、TCPのようなトランスポートプロトコル上で動作することができます。
In the future, if RAQMON PDUs are to be carried in an underlying protocol that provides the abstraction of a continuous octet stream rather than messages (packets), an encapsulation for the RAQMON packets must be defined to provide a framing mechanism. Framing is also needed if the underlying protocol contains padding so that the extent of the RAQMON payload cannot be determined. No framing mechanism is defined in this document. Carrying several RAQMON packets in one network or transport packet reduces header overhead.
RAQMON PDUは連続オクテットストリームではなく、メッセージ（パケット）の抽象化を提供しているプロトコルで実施される場合、将来的に、RAQMONパケットのカプセル化は、フレーミング機構を提供するために定義されなければなりません。 RAQMONペイロードの程度を決定することができないように、基礎となるプロトコルはパディングが含まれている場合、フレーミングも必要とされています。いいえフレーミング機構は、この文書で定義されていません。一つのネットワーク又はトランスポートパケット内にいくつかのRAQMONパケットを搬送するヘッダのオーバーヘッドを低減します。
Further memos like [RFC4712] describe how the PDU is transported over existing protocols like the Transmission Control Protocol (TCP) or the Simple Network Management Protocol (SNMP).
[RFC4712]のようなさらなるメモは、PDUが伝送制御プロトコル（TCP）または簡易ネットワーク管理プロトコル（SNMP）のような既存のプロトコルを介して伝送される方法について説明します。
RAQMON PDUs can be transmitted over multiple transport protocols. The RAQMON Framework will be congestion safe, if a RAQMON PDU is transported over TCP.
RAQMON PDUは、複数のトランスポートプロトコルを介して送信することができます。 RAQMON PDUはTCP上で転送されている場合RAQMON Frameworkは、混雑安全になります。
One solution to the congestion awareness problem could have been to discourage the use of UDP entirely for RAQMON. Though RAQMON PDUs can be transported over TCP, some transports like SNMP over TCP are not commonly practiced in practical deployments.
混雑意識の問題に対する1つの解決策は完全にRAQMONのためのUDPの使用を阻止するためだったかもしれません。 RAQMON PDUはTCP上で転送することができますが、TCP上のSNMPのようないくつかのトランスポートは、一般的に実用的な展開で実践されていません。
The use of UDP inherently increases the risks of network congestion problems, as UDP itself does not define congestion prevention, avoidance, detection, or correction mechanisms. The fundamental problem with UDP is that it provides no feedback mechanism to allow a sender to pace its transmissions against the real performance of the network. While this tends to have no significant effect on extremely low-volume sender-receiver pairs, the impact of high-volume relationships on the network can be severe. This problem could be further aggravated by large RAQMON PDUs fragmented at the UDP level. Transport protocols such as DCCP can also be used as underlying RAQMON PDU transport, which provides flexibility of UDP style datagram transmission with congestion control.
UDP自体が輻輳防止、回避、検出、または訂正メカニズムを定義していないとしてUDPを使用することは、本質的に、ネットワークの輻輳問題のリスクを増大させます。 UDPの基本的な問題は、それが何のフィードバック機構は、送信者がネットワークの実際のパフォーマンスに対してその送信をペーシングすることができないために提供することです。これは非常に低体積の送信者 - 受信機ペアに有意な影響を及ぼさない傾向にあるが、ネットワーク上の大量の関係の影響は深刻であることができます。この問題は、さらにUDPレベルで断片化された大規模なRAQMON PDUのにより悪化することができます。例えばDCCPなどのトランスポートプロトコルはまた、輻輳制御とUDPスタイルデータグラムの送信の柔軟性を提供する基盤となるRAQMON PDUをトランスポートとして使用することができます。
It should be noted that the congestion problem is not just between RDS and RRC pairs, but whenever there is a high fan-in ratio, congestion could occur (e.g., many RDSs reporting to an RRC). Within the RAQMON Framework using UDP as a transport, congestion safety can be achieved in following ways:
輻輳の問題がちょうどRDSとRRCペア間ではなく、高ファンイン比があるときはいつでも、輻輳が（RRCに報告例えば、多くのRDS）が起こり得ることに留意すべきです。トランスポートとしてUDPを使用してRAQMON枠組みの中で、渋滞の安全性は、次の方法で達成することができます。
1. Constant Transmission Rate: In a well-managed network, a constant transmission rate policy (e.g., 1 RAQMON PDU per device every N seconds) will ensure congestion safety as devices are introduced into the network in a controlled manner. For example, in an enterprise network, IP Phones are added in a controlled manner, and a constant transmission rate policy can be sufficient to ensure congestion-safe operation. The configured rate needs to be related to the expected peak number of devices. As a worst-case scenario, if the RDSs enforce an administrative policy where the maximum PDU transmission rate is no more than one RAQMON PDU every two minutes, a UDP-based implementation can be as congestion safe as a TCP-based implementation. Such policies can be enforced while configuring RDSs, and the timers for the constant rate need to be randomly jittered.
1.伝送速度一定：デバイスは、制御された方法でネットワークに導入されるとしてよく管理されたネットワークでは、伝送速度一定のポリシー（例えば、デバイスあたり1つのRAQMONのPDUごとにN秒）が、輻輳の安全を確保します。例えば、企業ネットワークでは、IP電話は、制御された様式で添加され、一定の伝送レートポリシーは、輻輳安全な動作を保証するのに十分であることができます。設定されたレートは、デバイスの予想されるピーク数に関連する必要があります。 RDSは、最大PDUの伝送速度が誰RAQMON PDUより2分ごとで管理ポリシーを施行する場合に最悪のシナリオとして、UDPベースの実装は、TCPベースの実装などの安全な混雑のようであってもよいです。 RDSに設定中にこのような政策は、強制することができ、かつ一定速度のタイマーは、ランダムジッタにする必要があります。
2. Single outstanding requests: This approach requires that a request be sent at the application level, then there is a wait for some sort of response indicating that the request was received before sending anything else. This produces an effect described by some as "ping-ponging": traffic bounces back and forth between two nodes like a ping-pong ball in a match. Since there's only one ball in play between any two players at any given time, most of the potential for congestion cascades is eliminated. For reliability and efficiency reasons, this technique must include backed-off retransmissions. For example, if RAQMON PDUs are transported using SNMP INFORM PDUs over UDP, a SNMP response from the RRC SHOULD be processed by the RDS to implement this mechanism. [RFC4712] specifies that
2.シングル未処理の要求：このアプローチは、要求がアプリケーションレベルで送信されることを要求し、要求は何かを送信する前に受信されたことを示す応答のいくつかの並べ替えのための待ち時間があります。トラフィックが前後に試合でピンポン玉のような2つのノード間のバウンス：これは、「ピンポン」としていくつかによって記述効果を発揮します。任意の時点で任意の2人の選手との間の遊びの唯一の1つのボールがありますので、混雑カスケードのための可能性の大部分が除去されます。信頼性と効率性の理由から、この技術は、バックオフの再送信が含まれている必要があります。 RAQMON PDUはSNMPはUDP上のPDUに知らせる使用して転送される場合、例えば、RRCからのSNMP応答が、このメカニズムを実装するためにRDSによって処理されるべきです。 [RFC4712]はことを指定します
if the SNMP notifications transport mapping mechanism is implemented, it is RECOMMENDED to use INFORM PDUs, and it is NOT RECOMMENDED to use Trap PDUs.
SNMP通知の輸送マッピング機構が実装されている場合、PDUをINFORM使用することが推奨され、トラップPDUを使用することが推奨されていません。
This pacing or serialization approach has the side-effect of significantly reducing the maximum throughput, as transmission occurs in only one direction at a time and there is at least a 2xRTT (round-trip time) delay between transmissions. More sophisticated algorithms (such as those in TCP and Stream Control Transmission Protocol (SCTP)) have been developed to address this, and it would be inappropriate to duplicate that work at the application level. Consequently, if greater efficiency is required than that provided by this simple approach, implementers SHOULD use TCP, SCTP, or another such protocol. But if one absolutely must use UDP, this approach works. It has been also used in other application scenarios like SIP over UDP.
送信は一度に一方向のみに発生し、送信の間に少なくとも2xRTT（ラウンドトリップ時間）遅延があるように、このペーシングまたはシリアル化アプローチは、有意に最大スループットを低下させる副作用を有します。 （TCPやストリーム制御伝送プロトコル（SCTP）のもののような）より洗練されたアルゴリズムは、この問題に対処するために開発されており、アプリケーションレベルでその作業を複製することは不適切だろう。より高い効率は、この単純なアプローチによって提供されるものよりも、必要とされる場合、結果として、実装者はTCP、SCTP、又は他のそのようなプロトコルを使用すべきです。 1は絶対にUDPを使用する必要がある場合でも、このアプローチは動作します。これは、UDP上のSIPなどの他のアプリケーションシナリオでも使用されています。
3. By restricting transmission to a maximum transmission unit (MTU) size: An RDS may be faced with a request to deliver a large message using UDP as a transport. Fragmentation of such messages is problematic in several ways. Loss of any fragment requires time-out and retransmission of the message. The fragments are commonly transmitted out of the interface at local interface (usually LAN) rates, without awareness of the intervening network conditions. For these reasons, it is generally considered a bad practice to send large PDUs over UDP. If the MTU size is known, as an implementation, an RDS should not allow an application to send more information by limiting the size of transmissions over UDP to reduce the effects of fragmentation. As an alternate, an RDS MAY also send parameters to RRC over multiple RAQMON PDUs but identify them as part of the same RAQMON reporting session with exactly the same Network Time Protocol (NTP) [RFC1305] time stamp.
3.最大伝送単位（MTU）サイズへの送信を制限することにより：RDSは、トランスポートとしてUDPを使用して大きなメッセージを配信するための要求に直面してもよいです。このようなメッセージの断片化は、いくつかの点で問題があります。任意のフラグメントの損失は、メッセージのタイムアウトおよび再送信が必要です。断片は、一般的に介在するネットワーク環境を意識することなく、ローカルインタフェース（通常はLAN）の速度でインターフェイスから送信されています。これらの理由から、一般的にUDP経由で大きなPDUを送信するために悪い習慣を考えられています。 MTUサイズがわかっている場合は、実装として、RDSは、アプリケーションが断片化の影響を低減するためにUDPを介した伝送のサイズを制限することにより、より多くの情報を送信できるようにするべきではありません。代替として、RDSは、複数のRAQMON PDUの上でRRCにパラメータを送信することができますが、まったく同じネットワーク・タイム・プロトコル（NTP）[RFC1305]タイムスタンプと同じRAQMON報告セッションの一部としてそれらを識別します。
While the actual MTU of a link may not be known, common practice seems to indicate that the RDS local interface MTU is likely to be a reasonable "approximation". Where the actual path MTU is known, that value SHOULD be used instead.
リンクの実際のMTUが知られていないかもしれないが、一般的な方法は、RDSローカルインターフェイスMTUは、合理的な「近似」である可能性が高いことを示していると思われます。ここで、実際の経路MTUは、値が代わりに使用されるべきであること、が知られています。
4. Irrespective of choice of transport protocol, it is also RECOMMENDED that no more than 10% network bandwidth be used for RDS/RRC reporting. More frequent reports from an RDS to RRC would imply requirements for higher network bandwidth usage.
4.かかわらず、トランスポートプロトコルの選択の、また、10％以下のネットワーク帯域幅がRDS / RRC報告に使用しないことをお勧めします。 RDSからのRRCに、より頻繁レポートは、高いネットワーク帯域幅の使用量の要件を暗示します。
It is not the intent of this document to recommend a methodology to measure any of the QoS parameters defined in Section 5. Measurement algorithms are left to the implementers and equipment vendors to choose. There are many different measurement methodologies available for measuring application performance. These include probe-based, client-based, synthetic-transaction, and other approaches. This specification does not mandate a particular methodology and is open to any methodology that meets the minimum requirements. For conformance to this specification, it is REQUIRED that the collected data match the semantics described herein. However, it is RECOMMENDED that vendors use IETF-defined and International Telecommunication Union (ITU)-specified methodologies to measure parameters when possible.
5.測定アルゴリズムを選択するように実装し、機器ベンダーに委ねられているセクションで定義されたQoSパラメータのいずれかを測定するための方法論をお勧めするには、このドキュメントの意図ではありません。アプリケーションのパフォーマンスを測定するために利用可能な多くの異なる測定方法があります。これらは、プローブベースの、クライアントベース、合成トランザクション、および他のアプローチが含まれます。この仕様は、特定の方法論を強制し、最小要件を満たしている任意の方法論に開放されていません。この仕様に準拠するためには、収集されたデータは、本明細書に記載の意味論と一致することが要求されます。しかし、ベンダーが可能な場合のパラメータを測定するために、IETF定義および国際電気通信連合（ITU）-specified方法論を使用することをお勧めします。
The BASIC part of the RAQMON PDU provides for a list of pre-defined parameters frequently used by applications to characterize end-to-end application Quality of Service. This section defines a set of simple metrics to be contained in the BASIC part of the RAQMON PDU, through reference to existing IETF, ITU, and other standards organizations' documents. Appropriate IETF or ITU references are included in the metrics definitions.
RAQMON PDUの基本的な部分は、しばしば、サービスのエンドツーエンドアプリケーションの品質を特徴付けるためにアプリケーションによって使用される事前定義されたパラメータのリストを提供します。このセクションでは、既存のIETF、ITU、及び他の標準化団体のドキュメントを参照しながら、RAQMON PDUのBASIC一部に含まれる簡単なメトリックのセットを定義します。適切なIETFやITUの参照は、メトリクスの定義に含まれています。
As mentioned earlier, the RAQMON PDU also contains an application-specific part, where application- and vendor-specific information not included in BASIC part can be added as <Name, Value> pairs, or as a variable binding list. These extensions, managed independently by vendors or other organizations, should be published for wider interoperability.
前述したように、RAQMON PDUは、基本的な部分に含まれていない用途向けおよびベンダー固有の情報は<名前、値>ペアとして、または変数バインディングリストとして添加することができるアプリケーション固有の部分を含んでいます。ベンダーや他の組織が独立して管理するこれらの拡張機能は、より広い相互運用性のために公開する必要があります。
Applications are not required to report all the parameters mentioned in this section, but should have the flexibility to report a subset of these parameters appropriate to an application context. The memo further identifies the parameters that RDSs are required to include in all PDUs for compliance, as well as optional parameters that RDSs may report as needed. The definitions presented here are meant to provide guidance to implementers, and IETF metric definition references are provided for each metric. Application developers should choose the metrics appropriate to their applications' needs. Syntactical representations of the parameters identified here are provided in the [RFC4712] specification.
アプリケーションは、このセクションで説明したすべてのパラメータを報告する必要はありませんが、アプリケーションコンテキストに適切なこれらのパラメータのサブセットを報告する柔軟性を持っている必要があります。メモは、さらにRDSには、コンプライアンスのためのすべてのPDUに含める必要なパラメータだけでなく、必要に応じてRDSには報告することがあり、オプションのパラメータを識別します。ここに提示された定義は実装者へのガイダンスを提供することを意図しており、IETFメトリック定義の参照は、各メトリックのために提供されます。アプリケーション開発者は、アプリケーションのニーズに適切なメトリックを選択する必要があります。ここで同定されたパラメータの構文表現は、[RFC4712]明細書で提供されます。
The Data Source Address (DA) is the address of the data source. This could be either a globally unique IPv4 or IPv6 address, or a privately IPv4 allocated address as defined in [RFC1918].
データソースアドレス（DA）は、データ・ソースのアドレスです。これは、グローバルにユニークなIPv4またはIPv6アドレス、または[RFC1918]で定義されるように個人のIPv4割り当てアドレスのいずれかとすることができます。
It is expected that the DA would remain constant within a given communication session. RDSs SHOULD avoid sending these parameters within RAQMON reports too often to ensure an efficient usage of network resources.
DAが与えられた通信セッション内で一定にとどまることが期待されます。 RDSにはRAQMONは、ネットワークリソースの効率的な使用を確保するために、あまりにも頻繁に報告の中に、これらのパラメータを送信することは避けてください。
The Receiver Address (RA) takes the same form as the Data Source Address (DA) but represents the Receiver's Address. In a communication session, the reporting RDSs SHOULD fill in the other party's address as a Receiver Address. Like the Data Source Address, this could be either a globally unique IPv4 or IPv6 address, or a privately allocated IPv4 address as defined in [RFC1918].
レシーバアドレス（RA）は、データ送信元アドレス（DA）と同じ形をとるが、Receiverのアドレスを表します。通信セッションでは、報告RDSには、レシーバアドレスなど相手のアドレスを記入すべきです。 [RFC1918]で定義されているデータソースのアドレスと同じように、これはグローバルにユニークなIPv4またはIPv6アドレス、または個人に割り当てられたIPv4アドレスのどちらかである可能性があります。
It is expected that the Receiver Address (RA) would remain constant within a given communication session. RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
レシーバアドレス（RA）が与えられた通信セッション内で一定にとどまることが期待されます。 RDSには、ネットワークリソースの効率的な使用を確保するためには、あまりにも頻繁にRAQMONレポート内のこれらのパラメータを送信することは避けてください。
The Data Source Name (DN) item could be of various formats as needed by the application. Forms the DN could take include, but are not restricted to:
アプリケーションによって必要に応じて、データソース名（DN）アイテムは、様々な形式のものであってもよいです。 DNには、取ることができるが、これらに限定されないフォーム：
- "user@host", or "host" if a user name is not available as on single-user systems. For both of these formats, "host" is the fully qualified domain name of the host from which the payload originates, formatted according to the rules specified in [RFC1034], [RFC1035], and Section 2.1 of [RFC1123]. Use example names are "big-guy@example.com" or "big-guy@192.0.2.178" for a multi-user system. On a system with no user name, an example would be "ip-phone4630.example.com". It is RECOMMENDED that the standard host's numeric address not be reported via the DN parameter, as the DA parameter is used for that purpose.
- 「ユーザー@ホスト」、または「ホスト」のユーザー名は、シングルユーザーシステム上として利用できない場合。これらの形式の両方について、「ホスト」とは、[RFC1034]、[RFC1035]及び[RFC1123]のセクション2.1で指定された規則に従ってフォーマット、ペイロードの発信元のホストの完全修飾ドメイン名です。例の名前を使用してマルチユーザシステムのための「big-guy@example.com」または「big-guy@192.0.2.178」です。いいえユーザー名を持つシステムでは、例としては、「ip-phone4630.example.com」になります。 DAパラメータは、その目的のために使用される標準のホストの数値アドレスは、DNパラメータを経由して報告しないことをお勧めします。
- Another instance of a DN could be a valid E.164 phone number, a SIP URI, or any other form of telephone or pager number. The phone number SHOULD be formatted with a plus sign replacing the international access code. Example: "+44-116-496-0348" for a number in the UK.
- DNの別のインスタンスは、有効なE.164電話番号、SIP URIまたは電話またはポケットベル番号の任意の他の形態であってもよいです。電話番号は、国際アクセスコードを置き換えるプラス記号でフォーマットする必要があります。例：英国の数のための「+ 44-116-496-0348」。
The DN value is expected to remain constant for the duration of a session. RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
DN値はセッションの間一定のままであることが期待されます。 RDSには、ネットワークリソースの効率的な使用を確保するためには、あまりにも頻繁にRAQMONレポート内のこれらのパラメータを送信することは避けてください。
The Receiver Name (RN) takes the same form as DN, but represents the Receiver's name. In a communication session, an application SHOULD supply as an RN the name of the other party with which it is communicating.
レシーバー名（RN）は、DNと同じ形式を取りますが、Receiverの名前を表します。通信セッションでは、アプリケーションはRNとして、それが通信している相手の名前を提供する必要があります。
The RN value is expected to remain constant for the duration of a session. RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
RN値は、セッションの間に一定のままと予想されます。 RDSには、ネットワークリソースの効率的な使用を確保するためには、あまりにも頻繁にRAQMONレポート内のこれらのパラメータを送信することは避けてください。
This parameter indicates the source port used by the application for a particular session or sub-session in communication. Examples of ports include TCP Ports or UDP Ports, as used by communication application protocols such as Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), H.323, RTP, HyperText Transport Protocol (HTTP), and so on.
このパラメータには、通信中に特定のセッションまたはサブセッションのためにアプリケーションによって使用される送信元ポートを示しています。ポートの例は、TCPポートまたはUDPポートを含む、このようなセッション開始プロトコル（SIP）などの通信アプリケーションプロトコルによって使用されるように、インスタントメッセージングとプレゼンスを活用エクステンション（SIMPLE）用のSIP、H.323、RTP、ハイパーテキスト転送プロトコル（HTTP）、等々。
This parameter MUST be sent in the first RAQMON PDU.
このパラメータは、最初のRAQMON PDUに送らなければなりません。
This parameter indicates the receiver port used by the application for a particular session or sub-session. Examples of ports include TCP Ports, or UDP Ports used by communication application protocols such as SIP, SIMPLE, H.323, RTP, HTTP, etc.
このパラメータは、特定のセッションまたはサブセッションのアプリケーションによって使用される受信ポートを示します。ポートの例は、TCPポート、または等SIP、SIMPLE、H.323、RTP、HTTPなどの通信アプリケーションプロトコルによって使用されるUDPポートを含みます
This parameter MUST be sent in the first RAQMON PDU.
このパラメータは、最初のRAQMON PDUに送らなければなりません。
This parameter gives the time when the setup was initiated, if the application has a setup phase, or when the session was started, if such a setup phase does not exist. The time is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC (Coordinated Universal Time) on 1 January 1900 [RFC1305].
このパラメータは、アプリケーションがセットアップフェーズを持っている場合、またはセッションが開始されたとき、そのようなセットアップフェーズが存在しない場合、セットアップは、開始された時間を提供します。時間は秒単位で1900年1月1日、[RFC1305]にUTC（協定世界時）を0Hに対して相対的であるネットワークタイムプロトコル（NTP）のタイムスタンプ形式を使用して表されています。
This parameter SHOULD be sent only in the first RAQMON PDU, after the session setup is completed.
セッションのセットアップが完了した後にこのパラメータは、最初のRAQMON PDUに送ってください。
The Session Setup Delay metric reports the time taken from an origination request being initiated by a host/endpoint to the media path being established (or a session progress indication being received from the remote host/endpoint), expressed in milliseconds. For example, in VoIP systems, a session setup time can be measured as the interval from the last DTMF (dual-tone multi-frequency) button pushed to the first ring-back tone that indicates that the far end is ringing. Another example would be the Session Setup Delay of a SIP call, which is measured as the elapsed time between when an INVITE is generated by a User Agent and when the 200 OK is received.
セッション設定遅延メトリックが確立されているメディア・パス（またはリモート・ホスト/エンドポイントから受信されたセッションの進行表示）ホスト/エンドポイントによって開始される発信要求からの時間を報告し、ミリ秒単位で表しました。最後DTMF（デュアルトーンマルチ周波数）ボタンから間隔が遠端が鳴っていることを示す第1のリングバックトーンにプッシュとしては、例えば、VoIPシステムでは、セッションセットアップ時間を測定することができます。別の例では、ユーザエージェントによって生成されたINVITEときに200 OKを受信したときの間の経過時間として測定されるSIP呼のセッション設定遅延であろう。
This parameter SHOULD be sent only in the first RAQMON PDU, after the session setup is completed.
セッションのセットアップが完了した後にこのパラメータは、最初のRAQMON PDUに送ってください。
The Session Duration metric reports how long a session or a sub-session lasted. This metric is application context sensitive. For example, a VoIP Call Session Duration can be measured as the elapsed time between call pickup and call termination, including session setup time.
セッションまたはサブセッションが続いたどのくらいのセッション継続時間メトリックレポート。このメトリックは、アプリケーション・コンテキストに敏感です。例えば、VoIPの通話セッション継続時間は、コールピックアップおよびセッションセットアップ時間を含め、終了呼び出し間の経過時間として測定することができます。
This parameter SHOULD be sent only in the first RAQMON PDU, after the session is terminated.
セッションが終了した後、このパラメータは、最初のRAQMON PDUに送ってください。
The Session Setup Status metric is intended to report the communication status of a session. Its values identify appropriate communication session states, such as Call Progressing, Call Established successfully, "trying", "ringing", "re-trying", "RSVP reservation failed", and so on.
セッションセットアップステータスメトリックは、セッションの通信状況を報告することを意図しています。その値は、その上の「再しよう」、「RSVP予約が失敗しました」、「リンギング」、および、「しよう」、成功裏に確立された呼は、そのようなコールが進んなどの適切な通信セッションの状態を識別します。
Session setup status is meaningful in the context of applications. For this reason, applications SHOULD use this metric together with the application/name metrics defined in Section 5.32.
セッションの設定状態は、アプリケーションのコンテキストで意味があります。このため、アプリケーションは、セクション5.32で定義されたアプリケーション/名前メトリックと一緒に、このメトリックを使用すべきです。
This information could be used by network management systems to calculate parameters such as call success rate, call failure rate, etc., or by a debugging tool that captures the status of a call's setup phase as soon as a call is established.
この情報には、コールの成功率などのパラメータを計算するなどの故障率を、呼び出し、またはとすぐに通話が確立されると、コールのセットアップフェーズの状態をキャプチャするデバッグツールにより、ネットワーク管理システムで使用することができます。
This parameter SHOULD be sent after each change in the session status.
このパラメータは、セッション状態の各変化の後に送ってください。
The Round-Trip End-to-End Network Delay, defined in [RFC3550] for applications running over RTP and in [RFC2681] for all other IP applications, is a key metric for Application QoS Monitoring. Some applications do not perform well (or at all) if the end-to-end delay between hosts is large relative to some threshold value. Erratic variation in delay values makes it difficult (or impossible) to support many real-time applications such as Voice over IP, Video over IP, Fax over IP etc.
その他のすべてのIPアプリケーションのためのRTP上とで動作するアプリケーションのための[RFC3550] [RFC2681]で定義された往復エンドツーエンドのネットワーク遅延は、アプリケーションQoSのモニタリングのための重要なメトリックです。ホスト間のエンドツーエンド遅延がある閾値に対して大きい場合、いくつかのアプリケーションでは、ウェル（またはまったく）行いません。遅延値の不安定な変動は、それが困難（または不可能）なボイスオーバーIP、IP上のビデオなどオーバーIPファックスなど、多くのリアルタイムアプリケーションをサポートすることができます
The Round-Trip End-to-End Network delay of the underlying transport network is measured using methodologies described in [RFC3550] for RTP and in [RFC2681] for other IP applications.
基礎となるトランスポートネットワークの往復エンドツーエンドのネットワーク遅延は、RTPおよび他のIPアプリケーションのために[RFC2681]の[RFC3550]に記載された方法論を使用して測定されます。
Note that the packets used for measurement in some methodologies may be of a different type from those used for media (e.g., ICMP instead of RTP) and hence may differ in terms of route and queue priority. This may result in measured delays being different from those experienced on the media path. Conformance for this metric requires that actual application packets, or packets of the same application type, be used.
いくつかの方法で測定するために使用されるパケットは、メディア（代わりにRTPの例えば、ICMP）のために使用されるものとは異なるタイプのものであってもよいし、したがって経路およびキューの優先度の点で異なっていてもよいことに留意されたいです。これは、測定された遅延は、メディアパスに経験したものとは異なるものになることがあります。このメトリックの適合性は、実際のアプリケーションパケット、または同じアプリケーションタイプのパケットは、使用されることを必要とします。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートは、アプリケーションを実行するホストにRTP MIB [RFC2959]のサポートによって、またはアプリケーション名（セクション5.32）の先頭に文字列「RTP」を含めることによって決定することができます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
The One-Way End-to-End Network Delay [RFC2679] metric reports the One-Way End-to-End delay encountered by traffic from the source to the destination network interface. One-Way Delay measurements identified by the IP Performance Metrics (IPPM) Working Group [RFC2679] will be used to measure one-way end-to-end network delay.
ワンウェイエンドツーエンドのネットワーク遅延[RFC2679]メトリックレポート送信元から宛先ネットワークインターフェイスへのトラフィックが遭遇ワンウェイエンドツーエンド遅延。 IPパフォーマンス・メトリック（IPPM）ワーキンググループ[RFC2679]で識別されるワンウェイ遅延測定は、一方向のエンドツーエンドのネットワーク遅延を測定するために使用されます。
The need for such a metric is derived from the fact that the path from a source to a destination may be different from the path from the destination back to the source ("asymmetric paths"), such that different sequences of routers are used for the forward and reverse paths. Therefore, round-trip measurements actually measure the performance of two distinct paths together.
そのようなメトリックの必要性は、ソースから宛先へのパスが宛先からバックルータの異なる配列がために使用されるように、ソース（「非対称パス」）へのパスとは異なるかもしれないという事実に由来しますフォワードおよびリバースパス。したがって、往復の測定値は、実際には2つの別個の経路の性能を測定します。
Measuring each path independently highlights the performance difference between the two paths that may traverse different Internet service providers, and even radically different types of networks (for example, research versus commodity networks, or ATM (Asynchronous Transfer Mode) versus Packet-over-SONET (Synchronous Optical) transport networks).
、コモディティネットワーク、またはパケットオーバーSONET対ATM（非同期転送モード）に対する研究（例えば、（異なるインターネットサービスプロバイダ、およびネットワークのも根本的に異なるタイプを横断することができる二つの経路間の性能の差は、それぞれ独立して、パスを強調測定します同期光）トランスポートネットワーク）。
Even when the two paths are symmetric, they may have radically different performance characteristics due to asymmetric queuing. Performance of an application may depend mostly on the performance in one direction. For example, a file transfer using TCP may depend more on the performance in the direction that data flows than on the direction in which acknowledgements travel.
2つのパスが対称である場合でも、それらは非対称イングに起因する根本的に異なる性能特性を有することができます。アプリケーションのパフォーマンスは、主に1つの方向の性能に依存してもよいです。例えば、TCPを使用してファイル転送は、データ移動を謝辞方向よりも流れる方向の性能の詳細に依存してもよいです。
In QoS-enabled networks, provisioning in one direction may be radically different from provisioning in the reverse direction, and thus the QoS guarantees differ. Measuring the paths independently allows the verification of both guarantees.
QoS対応ネットワークでは、一方向のプロビジョニングは逆方向にプロビジョニングから根本的に異なることができるので、QoS保証が異なります。経路を測定することは、独立して、両方の保証の検証を可能にします。
RAQMON SHOULD NOT derive One-Way End-to-End Network Delay by assuming Internet paths are symmetric (i.e., dividing Round-Trip Delay by two).
RAQMONは（すなわち、2でラウンドトリップ遅延を分割する）インターネットパスが対称であると仮定してワンウェイエンド・ツー・エンドのネットワーク遅延を導出すべきではありません。
Note that the packets used for measurement in some methodologies may be of a different type from those used for media (e.g., ICMP instead of RTP) and hence may differ in terms of route and queue priority. This may result in measured delays being different from those experienced on the media path. Conformance for this metric requires that actual application packets, or packets of the same application type, be used.
いくつかの方法で測定するために使用されるパケットは、メディア（代わりにRTPの例えば、ICMP）のために使用されるものとは異なるタイプのものであってもよいし、したがって経路およびキューの優先度の点で異なっていてもよいことに留意されたいです。これは、測定された遅延は、メディアパスに経験したものとは異なるものになることがあります。このメトリックの適合性は、実際のアプリケーションパケット、または同じアプリケーションタイプのパケットは、使用されることを必要とします。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
Various Network Delay versions, as outlined in Sections 5.11 and 5.12, do not include delays associated with buffering, play-out, packet-sequencing, coding/decoding, etc., in the end-devices. The Application Delay metric defined in this section is targeted to capture all such delay parameters, providing a total application endpoint delay.
さまざまなネットワーク遅延のバージョンは、セクション5.11と5.12で概説したように、エンドデバイスでは、バッファリング、遊ぶアウト、パケットシーケンシング、符号化/復号化などに関連する遅延が含まれていません。このセクションで定義されたアプリケーションの遅延メトリックは、全アプリケーションエンドポイント遅延を提供する、すべてのそのような遅延パラメータを捕捉するために標的化されます。
Application delay can be expressed as the time delay introduced between the network interface and the application-level presentation. Since it is difficult to envision usage of all sorts of applications, the following guidance is provided to the implementers to measure the application delay:
アプリケーションの遅延は、ネットワークインターフェースとアプリケーション・レベルのプレゼンテーションの間に導入される時間遅延として表すことができます。それはアプリケーションのすべての種類の使用を想定することは困難であるため、以下のガイダンスは、アプリケーションの遅延を測定するための実装に提供されています。
- The sending end contribution to application delay is defined as the sum of sample sequencing, accumulation, and encoding delay.
- アプリケーション遅延に送信端の寄与は、サンプルの配列決定、蓄積、符号化遅延の合計として定義されます。
- The receiving end contribution to application delay is calculated as the sum of delays associated with buffering, play-out, packet-sequencing, and decoding associated with the receiving direction, if relevant.
- アプリケーション遅延に受信端の寄与はバッファリング、プレイアウト、パケットシーケンシング、および関連する場合、受信方向に関連付けられた復号に関連する遅延の和として計算されます。
The endpoint application delay is defined as the sum of the receiving and sending contributions to delay measured or estimated within the endpoint that is generating this report.
エンドポイント・アプリケーションの遅延は、受信の合計として定義され、このレポートを生成しているエンドポイント内に測定または推定遅延に貢献を送信しています。
It is easy to recognize that applications running on an IP device can experience same network delay but have different application-associated delay values. As such, the user experience associated with specific applications may vary while the network delay value remains same for both the applications.
IPデバイス上で実行中のアプリケーションが同じネットワーク遅延が発生するが、別のアプリケーションに関連した遅延値を持つことができることを認識することは容易です。ネットワーク遅延値は、両方のアプリケーションのために同じままのような、特定のアプリケーションに関連付けられたユーザ体験が変化してもよいです。
Having network delay and application delay measurements available, a management application can represent the delay experienced by the end user at the application level as a sum of network delay and the application delays reported from the endpoints. However, the specification of such a management application is outside the scope of the RAQMON specification.
ネットワーク遅延およびアプリケーション遅延測定値が利用可能有する、管理アプリケーションは、ネットワーク遅延およびエンドポイントから報告されたアプリケーションの遅延の和としてアプリケーションレベルで、エンドユーザが経験する遅延を表すことができます。しかしながら、そのような管理アプリケーションの仕様はRAQMON仕様の範囲外です。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
The Inter-Arrival Jitter metric provides a short-term measure of network congestion [RFC3550]. The jitter measure may indicate congestion before it leads to packet loss. The inter-arrival jitter field is only a snapshot of the jitter at the time when a RAQMON PDU is generated and is not intended to be taken quantitatively as indicated in [RFC3550]. Rather, it is intended for comparison of inter-arrival jitter from one receiver over time. Such inter-arrival jitter information is extremely useful to understand the behavior of certain applications such as Voice over IP, Video over IP, etc. Inter-arrival jitter information is also used in the sizing of play-out buffers for applications requiring the regular delivery of packets (for example, voice or video play-out).
到着間ジッタメトリックは、ネットワークの混雑[RFC3550]の短期的な尺度を提供します。それはパケット損失につながる前に、ジッタ測定値は、輻輳を示すかもしれません。到着間ジッタフィールドはRAQMON PDUが生成され、[RFC3550]に示されているように定量的に解釈すべきものではない時のジッターのスナップショットのみです。むしろ、それは、時間をかけて一つの受信機から到着間ジッタの比較のために意図されています。このような到着間ジッタ情報は、インター到着ジッタ情報も定期的に配信を必要とするアプリケーションのためのプレイアウトバッファのサイズ設定で使用されているなどボイスオーバーIP、IP上のビデオ、などの特定のアプリケーションの動作を理解することは非常に有用ですパケット（例えば、音声またはビデオのプレイアウト）の。
In [RFC3550], the selection function is implicitly applied to consecutive packet pairs, and the "jitter estimate" is computed by applying an exponential filter with parameter 1/16 to generate the estimate (i.e., j_new = 15/16* j_old + 1/16*j_new).
[RFC3550]に、選択機能は、暗黙的に連続したパケットペアに適用され、「ジッタ推定値は」推定値を生成するパラメータ1/16と指数関数フィルタを適用することによって計算される（すなわち、j_new = 16分の15 * j_old + 1 / 16 * j_new）。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
[RFC3393] provides guidance to several absolute jitter parameters. RAQMON uses the [RFC3393] definition of the IP Packet Delay Variation (ipdv) for packets inside a stream of packets. The IP Delay Variation metric is used to determine the dynamics of queues within a network (or router) where the changes in delay variation can be linked to changes in the queue length processes at a given link or a combination of links. Such a parameter provides visibility within an IP Network and a better understanding of application-level performance problems as it relates to IP Network performance.
[RFC3393]はいくつかの絶対ジッタパラメータにガイダンスを提供します。 RAQMONは、パケットのストリーム内のパケットのIPパケット遅延変動（IPDV）の[RFC3393]の定義を使用します。 IP遅延変動メトリックは、遅延変動の変化が所定のリンクまたはリンクの組み合わせにおけるキュー長プロセスの変化にリンクすることができ、ネットワーク（またはルータ）内のキューのダイナミクスを決定するために使用されます。それはIPネットワーク性能に関連するそのようなパラメータは、IPネットワーク内の可視性、およびアプリケーション・レベルのパフォーマンスの問題のより良い理解を提供します。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
This metric reports the number of application payload packets received by the RDS as part of this session since the last RAQMON PDU was sent up until the time this RAQMON PDU was generated.
最後RAQMON PDUがこのRAQMON PDUが生成された時間までに送信されたので、このメトリックは、このセッションの一部として、RDSによって受信されたアプリケーション・ペイロード・パケットの数を報告します。
This parameter represents a very simple incremental counter that counts the number of "application" packets that an RDS has received. Application packets MAY include signaling packets. Since this count is a snapshot in time, depending on application type, it also varies based on the application states, e.g., an RDS within an application session will report the aggregated number of application packets that were sent out during signaling setup, media packets received, session termination, etc.
このパラメータは、RDSは、受信した「アプリケーション」のパケットの数をカウントし、非常に単純な増分カウンタを表します。アプリケーションパケットは、シグナリングパケットを含むかもしれません。このカウントが時間内にスナップショットがあるので、アプリケーションの種類に応じて、それはまた、例えばアプリケーションの状態に基づいて変化し、RDSは、シグナリングセットアップ中に送り出されたアプリケーションパケットの集約数を報告しますアプリケーションセッション内で、メディアパケットを受信しますなど、セッション終了、
For example, during Voice over IP or Video over IP sessions setup, this counter represents the number of signaling-session-related packets that have been received that will be derived from the relevant application signaling protocol stack such as SIP or H.323, SIMPLE, and various other signaling protocols used by the application to establish the communication session.
例えば、IPセッションのセットアップオーバーIPまたはビデオボイスオーバーの間に、このカウンタは、SIPやH.323、SIMPLEなどの関連アプリケーションシグナリングプロトコルスタックから誘導される受信されたシグナリングセッションに関連するパケットの数を表します。 、通信セッションを確立するためにアプリケーションによって使用される様々な他のシグナリングプロトコル。
However, during a period when media is established between the communicating entities, this counter will be indicative of the number of RTP Frames that have been sent out to the communicating party since last PDU was sent out. The methodology described within RTCP SR/RR reports [RFC3550] to count RTP frames will be applied wherever applications use RTP. This being a cumulative counter, applications need to take into consideration the possibility of the counter overflowing and restarting counting from zero.
しかし、メディアは通信エンティティ間で確立された期間中に、このカウンタは、最後のPDUが送信されてから通信相手に送信されてきたRTPフレームの数を示すことになります。アプリケーションは、RTPを使用どこRTPフレームをカウントするRTCP SR / RRレポート[RFC3550]の中に記載された方法論が適用されます。これは、累積カウンターされて、アプリケーションを考慮にカウンタがオーバーフローし、ゼロからカウントを再開する可能性を取る必要があります。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートは、アプリケーションを実行するホストにRTP MIB [RFC2959]のサポートによって、またはアプリケーション名（セクション5.32）の先頭に文字列「RTP」を含めることによって決定することができます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
This metric reports the number of signaling and payload packets sent by the RDS as part of this session since the last RAQMON PDU was sent until the time this RAQMON PDU was generated. Applications packets MAY include signaling packets. Similar to the total number of application packets received parameter in Section 5.16, this count is a snapshot in time. Depending on the application type, the counter also varies based on various application states, including packet counts for signaling setup, media establishment, session termination states, and so on. This being a cumulative counter, applications need to take into consideration the possibility of the counter overflowing and restarting counting from zero.
このメトリックは、最後のRAQMON PDUがこのRAQMON PDUが生成された時間までに送信されたので、このセッションの一部として、RDSによって送信されたシグナリングおよびペイロードパケットの数を報告します。アプリケーションパケットは、シグナリングパケットを含むかもしれません。 5.16でパラメータを受信したアプリケーションパケットの合計数と同様に、このカウントは、時間のスナップショットです。アプリケーションの種類に応じて、カウンターもそうでセットアップ、メディアの確立、セッション終了状態、およびシグナル伝達のためのパケットカウントを含むさまざまなアプリケーションの状態に基づいて変化します。これは、累積カウンターされて、アプリケーションを考慮にカウンタがオーバーフローし、ゼロからカウントを再開する可能性を取る必要があります。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
This metric reports the total number of signaling and payload octets received in packets by the RDS as part of this session since the last RAQMON PDU was sent, up until the time this RAQMON packet was generated. Applications octets MAY include signaling octets. The methodology described by [RFC3550] will be applied wherever applications use RTP. This being a cumulative counter, applications need to take into consideration the possibility of the counter overflowing and restarting counting from zero.
このメトリックは、シグナルの合計数を報告し、最後RAQMON PDUがこのRAQMONパケットが生成された時刻まで、送信されたため、ペイロードのオクテットは、このセッションの一部として、RDSによってパケットで受信しました。アプリケーションのオクテットは、シグナリングオクテットを含むかもしれません。アプリケーションは、RTPを使用する限り、[RFC3550]によって記載された方法が適用されます。これは、累積カウンターされて、アプリケーションを考慮にカウンタがオーバーフローし、ゼロからカウントを再開する可能性を取る必要があります。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートは、アプリケーションを実行するホストにRTP MIB [RFC2959]のサポートによって、またはアプリケーション名（セクション5.32）の先頭に文字列「RTP」を含めることによって決定することができます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
This metric reports the total number of signaling and payload octets received in packets by the RDS as part of this session since the last RAQMON PDU was sent, up until the time this RAQMON packet was generated. This is similar to the Total Number of Application Octets Received metric. Applications octets MAY include signaling octets. The methodology described by [RFC3550] will be applied wherever applications use RTP. This being a cumulative counter, applications need to take into consideration the possibility of the counter overflowing and restarting counting from zero.
このメトリックは、シグナルの合計数を報告し、最後RAQMON PDUがこのRAQMONパケットが生成された時刻まで、送信されたため、ペイロードのオクテットは、このセッションの一部として、RDSによってパケットで受信しました。これは、メトリック受信したアプリケーションオクテットの総数に似ています。アプリケーションのオクテットは、シグナリングオクテットを含むかもしれません。アプリケーションは、RTPを使用する限り、[RFC3550]によって記載された方法が適用されます。これは、累積カウンターされて、アプリケーションを考慮にカウンタがオーバーフローし、ゼロからカウントを再開する可能性を取る必要があります。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートは、アプリケーションを実行するホストにRTP MIB [RFC2959]のサポートによって、またはアプリケーション名（セクション5.32）の先頭に文字列「RTP」を含めることによって決定することができます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
The cumulative packet loss metric indicates the loss associated with the network as well as local device losses over time. This parameter is counted as the total number of application packets from the source that have been lost since the beginning of the session. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes the count of packets that are late or duplicates. If a packet is discarded due to late arrival, then it MUST be counted as either lost or discarded but MUST NOT be counted as both.
累積パケット損失メトリックは、時間の経過ネットワークならびにローカルデバイスの損失に関連する損失を示しています。このパラメータは、セッションの開始以来、失われたソースからのアプリケーションパケットの合計数としてカウントされます。この数は、パケットの数が遅いまたは重複しているパケット数を含む受信実際に受信したパケットのより少ない数を、予想されるパケットの数であると定義されます。パケットが遅れて到着が原因で廃棄されている場合は、失われたり、廃棄されたが、両方としてカウントしてはならないのどちらかとしてカウントされなければなりません。
Packet loss by the underlying transport network SHALL be measured using the methodologies described in [RFC3550] for RTP traffic and [RFC2680] for other IP traffic. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. For RTP traffic, this may be calculated using techniques such as those shown in Appendix A.3 of [RFC3550].
基礎となるトランスポート・ネットワークによるパケット損失は、他のIPトラフィックのRTPトラフィックと[RFC2680]のために[RFC3550]に記載の方法を用いて測定します。予想されるパケットの数が拡張最後のシーケンス番号であると定義される次の定義として、受信した、より少ない初期シーケンス番号は、受信されました。 RTPトラフィックの場合、これは、[RFC3550]の付録A.3に示すもののような技術を用いて計算することができます。
Packet loss by the underlying transport network SHALL be measured using the methodologies described in [RFC3550] for RTP traffic and [RFC2680] for other IP traffic. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. For RTP traffic, this may be calculated using techniques such as those shown in Appendix A.3 of [RFC3550].
基礎となるトランスポート・ネットワークによるパケット損失は、他のIPトラフィックのRTPトラフィックと[RFC2680]のために[RFC3550]に記載の方法を用いて測定します。予想されるパケットの数が拡張最後のシーケンス番号であると定義される次の定義として、受信した、より少ない初期シーケンス番号は、受信されました。 RTPトラフィックの場合、これは、[RFC3550]の付録A.3に示すもののような技術を用いて計算することができます。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートは、アプリケーションを実行するホストにRTP MIB [RFC2959]のサポートによって、またはアプリケーション名（セクション5.32）の先頭に文字列「RTP」を含めることによって決定することができます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
The Packet Loss in Fraction metric represents the packet loss as defined above, but expressed as a fraction of the total traffic over time.
画分メトリックにおけるパケット損失が上記で定義したパケット損失を表すが、時間の経過総トラフィックの割合として表しました。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
The RAQMON Framework allows applications to distinguish between packets lost by the network and those discarded due to jitter and other application-level errors. Though packet loss and discards have an equal effect on the quality of the application, having separate counts for packet loss and discards helps identify the source of quality degradation.
RAQMON Frameworkは、アプリケーションがネットワークによって失われたパケットとによるジッタおよび他のアプリケーションレベルのエラーのために廃棄されるものとを区別することを可能にします。パケット損失と破棄は、アプリケーションの品質に同等の効果を持っていますが、パケットロスおよび破棄のために別々のカウントを有する高品質の劣化の原因を特定するのに役立ちます。
The packet discard metric indicates packets discarded locally by the device over time. Local device-level packet discard is captured as the total number of application-level packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer, or any other application-specific reasons.
パケット廃棄メトリックは、時間の経過とともに、デバイスによってローカルで廃棄されたパケットを示します。ローカルデバイスレベルのパケット廃棄は、総受信ジッタバッファにおけるアンダーランまたはオーバーフロー後期又は早期到着による受信の開始以来、廃棄されたソースからアプリケーションレベルのパケットの数、または任意として捕捉されます他のアプリケーション固有の理由。
If the RDS cannot tell the difference between discards and lost packets, then it MUST report only lost packets and MUST NOT report discards.
RDSは破棄し、失われたパケットの違いを言うことができない場合は、それが唯一の失われたパケットを報告しなければなりませんし、破棄を報告してはなりません。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
The packet discards in fraction metric represents packets from the source that have been discarded since the beginning of the reception but expressed as a fraction of the total traffic over time.
フラクションメトリックにおけるパケット破棄は、受信の開始以来、廃棄なく経時総トラフィックの分数として表現されているソースからのパケットを表します。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
The source payload type reports payload formats (e.g., media encoding) as sent by the data source, e.g., ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII, etc. This memo follows the definition of Payload Type (PT) in [RFC3551]. For example, to indicate that the source payload type used for a session is PCMA (pulse-code modulation with A-law scaling), the value of the source payload field for the respective session will be 8.
ソースペイロードタイプは、このメモは、の定義に従うなど、データ・ソースによって送信されたペイロード・フォーマット（例えば、メディア符号化）を報告し、例えば、ITU G.711、ITU G.729B、H.263、MPEG-2、ASCIIペイロードタイプ[RFC3551]に（PT）。例えば、セッションのために使用されるソースペイロードタイプはPCMA（則スケーリングパルス符号変調）であることを示すために、各セッションのソース・ペイロード・フィールドの値が8であろう。
The source payload type value is expected to remain constant for the duration of a session, with the exception of events like dynamic codec changes. RDSs SHOULD avoid sending these parameters within RAQMON reports more often than necessary (e.g., at dynamic codec changes) to ensure an efficient usage of network resources.
ソースペイロードタイプ値は、動的コーデックの変更などのイベントを除いて、セッションの期間中一定に維持することが期待されます。 RDSはRAQMON内でこれらのパラメータを送信することは避けるべきネットワーク資源の効率的な使用を保証するために（例えば、動的なコーデックの変更で）より頻繁に必要以上に報告します。
If dynamic types (values 96 to 127, according to [RFC3551]) are being used to identify the source payload type, a RAQMON extension parameter MAY be defined to indicate the MIME subtypes. In the case where the RDS does send reports noting dynamic codec changes, there may be instances where this extension parameter is used only before or after the codec change, as the source payload may shift between the dynamic and static types.
動的型は（[RFC3551]によれば、96〜127の値）ソースペイロードタイプを識別するために使用されている場合、RAQMON拡張パラメータは、MIMEサブタイプを示すように定義されてもよいです。 RDSは、動的コーデックの変更を指摘レポートを送信しない場合には、ソース・ペイロードは、動的および静的タイプ間でシフトすることができるように、この拡張パラメータは、唯一のコーデック変更の前または後に使用されているインスタンスが存在してもよいです。
The receiver payload type reports payload formats (e.g., media encodings) as sent by the other communicating party back to the source, e.g., ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII, etc. This document follows the definition of payload type (PT) in [RFC3551].
受信ペイロードタイプはこのなど、バックソースに他の通信相手によって送信されたペイロード・フォーマット（例えば、メディアエンコーディング）を報告し、例えば、ITU G.711、ITU G.729B、H.263、MPEG-2、ASCIIドキュメントは[RFC3551]でペイロードタイプ（PT）の定義に従います。
For example, to indicate that the destination payload type used for a session is PCMA, the destination payload type field for the respective session will be 8.
例えば、セッションのために使用される宛先ペイロードタイプがPCMAであることを示すために、各セッションの宛先ペイロードタイプフィールドは8になります。
The destination payload type value is expected to remain constant for the duration of a session, with the exception of events like dynamic codec changes. RDSs SHOULD avoid sending these parameters within RAQMON reports more often than necessary (e.g., at dynamic codec changes) to ensure an efficient usage of network resources.
先のペイロードタイプ値は、動的コーデックの変更などのイベントを除いて、セッションの期間中一定に維持することが期待されます。 RDSはRAQMON内でこれらのパラメータを送信することは避けるべきネットワーク資源の効率的な使用を保証するために（例えば、動的なコーデックの変更で）より頻繁に必要以上に報告します。
If dynamic types (values 96 to 127, according to [RFC3551]) are being used to identify the destination payload type, a RAQMON extension parameter MAY be defined to indicate the MIME subtypes. In the case where the RDS does send reports noting dynamic codec changes, there may be instances where this extension parameter is used only before or after the codec change, as the destination payload may shift between the dynamic and static types.
動的型は（[RFC3551]によれば、96〜127の値）宛先ペイロードタイプを識別するために使用されている場合、RAQMON拡張パラメータは、MIMEサブタイプを示すように定義されてもよいです。 RDSは、動的コーデックの変更を指摘レポートを送信しない場合には、先のペイロードは、動的および静的タイプ間でシフトすることができるように、この拡張パラメータは、唯一のコーデック変更の前または後に使用されているインスタンスが存在してもよいです。
Many devices use Layer 2 technologies to prioritize certain types of traffic in the Local Area Network environment. For example, the 1998 Edition of IEEE 802.1D [IEEE802.1D], "Media Access Control Bridges", contains expedited traffic capabilities to support transmission of time-critical information. Many devices use that standard to mark Ethernet frames according to IEEE P802.1p standard. Details on these can be found in [IEEE802.1D], which incorporates P802.1p. The Source Layer 2 Priority RAQMON field indicates what Layer 2 values were used by the host running the RDS to prioritize these packets in the Local Area Network environment.
多くのデバイスは、ローカルエリアネットワーク環境において特定のタイプのトラフィックに優先順位を付けるレイヤ2技術を使用しています。例えば、IEEE 802.1D [IEEE802.1D]の1998年版は、「メディアアクセス制御ブリッジは」、タイムクリティカルな情報の伝送をサポートするために、迅速な交通機能が含まれています。多くのデバイスは、IEEE P802.1p標準に従ってイーサネットフレームをマークするために、その標準を使用しています。これらの詳細についてはP802.1pを組み込んだ、[IEEE802.1D]で見つけることができます。元レイヤ2優先順位RAQMONフィールドには、2つの値がローカルエリアネットワーク環境でこれらのパケットを優先するRDSを実行しているホストによって使用されたどのようなレイヤを示しています。
The Source Layer 2 Priority value is expected to remain constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
ソースレイヤ2優先順位値は、セッションの期間中、一定のままと予想されます。 RDSにを実行しているホストはRAQMONは、ネットワークリソースの効率的な使用を確保するためには、あまりにも頻繁に報告の中に、これらのパラメータを送信することは避けてください。
Various Layer 3 technologies are in place to prioritize traffic in the Internet. For example, the traditional IP Precedence [RFC791] and Type of Service (TOS) [RFC1812], or more recent technologies like Differentiated Services [RFC2474] [RFC2475], use the TOS octet in IPv4, whereas the traffic class octet is used to prioritize traffic in IPv6. Source Layer TOS/DCP RAQMON field reports the appropriate Layer 3 values used by the Data Source to prioritize these packets.
様々なレイヤ3の技術は、インターネットのトラフィックに優先順位を付けるための場所です。トラフィッククラスオクテットをするために使用されるのに対し、例えば、従来のIP優先順位[RFC791]およびサービスタイプ（TOS）[RFC1812]、または差別化サービスのような、より最近の技術[RFC2474] [RFC2475]は、IPv4のTOSオクテットを使用しますIPv6ではトラフィックに優先順位をつけます。元レイヤTOS / DCP RAQMONフィールドは、これらのパケットを優先するデータソースによって使用される適切なレイヤ3つの値を報告します。
The Source TOS/DSCP value is expected to remain constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
ソースTOS / DSCP値は、セッションの間に一定のままと予想されます。 RDSにを実行しているホストはRAQMONは、ネットワークリソースの効率的な使用を確保するためには、あまりにも頻繁に報告の中に、これらのパラメータを送信することは避けてください。
The Destination Layer 2 Priority reports the Layer 2 value used by the communication receiver to prioritize packets while sending traffic to the data source in the Local Area Networks environment. Like Source Layer 2 Priority, Destination Layer 2 Priority could indicate whether the destination has used Layer 2 technologies like IEEE P802.1p for priority queuing.
先のレイヤ2の優先順位は、ローカルエリアネットワーク環境でのデータソースへのトラフィックを送信中のパケットの優先順位を決定するために、通信受信機で使用されるレイヤ2値を報告します。ソースレイヤ2優先順位と同様に、先のレイヤ2優先順位は、宛先が優先キューイングのためのIEEE P802.1pのようなレイヤ2テクノロジーを使用しているかどうかを示すことができます。
The Destination Layer 2 Priority value is expected to remain constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
先のレイヤ2優先順位値は、セッションの期間中、一定のままと予想されます。 RDSにを実行しているホストはRAQMONは、ネットワークリソースの効率的な使用を確保するためには、あまりにも頻繁に報告の中に、これらのパラメータを送信することは避けてください。
The Destination TOS/DSCP RAQMON field reports the values used by the Data Receiver to prioritize these packets received by the source. Similar to Source Layer 3 Priority, Destination Layer 3 Priority indicates whether the destination has used any Layer 3 technologies like IP Precedence [RFC791] and Type of Service (TOS) [RFC1812], or more recent technologies like Differentiated Service [RFC2474] [RFC2475].
先TOS / DSCP RAQMONフィールドは、ソースが受信し、これらのパケットを優先するデータ受信で使用される値を報告します。ソースレイヤ3の優先順位と同様に、デスティネーションレイヤ3の優先順位は、宛先がIP優先順位[RFC791]およびサービスタイプ（TOS）[RFC1812]、または差別化サービスのような、より最近の技術[RFC2474] [RFC2475などの任意のレイヤ3つの技術を使用しているかどうかを示します]。
The Destination TOS/DSCP value is expected to remain constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
先TOS / DSCP値は、セッションの間に一定のままと予想されます。 RDSにを実行しているホストはRAQMONは、ネットワークリソースの効率的な使用を確保するためには、あまりにも頻繁に報告の中に、これらのパラメータを送信することは避けてください。
This parameter captures the CPU usage of the hosts running the RDSs that may have very critical implications for QoS of an end-device. It is computed as an average since the last reporting interval, and corresponds to the percentage of that time that the CPU was busy.
このパラメータは、エンドデバイスのQoSのために非常に重要な意味を持っていることがRDSにを実行しているホストのCPU使用率をキャプチャします。それは最後のレポート間隔以降の平均として計算され、CPUがビジー状態だった時間の割合に相当します。
In the case of multiple CPU hosts, the maximum utilization among the different CPUs MUST be reported.
複数のCPUのホストの場合には、異なるCPUのうちの最大の利用が報告されなければなりません。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
This parameter captures the memory usage of the hosts running the RDSs that may have very critical implications for QoS of an end-device. It is computed as an average since the last reporting interval and corresponds to the average percentage of the total memory space critical for the applications in use during that time interval (e.g., primary CPU RAM, buffers).
このパラメータは、エンドデバイスのQoSのために非常に重要な意味を持っていることがRDSにを実行しているホストのメモリ使用量をキャプチャします。これは、最後の報告インターバルので平均として計算され、その時間間隔（例えば、一次CPUのRAM、バッファ）中に使用中のアプリケーションのための重要な総メモリ空間の平均パーセンテージに相当します。
In the case of multiple CPU hosts, the maximum memory utilization among the different CPUs MUST be reported.
複数のCPUのホストの場合には、異なるCPU間で最大メモリ使用率が報告されなければなりません。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSは、その値を決定する能力を有する場合、パラメータは、アプリケーションに関連する場合、このパラメータは、各RAQMON PDUで送信されるべきです。
The Application Name/Version parameter gives the name and, optionally, the version of the application associated with that session or sub-session, e.g., "XYZ VoIP Agent 1.2". This information may be useful for scenarios where the end-device is running multiple applications with various priorities and could be very handy for debugging purposes.
アプリケーション名/バージョンパラメータは、必要に応じて、そのセッションまたはサブセッションに関連するアプリケーション、例えば、「XYZのVoIPエージェント1.2」のバージョンを名前を与え、。この情報は、エンドデバイスは、さまざまな優先順位で複数のアプリケーションを実行しているし、デバッグ目的のために非常に便利かもしれないシナリオに有用である可能性があります。
If the application is using RTP [RFC3550], the Application Name SHOULD begin with the string 'RTP'.
アプリケーションはRTP [RFC3550]を使用している場合は、アプリケーション名は、文字列「RTP」で始める必要があります。
This parameter MUST be sent in the first RAQMON PDU.
このパラメータは、最初のRAQMON PDUに送らなければなりません。
Within the RAQMON Framework, RRCs are expected to have significantly greater computational resources than RDSs. Consequently, various aggregation functions are performed by the RRCs, while RDSs are not burdened by statistical data processing such as computation of minima, maxima, averages, standard deviations, etc.
RAQMON枠組みの中で、RRCsは、RDSに比べて著しく大きな計算リソースを有することが期待されます。 RDSが等最小値の演算、最大値、平均値、標準偏差などの統計データ処理によって負担されていないながらその結果、様々な集約関数は、RRCsによって実行されます
The RAQMON MIB provides minimal aggregation of the RAQMON parameters defined above. The RAQMON MIB is not designed to provide extensive aggregation like the Application Performance Measurement (APM) MIB [RFC3729] or the Transport Performance Metrics (TPM) MIB [RFC4150]. One should use APM and TPM MIBs to aggregate parameters based on protocols (e.g., performance of HTTP, RTP) or applications (e.g., performance of VoIP, Video Applications).
RAQMON MIBは、上記で定義されたRAQMONパラメータの最小の集合を提供します。 RAQMON MIBは、アプリケーションのパフォーマンス測定（APM）MIB [RFC3729]またはトランスポート・パフォーマンス・メトリック（TPM）MIB [RFC4150]のような大規模な集合を提供するように設計されていません。一つは、プロトコルに基づいて集計のパラメータ（例えば、HTTP、RTPのパフォーマンス）、またはアプリケーション（例えば、VoIPの性能、ビデオアプリケーション）にAPMとTPM MIBを使用する必要があります。
In the RAQMON MIB, aggregation can be performed only on specific RAQMON metric parameters. Aggregation always results in statistical Mean/Min/Max values, according to these definitions:
RAQMON MIBにおいて、凝集は、特定RAQMONメトリックパラメータに行うことができます。集計は、常にこれらの定義によると、統計的な平均値/最小/最大値になり：
Mean: Mean is defined as the statistical average of a metric over the duration of a communication session. For example, if an RDS reported End-to-End delay metric N times within a communication session, then the Mean End-to-End Delay can be computed by summing of these N reported values, and then dividing by N.
平均値：平均は、通信セッションの持続時間にわたってメトリックの統計的平均として定義されます。 RDSは、通信セッション内のエンドツーエンド遅延をメトリックN回を報告した場合、その後、平均エンドツーエンド遅延は、これらのNを加算することによって計算することができる値を報告し、その後、Nで割ます
Min: Min is defined as the statistical minimum of a metric over the duration of a communication session. For example, if the end-to-end delay metric of an end-device within a communication session is reported N times by the RDS, then the Min end-to-end delay is the smallest of the N end-to-end delay metric values reported.
分：分は、通信セッションの持続時間にわたってメトリックの統計的最小値として定義されます。通信セッション内のエンドデバイスのエンドツーエンド遅延メトリックはRDSによってN回報告されている場合、例えば、次に最小のエンドツーエンド遅延は、N個のエンドツーエンド遅延の最も小さいですメトリック値を報告しました。
Max: Max is defined as the statistical maximum of a metric over the duration of a communication session. For example, if the end-to-end delay metric of an end-device within a communication session is reported N times by the RDS, then the Max End-to-End Delay is the largest of the N End-to-End Delay metric values reported.
最大：最大は、通信セッションの持続時間にわたってメトリックの統計的最大値として定義されます。通信セッション内のエンドデバイスのエンドツーエンド遅延メトリックはRDSによってN回報告されている場合、例えば、次に最大エンドツーエンド遅延は、Nエンドツーエンド遅延の最大でありますメトリック値を報告しました。
It is evident from the document that the RAQMON MIB data need to be managed to optimize storage space. The large volume of data gathered in a communication session could be optimized for storage space by performing and storing only aggregated RAQMON metrics for history if required.
それはRAQMON MIBデータは、ストレージスペースを最適化するために管理する必要がある文書から明らかです。通信セッションで収集されたデータの大容量が実行し、必要に応じて履歴のためにのみ集約RAQMONメトリクスを記憶することによって記憶空間のために最適化することができます。
Examples of how such storage space optimization can be performed include:
実行することができる方法なストレージスペースの最適化の例としては、
1. Make data available through the MIB only at the end of a communication session, i.e., upon receipt of a NULL PDU. The aggregated data could be made available using the RAQMON MIB as Mean, Max, or Min entries and saved for historical purposes.
1. NULLのPDUを受信すると、即ち、唯一の通信セッションの終了時にMIBを介してデータを利用できるようにします。集約されたデータは、平均値、最大値、又は最小エントリとしてRAQMON MIBを使用して利用可能になると歴史的な目的のために保存することができます。
2. Use a time-based algorithm that aggregates data over a specific period of time within a communication session, thus requiring fewer entries, to reduce storage space requirements. For example, if an RDS sends data out every 10 seconds and the RRC updates the RAQMON MIB once every minute, for every 6 data points there would be one MIB entry.
2.ストレージ・スペース要件を低減するために、このように少数のエントリを必要とする、通信セッション内の特定の期間にわたってデータを集計時間ベースのアルゴリズムを使用します。 RDSは、10秒ごとにデータを送信し、RRCが1分ごとにRAQMON MIBを更新した場合、すべての6つのデータポイントの1つのMIBエントリが存在することになります。
3. Periodically delete historical data in accordance with an administrative policy. An example of such a policy would be to delete historical data older than 60 days. The implementation of such policies is left to the application developer's discretion, and their use is an operational concern.
3.定期的な管理ポリシーに従って履歴データを削除します。そのようなポリシーの例は、60日よりも古い履歴データを削除することです。こうした政策の実施は、アプリケーション開発者の裁量に任され、そしてそれらの使用は、動作の関心事です。
Security considerations associated with the RAQMON Framework are discussed below, and in greater detail in other RAQMON memos as is appropriate.
RAQMONフレームワークに関連するセキュリティ上の考慮事項を以下に説明し、他のRAQMONメモに詳細に適切であるようにされています。
The vulnerabilities associated with the RAQMON Framework are a combination of those associated with the underlying layers up to the transport layer, and of possible exploits of RAQMON payload. Possible exploits of RAQMON payloads fall within these classes:
RAQMONフレームワークに関連した脆弱性は、トランスポート層まで、及びRAQMONペイロードの可能な悪用の下の層に関連するものの組み合わせです。 RAQMONペイロードの可能性悪用は、これらのクラスに入ります：
1. Unauthorized examination of sensitive information in the payload in transit.
輸送中のペイロードにおける機密情報の無断1.検査。
2. Unauthorized modification of payload contents in transit, leading to:
につながる2.輸送中のペイロードの内容の無断変更、：
a. Mis-identification of information from one RAQMON reporting session as belonging to another destined to the same RRC;
A。同じRRC宛別に属するものとして、セッションを報告1 RAQMONからの情報の誤識別。
b. Mismapping of RAQMON sessions;
B。 RAQMONセッションのMismapping。
c. Various forms of session-level denial-of-service (DoS) attacks;
C。セッションレベルサービス拒否（DoS）攻撃の様々な形。
d. DoS through modification of RAQMON parameter values and statistics;
D。 RAQMONパラメータ値と統計情報の変更によるDoS攻撃。
e. Invalid timestamps, leading to false interpretation of the monitored data, affecting call records information, and making difficult to place monitoring events in their appropriate temporal context.
電子。無効なタイムスタンプ、監視データの誤った解釈につながる通話記録情報に影響を与え、そしてその適切な一時的な文脈での監視イベントを配置することが困難になります。
3. Malformed payloads, permitting the exploitation of potential implementation weaknesses to compromise an RRC.
3.不正なペイロードは、潜在的な実装の弱点の利用を許可することはRRCを危うくします。
4. Unauthorized disclosure of sensitive data carried by application PDUs, leading to a breach of confidentiality.
守秘義務の違反につながるアプリケーションのPDUによって運ばれる機密データ、の4不正な開示。
Consequently, threats based on unauthorized disclosure or modification of payloads or headers will have to be assumed.
その結果、不正な開示またはペイロードまたはヘッダの修正に基づいて脅威を想定する必要があります。
In order to preserve integrity of the RAQMON PDU against these threats, the RAQMON model must provide for cryptographically strong security services.
これらの脅威に対するRAQMON PDUの整合性を維持するためには、RAQMONモデルは、暗号強度の高いセキュリティサービスを提供しなければなりません。
Consequently, the RAQMON framework must be able to provide for the following protections:
その結果、RAQMONフレームワークは、以下の保護のために提供することができなければなりません。
1. Authentication - the RRC should be able to verify that a RAQMON PDU was in fact originated by the RDS that claims to have sent it.
1.認証 - RRCはRAQMON PDUが実際にそれを送信したと主張RDSによって発信されたことを確認することができなければなりません。
2. Privacy - Since RAQMON information includes identification of the parties participating in a communication session, the RAQMON framework should be able to provide for protection from eavesdropping, to prevent an unauthorized third party from gathering potentially sensitive information. This can be achieved by using various payload encryption technologies, such as Data Encryption Standard (DES), 3-DES, Advanced Encryption Standard (AES), etc.
2.プライバシー - RAQMON情報が通信セッションに参加している当事者の識別情報を含むので、RAQMONフレームワークは、潜在的に機密情報を収集からの権限のない第三者を防止するために、盗聴からの保護を提供することができなければなりません。これ等データ暗号化規格（DES）、3-DES、高度暗号化標準（AES）などの様々なペイロードの暗号化技術を使用することによって達成することができます
3. Protection from DoS attacks directed at the RRC - RDSs send RAQMON reports as a side effect of an external event (for example, a phone call is being received). An attacker can try to overwhelm the RRC (or the network) by initiating a large number of events (i.e., calls) for the purpose of swamping the RRC with too many RAQMON PDUs.
RRCに向けDoS攻撃から3の保護 - のRDSは、外部イベントの副作用としてRAQMONレポートを送信（例えば、電話呼が受信されています）。攻撃者は、あまりにも多くのRAQMON PDUのでRRCを圧倒する目的のために多数のイベント（すなわち、通話）を開始することによって、RRC（またはネットワーク）を圧倒しようとすることができます。
To prevent DoS attacks against RRC, the RDS will send the first report for a session only after the session has been in progress for the five-second reporting interval. Sessions shorter than that should be stored in the RDS and will be reported only after that interval has expired.
RRCに対するDoS攻撃を防ぐために、RDSはセッションが5秒のレポート間隔のために進んでいるだけで後にセッションのための最初のレポートをお送りします。それよりも短いセッションはRDSに格納する必要があり、その間隔が経過した後にのみ報告されます。
The RAQMON architecture permits the use of multiple transport protocols. Most of these support a secure mode of operation. There are advantages to relying on the security provided at the transport protocol layer.
RAQMONアーキテクチャは、複数のトランスポートプロトコルを使用することが可能になります。これらのほとんどは、セキュアな動作モードをサポートしています。トランスポートプロトコル層で提供されるセキュリティに頼ることには利点があります。
1. Transport-protocol-level security can generally protect the payload with end-to-end authentication, confidentiality, message integrity, and replay protection services.
1.トランスポートプロトコルレベルのセキュリティは、一般的に、エンドツーエンドの認証、機密性、メッセージの完全性、およびリプレイ保護サービスとペイロードを保護することができます。
2. A good cryptographic security protocol always has an associated key management protocol. Use of transport protocol security relies on its key management and does not require development of another mechanism.
2.優れた暗号化セキュリティプロトコルは、常に関連する鍵管理プロトコルを持っています。トランスポート・プロトコル・セキュリティを使用すると、その鍵管理に依存していると別のメカニズムの開発を必要としません。
3. When transport protocol security is already enabled between the RDS and RRC, additional encryption and message authentication at the application level is avoided.
トランスポートプロトコルのセキュリティがすでにRDSとRRCの間で有効になっている場合は3、アプリケーションレベルで追加の暗号化およびメッセージ認証が回避されます。
However, there are also shortcomings to be noted in relying on transport protocol security.
しかし、トランスポートプロトコルのセキュリティに頼るに記載される欠点もあります。
1. When session-level isolation of the different RAQMON sessions of an RDS-RRC pair is required, it will be necessary to open separate transport protocol instances. Such cases, however, may be rare.
RDS-RRC対の異なるRAQMONセッションのセッション・レベルの分離が必要な場合は1、別のトランスポートプロトコルインスタンスを開くために必要であろう。このような例は、しかし、珍しいかもしれません。
2. Since security services are not provided by the RAQMON framework, the absence of transport or lower protocol security implies the absence of RAQMON security.
2.セキュリティサービスはRAQMONフレームワークによって提供されていないので、輸送または下位プロトコルセキュリティの欠如はRAQMONセキュリティが存在しないことを意味しています。
The authors would like to thank Andy Bierman, Alan Clark, Mahalingam Mani, Colin Perkins, Steve Waldbusser, Magnus Westerlund, and Itai Zilbershtein for the precious advices and real contributions brought to this document. The authors would also like to extend special thanks to Randy Presuhn, who reviewed this document for spelling and formatting purposes, and who provided a deep review of the technical content. We also would like to thank Bert Wijnen for the permanent coaching during the evolution of this document and the detailed review of its final versions.
著者は、この文書にもたらさ貴重なアドバイスや実際の貢献のためにアンディBierman、アラン・クラーク、Mahalingamマニ、コリンパーキンス、スティーブWaldbusser、マグヌスウェスター、と板井Zilbershteinに感謝したいと思います。著者らはまた、スペルや書式の目的のために、この文書を検討し、技術的な内容の深いレビューを提供ランディPresuhn、に特別な感謝を拡張したいと思います。また、このドキュメントの進化とその最終版の詳細なレビュー中に永久コーチングのためのバートWijnenに感謝したいと思います。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "一方向IPPMの遅延メトリック"、RFC 2679、1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "IPPMための一方向パケット損失メトリック"、RFC 2680、1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "IPPMのラウンドトリップ遅延メトリック"、RFC 2681、1999年9月。
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000.
[RFC2819] Waldbusser、S.、 "リモートネットワーク監視管理情報ベース"、STD 59、RFC 2819、2000年5月。
[RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time Transport Protocol Management Information Base", RFC 2959, October 2000.
[RFC2959] Baugher、M.、Strahm、B.、およびI. Suconick、 "リアルタイムトランスポートプロトコル管理情報ベース"、RFC 2959、2000年10月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]デミチェリス、C.およびP. Chimento、 "IPパフォーマンス・メトリックのためのIPパケット遅延変動メトリック（IPPM）"、RFC 3393、2002年11月。
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416] Presuhn、R.、エド。、STD 62、RFC 3416、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2"。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinneと、H.とS. Casner、 "最小量のコントロールがあるオーディオとビデオ会議システムのためのRTPプロフィール"、STD 65、RFC 3551、2003年7月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[RFC3235] Senie、D.、 "ネットワークアドレス変換（NAT）フレンドリアプリケーションの設計ガイドライン"、RFC 3235、2002年1月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]フリードマン、T.、カセレス、R.、およびA.クラーク、 "RTP制御プロトコル拡張レポート（RTCP XR）"、RFC 3611、2003年11月。
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004.
[RFC3729] Waldbusser、S.、 "アプリケーションのパフォーマンス測定MIB"、RFC 3729、2004年3月。
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005.
[RFC4150]ディーツ、R.とR.コール、 "交通パフォーマンス・メトリックMIB"、RFC 4150、2005年8月。
[RFC4711] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON) MIB", RFC 4711, October 2006.
[RFC4711] Siddiqui著、A.、Romascanu、D.、およびE. Golovinsky、 "リアルタイムアプリケーションサービス品質のモニタリング（RAQMON）MIB"、RFC 4711、2006年10月。
[RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Ramhman, M., and Y. Kim, "Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)", RFC 4712, October 2006.
[RFC4712] Siddiqui著、A.、Romascanu、D.、Golovinsky、E.、Ramhman、M.、およびY.キム、「トランスポートマッピングリアルタイムのアプリケーションサービス品質モニタリング（RAQMON）プロトコルデータユニット（PDU ）」、RFC 4712、2006年10月。
[IEEE802.1D] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common Specification a - Media access control (MAC) bridges:15802-3: 1998 (ISO/IEC). Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e [ANSI/IEEE Std 802.1D, 1998 Edition]
[IEEE802.1D]情報技術 - システム間のテレコミュニケーションと情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - メディアアクセス制御（MAC）ブリッジ：15802-3：1998（ISO / IEC）。リビジョン。 1993年、802.1j-1992と802.6k-1992：これは、ISO / IEC 10038の改訂版です。それは組み込まれてP802.11c、P802.1pとP802.12e [ANSI / IEEE規格802.1D、1998年版]
Authors' Addresses
著者のアドレス
Anwar A. Siddiqui Avaya Labs 307 Middletown Lincroft Road Lincroft, New Jersey 07738 USA
アンワルA. Siddiquiはアバイア研究所307ミドルリンクロフト道路リンクロフト、ニュージャージー州07738米国
Phone: +1 732 852-3200 EMail: anwars@avaya.com
電話：+1 732 852-3200 Eメール：anwars@avaya.com
Dan Romascanu Avaya Atidim Technology Park, Building #3 Tel Aviv, 61131 Israel
ダンromaskenumアバイアatidima tecanoloji公園、ビル＃3、テルアビブ、イスラエル61131
Phone: +972-3-645-8414 EMail: dromasca@avaya.com
電話：+ 972-3-645-8414 Eメール：dromasca@avaya.com
Eugene Golovinsky
ユージンGolovinsky
EMail: gene@alertlogic.net
メールアドレス：gene@alertlogic.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。