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)
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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）は、メディアトランスポート[RFC3550]のためのリアルタイムトランスポートプロトコル（RTP）を使用するアプリケーションのための帯域外制御プロトコルです。 RTPエンティティに最小限の制御機能を提供することに加えて、RTCPも送信者と受信者のレポートを経由して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アプリケーションおよび/またはコンテンツ自体についての何らかの基準情報を取得する前に、一つ以上の以前のRTPパケット内のデータを復号化する前に、RTPパケット内のデータをデコードし、提示することができないかもしれません。このように、ランダムにマルチキャストセッションに参加しているRTP受信機は、多くの場合、ランダム取得遅延が発生します。この遅延を低減するために、[RFC6285]は補助ユニキャストRTPセッションが再送サーバと接合RTP受信機との間で確立されたアプローチを提案しています。このユニキャスト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の迅速な取得のための別の方法を使用する受信機またはそれらはまた、このレポートを使用して参加します。この方法では、マルチキャストサービスプロバイダは、定量的に異なる方法によって達成改善を比較することができます。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「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フィールドは、（207）XRに設定されています。
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]で指定されたルールに続いて、以下に定義ベースレポートや拡張のすべての整数フィールドはネットワークバイトオーダーで運ばれる、つまり、最上位バイト（オクテット）。特に断りのない限り、数値定数は、小数点（基数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法（例えば、単純参加、RAMS等）のタイプを表すフィールド。 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 SSRC（32ビット）：フィールド主マルチキャストストリームの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受信機はゼロにStatusフィールドを設定しなければなりません。 RTP受信機は実体が受け取るとXRは、プライベート拡張を理解して処理するアウトオブバンド方法から知っていない限り、プライベート拡張子がXRに使用してはいけません。
o Rsvd. (16 bits): The RTP receiver MUST set this field to zero. The recipient MUST ignore this field when received.
RSVD O。 （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 Methodフィールドで指定された特定の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レポートブロックの新しいフィールドを定義することが望ましいかもしれません。そのようなフィールドは、以下に記載し、図2に描かれるようTLV要素として符号化されるべきです。
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長さ：それらの間の型と長さフィールドと、8ビットのReservedフィールドを除くTLV要素の長さを（オクテットで）示す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：TLV要素最初のマルチキャストパケットのRTPシーケンス番号を指定し、プライマリマルチキャストストリームの受信しました。マルチキャスト加入が成功した場合、この要素が含まれなければなりません。マルチキャストパケットを受信していない場合は、この要素はレポートブロックに存在してはなりません。
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 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.
O SFGMPは時間（32ビット）に参加：SFGMPはメッセージが送信された参加インスタントと最初のパケットがマルチキャストセッションで受信された瞬間の間のゼロの大きいか（ミリ秒）の時間差を示しTLV要素。マルチキャスト加入が成功した場合、この要素が含まれなければなりません。マルチキャストパケットを受信していない場合は、この要素はレポートブロックに存在してはなりません。
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ビット）：オプションTLV要素アプリケーションが新しいマルチキャストセッションと第一のRTPパケットから受信された瞬間に参加するだろう知った瞬間の間（ミリ秒）の時間差を示し主なマルチキャストストリーム。そのようなパケットを受信していない場合は、この要素はレポートブロックに存在してはなりません。
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ビット）：オプションの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受信機は、迅速な取得要求を送信しない場合は、以下のTLV要素は、MAレポートブロックに存在してはなりません。いくつかの要素は、または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アプリケーションリクエストツーRAMS要求デルタタイム（32ビット）：オプションTLV要素アプリケーションが急速取得および急速取得要求が実際に送信された瞬間を要求する気づいた瞬間の間（ミリ秒）の時間差を示しアプリケーションによって。
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 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.
O RAMSリクエストツーRAMS情報デルタタイム（32ビット）：オプションTLV要素急速取得要求が送信されたインスタント及び第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 RAMSリクエスト・ツー・バーストデルタタイム（32ビット）：迅速な取得要求が送信されたインスタント及び最初のバーストパケットがユニキャストセッションで受信した瞬間の間（ミリ秒）の時間差を示しOPTIONAL 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 RAMSリクエスト・ツー・マルチキャストデルタタイム（32ビット）：オプションTLV要素急速取得要求が送信されたインスタント及び第一のRTPパケットは、プライマリマルチキャストストリームから受信された瞬間の間（ミリ秒）の時間差を表します。そのようなパケットを受信していない場合は、この要素はレポートブロックに存在してはなりません。
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 RAMSリクエスト・ツー・バースト完了デルタタイム（32ビット）：オプション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セッションで同一のパケットを受信すること、重複パケットの数を示しOPTIONAL 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 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.
バースト・ツー・マルチキャストギャップ（32ビット）のOサイズ：ゼロより大きいまたは（プライマリマルチキャストストリームから受信した）最初のマルチキャストパケットのシーケンス番号と最後のシーケンス番号との間の差を示しOPTIONAL TLV要素（シーケンス番号の折り返しを考慮して）バーストパケットマイナス1。いかなるバーストパケットがユニキャストセッションで受信されていないまたは全く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レポートブロックのために定義されています。 [RFC3611]で定義されるように、以下のABNF [RFC5234]において、XR-フォーマットが使用されます。
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].
適切な保護メカニズム（s）が所定の位置にない場合はMAレポートに含まれる情報は他のRTCPレポートのように盗まれる可能性があります。所望であれば、他のRTCP XRSと同様、MAレポートは、セキュアRTP（SRTP）およびセキュアRTP制御プロトコル（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
アリはabegen@cisco.com願っています
Type value 11 has been registered with IANA for the "Multicast Acquisition Report Block" in the RTCP XR Block Type Registry.
Type値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]パラメータ「マルチキャスト-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少なくとも名前、住所、電子メールなどの登録をしている1の情報を、お問い合わせください。
o A detailed description of how the MA method works.
MAの方法がどのように動作するかの詳細な説明O。
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少なくとも名前、住所、電子メールなどの登録をしている1の情報を、お問い合わせください。
o A detailed description of what the new TLV element represents and how it is interpreted.
新しいTLV要素を表し、それがどのように解釈されるものの詳細な説明を、O。
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 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.
Statusフィールドの長さは65536のコードをできるように、2つのオクテットです。しかし、ステータスコードは、簡単に分類できるように登録されています。例えば、間（及び含む）1〜1000の値は、主に単純な結合のMA法で使用されます。 1001と2000の間で（を含む）の値は、[RFC6285]に記載MA法で使用されます。既存のMA法または新しく定義されたMA法のための新しいステータスコードを登録する場合、登録者は、十分な連続領域を割り当てることをお勧めします。なぜなら、限られたスペースで、すべての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少なくとも名前、住所、電子メールなどの登録をしている1の情報を、お問い合わせください。
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.
この仕様は大幅にマイケルLague、ドン・スー、キャロルIturralde、玄忠、デイブ・オラン、トム・ヴァンCaenegem、および他の多くとの議論の恩恵を受けています。作者は彼らの貢献のために、これらの個人のそれぞれに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、フレデリック、R.、およびV.ヤコブソン、 "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]フリードマン、T.、カセレス、R.、およびA.クラーク、 "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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、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]版シュテーク、B.、Begen、A.、RFC 6285、2011年6月ヴァンCaenegem、T.、およびZ. Vaxの、 "マルチキャストRTPセッションのユニキャストベースの高速取得"。
[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
M5J 2T3カナダONアリBegenのCisco 181ベイストリートトロント、
EMail: abegen@cisco.com
メールアドレス：abegen@cisco.com
Eric Friedrich Cisco 1414 Massachusetts Ave. Boxborough, MA 01719 USA
エリック・フリードリヒのCisco 1414マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
EMail: efriedri@cisco.com
メールアドレス：efriedri@cisco.com