[要約] RFC 6332は、RTP制御プロトコル（RTCP）拡張レポート（XRs）のためのマルチキャスト取得レポートブロックタイプに関する規格です。このRFCの目的は、マルチキャストグループのパフォーマンスを評価するための情報を提供することです。
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 6332 E. Friedrich
Category: Standards Track Cisco
ISSN: 2070-1721 July 2011
Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
RTPコントロールプロトコル（RTCP）拡張レポート（XRS）のマルチキャスト取得レポートブロックタイプ
Abstract
概要
In most RTP-based multicast applications, the RTP source sends inter-related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called the Multicast Acquisition (MA) report block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP).
ほとんどのRTPベースのマルチキャストアプリケーションでは、RTPソースは相互に関連するデータを送信します。この相互依存により、RTPレシーバーにランダムに参加することは、通常、セッションに参加した直後にマルチキャストデータの消費を開始することはできません。したがって、彼らはしばしばランダムな取得遅延を経験します。RTPレシーバーは、1つ以上の異なるアプローチを使用して、迅速な獲得を達成できます。しかし、さまざまな要因により、迅速な獲得方法のパフォーマンスは通常異なります。さらに、場合によっては、RTPレシーバーは簡単なマルチキャスト結合を実行できます（他の場合は、そうすることを余儀なくされます）。質の高いレポート、監視、診断の目的では、RTP受信者からの取得とプレゼンテーションの経験に関する詳細情報を収集することが重要です。このドキュメントは、RTPコントロールプロトコル（RTCP）拡張レポート（XRS）（RFC 3611）のフレームワーク内で、マルチキャスト取得（MA）レポートブロックと呼ばれる新しいレポートブロックタイプを定義することにより、この問題に対処します。このドキュメントは、セッション説明プロトコル（SDP）の新しいMAレポートブロックタイプの必要なシグナル伝達も定義します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6332.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6332で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 4
4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 6
4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 6
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 7
4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 10
5. Session Description Protocol Signaling . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 11
7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 12
7.3. Multicast Acquisition Method Registry . . . . . . . . . . 12
7.4. Multicast Acquisition Report Block TLV Space Registry . . 12
7.5. Multicast Acquisition Status Code Space Registry . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
The RTP Control Protocol (RTCP) is the out-of-band control protocol for applications that use the Real-time Transport Protocol (RTP) for media transport [RFC3550]. In addition to providing minimal control functionality to RTP entities, RTCP also enables a basic-level monitoring of RTP sessions via sender and receiver reports. More statistically detailed monitoring as well as application-specific monitoring are usually achieved through the RTCP Extended Reports (XRs) [RFC3611].
RTPコントロールプロトコル（RTCP）は、メディアトランスポートにリアルタイムトランスポートプロトコル（RTP）を使用するアプリケーションのバンド外コントロールプロトコル[RFC3550]です。RTCPは、RTPエンティティに最小限の制御機能を提供することに加えて、送信者および受信者レポートを介したRTPセッションの基本レベルの監視も可能にします。通常、より統計的に詳細な監視とアプリケーション固有の監視は、RTCP拡張レポート（XRS）[RFC3611]を通じて実現されます。
In most RTP-based multicast applications such as the ones carrying video content, the RTP source sends inter-related data. Consequently, the RTP application may not be able to decode and present the data in an RTP packet before decoding the data in one or more earlier RTP packets and/or before acquiring some Reference Information about the content itself. Thus, RTP receivers that are randomly joining a multicast session often experience a random acquisition delay. In order to reduce this delay, [RFC6285] proposes an approach where an auxiliary unicast RTP session is established between a retransmission server and the joining RTP receiver. Over this unicast RTP session, the retransmission server provides the Reference Information, which is all the information the RTP receiver needs to rapidly acquire the multicast stream. This method is referred to as the Rapid Acquisition of Multicast RTP Sessions (RAMS). However, depending on the variability in the Source Filtering Group Management Protocol (SFGMP) processing times, the availability of network resources for rapid acquisition, and the nature of the RTP data, not all RTP receivers can acquire the multicast stream in the same amount of time. The performance of rapid acquisition may vary not only for different RTP receivers but also over time.
ビデオコンテンツを搭載したものなどのほとんどのRTPベースのマルチキャストアプリケーションでは、RTPソースは相互に関連するデータを送信します。したがって、RTPアプリケーションは、1つ以上の以前のRTPパケットでデータをデコードする前に、および/またはコンテンツ自体に関する参照情報を取得する前に、RTPパケットにデータをデコードして提示できない場合があります。したがって、マルチキャストセッションにランダムに結合しているRTPレシーバーは、しばしばランダムな取得遅延を経験します。この遅延を減らすために、[RFC6285]は、再送信サーバーと結合RTPレシーバーの間に補助ユニキャストRTPセッションが確立されるアプローチを提案します。このUnicast RTPセッションでは、再送信サーバーが参照情報を提供します。これは、RTPレシーバーがマルチキャストストリームを迅速に取得するために必要なすべての情報です。この方法は、マルチキャストRTPセッション（RAMS）の迅速な買収と呼ばれます。ただし、ソースフィルタリンググループ管理プロトコル（SFGMP）処理時間の変動性、迅速な取得のためのネットワークリソースの可用性、およびRTPデータの性質に応じて、すべてのRTP受信機が同じ量のマルチキャストストリームを取得できるわけではありません。時間。迅速な買収のパフォーマンスは、異なるRTPレシーバーだけでなく、時間の経過とともに異なる場合があります。
To increase the visibility of the multicast service provider in its network, to diagnose slow multicast acquisition issues, and to collect the acquisition experiences of the RTP receivers, this document defines a new report block type, which is called the Multicast Acquisition (MA) report block, within the framework of RTCP XR. RTP receivers that use the method described in [RFC6285] may use this report every time they join a new multicast RTP session. RTP receivers that use a different method for rapid acquisition or those that do not use any method but rather do a simple multicast join may also use this report. This way, the multicast service provider can quantitatively compare the improvements achieved by different methods.
ネットワーク内のマルチキャストサービスプロバイダーの可視性を高め、遅いマルチキャストの取得問題を診断し、RTP受信機の取得経験を収集するために、このドキュメントは、マルチキャスト取得（MA）レポートと呼ばれる新しいレポートブロックタイプを定義します。ブロック、RTCP XRのフレームワーク内。[RFC6285]で説明されているメソッドを使用するRTP受信機は、新しいマルチキャストRTPセッションに参加するたびにこのレポートを使用できます。迅速な買収に別のメソッドを使用するRTPレシーバーまたは方法を使用しないが、単純なマルチキャスト結合を実行するRTP受信機もこのレポートを使用する場合があります。これにより、マルチキャストサービスプロバイダーは、さまざまな方法で達成される改善を定量的に比較できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「このドキュメントでは、[RFC2119]に記載されているように解釈されます。
This document uses the acronyms and definitions from Section 3 of [RFC6285].
このドキュメントでは、[RFC6285]のセクション3の頭字語と定義を使用しています。
This section defines the format of the MA report block. The base report is payload independent. An extension mechanism is provided where further optional payload-independent and payload-specific information can be included in the report as desired.
このセクションでは、MAレポートブロックの形式を定義します。基本レポートはペイロード独立です。必要に応じて、さらにオプションのペイロードに依存しない、ペイロード固有の情報をレポートに含めることができる拡張メカニズムが提供されます。
The OPTIONAL extensions that are defined in this document are primarily developed for the method presented in [RFC6285]. Other methods that provide rapid acquisition can define their own extensions to be used in the MA report block.
このドキュメントで定義されているオプションの拡張機能は、主に[RFC6285]で提示された方法のために開発されました。迅速な獲得を提供する他の方法では、MAレポートブロックで使用される独自の拡張機能を定義できます。
The packet format for the RTCP XR is defined in Section 2 of [RFC3611]. Each XR packet has a fixed-length field for version, padding, reserved bits, payload type (PT), length, synchronization source (SSRC) of packet sender as well as a variable-length field for report blocks. In the XR packets, the PT field is set to XR (207).
RTCP XRのパケット形式は、[RFC3611]のセクション2で定義されています。各XRパケットには、バージョン、パディング、予約ビット、ペイロードタイプ（PT）、長さ、同期ソース（SSRC）のパケット送信者の固定長フィールド、およびレポートブロック用の可変長さフィールドがあります。XRパケットでは、PTフィールドはXR（207）に設定されています。
It is better to send the MA report block after all the necessary information is collected and computed. Partial reporting is generally not useful as it cannot give the full picture of the multicast acquisition, and it causes additional complexity in terms of report block matching and correlation. The MA report block is only sent as a part of an RTCP compound packet, and it is sent in the primary multicast session.
必要な情報がすべて収集され、計算された後、MAレポートブロックを送信することをお勧めします。部分的な報告は、マルチキャストの獲得の全体像を示すことができず、レポートブロックのマッチングと相関の観点から追加の複雑さを引き起こすため、一般的に有用ではありません。MAレポートブロックは、RTCP化合物パケットの一部としてのみ送信され、プライマリマルチキャストセッションで送信されます。
The need for reliability of the MA report block is not any greater than other report blocks or types. If desired, the report block could be repeated for redundancy purposes while respecting the RTCP scheduling algorithms.
MAレポートブロックの信頼性の必要性は、他のレポートブロックまたはタイプよりも大きくありません。必要に応じて、RTCPスケジューリングアルゴリズムを尊重しながら、冗長性の目的でレポートブロックを繰り返すことができます。
Following the rules specified in [RFC3550], all integer fields in the base report and extensions defined below are carried in network-byte order, that is, most significant byte (octet) first, also known as big-endian. Unless otherwise stated, numeric constants are in decimal (base 10).
[RFC3550]で指定されたルールに従って、以下に定義されている基本レポートと拡張機能のすべての整数フィールドは、ネットワークバイトの順序で運ばれます。つまり、最も重要なバイト（Octet）が最初に、Big-Endianとも呼ばれます。特に明記しない限り、数値定数は10進数です（ベース10）。
The base report format is 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=11 | MA Method | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of the Primary Multicast Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Base Report Format for the MA Report Block
図1：MAレポートブロックのベースレポート形式
o BT (8 bits): Field that denotes the type for this block format. The MA report block is identified by the constant 11.
o BT（8ビット）：このブロック形式のタイプを示すフィールド。MAレポートブロックは、定数11で識別されます。
o MA Method (8 bits): Field that denotes the type of the MA method (e.g., simple join, RAMS, etc.). See Section 7.3 for the values registered with IANA.
o MAメソッド（8ビット）：MAメソッドのタイプを示すフィールド（たとえば、単純な結合、ラムなど）。IANAに登録された値については、セクション7.3を参照してください。
o Block Length (16 bits): The length of this report block, including the header, in 32-bit words minus one.
o ブロック長（16ビット）：ヘッダーを含むこのレポートブロックの長さは、32ビット単語から1を引いたものです。
o SSRC of the Primary Multicast Stream (32 bits): Field that denotes the SSRC of the primary multicast stream.
o プライマリマルチキャストストリーム（32ビット）のSSRC：プライマリマルチキャストストリームのSSRCを示すフィールド。
o Status (16 bits): Field that denotes the status code for the MA operation.
o ステータス（16ビット）：MA操作のステータスコードを示すフィールド。
This document defines several status codes and registers them with IANA in Section 7.5. If a new vendor-neutral status code will be defined, it MUST be registered with IANA according to the guidelines specified in Section 7.5. If the new status code is intended to be used privately by a vendor, there is no need for IANA management. Section 4.2.2 defines how a vendor defines and uses private extensions to convey its messages.
このドキュメントでは、いくつかのステータスコードを定義し、セクション7.5のIANAでそれらを登録します。新しいベンダー中立ステータスコードが定義される場合、セクション7.5で指定されたガイドラインに従ってIANAに登録する必要があります。新しいステータスコードがベンダーが個人的に使用することを意図している場合、IANA管理は必要ありません。セクション4.2.2は、ベンダーがプライベートエクステンションを定義および使用してメッセージを伝える方法を定義しています。
To indicate use of a private extension, the RTP receiver MUST set the Status field to zero. A private extension MUST NOT be used in an XR unless the RTP receiver knows from out-of-band methods that the entity that will receive and process the XR understands the private extension.
プライベート拡張機能の使用を示すには、RTPレシーバーはステータスフィールドをゼロに設定する必要があります。RTPレシーバーが帯域外の方法からXRを受け取って処理するエンティティがプライベート拡張機能を理解していることを知っていない限り、プライベートエクステンションをXRで使用してはなりません。
o Rsvd. (16 bits): The RTP receiver MUST set this field to zero. The recipient MUST ignore this field when received.
o rsvd。（16ビット）：RTPレシーバーは、このフィールドをゼロに設定する必要があります。受信者は、受信したときにこのフィールドを無視する必要があります。
If the multicast join was successful, meaning that at least one multicast packet was received, some additional information MUST be appended to the base report as described in Section 4.2.1.
マルチキャストの結合が成功した場合、少なくとも1つのマルチキャストパケットが受信されたことを意味する場合、セクション4.2.1で説明されているように、いくつかの追加情報を基本レポートに追加する必要があります。
Different MA methods usually use different status codes, although some status codes (e.g., a code indicating that multicast join has failed) can be common among multiple MA methods. The status code reported in the base report MUST always be within the scope of the particular MA method specified in the MA Method field.
さまざまなMAメソッドは通常、異なるステータスコードを使用しますが、一部のステータスコード（たとえば、マルチキャスト結合が失敗したことを示すコード）は、複数のMAメソッド間で一般的です。基本レポートで報告されているステータスコードは、常にMAメソッドフィールドで指定された特定のMAメソッドの範囲内でなければなりません。
In certain MA methods, the RTP receiver can generate a status code for its multicast acquisition attempt or can be told by another network element or RTP endpoint what the current status is via a response code. In such cases, the RTP receiver MAY report the value of the received response code as its status code if the response code has a higher priority. Each MA method needs to outline the rules pertaining to its response and status codes so that RTP receiver implementations can determine what to report in any given scenario.
特定のMAメソッドでは、RTP受信機はマルチキャスト取得の試みのステータスコードを生成するか、別のネットワーク要素またはRTPエンドポイントで、応答コードを介して現在のステータスが何であるかを通知できます。そのような場合、RTPレシーバーは、応答コードの優先度が高い場合、受信した応答コードの値をステータスコードとして報告することができます。各MAメソッドは、RTPレシーバーの実装が特定のシナリオで何を報告するかを決定できるように、その応答とステータスコードに関連するルールの概要を説明する必要があります。
In this section, we provide the status code rules for the RAMS method described in [RFC6285].
このセクションでは、[RFC6285]で説明されているRAMSメソッドのステータスコードルールを提供します。
Section 11.6 of [RFC6285] defines several response codes. The 1xx-and 2xx-level response codes are informational and success response codes, respectively. If the RTP receiver receives a 1xx- or 2xx-level response code, then the RTP receiver MUST use one of the 1xxx-level status codes defined in Section 7.5 of this document. If the RTP receiver receives a 4xx- or 5xx-level response code (indicating receiver-side and server-side errors, respectively), then the RTP receiver MUST use the response code as its status code. In other words, the 4xx- and 5xx-level response codes have a higher priority than the 1xxx-level status codes.
[RFC6285]のセクション11.6は、いくつかの応答コードを定義しています。1xxおよび2xxレベルの応答コードは、それぞれ情報と成功の応答コードです。RTPレシーバーが1xxまたは2xxレベルの応答コードを受信した場合、RTPレシーバーは、このドキュメントのセクション7.5で定義されている1xxxレベルのステータスコードのいずれかを使用する必要があります。RTPレシーバーが4xxまたは5xxレベルの応答コード（それぞれ受信者側とサーバー側のエラーを示す）を受信した場合、RTPレシーバーは応答コードをステータスコードとして使用する必要があります。言い換えれば、4XXおよび5XXレベルの応答コードは、1XXXレベルのステータスコードよりも優先度が高くなっています。
To improve the reporting scope, it might be desirable to define new fields in the MA report block. Such fields are to be encoded as TLV elements as described below and sketched in Figure 2:
レポート範囲を改善するには、MAレポートブロックの新しいフィールドを定義することが望ましい場合があります。このようなフィールドは、以下に説明するようにTLV要素としてエンコードされ、図2にスケッチされます。
o Type: A single-octet identifier that defines the type of the parameter represented in this TLV element.
o タイプ：このTLV要素で表されるパラメーターのタイプを定義する単一オクテット識別子。
o Length: A two-octet field that indicates the length (in octets) of the TLV element excluding the Type and Length fields and the 8-bit Reserved field between them. Note that this length does not include any padding that is needed for alignment.
o 長さ：TLV要素の長さ（オクテット内）を、タイプと長さのフィールドとそれらの間の8ビット予約フィールドを除く2オクテットのフィールド。この長さには、アライメントに必要なパディングは含まれていないことに注意してください。
o Value: Variable-size set of octets that contains the specific value for the parameter.
o 値：パラメーターの特定の値を含むオクテットの可変サイズセット。
In the extensions, the Reserved field MUST be set to zero and ignored on reception. If a TLV element does not fall on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero.
拡張機能では、予約済みフィールドをゼロに設定し、受信時に無視する必要があります。TLV要素が32ビットの境界に当てはまらない場合、最後の単語は、さらにゼロに設定されたビットを使用して境界にパディングする必要があります。
In the MA report block, the RTP receiver MUST place any vendor-neutral or private extension after the base report.
MAレポートブロックでは、RTPレシーバーは、基本レポートの後にベンダーの中立またはプライベート拡張機能を配置する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Structure of a TLV Element
図2：TLV要素の構造
If the goal in defining new TLV elements is to extend the report block in a vendor-neutral manner, they need to be registered with IANA according to the guidelines provided in Section 7.4.
新しいTLV要素を定義する目標がベンダーに中立な方法でレポートブロックを拡張することである場合、セクション7.4で提供されているガイドラインに従ってIANAに登録する必要があります。
This document defines several vendor-neutral extensions. First, we present the TLV elements that can be used by any RTP-based multicast application.
このドキュメントでは、いくつかのベンダーに中立な拡張機能を定義しています。まず、RTPベースのマルチキャストアプリケーションで使用できるTLV要素を提示します。
o RTP Seqnum of the First Multicast Packet (16 bits): TLV element that specifies the RTP sequence number of the first multicast packet received for the primary multicast stream. If the multicast join was successful, this element MUST be included. If no multicast packet has been received, this element MUST NOT exist in the report block.
o 最初のマルチキャストパケット（16ビット）のRTP Seqnum：プライマリマルチキャストストリームで受信した最初のマルチキャストパケットのRTPシーケンス番号を指定するTLV要素。マルチキャストの結合が成功した場合、この要素を含める必要があります。マルチキャストパケットが受信されていない場合、この要素はレポートブロックに存在してはなりません。
Type: 1
タイプ：1
o SFGMP Join Time (32 bits): TLV element that denotes the greater of zero or the time difference (in ms) between the instant the SFGMP Join message was sent and the instant the first packet was
o SFGMP結合時間（32ビット）：ゼロの大きいまたは時差（MSで）を示すTLV要素SFGMP結合メッセージが送信され、最初のパケットが瞬時に送信されました。
received in the multicast session. If the multicast join was successful, this element MUST be included. If no multicast packet has been received, this element MUST NOT exist in the report block.
マルチキャストセッションで受信。マルチキャストの結合が成功した場合、この要素を含める必要があります。マルチキャストパケットが受信されていない場合、この要素はレポートブロックに存在してはなりません。
Type: 2
タイプ：2
o Application Request-to-Multicast Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the application became aware it would join a new multicast session and the instant the first RTP packet was received from the primary multicast stream. If no such packet has been received, this element MUST NOT exist in the report block.
o アプリケーションリクエスト - マルチキャストデルタ時間（32ビット）：アプリケーションが新しいマルチキャストセッションに参加する瞬間に、最初のRTPパケットが受信された瞬間に、時差を（MSで）示すオプションのTLV要素プライマリマルチキャストストリーム。そのようなパケットが受信されていない場合、この要素はレポートブロックに存在してはなりません。
Type: 3
タイプ：3
o Application Request-to-Presentation Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the application became aware it would join a new multicast session and the instant the media was first presented. If the RTP receiver cannot successfully present the media, this element MUST NOT exist in the report block.
o アプリケーションへのリクエストへのリクエストデルタ時間（32ビット）：アプリケーションが新しいマルチキャストセッションに参加する瞬間とメディアが最初に提示された瞬間に、時差（MSで）を示すオプションのTLV要素。RTPレシーバーがメディアを正常に提示できない場合、この要素はレポートブロックに存在してはなりません。
Type: 4
タイプ：4
We next present the TLV elements that can be used when the RTP receiver supports and uses the RAMS method described in [RFC6285]. However, if the RTP receiver does not send a rapid acquisition request, the following TLV elements MUST NOT exist in the MA report block. Some elements may or may not exist depending on whether or not the RTP receiver receives any packet from the unicast burst and/or the primary multicast stream. These are explained below.
次に、RTPレシーバーが[RFC6285]で説明されているRAMSメソッドをサポートおよび使用するときに使用できるTLV要素を提示します。ただし、RTPレシーバーが迅速な取得要求を送信しない場合、MAレポートブロックに次のTLV要素が存在してはなりません。一部の要素は、RTPレシーバーがユニキャストバーストおよび/またはプライマリマルチキャストストリームからパケットを受信するかどうかによって存在する場合と存在しない場合があります。これらを以下に説明します。
o Application Request-to-RAMS Request Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the application became aware it would request a rapid acquisition and the instant the rapid acquisition request was actually sent by the application.
o アプリケーションリクエストリクエストリクエストデルタ時間（32ビット）：時差を示すオプションのTLV要素（MSで）アプリケーションが迅速な取得を要求する瞬間と、迅速な取得要求が実際に送信された瞬間に認識されましたアプリケーション。
Type: 11
タイプ：11
o RAMS Request-to-RAMS Information Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the rapid acquisition request was sent and the instant the
o ラムズリクエスト対策情報デルタ時間（32ビット）：迅速な取得要求が送信された瞬間と瞬間の間に時差（MSで）を示すオプションのTLV要素
first RAMS Information message was received in the unicast session. If no such message has been received, this element MUST NOT exist in the report block.
ユニキャストセッションで最初のRams情報メッセージが受信されました。そのようなメッセージが受信されていない場合、この要素はレポートブロックに存在してはなりません。
Type: 12
タイプ：12
o RAMS Request-to-Burst Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the rapid acquisition request was sent and the instant the first burst packet was received in the unicast session. If no burst packet has been received, this element MUST NOT exist in the report block.
o ラムズリクエスト - バーストへのリクエスト時間（32ビット）：迅速な取得要求が送信され、ユニキャストセッションで最初のバーストパケットが受信された瞬間の間の時差（MS）を示すオプションのTLV要素。バーストパケットが受信されていない場合、この要素はレポートブロックに存在してはなりません。
Type: 13
タイプ：13
o RAMS Request-to-Multicast Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the rapid acquisition request was sent and the instant the first RTP packet was received from the primary multicast stream. If no such packet has been received, this element MUST NOT exist in the report block.
o ラムズリクエスト - マルチキャストデルタ時間（32ビット）：迅速な取得要求が送信され、最初のRTPパケットがプライマリマルチキャストストリームから受信された瞬間の間の時差（MS）を示すオプションのTLV要素。そのようなパケットが受信されていない場合、この要素はレポートブロックに存在してはなりません。
Type: 14
タイプ：14
o RAMS Request-to-Burst-Completion Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the rapid acquisition request was sent and the instant the last burst packet was received in the unicast session. If no burst packet has been received, this element MUST NOT exist in the report block.
o ラムズリクエスト - バーストの完了デルタ時間（32ビット）：迅速な取得要求が送信され、最後のバーストパケットがユニキャストセッションで受信された瞬間の間の時差（MS）を示すオプションのTLV要素。バーストパケットが受信されていない場合、この要素はレポートブロックに存在してはなりません。
Type: 15
タイプ：15
o Number of Duplicate Packets (32 bits): OPTIONAL TLV element that denotes the number of duplicate packets due to receiving the same packet in both unicast and primary multicast RTP sessions. If no RTP packet has been received from the primary multicast stream, this element MUST NOT exist. If no burst packet has been received in the unicast session, the value of this element MUST be set to zero.
o 重複パケットの数（32ビット）：ユニキャストとプライマリマルチキャストRTPセッションの両方で同じパケットを受信したために重複するパケットの数を示すオプションのTLV要素。プライマリマルチキャストストリームからRTPパケットが受信されていない場合、この要素は存在してはなりません。ユニキャストセッションでバーストパケットが受信されていない場合、この要素の値をゼロに設定する必要があります。
Type: 16
タイプ：16
o Size of Burst-to-Multicast Gap (32 bits): OPTIONAL TLV element that denotes the greater of zero or the difference between the sequence number of the first multicast packet (received from the primary multicast stream) and the sequence number of the last burst packet minus 1 (considering the wrapping of the sequence
o バースト間ギャップのサイズ（32ビット）：最初のマルチキャストパケットのシーケンス番号（プライマリマルチキャストストリームから受信）と最後のバーストのシーケンス番号の差を示すオプションのTLV要素パケットマイナス1（シーケンスのラッピングを考慮して
numbers). If no burst packet has been received in the unicast session or no RTP packet has been received from the primary multicast stream, this element MUST NOT exist in the report block.
数字）。ユニキャストセッションでバーストパケットが受信されていない場合、またはプライマリマルチキャストストリームからRTPパケットが受信されていない場合、この要素はレポートブロックに存在してはなりません。
Type: 17
タイプ：17
It is desirable to allow vendors to use private extensions in TLV format. The range of [128-254] of TLV Types is reserved for private extensions. IANA management for these extensions is unnecessary; they are the responsibility of individual vendors.
ベンダーがTLV形式でプライベート拡張機能を使用できるようにすることが望ましいです。TLVタイプの[128-254]の範囲は、プライベートエクステンション用に予約されています。これらの拡張機能のIANA管理は不要です。それらは個々のベンダーの責任です。
Implementations use the structure depicted in Figure 3 for private extensions. Here, the private enterprise numbers are used from http://www.iana.org. This will ensure the uniqueness of the private extensions and avoid any collision.
実装は、プライベートエクステンションに図3に示されている構造を使用します。ここでは、プライベートエンタープライズ番号はhttp://www.iana.orgから使用されています。これにより、プライベートエクステンションの独自性が確保され、衝突を回避できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Structure of a Private Extension
図3：プライベートエクステンションの構造
A new unilateral parameter is defined for the MA report block to be used with the Session Description Protocol (SDP) [RFC4566]. In the following ABNF [RFC5234], xr-format is used as defined in [RFC3611].
セッション説明プロトコル（SDP）[RFC4566]で使用されるMAレポートブロックに対して、新しい一方的なパラメーターが定義されています。以下のABNF [RFC5234]では、XR形式は[RFC3611]で定義されているように使用されます。
xr-format =/ multicast-acq-ext multicast-acq-ext = "multicast-acq"
xr-format =/ multicast-acq-ext multicast-acq-ext = "multicast-acq"
Refer to Section 5.1 of [RFC3611] for a detailed description and the full syntax of the 'rtcp-xr' attribute.
[RTCP-XR '属性の詳細な説明と完全な構文については、[RFC3611]のセクション5.1を参照してください。
The security considerations of [RFC3611] apply in this document as well.
[RFC3611]のセキュリティ上の考慮事項は、このドキュメントにも適用されます。
The information contained in MA reports could be stolen as with any other RTCP reports if proper protection mechanism(s) are not in place. If desired, similar to other RTCP XRs, the MA reports MAY be protected by using Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) [RFC3711].
MAレポートに含まれる情報は、適切な保護メカニズムが整っていない場合、他のRTCPレポートと同様に盗まれる可能性があります。必要に応じて、他のRTCP XRと同様に、MAレポートは、Secure RTP（SRTP）およびSecure RTP Controlプロトコル（SRTCP）[RFC3711]を使用して保護される場合があります。
Malicious sniffing or otherwise obtaining MA report blocks can reveal performance characteristics of the RTP service and underlying network. This information is mostly available to an observer with the ability to capture RTP and RTCP session traffic. The contents and value of any private extension need to be studied when considering the necessity to secure the MA reports since application-level performance data might be present that is not otherwise available to an attacker, as with the required fields and vendor-neutral extensions.
悪意のあるスニッフィングまたはMAレポートブロックの取得は、RTPサービスと基礎となるネットワークのパフォーマンス特性を明らかにすることができます。この情報は、RTPおよびRTCPセッショントラフィックをキャプチャする機能を備えたオブザーバーが主に利用できます。必要なフィールドやベンダーに中立な拡張と同様に、アプリケーションレベルのパフォーマンスデータが存在しないため、アプリケーションレベルのパフォーマンスデータが存在する可能性があるため、MAレポートを保護する必要性を考慮する際に、プライベートエクステンションの内容と価値を調査する必要があります。
Using the MA reports to provide feedback into the acquisition of the multicast streams can introduce possible additional security implications. If a forged or otherwise modified MA report is received for an earlier acquisition attempt, invalid data can be used as input in later rapid acquisition attempts. For example, incorrectly small SFGMP join times could cause the unicast burst to be too short, leading to gaps in sequence numbers in the approach discussed in [RFC6285]. Additionally, forged reports could give the appearance that rapid acquisition is performing correctly when it is in fact failing, or vice versa. While integrity protection can be achieved in different ways, we RECOMMEND the use of SRTCP [RFC3711].
MAレポートを使用して、マルチキャストストリームの取得へのフィードバックを提供すると、可能な追加のセキュリティへの影響が導入される可能性があります。以前の買収試行のために偽造または修正されたMAレポートを受信した場合、無効なデータは、その後の迅速な取得の試みで入力として使用できます。たとえば、SFGMPの結合時間が誤って誤っていると、ユニキャストバーストが短すぎる可能性があり、[RFC6285]で説明されているアプローチでシーケンス数のギャップにつながる可能性があります。さらに、偽造されたレポートは、実際に失敗している場合、またはその逆の場合、迅速な獲得が正しく実行されているという外観を与える可能性があります。整合性保護はさまざまな方法で達成できますが、SRTCP [RFC3711]の使用をお勧めします。
The following contact information is provided for all registrations in this document:
このドキュメントのすべての登録に対して、次の連絡先情報が提供されています。
Ali Begen abegen@cisco.com
Ali Begen abegen@cisco.com
Type value 11 has been registered with IANA for the "Multicast Acquisition Report Block" in the RTCP XR Block Type Registry.
タイプ値11は、RTCP XRブロックタイプレジストリの「マルチキャスト取得レポートブロック」についてIANAに登録されています。
The SDP [RFC4566] parameter 'multicast-acq' for the 'rtcp-xr' attribute has been registered in the RTCP XR SDP Parameters Registry.
「RTCP-XR」属性のSDP [RFC4566]パラメーター「Multicast-ACQ」は、RTCP XR SDPパラメーターレジストリに登録されています。
A new IANA registry for the MA methods has been created. The registry is called the "Multicast Acquisition Method Registry". This registry is to be managed by IANA according to the Specification Required policy of [RFC5226].
MAメソッドの新しいIANAレジストリが作成されました。レジストリは「マルチキャスト取得方法レジストリ」と呼ばれます。このレジストリは、[RFC5226]の仕様が必要なポリシーに従ってIANAによって管理されます。
The length of the MA Method field is a single octet, allowing 256 values. The registry is initialized with the following entries:
MAメソッドフィールドの長さは単一のオクテットで、256の値が許可されています。レジストリは次のエントリで初期化されます。
MA Method Description Reference
--------- ------------------------------------ -------------
0 Reserved [RFC6332]
1 Simple join (No explicit method) [RFC6332]
2 RAMS [RFC6285]
3-254 Unassigned Specification Required
255 Reserved [RFC6332]
The MA Method values 0 and 255 are reserved for future use.
MAメソッド値0および255は、将来の使用のために予約されています。
Any registration for an unassigned value needs to contain the following information:
割り当てられていない価値の登録は、次の情報を含める必要があります。
o Contact information of the one doing the registration, including at least name, address, and email.
o 少なくとも名前、住所、電子メールを含む登録を行う人の連絡先情報。
o A detailed description of how the MA method works.
o MAメソッドの仕組みの詳細な説明。
A new IANA TLV space registry for the MA report block extensions has been created. The registry is called the "Multicast Acquisition Report Block TLV Space Registry". This registry is to be managed by the IANA according to the Specification Required policy of [RFC5226].
MAレポートブロック拡張機能の新しいIANA TLVスペースレジストリが作成されました。レジストリは「マルチキャスト取得レポートブロックTLVスペースレジストリ」と呼ばれます。このレジストリは、[RFC5226]の仕様が必要なポリシーに従ってIANAによって管理されます。
The length of the Type field in the TLV elements is a single octet, allowing 256 values. The registry is initialized with the following entries:
TLV要素のタイプフィールドの長さは単一のオクテットで、256の値が許可されています。レジストリは次のエントリで初期化されます。
Type Description Reference
------- -------------------------------------------------- ---------
0 Reserved [RFC6332]
1 RTP Seqnum of the First Multicast Packet [RFC6332]
2 SFGMP Join Time [RFC6332]
3 Application Request-to-Multicast Delta Time [RFC6332]
4 Application Request-to-Presentation Delta Time [RFC6332]
5-10 Unassigned Specification Required
11 Application Request-to-RAMS Request Delta Time [RFC6332]
12 RAMS Request-to-RAMS Information Delta Time [RFC6332]
13 RAMS Request-to-Burst Delta Time [RFC6332]
14 RAMS Request-to-Multicast Delta Time [RFC6332]
15 RAMS Request-to-Burst-Completion Delta Time [RFC6332]
16 Number of Duplicate Packets [RFC6332]
17 Size of Burst-to-Multicast Gap [RFC6332]
18-127 Unassigned Specification Required
128-254 Reserved for private extensions [RFC6332]
255 Reserved [RFC6332]
The Type values 0 and 255 are reserved for future use. The Type values between (and including) 128 and 254 are reserved for private extensions.
タイプ値0および255は、将来の使用のために予約されています。128と254の間（および含む）タイプ値は、プライベートエクステンション用に予約されています。
Any registration for an unassigned Type value needs to contain the following information:
割り当てられていないタイプの値の登録は、次の情報を含める必要があります。
o Contact information of the one doing the registration, including at least name, address, and email.
o 少なくとも名前、住所、電子メールを含む登録を行う人の連絡先情報。
o A detailed description of what the new TLV element represents and how it is interpreted.
o 新しいTLV要素が表すものとそれがどのように解釈されるかの詳細な説明。
A new IANA TLV space registry for the status codes has been created. The registry is called the "Multicast Acquisition Status Code Space Registry". This registry is to be managed by the IANA according to the Specification Required policy of [RFC5226].
ステータスコードの新しいIANA TLVスペースレジストリが作成されました。レジストリは「マルチキャスト取得ステータスコードスペースレジストリ」と呼ばれます。このレジストリは、[RFC5226]の仕様が必要なポリシーに従ってIANAによって管理されます。
The length of the Status field is two octets, allowing 65536 codes. However, the status codes have been registered to allow for an easier classification. For example, the values between (and including) 1 and 1000 are primarily used by the MA method of simple join. The values between (and including) 1001 and 2000 are used by the MA method described in [RFC6285]. When registering new status codes for the existing MA methods or newly defined MA methods, registrants are
ステータスフィールドの長さは2オクテットで、65536コードが許可されています。ただし、ステータスコードは登録されており、簡単に分類できるようになりました。たとえば、1と1000の間の値は、主に単純な結合のMAメソッドで使用されます。[RFC6285]で説明されているMAメソッドでは、1001と2000の間の値が使用されます。既存のMAメソッドまたは新たに定義されたMAメソッドの新しいステータスコードを登録する場合、登録者は
encouraged to allocate sufficient continuous space. Note that because of the limited space, not every MA method can be assigned 1000 different values for its status codes.
十分な連続スペースを割り当てることを奨励しています。スペースが限られているため、すべてのMAメソッドがステータスコードに1000の異なる値を割り当てることができるわけではないことに注意してください。
The status code 65535 is reserved for future use. The registry is initialized with the following entries:
ステータスコード65535は、将来の使用のために予約されています。レジストリは次のエントリで初期化されます。
Code Description Reference
--------- ------------------------------------------------ ---------
0 A private status code is included in the message [RFC6332]
1 Multicast join was successful [RFC6332]
2 Multicast join has failed [RFC6332]
3 A presentation error has occurred [RFC6332]
4 An unspecified RTP receiver internal error has
occurred [RFC6332]
5-1000 Unassigned
1001 RAMS has been successfully completed [RFC6332]
1002 No RAMS-R message has been sent [RFC6332]
1003 Invalid RAMS-I message syntax [RFC6332]
1004 RAMS-I message has timed out [RFC6332]
1005 RAMS unicast burst has timed out [RFC6332]
1006 An unspecified RTP receiver internal error has
occurred during RAMS [RFC6332]
1007 A presentation error has occurred during RAMS [RFC6332]
1008-65534 Unassigned
65535 Reserved [RFC6332]
Any registration for an unassigned status code needs to contain the following information:
割り当てられていないステータスコードの登録は、次の情報を含める必要があります。
o Contact information of the one doing the registration, including at least name, address, and email.
o 少なくとも名前、住所、電子メールを含む登録を行う人の連絡先情報。
o A detailed description of what the new status code describes and how it is interpreted.
o 新しいステータスコードが説明するものとそれがどのように解釈されるかの詳細な説明。
This specification has greatly benefited from discussions with Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom Van Caenegem, and many others. The authors would like to thank each of these individuals for their contributions.
この仕様は、マイケル・ラーグ、ドン・フスー、キャロル・イトゥルラルデ、Xuan Zhong、デイブ・オラン、トム・ヴァン・シェネゲムなどとの議論から大きな恩恵を受けています。著者は、これらの個人の貢献についてそれぞれに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611] Friedman、T.、Caceres、R。、およびA. Clark、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 2011.
[RFC6285] Ver Steeg、B.、Begen、A.、Van Caenegem、T.、およびZ. Vax、「UnicastベースのマルチキャストRTPセッションの迅速な獲得」、RFC 6285、2011年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Authors' Addresses
著者のアドレス
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco 181 Bay Street Toronto、M5J 2T3カナダ
EMail: abegen@cisco.com
Eric Friedrich Cisco 1414 Massachusetts Ave. Boxborough, MA 01719 USA
エリックフリードリッヒシスコ1414マサチューセッツアベニュー、ボックスボロー、マサチューセッツ州01719 USA
EMail: efriedri@cisco.com