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

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

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によって開発されました。この文書は、この仕様は、BTのネットワーク外使用のための新しいレポートブロックを標準化していないRFC 3611の仕様が必要ポリシーに従ってIANAでブロックタイプを登録するために十分に詳細にレポートブロックを記述するために製造されています。

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]で定義された拡張メカニズムを使用して、ピアにRTPエンドシステムからXNQ措置を輸送するためにRTCP-XRレポートブロックを定義します。

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によって提供される往復遅延測定を補完するように設計されています。彼らは、で定義されたIPDVメトリックに基づいて、IPパケット遅延変動のための指標を提供[3]、「エラー状態」と「重大エラー」秒を報告するRTPエンドシステムの受信側のジッタバッファの活動を報告するメトリック、およびメトリック。

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

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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は、単に上記のようにvmaxdiff見つけるために得られた毎RTCPサイクル差の和です。メトリックCごとのRTCPサイクル差、すなわち、差の集合の濃度の数です。 2つのメトリックは、VSUMとVSUM / C、RTCP測定サイクル当たりの平均IPDVの計算を可能にする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.

最大IPDV差は、RTPタイムスタンプ単位で測定し、単一のRTCP測定周期内の日付に見られます。測定値が0xFFFEというを超える場合、値0xFFFFのオーバーレンジ測定値を示すことが報告されるべきです。

vrange: 16 bits unsigned

WS：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

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.

今日までのRTPフローの寿命にわたってRTCPサイクルにわたって合計された各RTCPサイクル内のピークIPDV差分値の合計。測定値が0xFFFFFFFEを超える場合、値は0xFFFFFFFFのオーバーレンジ測定値を示すことが報告されるべきです。

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は、ここで説明RTCP XRレポートブロックにレジストリ「RTP制御プロトコル拡張レポート（RTCP XR）ブロックタイプ」の中に数8を割り当てました。このレジストリは、[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]における検討事項の一部は、このレポートブロックには適用されません。具体的には、機密性へのリスクは、第7節では、[1]が適用されないのパラグラフ3を文書化してXNQはパケットごとの統計情報を提供していない、とサービス拒否のリスクは7節、段落に記載してXNQパケットは非常に大きくすることはできません7 [1]は適用されません。

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]ブラドナーのは、S.は、RFC 2119、BCP 14、1997年3月 "のRFCsにおける使用のためのレベルを示すために"。

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

ジェフ・ハントBTオリオン1 PP9 Adastral公園Martleshamヒースサフォーク州イプスウィッチIP5 3REイギリス

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

電話：+44 1473 608325 Eメール：geoff.hunt@bt.com

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

Intellectual Property

知的財産

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

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

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

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

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

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。