RFC4710 日本語訳
4710 Real-time Application Quality-of-Service Monitoring (RAQMON)Framework. A. Siddiqui, D. Romascanu, E. Golovinsky. October 2006. (Format: TXT=86403 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Siddiqui
Request for Comments: 4710 D. Romascanu
Category: Standards Track Avaya
E. Golovinsky
Alert Logic
October 2006
Siddiquiがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4710年のD.Romascanuカテゴリ: 標準化過程Avaya E.Golovinskyは2006年10月に論理を警告します。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
There is a need to monitor end-devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications.
IP電話や、ポケットベルや、Instant Messagingクライアントや、携帯電話や、他の様々なハンドヘルドのコンピュータ・デバイスなどの端末装置をモニターする必要があります。 このメモは、これらのデバイスで動く様々なアプリケーションのリアルタイムのサービスの質(QoS)モニターを許すために仕様のリモートネットワーク監視(RMON)ファミリーを広げて、この情報がRMONファミリーについて統合しているのをSimple Network Managementプロトコル(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
1. 序論…2 2. RAQMON機能的な建築…4 3. 混雑安全なモードにおけるRAQMON操作…11 4. 測定方法論…14 5. 測定基準は基本的ためにRAQMON PDUの一部を事前に定義しました…14 6. AggregationとStatistical Data処理を報告してください…28 7. 史料とストレージを保ちます…29 8. セキュリティ問題…30 9. 承認…32 10. 標準の参照…33 11. 有益な参照…34
Siddiqui, et al. Standards Track [Page 1] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[1ページ]。
1. Introduction
1. 序論
With the growth of the Internet and advancements in embedded technologies, smart IP devices (such as IP phones, pagers, instant message clients, mobile phones, wireless handhelds, and various other computing devices) have become an integral part of our day-to-day operations. Enterprise operators, information technology (IT) managers, application service providers, network service providers, and so on, need to monitor these application and device types in order to ensure that end user quality-of-service (QoS) objectives are met. This memo describes a monitoring solution for these environments, extending the remote network monitoring (RMON) family of specifications [RFC2819]. These extensions support real-time QoS monitoring of typical applications that run on end-devices mentioned above, and they allow this information to be integrated using the familiar RMON family of specifications via SNMP [RFC3416].
埋め込まれた技術における、インターネットと進出の成長によると、賢いIPデバイス(IP電話や、ポケットベルや、インスタントメッセージクライアントや、携帯電話や、ワイヤレスのハンドヘルドや、他の様々なコンピュータ・デバイスなどの)は私たちのその日その日の操作の不可欠の部分になりました。 エンタープライズオペレータ(情報技術(IT)マネージャ、アプリケーションサービスプロバイダー、ネットワークサービスプロバイダーなど)は、エンドユーザサービスの質(QoS)目的が満たされるのを確実にするためにこれらのアプリケーションと装置タイプをモニターする必要があります。 仕様[RFC2819]のリモートネットワーク監視(RMON)ファミリーを広げて、このメモはこれらの環境のためにモニターしているソリューションについて説明します。 これらの拡大は前記のように端末装置で動く主用途のリアルタイムのQoSモニターをサポートします、そして、それらはこの情報が統合しているのをSNMP[RFC3416]を通して仕様の身近なRMONファミリーを使用することで許容します。
The Real-time Application QoS Monitoring Framework (RAQMON) allows end-devices and applications to report QoS statistics in real time. Many real-time applications (as well as non-real-time applications managed within the RMON family of specifications) can report application-level QoS statistics in real time using the RAQMON Framework outlined in this memo. Some possible applications scenarios include applications such as Voice over IP, Fax over IP, Video over IP, Instant Messaging (IM), Email, software download applications, e-business style transactions, web access from handheld computing devices, etc.
レアル-時間Application QoS Monitoring Framework(RAQMON)は端末装置とアプリケーションにリアルタイムで、QoS統計を報告させます。 多くのリアルタイムのアプリケーション(仕様のRMONファミリーの中で管理された非リアルタイムのアプリケーションと同様に)が、リアルタイムでこのメモに概説されたRAQMON Frameworkを使用することでアプリケーションレベルQoS統計を報告できます。 いくつかの可能なアプリケーションシナリオがハンドヘルドのコンピュータ・デバイスからのボイス・オーバー IPなどのアプリケーション、IPの上のファックス、IPの上のVideo、Instant Messaging(IM)、メール、ソフトウェアダウンロードアプリケーション、電子ビジネススタイル取引、ウェブアクセスなどを含んでいます。
The user experience of an application running on an IP end-device depends upon the type of application the user is running and the surrounding resources available to that application. An end-to-end application QoS experience is a compound effect of various application-level transactions and available network and host resources. For example, the end-to-end user experience of a Voice over IP (VoIP) call depends on the total time required to set up the call as much as on media-related performance parameters such as end- to-end network delay, jitter, packet loss, and the type of codec used in a call. The performance of a VoIP call is also influenced by behavior of network protocols like the Reservation Protocol (RSVP), explicit tags in differentiated services (DiffServ) [RFC2475] or IEEE 802.1 [IEEE802.1D] along with available host resources such as device CPU or memory utilized by other applications while the call is ongoing.
アプリケーションがIP端末装置で動くユーザー・エクスペリエンスはユーザが実行しているアプリケーションのタイプとそのアプリケーションに手があいている周囲のリソースに頼っています。 終わりから終わりへのアプリケーションQoS経験は様々なアプリケーションレベルトランザクション、利用可能なネットワーク、およびホストリソースの合成効果です。 例えば、ボイス・オーバー IP(VoIP)呼び出しの終わりからエンドユーザへの経験は呼び出しを呼び出しに使用されるコーデックの終わりまでの終わりのネットワーク遅延や、ジターや、パケット損失や、タイプなどのメディア関連の性能パラメタと同じくらいたくさんセットアップするのに必要である合計時によります。 また、予約プロトコル(RSVP)(呼び出しが進行中である間に他のアプリケーションで利用されたデバイスCPUかメモリなどの利用可能なホストリソースに伴う差別化されたサービス(DiffServ)[RFC2475]かIEEE802.1[IEEE802.1D]の明白なタグ)のようなネットワーク・プロトコルの振舞いでVoIP呼び出しの性能は影響を及ぼされます。
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
終わりから終わりへのアプリケーションサービスの質(QoS)経験はアプリケーション文脈敏感です。 例えば、IP電話技術アプリケーションで報告されたパラメタの種類は本当にInstant Messagingなどの他のアプリケーションに必要でないかもしれません。 RAQMONフレームワーク
Siddiqui, et al. Standards Track [Page 2] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[2ページ]。
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特定のアプリケーション文脈に、メカニズムを提供することによって適切な経験が事前に定義されたリストから測定基準の部分集合を報告すると報告するためにメカニズムを提供します。
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。 「ユーザ、Application、Session」特定のパラメタ(例えば、セッション準備時間、アプリケーション文脈に基づくセッション持続時間パラメタ)。
ii. "IP end-device"-specific parameters during a session (e.g.,
CPU usage, memory usage).
ii。 セッション(例えば、CPU用法、メモリ使用量)の間の「IP端末装置」特定のパラメタ。
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 Frameworkは、終わりから終わりへのそのようなQoSが仕様のRMONファミリーにそのような視点を見て、合わせると報告するためにメカニズムを提供します。 特に、RAQMON Frameworkは以下を指定します:
a. A set of basic metrics sent as reports between the RAQMON
entities using for transport existing Internet Protocols such
as TCP or SNMP.
a。 1セットの基本的な測定基準は、レポートとしてRAQMON実体の間で輸送存在にTCPかSNMPなどのインターネットプロトコルを使用することで発信しました。
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 Modulesの拡大としてのManagement Information基地(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レポートのための情報モデルの1セット。
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)の上のそのようなPDUsのトランスミッションのケースシナリオとSimple Network Managementプロトコルを構文のPDU構造と使用の定義に提供します(SNMP)。
Siddiqui, et al. Standards Track [Page 3] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[3ページ]。
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.
SNMPプロトコルがインターネットコミュニティにある状態で、RAQMON MIB[RFC4711]メモは使用のためのManagement Information基地(MIB)について説明します。 ドキュメントは、RAQMONソリューションを収容するためにRemote Monitoring MIB[RFC2819]に拡大を提案します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. RAQMON Functional Architecture
2. RAQMON機能的な建築
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 FrameworkはRMON MIB[RFC2819]でエンドユーザによって経験されるようにアプリケーション性能情報を提供することによって作成されたアーキテクチャを広げています。 RAQMONアーキテクチャは以下で指定された3個の機能部品に基づいています:
- RAQMON Data Source (RDS)
- RAQMONデータ送信端末(RDS)
- RAQMON Report Collector (RRC)
- RAQMONレポートコレクタ(RRC)
- RAQMON MIB Structure
- RAQMON MIB構造
A RAQMON Data Source (RDS) is a functional component that acts as a source of data for monitoring purposes. End-devices like IP phones, cell phones, and pagers, and application clients like instant messaging clients, soft phones in PCs, etc., are envisioned to act as RDSs within the RAQMON Framework.
RAQMON Data Source(RDS)はモニターしている目的のためのデータの源として作動する機能部品です。 インスタントメッセージングクライアント(PCなどにおける柔らかい電話)がRDSsとしてRAQMON Frameworkの中で機能するように思い描かれるように端末装置はIP電話、携帯電話、ポケットベル、およびアプリケーションクライアントが好きです。
Siddiqui, et al. Standards Track [Page 4] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[4ページ]。
+----------------------+ +---------------------------+
| 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|
+------------------+ +------------------+ +------------+
+----------------------+ +---------------------------+ | IP端末装置| | IP端末装置>。----+ | |+--------------------+| |+--------------------+ | | || アプリケーション|| || アプリケーション| | | || -ボイス・オーバー IP<。----(1)---->ボイス・オーバー IP>+| | || -インスタントメッセージング|| || -インスタントメッセージング| | 3 | || -メール|| || -メール| 2 | | |+--------------------+| |+--------------------+ | | | | | | | | | | | | +------------------+ | | | +----------------------+ | |RAQMONデータ送信端末| <、-+ | | | | (RDS) | <、-、--+ | | +------------------+ | +-----------|---------------+ | (4) TCPかSNMP Notificationsの上で輸送されたRAQMON PDU| +----------------------------+ | | |/ |/ +------------------+ +------------------+ +------------+ |RAQMONレポート| .. |RAQMONレポート| | 管理| |コレクタ(RRC)#n| |コレクタ(RRC)#1| <--5-->| アプリケーション| +------------------+ +------------------+ +------------+
Figure 1 - RAQMON Framework.
図1--RAQMONフレームワーク。
(1) Communication Session between real-time applications
(1) リアルタイムのアプリケーションの間のコミュニケーションSession
(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測定基準(Interface(IP Address)が移植する特定のプロトコル)
(5) Management Application - RRC interaction using the RAQMON MIB
(5)管理Application--RAQMON MIBを使用するRRC相互作用
A RAQMON Report Collector (RRC) collects statistics from multiple RDSs, analyzes them, and stores such information appropriately. RRC is envisioned to be a network server, serving an administrative domain defined by the network administrator. The RRC component of the RAQMON architecture is envisioned to be computationally resourceful. Only RRCs should implement the RAQMON MIB module.
RAQMON Report Collector(RRC)は適切に複数のRDSsから統計を集めて、彼らを分析して、そのような情報を保存します。 ネットワーク管理者によって定義された管理ドメインに役立って、RRCは、ネットワークサーバになるように思い描かれます。 RAQMONアーキテクチャのRRCの部品は、計算上才略にたけるように思い描かれます。 RRCsだけがRAQMON MIBモジュールを実装するはずです。
Siddiqui, et al. Standards Track [Page 5] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[5ページ]。
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基地(RAQMON MIB)は、RAQMON Frameworkを収容するために、Remote Monitoring MIB[RFC2819]を広げていて、Endから終わりへのApplication QoSが情報であるとNetwork Management Applicationsに暴露します。
2.1. RAQMON Data Source (RDS)
2.1. RAQMONデータ送信端末(RDS)
2.1.1. RAQMON Data Source (RDS) Functional Architecture
2.1.1. RAQMONデータ送信端末(RDS)機能的な建築
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 Data Source(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 Report Collector(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パラメタを報告するのにPUSHメカニズムを使用します。 RDSの上で作業するアプリケーションはアプリケーション文脈に、適切なPDUの内容に関して決めますが、RDSはRRCにレポートを非同期に出します。
The rate at which PDUs are sent from RDSs to RRCs is controlled by the applications' administrative domain policy. While this mechanism provides flexibility to gather a detailed end-to-end experience required by IT managers and system administrators, certain steps should be followed to operate RAQMON in congestion-safe manner. Section 3 addresses steps required for congestion-safe operation.
PDUsがRDSsからRRCsに送られるレートはアプリケーションの管理ドメイン方針で制御されます。 このメカニズムが終わりから終わりへの詳細な経験が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によって知覚されるようにQoSパラメタの収集がコミュニケーションセッションと交際したので、RDSからのレポートは論理的に見られます。 例えば、2人のIP電話ユーザ(アリスとジョン)がコミュニケーションセッションにかかわると、終わりから終わりへのIP電話ユーザアリスによって経験された遅れはさまざまな理由でIP電話ユーザジョンによって経験されたものと異なっているかもしれません。 したがって、アリスのIP電話に住んでいるRDSによって知覚されるようにアリスのIP電話からのレポートはその呼び出しのQoS性能を表します。
Siddiqui, et al. Standards Track [Page 6] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[6ページ]。
2.1.2. RAQMON Data Source (RDS) Requirements
2.1.2. RAQMONデータ送信端末(RDS)要件
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 Data Sources SHALLはそのデバイスにある複数のアプリケーションからレポートを集めます、そして、SHALLは与えられた複数のコミュニケーションセッション瞬間に関連している合成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 Data Sourcesは、TCPが輸送であると実装しなければならなくて、SNMPが輸送であると実装するかもしれません。
2.1.3. Configuring RAQMON Data Sources
2.1.3. RAQMONデータ送信端末を構成します。
In order to report statistics to RAQMON Report Collectors, RDSs will need to be configured with the following parameters:
統計をRAQMON Report Collectorsに報告するために、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 PDUsの時間間隔。 このパラメタを構成しなければならないので、連続したトランスミッションの間の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は、RDS設定パラメータにコマンドラインインタフェース(CLI)、Telephone User Interface(TUI)などを使用することで手動の構成を使用するかもしれません。
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はDynamic Host Configuration Protocol(DHCP)クライアントとして機能して、RRCにDHCPオプションとして情報を扱わせます。 - RDSはDNSとしてクライアントを演じて、DNS Serverから目標コレクタ情報を得ます。. --RDSはLDAP Clientとして機能して、ディレクトリルックアップを使用します。
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図式を定義するのを探検できました。
Siddiqui, et al. Standards Track [Page 7] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[7ページ]。
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仕様への承諾は前記のようにどんな特定の構成メカニズムの使用法も必要としません。 それは適切な状態で選ぶシステムのためにメカニズムに食糧を供給するimplementersに残されます。
2.2. RAQMON Report Collector (RRC)
2.2. RAQMONレポートコレクタ(RRC)
2.2.1. RAQMON Report Collector (RRC) Functional Architecture
2.2.1. RAQMONレポートコレクタ(RRC)機能的な建築
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)はRAQMON MIBに情報を複数のRDSsからRAQMON PDUsを受けて、分析して、保存します。 ストレージと集合ポイントをRDSsの1セットに供給して、RRCは、計算上才略にたけるように思い描かれます。
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 FrameworkはRDSsにRRCsを切り離すためにQoSパラメタを報告させます。 ベンダーは、1つのコミュニケーションセッションを表すために複数の管理ドメインの向こう側に異なったRRCsにある情報を関連させるように管理アプリケーションを開発できます。 しかしながら、そのようなアプリケーションレベル指定はこのメモの範囲を超えています。
2.2.2. RAQMON Report Collector (RRC) Requirements
2.2.2. RAQMONレポートコレクタ(RRC)要件
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 Report CollectorsはRAQMON Data Sources(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 Report Collectorsは[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 Collectorsは、時間の妥当な持続時間を届け出るのから脱していたRDSsを届け出る終わりを仮定するためにセッションタイムアウトメカニズムを実装しなければなりません。 そのようなタイムアウトパラメタSHOULD、ベンダー実装では、プログラマブルパラメタとして展開で構成可能であってください。
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 Report Collectorsは[RFC4711]で説明されるようにRAQMON-MIBモジュールをサポートして、raqmonCompliance MODULE-COMPLIANCE定義に関する承諾必要条件を満たさなければなりません。 性能監視情報があるRAQMON MIBの人口がトランスポート・プロトコルから独立しているか、またはプロトコルは以前はよくRDSsとRRCsの間まで情報を運びました。
Siddiqui, et al. Standards Track [Page 8] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[8ページ]。
2.3. Information Model and RAQMON Protocol Data Unit (PDU)
2.3. 情報モデルとRAQMONプロトコルデータ単位(PDU)
2.3.1. RAQMON Information Model
2.3.1. RAQMON情報モデル
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 Data Sourcesによって報告されるようにアプリケーションのQoSを特徴付ける1セットの基本的な測定基準を定義します。 この基本的なセットの測定基準はこのメモのセクション5で定義されます。 義務的なセットの測定基準がRDSによってサポートされるというどんな最小量の要件もありません。
Specific applications, new types of network appliances or new methods to measure and characterize the QoS of applications lead to the requirement for the information model to be extensible. To answer this need, the information model is designed so that vendors can extend it by adding new metrics.
特定のアプリケーション、ネットワーク器具かアプリケーションのQoSを測定して、特徴付ける新しいメソッドの新しいタイプは情報モデルが広げることができるという要件につながります。 この必要性、ベンダーが新しい測定基準を加えることによってそれを広げることができるようにモデルが設計されているという情報に答えるために。
Although NOT REQUIRED for RAQMON conformance, extensions of the information model can offer useful information for specific applications. An example of metrics that can extend the basic RAQMON information model are the detailed metrics for VoIP media monitoring and call quality included in the VoIP Metrics Report Block defined in [RFC3611].
RAQMON順応のためのNOT REQUIREDですが、情報モデルの拡大は特定のアプリケーションのために役に立つ情報を提供できます。 基本的なRAQMON情報モデルを広げることができる測定基準に関する例は、VoIPメディアモニターのための詳細な測定基準であり、[RFC3611]で定義されたVoIP Metrics Report Blockに品質を含んでいて、呼びます。
The RAQMON Information model is expressed by defining a conceptual RAQMON Protocol Data Unit (PDU).
RAQMON情報モデルは、概念的なRAQMONプロトコルData Unit(PDU)を定義することによって、表されます。
2.3.2. RAQMON Protocol Data Unit
2.3.2. RAQMONプロトコルデータ単位
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プロトコルData Unit(PDU)はRDSsとRRCsに解釈された一般的なデータの形式です。 RAQMON PDUはアプリケーションデータを輸送しませんが、プロトコル・スタックの応用層でむしろペイロード仕様の場所を占領します。 異なった輸送マッピングは、RDSsとRRCsの間までRAQMON PDUを運ぶのに使用されるかもしれません。 トランスポート・プロトコル要件はこのメモのセクション2.4で定義されています。
Though architected conceptually as a single PDU, the RAQMON PDU is functionally divided into two different parts. They are the BASIC part, and the Application-Specific Extensions, required for application-, vendor-, and device-specific extensions.
独身のPDUとして概念的にarchitectedされますが、RAQMON PDUは2つの異なった部品に機能上分割されます。 それらは部分、およびApplication特有のExtensionsがアプリケーション、ベンダー、およびデバイス特有の拡大のために必要としたBASICです。
The BASIC part of the RAQMON PDU:
The BASIC part of the RAQMON PDU follows the SMI Network
Management Private Enterprise Code 0, indicating an IETF standard
construct. The RAQMON PDU BASIC part offers an entry-type from a
pre-defined list of QoS parameters defined in Section 5 and allows
applications to fill in appropriate values for those parameters.
Application developers also have the flexibility to make an RDS
report built only of a subset of the parameters listed in
RAQMON PDUのBASIC一部: RAQMON PDUのBASIC一部がSMI Network Management兵士のエンタープライズCode0に続きます、IETFの標準の構造物を示して。 RAQMON PDU BASIC部分は、セクション5で定義されたQoSパラメタの事前に定義されたリストからエントリータイプを申し出て、アプリケーションがそれらのパラメタのために適切な値に記入するのを許容します。 また、アプリケーション開発者には、パラメタの部分集合だけにおける組立のレポートが記載したRDSを作る柔軟性があります。
Siddiqui, et al. Standards Track [Page 9] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[9ページ]。
Section 5. There is no need to carry all metrics in every PDU;
moreover, it is RECOMMENDED that static or pseudo-static metrics
that do not change or seldom change for a given session or
application will be send only when the session or application are
initiated, and then at large time intervals.
セクション5。 すべての測定基準を運ぶ必要は全くあらゆるPDUにあるというわけではありません。 そのうえ、開始されて、与えられたセッションかアプリケーションがセッションかアプリケーションであるときにだけ、発信するためにことになるので変化するか、またはめったに変化する静的であるか疑似静的な測定基準がそして、大きい時間間隔で、そうするのは、RECOMMENDEDです。
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のApplication部分: すべてのアプリケーションの需要を満たすBASIC一部を構造化するのが難しいので、RAQMONは今後の使用のためのアプリケーション、ベンダー、およびデバイス特有のパラメタを伝える拡大能力を提供します。 アプリケーション開発者かベンダーがPDUのAPP部分のペイロードの中に追加パラメタを定義できます。 RAQMON PDUのアプリケーション部分の定義の所有者は兵士のエンタープライズCodeが http://www.iana.org/assignments/enterprise-numbers で定義したベンダーのSMI Network Managementによって示されます。 そのようなアプリケーション特有の拡大は、アプリケーションベンダーによって維持されて、発行されるべきです。
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とRRCsは全体の報告セッションのために状態がなくなるように設計されていますが、フレームワークは報告の終わりの指示を必要とします。 この目的、RDS MUSTがRAQMON NULL PDUを送るので。 NULL PDUはALL NULL値(すなわち、報告するために何でもない)を含むRAQMON PDUです。
2.4. RDS/RRC Network Transport Protocol Requirements
2.4. RDS/RRCネットワークトランスポート・プロトコル要件
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. トランスポート・プロトコルSHOULDは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. スケーラビリティ--RRCsが、多くのRDSs(多くの10、多くの数百、または以上)と対話する必要があるので、トランスポート・プロトコルのスケーラビリティはREQUIREDです。
3. Congestion safety - as per [RFC2914]. See also Section 3.
3. [RFC2914]に従って混雑安全。 また、セクション3を見てください。
Siddiqui, et al. Standards Track [Page 10] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[10ページ]。
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統計がトランジットにおける不当開示と変更から保護を必要とする機密のシステム情報を運ぶかもしれないので、データ暗号化と保全が適用されるのを強い安全なモードを前提とするか、または許容するトランスポート・プロトコルはREQUIREDです。
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味方--トランスポート・プロトコルSHOULDは[RFC3235]に従います、RDSがFirewall/ネットワークAddress Translationデバイスを通して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. トランスポート・プロトコルは、時間の妥当な持続時間を届け出るのから脱していたRDSsを届け出る終わりを仮定するためにセッションタイムアウトメカニズムを実装するかもしれません。 そのようなタイムアウトパラメタSHOULD、ベンダー実装で構成可能であって、展開でプログラマブルになってください。
7. Reliability - The RAQMON Framework expects PDUs to operate in
lossy networks. However, retransmission is not included in the
RAQMON framework, in order to keep the design simple. If
retransmission is a necessity, RAQMON MAY operate over
transport protocols, such as TCP.
7. 信頼性--RAQMON Frameworkは、PDUsが損失性ネットワークで作動すると予想します。 しかしながら、「再-トランスミッション」は、デザインを簡単に保つためにRAQMONフレームワークに含まれていません。 「再-トランスミッション」が必要性であるなら、RAQMON MAYは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 PDUsがメッセージ(パケット)よりむしろ連続した八重奏ストリームの抽象化を提供する基本的なプロトコルで運ばれるつもりであるなら、縁どりメカニズムを提供するために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]のようなさらなるメモはPDUが通信制御プロトコル(TCP)やSimple Network Managementプロトコル(SNMP)のような既存のプロトコルの上でどう輸送されるかを説明します。
3. RAQMON Operation in Congestion-Safe Mode
3. 混雑安全なモードにおけるRAQMON操作
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 PDUsを伝えることができます。 RAQMON PDUがTCPの上で輸送されるなら、RAQMON Frameworkは混雑金庫になるでしょう。
One solution to the congestion awareness problem could have been to discourage the use of UDP entirely for RAQMON. Though RAQMON PDUs can be transported over TCP, some transports like SNMP over TCP are not commonly practiced in practical deployments.
混雑認識問題への1つの解決はUDPの完全なRAQMONの使用に水をさしていることであったかもしれません。 TCPの上でRAQMON PDUsを輸送できますが、TCPの上のSNMPのようないくつかの輸送は実用的な展開では一般的に練習されません。
Siddiqui, et al. Standards Track [Page 11] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[11ページ]。
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 PDUsによってさらにいらいらさせられるかもしれません。 また、RAQMON PDU輸送の基礎となるとしてDCCPなどのトランスポート・プロトコルを使用できます。(輸送は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 Frameworkの中では、道に従う際に混雑安全を達成できます:
1. Constant Transmission Rate: In a well-managed network, a
constant transmission rate policy (e.g., 1 RAQMON PDU per
device every N seconds) will ensure congestion safety as
devices are introduced into the network in a controlled manner.
For example, in an enterprise network, IP Phones are added in a
controlled manner, and a constant transmission rate policy can
be sufficient to ensure congestion-safe operation. The
configured rate needs to be related to the expected peak number
of devices. As a worst-case scenario, if the RDSs enforce an
administrative policy where the maximum PDU transmission rate
is no more than one RAQMON PDU every two minutes, a UDP-based
implementation can be as congestion safe as a TCP-based
implementation. Such policies can be enforced while
configuring RDSs, and the timers for the constant rate need to
be randomly jittered.
1. 一定の通信速度: よく管理されたネットワーク、一定の通信速度方針、(例えば、1デバイスあたり1RAQMON PDU、あらゆる、N秒) デバイスが制御方法でネットワークに取り入れられるとき、混雑安全を確実にするでしょう。 例えば、企業網では、IP電話は制御方法で加えられます、そして、一定の通信速度方針は、混雑安全操業を確実にするために十分である場合があります。 構成されたレートは、デバイスの予想されたピーク番号に関連される必要があります。 最悪の事態のシナリオとして、RDSsが最大のPDU通信速度が2分毎の1RAQMON PDUである施政方針を実施するなら、TCPベースの実装としての混雑金庫としてUDPベースの実装があることができます。 RDSsを構成している間、そのような方針を励行されることができます、そして、一定のレートのためのタイマは手当たりしだいにjitteredされる必要があります。
2. Single outstanding requests: This approach requires that a
request be sent at the application level, then there is a wait
for some sort of response indicating that the request was
received before sending anything else. This produces an effect
described by some as "ping-ponging": traffic bounces back and
forth between two nodes like a ping-pong ball in a match.
Since there's only one ball in play between any two players at
any given time, most of the potential for congestion cascades
is eliminated. For reliability and efficiency reasons, this
technique must include backed-off retransmissions. For
example, if RAQMON PDUs are transported using SNMP INFORM PDUs
over UDP, a SNMP response from the RRC SHOULD be processed by
the RDS to implement this mechanism. [RFC4712] specifies that
2. ただ一つの傑出している要求: このアプローチは、要求がアプリケーションレベルで送られるのを必要として、次に、ある種の応答のための他の何かを送る前に要求が受け取られたのを示す待ちがあります。 これはいくつかによって「ピングに悪臭を放ちます」と説明された効果を生みます: トラフィックはマッチの卓球のボールのような2つのノードの間で前後まで弾みます。 その時々で、どんな2人のプレーヤーの間にはも、プレーに1個のボールしかないので、混雑カスケードの可能性の大部分は排除されます。 信頼性と効率理由で、このテクニックは引き返している「再-トランスミッション」を含まなければなりません。 例えば、RAQMON PDUsがRRC SHOULDからUDPの上のSNMP INFORM PDUs、SNMP応答を使用することで輸送されるならRDSが処理されて、このメカニズムを実装してください。 [RFC4712]はそれを指定します。
Siddiqui, et al. Standards Track [Page 12] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[12ページ]。
if the SNMP notifications transport mapping mechanism is
implemented, it is RECOMMENDED to use INFORM PDUs, and it is
NOT RECOMMENDED to use Trap PDUs.
メカニズムを写像するSNMP通知輸送が実装されるなら、それはINFORM PDUsを使用するRECOMMENDEDです、そして、Trap PDUsを使用するNOT RECOMMENDEDです。
This pacing or serialization approach has the side-effect of
significantly reducing the maximum throughput, as transmission
occurs in only one direction at a time and there is at least a
2xRTT (round-trip time) delay between transmissions. More
sophisticated algorithms (such as those in TCP and Stream
Control Transmission Protocol (SCTP)) have been developed to
address this, and it would be inappropriate to duplicate that
work at the application level. Consequently, if greater
efficiency is required than that provided by this simple
approach, implementers SHOULD use TCP, SCTP, or another such
protocol. But if one absolutely must use UDP, this approach
works. It has been also used in other application scenarios
like SIP over UDP.
このペースか連載アプローチには、最大のスループットをかなり減らす副作用があります、トランスミッションが一度に、一方向だけに起こって、トランスミッションの間に少なくとも2xRTT(往復の時間)遅れがあるとき。 これを扱うために、より高度なアルゴリズム(TCPとStream Control Transmissionプロトコル(SCTP)のそれらなどの)を開発してあります、そして、アプリケーションレベルでその仕事をコピーするのは不適当でしょう。 その結果implementers SHOULDがこの簡潔な解決法で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)レートでインタフェースから一般的に伝えられます、介入しているネットワーク状態の認識なしで。 これらの理由で、一般に、それは、大きいPDUsをUDPの上に送るために悪い習慣であると考えられます。 MTUサイズが実装として知られているなら、RDSは、アプリケーションに断片化の効果を減少させるためにUDPの上に詳しい情報をトランスミッションのサイズを制限することによって、送らせるべきではありません。 補欠、RDS MAYが、まさに同じNetwork Timeプロトコル(NTP)[RFC1305]時間でまた、複数のRAQMON PDUsの上でパラメタをRRCに送りますが、彼らが同じ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が知られていて、それが値のSHOULDであるところに、いてください。代わりに使用されます。
4. Irrespective of choice of transport protocol, it is also
RECOMMENDED that no more than 10% network bandwidth be used for
RDS/RRC reporting. More frequent reports from an RDS to RRC
would imply requirements for higher network bandwidth usage.
4. トランスポート・プロトコルの選択において関係ありません、また、10%未満のネットワーク回線容量がRDS/RRC報告に使用されるのは、RECOMMENDEDです。 より頻繁なRDSからRRCまでのレポートは、より高度なネットワーク回線容量用法のための要件を含意するでしょう。
Siddiqui, et al. Standards Track [Page 13] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[13ページ]。
4. Measurement Methodology
4. 測定方法論
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パラメタのどれかを測定することを勧めるのは、このドキュメントの意図ではありません。 測定アルゴリズムが選ぶのがimplementersと設備ベンダーに残されます。 測定アプリケーション性能に利用可能な多くの異なった測定方法論があります。 これらは徹底的調査ベースの、そして、クライアントベースの、そして、合成のトランザクションの、そして、他のアプローチを含んでいます。 この仕様は、特定の方法論を強制しないで、必要最小限を満たすどんな方法論にも開かれています。 この仕様への順応のために、集まっているデータがここに説明された意味論に合っているのは、REQUIREDです。 しかしながら、ベンダー使用IETFによって定義されるのと国際電気通信連合(ITU)が可能であるときに、パラメタを測定するために方法論を指定したのは、RECOMMENDEDです。
5. Metrics Pre-Defined for the BASIC Part of the RAQMON PDU
5. RAQMON PDUの基本的な部分に事前に定義された測定基準
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のBASIC一部がServiceの終わりからエンドへのアプリケーションQualityを特徴付けるのにアプリケーションで頻繁に使用される事前に定義されたパラメタのリストに備えます。 このセクションはRAQMON PDUのBASIC一部に含まれるように1セットの簡単な測定基準を定義します、既存のIETFの参照、ITU、および他の規格組織のドキュメントを通して。 適切な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>組として、または、変項束縛リストとしてBASIC一部に含まれていなかったアプリケーションとベンダー特殊情報は加えることができます。 ベンダーか他の組織によって独自に管理されたこれらの拡大は、より広い相互運用性のために発行されるべきです。
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.
アプリケーションには、このセクションで言及されたすべてのパラメタを報告するのが必要ではありませんが、これらのパラメタの部分集合がアプリケーション文脈に適切であると報告する柔軟性があるべきです。 メモは承諾ために、さらに、RDSsがすべてのPDUsに含まなければならないパラメタを特定します、RDSsが必要に応じて報告するかもしれない任意のパラメタと同様に。 ここに提示された定義は指導をimplementersに供給することになっています、そして、IETFのメートル法の定義参照はそれぞれメートル法で備えられます。 アプリケーション開発者は彼らのアプリケーションの必要性に適切な測定基準を選ぶべきです。 ここで特定されたパラメタの構文の表現を[RFC4712]仕様に提供します。
Siddiqui, et al. Standards Track [Page 14] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[14ページ]。
5.1. Data Source Address (DA)
5.1. データ送信端末アドレス(DA)
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].
Data Source Address(DA)はデータ送信端末のアドレスです。 これは、個人的にグローバルにユニークなIPv4かIPv6アドレスかaのどちらかであるかもしれません。IPv4は[RFC1918]で定義されるようにアドレスを割り当てました。
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 SHOULDは、あまりにも頻繁にネットワーク資源の効率的な使用法を確実にするためにRAQMONレポートの中でこれらのパラメタを送るのを避けます。
5.2. Receiver Address (RA)
5.2. 受信機アドレス(RA)
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].
Receiver Address(RA)はData Source Address(DA)と同じ形を取りますが、ReceiverのAddressを表します。 コミュニケーションセッションのときに、報告しているRDSs SHOULDはReceiver Addressとして相手のアドレスに記入します。 Data Source Addressのように、これは、[RFC1918]で定義されるようにグローバルにユニークなIPv4かIPv6アドレスか個人的に割り当てられたIPv4アドレスのどちらかであるかもしれません。
It is expected that the Receiver Address (RA) would remain constant within a given communication session. RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
Receiver Address(RA)が与えられたコミュニケーションセッション以内に一定のままで残っていると予想されます。 RDSs SHOULDは、ネットワーク資源の効率的な使用法を確実にするためにRAQMONレポートの中であまりにも頻繁にこれらのパラメタを送るのを避けます。
5.3. Data Source Name (DN)
5.3. データ送信端末名(DN)
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:
アプリケーションによってData Source Name(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であるなら「接待します」。 または、例が命名する使用が" big-guy@example.com "である、「大きい奴の@、192.0、.2、0.178インチ、マルチユーザーシステム、」 ユーザ名のないシステムの上では、例は"ip-phone4630.example.com"でしょう。 標準のホストの数値アドレスがDNパラメタで報告されないのは、RECOMMENDEDです、DAパラメタがそのために使用されるとき。
- 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、またはいかなる他のフォームの電話かポケットベル番号であるかもしれません。 電話番号SHOULDは、aでフォーマットされて、国際的なアクセスコードを置き換えながら、署名します。 例: イギリスの数のための「+44-116-496-0348。」
Siddiqui, et al. Standards Track [Page 15] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[15ページ]。
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 SHOULDは、ネットワーク資源の効率的な使用法を確実にするためにRAQMONレポートの中であまりにも頻繁にこれらのパラメタを送るのを避けます。
5.4. Receiver Name (RN)
5.4. 受信機名(Rn)
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.
Receiver Name(RN)はDNと同じ形を取りますが、Receiverの名前を表します。 コミュニケーションセッション、SHOULDが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 SHOULDは、ネットワーク資源の効率的な使用法を確実にするためにRAQMONレポートの中であまりにも頻繁にこれらのパラメタを送るのを避けます。
5.5. Data Source Device Port Used
5.5. ポートが使用したデータ送信端末デバイス
This parameter indicates the source port used by the application for a particular session or sub-session in communication. Examples of ports include TCP Ports or UDP Ports, as used by communication application protocols such as Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), H.323, RTP, HyperText Transport Protocol (HTTP), and so on.
このパラメタはコミュニケーションにおける特定のセッションかサブセッションにアプリケーションで使用されるソースポートを示します。 ポートに関する例はTCP PortsかUDP Portsを含んでいます、Session Initiationプロトコルなどのコミュニケーションアプリケーション・プロトコルによって使用されるように(SIP)、Instant MessagingとPresence Leveraging Extensions(SIMPLE)のためのSIP、H.323、RTP(プロトコル(HTTP)であって、とてもオンなHyperText Transport)
This parameter MUST be sent in the first RAQMON PDU.
最初のRAQMON PDUでこのパラメタを送らなければなりません。
5.6. Receiver Device Port Used
5.6. ポートが使用した受信機デバイス
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 Ports、またはSIP、SIMPLE、H.323、RTP、HTTPなどのコミュニケーションアプリケーション・プロトコルによって使用されるUDP Portsを含んでいます。
This parameter MUST be sent in the first RAQMON PDU.
最初のRAQMON PDUでこのパラメタを送らなければなりません。
5.7. Session Setup Date/Time
5.7. セッションセットアップ日付/時間
This parameter gives the time when the setup was initiated, if the application has a setup phase, or when the session was started, if such a setup phase does not exist. The time is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC (Coordinated Universal Time) on 1 January 1900 [RFC1305].
このパラメタはアプリケーションにセットアップフェーズがあるならセットアップが着手されたか、またはセッションが始められた時を与えます、そのようなセットアップフェーズが存在していないなら。 時間は、秒に1900年1月1日[RFC1305]の0h UTC(協定世界時)に比例しているNetwork Timeプロトコル(NTP)のタイムスタンプ形式を使用することで表されます。
This parameter SHOULD be sent only in the first RAQMON PDU, after the session setup is completed.
最初のRAQMON PDUだけでこのパラメタSHOULDを送って、セッションの後に、セットアップは終了しています。
Siddiqui, et al. Standards Track [Page 16] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[16ページ]。
5.8. Session Setup Delay
5.8. セッションセットアップ遅れ
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.
確立(または、遠く離れたホスト/終点から受けられるセッション進歩指示)であって、ミリセカンドで言い表されて、創作からかかる時間がメディア経路にホスト/終点によって開始されていた状態で存在を要求するというSession Setup Delayのメートル法のレポート。 例えば、VoIPシステムでは、最後のDTMF(二元的なトーン多重周波数)ボタンからの間隔が遠端が鳴っているのを示す最初のリング逆トーンに押されたので、セッション準備時間を測定できます。 別の例はSIP呼び出しのSession Setup Delayでしょう。(INVITEがUserエージェントによって生成される時の間の経過時間であって200OKがいつ受信されているかとそれは、測定されます)。
This parameter SHOULD be sent only in the first RAQMON PDU, after the session setup is completed.
最初のRAQMON PDUだけでこのパラメタSHOULDを送って、セッションの後に、セットアップは終了しています。
5.9. Session Duration
5.9. セッション持続時間
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.
どれくらい長いセッションかサブセッションが持続したSession Durationのメートル法のレポート。 これほどメートル法であることは、アプリケーションです。文脈敏感です。 例えば、経過時間として呼び出しピックアップと呼び出し終了の間でVoIP Call Session Durationを測定できます、セッション準備時間を含んでいて。
This parameter SHOULD be sent only in the first RAQMON PDU, after the session is terminated.
最初のRAQMON PDUだけでこのパラメタSHOULDを送って、後に、セッションは終えられます。
5.10. Session Setup Status
5.10. セッションセットアップ状態
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.
Session Setup Statusメートル法、セッションのコミュニケーション状態を報告することを意図します。 値は首尾よくCall Progressing、Call Establishedなどの適切なコミュニケーションセッション州を特定します、「試みます」、「再試行し」て、「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.
セッションセットアップ状態はアプリケーションの文脈で重要です。 この理由のために、アプリケーションSHOULDは測定基準というセクション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.
このパラメタSHOULD、セッション状態の各変化の後に送ってください。
Siddiqui, et al. Standards Track [Page 17] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[17ページ]。
5.11. Round-Trip End-to-End Network Delay
5.11. 終わりから終わりへの往復のネットワーク遅延
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.
Round-旅行のEndから終わりへのRTPをひくアプリケーションのための[RFC3550]と他のすべてのIPアプリケーションのための[RFC2681]で定義されたNetwork DelayはApplication QoS Monitoringにおける、メートル法のキーです。 ホストの間の終わりから終わりへの遅れが何らかの閾値に比例して大きいなら、いくつかのアプリケーションはよく振る舞いません(全く)。 遅れ値の不安定な変化はボイス・オーバー IPなどのリアルタイムの多くのアプリケーションをサポートするのを難しい、そして、(不可能)であるのにします、IPの上のVideo、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.
Endから終わりへの基本的な転送ネットワークのRound-旅行Network遅れは、他のIPアプリケーションにRTPのための[RFC3550]と[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]のサポートかApplication Name(セクション5.32)の始めのストリング'RTP'の包含で決定できます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSに値を決定する能力があるなら各RAQMON PDUで送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.12. One-Way End-to-End Network Delay
5.12. 終わりから終わりへの一方向ネットワーク遅延
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.
One-道のEndから終わりへの遅れがトラフィックでソースから目的地まで遭遇したOne-道のEndから終わりへのNetwork Delay[RFC2679]のメートル法のレポートはインタフェースをネットワークでつなぎます。 IPパフォーマンスMetrics(IPPM)作業部会[RFC2679]によって特定された1方法のDelay測定は、終わりから終わりへの一方向ネットワーク遅延を測定するのに使用されるでしょう。
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つの異なった経路の性能を一緒に測定します。
Siddiqui, et al. Standards Track [Page 18] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[18ページ]。
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(非同期なTransfer Mode)対Packet過剰Sonet(同期Optical)転送ネットワークに研究してください)。
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).
インターネット経路が左右対称であると(すなわち、Round-旅行Delayを2に割ります)仮定することによって、RAQMON SHOULD NOTはOne-道のEndから終わりへのNetwork Delayを引き出します。
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で送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.13. Application Delay
5.13. アプリケーション遅れ
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に概説されている様々なNetwork Delayバージョンはバッファリング、外でプレーするパケット順序制御、コード化/解読などに関連している遅れを含んでいません、端末装置で。 これが区分するApplication Delayメートル法の定義されたコネはそのようなすべての遅れがパラメタであるとキャプチャするために狙います、総アプリケーション終点遅れを提供して。
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,
ネットワーク・インターフェースとアプリケーションレベルプレゼンテーションに取り入れられる時間遅れとしてアプリケーション遅れを言い表すことができます。 以来、いろいろなアプリケーションの用法を思い描くのは難しいです。
Siddiqui, et al. Standards Track [Page 19] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[19ページ]。
the following guidance is provided to the implementers to measure the application delay:
アプリケーション遅れを測定するために以下の指導をimplementersに提供します:
- 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で送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.14. Inter-Arrival Jitter
5.14. 相互到着ジター
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).
Inter-到着Jitterメートル法、ネットワークの混雑[RFC3550]の短期的な手段を提供します。 パケット損失に通じる前にジター測定は混雑を示すかもしれません。 相互到着ジター分野は、RAQMON PDUが発生しているときのジターのスナップだけであり、[RFC3550]にみられるように量的に取られることを意図しません。 むしろ、それは時間がたつにつれて、1台の受信機からの相互到着ジターの比較のために意図します。 そのような相互到着ジター情報は、ボイス・オーバー IP、IPの上のVideoなどのあるアプリケーションの働きを理解するために非常に役に立ちます。 また、相互到着ジター情報は、アプリケーションにパケット(例えば、声か外でビデオプレーする)の定期的な配送を必要としながら、プレーの出ているバッファのサイズ処理で使用されます。
Siddiqui, et al. Standards Track [Page 20] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[20ページ]。
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]では、選択機能はそれとなく連続したパケット組に適用されます、そして、「ジター見積り」は、(すなわち、j_新しい=_古い15/16*j+1/16*j_新しい)で見積りを生成するためにパラメタ1/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で送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.15. IP Packet Delay Variation
5.15. IPパケット遅れ変化
[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 Packet Delay Variation(ipdv)の[RFC3393]定義を使用します。 IP Delay Variationメートル法、与えられたリンクかリンクの組み合わせのときに待ち行列長さのプロセスで遅れ変化における変化を変化にリンクできるネットワーク(または、ルータ)の中で待ち行列の力学を決定するために、使用されます。 IP Network性能に関連するとき、そのようなパラメタはアプリケーションレベル性能問題のIP Networkと、より良い理解の中で目に見えることを提供します。
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で送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.16. Total Number of Application Packets Received
5.16. 総数のアプリケーションパケットは受信されました。
This metric reports the number of application payload packets received by the RDS as part of this session since the last RAQMON PDU was sent up until the time this RAQMON PDU was generated.
このRAQMON PDUが生成された時まで最後のRAQMON PDU以来アプリケーションペイロードパケットの数がこのセッションの一部としてRDSで受け取ったこのメートル法のレポートを送りました。
This parameter represents a very simple incremental counter that counts the number of "application" packets that an RDS has received. Application packets MAY include signaling packets. Since this count is a snapshot in time, depending on application type, it also varies based on the application states, e.g., an RDS within an application session will report the aggregated number of application packets that were sent out during signaling setup, media packets received, session termination, etc.
このパラメタはRDSが受けた「アプリケーション」パケットの数を数える非常に簡単な増加のカウンタを表します。 アプリケーションパケットは、パケットに合図するのを含むかもしれません。 アプリケーションタイプに頼っていて、時間内にこのカウントがスナップであるので、また、アプリケーション状態に基づいて異なります、例えば、アプリケーションセッション以内のRDSはシグナリングセットアップ、パケットが受け取ったメディア、セッション終了などの間に出されたアプリケーションパケットの集められた数を報告するでしょう。
For example, during Voice over IP or Video over IP sessions setup, this counter represents the number of signaling-session-related packets that have been received that will be derived from the relevant application signaling protocol stack such as SIP or H.323, SIMPLE, and various other signaling protocols used by the application to establish the communication session.
例えば、IPセッションセットアップの上のボイス・オーバー IPかVideoの間、このカウンタはプロトコルがコミュニケーションセッションを証明するのにアプリケーションで使用したSIPかH.323などのプロトコル・スタックを示す関連アプリケーション、SIMPLE、および他の様々なシグナリングから得られる受け取られたシグナリングセッション関連のパケットの数を表します。
Siddiqui, et al. Standards Track [Page 21] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[21ページ]。
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 Framesの数を暗示するでしょう。 アプリケーションがどこでRTPを使用しても、RTPフレームを数えるためにRTCP SR/RRレポート[RFC3550]の中で説明された方法論は適用されるでしょう。 これが累積しているカウンタであり、アプリケーションは、ゼロから数えながら、カウンタオーバフローと再開の可能性を考慮に入れる必要があります。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートはアプリケーションを実行するホストでのRTP MIB[RFC2959]のサポートかApplication Name(セクション5.32)の始めのストリング'RTP'の包含で決定できます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSに値を決定する能力があるなら各RAQMON PDUで送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.17. Total Number of Application Packets Sent
5.17. 総数のアプリケーションパケットは発信しました。
This metric reports the number of signaling and payload packets sent by the RDS as part of this session since the last RAQMON PDU was sent until the time this RAQMON PDU was generated. Applications packets MAY include signaling packets. Similar to the total number of application packets received parameter in Section 5.16, this count is a snapshot in time. Depending on the application type, the counter also varies based on various application states, including packet counts for signaling setup, media establishment, session termination states, and so on. This being a cumulative counter, applications need to take into consideration the possibility of the counter overflowing and restarting counting from zero.
シグナリングとペイロードパケットの数が時間まで最後のRAQMON PDUを送って以来のこのセッションの一部としてのRDSでこの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で送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.18. Total Number of Application Octets Received
5.18. 総数のアプリケーション八重奏は受信されました。
This metric reports the total number of signaling and payload octets received in packets by the RDS as part of this session since the last RAQMON PDU was sent, up until the time this RAQMON packet was generated. Applications octets MAY include signaling octets. The methodology described by [RFC3550] will be applied wherever applications use RTP. This being a cumulative counter, applications need to take into consideration the possibility of the counter overflowing and restarting counting from zero.
シグナリングとペイロード八重奏の総数が最後のRAQMON PDUを送って以来のこのセッションの一部としてパケットにRDSで受け取ったこのメートル法のレポート、時間まで、このRAQMONパケットは生成されました。 アプリケーション八重奏は、八重奏に合図するのを含むかもしれません。 アプリケーションがどこでRTPを使用しても、[RFC3550]によって説明された方法論は適用されるでしょう。 これが累積しているカウンタであり、アプリケーションは、ゼロから数えながら、カウンタオーバフローと再開の可能性を考慮に入れる必要があります。
Siddiqui, et al. Standards Track [Page 22] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[22ページ]。
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]のサポートかApplication Name(セクション5.32)の始めのストリング'RTP'の包含で決定できます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSに値を決定する能力があるなら各RAQMON PDUで送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.19. Total Number of Application Octets Sent
5.19. 総数のアプリケーション八重奏は発信しました。
This metric reports the total number of signaling and payload octets received in packets by the RDS as part of this session since the last RAQMON PDU was sent, up until the time this RAQMON packet was generated. This is similar to the Total Number of Application Octets Received metric. Applications octets MAY include signaling octets. The methodology described by [RFC3550] will be applied wherever applications use RTP. This being a cumulative counter, applications need to take into consideration the possibility of the counter overflowing and restarting counting from zero.
シグナリングとペイロード八重奏の総数が最後のRAQMON PDUを送って以来のこのセッションの一部としてパケットにRDSで受け取ったこのメートル法のレポート、時間まで、このRAQMONパケットは生成されました。 これはApplication Octets ReceivedのTotal Numberとメートル法であることで同様です。 アプリケーション八重奏は、八重奏に合図するのを含むかもしれません。 アプリケーションがどこでRTPを使用しても、[RFC3550]によって説明された方法論は適用されるでしょう。 これが累積しているカウンタであり、アプリケーションは、ゼロから数えながら、カウンタオーバフローと再開の可能性を考慮に入れる必要があります。
Support for RTP can be determined by the support of the RTP MIB [RFC2959] in the hosts running the applications or by inclusion of the string 'RTP' at the beginning of the Application Name (Section 5.32).
RTPのサポートはアプリケーションを実行するホストでのRTP MIB[RFC2959]のサポートかApplication Name(セクション5.32)の始めのストリング'RTP'の包含で決定できます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSに値を決定する能力があるなら各RAQMON PDUで送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.20. Cumulative Packet Loss
5.20. 累積しているパケット損失
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
基本的な輸送によるパケット損失は測定使用がRTPトラフィックのための[RFC3550]と他のIPトラフィックのための[RFC2680]で説明された方法論であったならSHALLをネットワークでつなぎます。 予想されたパケットの数は、広げることであることのように最後の一連番号が受けたなるように定義されるように定義されます。
Siddiqui, et al. Standards Track [Page 23] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[23ページ]。
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]のAppendix 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]で説明された方法論であったならSHALLをネットワークでつなぎます。 予想されたパケットの数は広げることであることのように最後の一連番号が受けたなるように次に定義されるように定義されて、以下は受け取られた初期シーケンス番号です。 RTPトラフィックにおいて、これは、[RFC3550]のAppendix 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]のサポートかApplication Name(セクション5.32)の始めのストリング'RTP'の包含で決定できます。
This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the capability of determining its value and if the parameter is relevant for the application.
RDSに値を決定する能力があるなら各RAQMON PDUで送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.21. Packet Loss in Fraction
5.21. 断片におけるパケット損失
The Packet Loss in Fraction metric represents the packet loss as defined above, but expressed as a fraction of the total traffic over time.
上で定義されますが、トラフィックが時間がたつにつれて合計の部分として言い表されるので、Fractionのメートル法のPacket Lossはパケット損失を表します。
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で送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.22. Cumulative Application Packet Discards
5.22. 累積しているアプリケーションパケット破棄
The RAQMON Framework allows applications to distinguish between packets lost by the network and those discarded due to jitter and other application-level errors. Though packet loss and discards have an equal effect on the quality of the application, having separate counts for packet loss and discards helps identify the source of quality degradation.
RAQMON Frameworkはアプリケーションにネットワークによって失われたパケット、ジターのため捨てられたもの、および他のアプリケーションレベル誤りを見分けさせます。 パケット損失と破棄はアプリケーションの品質に均等効果を持っていますが、パケット損失と破棄のための別々のカウントを持っているのは、品質劣化の源を特定するのを助けます。
The packet discard metric indicates packets discarded locally by the device over time. Local device-level packet discard is captured as the total number of application-level packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer, or any other application-specific reasons.
パケットはメートル法で捨てられます。パケットが時間がたつにつれてデバイスによって局所的に捨てられたのを示します。 ソースからのレセプションの始まり以来捨てられているアプリケーションレベルパケットの総数として地方のデバイスレベルパケット破棄を得ます、経営の下の遅いか早めの到着か受信ジターバッファ、またはいかなる他のアプリケーション特有の理由におけるオーバーフローのためも。
Siddiqui, et al. Standards Track [Page 24] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[24ページ]。
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で送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.23. Packet Discards in Fraction
5.23. 断片におけるパケット破棄
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で送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.24. Source Payload Type
5.24. ソース有効搭載量タイプ
The source payload type reports payload formats (e.g., media encoding) as sent by the data source, e.g., ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII, etc. This memo follows the definition of Payload Type (PT) in [RFC3551]. For example, to indicate that the source payload type used for a session is PCMA (pulse-code modulation with A-law scaling), the value of the source payload field for the respective session will be 8.
ソースペイロードタイプレポートペイロードはデータ送信端末、例えば、ITU G.711、ITU G.729B、H.263、MPEG-2、ASCIIなどで送るように(例えば、メディアコード化)をフォーマットします。 このメモは[RFC3551]との有効搭載量Type(太平洋標準時の)の定義に続きます。 例えば、セッションに使用されるソースペイロードタイプがPCMA(A-法のスケーリングがあるパルスコード変調)であることを示すために、それぞれのセッションのためのソースペイロード分野の値は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 SHOULDは、ネットワーク資源の効率的な使用法を確実にするために必要とするより(例えば、ダイナミックなコーデック変化の)RAQMONレポートの中でさらにしばしばこれらのパラメタを送るのを避けます。
If dynamic types (values 96 to 127, according to [RFC3551]) are being used to identify the source payload type, a RAQMON extension parameter MAY be defined to indicate the MIME subtypes. In the case where the RDS does send reports noting dynamic codec changes, there may be instances where this extension parameter is used only before or after the codec change, as the source payload may shift between the dynamic and static types.
ダイナミックなタイプ([RFC3551]に従って、96〜127を評価する)がソースペイロードタイプを特定するのに使用されているなら、RAQMON拡大パラメタは、MIME血液型亜型を示すために定義されるかもしれません。 RDSがレポートにダイナミックなコーデック変化を注意させる場合には、インスタンスがこの拡大パラメタがコーデック変化の単に前または後に使用されるところにあるかもしれません、ソースペイロードがダイナミックで静的なタイプの間で移行するとき。
5.25. Receiver Payload Type
5.25. 受信機有効搭載量タイプ
The receiver payload type reports payload formats (e.g., media encodings) as sent by the other communicating party back to the source, e.g., ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII, etc. This document follows the definition of payload type (PT) in [RFC3551].
ソースへのパーティー、例えば、ITU G.711、ITU G.729B、H.263、MPEG-2、ASCIIなどを伝えるもう片方によって送られる受信機ペイロードタイプレポートペイロード形式(例えば、メディアencodings) このドキュメントは[RFC3551]とのペイロードタイプ(太平洋標準時の)の定義に続きます。
Siddiqui, et al. Standards Track [Page 25] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[25ページ]。
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 SHOULDは、ネットワーク資源の効率的な使用法を確実にするために必要とするより(例えば、ダイナミックなコーデック変化の)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がレポートにダイナミックなコーデック変化を注意させる場合には、インスタンスがこの拡大パラメタがコーデック変化の単に前または後に使用されるところにあるかもしれません、目的地ペイロードがダイナミックで静的なタイプの間で移行するとき。
5.26. Source Layer 2 Priority
5.26. ソース層2の優先権
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.
多くのデバイスがローカル・エリア・ネットワーク環境で、あるタイプのトラフィックを最優先させるLayer2技術を使用します。 例えば、「メディアアクセス制御ブリッジ」というIEEE 802.1D[IEEE802.1D]のEditionが含む1998は時間重要情報の伝達をサポートするトラフィック能力を速めました。 多くのデバイスが、IEEE P802.1pに従ったイーサネットフレームが標準であるとマークするのにその規格を使用します。 [IEEE802.1D]でこれらに関する詳細を見つけることができます。(それは、P802.1pを組み込みます)。 Source Layer2Priority RAQMON分野は、どんなLayer2値がローカル・エリア・ネットワーク環境でこれらのパケットを最優先させるためにRDSを実行するホストによって使用されたかを示します。
The Source Layer 2 Priority value is expected to remain constant for the duration of a session. Hosts running the RDSs SHOULD avoid sending these parameters within RAQMON reports too often in order to ensure an efficient usage of network resources.
Source Layer2Priority価値がセッションの持続時間に一定のままで残っていると予想されます。 RDSs SHOULDを実行するホストは、ネットワーク資源の効率的な使用法を確実にするためにRAQMONレポートの中であまりにも頻繁にこれらのパラメタを送るのを避けます。
5.27. Source TOS/DSCP Value
5.27. ソースTOS/DSCP価値
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.
インターネットでトラフィックを最優先させるために、様々なLayer3技術は適所にあります。 例えば、伝統的なIP Precedence[RFC791]とService(TOS)のType[RFC1812]か、Differentiated Services[RFC2474]のような、より最近の技術[RFC2475]がIPv4でTOS八重奏を使用しますが、トラフィッククラス八重奏は、IPv6でトラフィックを最優先させるのに使用されます。 ソースLayer TOS/DCP RAQMONは適切なLayer3値がこれらのパケットを最優先させるのにData Sourceで使用したレポートをさばきます。
Siddiqui, et al. Standards Track [Page 26] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[26ページ]。
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.
Source TOS/DSCP値がセッションの持続時間に一定のままで残っていると予想されます。 RDSs SHOULDを実行するホストは、ネットワーク資源の効率的な使用法を確実にするためにRAQMONレポートの中であまりにも頻繁にこれらのパラメタを送るのを避けます。
5.28. Destination Layer 2 Priority
5.28. 目的地層2の優先権
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.
Destination Layer2Priorityは、ローカル・エリア・ネットワーク環境でトラフィックをデータ送信端末に送る間、通信受信機によって使用されるLayer2値がパケットを最優先させると報告します。 Source Layer2Priorityのように、Destination Layer2Priorityは、目的地が優先権の列を作りのためのIEEE P802.1pのようなLayer2技術を使用したかどうかを示すことができました。
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.
Destination Layer2Priority価値がセッションの持続時間に一定のままで残っていると予想されます。 RDSs SHOULDを実行するホストは、ネットワーク資源の効率的な使用法を確実にするためにRAQMONレポートの中であまりにも頻繁にこれらのパラメタを送るのを避けます。
5.29. Destination TOS/DSCP Value
5.29. 目的地TOS/DSCP価値
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].
値がこれらのパケットを最優先させるのにData Receiverで使用したDestination TOS/DSCP RAQMON現地報告はソースのそばで受信されました。 Source Layer3Priorityと同様です、Destination Layer3Priorityは目的地が何かService(TOS)のIP Precedence[RFC791]とTypeのようなLayer3技術[RFC1812]、またはDifferentiated Service[RFC2474]のような、より最近の技術[RFC2475]を使用したかどうかを示します。
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.
Destination TOS/DSCP値がセッションの持続時間に一定のままで残っていると予想されます。 RDSs SHOULDを実行するホストは、ネットワーク資源の効率的な使用法を確実にするためにRAQMONレポートの中であまりにも頻繁にこれらのパラメタを送るのを避けます。
5.30. CPU Utilization in Fraction
5.30. 断片におけるCPU利用
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のために非常に重要な意味を持っているかもしれないRDSsを実行するホストの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で送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
Siddiqui, et al. Standards Track [Page 27] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[27ページ]。
5.31. Memory Utilization in Fraction
5.31. 断片におけるメモリ使用量
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のために非常に重要な意味を持っているかもしれないRDSsを実行するホストの使用法であるとキャプチャします。 それは、その時間間隔(例えば、一次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で送られて、アプリケーションにおいて、パラメタが関連しているなら、このパラメタSHOULDはそうです。
5.32. Application Name/Version
5.32. アプリケーション名/バージョン
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.
Application Name/バージョンパラメタが例えばそのセッションかサブセッションと共に名前と任意にアプリケーションのバージョンを関連しているのに与える、「XYZ VoIP、エージェント1.2インチ」 この情報は、端末装置が様々なプライオリティで複数のアプリケーションを実行しているシナリオの役に立つかもしれなくて、デバッグ目的のために非常に便利であるかもしれません。
If the application is using RTP [RFC3550], the Application Name SHOULD begin with the string 'RTP'.
アプリケーションがRTP[RFC3550]を使用しているなら、Application Name SHOULDはストリング'RTP'と共に始まります。
This parameter MUST be sent in the first RAQMON PDU.
最初のRAQMON PDUでこのパラメタを送らなければなりません。
6. Report Aggregation and Statistical Data processing
6. レポートAggregationとStatistical Data処理
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 Frameworkの中では、RRCsにはRDSsよりかなりすばらしいコンピュータのリソースがあると予想されます。 その結果、様々な総計機能はRRCsによって実行されます、RDSsがminima、maxima、平均、標準偏差などの計算などの統計データ処理で負われていませんが
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は、ApplicationパフォーマンスMeasurement(APM)MIB[RFC3729]やTransportパフォーマンスMetrics(TPM)MIB[RFC4150]のように大規模な集合を提供するように設計されていません。 プロトコル(例えば、HTTP、RTPの性能)かアプリケーション(例えば、VoIP、Video Applicationsの性能)に基づくパラメタに集めるのにAPMとTPM MIBsを使用するべきです。
Siddiqui, et al. Standards Track [Page 28] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[28ページ]。
In the RAQMON MIB, aggregation can be performed only on specific RAQMON metric parameters. Aggregation always results in statistical Mean/Min/Max values, according to these definitions:
RAQMON MIBでは、特定のRAQMONメートル法のパラメタだけに集合を実行できます。 これらの定義に従って、集合はいつも統計的なMean/分/マックス値をもたらします:
Mean: 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.
平均: 平均はコミュニケーションセッションの持続時間の上のメートル法のaの統計的な平均と定義されます。 例えば、RDSがコミュニケーションセッション以内にメートル法のN回Endから終わりへの遅れを報告したなら、N報告された値はこれらをまとめて、次に、Nによる分割をまとめることによって、Mean Endから終わりへのDelayを計算できます。
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.
分: 分はコミュニケーションセッションの持続時間の上のメートル法のaの統計的な最小限と定義されます。 例えば、終わりから終わりへのコミュニケーションセッション以内の端末装置におけるメートル法の遅れがN回RDSによって報告されるなら、N終わりから終わりへのメートル法の数値が報告した遅れでMin終わりから終わりへの遅れは最も小さいです。
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.
マックス: マックスはコミュニケーションセッションの持続時間の上のメートル法のaの統計的な最大と定義されます。 例えば、終わりから終わりへのコミュニケーションセッション以内の端末装置におけるメートル法の遅れがN回RDSによって報告されるなら、N Endから終わりへのDelayメートル法の数値でDelayが最も大きいマックスのEndから終わりは報告しました。
7. Keeping Historical Data and Storage
7. 史料とストレージを保ちます。
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を通して利用可能にしてください、すなわち、NULL PDUを受け取り次第。 集められたデータをMean、マックス、またはMinエントリーとしてRAQMON MIBを使用することで利用可能に作って、歴史的な目的のために保存できました。
2. Use a time-based algorithm that aggregates data over a specific
period of time within a communication session, thus requiring
fewer entries, to reduce storage space requirements. For
example, if an RDS sends data out every 10 seconds and the RRC
updates the RAQMON MIB once every minute, for every 6 data
points there would be one MIB entry.
2. コミュニケーションセッション以内に特定の期間の間にデータに集められる時間ベースのアルゴリズムを使用してください、その結果、集積スペース要件を減らすために、より少ないエントリーを必要とします。 例えば、RDSが10秒毎にデータを出して、RRCが毎分に一度RAQMON MIBをアップデートするなら、6データポイント毎に、1つのMIBエントリーがあるでしょう。
Siddiqui, et al. Standards Track [Page 29] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[29ページ]。
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日間より古い史料を削除するだろうことです。 そのような方針の実装はアプリケーション開発者のものに任せます、そして、彼らの使用は操作上の関心です。
8. Security Considerations
8. セキュリティ問題
Security considerations associated with the RAQMON Framework are discussed below, and in greater detail in other RAQMON memos as is appropriate.
詳細に他のRAQMONメモで詳細によりすばらしいそのままで適切な状態でRAQMON Frameworkに関連しているセキュリティ問題について議論します。
8.1. The RAQMON Threat Model
8.1. 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 Frameworkに関連している脆弱性はトランスポート層までの下位層に関連づけられたもの、および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。 別のものに属すとしての1つのRAQMON報告セッションからの情報の誤認は同じRRCに運命づけられました。
b. Mismapping of RAQMON sessions;
b。 RAQMONセッションのMismapping。
c. Various forms of session-level denial-of-service (DoS)
attacks;
c。 様々な形式のサービスのセッションレベル否定(DoS)は攻撃されます。
d. DoS through modification of RAQMON parameter values and
statistics;
d。 RAQMONパラメタ値の変更によるDoSと統計。
e. Invalid timestamps, leading to false interpretation of the
monitored data, affecting call records information, and
making difficult to place monitoring events in their
appropriate temporal context.
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. 秘密性の不履行に通じて、権限のない慎重に扱うべきデータの公表はアプリケーションPDUsで運ばれました。
Siddiqui, et al. Standards Track [Page 30] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[30ページ]。
Consequently, threats based on unauthorized disclosure or modification of payloads or headers will have to be assumed.
その結果、ペイロードかヘッダーの不当開示か変更に基づく脅威は想定されなければならないでしょう。
8.2. The RAQMON Security Requirements and Assumptions
8.2. RAQMONセキュリティ要件と仮定
In order to preserve integrity of the RAQMON PDU against these threats, the RAQMON model must provide for cryptographically strong security services.
これらの脅威に対してRAQMON PDUの保全を保持するために、RAQMONモデルは暗号で強いセキュリティー・サービスに備えなければなりません。
Consequently, the RAQMON framework must be able to provide for the following protections:
その結果、RAQMONフレームワークは以下の保護に備えることができなければなりません:
1. Authentication - the RRC should be able to verify that a RAQMON
PDU was in fact originated by the RDS that claims to have sent
it.
1. 認証--RRCは、事実上、RAQMON PDUがそれを送ったと主張するRDSによって溯源されたことを確かめるはずであることができます。
2. Privacy - Since RAQMON information includes identification of
the parties participating in a communication session, the
RAQMON framework should be able to provide for protection from
eavesdropping, to prevent an unauthorized third party from
gathering potentially sensitive information. This can be
achieved by using various payload encryption technologies, such
as Data Encryption Standard (DES), 3-DES, Advanced Encryption
Standard (AES), etc.
2. プライバシー--RAQMON情報がコミュニケーションセッションのときに参加するパーティーの識別を含んでいるので、RAQMONフレームワークは権限のない第三者が潜在的に機密の情報を集めるのを防ぐために盗み聞くのから保護に備えることができるべきです。 様々なペイロード暗号技術を使用することによって、これを達成できます、データ暗号化規格(DES)、3-DES、エー・イー・エス(AES)などのように
3. Protection from DoS attacks directed at the RRC - RDSs send
RAQMON reports as a side effect of an external event (for
example, a phone call is being received). An attacker can try
to overwhelm the RRC (or the network) by initiating a large
number of events (i.e., calls) for the purpose of swamping the
RRC with too many RAQMON PDUs.
3. RRCが向けられたDoS攻撃からの保護--RDSsは外部のイベントの副作用としてレポートをRAQMONに送ります(例えば、電話を受けています)。 攻撃者は、あまりに多くのRAQMON PDUsで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攻撃を防ぐために、セッションが5秒の報告間隔の間、進行している後にだけRDSはセッションの最初のレポートを送るでしょう。 その間隔が期限が切れた後にだけ、それであるべきであるより短いセッションは、RDSに保存されて、報告されるでしょう。
8.3. RAQMON Security Model
8.3. RAQMON機密保護モデル
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. 一般に、輸送プロトコルレベルセキュリティは終わりから終わりへの認証、秘密性、メッセージの保全、および反復操作による保護サービスがあるペイロードを保護できます。
Siddiqui, et al. Standards Track [Page 31] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[31ページ]。
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. 1RDS-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セキュリティの欠如を含意します。
9. Acknowledgements
9. 承認
The authors would like to thank Andy Bierman, Alan Clark, Mahalingam Mani, Colin Perkins, Steve Waldbusser, Magnus Westerlund, and Itai Zilbershtein for the precious advices and real contributions brought to this document. The authors would also like to extend special thanks to Randy Presuhn, who reviewed this document for spelling and formatting purposes, and who provided a deep review of the technical content. We also would like to thank Bert Wijnen for the permanent coaching during the evolution of this document and the detailed review of its final versions.
作者はこのドキュメントにもたらされた貴重なアドバイスと本当の貢献についてアンディBierman、アラン・クラーク、Mahalingamマニ、コリン・パーキンス、スティーブWaldbusser、マグヌスWesterlund、およびItai Zilbershteinに感謝したがっています。 また、作者はランディPresuhnに特別な感謝を表したがっています。(Presuhnはスペルと形式目的のためのこのドキュメントを再検討して、技術的な内容の深いレビューを提供しました)。 また、発展の間のこのドキュメントの永久的なコーチと最終版の詳細なレビューについてバートWijnenに感謝申し上げます。
Siddiqui, et al. Standards Track [Page 32] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[32ページ]。
10. Normative References
10. 引用規格
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2475] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」RFC2475、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における、メートル法のA One-道の遅れ」、RFC2679、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における、メートル法のA One-道のパケット損失」、RFC2680、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のためのRound旅行Delay Metric」、RFC2681、1999年9月。
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000.
[RFC2819]Waldbusser(S.、「リモートネットワーク監視管理情報ベース」、STD59、RFC2819)は2000がそうするかもしれません。
[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、「リアルタイムのトランスポート・プロトコル管理情報ベース」、RFC2959、2000年10月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)", RFC
3393, November 2002.
[RFC3393]デミチェリスとC.とP.Chimento、「IPパフォーマンス測定基準(IPPM)における、メートル法のIPパケット遅れ変化」、RFC3393、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.(エド)、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMP)について議定書の中で述べます」、STD62、RFC3416、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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
Siddiqui, et al. Standards Track [Page 33] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[33ページ]。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
and Video Conferences with Minimal Control", STD 65, RFC
3551, July 2003.
[RFC3551] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
11. Informative References
11. 有益な参照
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[RFC1305] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[RFC3235] Senie、D.、「ネットワーク・アドレスの翻訳者の(NAT)に優しいアプリケーション設計ガイドライン」、RFC3235、2002年1月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, November
2003.
[RFC3611]フリードマン、T.、カセレス、R.、およびA.クラーク、「RTP制御プロトコルの拡張レポート(RTCP XR)」、RFC3611 2003年11月。
[RFC3729] Waldbusser, S., "Application Performance Measurement
MIB", RFC 3729, March 2004.
2004年のS.、「アプリケーションパフォーマンス測定MIB」、RFC3729行進の[RFC3729]Waldbusser。
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics
MIB", RFC 4150, August 2005.
[RFC4150]ディーツとR.とR.コール、「輸送パフォーマンス測定基準MIB」、RFC4150 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、「リアルタイムサービスのApplication Quality Monitoring(RAQMON)MIB」、RFC4711 2006年10月。
[RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Ramhman,
M., and Y. Kim, "Transport Mappings for Real-time
Application Quality-of-Service Monitoring (RAQMON)
Protocol Data Unit (PDU)", RFC 4712, October 2006.
[RFC4712]Siddiqui(A.、Romascanu、D.、Golovinsky、E.、Ramhman、M.、およびY.キム)は「(RAQMON)プロトコルデータ単位(PDU)をモニターして、サービスのリアルタイムのアプリケーション品質のためのマッピングを輸送します」、RFC4712、2006年10月。
Siddiqui, et al. Standards Track [Page 34] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[34ページ]。
[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]情報技術--システムの間のテレコミュニケーションと情報交換--ローカルとメトロポリタンエリアネットワーク--一般的なSpecification a--メディアアクセスは(MAC)ブリッジ: 15802-3を制御します: 1998 (ISO/IEC。) 改正。 これはISO/IEC10038の改正です: 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
ミドルタウンLincroft道路Lincroft、アンウォーA.Siddiqui Avaya研究室307ニュージャージー07738米国
Phone: +1 732 852-3200 EMail: anwars@avaya.com
以下に電話をしてください。 +1 732 852-3200 メールしてください: anwars@avaya.com
Dan Romascanu Avaya Atidim Technology Park, Building #3 Tel Aviv, 61131 Israel
ダンRomascanu Avaya Atidim技術公園、#3テルアビブ、ビル61131イスラエル
Phone: +972-3-645-8414 EMail: dromasca@avaya.com
以下に電話をしてください。 +972-3-645-8414 メールしてください: dromasca@avaya.com
Eugene Golovinsky
ユージンGolovinsky
EMail: gene@alertlogic.net
メール: gene@alertlogic.net
Siddiqui, et al. Standards Track [Page 35] RFC 4710 RAQMON Framework October 2006
Siddiqui、他 規格はRAQMONフレームワーク2006年10月にRFC4710を追跡します[35ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Siddiqui, et al. Standards Track [Page 36]
Siddiqui、他 標準化過程[36ページ]
一覧
スポンサーリンク
