RFC 5093 - BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5093
タイトル : RFC 5093 - BTの拡張ネットワーク品質RTPコントロールプロトコル拡張レポート（RTCP XR XNQ）
翻訳編集 : 自動生成

[要約] RFC 5093は、BTの拡張ネットワーク品質RTP制御プロトコル拡張レポート（RTCP XR XNQ）に関する規格です。このRFCの目的は、ネットワーク品質の測定と監視を向上させるために、RTP制御プロトコルの拡張レポートを提供することです。

Network Working Group                                            G. Hunt
Request for Comments: 5093                                            BT
Category: Informational                                    December 2007

BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)

BTの拡張ネットワーク品質RTPコントロールプロトコル拡張レポート（RTCP XR XNQ）

Status of This Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

IESG Note

IESGノート

The IESG has concerns about vendor code points allocation in this small namespace and might not approve similar documents in the future.

IESGは、この小さな名前空間でベンダーコードポイントの割り当てについて懸念があり、将来同様の文書を承認しない可能性があります。

Abstract

概要

This document describes an RTCP XR report block, which reports packet transport parameters. The report block was developed by BT for pre-standards use in BT's next-generation network. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of RFC 3611. This specification does not standardise the new report block for use outside BT's network.

このドキュメントでは、パケット輸送パラメーターを報告するRTCP XRレポートブロックについて説明します。レポートブロックは、BTの次世代ネットワークでの標準以前の使用のためにBTによって開発されました。このドキュメントは、RFC 3611の仕様に従ってIANAにブロックタイプを登録するのに十分な詳細でレポートブロックを説明するために作成されています。この仕様は、BTのネットワーク外で使用する新しいレポートブロックを標準化するものではありません。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . . . 2
   3.  Extended Network Quality (XNQ) Report Block . . . . . . . . . . 2
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

1. Introduction

1. はじめに

A set of metrics of packet-transport quality has been defined by BT for pre-standards use in its network. These metrics are known as "XNQ" for "eXtended Network Quality". This document defines an RTCP-XR Report Block to transport the XNQ measures from an RTP end system to its peer, using the extension mechanism defined in [1].

パケット輸送品質の一連のメトリックは、そのネットワークでの標準以前の使用のためにBTによって定義されています。これらのメトリックは、「拡張ネットワーク品質」の「XNQ」として知られています。このドキュメントでは、[1]で定義されている拡張メカニズムを使用して、RTCP-XRレポートブロックを定義してXNQ測定値をRTPエンドシステムからピアに輸送します。

The metrics are designed to supplement the packet-loss metric in RTCP [2] and the roundtrip delay measurement provided by RTCP. They provide metrics for IP Packet Delay Variation based on the IPDV metric defined in [3], metrics reporting the activity of the RTP end system's receiver's jitter buffer, and metrics reporting "errored" and "severely errored" seconds.

メトリックは、RTCP [2]のパケットロスメトリックとRTCPによって提供される往復遅延測定を補完するように設計されています。[3]で定義されたIPDVメトリック、RTPエンドシステムの受信機のジッターバッファーのアクティビティを報告するメトリック、および「エラー」と「重度のエラー」秒を報告するメトリックに基づいたIPパケット遅延変動のメトリックを提供します。

This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of [1]. This specification does not standardise the new report block for use outside BT's network.

このドキュメントは、[1]の仕様に従ってIANAにブロックタイプを登録するのに十分な詳細でレポートブロックを説明するために作成されています。この仕様は、BTのネットワーク外で使用するための新しいレポートブロックを標準化するものではありません。

Work in progress on RTCP HR [5] is likely to obsolete these metrics and the RTCP-XR Report Block defined here.

RTCP HR [5]で進行中の作業は、これらのメトリックとここで定義されているRTCP-XRレポートブロックを廃止する可能性があります。

2. Requirements Notation

2. 要件表記

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 [4].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[4]で説明されているように解釈される。

3. Extended Network Quality (XNQ) Report Block

3. 拡張ネットワーク品質（XNQ）レポートブロック

A set of metrics of packet-transport quality has been defined by BT for pre-standards use in its network. These metrics are known as "XNQ" for "eXtended Network Quality".

パケット輸送品質の一連のメトリックは、そのネットワークでの標準以前の使用のためにBTによって定義されています。これらのメトリックは、「拡張ネットワーク品質」の「XNQ」として知られています。

This document defines an RTCP-XR Report Block using the extension mechanism defined in [1]. The new Report Block provides transport of the XNQ measures from an RTP end system to its peer.

このドキュメントは、[1]で定義されている拡張メカニズムを使用して、RTCP-XRレポートブロックを定義します。新しいレポートブロックは、RTPエンドシステムからピアへのXNQメジャーの輸送を提供します。

The metrics are described in the following text. However, some additional explanation is required for the metrics vmaxdiff, vrange, vsum, and c, which measure aspects of packet delay variation. The metrics are based on the measure known as IP Packet Delay Variation (IPDV) defined in [3]. The IPDV of a packet is the amount by which the packet was delayed in the network, minus the amount a reference packet was delayed in the network. The reference packet is usually the first packet of the connection. IPDV is a signed quantity.

メトリックは、次のテキストで説明されています。ただし、パケット遅延の変動の側面を測定するメトリックvmaxdiff、vrange、vsum、およびcには、いくつかの追加の説明が必要です。メトリックは、[3]で定義されているIPパケット遅延変動（IPDV）と呼ばれる測定に基づいています。パケットのIPDVは、ネットワークでパケットが遅れた量であり、ネットワークで参照パケットが遅れた量を差し引いています。参照パケットは通常、接続の最初のパケットです。IPDVは署名された数量です。

The metric vrange is the difference (longest minus shortest) between the longest and shortest network packet delays seen over the duration of the connection to date. The metric vrange is usually a positive quantity, but may be zero if the packet delay is exactly constant over the lifetime of the connection to date.

メトリックvRangeは、これまでの接続期間中に見られる最長および最短のネットワークパケットの遅延の差（最短）の差です。メトリックvrangeは通常正の量ですが、パケットの遅延が現在までの寿命にわたって正確に一定である場合、ゼロになる可能性があります。

The metric vmaxdiff is found as follows. For each RTCP measurement cycle, find the difference (longest minus shortest) between the longest and shortest network packet delays within that measurement cycle. These differences are usually all positive quantities, but a difference may be zero if the packet delay is exactly constant throughout the measurement cycle. Take the set of these differences and find the maximum, which is vmaxdiff. The metric vmaxdiff is also usually a positive quantity, but will be zero if all the members of the set of per-cycle differences are zero.

メトリックvmaxdiffは次のように見つかります。各RTCP測定サイクルについて、その測定サイクル内で最も長いネットワークパケット遅延と最短のネットワークパケット遅延の差（最短）を見つけます。これらの違いは通常すべて正の量ですが、測定サイクル全体でパケットの遅延が正確に一定である場合、差はゼロになる場合があります。これらの違いのセットを取り、vmaxdiffである最大値を見つけます。メトリックvmaxdiffも通常は正ですが、サイクルごとの違いのセットのすべてのメンバーがゼロである場合、ゼロになります。

The metric vsum is simply the sum of the per-RTCP-cycle differences, which were obtained to find vmaxdiff as described above. The metric c is the number of per-RTCP-cycle differences, that is, the cardinality of the set of differences. The two metrics vsum and c allow calculation of vsum/c, the average IPDV per RTCP measurement cycle.

メトリックVSUMは、単にRTCPごとの違いの合計であり、上記のようにvmaxdiffを見つけるために取得されました。メトリックCは、RTCPサイクルごとの違い、つまり一連の違いのカーディナリティの数です。2つのメトリックVSUMとCは、RTCP測定サイクルあたりの平均IPDVであるVSUM/Cの計算を可能にします。

The format of the report is as shown in Figure 1.

レポートの形式は、図1に示すとおりです。

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     BT=8      |   reserved    |      block length = 8         |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |          begin_seq            |             end_seq           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           vmaxdiff            |             vrange            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              vsum                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               c               |            jbevents           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   reserved    |                     tdegnet                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   reserved    |                     tdegjit                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   reserved    |                        es                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   reserved    |                       ses                     |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Figure 1

図1

The report consists of an RTCP-XR block header and a single 8-word sub-block.

レポートは、RTCP-XRブロックヘッダーと1つの8ワードサブブロックで構成されています。

block type (BT): 8 bits

ブロックタイプ（BT）：8ビット

An XNQ Metrics Report Block is identified by the constant 8.

XNQメトリックレポートブロックは、定数8によって識別されます。

reserved: 8 bits

予約済み：8ビット

These fields are reserved for future definition. In the absence of such a definition, the bits in these fields MUST be set to zero and MUST be ignored by the receiver.

これらのフィールドは、将来の定義のために予約されています。このような定義がない場合、これらのフィールドのビットはゼロに設定する必要があり、受信機は無視する必要があります。

block length: 16 bits

ブロック長：16ビット

Defined in Section 3 of [1].

[1]のセクション3で定義されています。

begin_seq: 16 bits

begin_seq：16ビット

As defined in Section 4.1 of [1].

[1]のセクション4.1で定義されているとおり。

end_seq: 16 bits

end_seq：16ビット

As defined in Section 4.1 of [1].

[1]のセクション4.1で定義されているとおり。

vmaxdiff: 16 bits unsigned

vmaxdiff：符号なし16ビット

Largest IPDV difference seen to date within a single RTCP measurement cycle, measured in RTP timestamp units. If the measured value exceeds 0xFFFE, the value 0xFFFF should be reported to indicate an over-range measurement.

RTPタイムスタンプユニットで測定された、単一のRTCP測定サイクル内でこれまで見られる最大のIPDV差。測定値が0xfffeを超える場合、値0xffffを報告する必要があります。

vrange: 16 bits unsigned

vrange：16ビット符号なし

Largest IPDV difference over the lifetime of the RTP flow to date, measured in RTP timestamp units. If the measured value exceeds 0xFFFE, the value 0xFFFF should be reported to indicate an over-range measurement.

RTPタイムスタンプユニットで測定された、これまでのRTPフローの寿命にわたる最大のIPDV差。測定値が0xfffeを超える場合、値0xffffを報告する必要があります。

vsum: 32 bits unsigned

VSUM：署名なし32ビット

Sum of the peak IPDV difference values within each RTCP cycle, summed over RTCP cycles over the lifetime of the RTP flow to date. If the measured value exceeds 0xFFFFFFFE, the value 0xFFFFFFFF should be reported to indicate an over-range measurement.

各RTCPサイクル内のピークIPDV差値の合計は、これまでのRTPフローの寿命にわたってRTCPサイクルに合計されています。測定値が0xfffffffffeを超える場合、値0xffffffffffを報告する必要があります。

c: 16 bits unsigned

C：符号なし16ビット

Number of RTCP cycles over which vsum was accumulated. If the measured value exceeds 0xFFFE, the value 0xFFFF should be reported to indicate an over-range measurement.

VSumが蓄積されたRTCPサイクルの数。測定値が0xfffeを超える場合、値0xffffを報告する必要があります。

jbevents: 16 bits unsigned

JBevents：16ビット署名

Cumulative number of jitter buffer adaptation events over the lifetime of the RTP flow to date. If the measured value exceeds 0xFFFE, the value 0xFFFF should be reported to indicate an over-range measurement.

これまでのRTPフローの寿命にわたるジッターバッファー適応イベントの累積数。測定値が0xfffeを超える場合、値0xffffを報告する必要があります。

tdegnet: 24 bits unsigned

Tdegnet：24ビット署名

The total time in sample periods affected either by packets unavailable due to network loss, or late delivery of packets, since the start of transmission. If the measured value exceeds 0xFFFFFE, the value 0xFFFFFF should be reported to indicate an over-range measurement.

送信の開始以来、ネットワークの損失またはパケットの遅延のために利用できないパケットの影響を受けたサンプル期間の合計時間。測定値が0xfffffeを超える場合、値0xffffffを報告する必要があります。

tdegjit: 24 bits unsigned

Tdegjit：24ビット符号なし

The total time in sample periods degraded by jitter buffer adaptation events, e.g., where the jitter buffer either plays out a sample sequence not originating at the transmitter, repeats samples, or chooses not to play out a sample sequence that was sent by the transmitter. If the measured value exceeds 0xFFFFFE, the value 0xFFFFFF should be reported to indicate an over-range measurement.

ジッターバッファー適応イベントによって劣化したサンプル期間の合計時間は、たとえば、ジッターバッファーが送信機で発生しないサンプルシーケンスを再生したり、サンプルを繰り返したり、送信機によって送信されたサンプルシーケンスを再生しないことを選択します。測定値が0xfffffeを超える場合、値0xffffffを報告する必要があります。

es: 24 bits unsigned

ES：24ビットは署名されていません

cumulative seconds affected by "unavailable packet" events over the lifetime of this ephemeral, to date. If the measured value exceeds 0xFFFFFE, the value 0xFFFFFF should be reported to indicate an over-range measurement.

これまでのこのはかない寿命の「利用できないパケット」イベントの影響を受ける累積秒。測定値が0xfffffeを超える場合、値0xffffffを報告する必要があります。

ses: 24 bits unsigned

SES：24ビットは署名されていません

cumulative seconds affected by severe "unavailable packet" events over the lifetime of this ephemeral, to date. If the measured value exceeds 0xFFFFFE, the value 0xFFFFFF should be reported to indicate an over-range measurement.

これまでに、このはかない寿命にわたる深刻な「利用できないパケット」イベントの影響を受ける累積秒。測定値が0xfffffeを超える場合、値0xffffffを報告する必要があります。

4. IANA Considerations

4. IANAの考慮事項

IANA has allocated the number 8 within the registry "RTP Control Protocol Extended Reports (RTCP XR) Block Types" to the RTCP XR report block described here. This registry is defined in [1].

IANAは、レジストリ「RTP制御プロトコル拡張レポート（RTCP XR）ブロックタイプ」内で、ここで説明するRTCP XRレポートブロックに割り当てました。このレジストリは[1]で定義されています。

5. Security Considerations

5. セキュリティに関する考慮事項

It is believed that this proposed RTCP XR report block introduces no new security considerations beyond those described in [1]. Some of the considerations in [1] do not apply to this report block. Specifically, XNQ does not provide per-packet statistics so the risk to confidentiality documented in Section 7, paragraph 3 of [1] does not apply, and XNQ packets cannot be very large so the risk of denial of service documented in Section 7, paragraph 7 of [1] does not apply.

この提案されたRTCP XRレポートブロックは、[1]に記載されているものを超えた新しいセキュリティ上の考慮事項を導入しないと考えられています。[1]の考慮事項のいくつかは、このレポートブロックには適用されません。具体的には、XNQはパケットごとの統計を提供しないため、セクション7、[1]のパラグラフ3に文書化された機密性のリスクは適用されず、XNQパケットは非常に大きくできないため、セクション7、パラグラフで文書化されたサービス拒否のリスク[1]の7は適用されません。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[1] Friedman, T., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.

[1] フリードマン、T。、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。

[2] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.

[2] Schulzrinne、H。、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 3550、2003年7月。

[3] ITU-T, "Recommendation Y.1540, Internet protocol data communication service -- IP packet transfer and availability performance parameters", December 2002.

[3] ITU-T、「推奨Y.1540、インターネットプロトコルデータ通信サービス - IPパケット転送および可用性パフォーマンスパラメーター」、2002年12月。

[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.

[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。

6.2. Informative References

6.2. 参考引用

[5] Clark, A., "RTCP HR - High Resolution VoIP Metrics Report Blocks", Work in Progress, November 2007.

[5] クラーク、A。、「RTCP HR-高解像度VoIPメトリックレポートブロック」、2007年11月、作業進行中。

Author's Address

著者の連絡先

Geoff Hunt BT Orion 1 PP9 Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom

Geoff Hunt Bt Orion 1 pp9 Adastral Park Martlesham Heath Ipswich、Suffolk IP5 3RE英国

   Phone: +44 1473 608325
   EMail: geoff.hunt@bt.com

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（2007）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。