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
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）ビルディングブロックを合成します送信者。この文書は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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、[RFC2119]に記載されているように解釈されます。
ALC can support several different reliable content delivery service models as described in [RFC5651].
[RFC5651]で説明したようにALCは、いくつかの異なる信頼性の高いコンテンツ配信サービスモデルをサポートすることができます。
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、負荷または発信率に差は、受信機が参加して離れるときの独立存在しません。
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）の使用とは、Multicast Source Discovery Protocol（MSDP）に大きくなる可能性が[RFC3618]プロトコルは、パケットをRP及び（S、G）送信者に直接参加する参加（*、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.
それはLCTのためであるとして、ALCのためのセッションの定義は同じです。 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.
[RFC3048]で定義されるようにALCプロトコルのインスタンスです。このドキュメントは[RFC5651]で説明LCTのバージョン1を使用しなければならないALCのバージョン1を、記載されています。 LCTのように、ALCは、IPマルチキャストネットワークサービスで使用するように設計されています。この仕様は、パケットのIPマルチキャスト配信をサポートUDPトランスポートプロトコル[RFC0768]のペイロードとしてALCを定義します。
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ヘッダの後に続き、[RFC5052]に記載されているFECペイロードID続いて[RFC5651]に記載されているデフォルトのLCTヘッダから成ります。 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）フィールドを含みます。そこCCIフィールドの長さを指定するLCTヘッダ内のフィールドであり、複数のレート混雑制御ビルディング・ブロックは一意にこの長さに対応する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
LCTヘッダは、受信機へのセッションの間に変化することができる情報の設定を通信するために使用されるかもしれコードポイントフィールドを含みます。使用した場合、設定とコードポイント値との間のマッピングは、セッション記述に通信され、このマッピングは、この文書の範囲外です。例えばFECオブジェクト伝送の一部である、FEC符号化ID
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.
情報は、FECビルディングブロック[RFC5052]で指定されるように、セッション内で運ばれる各オブジェクトに対して変化でき、コードポイント値は、各オブジェクトのために使用されるFEC符号化IDを通信するために使用することができます。 FEC符号化IDとコードポイントとの間のマッピングは、例えば、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.
複数のオブジェクトがセッション内で実施される場合、送信対象識別子（TOI）は、どのオブジェクトに関連付けされるべきパケットを識別するために、LCTヘッダで使用されなければなりません。この場合、受信機は、オブジェクトに受信したパケットを関連付けるためにTOIを使用しなければなりません。 TOIが送信者とTSIのIPアドレスによってスコープされる、すなわち、TOIは、セッションによってスコープされます。各オブジェクトのTOIは、セッション内で一意であることが要求されますが、セッション間で一意である必要はありません。さらに、同じオブジェクトが異なるセッションで異なるTOIを持っているかもしれません。セッションで運ばTOISとオブジェクトとの間のマッピングは、この文書の範囲外です。
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ヘッダのビット6及びLCTヘッダの最初のワードの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ビット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
ソースパケットインジケータがリペアデータを含むパケットのFECペイロードIDフォーマットと比較して唯一のソースデータを含むパケットの異なるFECペイロードIDフォーマットを定義システマティックFECスキームで使用されます。そのようなFECスキームのために、SPIは、1に設定しなければならない場合にのみ、ソースデータを含むパケットのFECペイロードIDフォーマットが使用され、修復データを含むパケットのFECペイロードIDを使用する場合SPIをゼロに設定しなければなりません。 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フォーマットを定義する方式は、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つに対応しなければなりません。この長さは、セッションに送信されるすべてのパケット、及びLCTヘッダ内のCCIフィールドのために使用される形式でなければなりません複数のレート混雑制御ビルディングブロックで指定されている長さに対応する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ビルディングに記載されているようにパケットのペイロードで運ばれた符号化シンボルは、オブジェクトから生成されたかを決定するためにFECペイロードIDを使用しなければなりませんブロック。
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.
FEC符号化ID、O。
o If an Under-Specified FEC Encoding ID is used, then the FEC Instance ID associated with the FEC Encoding ID.
アンダー指定FEC符号化IDが使用される場合、O、次いで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符号化IDによって識別される）が使用されるFECスキームに応じて必要とされ得ます。
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オブジェクト伝送情報を動的にまたはオブジェクトのための時間パケットがセッションから受信される前に、受信機に伝達することができます。これは、コードポイントフィールド又はヘッダ拡張、またはこれらの方法の任意の組み合わせを使用して、インバンド、アウトオブバンドメカニズムを用いて達成することができます。 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;
送信元のIPアドレスO;
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部分内のコードポイントフィールドは、インバンドセッション内の動的に変化する情報の一部を通信するために使用することができます。これを行うために、コードポイント値と異なる動的設定との間のマッピングは、セッション記述内に含まれなければならないし、次に使用する設定は、各パケットに入れコードポイント値を介して通信されます。例えば、複数のオブジェクトが同じセッション内で異なるFEC符号化アルゴリズムは、異なるタイプのオブジェクトのために使用されることが配信されることが可能です。そして、セッション記述は、コードポイント値とFEC符号化IDの間のマッピングを含めることができます。別の例として、異なるパケット認証方式がセッションに送信された異なるパケットに使用されることが可能です。この場合、パケットの認証方式とコードポイント値との間のマッピングは、セッション記述に提供することができます。設定の組み合わせは、同様にコードポイント値にマッピングすることができます。例えば、FEC符号化IDおよびパケットの認証方式の特定の組合せは、コードポイント値に関連することができます。
The Session Description could also include, but is not limited to:
セッション記述も含めることができるが、これらに限定されません。
o The mappings between combinations of settings and Codepoint values;
設定およびコードポイント値の組み合わせの間のマッピングO。
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.
[RFC3023]で定義された、またはHTTP / MIMEヘッダとして、[RFC2616]で定義されるように、セッション記述は、[RFC4566]で定義されるようにセッション記述プロトコル（SDP）、XMLメタデータとしての形態であってもよい等はあるかもしれません[RFC2974]で定義されるようにSAPなどのセッションアナウンスメントプロトコルで運ばれ、スケジューリング情報をウェブページ上に位置する独自のセッション制御プロトコルを用いて得られた、または電子メールまたはその他のアウトオブバンド方法を経て搬送されます。受信機へのセッション記述の通信のためのセッション記述形式や方法についての議論は、この文書の範囲を超えています。
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].
ALCの実装者は攻撃からプロトコルを保護するために、いくつかのパケットの認証方式を使用することをお勧めします。適切なスキームは[RFC5776]と[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によって使用されるパケットフォーマットは、パケットのペイロードが続くFECペイロードID続いLCTヘッダに続くUDPヘッダです。 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のバージョン番号は、LCTヘッダのバージョン番号フィールドはALCバージョン番号フィールドとして解釈されなければならない1です。 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パケットフォーマットは、IPv4またはIPv6のいずれかで、パケットがIPパケットである図3に示され、および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フラグSと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.
[RFC5052]で定義されるようEXT_FTI LCTヘッダ拡張ヘッダ拡張コンテンツ（HEC）フィールドは、符号化された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.
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.
2.4節で説明したようにALCを使用して、送信者は、必要なセッション記述利用できるようにする必要があります。 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.受信機は、ヘッダで運ばTSIと共に、送信元IPアドレスは、セッション記述で受信し、受信機が現在結合されているために（送信元IPアドレス、TSI）ペアの一つと一致することを確認しなければなりません。一致がない場合、パケットは、黙って、更なる処理なしに捨てなければなりません。残りのステップは、受信したパケットの（送信元IPアドレス、TSI）セッションの範囲内で行われます。
3. The receiver MUST process and act on the CCI field in accordance with the multiple rate congestion control building block.
前記受信機は、複数のレート混雑制御ビルディングブロックに従って処理し、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.
前記受信機は、適切に他のヘッダフィールドを解釈し、対応するオブジェクトを再構成するためにペイロードに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）に進む前に、パケットの信憑性を確認することをお勧めされています。即時のチェックが可能であり、パケットはチェックを失敗した場合、受信機は静かにパケットを捨てなければなりません場合。
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は、特に、このような攻撃の影響を受けています。このような攻撃、アプリケーションレベルで1パケットレベルでの1から保護するには、2つの方法があります。予防の両方のレベルで提供されることが推奨されます。
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.
アプリケーションレベルでは、オブジェクトが、それが送信されたオブジェクトと同じであることを確認するために再構築されると、全体の受信されたオブジェクト上の整合性チェックが行われることが推奨されます。また、強力な暗号化、完全性保護を得るために、受信機によって検証デジタル署名は、このアプリケーション・レベルの整合性チェックを提供するために使用されるべきです。一つでも壊れているか、または偽造パケットがオブジェクトを再構築するために使用されている場合は、受信したオブジェクトが誤って再構築される可能性があります。これは、適切に整合性チェックが失敗する原因となり、この場合には、不正確に再構築されたオブジェクトは破棄されるべきである（SHOULD）。したがって、単一の偽造パケットの受け入れは、オブジェクトを配布するための効果的なサービス拒否攻撃することができますが、オブジェクトの整合性チェックは、少なくとも不正確に再構築されたオブジェクトの不注意な使用を防止します。受信したオブジェクトのアプリケーションレベルの整合性チェックの仕様は、この文書の範囲外です。
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.
不正確なオブジェクトの再構築に対する保護を提供することに加えて、パケットレベルの認証は、複数のレート混雑制御上のサービス拒否攻撃に対する何らかの保護を提供することができます。攻撃者は、攻撃の下流のネットワーク要素と受信機に影響を与える、とはるかに少ない大幅にネットワークの他の部分と他のレシーバ、それによって潜在的に有害な、マルチキャストストリームに間違った輻輳制御情報を偽造パケットを注入しようとすることができます。このように、また、パケットレベルの認証は、このような攻撃から保護するために使用することをお勧めします。時限効率ストリーム損失トレラント認証（テスラ）[RFC5776]も、このような攻撃によって引き起こされる損傷を制限するために、ある程度使用することができます。しかし、TESLAと、受信機は、それが受信された後、パケットが真正数秒であり、受信機は、セッションの受信速度を遅くするために反応することができる前に、輻輳制御プロトコルに対するこのような攻撃は、数秒間有効であることができるかどうかを決定することができます。
Some packet authentication schemes such as TESLA [RFC5776] do not allow an immediate authenticity check. In this case, the receiver
このようTESLA [RFC5776]などの一部のパケットの認証方式は、即時の真正性チェックを許可していません。この場合、受信機
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.
できるだけ早くパケットの信憑性を確認する必要があり、かつパケットがチェックに失敗した場合、それは静かに上記ステップ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 / LCTプロトコルメッセージのヘッダに指定され、挿入されるIPsecのと同様のALC固有の認証またはセキュリティカプセル化ヘッダを可能にすることができます。これは、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 Security Association（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一対多SSM操作のこのベースラインフォームをサポートするために、各ノードは、トランスポートモードのIPsecセキュリティアソシエーションと対応するセキュリティポリシーデータベース（SPD）エントリを使用して構成されるものとする（SHALL）。このエントリは、送信者とグループのマルチキャストパケットの認証と、必要に応じて暗号化に使用されます。
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の送信者は、カプセル化セキュリティペイロード（ESP）対応のデータ発信認証のためのオプションを指定したプロトコル[RFC4303]の操作用に構成されたIPsec SAを使用しなければなりません。また、このIPsecのESP SAでもALCプロトコルメッセージを含むIPパケットの機密性保護を提供するように構成することが推奨されます。これは、複雑なリプレイ攻撃の実現がはるかに困難にすることが示唆されています。このSAの暗号化キーは、前ALCプロトコルの動作に送信者と受信者（複数可）に予め配置されるものとします。リキーがSAのためのシーケンス空間の満了前に要するものとして、自動化された鍵管理の使用が推奨されます。受信機は、単一のソース（ALCの送信者）とのIPsec SAのための可能なIPsecの組み込みのリプレイ攻撃からの保護を使用することができるように、これが必要です。このSAは、ALC送信者のトラフィックを保護するために使用するためにこのように、受信機は、リプレイ攻撃からの保護を有効にするものとします。送信側の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受信機（単数または複数）は、適切に、送信者からのIPsec-固定パケットを処理するSAとSPDエントリを設定する必要があります。敵は、コンテンツ受信時に受信機を欺くことが効果的なリプレイ攻撃を実施するための安全な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信頼転送セッション内のメッセージまたはトランスポートオブジェクトとしてグループに送信するための再入力メッセージのためのいくつかのキー管理方式を用いてもよいです。追加の仕様は、おそらくこの文書において引用自動グループ鍵管理仕様のメカニズムを使用して、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トラフィックのIPsec [RFC4301]処理の使用はまた、認証されていないパケットはALCプロトコル実装によって受信されないように要求されるべきです。
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アプリケーションおよび鍵管理の間利用可能であった場合、トランスポートオブジェクトとしてALCアプリケーション信頼性の高いデータ伝送に含まれる鍵更新メッセージ（例えば、GDOI GROUPKEY-PUSHメッセージ）のために可能であってもよいことに留意すべきですデーモン。
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.
レシーバは、指定、認可送信者（S）からの接続を受け入れる必要があります。適切なキー管理が唯一の指定されたセッションに参加することを許可受信者に暗号化キーを提供することが期待されます。ここで概説したアプローチは、受信機セットごとの送信者に基づいて制御されることを可能にします。
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の作者によるものです：マイク・ルビー、ジムGemmel、ロレンツォVicisano、ルイジ・リゾ、そしてジョン・クロークロフト。ヴィンセントロカ、ジャスティンChapweske、ロジャーKermodeも3450追加のおかげで、標準案にこの更新への貢献のためにヴィンセントロカとロッド・ウォルシュに起因するものであるRFCに貢献しました。
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 2616に廃止されたRFC 2068へのすべての参照を更新しました。
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一般LCTの文脈において適用可能な材料は、ALCは、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.
LCTヘッダの「プロトコル固有の表示」の最初のビットO「ソースパケット指示」として定義されます。これはFECスキームは、FEC復号化をサポートしていない受信機によって処理されることができる唯一のソースシンボルを含むパケットのためのものである一方は2つのFECペイロードIDフォーマットを定義する場合に用いられます。
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]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[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月。
[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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738]ルビー、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]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[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月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]ワトソン、M.、ルビー、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]ルビー、M.、ワトソン、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]マンキン、A.、ロマノフ、A.、RFC 2357、1998年6月ブラドナーの、S.、およびV.パクソン、 "信頼性の高いマルチキャストトランスポートとアプリケーションプロトコルを評価するためのIETF基準"。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]ハンドリー、M.、パーキンス、C.、およびE.ウィーラン、 "セッションアナウンスメントプロトコル"、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.、ハンドレー、M.、フロイド、S.、およびM.ルビー、 "信頼できるマルチキャストトランスポート・ビルディング・ブロック一対多バルクデータ転送のための" 、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、RFC 3269、2002年4月 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書の作者のガイドライン"。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[RFC3450]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、およびJ.クロウクロフト、RFC 3450 "非同期階層は（ALC）プロトコルインスタンス化コーディング"、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]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（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.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]バッタチャリヤ、S.、 "ソース固有マルチキャスト（SSM）の概要"、RFC 3569、2003年7月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]フェナー、B.とD.マイヤー、 "は、Multicast Source Discovery Protocol（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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（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.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、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]はハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロスは、：RFC 4535、2006年6月、 "GSAKMPグループは、協会の鍵管理プロトコルをセキュア"。
[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]はロカ、V.、Francillon、A.、およびS. Faurite、「非同期階層符号化（ALC）及びタイミング効率ストリーム損失トレラント認証（テスラ）を使用する高信頼マルチキャスト（NORM）プロトコルNACKを指向します」 、RFC 5776、2010年4月。
[RMT-SIMPLE] Roca, V., "Simple Authentication Schemes for the ALC and NORM Protocols", Work in Progress, October 2009.
[RMT-SIMPLE]ロカ、V.、 "ALCおよびNORMプロトコルのための簡単な認証スキーム"、進歩、2009年10月に作業。
Authors' Addresses
著者のアドレス
Michael Luby Qualcomm, Inc. 3165 Kifer Road Santa Clara, CA 95051 US
マイケル・ルビークアルコム社3165 Kifer道州サンタクララ、カリフォルニア州95051米国
EMail: luby@qualcomm.com
メールアドレス：luby@qualcomm.com
Mark Watson Qualcomm, Inc. 3165 Kifer Road Santa Clara, CA 95051 US
マーク・ワトソンクアルコム社3165 Kifer道州サンタクララ、カリフォルニア州95051米国
EMail: watson@qualcomm.com
メールアドレス：watson@qualcomm.com
Lorenzo Vicisano Qualcomm, Inc. 3165 Kifer Road Santa Clara, CA 95051 US
ロレンツォVicisanoクアルコム社3165 Kifer道州サンタクララ、カリフォルニア州95051米国
EMail: vicisano@qualcomm.com
メールアドレス：vicisano@qualcomm.com