[要約] RFC 5775は、非同期層化コーディング（ALC）プロトコルのインスタンス化に関する情報を提供するものであり、ALCプロトコルの目的は、高い信頼性と効率的なデータ配信を実現することです。
Internet Engineering Task Force (IETF) M. Luby
Request for Comments: 5775 M. Watson
Obsoletes: 3450 L. Vicisano
Category: Standards Track Qualcomm, Inc.
ISSN: 2070-1721 April 2010
Asynchronous Layered Coding (ALC) Protocol Instantiation
非同期層コーディング（ALC）プロトコルインスタンス化
Abstract
概要
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450.
このドキュメントでは、非同期層コード（ALC）プロトコル、非常にスケーラブルな信頼できるコンテンツ配信プロトコルについて説明します。非同期層状コーディングは、層状コーディング輸送（LCT）ビルディングブロック、複数レートのうっ血制御ビルディングブロック、および前方エラー補正（FEC）ビルディングブロックを組み合わせて、渋滞制御された信頼できる非同期配信を1つの単一の同時受信機から無限の数の同時受信者に提供します送信者。このドキュメントは、RFC 3450を廃止します。
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/rfc5775.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5775で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Delivery Service Models . . . . . . . . . . . . . . . . . 4
1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Environmental Requirements and Considerations . . . . . . 5
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 5
2.1. LCT Building Block . . . . . . . . . . . . . . . . . . . . 7
2.2. Multiple Rate Congestion Control Building Block . . . . . 9
2.3. FEC Building Block . . . . . . . . . . . . . . . . . . . . 10
2.4. Session Description . . . . . . . . . . . . . . . . . . . 11
2.5. Packet Authentication Building Block . . . . . . . . . . . 12
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 12
4. Functionality Definition . . . . . . . . . . . . . . . . . . . 13
4.1. Packet Format Used by ALC . . . . . . . . . . . . . . . . 13
4.2. LCT Header Extension Fields . . . . . . . . . . . . . . . 14
4.3. Sender Operation . . . . . . . . . . . . . . . . . . . . . 15
4.4. Receiver Operation . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Baseline Secure ALC Operation . . . . . . . . . . . . . . 18
5.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 18
5.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. Changes from RFC 3450 . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
This document describes a massively scalable reliable content delivery protocol, Asynchronous Layered Coding (ALC), for multiple rate congestion controlled reliable content delivery. The protocol is specifically designed to provide massive scalability using IP multicast as the underlying network service. Massive scalability in this context means the number of concurrent receivers for an object is potentially in the millions, the aggregate size of objects to be delivered in a session ranges from hundreds of kilobytes to hundreds of gigabytes, each receiver can initiate reception of an object asynchronously, the reception rate of each receiver in the session is the maximum fair bandwidth available between that receiver and the sender, and all of this can be supported using a single sender.
このドキュメントでは、複数レートの混雑を制御する信頼できるコンテンツ配信のための、非常にスケーラブルな信頼性の高いコンテンツ配信プロトコル、非同期層コーディング（ALC）について説明します。このプロトコルは、基礎となるネットワークサービスとしてIPマルチキャストを使用して、大規模なスケーラビリティを提供するように特別に設計されています。このコンテキストでの大規模なスケーラビリティは、オブジェクトの同時受信機の数が潜在的に数百万であることを意味します。数百キロバイトから数百ギガバイトまでのセッション範囲で配信されるオブジェクトの総サイズは、各受信者が非同期にオブジェクトの受信を開始できます、セッション内の各レシーバーの受信率は、その受信者と送信者の間で利用可能な最大の公正帯域幅であり、これらすべては単一の送信者を使用してサポートできます。
Because ALC is focused on reliable content delivery, the goal is to deliver objects as quickly as possible to each receiver while at the same time remaining network friendly to competing traffic. Thus, the congestion control used in conjunction with ALC should strive to maximize use of available bandwidth between receivers and the sender while at the same time backing off aggressively in the face of competing traffic.
ALCは信頼できるコンテンツ配信に焦点を当てているため、目標は各レシーバーにできるだけ早くオブジェクトを配信すると同時に、競合するトラフィックに対してネットワークに優しいものです。したがって、ALCと連携して使用される混雑制御は、受信機と送信者間の利用可能な帯域幅の使用を最大化するよう努め、同時に競合するトラフィックに直面して積極的に後退します。
The sender side of ALC consists of generating packets based on objects to be delivered within the session and sending the appropriately formatted packets at the appropriate rates to the channels associated with the session. The receiver side of ALC consists of joining appropriate channels associated with the session, performing congestion control by adjusting the set of joined channels associated with the session in response to detected congestion, and using the packets to reliably reconstruct objects. All information flow in an ALC session is in the form of data packets sent by a single sender to channels that receivers join to receive data.
ALCの送信者側は、セッション内で配信されるオブジェクトに基づいてパケットを生成し、適切にフォーマットされたパケットを適切なレートでセッションに関連付けられたチャネルに送信することで構成されています。ALCのレシーバー側は、セッションに関連付けられた適切なチャネルの結合、検出された混雑に応じてセッションに関連付けられた結合チャネルのセットを調整し、パケットを使用してオブジェクトを確実に再構築することにより、渋滞制御を実行することで構成されています。ALCセッションのすべての情報フローは、データを受信するために受信者が参加するチャネルに単一の送信者によって送信されたデータパケットの形式です。
ALC does specify the Session Description needed by receivers before they join a session, but the mechanisms by which receivers obtain this required information is outside the scope of ALC. An application that uses ALC may require that receivers report statistics on their reception experience back to the sender, but the mechanisms by which receivers report back statistics is outside the scope of ALC. In general, ALC is designed to be a minimal protocol instantiation that provides reliable content delivery without unnecessary limitations to the scalability of the basic protocol.
ALCは、受信機がセッションに参加する前に必要なセッションの説明を指定しますが、受信機がこの必要な情報を取得するメカニズムはALCの範囲外です。ALCを使用するアプリケーションでは、受信者が受信体験に関する統計を送信者に報告する必要がある場合がありますが、受信機が統計を報告するメカニズムはALCの範囲外にあります。一般に、ALCは、基本プロトコルのスケーラビリティに不必要な制限なしに信頼性の高いコンテンツ配信を提供する最小限のプロトコルインスタンス化になるように設計されています。
This document is a product of the IETF RMT WG and follows the general guidelines provided in [RFC3269].
このドキュメントは、IETF RMT WGの製品であり、[RFC3269]で提供される一般的なガイドラインに従います。
A previous version of this document was published in the "Experimental" category as [RFC3450] and is obsoleted by this document.
このドキュメントの以前のバージョンは、[実験的]カテゴリで[RFC3450]として公開され、このドキュメントで廃止されています。
This Proposed Standard specification is thus based on and backwards compatible with the protocol defined in [RFC3450] updated according to accumulated experience and growing protocol maturity since its original publication. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
したがって、この提案された標準仕様は、元の出版物以降の累積経験とプロトコルの成長の成長に従って更新された[RFC3450]で定義されたプロトコルと互換性があることに基づいて互換性があります。上記の経験は、この仕様自体と、この仕様の使用に関連する混雑制御戦略の両方に適用されます。
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 BCP 14, [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、[RFC2119]に記載されているように解釈される。
ALC can support several different reliable content delivery service models as described in [RFC5651].
ALCは、[RFC5651]に記載されているように、いくつかの異なる信頼できるコンテンツ配信サービスモデルをサポートできます。
Massive scalability is a primary design goal for ALC. IP multicast is inherently massively scalable, but the best effort service that it provides does not provide session management functionality, congestion control, or reliability. ALC provides all of this on top of IP multicast without sacrificing any of the inherent scalability of IP multicast. ALC has the following properties:
大規模なスケーラビリティは、ALCの主要な設計目標です。IPマルチキャストは本質的に非常にスケーラブルですが、それが提供する最良の努力サービスは、セッション管理機能、混雑制御、または信頼性を提供しません。ALCは、IPマルチキャストの固有のスケーラビリティを犠牲にすることなく、IPマルチキャストの上にこれらすべてを提供します。ALCには次のプロパティがあります。
o To each receiver, it appears as if there is a dedicated session from the sender to the receiver, where the reception rate adjusts to congestion along the path from sender to receiver.
o 各レシーバーには、送信者から受信機への専用セッションがあるかのように見えます。ここでは、受信率が送信者から受信機へのパスに沿って混雑に適応します。
o To the sender, there is no difference in load or outgoing rate if one receiver or a million (or any number of) receivers are joined to the session, independent of when the receivers join and leave.
o 送信者にとって、レシーバーが参加して出発するときとは無関係に、1人の受信機または100万（または任意の数の）レシーバーがセッションに参加している場合、負荷または発信率に違いはありません。
o No feedback packets are required from receivers to the sender.
o 受信者から送信者へのフィードバックパケットは必要ありません。
o Almost all packets in the session that pass through a bottleneck link are utilized by downstream receivers, and the session shares the link with competing flows fairly in proportion to their utility.
o ボトルネックリンクを通過するセッション内のほとんどすべてのパケットは、ダウンストリームレシーバーによって使用され、セッションはユーティリティに比例して競合するフローとリンクを共有します。
Thus, ALC provides a massively scalable content delivery transport that is network friendly.
したがって、ALCは、ネットワークに優しい非常にスケーラブルなコンテンツ配信トランスポートを提供します。
ALC intentionally omits any application-specific features that could potentially limit its scalability. By doing so, ALC provides a minimal protocol that is massively scalable. Applications may be built on top of ALC to provide additional features that may limit the scalability of the application. Such applications are outside the scope of this document.
ALCは、スケーラビリティを潜在的に制限する可能性のあるアプリケーション固有の機能を意図的に省略します。そうすることで、ALCは非常にスケーラブルな最小限のプロトコルを提供します。アプリケーションは、ALCの上に構築され、アプリケーションのスケーラビリティを制限する可能性のある追加機能を提供できます。このようなアプリケーションは、このドキュメントの範囲外です。
All of the environmental requirements and considerations that apply to the LCT building block [RFC5651], the FEC building block [RFC5052], the multiple rate congestion control building block, and to any additional building blocks that ALC uses also apply to ALC.
LCTビルディングブロック[RFC5651]、FECビルディングブロック[RFC5052]、複数レートの混雑制御ビルディングブロック、およびALCが使用する追加のビルディングブロックにALCにも適用されるすべての環境要件と考慮事項。
The IP multicast model defined in [RFC1112] is commonly known as Any-Source Multicast (ASM), in contrast to Source-Specific Multicast (SSM) which is defined in [RFC3569]. One issue that is specific to ALC with respect to ASM is the way the multiple rate congestion control building block interacts with ASM. The congestion control building block may use the measured difference in time between when a join to a channel is sent and when the first packet from the channel arrives in determining the receiver reception rate. The congestion control building block may also use packet sequence numbers per channel to measure losses, and this is also used to determine the receiver reception rate. These features raise two concerns with respect to ASM: The time difference between when the join to a channel is sent and when the first packet arrives can be significant due to the use of Rendezvous Points (RPs) and the Multicast Source Discovery Protocol (MSDP) [RFC3618] protocol, and packets can be lost in the switch over from the (*,G) join to the RP and the (S,G) join directly to the sender. Both of these issues could potentially substantially degrade the reception rate of receivers. To ameliorate these concerns, it is recommended during deployment to ensure that the RP be as close to the sender as possible. SSM does not share these same concerns. For a fuller consideration of these issues, consult the multiple rate congestion control building block.
[RFC1112]で定義されているIPマルチキャストモデルは、[RFC3569]で定義されているソース固有のマルチキャスト（SSM）とは対照的に、任意のソースマルチキャスト（ASM）として一般的に知られています。ASMに関してALCに固有の1つの問題は、複数のレートの混雑制御ビルディングブロックがASMと相互作用する方法です。輻輳制御ビルディングブロックは、チャネルへの結合が送信されるときと、チャネルからの最初のパケットが受信者受信率を決定する際に到着するときの間の時間の測定された差を使用する場合があります。輻輳制御ビルディングブロックは、チャネルごとのパケットシーケンス番号を使用して損失を測定することもできます。これは、受信者の受信率を決定するためにも使用されます。これらの機能は、ASMに関して2つの懸念を引き起こします。チャネルへの結合が送信されたときと最初のパケットが到着したときの時間差は、ランデブーポイント（RPS）とマルチキャストソースディスカバリープロトコル（MSDP）の使用により重要になる可能性があります。[RFC3618]プロトコル、およびパケットは（*、g）結合からRPへのスイッチで失われ、（s、g）が送信者に直接結合します。これらの問題は両方とも、受信者の受信率を大幅に劣化させる可能性があります。これらの懸念を改善するために、展開中にRPが可能な限り送信者に近づくことを保証することをお勧めします。SSMはこれらの同じ懸念を共有していません。これらの問題をより詳細に検討するには、複数のレートの混雑制御ビルディングブロックを参照してください。
ALC uses the LCT building block [RFC5651] to provide in-band session management functionality. ALC uses a multiple rate congestion control building block that is compliant with [RFC2357] to provide congestion control that is feedback free. Receivers adjust their reception rates individually by joining and leaving channels associated with the session. ALC uses the FEC building block [RFC5052] to provide reliability. The sender generates encoding symbols based on the object to be delivered using FEC codes and sends them in packets to channels associated with the session. Receivers simply wait for enough packets to arrive in order to reliably reconstruct the object. Thus, there is no request for retransmission of individual packets from receivers that miss packets in order to assure reliable reception of an object, and the packets and their rate of transmission out of the sender can be independent of the number and the individual reception experiences of the receivers.
ALCは、LCTビルディングブロック[RFC5651]を使用して、バンド内セッション管理機能を提供します。ALCは、[RFC2357]に準拠した複数のレートの混雑制御ビルディングブロックを使用して、フィードバックフリーのうっ血制御を提供します。受信者は、セッションに関連付けられたチャネルに参加および離れることにより、レセプション率を個別に調整します。ALCは、FECビルディングブロック[RFC5052]を使用して信頼性を提供します。送信者は、FECコードを使用して配信されるオブジェクトに基づいてエンコードシンボルを生成し、セッションに関連付けられたチャネルにパケットに送信します。受信機は、オブジェクトを確実に再構築するために十分なパケットが到着するのを待つだけです。したがって、オブジェクトの信頼できる受信を保証するためにパケットを逃すレシーバーからの個々のパケットの再送信のリクエストはありません。受信機。
The definition of a session for ALC is the same as it is for LCT. An ALC session comprises multiple channels originating at a single sender that are used for some period of time to carry packets pertaining to the transmission of one or more objects that can be of interest to receivers. Congestion control is performed over the aggregate of packets sent to channels belonging to a session. The fact that an ALC session is restricted to a single sender does not preclude the possibility of receiving packets for the same objects from multiple senders. However, each sender would be sending packets to a different session to which congestion control is individually applied. Although receiving concurrently from multiple sessions is allowed, how this is done at the application level is outside the scope of this document.
ALCのセッションの定義は、LCTと同じです。ALCセッションは、レシーバーにとって興味深い1つ以上のオブジェクトの送信に関連するパケットを運ぶために、ある期間使用される単一の送信者を発信する複数のチャネルで構成されています。輻輳制御は、セッションに属するチャネルに送信されるパケットの集合体で実行されます。ALCセッションが単一の送信者に制限されているという事実は、複数の送信者から同じオブジェクトのパケットを受信する可能性を排除しません。ただし、各送信者は、渋滞制御が個別に適用される別のセッションにパケットを送信します。複数のセッションから同時に受信することは許可されていますが、アプリケーションレベルでこれがどのように行われるかは、このドキュメントの範囲外です。
ALC is a protocol instantiation as defined in [RFC3048]. This document describes version 1 of ALC, which MUST use version 1 of LCT described in [RFC5651]. Like LCT, ALC is designed to be used with the IP multicast network service. This specification defines ALC as payload of the UDP transport protocol [RFC0768] that supports the IP multicast delivery of packets.
ALCは、[RFC3048]で定義されているプロトコルインスタンス化です。このドキュメントでは、[RFC5651]で説明されているLCTのバージョン1を使用する必要があるALCのバージョン1について説明します。LCTと同様に、ALCはIPマルチキャストネットワークサービスで使用するように設計されています。この仕様では、ALCは、パケットのIPマルチキャスト配信をサポートするUDPトランスポートプロトコル[RFC0768]のペイロードとして定義しています。
The ALC packet format is illustrated in Figure 1. An ALC packet header immediately follows the IP/UDP header and consists of the default LCT header that is described in [RFC5651] followed by the FEC Payload ID that is described in [RFC5052]. The Congestion Control Information field within the LCT header carries the required Congestion Control Information that is described in the multiple rate congestion control building block specified that is compliant with [RFC2357]. The packet payload that follows the ALC packet header consists of encoding symbols that are identified by the FEC Payload ID as described in [RFC5052].
ALCパケット形式を図1に示します。ALCパケットヘッダーは、IP/UDPヘッダーをすぐに追跡し、[RFC5651]で説明されているデフォルトのLCTヘッダーで構成され、[RFC5052]で説明されているFECペイロードIDが続きます。LCTヘッダー内の輻輳制御情報フィールドには、[RFC2357]に準拠した複数のレートの混雑制御ビルディングブロックに記載されている必要な輻輳制御情報が搭載されています。ALCパケットヘッダーに続くパケットペイロードは、[RFC5052]で説明されているように、FECペイロードIDによって識別されるエンコードシンボルで構成されています。
+----------------------------------------+
| IP Header |
+----------------------------------------+
| UDP Header |
+----------------------------------------+
| LCT Header |
+----------------------------------------+
| FEC Payload Id |
+----------------------------------------+
| Encoding Symbols |
+----------------------------------------+
Figure 1: ALC Packet Format
図1：ALCパケット形式
Each receiver is required to obtain a Session Description before joining an ALC session. As described later, the Session Description includes out-of-band information required for the LCT, FEC, and the multiple rate congestion control building blocks. The FEC Object Transmission Information specified in the FEC building block [RFC5052] required for each object to be received by a receiver can be communicated to a receiver either out-of-band or in-band using a Header Extension. The means for communicating the Session Description and the FEC Object Transmission Information to a receiver is outside the scope of this document.
各レシーバーは、ALCセッションに参加する前にセッションの説明を取得する必要があります。後で説明したように、セッションの説明には、LCT、FEC、および複数レートの輻輳制御ビルディングブロックに必要なバンド外情報が含まれています。FECビルディングブロック[RFC5052]で指定されたFECオブジェクトトランスミッション情報は、各オブジェクトを受信者に受信するために必要な情報を、ヘッダー拡張機能を使用して、帯域外または帯域内のいずれかのレシーバーに通知できます。セッションの説明とFECオブジェクト伝送情報を受信機に伝える手段は、このドキュメントの範囲外です。
LCT requires receivers to be able to uniquely identify and demultiplex packets associated with an LCT session, and ALC inherits and strengthens this requirement. A Transport Session Identifier (TSI) MUST be associated with each session and MUST be carried in the LCT header of each ALC packet. The TSI is scoped by the sender IP address, and the (sender IP address, TSI) pair MUST uniquely identify the session.
LCTでは、レシーバーがLCTセッションに関連付けられているパケットを一意に識別して反映していることを要求し、ALCはこの要件を継承して強化します。トランスポートセッション識別子（TSI）は各セッションに関連付けられている必要があり、各ALCパケットのLCTヘッダーに携帯する必要があります。TSIは送信者IPアドレスによってスコープされ、（送信者IPアドレス、TSI）ペアはセッションを一意に識別する必要があります。
The LCT header contains a Congestion Control Information (CCI) field that MUST be used to carry the Congestion Control Information from the specified multiple rate congestion control protocol. There is a field in the LCT header that specifies the length of the CCI field, and the multiple rate congestion control building block MUST uniquely identify a format of the CCI field that corresponds to this length.
LCTヘッダーには、指定された複数レートの混雑制御プロトコルから輻輳制御情報を運ぶために使用する必要がある輻輳制御情報（CCI）フィールドが含まれています。LCTヘッダーには、CCIフィールドの長さを指定するフィールドがあり、複数レートの輻輳制御ビルディングブロックは、この長さに対応するCCIフィールドの形式を一意に識別する必要があります。
The LCT header contains a Codepoint field that MAY be used to communicate to a receiver the settings for information that may vary during a session. If used, the mapping between settings and Codepoint values is to be communicated in the Session Description, and this mapping is outside the scope of this document. For example, the FEC Encoding ID that is part of the FEC Object Transmission Information, as specified in the FEC building block [RFC5052], could vary for each object carried in the session, and the Codepoint value could be used to communicate the FEC Encoding ID to be used for each object. The mapping between FEC Encoding IDs and Codepoints could be, for example, the identity mapping.
LCTヘッダーには、セッション中に異なる可能性のある情報の設定を受信者と通信するために使用できるCodePointフィールドが含まれています。使用すると、設定とCodePoint値の間のマッピングはセッションの説明で通知され、このマッピングはこのドキュメントの範囲外です。たとえば、FECビルディングブロック[RFC5052]で指定されているFECオブジェクトトランスミッション情報の一部であるFECエンコードIDは、セッションで携帯される各オブジェクトに対して異なる可能性があり、CodePoint値を使用してFECエンコードの通信を使用できます。各オブジェクトに使用されるid。FECエンコードIDとCodePointのマッピングは、たとえばIDマッピングである可能性があります。
If more than one object is to be carried within a session, then the Transmission Object Identifier (TOI) MUST be used in the LCT header to identify which packets are to be associated with which objects. In this case, the receiver MUST use the TOI to associate received packets with objects. The TOI is scoped by the IP address of the sender and the TSI, i.e., the TOI is scoped by the session. The TOI for each object is REQUIRED to be unique within a session, but is not required be unique across sessions. Furthermore, the same object MAY have a different TOI in different sessions. The mapping between TOIs and objects carried in a session is outside the scope of this document.
セッション内で複数のオブジェクトを携帯する場合は、LCTヘッダーで送信オブジェクト識別子（TOI）を使用して、どのパケットがどのオブジェクトに関連付けられるかを識別する必要があります。この場合、受信者はTOIを使用して、受信したパケットをオブジェクトに関連付ける必要があります。TOIは、送信者のIPアドレスとTSI、つまりTOIがセッションによってスコープされます。各オブジェクトのTOIはセッション内で一意である必要がありますが、セッション全体で一意である必要はありません。さらに、同じオブジェクトが異なるセッションで異なるTOIを持っている可能性があります。TOIとセッションで運ばれるオブジェクトの間のマッピングは、このドキュメントの範囲外です。
If only one object is carried within a session, then the TOI MAY be omitted from the LCT header.
セッション内で1つのオブジェクトのみが運ばれる場合、TOIはLCTヘッダーから省略できます。
The LCT header from version 1 of the LCT building block [RFC5651] MUST be used.
LCTビルディングブロック[RFC5651]のバージョン1のLCTヘッダーを使用する必要があります。
The LCT Header includes a two-bit Protocol Specific Indication (PSI) field in bits 6 and 7 of the first word of the LCT header. These two bits are used by ALC as follows:
LCTヘッダーには、LCTヘッダーの最初の単語のビット6および7の2ビットプロトコル固有の表示（PSI）フィールドが含まれています。これらの2つのビットは、ALCによって次のように使用されます。
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
+-+-+
...|X|Y|...
+-+-+
Figure 2: PSI Bits within LCT Header
図2：LCTヘッダー内のPSIビット
PSI bit X - Source Packet Indicator (SPI)
PSIビットX-ソースパケットインジケーター（SPI）
PSI bit Y - Reserved
psi bit y-予約
The Source Packet Indicator is used with systematic FEC Schemes which define a different FEC Payload ID format for packets containing only source data compared to the FEC Payload ID format for packets containing repair data. For such FEC Schemes, the SPI MUST be set to 1 when the FEC Payload ID format for packets containing only source data is used, and the SPI MUST be set to zero when the FEC Payload ID for packets containing repair data is used. In the case of FEC Schemes that define only a single FEC Payload ID format, the SPI MUST be set to zero by the sender and MUST be ignored by the receiver.
ソースパケットインジケーターは、修理データを含むパケットのFECペイロードID形式と比較して、ソースデータのみを含むパケットの異なるFECペイロードID形式を定義する系統的FECスキームで使用されます。このようなFECスキームの場合、ソースデータのみを含むパケットのFECペイロードID形式が使用される場合は、SPIを1に設定する必要があり、修理データを含むパケットのFECペイロードIDを使用する場合、SPIをゼロに設定する必要があります。単一のFECペイロードID形式のみを定義するFECスキームの場合、SPIは送信者によってゼロに設定され、受信機によって無視する必要があります。
Support of two FEC Payload ID formats allows FEC Payload ID information that is only of relevance when FEC decoding is to be performed to be provided in the FEC Payload ID format for packets containing repair data. This information need not be processed by receivers that do not perform FEC decoding (either because no FEC decoding is required or because the receiver does not support FEC decoding).
2つのFECペイロードIDフォーマットのサポートにより、FECデコードが実行される場合にのみ、FECペイロードID情報が、修理データを含むパケットのFECペイロードID形式で提供される場合にのみ関連性があります。この情報は、FECデコードを実行しない受信機によって処理する必要はありません（FECデコードが不要なため、または受信機がFECデコードをサポートしていないため）。
At a minimum, implementations of ALC MUST support [RFC3738]. Note that [RFC3738] has been published in the "Experimental" category and thus has lower maturity level than the present document. Caution should be used since it may be less stable than this document.
少なくとも、ALCの実装は[RFC3738]をサポートする必要があります。[RFC3738]は「実験」カテゴリに掲載されているため、現在のドキュメントよりも低い成熟度レベルを持っていることに注意してください。このドキュメントよりも安定性が低い可能性があるため、注意が必要です。
Congestion control MUST be applied to all packets within a session independently of which information about which object is carried in each packet. Multiple rate congestion control is specified because of its suitability to scale massively and because of its suitability for reliable content delivery. [RFC3738] specifies in-band Congestion Control Information (CCI) that MUST be carried in the CCI field of the LCT header.
輻輳制御は、各パケットにどのオブジェクトが運ばれているかについての情報とは無関係にセッション内のすべてのパケットに適用する必要があります。複数のレートの混雑制御が指定されています。これは、大規模にスケーリングする適合性と、信頼できるコンテンツ配信に適しているためです。[RFC3738]は、LCTヘッダーのCCIフィールドで運ばなければならないバンド浸漬制御情報（CCI）を指定します。
Alternative multiple rate congestion control building blocks MAY be supported, but only a single congestion control building block may be used in a given ALC session. The congestion control building block to be used in an ALC session is specified in the Session Description (see Section 2.4). A multiple rate congestion control building block MAY specify more than one format for the CCI field, but it MUST specify at most one format for each of the possible lengths 32, 64, 96, or 128 bits. The value of C in the LCT header that determines the length of the CCI field MUST correspond to one of the lengths for the CCI defined in the multiple rate congestion control building block; this length MUST be the same for all packets sent to a session, and the CCI format that corresponds to the length as specified in the multiple rate congestion control building block MUST be the format used for the CCI field in the LCT header.
代替の複数のレート輻輳制御ビルディングブロックがサポートされる場合がありますが、特定のALCセッションでは、単一の輻輳制御ビルディングブロックのみを使用できます。ALCセッションで使用される混雑制御ビルドブロックは、セッションの説明で指定されています（セクション2.4を参照）。複数のレートの混雑制御ビルディングブロックは、CCIフィールドに複数の形式を指定する場合がありますが、可能な長さ32、64、96、または128ビットのそれぞれについて、最大1つの形式で指定する必要があります。CCIフィールドの長さを決定するLCTヘッダー内のCの値は、複数レートの混雑制御ビルディングブロックで定義されたCCIの長さの1つに対応する必要があります。この長さは、セッションに送信されたすべてのパケットで同じでなければならず、複数レートの混雑制御ビルディングブロックで指定されている長さに対応するCCI形式は、LCTヘッダーのCCIフィールドに使用される形式でなければなりません。
When using a multiple rate congestion control building block, a sender sends packets in the session to several channels at potentially different rates. Then, individual receivers adjust their reception rate within a session by adjusting to which set of channels they are joined at each point in time depending on the available bandwidth between the receiver and the sender, but independent of other receivers.
複数のレートの混雑制御ビルディングブロックを使用する場合、送信者はセッション内のパケットを潜在的に異なるレートで複数のチャネルに送信します。次に、個々のレシーバーは、受信者と送信者間の利用可能な帯域幅に応じて、他のレシーバーとは無関係に、各時点で参加するチャネルのセットを調整することにより、セッション内で受信率を調整します。
The FEC building block [RFC5052] provides reliable object delivery within an ALC session. Each object sent in the session is independently encoded using FEC codes as described in [RFC3453], which provide a more in-depth description of the use of FEC codes in reliable content delivery protocols. All packets in an ALC session MUST contain an FEC Payload ID in a format that is compliant with the FEC Scheme in use. The FEC Payload ID uniquely identifies the encoding symbols that constitute the payload of each packet, and the receiver MUST use the FEC Payload ID to determine how the encoding symbols carried in the payload of the packet were generated from the object as described in the FEC building block.
FECビルディングブロック[RFC5052]は、ALCセッション内で信頼できるオブジェクト配信を提供します。セッションで送信される各オブジェクトは、[RFC3453]で説明されているようにFECコードを使用して独立してエンコードされます。これは、信頼できるコンテンツ配信プロトコルでのFECコードの使用に関するより詳細な説明を提供します。ALCセッション内のすべてのパケットには、使用中のFECスキームに準拠した形式のFECペイロードIDを含める必要があります。FECペイロードIDは、各パケットのペイロードを構成するエンコードシンボルを一意に識別し、受信者はFECペイロードIDを使用して、Packetのペイロードに掲載されたエンコードシンボルがFECビルディングで説明されているようにオブジェクトから生成された方法を決定する必要があります。ブロック。
As described in [RFC5052], a receiver is REQUIRED to obtain the FEC Object Transmission Information for each object for which data packets are received from the session. In the context of ALC, the FEC Object Transmission Information includes:
[RFC5052]で説明されているように、セッションからデータパケットが受信される各オブジェクトのFECオブジェクト伝送情報を取得するには、受信機が必要です。ALCのコンテキストでは、FECオブジェクト伝送情報には次のものが含まれます。
o The FEC Encoding ID.
o FECエンコーディングID。
o If an Under-Specified FEC Encoding ID is used, then the FEC Instance ID associated with the FEC Encoding ID.
o 不足しているFECエンコードIDが使用されている場合、FECエンコードIDに関連付けられたFECインスタンスID。
o For each object in the session, the transfer length of the object in bytes.
o セッション内の各オブジェクトについて、バイト内のオブジェクトの転送長。
Additional FEC Object Transmission Information may be required depending on the FEC Scheme that is used (identified by the FEC Encoding ID).
追加のFECオブジェクト伝送情報は、使用されるFECスキーム（FECエンコードIDで識別）に応じて必要になる場合があります。
Some of the FEC Object Transmission Information MAY be implicit based on the FEC Scheme and/or implementation. As an example, source block lengths may be derived by a fixed algorithm from the object length. As another example, it may be that all source blocks are the same length and this is what is passed out-of-band to the receiver. As another example, it could be that the full-sized source block length is provided, and this is the length used for all but the last source block, which is calculated based on the full source block length and the object length. As another example, it could be that the same FEC Encoding ID and FEC Instance ID are always used for a particular application, and thus the FEC Encoding ID and FEC Instance ID are implicitly defined.
FECオブジェクト伝送情報の一部は、FECスキームおよび/または実装に基づいて暗黙的になる場合があります。例として、ソースブロックの長さは、オブジェクト長から固定アルゴリズムによって導出される場合があります。別の例として、すべてのソースブロックが同じ長さであり、これがレシーバーに帯域外に渡されるものである可能性があります。別の例として、フルサイズのソースブロックの長さが提供されている可能性があり、これは完全なソースブロックの長さとオブジェクト長に基づいて計算される最後のソースブロックを除くすべてに使用される長さです。別の例として、同じFECエンコードIDおよびFECインスタンスIDが常に特定のアプリケーションに使用されるため、FECエンコードIDおよびFECインスタンスIDが暗黙的に定義されている可能性があります。
Sometimes the objects that will be sent in a session are completely known before the receiver joins the session, in which case the FEC Object Transmission Information for all objects in the session can be communicated to receivers before they join the session. At other times, the objects may not know when the session begins, receivers may join a session in progress and may not be interested in some objects for which transmission has finished, or receivers may leave a session before some objects are even available within the session. In these cases, the FEC Object Transmission Information for each object may be dynamically communicated to receivers at or before the time packets for the object are received from the session. This may be accomplished using an out-of-band mechanism, in-band using the Codepoint field or a Header Extension, or any combination of these methods. How the FEC Object Transmission Information is communicated to receivers is outside the scope of this document.
セッションで送信されるオブジェクトは、受信者がセッションに参加する前に完全に知られている場合があります。この場合、セッション内のすべてのオブジェクトのFECオブジェクト伝送情報は、セッションに参加する前に受信機に通信できます。それ以外の場合、オブジェクトはセッションがいつ開始されるか、受信者が進行中のセッションに参加し、送信が完了したオブジェクトに興味がない場合があります。。これらの場合、各オブジェクトのFECオブジェクト伝送情報は、オブジェクトの時間パケットがセッションから受信されるか、または前に受信機に動的に通知される場合があります。これは、帯域外のメカニズム、CodePointフィールドまたはヘッダー拡張機能、またはこれらの方法の任意の組み合わせを使用して帯域内の帯域を使用して達成できます。FECオブジェクトの伝送情報が受信機に伝達される方法は、このドキュメントの範囲外です。
Before a receiver can join an ALC session, the receiver needs to obtain a Session Description that contains the following information:
受信者がALCセッションに参加する前に、受信者は次の情報を含むセッションの説明を取得する必要があります。
o The multiple rate congestion control building block to be used for the session;
o セッションに使用される複数レートの混雑制御ビルディングブロック。
o The sender IP address;
o 送信者IPアドレス。
o The number of channels in the session;
o セッション内のチャネルの数。
o The address and port number used for each channel in the session;
o セッション内の各チャネルに使用されるアドレスとポート番号。
o The Transport Session ID (TSI) to be used for the session;
o セッションに使用されるトランスポートセッションID（TSI）。
o An indication of whether or not the session carries packets for more than one object;
o セッションが複数のオブジェクトのパケットを搭載しているかどうかの指標。
o If Header Extensions are to be used, the format of these Header Extensions.
o ヘッダー拡張機能を使用する場合、これらのヘッダー拡張機能の形式。
o Enough information to determine the packet authentication scheme being used, if one is being used.
o 使用されている場合、使用されているパケット認証スキームを決定するのに十分な情報。
How the Session Description is communicated to receivers is outside the scope of this document.
セッションの説明が受信機に伝達される方法は、このドキュメントの範囲外です。
The Codepoint field within the LCT portion of the header CAN be used to communicate in-band some of the dynamically changing information within a session. To do this, a mapping between Codepoint values and the different dynamic settings MUST be included within the Session Description, and then settings to be used are communicated via the Codepoint value placed into each packet. For example, it is possible that multiple objects are delivered within the same session and that a different FEC encoding algorithm is used for different types of objects. Then the Session Description could contain the mapping between Codepoint values and FEC Encoding IDs. As another example, it is possible that a different packet authentication scheme is used for different packets sent to the session. In this case, the mapping between the packet authentication scheme and Codepoint values could be provided in the Session Description. Combinations of settings can be mapped to Codepoint values as well. For example, a particular combination of a FEC Encoding ID and a packet authentication scheme could be associated with a Codepoint value.
ヘッダーのLCT部分内のCodePointフィールドを使用して、セッション内で動的に変化する情報の一部を帯域内に通信できます。これを行うには、CodePoint値とさまざまな動的設定のマッピングをセッションの説明に含める必要があり、使用する設定は各パケットに配置されたCodePoint値を介して通知されます。たとえば、同じセッション内で複数のオブジェクトが配信され、異なるタイプのオブジェクトに異なるFECエンコードアルゴリズムが使用される可能性があります。セッションの説明には、CodePoint値とFECエンコードIDのマッピングが含まれます。別の例として、セッションに送信された異なるパケットに別のパケット認証スキームが使用される可能性があります。この場合、パケット認証スキームとCodePoint値のマッピングをセッションの説明で提供できます。設定の組み合わせも、コードポイント値にマッピングできます。たとえば、FECエンコードIDとパケット認証スキームの特定の組み合わせは、CodePoint値に関連付けられている可能性があります。
The Session Description could also include, but is not limited to:
セッションの説明には含めることもできますが、以下に限定されません。
o The mappings between combinations of settings and Codepoint values;
o 設定の組み合わせとCodePoint値の間のマッピング。
o The data rates used for each channel;
o 各チャネルに使用されるデータレート。
o The length of the packet payload;
o パケットペイロードの長さ。
o Any information that is relevant to each object being transported, such as the Object Transmission Information for each object, when the object will be available within the session, and for how long.
o 各オブジェクトのオブジェクト伝送情報、セッション内でオブジェクトが利用可能になる場合、どのくらいの期間、輸送される各オブジェクトに関連する情報。
The Session Description could be in a form such as the Session Description Protocol (SDP) as defined in [RFC4566], XML metadata as defined in [RFC3023], or HTTP/MIME headers as defined in [RFC2616], etc. It might be carried in a session announcement protocol such as SAP as defined in [RFC2974], obtained using a proprietary session control protocol, located on a web page with scheduling information, or conveyed via email or other out-of-band methods. Discussion of Session Description formats and methods for communication of Session Descriptions to receivers is beyond the scope of this document.
セッションの説明は、[RFC4566]で定義されているセッション説明プロトコル（SDP）、[RFC3023]で定義されているXMLメタデータ、または[RFC2616]で定義されているHTTP/MIMEヘッダーなどの形式である可能性があります。[RFC2974]で定義されているSAPなどのセッションアナウンスプロトコルに掲載され、独自のセッション制御プロトコルを使用して取得し、情報をスケジュールしたWebページにある、または電子メールまたはその他の帯域外の方法で伝えられます。セッションの説明の説明形式とセッション説明の通信のための方法は、受信機への通信方法は、このドキュメントの範囲を超えています。
It is RECOMMENDED that implementors of ALC use some packet authentication scheme to protect the protocol from attacks. Suitable schemes are described in [RFC5776] and [RMT-SIMPLE].
アルコールの実装者は、プロトコルを攻撃から保護するために、パケット認証スキームを使用することをお勧めします。適切なスキームは[RFC 5776]および[RMT-Simple]で説明されています。
This Protocol Instantiation document, in conjunction with the LCT building block [RFC5651], the FEC building block [RFC5052], and [RFC3738] completely specifies a working reliable multicast transport protocol that conforms to the requirements described in [RFC2357].
このプロトコルインスタンス化ドキュメントは、LCTビルディングブロック[RFC5651]、FECビルディングブロック[RFC5052]、および[RFC3738]と併せて、[RFC2357]に記載されている要件に準拠する実用的な信頼できるマルチキャストトランスポートプロトコルを完全に指定しています。
This section describes the format and functionality of the data packets carried in an ALC session as well as the sender and receiver operations for a session.
このセクションでは、ALCセッションで掲載されたデータパケットの形式と機能、およびセッションの送信者と受信機の操作について説明します。
The packet format used by ALC is the UDP header followed by the LCT header followed by the FEC Payload ID followed by the packet payload. The LCT header is defined in the LCT building block [RFC5651] and the FEC Payload ID is described in the FEC building block [RFC5052]. The Congestion Control Information field in the LCT header contains the required Congestion Control Information that is described in the multiple rate congestion control building block used. The packet payload contains encoding symbols generated from an object. If more than one object is carried in the session, then the Transmission Object ID (TOI) within the LCT header MUST be used to identify from which object the encoding symbols are generated. Within the scope of an object, encoding symbols carried in the payload of the packet are identified by the FEC Payload ID as described in the FEC building block.
ALCが使用するパケット形式は、UDPヘッダーに続いてLCTヘッダーが続いてFECペイロードIDが続き、パケットペイロードが続きます。LCTヘッダーはLCTビルディングブロック[RFC5651]で定義され、FECペイロードIDはFECビルディングブロック[RFC5052]で説明されています。LCTヘッダーの輻輳制御情報フィールドには、使用される複数のレートの混雑制御ビルドブロックに記載されている必要な輻輳制御情報が含まれています。パケットペイロードには、オブジェクトから生成されたエンコードシンボルが含まれています。セッションで複数のオブジェクトが運ばれている場合、LCTヘッダー内の送信オブジェクトID（TOI）を使用して、エンコードシンボルが生成されるオブジェクトを識別する必要があります。オブジェクトの範囲内で、パケットのペイロードで運ばれるエンコードシンボルは、FECビルディングブロックで説明されているように、FECペイロードIDによって識別されます。
The version number of ALC specified in this document is 1. The version number field of the LCT header MUST be interpreted as the ALC version number field. This version of ALC implicitly makes use of version 1 of the LCT building block defined in [RFC5651].
このドキュメントで指定されたALCのバージョン番号は1です。LCTヘッダーのバージョン番号フィールドは、ALCバージョン番号フィールドとして解釈する必要があります。ALCのこのバージョンは、[RFC5651]で定義されたLCTビルディングブロックのバージョン1を暗黙的に使用しています。
The overall ALC packet format is depicted in Figure 3. The packet is an IP packet, either IPv4 or IPv6, and the IP header precedes the UDP header. The ALC packet format has no dependencies on the IP version number.
全体のALCパケット形式を図3に示します。パケットはIPv4またはIPv6のいずれかのIPパケットであり、IPヘッダーはUDPヘッダーの前にあります。ALCパケット形式には、IPバージョン番号に依存関係がありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| LCT Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Overall ALC Packet Format
図3：全体的なALCパケット形式
In some special cases an ALC sender may need to produce ALC packets that do not contain any payload. This may be required, for example, to signal the end of a session or to convey congestion control information. These data-less packets do not contain the FEC Payload ID either, but only the LCT header fields. The total datagram length, conveyed by outer protocol headers (e.g., the IP or UDP header), enables receivers to detect the absence of the ALC payload and FEC Payload ID.
特別な場合には、ALC送信者がペイロードを含まないALCパケットを生成する必要がある場合があります。これは、たとえば、セッションの終了を通知するか、混雑制御情報を伝えるために必要になる場合があります。これらのデータレスパケットには、FECペイロードIDも含まれていませんが、LCTヘッダーフィールドのみが含まれています。外側のプロトコルヘッダー（例：IPまたはUDPヘッダー）によって伝達される総データグラムの長さにより、受信機はALCペイロードとFECペイロードIDがないことを検出できます。
For ALC, the length of the TSI field within the LCT header is REQUIRED to be non-zero. This implies that the sender MUST NOT set both the LCT flags S and H to zero.
ALCの場合、LCTヘッダー内のTSIフィールドの長さはゼロ以外である必要があります。これは、送信者がLCTフラグとHの両方をゼロに設定してはならないことを意味します。
This specification defines a new LCT Header Extension, "EXT_FTI", for the purpose of communicating the FEC Object Transmission Information in association with data packets of an object. The LCT Header Extension Type for EXT_FTI is 64.
この仕様は、オブジェクトのデータパケットと関連してFECオブジェクト伝送情報を通信する目的で、新しいLCTヘッダー拡張機能「Ext_fti」を定義します。ext_ftiのLCTヘッダー拡張タイプは64です。
The Header Extension Content (HEC) field of the EXT_FTI LCT Header Extension contains the encoded FEC Object Transmission Information as defined in [RFC5052]. The format of the encoded FEC Object Transmission Information is dependent on the FEC Scheme in use and so is outside the scope of this document.
ext_fti LCTヘッダー拡張のヘッダー拡張コンテンツ（HEC）フィールドには、[RFC5052]で定義されているエンコードされたFECオブジェクト伝送情報が含まれています。エンコードされたFECオブジェクト伝送情報の形式は、使用中のFECスキームに依存しているため、このドキュメントの範囲外です。
The sender operation, when using ALC, includes all the points made about the sender operation when using the LCT building block [RFC5651], the FEC building block [RFC5052], and the multiple rate congestion control building block.
Sender操作は、ALCを使用する場合、LCTビルディングブロック[RFC5651]、FECビルディングブロック[RFC5052]、および複数レートの混雑制御ビルディングブロックを使用する際に、送信者操作に関するすべてのポイントが含まれます。
A sender using ALC should make available the required Session Description as described in Section 2.4. A sender should also make available the required FEC Object Transmission Information as described in Section 2.3.
ALCを使用する送信者は、セクション2.4で説明されているように、必要なセッションの説明を利用できるようにする必要があります。送信者は、セクション2.3で説明されているように、必要なFECオブジェクト伝送情報も利用できるようにする必要があります。
Within a session, a sender transmits a sequence of packets to the channels associated with the session. The ALC sender MUST obey the rules for filling in the CCI field in the packet headers, and it MUST send packets at the appropriate rates to the channels associated with the session as dictated by the multiple rate congestion control building block.
セッション内で、送信者はセッションに関連付けられたチャネルに一連のパケットを送信します。ALC送信者は、パケットヘッダーのCCIフィールドに記入するためのルールに従う必要があり、複数レートの輻輳制御ビルディングブロックによって指示されているように、セッションに関連付けられたチャネルに適切なレートでパケットを送信する必要があります。
The ALC sender MUST use the same TSI for all packets in the session. Several objects MAY be delivered within the same ALC session. If more than one object is to be delivered within a session, then the sender MUST use the TOI field. Each object MUST be identified by a unique TOI within the session, and the sender MUST use corresponding TOI for all packets pertaining to the same object. The FEC Payload ID MUST correspond to the encoding symbol(s) for the object carried in the payload of the packet.
ALC送信者は、セッション内のすべてのパケットに同じTSIを使用する必要があります。同じALCセッション内でいくつかのオブジェクトが配信される場合があります。セッション内で複数のオブジェクトを配信する場合、送信者はTOIフィールドを使用する必要があります。各オブジェクトはセッション内の一意のTOIによって識別される必要があり、送信者は同じオブジェクトに関連するすべてのパケットに対応するTOIを使用する必要があります。FECペイロードIDは、パケットのペイロードに掲載されたオブジェクトのエンコードシンボルに対応する必要があります。
It is RECOMMENDED that packet authentication be used. If packet authentication is used, then the Header Extensions described in Section 4.2 MAY be used to carry the authentication.
パケット認証を使用することをお勧めします。パケット認証が使用される場合、セクション4.2で説明されているヘッダー拡張機能を使用して認証を運ぶことができます。
The receiver operation, when using ALC, includes all the points made about the receiver operation when using the LCT building block [RFC5651], the FEC building block [RFC5052], and the multiple rate congestion control building block.
受信機の操作には、ALCを使用する場合、LCTビルディングブロック[RFC5651]、FECビルディングブロック[RFC5052]、および複数レートのうっ血制御ビルディングブロックを使用する際に、受信機操作に関するすべてのポイントが含まれます。
To be able to participate in a session, a receiver needs to obtain the required Session Description as listed in Section 2.4. How receivers obtain a Session Description is outside the scope of this document.
セッションに参加できるようにするには、セクション2.4にリストされているように、必要なセッションの説明を取得する必要があります。受信者がセッションの説明を取得する方法は、このドキュメントの範囲外です。
As described in Section 2.3, a receiver needs to obtain the required FEC Object Transmission Information for each object for which the receiver receives and processes packets.
セクション2.3で説明したように、受信者は、受信者がパケットを受信および処理する各オブジェクトに対して必要なFECオブジェクト伝送情報を取得する必要があります。
Upon receipt of each packet, the receiver proceeds with the following steps in the order listed.
各パケットを受け取ると、レシーバーは、リストされた順序で次の手順を進めます。
1. The receiver MUST parse the packet header and verify that it is a valid header. If it is not valid, then the packet MUST be discarded without further processing.
1. 受信機は、パケットヘッダーを解析し、有効なヘッダーであることを確認する必要があります。有効でない場合は、パケットをさらに処理せずに破棄する必要があります。
2. The receiver MUST verify that the sender IP address together with the TSI carried in the header matches one of the (sender IP address, TSI) pairs that was received in a Session Description and to which the receiver is currently joined. If there is not a match, then the packet MUST be silently discarded without further processing. The remaining steps are performed within the scope of the (sender IP address, TSI) session of the received packet.
2. 受信者は、セッションの説明で受信され、レシーバーが現在結合されている（送信者IPアドレス、TSI）ペアの1つであるヘッダーマッチで送信されるTSIと一緒に送信者IPアドレスが一緒になっていることを確認する必要があります。一致がない場合は、パケットをさらに処理せずに静かに破棄する必要があります。残りの手順は、受信したパケットの（送信者IPアドレス、TSI）セッションの範囲内で実行されます。
3. The receiver MUST process and act on the CCI field in accordance with the multiple rate congestion control building block.
3. 受信者は、複数レートの輻輳制御ビルディングブロックに従って、CCIフィールドに処理および行動する必要があります。
4. If more than one object is carried in the session, the receiver MUST verify that the TOI carried in the LCT header is valid. If the TOI is not valid, the packet MUST be discarded without further processing.
4. セッションで複数のオブジェクトが運ばれている場合、受信者はLCTヘッダーに携帯されているTOIが有効であることを確認する必要があります。TOIが有効でない場合、パケットをさらに処理することなく破棄する必要があります。
5. The receiver SHOULD process the remainder of the packet, including interpreting the other header fields appropriately, and using the FEC Payload ID and the encoding symbol(s) in the payload to reconstruct the corresponding object.
5. レシーバーは、他のヘッダーフィールドの適切な解釈や、対応するオブジェクトを再構築するためにペイロード内のFECペイロードIDとエンコードシンボルを使用するなど、パケットの残りを処理する必要があります。
It is RECOMMENDED that packet authentication be used. If packet authentication is used, then it is RECOMMENDED that the receiver immediately check the authenticity of a packet before proceeding with step (3) above. If immediate checking is possible and if the packet fails the check, then the receiver MUST silently discard the packet.
パケット認証を使用することをお勧めします。パケット認証を使用する場合は、上記のステップ（3）を進める前に、受信者がパケットの信ity性を直ちに確認することをお勧めします。即時チェックが可能で、パケットがチェックに失敗した場合、受信者はパケットを静かに破棄する必要があります。
The same security considerations that apply to the LCT, FEC, and the multiple rate congestion control building blocks also apply to ALC.
LCT、FEC、および複数レートの混雑制御ビルドブロックに適用される同じセキュリティ上の考慮事項もALCに適用されます。
ALC is especially vulnerable to denial-of-service attacks by attackers that try to send forged packets to the session, which would prevent successful reconstruction or cause inaccurate reconstruction of large portions of the object by receivers. ALC is also particularly affected by such an attack because many receivers may receive the same forged packet. There are two ways to protect against such attacks, one at the application level and one at the packet level. It is RECOMMENDED that prevention be provided at both levels.
ALCは、セッションに偽造パケットを送信しようとする攻撃者によるサービス拒否攻撃に対して特に脆弱です。ALCは、多くのレシーバーが同じ鍛造パケットを受け取る可能性があるため、このような攻撃の影響を特に受けます。このような攻撃から保護する方法は2つあります。1つはアプリケーションレベルで、もう1つはパケットレベルにあります。両方のレベルで予防を提供することをお勧めします。
At the application level, it is RECOMMENDED that an integrity check on the entire received object be done once the object is reconstructed to ensure it is the same as the sent object. Moreover, in order to obtain strong cryptographic integrity protection, a digital signature verifiable by the receiver SHOULD be used to provide this application-level integrity check. However, if even one corrupted or forged packet is used to reconstruct the object, it is likely that the received object will be reconstructed incorrectly. This will appropriately cause the integrity check to fail and in this case, the inaccurately reconstructed object SHOULD be discarded. Thus, the acceptance of a single forged packet can be an effective denial-of-service attack for distributing objects, but an object integrity check at least prevents inadvertent use of inaccurately reconstructed objects. The specification of an application-level integrity check of the received object is outside the scope of this document.
アプリケーションレベルでは、受信オブジェクト全体の整合性チェックを行うことをお勧めします。さらに、強力な暗号整合性保護を取得するには、受信機が検証可能なデジタル署名を使用して、このアプリケーションレベルの整合性チェックを提供する必要があります。ただし、オブジェクトを再構築するために破損したパケットまたは鍛造パケットが1つでも使用されている場合、受信オブジェクトが誤って再構築される可能性があります。これにより、整合性チェックが適切に失敗し、この場合、不正確に再構築されたオブジェクトを破棄する必要があります。したがって、単一の鍛造パケットの受け入れは、オブジェクトを配布するための効果的なサービス拒否攻撃になる可能性がありますが、オブジェクトの整合性チェックは、少なくとも不正確に再構築されたオブジェクトの不注意な使用を防ぎます。受信オブジェクトのアプリケーションレベルの整合性チェックの仕様は、このドキュメントの範囲外です。
At the packet level, it is RECOMMENDED that a packet-level authentication be used to ensure that each received packet is an authentic and uncorrupted packet containing data for the object arriving from the specified sender. Packet-level authentication has the advantage that corrupt or forged packets can be discarded individually and the received authenticated packets can be used to accurately reconstruct the object. Thus, the effect of a denial-of-service attack that injects forged packets is proportional only to the number of forged packets, and not to the object size. [RMT-SIMPLE]and [RFC5776] described packet level authentication schemes that can be used with the ALC protocol.
パケットレベルでは、パケットレベルの認証を使用して、受信した各パケットが、指定された送信者から到着するオブジェクトのデータを含む本物で腐敗していないパケットであることを確認することをお勧めします。パケットレベルの認証には、破損したパケットまたは偽造パケットを個別に破棄できるという利点があり、受信した認証されたパケットを使用してオブジェクトを正確に再構築できることがあります。したがって、鍛造パケットを注入するサービス拒否攻撃の効果は、オブジェクトサイズではなく、偽造パケットの数にのみ比例します。[RMT-Simple]および[RFC5776]は、ALCプロトコルで使用できるパケットレベル認証スキームを説明しました。
In addition to providing protection against reconstruction of inaccurate objects, packet-level authentication can also provide some protection against denial-of-service attacks on the multiple rate congestion control. Attackers can try to inject forged packets with incorrect congestion control information into the multicast stream, thereby potentially adversely affecting network elements and receivers downstream of the attack, and much less significantly the rest of the network and other receivers. Thus, it is also RECOMMENDED that packet-level authentication be used to protect against such attacks. Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC5776] can also be used to some extent to limit the damage caused by such attacks. However, with TESLA, a receiver can only determine if a packet is authentic several seconds after it is received, and thus an attack against the congestion control protocol can be effective for several seconds before the receiver can react to slow down the session reception rate.
不正確なオブジェクトの再構築に対する保護を提供することに加えて、パケットレベルの認証は、複数のレートの混雑制御に対するサービス拒否攻撃に対するある程度の保護も提供できます。攻撃者は、誤った輻輳制御情報を備えた鍛造パケットをマルチキャストストリームに注入しようとすることができます。これにより、攻撃の下流のネットワーク要素やレシーバーに潜在的に悪影響を及ぼし、ネットワークやその他のレシーバーの残りの部分にはそれほど有意ではありません。したがって、パケットレベルの認証を使用して、そのような攻撃から保護することもお勧めします。タイミングの効率的なストリーム損失耐性認証（TESLA）[RFC5776]は、そのような攻撃によって引き起こされる損傷を制限するためにある程度使用することもできます。ただし、テスラを使用すると、受信者はパケットが受信してから数秒後に本物であるかどうかを判断することができるため、渋滞制御プロトコルに対する攻撃は、受信機が反応してセッション受信率を遅くすることができる前に数秒間有効になります。
Some packet authentication schemes such as TESLA [RFC5776] do not allow an immediate authenticity check. In this case, the receiver SHOULD check the authenticity of a packet as soon as possible, and if the packet fails the check, then it MUST be silently discarded before Step 5 above. It is RECOMMENDED that if receivers detect many packets that fail authentication checks within a session, the above procedure should be modified for this session so that Step 3 is delayed until after the authentication check and only performed if the check succeeds.
Tesla [RFC5776]などの一部のパケット認証スキームは、即時の信頼性チェックを許可していません。この場合、受信者はできるだけ早くパケットの信ity性をチェックする必要があり、パケットがチェックに障害が発生した場合は、上記のステップ5の前に静かに破棄する必要があります。受信機がセッション内で認証チェックを失敗させる多くのパケットを検出する場合、上記の手順をこのセッションのために変更する必要があるため、認証チェックの後にステップ3が遅延し、チェックが成功した場合にのみ実行することをお勧めします。
Reverse Path Forwarding checks SHOULD be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent injecting forged packets into the multicast tree data path.
リバースパス転送チェックは、すべてのネットワークルーターと送信者からレシーバーへのパスに沿って切り替えて有効にする必要があります。
This section describes a baseline mode of secure ALC protocol operation based on application of the IPsec security protocol. This approach is documented here to provide a reference of an interoperable secure mode of operation. However, additional approaches to ALC security, including other forms of IPsec application, MAY be specified in the future. For example, the use of the EXT_AUTH Header Extension could enable ALC-specific authentication or security encapsulation headers similar to those of IPsec to be specified and inserted into the ALC/LCT protocol message headers. This would allow header compression techniques to be applied to IP and ALC protocol headers when needed in a similar fashion to that of RTP [RFC3550] and as preserved in the specification for Secure Real Time Protocol (SRTP) [RFC3711].
このセクションでは、IPSECセキュリティプロトコルの適用に基づいた安全なALCプロトコル操作のベースラインモードについて説明します。このアプローチは、相互運用可能な安全な動作モードの参照を提供するためにここに文書化されています。ただし、IPSECアプリケーションの他の形式を含むALCセキュリティへの追加のアプローチは、将来的に指定される場合があります。たとえば、Ext_Authヘッダー拡張機能を使用すると、ALC固有の認証またはセキュリティカプセル化ヘッダーが、IPSECのものと同様のALC/LCTプロトコルメッセージヘッダーに挿入されるヘッダーを可能にします。これにより、ヘッダー圧縮技術は、必要に応じて、必要に応じてRTP [RFC3550]と同様の方法で、および安全なリアルタイムプロトコル（SRTP）[RFC3711]の仕様に保存されている場合に、IPおよびALCプロトコルヘッダーに適用できます。
The baseline approach described is applicable to ALC operation configured for SSM (or SSM-like) operation where there is a single sender. The receiver set would maintain a single IPsec Security Association (SA) for each ALC sender.
説明されているベースラインアプローチは、単一の送信者がいるSSM（またはSSMのような）操作用に構成されたALC操作に適用されます。レシーバーセットは、各ALCセンダーに対して単一のIPSECセキュリティアソシエーション（SA）を維持します。
To support this baseline form of secure ALC one-to-many SSM operation, each node SHALL be configured with a transport mode IPsec Security Association and corresponding Security Policy Database (SPD) entry. This entry will be used for sender-to-group multicast packet authentication and optionally encryption.
安全なALCの1対多くのSSM操作のこのベースライン形式をサポートするために、各ノードは、トランスポートモードIPSECセキュリティアソシエーションと対応するセキュリティポリシーデータベース（SPD）エントリで構成されなければなりません。このエントリは、Sender-to-Groupマルチキャストパケット認証とオプションで暗号化に使用されます。
The ALC sender SHALL use an IPsec SA configured for Encapsulating Security Payload (ESP) protocol [RFC4303] operation with the option for data origination authentication enabled. It is also RECOMMENDED that this IPsec ESP SA be also configured to provide confidentiality protection for IP packets containing ALC protocol messages. This is suggested to make the realization of complex replay attacks much more difficult. The encryption key for this SA SHALL be preplaced at the sender and receiver(s) prior to ALC protocol operation. Use of automated key management is RECOMMENDED as a rekey SHALL be required prior to expiration of the sequence space for the SA. This is necessary so that receivers may use the built-in IPsec replay attack protection possible for an IPsec SA with a single source (the ALC sender). Thus, the receivers SHALL enable replay attack protection for this SA used to secure ALC sender traffic. The sender IPsec SPD entry MUST be configured to process outbound packets to the destination address and UDP port number of the applicable ALC session.
ALC送信者は、Data Origination Authentication Enabledのオプションを使用して、セキュリティペイロード（ESP）プロトコル[RFC4303]操作をカプセル化するために構成されたIPSEC SAを使用するものとします。また、ALCプロトコルメッセージを含むIPパケットの機密保護を提供するようにこのIPSEC ESP SAを構成することもお勧めします。これは、複雑なリプレイ攻撃の実現をはるかに困難にするために提案されています。このSAの暗号化キーは、ALCプロトコル操作の前に送信者と受信機で事前に科せられなければなりません。SAのシーケンススペースの有効期限が切れる前に、Rekeyが必要であるため、自動化されたキー管理の使用が推奨されます。これは、レシーバーが単一のソース（ALC送信者）を備えたIPSEC SAに可能な内蔵IPSECリプレイ攻撃保護を使用できるようにする必要があります。したがって、受信機は、ALC送信者トラフィックを確保するために使用されるこのSAのリプレイ攻撃保護を有効にする必要があります。Sender IPSEC SPDエントリは、該当するALCセッションの宛先アドレスとUDPポート番号へのアウトバウンドパケットを処理するように構成する必要があります。
The ALC receiver(s) MUST be configured with the SA and SPD entry to properly process the IPsec-secured packets from the sender. Note that use of ESP confidentiality, as RECOMMENDED, for secure ALC protocol operation makes it more difficult for adversaries to conduct effective replay attacks that may mislead receivers on content reception. This baseline approach can be used for ALC protocol sessions with multiple senders if a distinct SA is established for each sender.
ALCレシーバーは、SAおよびSPDエントリで構成して、送信者からIPSECで固定されたパケットを適切に処理する必要があります。安全なALCプロトコル操作のために、推奨されるようにESPの機密性を使用すると、敵がコンテンツレセプションで受信者を誤解させる可能性のある効果的なリプレイ攻撃を実施することがより困難であることに注意してください。このベースラインアプローチは、各送信者に対して異なるSAが確立されている場合、複数の送信者とのALCプロトコルセッションに使用できます。
In early deployments of this baseline approach to ALC security, it is anticipated that key management will be conducted out-of-band with respect to ALC protocol operation. For ALC unidirectional operation, it is possible that receivers may retrieve keying information from a central server via out-of-band (with respect to ALC) communication as needed or otherwise conduct group key updates with a similar centralized approach. However, it may be possible with some key management schemes for rekey messages to be transmitted to the group as a message or transport object within the ALC reliable transfer session. An additional specification is necessary to define an in-band key management scheme for ALC sessions perhaps using the mechanisms of the automated group key management specifications cited in this document.
ALCセキュリティに対するこのベースラインアプローチの早期展開では、ALCプロトコル操作に関して主要な管理が帯域外に行われることが予想されます。ALC単方方向の動作の場合、必要に応じて（ALCの）通信を介して中央サーバーからキーイング情報を取得するか、同様の集中アプローチでグループキーアップデートを実施することができます。ただし、ALC信頼できる転送セッション内のメッセージまたはトランスポートオブジェクトとして、Rekeyメッセージをグループに送信するためのいくつかの主要な管理スキームでは可能性があります。おそらく、このドキュメントで引用されている自動グループのキー管理仕様のメカニズムを使用して、ALCセッションのバンド内キー管理スキームを定義するには、追加の仕様が必要です。
In order to implement this secure mode of ALC protocol operation, the following IPsec capabilities are required.
ALCプロトコル操作のこの安全なモードを実装するには、次のIPSEC機能が必要です。
The implementation MUST be able to use the source address, destination address, protocol (UDP), and UDP port numbers as selectors in the SPD.
実装は、SPDのセレクターとして、ソースアドレス、宛先アドレス、プロトコル（UDP）、およびUDPポート番号を使用できる必要があります。
IPsec in transport mode MUST be supported. The use of IPsec [RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED such that unauthenticated packets are not received by the ALC protocol implementation.
輸送モードのIPSECをサポートする必要があります。ALCプロトコルの実装によって未認定のパケットが受信されないように、安全なALCトラフィックにIPSEC [RFC4301]処理の使用も必要です。
An automated key management scheme for group key distribution and rekeying such as the Group Domain of Interpretation (GDOI) [RFC3547], Group Secure Association Key Management Protocol (GSAKMP) [RFC4535], or Multimedia Internet KEYing (MIKEY) [RFC3830] SHOULD be used. Relatively short-lived ALC sessions MAY be able to use Manual Keying with a single, preplaced key, particularly if Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec implementation used. It should also be noted that it may be possible for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be included in the ALC application reliable data transmission as transport objects if appropriate interfaces were available between the ALC application and the key management daemon.
グループキーの分布とグループの解釈のドメイン（GDOI）[RFC3547]、グループセキュアーアソシエーションキー管理プロトコル（GSAKMP）[RFC4535]、またはマルチメディアインターネットキーイング（Mikey）[RFC3830]などの自動化されたキー管理スキームの自動化されたキー管理スキーム。使用済み。比較的短命のALCセッションでは、特に拡張シーケンス番号（ESN）[RFC4303]が使用されているIPSEC実装で利用可能な場合、単一の事前に前状のキーを使用して手動キーイングを使用できる場合があります。また、ALCアプリケーションとキー管理の間で適切なインターフェイスが利用可能な場合、キーアップデートメッセージ（GDOI GroupKey-Pushメッセージなど）をALCアプリケーションに信頼できるデータ送信として信頼できるデータ送信に含めることが可能であることに注意する必要があります。デーモン。
Receivers SHOULD accept connections only from the designated, authorized sender(s). It is expected that appropriate key management will provide encryption keys only to receivers authorized to participate in a designated session. The approach outlined here allows receiver sets to be controlled on a per-sender basis.
受信者は、指定された認定送信者からのみ接続を受け入れる必要があります。適切なキー管理は、指定されたセッションに参加することを許可されたレシーバーにのみ暗号化キーを提供することが期待されています。ここで概説されているアプローチにより、受信機セットをセンダーごとに制御できます。
Large ALC group sizes may necessitate some form of key management that does rely upon shared secrets. The GDOI and GSAKMP protocols mentioned here allow for certificate-based authentication. These certificates SHOULD use IP addresses for authentication. However, it is likely that available group key management implementations will not be ALC-specific.
大規模なALCグループサイズは、共有された秘密に依存する何らかの形の主要な管理を必要とする場合があります。ここで説明したGDOIおよびGSAKMPプロトコルは、証明書ベースの認証を可能にします。これらの証明書は、認証にIPアドレスを使用する必要があります。ただし、利用可能なグループキー管理の実装はALC固有のものではない可能性があります。
The IPsec requirements profile outlined here is commonly available on many potential ALC hosts. The principal issue is that configuration and operation of IPsec typically requires privileged user authorization. Automated key management implementations are typically configured with the privileges necessary to allow the needed system IPsec configuration.
ここで概説するIPSEC要件プロファイルは、多くの潜在的なALCホストで一般的に利用可能です。主要な問題は、IPSECの構成と操作には通常、特権ユーザー許可が必要であることです。通常、自動化された主要な管理実装は、必要なシステムIPSEC構成を許可するために必要な特権で構成されます。
This specification registers one value in the LCT Header Extensions Types namespace as follows:
この仕様は、LCTヘッダー拡張機能の1つの値を次のように登録します。
+-------+---------+--------------------+
| Value | Name | Reference |
+-------+---------+--------------------+
| 64 | EXT_FTI | This specification |
+-------+---------+--------------------+
This specification is substantially based on RFC 3450 [RFC3450] and thus credit for the authorship of this document is primarily due to the authors of RFC 3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano, Luigi Rizzo, and Jon Crowcroft. Vincent Roca, Justin Chapweske, and Roger Kermode also contributed to RFC 3450. Additional thanks are due to Vincent Roca and Rod Walsh for contributions to this update to Proposed Standard.
この仕様は実質的にRFC 3450 [RFC3450]に基づいているため、この文書の著者の功績は主にRFC 3450の著者によるものです。Vincent Roca、Justin Chapweske、およびRoger KermodeもRFC 3450に貢献しました。追加の感謝は、標準の提案へのこの更新への貢献について、Vincent RocaとRod Walshによるものです。
This section summarizes the changes that were made from the "Experimental" version of this specification published as RFC 3450 [RFC3450]:
このセクションでは、RFC 3450 [RFC3450]として公開されたこの仕様の「実験」バージョンから作成された変更を要約します。
o Updated all references to the obsoleted RFC 2068 to RFC 2616.
o 廃止されたRFC 2068へのすべての参照をRFC 2616に更新しました。
o Removed the 'Statement of Intent' from the introduction. (The Statement of Intent was meant to clarify the "Experimental" status of RFC 3450.)
o はじめに「意図の声明」を削除しました。（意図の声明は、RFC 3450の「実験的」ステータスを明確にすることを目的としていました。）
o Removed the 'Intellectual Property Issues' Section and replaced with a standard IPR Statement.
o 「知的財産の問題」セクションを削除し、標準のIPRステートメントに置き換えました。
o Removed material duplicated in LCT.
o LCTで複製された材料を除去しました。
o Updated references in this document to new versions of the LCT Building Block and the FEC Building Block, and aligned this document with changes in the new version of the FEC Building Block.
o このドキュメントの参照を更新したLCTビルディングブロックとFECビルディングブロックの新しいバージョンに、このドキュメントをFECビルディングブロックの新しいバージョンの変更に合わせました。
o Split normative and informative references.
o 規範的および有益な参照を分割します。
o Material applicable in a general LCT context, not just for ALC has been moved to LCT.
o ALCだけでなく、一般的なLCTコンテキストで適用可能な材料がLCTに移動しました。
o The first bit of the "Protocol-Specific Indication" in the LCT Header is defined as a "Source Packet Indication". This is used in the case that an FEC Scheme defines two FEC Payload ID formats, one of which is for packets containing only source symbols that can be processed by receivers that do not support FEC Decoding.
o LCTヘッダーの「プロトコル固有の表示」の最初のビットは、「ソースパケット表示」として定義されます。これは、FECスキームが2つのFECペイロードID形式を定義する場合に使用されます。その1つは、FECデコードをサポートしないレシーバーで処理できるソースシンボルのみを含むパケット用です。
o Definition and IANA registration of the EXT_FTI LCT Header Extension.
o ext_fti lctヘッダー拡張機能の定義とIANA登録。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738] Luby、M。およびV. Goyal、「波と方程式ベースのレート制御（WEBRC）ビルディングブロック」、RFC 3738、2004年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[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月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052] Watson、M.、Luby、M.、およびL. Vicisano、「フォワードエラー補正（FEC）ビルディングブロック」、RFC 5052、2007年8月。
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5651] Luby、M.、Watson、M。、およびL. Vicisano、「レイヤードコーディング輸送（LCT）ビルディングブロック」、RFC 5651、2009年10月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357] Mankin、A.、Romanov、A.、Bradner、S。、およびV. Paxson、「信頼できるマルチキャスト輸送およびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048] Whetten、B.、Vicisano、L.、Kermode、R.、Handley、M.、Floyd、S。、およびM. Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269] Kermode、R。およびL. Vicisano、「信頼できるマルチキャスト輸送（RMT）ビルディングブロックとプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、2002年4月。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[RFC3450] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L。、およびJ. Crowcroft、「非同期層コーディング（ALC）プロトコルインスタンス化」、RFC 3450、2002年12月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、2002年12月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、RFC 3547、2003年7月。
[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月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569] Bhattacharyya、S。、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、2003年7月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B。およびD. Meyer、「マルチキャストソースディスカバリープロトコル（MSDP）」、RFC 3618、2003年10月。
[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月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、RFC 3830、2004年8月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、「GSAKMP：Group Secure Association Key Management Protocol」、RFC 4535、2006年6月。
[RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 5776, April 2010.
[RFC5776] Roca、V.、Francillon、A。、およびS. Faurite、「非同期層コーディング（ALC）およびNACK指向の信頼できるマルチキャスト（NORM）プロトコルにおけるタイミングの効率的なストリーム損失耐性認証（TESLA）の使用」、RFC 5776、2010年4月。
[RMT-SIMPLE] Roca, V., "Simple Authentication Schemes for the ALC and NORM Protocols", Work in Progress, October 2009.
[RMT-Simple] Roca、V。、「ALCおよびNORMプロトコルの単純な認証スキーム」、2009年10月、進行中の作業。
Authors' Addresses
著者のアドレス
Michael Luby Qualcomm, Inc. 3165 Kifer Road Santa Clara, CA 95051 US
Michael Luby Qualcomm、Inc。3165 Kifer Road Santa Clara、CA 95051 US
EMail: luby@qualcomm.com
Mark Watson Qualcomm, Inc. 3165 Kifer Road Santa Clara, CA 95051 US
Mark Watson Qualcomm、Inc。3165 Kifer Road Santa Clara、CA 95051 US
EMail: watson@qualcomm.com
Lorenzo Vicisano Qualcomm, Inc. 3165 Kifer Road Santa Clara, CA 95051 US
Lorenzo Vicisano Qualcomm、Inc。3165 Kifer Road Santa Clara、CA 95051 US
EMail: vicisano@qualcomm.com