[要約] RFC 4710は、リアルタイムアプリケーションの品質監視のためのフレームワークであり、RAQMONと呼ばれます。その目的は、ネットワーク上でのアプリケーションの品質を監視し、問題を特定することです。
Network Working Group A. Siddiqui
Request for Comments: 4710 D. Romascanu
Category: Standards Track Avaya
E. Golovinsky
Alert Logic
October 2006
Real-time Application Quality-of-Service Monitoring (RAQMON) Framework
リアルタイムアプリケーションサービス品質監視（RAQMON）フレームワーク
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
There is a need to monitor end-devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications.
IPフォン、ポケットベル、インスタントメッセージングクライアント、携帯電話、その他のさまざまなハンドヘルドコンピューティングデバイスなどのエンドデバイスを監視する必要があります。このメモは、リモートネットワーク監視（RMON）仕様ファミリを拡張して、これらのデバイスで実行されるさまざまなアプリケーションのリアルタイム品質（QOS）監視を可能にし、この情報を単純なネットワークを使用して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）の目標が満たされるようにするために、これらのアプリケーションとデバイスの種類を監視する必要があります。このメモは、これらの環境の監視ソリューションについて説明し、リモートネットワーク監視（RMON）仕様ファミリを拡張します[RFC2819]。これらの拡張機能は、上記のエンドデバイスで実行される典型的なアプリケーションのリアルタイムQoSモニタリングをサポートし、SNMP [RFC3416]を介して馴染みのあるRMONファミリーの仕様を使用してこの情報を統合することを可能にします。
The Real-time Application QoS Monitoring Framework (RAQMON) allows end-devices and applications to report QoS statistics in real time. Many real-time applications (as well as non-real-time applications managed within the RMON family of specifications) can report application-level QoS statistics in real time using the RAQMON Framework outlined in this memo. Some possible applications scenarios include applications such as Voice over IP, Fax over IP, Video over IP, Instant Messaging (IM), Email, software download applications, e-business style transactions, web access from handheld computing devices, etc.
リアルタイムアプリケーションQoS監視フレームワーク（RAQMON）を使用すると、エンドデバイスとアプリケーションがQoS統計をリアルタイムで報告できます。多くのリアルタイムアプリケーション（および仕様のRMONファミリー内で管理されている非リアルタイムアプリケーション）は、このメモに概説されているRaqmonフレームワークを使用して、アプリケーションレベルのQoS統計をリアルタイムで報告できます。いくつかの可能なアプリケーションシナリオには、Voice Over IP、Fax Over IP、ビデオオーバーIP、インスタントメッセージング（IM）、電子メール、ソフトウェアダウンロードアプリケーション、E-BusiessIness Styleトランザクション、ハンドヘルドコンピューティングデバイスからの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 End-Deviceで実行されているアプリケーションのユーザーエクスペリエンスは、ユーザーが実行しているアプリケーションのタイプと、そのアプリケーションで利用可能な周囲のリソースによって異なります。エンドツーエンドアプリケーションQoSエクスペリエンスは、さまざまなアプリケーションレベルのトランザクションと利用可能なネットワークおよびホストリソースの複合効果です。たとえば、Voice over IP（VoIP）コールのエンドツーエンドユーザーエクスペリエンスは、エンドツーエンドネットワーク遅延などのメディア関連のパフォーマンスパラメーターと同様に、コールを設定するのに必要な合計時間に依存します。ジッター、パケット損失、およびコールで使用されるコーデックの種類。VOIPコールのパフォーマンスは、予約プロトコル（RSVP）、差別化されたサービス（DIFFSERV）[RFC2475]またはIEEE 802.1 [IEEE802.1D]の明示的なタグなどのネットワークプロトコルの動作と、デバイスCPUなどの利用可能な宿主リソースなどの動作にも影響されます。または、コールが進行中に他のアプリケーションによって使用されるメモリ。
The end-to-end application quality of service (QoS) experience is application context sensitive. For example, the kinds of parameters reported by an IP telephony application may not really be needed for other applications such as Instant Messaging. The RAQMON Framework 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フレームワークは、事前定義されたリストからメトリックのサブセットを報告するメカニズムを提供することにより、特定のアプリケーションコンテキストに適したエンドツーエンドQoSエクスペリエンスを報告するメカニズムを提供します。
In order to facilitate a complete end-to-end view, RAQMON correlates statistics that involve:
完全なエンドツーエンドビューを容易にするために、Raqmonは次のことを伴う統計を相関させます。
i. "User, Application, Session"-specific parameters (e.g., session setup time, session duration parameters based on application context).
i. 「ユーザー、アプリケーション、セッション」特異的パラメーター（例：セッションのセットアップ時間、アプリケーションコンテキストに基づくセッション期間パラメーター）。
ii. "IP end-device"-specific parameters during a session (e.g., CPU usage, memory usage).
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フレームワークは次のことを指定します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 Report Collector（RRC）
- RAQMON MIB Structure
- Raqmon MIB構造
A RAQMON Data Source (RDS) is a functional component that acts as a source of data for monitoring purposes. End-devices like IP phones, cell phones, and pagers, and application clients like instant messaging clients, soft phones in PCs, etc., are envisioned to act as RDSs within the RAQMON Framework.
RAQMONデータソース（RDS）は、監視目的のためのデータソースとして機能する機能コンポーネントです。IP電話、携帯電話、ポテンツ、インスタントメッセージングクライアント、PCのソフトフォンなどのアプリケーションクライアントなどのエンドデバイスは、RAQMONフレームワーク内のRDSとして機能することを想定しています。
+----------------------+ +---------------------------+
| IP End-Device | | IP End-Device >----+ |
|+--------------------+| |+--------------------+ | |
|| APPLICATION || || APPLICATION | | |
|| -Voice over IP <----(1)----> -Voice over IP >- + | |
|| -Instant Messaging|| || -Instant Messaging| | 3 |
|| -Email || || -Email | 2 | |
|+--------------------+| |+--------------------+ | | |
| | | | | |
| | | +------------------+ | | |
+----------------------+ | |RAQMON Data Source|<-+ | |
| | (RDS) |<---+ |
| +------------------+ |
+-----------|---------------+
|
(4) RAQMON PDU transported
over TCP or SNMP Notifications
|
+----------------------------+
| |
|/ |/
+------------------+ +------------------+ +------------+
|RAQMON Report | .. |RAQMON Report | | Management |
|Collector (RRC) #n| |Collector (RRC) #1|<--5-->| Application|
+------------------+ +------------------+ +------------+
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) 管理アプリケーション-RaqmonMIBを使用したRRC相互作用
A RAQMON Report Collector (RRC) collects statistics from multiple RDSs, analyzes them, and stores such information appropriately. RRC is envisioned to be a network server, serving an administrative domain defined by the network administrator. The RRC component of the RAQMON architecture is envisioned to be computationally resourceful. Only RRCs should implement the RAQMON MIB module.
RAQMONレポートコレクター（RRC）は、複数のRDSから統計を収集し、それらを分析し、そのような情報を適切に保存します。RRCはネットワークサーバーであると想定されており、ネットワーク管理者によって定義された管理ドメインを提供します。RAQMONアーキテクチャのRRCコンポーネントは、計算的に機知に富んでいると考えられています。RRCのみがRaqmon MIBモジュールを実装する必要があります。
The RAQMON Management Information Base (RAQMON MIB) extends the Remote Monitoring MIB [RFC2819] to accommodate the RAQMON Framework and exposes End-to-End Application QoS information to Network Management Applications.
Raqmon Management Information Base（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.
RDSSはプッシュメカニズムを使用してQoSパラメーターを報告します。RDSで実行されているアプリケーションは、アプリケーションコンテキストに適したPDUのコンテンツについて決定しますが、RDSはレポートをRRCに非同期に送信します。
The rate at which PDUs are sent from RDSs to RRCs is controlled by the applications' administrative domain policy. While this mechanism provides flexibility to gather a detailed end-to-end experience required by IT managers and system administrators, certain steps should be followed to operate RAQMON in congestion-safe manner. Section 3 addresses steps required for congestion-safe operation.
PDUがRDSからRRCに送信されるレートは、アプリケーションの管理ドメインポリシーによって制御されます。このメカニズムは、ITマネージャーとシステム管理者が必要とする詳細なエンドツーエンドエクスペリエンスを収集する柔軟性を提供しますが、RAQMONを渋滞に安全な方法で操作するために、特定の手順に従う必要があります。セクション3では、輻輳安全操作に必要な手順に対処します。
An RDS reports QoS statistics for simplex flows. At a given instance, a report from RDS is logically viewed as a collection of QoS parameters associated with a communication session as perceived by the reporting RDS. For example, if two IP phone users, Alice and John, are involved in a communication session, the end-to-end delay experienced by the IP phone user Alice could be different from the one experienced by the IP phone user John for a variety of reasons. Hence, a report from Alice's IP phone represents the QoS performance of that call as perceived by the RDS that resides in Alice's IP phone.
RDSは、シンプレックスフローのQoS統計を報告しています。特定のインスタンスでは、RDSからのレポートは、レポートRDSによって知覚される通信セッションに関連付けられたQoSパラメーターのコレクションと論理的に見られます。たとえば、2人のIP電話ユーザー、AliceとJohnがコミュニケーションセッションに関与している場合、IP電話ユーザーのAliceが経験するエンドツーエンドの遅延は、IP電話ユーザーJohnがさまざまなために経験したものとは異なる可能性があります。理由の。したがって、AliceのIP電話からのレポートは、AliceのIP電話にあるRDSが知覚したその呼び出しのQoSパフォーマンスを表しています。
1. RAQMON Data Sources SHALL gather reports from multiple applications residing in that device and SHALL send out compound QoS reports associated with multiple communication sessions at a given moment.
1. Raqmonデータソースは、そのデバイスに居住する複数のアプリケーションからレポートを収集し、特定の瞬間に複数の通信セッションに関連する複合QoSレポートを送信するものとします。
Examples include a conference bridge hosting several different conference calls or a two-party video call consisting of audio/video sessions. In each case an RDS could send out one single RAQMON report that consists of multiple sub-reports associated with audio and video sessions or sub-reports for each conference call.
例には、いくつかの異なる電話会議またはオーディオ/ビデオセッションで構成される2パーティのビデオ通話をホストするカンファレンスブリッジが含まれます。いずれの場合も、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レポートコレクターに統計を報告するには、RDSSを次のパラメーターで構成する必要があります。
1. The time interval between RAQMON PDUs. This parameter MUST be configured such that overflow of any RAQMON parameter within a PDU between consecutive transmissions is avoided.
1. Raqmon PDU間の時間間隔。このパラメーターは、連続した送信間のPDU内のRaqmonパラメーターのオーバーフローが回避されるように構成する必要があります。
2. The IP address and port of target RRC.
2. ターゲットRRCのIPアドレスとポート。
An RDS may use manual configuration for the RDS configuration parameters using command line interface (CLI), Telephone User Interface (TUI), etc.
RDSは、コマンドラインインターフェイス（CLI）、電話ユーザーインターフェイス（TUI）などを使用して、RDS構成パラメーターに手動構成を使用できます。
One of the following mechanisms to gain access to configuration parameters can also be considered:
構成パラメーターにアクセスするための次のメカニズムの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 Report Collector（RRC）は、複数のRDSからRaqmon PDUを受け取り、Raqmon MIBに情報を分析および保存します。RRCは計算的に機知に富んでいると想定されており、RDSSのセットにストレージと集約点を提供します。
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.
RDSSは別々の管理ドメインに属する可能性があるため、RAQMONフレームワークにより、RDSSはQOSパラメーターを報告してRRCを分離できます。ベンダーは、複数の管理ドメインにまたがるさまざまなRRCに存在する情報を相関させるための管理アプリケーションを開発して、1つの通信セッションを表すことができます。ただし、このようなアプリケーションレベルの仕様は、このメモの範囲を超えています。
1. RAQMON Report Collectors MUST support the mandatory mapping over TCP of the RAQMON information model defined in [RFC4712] with the purpose of receiving RAQMON reports from RAQMON Data Sources (RDS).
1. RAQMONレポートコレクターは、RAQMONデータソース（RDS）からRAQMONレポートを受信する目的で、[RFC4712]で定義されているRAQMON情報モデルのTCPを介した必須マッピングをサポートする必要があります。
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 Report Collectorは、合理的な期間レポートを外してきた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モジュールコンプライアンス定義のコンプライアンス要件を満たす必要があります。パフォーマンス監視情報を備えたRaqmon MIBの母集団は、輸送プロトコル、またはRDSとRRCの間の情報を伝達するために使用されるプロトコルとは無関係です。
RAQMON defines a set of basic metrics that characterize the QoS of applications, as reported by RAQMON Data Sources. This basic set of metrics is defined in Section 5 of this memo. There is no minimal requirement for a mandatory set of metrics to be supported by an RDS.
RAQMONは、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.
特定のアプリケーション、新しいタイプのネットワークアプライアンス、またはアプリケーションのQOを測定および特徴付ける新しい方法は、情報モデルが拡張可能になるための要件につながります。このニーズに答えるために、情報モデルは、ベンダーが新しいメトリックを追加することで拡張できるように設計されています。
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とRRCが理解する一般的なデータ形式です。RAQMON PDUは、アプリケーションデータを輸送するのではなく、プロトコルスタックのアプリケーションレイヤーでペイロード仕様の場所を占有します。RDSとRRCの間でRaqmon PDUを運ぶために、さまざまな輸送マッピングを使用できます。輸送プロトコルの要件は、このメモのセクション2.4で定義されています。
Though architected conceptually as a single PDU, the RAQMON PDU is functionally divided into two different parts. They are the BASIC part, and the Application-Specific Extensions, required for application-, vendor-, and device-specific extensions.
概念的に単一の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 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.
Raqmon PDUの基本部分：Raqmon PDUの基本部分は、SMIネットワーク管理プライベートエンタープライズコード0に従い、IETF標準コンストラクトを示しています。RAQMON PDU BASICパーツは、セクション5で定義されたQOSパラメーターの事前定義されたリストのエントリタイプを提供し、アプリケーションがそれらのパラメーターの適切な値を入力できるようにします。また、アプリケーション開発者は、セクション5にリストされているパラメーターのサブセットのみでRDSレポートを作成する柔軟性を持っています。すべてのPDUにすべてのメトリックを携帯する必要はありません。さらに、特定のセッションまたはアプリケーションの変更またはめったに変更されない静的または擬似静的メトリックは、セッションまたはアプリケーションが開始された場合にのみ送信されることをお勧めします。
The Application part of RAQMON PDU: Since it is difficult to structure a BASIC part that meets the needs of all applications, RAQMON provides extension capabilities to convey application-, vendor-, and device-specific parameters for future use. Additional parameters can be defined within payload of the APP part of the PDU by the application developers or vendors. The owner of the definition of the application part of the RAQMON PDU is indicated by a vendor's SMI Network Management Private Enterprise Code defined in http://www.iana.org/assignments/enterprise-numbers. Such application-specific extensions should be maintained and published by the application vendor.
Raqmon PDUのアプリケーション部分：すべてのアプリケーションのニーズを満たす基本的な部分を構築することは困難であるため、Raqmonは、将来の使用のためのアプリケーション、ベンダー、およびデバイス固有のパラメーターを伝えるための拡張機能を提供します。追加のパラメーターは、アプリケーション開発者またはベンダーによってPDUのアプリ部分のペイロード内で定義できます。RAQMON PDUのアプリケーション部分の定義の所有者は、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).
RDSSとRRCは、レポートセッション全体でステートレスになるように設計されていますが、フレームワークにはレポートの終了を示す必要があります。この目的のために、RDSはRaqmon Null PDUを送信する必要があります。ヌルPDUは、すべてのヌル値を含むRaqmon PDUです（つまり、報告するものはありません）。
The RAQMON PDUs rely on the underlying protocol(s) to provide transport functionalities and other attributes of a transport protocol, e.g., transport reliability, re-transmission, error correction, length indication, congestion safety, fragmentation/defragmentation, etc. The maximum length of the RAQMON data packet is limited only by the underlying protocols.
RAQMON PDUSは、基礎となるプロトコルに依存して、輸送プロトコルの輸送機能やその他の属性、たとえば輸送の信頼性、再送信、エラー修正、長さの適応、混雑の安全性、断片化/解凍などを提供します。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の軽量実装を可能にする必要があります。RDSSは、限られたデバイスリソースを備えた低電力埋め込みデバイスに実装されます。
2. Scalability - Since RRCs need to interact with a very large number (many tens, many hundreds, or more) of RDSs, scalability of the transport protocol is REQUIRED.
2. スケーラビリティ - RRCは非常に多数（多くの数十、数百以上）のRDSと相互作用する必要があるため、輸送プロトコルのスケーラビリティが必要です。
3. Congestion safety - as per [RFC2914]. See also Section 3.
3. 混雑の安全性 - [RFC2914]による。セクション3も参照してください。
4. Security - Since RAQMON statistics may carry sensitive system information requiring protection from unauthorized disclosure and modification in transit, a transport protocol that provides strong secure modes or allows for data encryption and integrity to be applied is REQUIRED.
4. セキュリティ - RAQMON統計には、強力な安全なモードを提供する輸送プロトコル、またはデータの暗号化と整合性を適用できるようにする輸送プロトコルが必要な輸送プロトコルが必要な輸送プロトコルが必要であるため、RAQMON統計には機密システム情報が搭載される場合があります。
5. NAT-Friendly - The transport protocol SHOULD comply with [RFC3235], so that an RDS could communicate with an RRC through a Firewall/Network Address Translation device.
5. NATフレンドリー - トランスポートプロトコルは[RFC3235]に準拠する必要があります。これにより、RDSはファイアウォール/ネットワークアドレス翻訳デバイスを介してRRCと通信できます。
6. The transport protocol MAY implement session timeout mechanisms to assume end of reporting for RDSs that have been out of reporting for a reasonable duration of time. Such timeout parameters SHOULD be configurable in vendor implementations, programmable at deployment.
6. トランスポートプロトコルは、セッションタイムアウトメカニズムを実装して、妥当な期間報告を受けていないRDSの報告の終了を想定する場合があります。このようなタイムアウトパラメーターは、ベンダーの実装で構成可能で、展開時にプログラム可能です。
7. Reliability - The RAQMON Framework expects PDUs to operate in lossy networks. However, retransmission is not included in the RAQMON framework, in order to keep the design simple. If retransmission is a necessity, RAQMON MAY operate over transport protocols, such as TCP.
7. 信頼性 - RAQMONフレームワークは、PDUが損失のあるネットワークで動作することを期待しています。ただし、設計をシンプルに保つために、再送信はRaqmonフレームワークには含まれていません。再送信が必要な場合、RaqmonはTCPなどの輸送プロトコルを介して動作する場合があります。
In the future, if RAQMON PDUs are to be carried in an underlying protocol that provides the abstraction of a continuous octet stream rather than messages (packets), an encapsulation for the RAQMON packets must be defined to provide a framing mechanism. Framing is also needed if the underlying protocol contains padding so that the extent of the RAQMON payload cannot be determined. No framing mechanism is defined in this document. Carrying several RAQMON packets in one network or transport packet reduces header overhead.
将来的には、Raqmon PDUがメッセージ（パケット）ではなく連続的なオクテットストリームの抽象化を提供する基礎となるプロトコルで運ばれる場合、Raqmonパケットのカプセル化を定義してフレーミングメカニズムを提供する必要があります。基礎となるプロトコルにパディングが含まれている場合は、Raqmonペイロードの範囲を決定できない場合もフレーミングが必要です。このドキュメントでは、フレーミングメカニズムは定義されていません。1つのネットワークまたはトランスポートパケットにいくつかのRAQMONパケットを運ぶと、ヘッダーのオーバーヘッドが減少します。
Further memos like [RFC4712] describe how the PDU is transported over existing protocols like the Transmission Control Protocol (TCP) or the Simple Network Management Protocol (SNMP).
[RFC4712]のようなさらなるメモは、伝送制御プロトコル（TCP）や単純なネットワーク管理プロトコル（SNMP）などの既存のプロトコルに対してPDUがどのように輸送されるかを説明しています。
RAQMON PDUs can be transmitted over multiple transport protocols. The RAQMON Framework will be congestion safe, if a RAQMON PDU is transported over TCP.
Raqmon PDUは、複数の輸送プロトコルに送信できます。Raqmon PDUがTCPを介して輸送される場合、Raqmonフレームワークは渋滞になります。
One solution to the congestion awareness problem could have been to discourage the use of UDP entirely for RAQMON. Though RAQMON PDUs can be transported over TCP, some transports like SNMP over TCP are not commonly practiced in practical deployments.
渋滞の認識の問題に対する解決策の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などの輸送プロトコルは、根底にあるRaqmon PDU輸送としても使用できます。これは、混雑制御を備えたUDPスタイルのデータグラム伝送の柔軟性を提供します。
It should be noted that the congestion problem is not just between RDS and RRC pairs, but whenever there is a high fan-in ratio, congestion could occur (e.g., many RDSs reporting to an RRC). Within the RAQMON Framework using UDP as a transport, congestion safety can be achieved in following ways:
混雑の問題は、RDSとRRCペアの間だけでなく、ファンイン比が高い場合はいつでも、うっ血が発生する可能性があることに注意する必要があります（たとえば、RRCに報告する多くのRDSS）。輸送としてUDPを使用したRaqmonフレームワーク内で、次の方法で混雑の安全性を達成できます。
1. Constant Transmission Rate: In a well-managed network, a constant transmission rate policy (e.g., 1 RAQMON PDU per device every N seconds) will ensure congestion safety as devices are introduced into the network in a controlled manner. For example, in an enterprise network, IP Phones are added in a controlled manner, and a constant transmission rate policy can be sufficient to ensure congestion-safe operation. The configured rate needs to be related to the expected peak number of devices. As a worst-case scenario, if the RDSs enforce an administrative policy where the maximum PDU transmission rate is no more than one RAQMON PDU every two minutes, a UDP-based implementation can be as congestion safe as a TCP-based implementation. Such policies can be enforced while configuring RDSs, and the timers for the constant rate need to be randomly jittered.
1. 一定の伝送速度：適切に管理されたネットワークでは、一定の伝送速度ポリシー（たとえば、n秒ごとにデバイスごとに1 raqmon PDU）が、デバイスが制御された方法でネットワークに導入されるため、混雑の安全性を確保します。たとえば、エンタープライズネットワークでは、IP電話が制御された方法で追加され、渋滞に安全な操作を確保するのに一定の伝送速度ポリシーで十分です。構成されたレートは、予想されるピーク数のデバイスに関連する必要があります。最悪のシナリオとして、RDSSが最大PDU伝送レートが2分ごとに1つのRaqmon PDU以下である管理ポリシーを実施する場合、UDPベースの実装はTCPベースの実装と同じくらい渋滞になります。このようなポリシーは、RDSを構成する際に実施することができ、一定の速度のタイマーはランダムにジッタ化する必要があります。
2. Single outstanding requests: This approach requires that a request be sent at the application level, then there is a wait for some sort of response indicating that the request was received before sending anything else. This produces an effect described by some as "ping-ponging": traffic bounces back and forth between two nodes like a ping-pong ball in a match. Since there's only one ball in play between any two players at any given time, most of the potential for congestion cascades is eliminated. For reliability and efficiency reasons, this technique must include backed-off retransmissions. For example, if RAQMON PDUs are transported using SNMP INFORM PDUs over UDP, a SNMP response from the RRC SHOULD be processed by the RDS to implement this mechanism. [RFC4712] specifies that 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.
2. 単一の未解決のリクエスト：このアプローチでは、リクエストをアプリケーションレベルで送信する必要があります。その後、他のものを送信する前にリクエストが受信されたことを示す何らかの応答を待ちます。これにより、一部の人が「ping-ponging」と説明する効果が生じます。マッチ中のピンポンボールのような2つのノードの間でトラフィックが前後に跳ね返ります。いつでも2人のプレイヤーの間に1つのボールが1つしかないため、混雑カスケードの可能性のほとんどは排除されます。信頼性と効率的な理由のために、この手法にはバックオフ再送信を含める必要があります。たとえば、Raqmon PDUがUDPを介したSNMP情報PDUを使用して輸送される場合、RRCからのSNMP応答をRDSによって処理して、このメカニズムを実装する必要があります。[RFC4712]は、SNMP通知トランスポートマッピングメカニズムが実装されている場合、PDUSを使用することをお勧めし、TRAP PDUを使用することをお勧めしないことを指定します。
This pacing or serialization approach has the side-effect of significantly reducing the maximum throughput, as transmission occurs in only one direction at a time and there is at least a 2xRTT (round-trip time) delay between transmissions. More sophisticated algorithms (such as those in TCP and Stream Control Transmission Protocol (SCTP)) have been developed to address this, and it would be inappropriate to duplicate that work at the application level. Consequently, if greater efficiency is required than that provided by this simple approach, implementers SHOULD use TCP, SCTP, or another such protocol. But if one absolutely must use UDP, this approach works. It has been also used in other application scenarios like SIP over UDP.
このペーシングまたはシリアル化アプローチは、一度に1つの方向でのみ伝送が発生し、透過間に少なくとも2xRTT（往復時間）遅延があるため、最大スループットを大幅に削減する副作用があります。より洗練されたアルゴリズム（TCPおよびストリーム制御伝送プロトコル（SCTP）などのアルゴリズムがこれに対処するために開発されており、アプリケーションレベルでその作業を複製することは不適切です。その結果、この単純なアプローチで提供されるものよりも大きな効率が必要な場合、実装者はTCP、SCTP、またはそのようなプロトコルを使用する必要があります。ただし、UDPを絶対に使用する必要がある場合、このアプローチは機能します。また、UDP上のSIPなどの他のアプリケーションシナリオでも使用されています。
3. By restricting transmission to a maximum transmission unit (MTU) size: An RDS may be faced with a request to deliver a large message using UDP as a transport. Fragmentation of such messages is problematic in several ways. Loss of any fragment requires time-out and retransmission of the message. The fragments are commonly transmitted out of the interface at local interface (usually LAN) rates, without awareness of the intervening network conditions. For these reasons, it is generally considered a bad practice to send large PDUs over UDP. If the MTU size is known, as an implementation, an RDS should not allow an application to send more information by limiting the size of transmissions over UDP to reduce the effects of fragmentation. As an alternate, an RDS MAY also send parameters to RRC over multiple RAQMON PDUs but identify them as part of the same RAQMON reporting session with exactly the same Network Time Protocol (NTP) [RFC1305] time stamp.
3. トランスミッションを最大送信ユニット（MTU）サイズに制限することにより：RDSは、輸送としてUDPを使用して大きなメッセージを配信するリクエストに直面する場合があります。そのようなメッセージの断片化は、いくつかの点で問題があります。フラグメントの損失には、メッセージのタイムアウトと再送信が必要です。フラグメントは、介入するネットワーク条件を認識することなく、ローカルインターフェイス（通常はLAN）レートでインターフェイスから一般的に送信されます。これらの理由により、一般に、UDPに大きなPDUを送信することは悪い慣行と考えられています。MTUサイズが実装として知られている場合、RDSは、断片化の影響を減らすためにUDPよりもトランスミッションのサイズを制限することにより、アプリケーションがより多くの情報を送信できるようにしてはなりません。代替として、RDSは複数のRaqmon PDUを介してRRCにパラメーターを送信する場合がありますが、まったく同じネットワークタイムプロトコル（NTP）[RFC1305]タイムスタンプを使用して、同じRaqmonレポートセッションの一部としてそれらを識別します。
While the actual MTU of a link may not be known, common practice seems to indicate that the RDS local interface MTU is likely to be a reasonable "approximation". Where the actual path MTU is known, that value SHOULD be used instead.
リンクの実際のMTUは知られていないかもしれませんが、一般的な慣行は、RDSローカルインターフェイスMTUが合理的な「近似」である可能性が高いことを示しているようです。実際のパスMTUがわかっている場合、その値は代わりに使用する必要があります。
4. Irrespective of choice of transport protocol, it is also RECOMMENDED that no more than 10% network bandwidth be used for RDS/RRC reporting. More frequent reports from an RDS to RRC would imply requirements for higher network bandwidth usage.
4. 輸送プロトコルの選択に関係なく、RDS/RRCレポートには10％以下のネットワーク帯域幅を使用することもお勧めします。RDSからRRCへのより頻繁なレポートは、より高いネットワーク帯域幅使用の要件を暗示しています。
It is not the intent of this document to recommend a methodology to measure any of the QoS parameters defined in Section 5. Measurement algorithms are left to the implementers and equipment vendors to choose. There are many different measurement methodologies available for measuring application performance. These include probe-based, client-based, synthetic-transaction, and other approaches. This specification does not mandate a particular methodology and is open to any methodology that meets the minimum requirements. For conformance to this specification, it is REQUIRED that the collected data match the semantics described herein. However, it is RECOMMENDED that vendors use IETF-defined and International Telecommunication Union (ITU)-specified methodologies to measure parameters when possible.
セクション5で定義されているQoSパラメーターのいずれかを測定する方法論を推奨することは、このドキュメントの意図ではありません。測定アルゴリズムは、選択する実装者と機器ベンダーに任されています。アプリケーションのパフォーマンスを測定するために利用できる多くの異なる測定方法があります。これらには、プローブベース、クライアントベース、合成トランザクション、およびその他のアプローチが含まれます。この仕様は特定の方法論を義務付けるものではなく、最小要件を満たす方法論に対して開かれています。この仕様に準拠するために、収集されたデータは本明細書に記載されているセマンティクスと一致する必要があります。ただし、ベンダーはIETF定義および国際通信連合（ITU）指定の方法論を使用して、可能な場合はパラメーターを測定することをお勧めします。
The BASIC part of the RAQMON PDU provides for a list of pre-defined parameters frequently used by applications to characterize end-to-end application Quality of Service. This section defines a set of simple metrics to be contained in the BASIC part of the RAQMON PDU, through reference to existing IETF, ITU, and other standards organizations' documents. Appropriate IETF or ITU references are included in the metrics definitions.
Raqmon PDUの基本部分は、エンドツーエンドのアプリケーションサービスの品質を特徴付けるためにアプリケーションで頻繁に使用される事前定義されたパラメーターのリストを提供します。このセクションでは、既存のIETF、ITU、およびその他の標準組織のドキュメントを参照して、Raqmon PDUの基本部分に含める単純なメトリックのセットを定義します。適切なIETFまたはITU参照は、メトリック定義に含まれています。
As mentioned earlier, the RAQMON PDU also contains an application-specific part, where application- and vendor-specific information not included in BASIC part can be added as <Name, Value> pairs, or as a variable binding list. These extensions, managed independently by vendors or other organizations, should be published for wider interoperability.
前述のように、Raqmon PDUにはアプリケーション固有の部分も含まれています。このパーツには、基本部品に含まれていないアプリケーションおよびベンダー固有の情報を<name、value>ペア、または可変バインディングリストとして追加できます。ベンダーまたは他の組織によって独立して管理されるこれらの拡張機能は、より広い相互運用性のために公開する必要があります。
Applications are not required to report all the parameters mentioned in this section, but should have the flexibility to report a subset of these parameters appropriate to an application context. The memo further identifies the parameters that RDSs are required to include in all PDUs for compliance, as well as optional parameters that RDSs may report as needed. The definitions presented here are meant to provide guidance to implementers, and IETF metric definition references are provided for each metric. Application developers should choose the metrics appropriate to their applications' needs. Syntactical representations of the parameters identified here are provided in the [RFC4712] specification.
このセクションで記載されているすべてのパラメーターを報告するためにアプリケーションは必要ありませんが、これらのパラメーターのサブセットをアプリケーションコンテキストに適切なサブセットを報告する柔軟性を持つ必要があります。メモは、RDSがコンプライアンスのためにすべてのPDUに含める必要があるパラメーターと、必要に応じてRDSSが報告できるオプションのパラメーターをさらに識別します。ここで紹介する定義は、実装者にガイダンスを提供するためのものであり、各メトリックに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）は、データソースのアドレスです。これは、[RFC1918]で定義されているように、グローバルに一意のIPv4またはIPv6アドレス、または個人的に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は、特定の通信セッション内で一定のままであると予想されます。RDSSは、ネットワークリソースの効率的な使用を確保するために、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）と同じフォームを取得しますが、受信者のアドレスを表します。通信セッションでは、RDSSの報告は、レシーバーアドレスとして相手のアドレスを記入する必要があります。データソースアドレスと同様に、これはグローバルに一意のIPv4またはIPv6アドレス、または[RFC1918]で定義されている個人的に割り当てられたIPv4アドレスのいずれかです。
It is expected that the Receiver Address (RA) would remain constant within a given communication session. RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
受信者アドレス（RA）は、特定の通信セッション内で一定のままであると予想されます。RDSSは、ネットワークリソースの効率的な使用を確保するために、Raqmonレポート内でこれらのパラメーターを頻繁に送信することを避ける必要があります。
The Data Source Name (DN) item could be of various formats as needed by the application. Forms the DN could take include, but are not restricted to:
データソース名（DN）項目は、アプリケーションで必要に応じてさまざまな形式を備えている場合があります。DNが含めることができるフォームですが、以下に制限されていません。
- "user@host", or "host" if a user name is not available as on single-user systems. For both of these formats, "host" is the fully qualified domain name of the host from which the payload originates, formatted according to the rules specified in [RFC1034], [RFC1035], and Section 2.1 of [RFC1123]. Use example names are "big-guy@example.com" or "big-guy@192.0.2.178" for a multi-user system. On a system with no user name, an example would be "ip-phone4630.example.com". It is RECOMMENDED that the standard host's numeric address not be reported via the DN parameter, as the DA parameter is used for that purpose.
- 「user@host」、またはシングルユーザーシステムのようにユーザー名が利用できない場合は「ホスト」。これらの形式の両方について、「ホスト」は、[RFC1034]、[RFC1035]で指定されたルールに従ってフォーマットされた、ペイロードが発生するホストの完全に適格なドメイン名であり、[RFC1123]のセクション2.1です。例の名前を使用すると、マルチユーザーシステムの「bigguy@example.com」または「bigguy@192.0.2.178」です。ユーザー名のないシステムでは、例は「IPPhone4630.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値は、セッション期間中、一定のままであると予想されます。RDSSは、ネットワークリソースの効率的な使用を確保するために、Raqmonレポート内でこれらのパラメーターを頻繁に送信することを避ける必要があります。
The Receiver Name (RN) takes the same form as DN, but represents the Receiver's name. In a communication session, an application SHOULD supply as an RN the name of the other party with which it is communicating.
受信者名（RN）はDNと同じ形式を取得しますが、受信者の名前を表します。通信セッションでは、アプリケーションがRNとして、それが通信している相手の名前を提供する必要があります。
The RN value is expected to remain constant for the duration of a session. RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
RN値は、セッション期間中、一定のままであると予想されます。RDSSは、ネットワークリソースの効率的な使用を確保するために、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.
このパラメーターは、特定のセッションまたは通信のサブセッションにアプリケーションで使用されるソースポートを示します。ポートの例には、セッション開始プロトコル（SIP）などの通信アプリケーションプロトコルで使用されるTCPポートまたはUDPポートが含まれます。等々。
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日の0H UTC（調整されたユニバーサル時間）に比べて数秒であるネットワーク時間プロトコル（NTP）のタイムスタンプ形式を使用して表されます[RFC1305]。
This parameter SHOULD be sent only in the first RAQMON PDU, after the session setup is completed.
このパラメーターは、セッションのセットアップが完了した後、最初のRaqmon PDUでのみ送信する必要があります。
The Session Setup Delay metric reports the time taken from an origination request being initiated by a host/endpoint to the media path being established (or a session progress indication being received from the remote host/endpoint), expressed in milliseconds. For example, in VoIP systems, a session setup time can be measured as the interval from the last DTMF (dual-tone multi-frequency) button pushed to the first ring-back tone that indicates that the far end is ringing. Another example would be the Session Setup Delay of a SIP call, which is measured as the elapsed time between when an INVITE is generated by a User Agent and when the 200 OK is received.
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.
RTPを介して実行されるアプリケーションおよび[RFC2681]で[RFC3550]で定義された往復エンドツーエンドネットワーク遅延は、アプリケーションQoSモニタリングの重要なメトリックです。一部のアプリケーションは、ホスト間のエンドツーエンドの遅延が一部のしきい値に比べて大きい場合、うまく機能しません（またはまったく）。遅延値の不規則な変動により、IPオーバー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の[RFC3550]および他のIPアプリケーションで[RFC2681]に記載されている方法論を使用して測定されます。
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]のサポート、またはアプリケーション名の先頭に文字列「RTP」を含めることによって決定できます（セクション5.32）。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
このパラメーターは、RDSがその値を決定する機能を持っている場合、およびパラメーターがアプリケーションに関連する場合、各Raqmon PDUで送信する必要があります。
The One-Way End-to-End Network Delay [RFC2679] metric reports the One-Way End-to-End delay encountered by traffic from the source to the destination network interface. One-Way Delay measurements identified by the IP Performance Metrics (IPPM) Working Group [RFC2679] will be used to measure one-way end-to-end network delay.
一方向のエンドツーエンドネットワーク遅延[RFC2679]メトリックは、ソースから宛先ネットワークインターフェイスへのトラフィックで遭遇する一方向のエンドツーエンド遅延を報告しています。IPパフォーマンスメトリック（IPPM）ワーキンググループ[RFC2679]によって特定された一元配置遅延測定は、一方向のエンドツーエンドネットワーク遅延を測定するために使用されます。
The need for such a metric is derived from the fact that the path from a source to a destination may be different from the path from the destination back to the source ("asymmetric paths"), such that different sequences of routers are used for the forward and reverse paths. Therefore, round-trip measurements actually measure the performance of two distinct paths together.
このようなメトリックの必要性は、ソースから宛先へのパスが宛先からソースへのパスとは異なる可能性があるという事実（「非対称パス」）から派生しているため、ルーターの異なるシーケンスが使用されるようになります。前後のパス。したがって、往復測定では、実際には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).
各パスを独立して測定すると、異なるインターネットサービスプロバイダーを横断する可能性のある2つのパスのパフォーマンスの違い、さらには根本的に異なるタイプのネットワーク（たとえば、研究対商品ネットワーク、または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つのパスが対称であっても、非対称のキューイングのために根本的に異なるパフォーマンス特性を持っている可能性があります。アプリケーションのパフォーマンスは、主に一方向のパフォーマンスに依存する場合があります。たとえば、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]。ジッターの測定値は、パケットの損失につながる前に混雑を示す場合があります。Arrival Inter-Arrival Jitterフィールドは、Raqmon PDUが生成された時点でのジッターのスナップショットにすぎず、[RFC3550]に示されているように定量的に採用されることを意図していません。むしろ、1つのレシーバーからの攻撃間ジッターを時間の経過とともに比較することを目的としています。このような到着間ジッター情報は、IPオーバーIP、ビデオオーバーIPなどのVoice Over IPなどの特定のアプリケーションの動作を理解するのに非常に役立ちます。また、定期的な配信を必要とするアプリケーションのプレイアウトバッファーのサイジングには、攻撃間ジッター情報も使用されます。パケットの（たとえば、音声やビデオの再生）。
In [RFC3550], the selection function is implicitly applied to consecutive packet pairs, and the "jitter estimate" is computed by applying an exponential filter with parameter 1/16 to generate the estimate (i.e., j_new = 15/16* j_old + 1/16*j_new).
[RFC3550]では、選択関数は連続したパケットペアに暗黙的に適用され、「ジッター推定」は、パラメーター1/16の指数フィルターを適用して推定値を生成することによって計算されます（つまり、j_new = 15/16* j_old 1/16*j_new）。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
このパラメーターは、RDSがその値を決定する機能を持っている場合、およびパラメーターがアプリケーションに関連する場合、各Raqmon PDUで送信する必要があります。
[RFC3393] provides guidance to several absolute jitter parameters. RAQMON uses the [RFC3393] definition of the IP Packet Delay Variation (ipdv) for packets inside a stream of packets. The IP Delay Variation metric is used to determine the dynamics of queues within a network (or router) where the changes in delay variation can be linked to changes in the queue length processes at a given link or a combination of links. Such a parameter provides visibility within an IP Network and a better understanding of application-level performance problems as it relates to IP Network performance.
[RFC3393]は、いくつかの絶対ジッターパラメーターのガイダンスを提供します。Raqmonは、パケットのストリーム内のパケットにIPパケット遅延変動（IPDV）の[RFC3393]定義を使用します。IP遅延変動メトリックは、遅延変動の変化が特定のリンクまたはリンクの組み合わせでキュー長プロセスの変化にリンクできるネットワーク（またはルーター）内のキューのダイナミクスを決定するために使用されます。このようなパラメーターは、IPネットワーク内の可視性を提供し、IPネットワークパフォーマンスに関連するアプリケーションレベルのパフォーマンスの問題をよりよく理解します。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
このパラメーターは、RDSがその値を決定する機能を持っている場合、およびパラメーターがアプリケーションに関連する場合、各Raqmon PDUで送信する必要があります。
This metric reports the number of application payload packets received by the RDS as part of this session since the last RAQMON PDU was sent up until the time this RAQMON PDU was generated.
このメトリックは、このRaqmon PDUが生成されるまでの最後の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.
たとえば、Voice Over IPまたはビデオオーバーIPセッションのセットアップでは、このカウンターは、SIPやH.323などの関連するアプリケーションシグナリングプロトコルスタックから導出されるシグナリングセッション関連のパケットの数を表します。、およびアプリケーションが通信セッションを確立するために使用する他のさまざまなシグナリングプロトコル。
However, during a period when media is established between the communicating entities, this counter will be indicative of the number of RTP Frames that have been sent out to the communicating party since last PDU was sent out. The methodology described within RTCP SR/RR reports [RFC3550] to count RTP frames will be applied wherever applications use RTP. This being a cumulative counter, applications need to take into consideration the possibility of the counter overflowing and restarting counting from zero.
ただし、通信エンティティ間でメディアが確立される期間に、このカウンターは、前回のPDUが送信されてから通信当事者に送信されたRTPフレームの数を示します。RTCP SR/RRレポート[RFC3550]で説明されている方法論は、アプリケーションがRTPを使用する場合はどこでも適用されます。これは累積カウンターであるため、アプリケーションはカウンターがオーバーフローし、ゼロからカウントを再起動する可能性を考慮する必要があります。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートは、アプリケーションを実行しているホストでのRTP MIB [RFC2959]のサポート、またはアプリケーション名の先頭に文字列「RTP」を含めることによって決定できます（セクション5.32）。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
このパラメーターは、RDSがその値を決定する機能を持っている場合、およびパラメーターがアプリケーションに関連する場合、各Raqmon PDUで送信する必要があります。
This metric reports the number of signaling and payload packets sent by the RDS as part of this session since the last RAQMON PDU was sent until the time this RAQMON PDU was generated. Applications packets MAY include signaling packets. Similar to the total number of application packets received parameter in Section 5.16, this count is a snapshot in time. Depending on the application type, the counter also varies based on various application states, including packet counts for signaling setup, media establishment, session termination states, and so on. This being a cumulative counter, applications need to take into consideration the possibility of the counter overflowing and restarting counting from zero.
このメトリックは、このセッションの一部としてRDSが送信したシグナリングとペイロードパケットの数を報告しています。このRaqmon PDUが生成されるまでの最後のRaqmon PDUが送信されてからです。アプリケーションパケットには、信号パケットが含まれる場合があります。セクション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.
このメトリックは、このセッションの一部としてRDSがパケットで受け取ったシグナリングとペイロードオクテットの総数を、最後のRaqmon PDUが送信されてから、このRaqmonパケットが生成されるまでに送信されます。アプリケーションオクテットには、シグナリングオクテットが含まれる場合があります。[RFC3550]で説明されている方法論は、アプリケーションがRTPを使用する場所に適用されます。これは累積カウンターであるため、アプリケーションはカウンターがオーバーフローし、ゼロからカウントを再起動する可能性を考慮する必要があります。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートは、アプリケーションを実行しているホストでのRTP MIB [RFC2959]のサポート、またはアプリケーション名の先頭に文字列「RTP」を含めることによって決定できます（セクション5.32）。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
このパラメーターは、RDSがその値を決定する機能を持っている場合、およびパラメーターがアプリケーションに関連する場合、各Raqmon PDUで送信する必要があります。
This metric reports the total number of signaling and payload octets received in packets by the RDS as part of this session since the last RAQMON PDU was sent, up until the time this RAQMON packet was generated. This is similar to the Total Number of Application Octets Received metric. Applications octets MAY include signaling octets. The methodology described by [RFC3550] will be applied wherever applications use RTP. This being a cumulative counter, applications need to take into consideration the possibility of the counter overflowing and restarting counting from zero.
このメトリックは、このセッションの一部としてRDSがパケットで受け取ったシグナリングとペイロードオクテットの総数を、最後のRaqmon PDUが送信されてから、このRaqmonパケットが生成されるまでに送信されます。これは、メトリックを受信したアプリケーションの総数に似ています。アプリケーションオクテットには、シグナリングオクテットが含まれる場合があります。[RFC3550]で説明されている方法論は、アプリケーションがRTPを使用する場所に適用されます。これは累積カウンターであるため、アプリケーションはカウンターがオーバーフローし、ゼロからカウントを再起動する可能性を考慮する必要があります。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートは、アプリケーションを実行しているホストでのRTP MIB [RFC2959]のサポート、またはアプリケーション名の先頭に文字列「RTP」を含めることによって決定できます（セクション5.32）。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
このパラメーターは、RDSがその値を決定する機能を持っている場合、およびパラメーターがアプリケーションに関連する場合、各Raqmon PDUで送信する必要があります。
The cumulative packet loss metric indicates the loss associated with the network as well as local device losses over time. This parameter is counted as the total number of application packets from the source that have been lost since the beginning of the session. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes the count of packets that are late or duplicates. If a packet is discarded due to late arrival, then it MUST be counted as either lost or discarded but MUST NOT be counted as both.
累積パケット損失メトリックは、ネットワークに関連する損失と、時間の経過に伴うローカルデバイスの損失を示します。このパラメーターは、セッションの開始以来失われてきたソースからのアプリケーションパケットの総数としてカウントされます。この数は、受け取ったパケットの数には、遅れたパケットまたは複製のパケットの数が含まれる場合、実際に受け取ったパケットの数が少ないと予想されるパケットの数であると定義されています。到着が遅れたためにパケットが破棄される場合、紛失または破棄としてカウントする必要がありますが、両方としてカウントする必要はありません。
Packet loss by the underlying transport network SHALL be measured using the methodologies described in [RFC3550] for RTP traffic and [RFC2680] for other IP traffic. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. For RTP traffic, this may be calculated using techniques such as those shown in Appendix A.3 of [RFC3550].
基礎となる輸送ネットワークによるパケット損失は、RTPトラフィックについて[RFC3550]に記載されている方法論、および他のIPトラフィックについて[RFC2680]を使用して測定するものとします。予想されるパケットの数は、次に定義されているように、受信した初期シーケンス数を減らすことができるように、受信した拡張最後のシーケンス番号であると定義されます。RTPトラフィックの場合、これは[RFC3550]の付録A.3に示すような手法を使用して計算できます。
Packet loss by the underlying transport network SHALL be measured using the methodologies described in [RFC3550] for RTP traffic and [RFC2680] for other IP traffic. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. For RTP traffic, this may be calculated using techniques such as those shown in Appendix A.3 of [RFC3550].
基礎となる輸送ネットワークによるパケット損失は、RTPトラフィックについて[RFC3550]に記載されている方法論、および他のIPトラフィックについて[RFC2680]を使用して測定するものとします。予想されるパケットの数は、次に定義されているように、受信した初期シーケンス数を減らすことができるように、受信した拡張最後のシーケンス番号であると定義されます。RTPトラフィックの場合、これは[RFC3550]の付録A.3に示すような手法を使用して計算できます。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートは、アプリケーションを実行しているホストでのRTP MIB [RFC2959]のサポート、またはアプリケーション名の先頭に文字列「RTP」を含めることによって決定できます（セクション5.32）。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
このパラメーターは、RDSがその値を決定する機能を持っている場合、およびパラメーターがアプリケーションに関連する場合、各Raqmon PDUで送信する必要があります。
The Packet Loss in Fraction metric represents the packet loss as defined above, but expressed as a fraction of the total traffic over time.
画分メトリックのパケット損失は、上記で定義されているパケット損失を表しますが、総トラフィックの一部として時間の経過とともに表されます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
このパラメーターは、RDSがその値を決定する機能を持っている場合、およびパラメーターがアプリケーションに関連する場合、各Raqmon PDUで送信する必要があります。
The RAQMON Framework allows applications to distinguish between packets lost by the network and those discarded due to jitter and other application-level errors. Though packet loss and discards have an equal effect on the quality of the application, having separate counts for packet loss and discards helps identify the source of quality degradation.
RAQMONフレームワークにより、アプリケーションは、ネットワークによって失われたパケットと、ジッターおよびその他のアプリケーションレベルのエラーにより破棄されたパケットを区別できます。パケットの損失と廃棄はアプリケーションの品質に平等な影響を及ぼしますが、パケットの損失と廃棄のために個別のカウントを持つことは、品質劣化の原因を特定するのに役立ちます。
The packet discard metric indicates packets discarded locally by the device over time. Local device-level packet discard is captured as the total number of application-level packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer, or any other application-specific reasons.
パケット廃棄メトリックは、時間の経過とともにデバイスによって局所的に廃棄されたパケットを示します。ローカルデバイスレベルのパケット廃棄は、レセプションの開始以来廃棄されたソースからのアプリケーションレベルのパケットの総数としてキャプチャされます。その他のアプリケーション固有の理由。
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.
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.
動的なコーデックの変更などのイベントを除き、ソースペイロードタイプの値は、セッションの期間中、一定のままであると予想されます。RDSSは、ネットワークリソースの効率的な使用を確保するために、必要以上に（たとえば、動的コーデックの変更など）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）がソースペイロードタイプを識別するために使用されている場合、MIMEサブタイプを示すためにRaqmon拡張パラメーターを定義できます。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].
受信者のペイロードタイプは、他の通信パーティーから送信されたペイロードフォーマット（メディアエンコーディングなど）をレポートします。ドキュメントは、[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.
動的なコーデックの変更などのイベントを除き、宛先のペイロードタイプの値は、セッションの期間中、一定のままであると予想されます。RDSSは、ネットワークリソースの効率的な使用を確保するために、必要以上に（たとえば、動的コーデックの変更など）raqmonレポート内でこれらのパラメーターを送信することを避ける必要があります。
If dynamic types (values 96 to 127, according to [RFC3551]) are being used to identify the destination payload type, a RAQMON extension parameter MAY be defined to indicate the MIME subtypes. In the case where the RDS does send reports noting dynamic codec changes, there may be instances where this extension parameter is used only before or after the codec change, as the destination payload may shift between the dynamic and static types.
動的型（[RFC3551]に従って値96〜127）が宛先のペイロードタイプを識別するために使用されている場合、RAQMON拡張パラメーターを定義してMIMEサブタイプを示すことができます。RDSが動的なコーデックの変更に注目するレポートを送信する場合、宛先ペイロードが動的タイプと静的タイプの間にシフトする可能性があるため、この拡張パラメーターがコーデックの変更の前または後にのみ使用される場合があります。
Many devices use Layer 2 technologies to prioritize certain types of traffic in the Local Area Network environment. For example, the 1998 Edition of IEEE 802.1D [IEEE802.1D], "Media Access Control Bridges", contains expedited traffic capabilities to support transmission of time-critical information. Many devices use that standard to mark Ethernet frames according to IEEE P802.1p standard. Details on these can be found in [IEEE802.1D], which incorporates P802.1p. The Source Layer 2 Priority RAQMON field indicates what Layer 2 values were used by the host running the RDS to prioritize these packets in the Local Area Network environment.
多くのデバイスは、レイヤー2テクノロジーを使用して、ローカルエリアネットワーク環境で特定の種類のトラフィックに優先順位を付けています。たとえば、1998年版IEEE 802.1d [IEEE802.1d]、「Media Access Control Bridges」には、時間のような情報の伝達をサポートするための迅速なトラフィック機能が含まれています。多くのデバイスは、その標準を使用して、IEEE P802.1p標準に従ってイーサネットフレームをマークします。これらの詳細は、p802.1pが組み込まれた[IEEE802.1d]にあります。ソースレイヤー2優先Raqmonフィールドは、ローカルエリアネットワーク環境でこれらのパケットに優先順位を付けるためにRDSを実行しているホストが使用したレイヤー2値を示します。
The Source Layer 2 Priority value is expected to remain constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
ソースレイヤー2の優先順位値は、セッション期間中、一定のままであると予想されます。RDSを実行しているホストは、ネットワークリソースの効率的な使用を確保するために、Raqmonレポート内でこれらのパラメーターを頻繁に送信することを避ける必要があります。
Various Layer 3 technologies are in place to prioritize traffic in the Internet. For example, the traditional IP Precedence [RFC791] and Type of Service (TOS) [RFC1812], or more recent technologies like Differentiated Services [RFC2474] [RFC2475], use the TOS octet in IPv4, whereas the traffic class octet is used to prioritize traffic in IPv6. Source Layer TOS/DCP RAQMON field reports the appropriate Layer 3 values used by the Data Source to prioritize these packets.
インターネット内のトラフィックに優先順位を付けるために、さまざまなレイヤー3テクノロジーが用意されています。たとえば、従来のIPの優先順位[RFC791]およびサービスのタイプ（TOS）[RFC1812]、または差別化されたサービス[RFC2474] [RFC2475]などの最近のテクノロジーは、IPv4のTOSオクテットを使用しますが、トラフィッククラスのオクテットは使用されます。IPv6のトラフィックに優先順位を付けます。ソースレイヤーTOS/DCP Raqmonフィールドは、これらのパケットに優先順位を付けるためにデータソースが使用する適切なレイヤー3値を報告します。
The Source TOS/DSCP value is expected to remain constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
ソースTOS/DSCP値は、セッションの期間中、一定のままであると予想されます。RDSを実行しているホストは、ネットワークリソースの効率的な使用を確保するために、Raqmonレポート内でこれらのパラメーターを頻繁に送信することを避ける必要があります。
The Destination Layer 2 Priority reports the Layer 2 value used by the communication receiver to prioritize packets while sending traffic to the data source in the Local Area Networks environment. Like Source Layer 2 Priority, Destination Layer 2 Priority could indicate whether the destination has used Layer 2 technologies like IEEE P802.1p for priority queuing.
宛先レイヤー2の優先度は、ローカルエリアネットワーク環境のデータソースにトラフィックを送信しながらパケットを優先順位付けするために通信レシーバーが使用するレイヤー2値を報告します。ソースレイヤー2の優先度と同様に、宛先レイヤー2の優先度は、宛先が優先キューイングに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]などのレイヤー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フレームワーク内では、RRCはRDSよりも大幅に大きな計算リソースを持つと予想されます。その結果、RRCによってさまざまな集約関数が実行されますが、RDSは、最小値、最大、平均、標準偏差などの計算などの統計データ処理によって負担されません。
The RAQMON MIB provides minimal aggregation of the RAQMON parameters defined above. The RAQMON MIB is not designed to provide extensive aggregation like the Application Performance Measurement (APM) MIB [RFC3729] or the Transport Performance Metrics (TPM) MIB [RFC4150]. One should use APM and TPM MIBs to aggregate parameters based on protocols (e.g., performance of HTTP, RTP) or applications (e.g., performance of VoIP, Video Applications).
Raqmon MIBは、上記のRaqmonパラメーターの最小分質を提供します。Raqmon MIBは、アプリケーションパフォーマンス測定（APM）MIB [RFC3729]や輸送パフォーマンスメトリック（TPM）MIB [RFC4150]などの広範な集約を提供するようには設計されていません。APMおよびTPM MIBSを使用して、プロトコル（HTTP、RTPのパフォーマンスなど）またはアプリケーション（VoIP、ビデオアプリケーションのパフォーマンスなど）に基づいてパラメーターを集約する必要があります。
In the RAQMON MIB, aggregation can be performed only on specific RAQMON metric parameters. Aggregation always results in statistical Mean/Min/Max values, according to these definitions:
Raqmon MIBでは、凝集は特定のRaqmonメトリックパラメーターでのみ実行できます。これらの定義によると、集約は常に統計的平均/min/max値をもたらします。
Mean: Mean is defined as the statistical average of a metric over the duration of a communication session. For example, if an RDS reported End-to-End delay metric N times within a communication session, then the Mean End-to-End Delay can be computed by summing of these N reported values, and then dividing by N.
平均：平均は、通信セッションの期間中のメトリックの統計平均として定義されます。たとえば、RDSが通信セッション内でエンドツーエンドの遅延メトリックnを報告した場合、これらのn報告値を合計してnで除算することにより、平均エンドツーエンド遅延を計算できます。
Min: Min is defined as the statistical minimum of a metric over the duration of a communication session. For example, if the end-to-end delay metric of an end-device within a communication session is reported N times by the RDS, then the Min end-to-end delay is the smallest of the N end-to-end delay metric values reported.
Min：MINは、通信セッションの期間中の統計的最小メトリックとして定義されます。たとえば、通信セッション内のエンドデバイスのエンドツーエンド遅延メトリックがRDSによってn回報告される場合、最小エンドツーエンドの遅延はNエンドツーエンド遅延の最小です報告されているメートル法の値。
Max: Max is defined as the statistical maximum of a metric over the duration of a communication session. For example, if the end-to-end delay metric of an end-device within a communication session is reported N times by the RDS, then the Max End-to-End Delay is the largest of the N End-to-End Delay metric values reported.
MAX：MAXは、通信セッションの期間中のメトリックの統計的最大値として定義されます。たとえば、通信セッション内のエンドデバイスのエンドツーエンド遅延メトリックがRDSによってn回報告される場合、最大エンドツーエンド遅延はNエンドツーエンド遅延の最大です。報告されているメートル法の値。
It is evident from the document that the RAQMON MIB data need to be managed to optimize storage space. The large volume of data gathered in a communication session could be optimized for storage space by performing and storing only aggregated RAQMON metrics for history if required.
ドキュメントから、Raqmon MIBデータをストレージスペースを最適化するために管理する必要があることが明らかです。通信セッションで収集された大量のデータは、必要に応じて履歴のために集約されたRaqmonメトリックのみを実行および保存することにより、ストレージスペース用に最適化できます。
Examples of how such storage space optimization can be performed include:
そのようなストレージスペースの最適化をどのように実行できるかの例は次のとおりです。
1. Make data available through the MIB only at the end of a communication session, i.e., upon receipt of a NULL PDU. The aggregated data could be made available using the RAQMON MIB as Mean, Max, or Min entries and saved for historical purposes.
1. コミュニケーションセッションの終了時にのみMIBを介してデータを利用可能にします。つまり、ヌルPDUを受信します。集約されたデータは、Raqmon MIBを平均、最大、またはMINエントリとして使用して利用可能にし、歴史的な目的で保存できます。
2. Use a time-based algorithm that aggregates data over a specific period of time within a communication session, thus requiring fewer entries, to reduce storage space requirements. For example, if an RDS sends data out every 10 seconds and the RRC updates the RAQMON MIB once every minute, for every 6 data points there would be one MIB entry.
2. 通信セッション内の特定の期間にわたってデータを集約する時間ベースのアルゴリズムを使用するため、ストレージスペースの要件を削減するために、より少ないエントリが必要です。たとえば、RDSが10秒ごとにデータを送信し、RRCがRaqmon MIBを1分間1回更新する場合、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に運命づけられている別のRAQMONレポートセッションからの情報の誤認。
b. Mismapping of RAQMON sessions;
b. Raqmonセッションの不適切な;
c. Various forms of session-level denial-of-service (DoS) attacks;
c. さまざまな形式のセッションレベルのサービス拒否（DOS）攻撃。
d. DoS through modification of RAQMON parameter values and statistics;
d.
e. Invalid timestamps, leading to false interpretation of the monitored data, affecting call records information, and making difficult to place monitoring events in their appropriate temporal context.
e. 無効なタイムスタンプは、監視されたデータの誤った解釈につながり、コールレコード情報に影響を与え、適切な時間的コンテキストで監視イベントを監視することを困難にします。
3. Malformed payloads, permitting the exploitation of potential implementation weaknesses to compromise an RRC.
3. 奇形のペイロードは、RRCを妥協するために潜在的な実装の弱点を活用することを許可します。
4. Unauthorized disclosure of sensitive data carried by application PDUs, leading to a breach of confidentiality.
4. アプリケーションPDUによって運ばれる機密データの不正な開示は、機密性の違反につながります。
Consequently, threats based on unauthorized disclosure or modification of payloads or headers will have to be assumed.
その結果、不正な開示またはペイロードまたはヘッダーの変更に基づく脅威を想定する必要があります。
In order to preserve integrity of the RAQMON PDU against these threats, the RAQMON model must provide for cryptographically strong security services.
これらの脅威に対するRaqmon PDUの完全性を維持するために、Raqmonモデルは暗号化的に強力なセキュリティサービスを提供する必要があります。
Consequently, the RAQMON framework must be able to provide for the following protections:
したがって、Raqmonフレームワークは、次の保護を提供できる必要があります。
1. Authentication - the RRC should be able to verify that a RAQMON PDU was in fact originated by the RDS that claims to have sent it.
1. 認証 - RRCは、Raqmon PDUが実際にそれを送信したと主張するRDSによって発生したことを確認できるはずです。
2. Privacy - Since RAQMON information includes identification of the parties participating in a communication session, the RAQMON framework should be able to provide for protection from eavesdropping, to prevent an unauthorized third party from gathering potentially sensitive information. This can be achieved by using various payload encryption technologies, such as Data Encryption Standard (DES), 3-DES, Advanced Encryption Standard (AES), etc.
2. プライバシー - RAQMON情報には、コミュニケーションセッションに参加している当事者の識別が含まれているため、RAQMONフレームワークは盗聴からの保護を提供し、許可されていない第三者が潜在的に機密情報を収集するのを防ぐことができるはずです。これは、データ暗号化標準（DES）、3-DE、高度な暗号化標準（AES）など、さまざまなペイロード暗号化技術を使用することで実現できます。
3. Protection from DoS attacks directed at the RRC - RDSs send RAQMON reports as a side effect of an external event (for example, a phone call is being received). An attacker can try to overwhelm the RRC (or the network) by initiating a large number of events (i.e., calls) for the purpose of swamping the RRC with too many RAQMON PDUs.
3. RRC -RDSSに向けられたDOS攻撃からの保護は、外部イベントの副作用として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.
3. RDSとRRCの間で輸送プロトコルセキュリティがすでに有効になっている場合、アプリケーションレベルでの追加の暗号化とメッセージ認証は回避されます。
However, there are also shortcomings to be noted in relying on transport protocol security.
ただし、輸送プロトコルのセキュリティに依存することには注意が必要です。
1. When session-level isolation of the different RAQMON sessions of an RDS-RRC pair is required, it will be necessary to open separate transport protocol instances. Such cases, however, may be rare.
1. RDS-RRCペアのさまざまなRaqmonセッションのセッションレベルの分離が必要な場合、個別の輸送プロトコルインスタンスを開く必要があります。ただし、そのような場合はまれかもしれません。
2. Since security services are not provided by the RAQMON framework, the absence of transport or lower protocol security implies the absence of RAQMON security.
2. セキュリティサービスはRAQMONフレームワークによって提供されていないため、輸送の欠如またはプロトコルセキュリティの低下は、RAQMONセキュリティの欠如を意味します。
The authors would like to thank Andy Bierman, Alan Clark, Mahalingam Mani, Colin Perkins, Steve Waldbusser, Magnus Westerlund, and Itai Zilbershtein for the precious advices and real contributions brought to this document. The authors would also like to extend special thanks to Randy Presuhn, who reviewed this document for spelling and formatting purposes, and who provided a deep review of the technical content. We also would like to thank Bert Wijnen for the permanent coaching during the evolution of this document and the detailed review of its final versions.
著者は、この文書にもたらされた貴重なアドバイスと真の貢献について、アンディ・ビアマン、アラン・クラーク、マハリンガム・マニ、コリン・パーキンス、スティーブ・ウォルドバッサン、マグナス・ウェスターランド、イタイ・ジルバーシュテインに感謝したいと思います。著者はまた、スペルとフォーマットの目的でこのドキュメントをレビューし、技術コンテンツの深いレビューを提供したRandy Presuhnに特別な感謝を拡大したいと考えています。また、この文書の進化とその最終バージョンの詳細なレビュー中の恒久的なコーチングについて、Bert Wijnenに感謝します。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「Distementiated Serviceの建築」、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] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」、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.、ed。、「Simple Network Management Protocol（SNMP）のプロトコル操作のバージョン2」、STD 62、RFC 3416、2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 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] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Friedman、T.、Caceres、R。、およびA. Clark、「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] Dietz、R。およびR. Cole、「Transport Performance Metrics 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. Kim、「リアルタイムのアプリケーションのための輸送マッピングサービス品質監視（RAQMON）プロトコルデータユニット（PDU）」、RFC 4712、2006年10月。
[IEEE802.1D] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common Specification a - Media access control (MAC) bridges:15802-3: 1998 (ISO/IEC). Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e [ANSI/IEEE Std 802.1D, 1998 Edition]
[IEEE802.1D]情報技術 - システム間の通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 共通仕様A-メディアアクセス制御（MAC）ブリッジ：15802-3：1998（ISO/IEC）。リビジョン。これは、ISO/IEC 10038：1993、802.1J-1992および802.6K-1992の改訂です。P802.11C、P802.1P、およびP802.12E [ANSI/IEEE STD 802.1d、1998エディション]が組み込まれています。
Authors' Addresses
著者のアドレス
Anwar A. Siddiqui Avaya Labs 307 Middletown Lincroft Road Lincroft, New Jersey 07738 USA
Anwar A. Siddiqui Avaya Labs 307 Middletown Lincroft Road Lincroft、ニュージャージー07738 USA
Phone: +1 732 852-3200
EMail: anwars@avaya.com
Dan Romascanu Avaya Atidim Technology Park, Building #3 Tel Aviv, 61131 Israel
ダン・ロマスカヌ・アヴァヤ・アティディム・テクノロジー・パーク、建物＃3テルアビブ、61131イスラエル
Phone: +972-3-645-8414
EMail: dromasca@avaya.com
Eugene Golovinsky
ユージン・ゴロビンスキー
EMail: gene@alertlogic.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。