Network Working Group M. Luby
Request for Comments: 3450 Digital Fountain
Category: Experimental J. Gemmell
Microsoft
L. Vicisano
Cisco
L. Rizzo
Univ. Pisa
J. Crowcroft
Cambridge Univ.
December 2002
Asynchronous Layered Coding (ALC) Protocol Instantiation
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書では、非同期階層符号化（ALC）プロトコル、大規模なスケーラブルな信頼性の高いコンテンツ配信プロトコルを記述します。非同期階層符号化は階層化符号化トランスポート（LCT）ビルディングブロック、複数のレート混雑制御ビルディングブロックおよび単一の同時受信を無制限にコンテンツの輻輳制御信頼性のある非同期の配信を提供するために、前方誤り訂正（FEC）ビルディングブロックを合成します送信者。
Table of Contents
目次
1. Introduction.................................................2
1.1 Delivery service models...................................3
1.2 Scalability...............................................5
1.3 Environmental Requirements and Considerations.............6
2. Architecture Definition......................................8
2.1 LCT building block........................................9
2.2 Multiple rate congestion control building block..........10
2.3 FEC building block.......................................11
2.4 Session Description......................................13
2.5 Packet authentication building block.....................14
3. Conformance Statement.......................................14
4. Functionality Definition....................................14
4.1 Packet format used by ALC................................15
4.2 Detailed Example of Packet format used by ALC............16
4.3 Header-Extension Fields..................................23
4.4 Sender Operation.........................................26
4.5 Receiver Operation.......................................27
5. Security Considerations.....................................29
6. IANA Considerations.........................................31
7. Intellectual Property Issues................................31
8. Acknowledgments.............................................31
9. References..................................................31
Authors' Addresses.............................................33
Full Copyright Statement.......................................34
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 RFC 3269 [8].
この文書は、IETF RMT WGの製品であり、[8] RFC 3269に設けられた一般的なガイドラインに従います。
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, RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC2357. As per RFC2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
このメモは、完全にRFC2357に従った信頼性の高いマルチキャストトランスポートプロトコルを指定するために必要な定義の一部が含まれています。 RFC2357に従って、インターネットの任意の信頼できるマルチキャストプロトコルの使用は、適切な輻輳制御方式を必要とします。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
このようなスキームを待っているが利用できるようにする、または既存のスキームのための十分な証明することが、信頼性の高いマルチキャスト交通ワーキンググループ（RMT）は「実験」カテゴリ内のコメントのためにこの要求を発行しています。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
すぐに上記の条件が満たされたとしてIETFのProposed Standardとして、この明細書を再提出するRMTの意図です。
ALC can support several different reliable content delivery service models. Some examples are briefly described here.
ALCは、いくつかの異なる信頼性の高いコンテンツ配信サービスモデルをサポートすることができます。いくつかの例をここで簡単に説明されています。
Push service model.
サービスモデルを押してください。
A push model is a sender initiated concurrent delivery of objects to a selected set of receivers. A push service model can be used for example for reliable delivery of a large object such as a 100 GB file. The sender could send a Session Description announcement to a control channel and receivers could monitor this channel and join a session whenever a Session Description of interest arrives. Upon receipt of the Session Description, each receiver could join the session to receive packets until enough packets have arrived to reconstruct the object, at which point the receiver could report back to the sender that its reception was completed successfully. The sender could decide to continue sending packets for the object to the session until all receivers have reported successful reconstruction or until some other condition has been satisfied. In this example, the sender uses ALC to generate packets based on the object and send packets to channels associated with the session, and the receivers use ALC to receive packets from the session and reconstruct the object.
プッシュモデルは、受信機の選択セットにオブジェクトの同時配信を開始し、送信者です。プッシュサービスモデルは、100GBのファイルのような大きな物体の信頼できる配信するための例示のために使用することができます。送信者は、制御チャネルにセッション記述の発表を送ることができるし、受信機は、このチャネルを監視し、関心のセッション記述が到着するたびにセッションに参加することができます。セッション記述を受信すると、各受信機は、十分なパケットが受信機はその受信が正常に完了したことを送信者に報告することがあり、その時点で対象物を、再構築するために到着するまでパケットを受信するセッションに参加できます。送信者は、すべての受信機が成功した再構成を報告したり他のいくつかの条件が満たされたまでするまでセッションへのオブジェクトのためのパケットの送信を継続することを決定することもできます。この例では、送信者は、オブジェクトに基づいてパケットを生成し、セッションに関連付けられたチャネルにパケットを送信するためにALCを使用し、受信機は、セッションからのパケットを受信するALCを使用してオブジェクトを再構成します。
There are several features ALC provides to support the push model. For example, the sender can optionally include an Expected Residual Time (ERT) in the packet header that indicates the expected remaining time of packet transmission for either the single object carried in the session or for the object identified by the Transmission Object Identifier (TOI) if there are multiple objects carried in the session. This can be used by receivers to determine if there is enough time remaining in the session to successfully receive enough additional packets to recover the object. If for example there is not enough time, then the push application may have receivers report back to the sender to extend the transmission of packets for the object for enough time to allow the receivers to obtain enough packets to reconstruct the object. The sender could then include an ERT based on the extended object transmission time in each subsequent packet header for the object. As other examples, the LCT header optionally can contain a Close Session flag that indicates when the sender is about to end sending packet to the session and a Close Object flag that indicates when the sender is about to end sending packets to the session for the object identified by the Transmission Object ID. However, these flags are not a completely reliable mechanism and thus the Close Session flag should only be used as a hint of when the session is about to close and the Close Object flag should only be used as a hint of when transmission of packets for the object is about to end.
ALCは、プッシュモデルをサポートするために提供し、いくつかの機能があります。例えば、送信者は、必要に応じてセッションまたは送信対象識別子（TOI）によって識別されたオブジェクトのために行わ単一のオブジェクトのいずれかのパケット送信の予想される残り時間を示すパケットヘッダに予想残余時間（ERT）を含むことができますセッションに運ば複数のオブジェクトが存在する場合。これが成功したオブジェクトを回復するために十分な追加のパケットを受信するためのセッションの残りの十分な時間があるかどうかを判断するために受信機で使用することができます。例えば十分な時間がない場合は、プッシュアプリケーションは、受信機は受信機がオブジェクトを再構築するのに十分なパケットを得ることができるように十分な時間のためのオブジェクトのためのパケットの送信を拡張するために送信者に報告しています。送信者は、オブジェクトのための後続の各パケットヘッダの拡張オブジェクトの伝送時間に基づいて、ERTを含むことができます。他の例として、LCTヘッダは、必要に応じて、送信者がセッションにパケットを送信終了しようとしているときを示すクローズセッションフラグと送信者がオブジェクトのセッションへのパケットの送信終了しようとしているときを示すクローズオブジェクトフラグを含むことができ送信対象のIDで識別されます。しかしながら、これらのフラグは、完全に信頼性の高いメカニズムではないので、クローズセッションフラグは、セッションがクローズしようとしていると近距離物体フラグのみのためのパケットの場合、送信のヒントとして使用されるべきである場合のヒントとして使用されるべきですオブジェクトは、終了しようとしています。
The push model is particularly attractive in satellite networks and wireless networks. In these environments a session may include one channel and a sender may send packets at a fixed rate to this channel, but sending at a fixed rate without congestion control is outside the scope of this document.
プッシュモデルは、衛星ネットワークと無線ネットワークにおいて特に魅力的です。これらの環境では、セッションは、一つのチャネルを含むことができ、送信者がこのチャネルに一定速度でパケットを送信するが、輻輳制御なしで固定レートで送信すると、この文書の範囲外であることができます。
On-demand content delivery model.
オンデマンドコンテンツ配信モデル。
For an on-demand content delivery service model, senders typically transmit for some given time period selected to be long enough to allow all the intended receivers to join the session and recover a single object. For example a popular software update might be transmitted using ALC for several days, even though a receiver may be able to complete the download in one hour total of connection time, perhaps spread over several intervals of time. In this case the receivers join the session at any point in time when it is active. Receivers leave the session when they have received enough packets to recover the object. The receivers, for example, obtain a Session Description by contacting a web server.
オンデマンドのコンテンツ配信サービスモデルの場合、送信者は、一般的に、すべての意図した受信機がセッションに参加し、単一のオブジェクトを回復できるように十分な長さに選択いくつかの特定の期間のために送信します。例えば、人気のあるソフトウェアの更新は、受信機は、おそらく、接続時間の1時間の合計でダウンロードを完了時にはいくつかの間隔に広がることが可能であっても、数日間ALCを使用して送信される可能性があります。この場合、受信機は、それがアクティブである場合、任意の時点でセッションに参加します。彼らはオブジェクトを回復するのに十分なパケットを受信したときの受信機がセッションを終了します。受信機は、例えば、Webサーバを接触させることにより、セッション記述を得ます。
Other service models.
その他のサービスモデル。
There may be other reliable content delivery service models that can be supported by ALC. The description of the potential applications, the appropriate delivery service model, and the additional mechanisms to support such functionalities when combined with ALC is beyond the scope of this document.
ALCによりサポートすることができ、他の信頼性の高いコンテンツ配信サービスモデルがあるかもしれません。 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 though 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 is joined to the session 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 [11], the FEC building block [10], the multiple rate congestion control building block and to any additional building blocks that ALC uses also apply to ALC.
LCTのビルディングブロックに適用される環境要件と考慮事項のすべてを[11]、FECビルディングブロック[10]、複数のレート混雑制御ビルディングブロックとALCはまた、ALCに適用されます使用して追加のビルディングブロックへ。
ALC requires connectivity between a sender and receivers, but does not require connectivity from receivers to a sender. ALC inherently works with all types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. Thus, the inherent raw scalability of ALC is unlimited. However, ALC requires receivers to obtain the Session Description out-of-band before joining a session and some implementations of this may limit scalability.
ALCは、送信者と受信者間の接続を必要としますが、受信機から送信側への接続を必要としません。 ALCは、本質的にLANやWANを、イントラネット、インターネット、非対称ネットワーク、無線ネットワーク、衛星ネットワークを含むネットワークのすべてのタイプで動作します。このように、ALCの固有の生のスケーラビリティは無制限です。しかし、ALCは、セッションに参加する前に、アウト・オブ・バンドセッション記述を取得するために受信機を必要とし、これのいくつかの実装は、スケーラビリティを制限することがあります。
If a receiver is joined to multiple ALC sessions then the receiver MUST be able to uniquely identify and demultiplex packets to the correct session. The Transmission Session Identifier (TSI) that MUST appear in each packet header is used for this purpose. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI uniquely identify the session. Thus, the demultiplexing MUST be done on the basis of the IP address of the sender and the TSI of the session from that sender.
受信機は、複数のALCセッションに参加している場合、受信機は一意的正しいセッションにパケットを識別し、逆多重化できなければなりません。各パケットのヘッダに表示される必要があり伝送セッション識別子（TSI）は、この目的のために使用されます。 TSIは、送信者のIPアドレスによってスコープされ、そしてTSIと共に、送信者のIPアドレスは、セッションを一意に識別する。したがって、分離は、送信者のIPアドレスと、その送信者からのセッションのTSIに基づいて行われなければなりません。
ALC is presumed to be used with an underlying IP multicast network or transport service that is a "best effort" service that does not guarantee packet reception, packet reception order, and which does not have any support for flow or congestion control. There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in RFC 1112 [3] and the Source-Specific Multicast (SSM) model as defined in [7]. ALC works with both multicast models, but in a slightly different way with somewhat different environmental concerns. When using ASM, a sender S sends packets to a multicast group G, and an ALC channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and an ALC channel address coincides with the SSM channel address.
ALCは、パケット受信、パケットの受信順序を保証するものではありません「ベストエフォート」のサービスである基本的なIPマルチキャストネットワークまたはトランスポートサービスで使用していると推定され、これは、フローや輻輳制御のためのあらゆるサポートしていません。マルチキャスト配信の2つのモデルが現在あり、RFC 1112で定義されるような任意の-ソースマルチキャスト（ASM）モデル[3]で定義されるようにソース固有マルチキャスト（SSM）モデル[7]。 ALCは、両方のマルチキャストモデルで動作しますが、多少異なる環境への懸念と少し異なる方法インチASMを使用する場合、送信者Sは、マルチキャストグループGにパケットを送信し、ALCチャンネルアドレスがSは、送信者のIPアドレスでありGはマルチキャストグループアドレスである対（S、G）、から成ります。 SSMを使用する場合、送信者Sは、SSMチャネル（S、G）にパケットを送信し、ALCチャンネルアドレスがSSMチャネルアドレスと一致します。
A sender can locally allocate unique SSM channel addresses, and this makes allocation of ALC channel addresses easy with SSM. To allocate ALC channel addresses using ASM, the sender must uniquely choose the ASM multicast group address across the scope of the group, and this makes allocation of ALC channel addresses more difficult with ASM.
送信者は、ローカルで一意SSMチャンネルアドレスを割り当てることができ、そしてこれは、SSMとALCチャンネルアドレスの割り当てが容易になります。 ASMを使用してALCチャンネルアドレスを割り当てるには、送信者は、一意のグループの範囲全体でASMマルチキャストグループアドレスを選択する必要があり、これはASMとALCチャンネルアドレスの割り当てがより困難にします。
ALC channels and SSM channels coincide, and thus the receiver will only receive packets sent to the requested ALC channel. With ASM, the receiver joins an ALC channel by joining a multicast group G, and all packets sent to G, regardless of the sender, may be received by the receiver. Thus, SSM has compelling security advantages over ASM for prevention of denial of service attacks. In either case, receivers SHOULD use mechanisms to filter out packets from unwanted sources.
ALCチャネルとSSMチャネルが一致するので、受信機は、要求されたALCチャンネルに送信されたパケットを受信します。 ASMと、受信機にかかわらず、送信者の受信機によって受信されるマルチキャストグループGに参加することによりALCチャネル、およびGに送信されたすべてのパケットを、合流します。このように、SSMは、サービス拒否攻撃の防止のためのASM以上の魅力的なセキュリティ上の利点があります。いずれの場合においても、受信機は、不要なソースからパケットをフィルタリングするためのメカニズムを使用すべきです。
Other issues 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 uses 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 MSDP 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 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.
ASMに関してはALCに固有の他の問題は、複数のレート混雑制御ビルディングブロックは、ASMと対話する方法です。輻輳制御ビルディングブロックは、送信されたチャネルに参加するとの間の時間で測定された差を使用してもよいし、チャネルからの最初のパケットは、受信機の受信レートを決定する際に到着したとき。輻輳制御ビルディングブロックは、損失を測定するために、チャネル当たりのパケットのシーケンス番号を使用してもよく、これは、受信機の受信レートを決定するために使用されます。これらの機能は、ASMに関して2つの懸念を提起：チャネルに参加するとの間の時間差が送信され、最初のパケットが到着したときに原因ランデブーポイント（RPS）の使用およびMSDPプロトコルに重要なことができ、かつパケットが可能（*、G）からスイッチオーバーで失わRPおよび（S、G）送信者に直接参加する参加します。これらの問題の両方が潜在的に、実質的に受信機の受信率を低下させることができます。これらの懸念を緩和するためには、RPが可能な限り、送信者に近いことが推奨されます。 SSMは、これらの同じ懸念を共有していません。これらの問題のより完全な検討のために、複数のレート混雑制御ビルディングブロックを参照してください。
Some networks are not amenable to some congestion control protocols that could be used with ALC. In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session.
ネットワークによっては、ALCで使用することができ、いくつかの輻輳制御プロトコルに従順ではありません。具体的には、衛星または無線ネットワークのために、セッションに割り当てられた一定の伝送速度が存在し得るので、効果的に受信レートを低減するための受信機のためのメカニズムが存在しない場合があります。
ALC is compatible with either IPv4 or IPv6 as no part of the packet is IP version specific.
パケットのどの部分が、IPバージョン特定されないようALCは、IPv4またはIPv6のいずれかと互換性があります。
ALC uses the LCT building block [11] to provide in-band session management functionality. ALC uses a multiple rate congestion control building block that is compliant with RFC 2357 [12] 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 [10] 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ビルディングブロック[11]を使用します。 ALCは、フィードバック自由である輻輳制御を提供するために、[12] RFC 2357に準拠した複数のレート混雑制御ビルディング・ブロックを使用しています。レシーバは、セッションに関連付けられているチャンネルに参加して残すことによって、個別にその受信速度を調整します。 ALCは、信頼性を提供するために、FECビルディングブロック[10]を使用しています。送信者は、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 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 RFC 3048 [16]. This document describes version 1 of ALC which MUST use version 1 of LCT described in [11]. 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 [15] that supports IP multicast delivery of packets. Future versions of this specification, or companion documents may extend ALC to use the IP network layer service directly. ALC could be used as the basis for designing a protocol that uses a different underlying network service such as unicast UDP, but the design of such a protocol is outside the scope of this document.
ALCは、RFC 3048 [16]で定義されたプロトコルのインスタンスです。この文書では、[11]に記載のLCTのバージョン1を使用しなければならないALCのバージョン1を記述する。 LCTのように、ALCは、IPマルチキャストネットワークサービスで使用するように設計されています。この仕様は、パケットのIPマルチキャスト配信をサポートUDPトランスポートプロトコル[15]のペイロードとしてALCを定義します。将来、この仕様のバージョン、またはコンパニオン文書は、直接IPネットワークレイヤサービスを使用するようにALCを延長することができます。 ALCは、ユニキャストUDPなどの異なる基本的なネットワークサービスを使用するプロトコルを設計するための基礎として使用することができ、そのようなプロトコルの設計は、この文書の範囲外です。
An ALC packet header immediately follows the UDP header and consists of the default LCT header that is described in [11] followed by the FEC Payload ID that is described in [10]. The Congestion Control Information field within the LCT header carries the required
ALCパケットヘッダは直ちにUDPヘッダの後に続き、[11] [10]に記載されているFECペイロードID続いに記載されているデフォルトのLCTヘッダから成ります。 LCTヘッダ内の輻輳制御情報フィールドは必須を運びます
Congestion Control Information that is described in the multiple rate congestion control building block specified that is compliant with RFC 2357 [12]. The packet payload that follows the ALC packet header consists of encoding symbols that are identified by the FEC Payload ID as described in [10].
複数のレート混雑制御ビルディングブロックで説明されている輻輳制御情報は、それはRFC 2357 [12]に準拠して指定しました。 ALCパケットヘッダに続くパケットペイロードは、[10]に記載されているようにFECペイロードIDによって識別される符号化シンボルから成ります。
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 [10] 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ビルディングブロック[10]で指定された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 Information as specified in the FEC building block [10] 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ヘッダは、受信機へのセッションの間に変化することができる情報の設定を通信するために使用されるかもしれコードポイントフィールドを含みます。使用した場合、設定とコードポイント値との間のマッピングは、セッション記述に通信され、このマッピングは、この文書の範囲外です。各オブジェクトは、セッション中に行われ、コードポイント値がFEC符号化IDを通信するために使用することができるため、例えば、FECビルディングブロック[10]で指定されるようにFECオブジェクト伝送情報の一部である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 MAY NOT 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 default LCT header from version 1 of the LCT building block [11] MUST be used.
LCTのビルディングブロック[11]のバージョン1から既定のLCTヘッダが使用されなければなりません。
Implementors of ALC MUST implement a multiple rate feedback-free congestion control building block that is in accordance to RFC 2357 [12]. 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. The multiple rate congestion control building block MUST specify in-band Congestion Control Information (CCI) that MUST be carried in the CCI field of the LCT header. The multiple rate congestion control building block MAY specify more than one format, 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の実装は、RFC 2357 [12]に応じた複数の速度フィードバックフリー輻輳制御ビルディングブロックを実装しなければなりません。輻輳制御は、独立して、オブジェクトが各パケットで運ばれているかについてのどの情報のセッション内のすべてのパケットに適用されなければなりません。複数のレート輻輳制御があるため、大規模なスケールするの適合のしているため信頼性の高いコンテンツ配信のためのその適合性の指定されています。複数のレート混雑制御ビルディングブロックは、LCTヘッダのCCIフィールドで実行されなければならない帯域内輻輳制御情報（CCI）を指定しなければなりません。複数のレート混雑制御ビルディングブロックは、複数のフォーマットを指定するかもしれないが、それは可能な長さ32、64、96または128ビットのそれぞれに対して最大1つのフォーマットを指定しなければなりません。 CCIフィールドの長さを決定するLCTヘッダ内のCの値は、複数のレート輻輳制御構築ブロックで定義されたCCIのための長さのいずれかに対応している必要があり、この長さは、セッションに送信されるすべてのパケットで同じである必要があり、そして、複数のレート混雑制御ビルディングブロックで指定されている長さに対応する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 which set of channels they are joined to 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 [10] provides reliable object delivery within an ALC session. Each object sent in the session is independently encoded using FEC codes as described in [9], 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 building block [10]. 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ビルディングブロック[10] ALCセッション内の信頼性の高いオブジェクトの配信を提供します。 [9]に記載されているようにセッションで送信される各オブジェクトは、独立してFEC符号を用いて符号化され、信頼性の高いコンテンツ配信プロトコルでFEC符号の使用のより詳細な説明を提供します。 ALCセッション内のすべてのパケットは、FECビルディングブロック[10]に準拠した形式でFECペイロードIDを含まなければなりません。 FECペイロードIDは一意に各パケットのペイロードを構成する符号化シンボルを識別し、受信機は、FECビルディングに記載されているようにパケットのペイロードで運ばれた符号化シンボルは、オブジェクトから生成されたかを決定するためにFECペイロードIDを使用しなければなりませんブロック。
As described in [10], a receiver is REQUIRED to obtain the FEC Object Transmission Information for each object for which data packets are received from the session. The FEC Object Transmission Information includes:
[10]に記載されているように、受信機は、データパケットがセッションから受信される各オブジェクトのFECオブジェクト伝送情報を得るために必要とされます。 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 length of the object in bytes.
セッション内の各オブジェクトについて、O、バイト内のオブジェクトの長さ。
o The additional required FEC Object Transmission Information for the FEC Encoding ID as prescribed in the FEC building block [10]. For example, when the FEC Encoding ID is 128, the required FEC Object Transmission Information is the number of source blocks that the object is partitioned into and the length of each source block in bytes.
FECビルディングブロック[10]に規定するFEC符号化IDのために必要な追加のFECオブジェクト伝送情報O。 FEC符号化IDが128である場合、例えば、必要なFECオブジェクト伝送情報は、オブジェクトに分割されるソースブロックの数とバイト内の各ソースブロックの長さです。
Some of the FEC Object Transmission Information MAY be implicit based on the 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符号化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, or 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 either 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オブジェクト伝送情報を受信機に伝達されてどのようにこの文書の範囲外です。
If packets for more than one object are transmitted within a session then a Transmission Object Identifier (TOI) that uniquely identifies objects within a session MUST appear in each packet header. Portions of the FEC Object Transmission Information could be the same for all objects in the session, in which case these portions can be communicated to the receiver with an indication that this applies to all objects in the session. These portions may be implicitly determined based on the application, e.g., an application may use the same FEC Encoding ID for all objects in all sessions. If there is a portion of the FEC Object Transmission Information that may vary from object to object and if this FEC Object Transmission Information is communicated to a receiver out-of-band then the TOI for the object MUST also be communicated to the receiver together with the corresponding FEC Object Transmission Information, and the receiver MUST use the corresponding FEC Object Transmission Information for all packets received with that TOI. How the TOI and corresponding FEC Object Transmission Information is communicated out-of-band to receivers is outside the scope of this document.
複数のオブジェクトのためのパケットがセッション内で送信されている場合、一意のセッション内のオブジェクトを識別する送信対象識別子（TOI）は、各パケットのヘッダに現れなければなりません。 FECオブジェクト伝送情報の部分は、これらの部分は、これがセッション内のすべてのオブジェクトに適用されることを指示して受信機に通信することができる場合には、セッション内のすべてのオブジェクトについて同じであってもよいです。これらの部分は、暗黙的にアプリケーションに基づいて決定することができる、例えば、アプリケーションは、すべてのセッション内のすべてのオブジェクトに対して同一のFEC符号化IDを使用してもよいです。 FECオブジェクト伝送情報の部分がある場合にオブジェクトのオブジェクトごとに異なるかもしれないし、このFECオブジェクト伝送情報は、帯域外受信器に通信されるならば、オブジェクトのTOIもと共に受信機に伝達されなければなりません対応するFECオブジェクト伝送情報、及び受信機は、そのTOIで受信されたすべてのパケットに対応するFECオブジェクト伝送情報を使用しなければなりません。 TOIと対応するFECオブジェクト伝送情報を受信機にアウト・オブ・バンドで通信される方法は、この文書の範囲外です。
It is also possible that there is a portion of the FEC Object Transmission Information that may vary from object to object that is carried in-band, for example in the CodePoint field or in Header Extensions. How this is done is outside the scope of this document. In this case the FEC Object Transmission Information is associated with the object identified by the TOI carried in the packet.
それがコードポイントフィールド又はヘッダ拡張、例えば、帯域内で実行されるオブジェクトのオブジェクトと異なる場合がFECオブジェクト伝送情報の一部が存在することも可能です。これはどのように行われ、この文書の範囲外です。この場合、FECオブジェクト伝送情報は、パケットで運ばTOIによって識別されたオブジェクトに関連付けられています。
The Session Description that a receiver is REQUIRED to obtain before joining an ALC session MUST contain 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 it 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 SDP as defined in RFC 2327 [5], or XML metadata as defined in RFC 3023 [13], or HTTP/Mime headers as defined in RFC 2068 [4], etc. It might be carried in a session announcement protocol such as SAP as defined in RFC 2974 [6], obtained using a proprietary session control protocol, located on a web page with scheduling information, or conveyed via E-mail 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.
RFC 2068で定義されているセッション記述は、それがかもしれない等、[4] RFC 2327で定義されるように[13] [5]、またはXMLメタデータRFC 3023で定義されるようなSDPのような形態であっても、またはHTTP / MIMEヘッダができRFC 2974で定義されている[6]、Eメールまたはその他のアウトオブバンド方法を介して、スケジューリング情報をウェブページ上に位置する独自のセッション制御プロトコルを用いて得られた、又は搬送SAPなどのセッションアナウンスメントプロトコルで運ばれます。受信機へのセッション記述の通信のためのセッション記述形式や方法についての議論は、この文書の範囲を超えています。
It is RECOMMENDED that implementors of ALC use some packet authentication scheme to protect the protocol from attacks. An example of a possibly suitable scheme is described in [14]. Packet authentication in ALC, if used, is to be integrated through the Header Extension support for packet authentication provided in the LCT building block.
ALCの実装者は攻撃からプロトコルを保護するために、いくつかのパケットの認証方式を使用することをお勧めします。おそらく適切なスキームの例は、[14]に記載されています。 ALCにおけるパケット認証は、使用している場合、LCTのビルディングブロックで提供パケット認証のためのヘッダー拡張機能のサポートを通じて統合されます。
This Protocol Instantiation document, in conjunction with the LCT building block [11], the FEC building block [10] and with a multiple rate congestion control building block completely specifies a working reliable multicast transport protocol that conforms to the requirements described in RFC 2357 [12].
LCTのビルディングブロックと関連して、このプロトコル・インスタンス化文書、[11]、FECビルディングブロック[10]と、複数のレート混雑制御ビルディングブロックとは、完全にRFC 2357で説明した要件に準拠作動信頼できるマルチキャストトランスポートプロトコルを指定します[ 12]。
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 default LCT header followed by the FEC Payload ID followed by the packet payload. The default LCT header is described in the LCT building block [11] and the FEC Payload ID is described in the FEC building block [10]. 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 which object the encoding symbols are generated from. 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ビルディングブロック[11]に記載されており、FECペイロードIDは、FECビルディングブロック[10]に記載されています。 LCTヘッダ内の輻輳制御情報フィールドが使用される複数のレート輻輳制御構築ブロックで説明されている必要な輻輳制御情報を含みます。パケットペイロードは、オブジェクトから生成された符号化シンボルを含みます。複数のオブジェクトは、その後のセッションで実行される場合LCTヘッダ内の送信対象のID（TOI）がから生成される符号化シンボルオブジェクトを識別するために使用されなければなりません。 FECビルディングブロックに記載されているように、オブジェクトの範囲内で、パケットのペイロードで運ばれた符号化シンボルがFECペイロードIDによって識別されます。
The version number of ALC specified in this document is 1. This coincides with version 1 of the LCT building block [11] used in this specification. The LCT version number field should be interpreted as the ALC version number field.
この文書で指定されたALCのバージョン番号がこの明細書中で使用されるLCTビルディングブロック[11]のバージョン1と一致1です。 LCTバージョン番号フィールドは、ALCバージョン番号フィールドとして解釈されるべきです。
The overall ALC packet format is depicted in Figure 1. 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. The default LCT header MUST be used by ALC and this default is described in detail in the LCT building block [11].
全体的なALCパケットフォーマットは、IPv4またはIPv6のいずれかで、パケットがIPパケットである図1に示され、およびIPヘッダがUDPヘッダに先行されます。 ALCパケットフォーマットは、IPのバージョン番号に依存しません。デフォルトのLCTヘッダは、ALCによって使用する必要があり、このデフォルトは、LCTのビルディングブロック[11]に詳細に記載されています。
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 |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default LCT header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Overall ALC packet format
図1 - 全体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の不在を検出するための受信機を可能にします。
A detailed example of an ALC packet starting with the LCT header is shown in Figure 2. In the example, the LCT header is the first 5 32-bit words, the FEC Payload ID is the next 2 32-bit words, and the remainder of the packet is the payload.
LCTヘッダから始まるALCパケットの具体例を実施例図2に示され、LCTヘッダは第5の32ビット・ワードであり、FECペイロードIDは、次の2 32ビット・ワードであり、そして残りパケットのペイロードです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 0 |1| 1 |0|1|0|0|0| 5 | 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - A detailed example of the ALC packet format
図2 - ALCパケットフォーマットの詳細な例
The LCT portion of the overall ALC packet header is of variable size, which is specified by a length field in the third byte of the header. All integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. Bits designated as "padding" or "reserved" (r) MUST by set to 0 by senders and ignored by receivers. Unless otherwise noted, numeric constants in this specification are in decimal (base 10).
全体的なALCパケットヘッダのLCT部分は、ヘッダの第3バイトの長さフィールドで指定された可変サイズのものです。すべての整数フィールドは、最上位バイト（オクテット）最初、つまり、「ビッグエンディアン」または「ネットワーク順」形式で行われています。ビットは送信者によって0に設定することによって「パディング」または「予約」（登録商標）MUSTとして指定され、受信機によって無視します。特に断りのない限り、本明細書中の数値定数は、小数（ベース10）です。
The function and length and particular setting of the value for each field in this detailed example of the header is the following, described in the order of their appearance in the header.
関数と長さとヘッダのこの詳細な例では、各フィールドの値の特定の設定は、ヘッダ内のそれらの出現の順に説明以下、です。
ALC version number (V): 4 bits
ALCバージョン番号（V）：4ビット
Indicates the ALC version number.
The ALC version number for this specification is 1 as shown.
This is also the LCT version number.
Congestion control flag (C): 2 bits
輻輳制御フラグ（C）：2ビット
The Congestion Control Information (CCI) field specified by the
multiple rate congestion control building block is a multiple
of 32-bits in length. The multiple rate congestion control
building block MUST specify a format for the CCI. The
congestion control building block MAY specify formats for
different CCI lengths, where the set of possible lengths is 32,
64, 96 or 128 bits. The value of C MUST match the length of
exactly one of the possible formats for the congestion control
building block, and this format MUST be used for the CCI field.
The value of C MUST be the same for all packets sent to a
session.
C=0 indicates the 32-bit CCI field format is to be used. C=1 indicates the 64-bit CCI field format is to be used. C=2 indicates the 96-bit CCI field format is to be used. C=3 indicates the 128-bit CCI field format is to be used.
C = 0は、32ビットCCIフィールドのフォーマットが使用されるべきであることを示します。 C = 1は、64ビットCCIフィールドのフォーマットが使用されるべきであることを示します。 C = 2 96ビットCCIフィールドのフォーマットが使用されるべきであることを示します。 C = 3、128ビットCCIフィールドのフォーマットが使用されるべきであることを示します。
In the example C=0 indicates that a 32-bit format is to be used.
一例ではC = 0が32ビットフォーマットが使用されることを示しています。
Reserved (r): 2 bits
予約済み（R）：2ビット
Reserved for future use. A sender MUST set these bits to zero
and a receiver MUST ignore these bits.
As required, these bits are set to 0 in the example.
必要に応じて、これらのビットは、例えば0に設定されています。
Transport Session Identifier flag (S): 1 bit
移送セッション識別子フラグ（S）：1ビット
This is the number of full 32-bit words in the TSI field. The
TSI field is 32*S + 16*H bits in length. For ALC the length of
the TSI field is REQUIRED to be non-zero. This implies that
the setting S=0 and H=0 MUST NOT be used.
In the example S=1 and H=0, and thus the TSI is 32-bits in length.
例えばS = 1及びH = 0、したがって、TSIは、長さが32ビットです。
Transport Object Identifier flag (O): 2 bits
移送オブジェクト識別子フラグ（O）：2ビット
This is the number of full 32-bit words in the TOI field. The
TOI field is 32*O + 16*H bits in length. If more than one
object is to be delivered in the session then the TOI MUST be
used, in which case the setting O=0 and H=0 MUST NOT be used.
In the example O=1 and H=0, and thus the TOI is 32-bits in length.
例のO = 1及びH = 0、従ってTOIは、長さが32ビットです。
Half-word flag (H): 1 bit
ハーフワードフラグ（H）：1ビット
The TSI and the TOI fields are both multiples of 32-bits plus
16*H bits in length. This allows the TSI and TOI field lengths
to be multiples of a half-word (16 bits), while ensuring that
the aggregate length of the TSI and TOI fields is a multiple of
32-bits.
In the example H=0 which indicates that both TSI and TOI are both multiples of 32-bits in length.
TSIとTOIの両方の長さが32ビットの両方の倍数であることを示し、例えばH = 0です。
Sender Current Time present flag (T): 1 bit
送信側現在時刻存在フラグ（T）：1ビット
T = 0 indicates that the Sender Current Time (SCT) field is not
present.
T = 1 indicates that the SCT field is present. The SCT is
inserted by senders to indicate to receivers how long the
session has been in progress.
In the example T=1, which indicates that the SCT is carried in this packet.
SCTは、このパケットで運ばれていることを示す例でT = 1、です。
Expected Residual Time present flag (R): 1 bit
予想残余時間存在フラグ（R）：1ビット
R = 0 indicates that the Expected Residual Time (ERT) field is
not present.
R = 1 indicates that the ERT field is present.
The ERT is inserted by senders to indicate to receivers how much longer packets will be sent to the session for either the single object carried in the session or for the object identified by the TOI if there are multiple objects carried in the session. Senders MUST NOT set R = 1 when the ERT for the object is more than 2^32-1 time units (approximately 49 days), where time is measured in units of milliseconds.
ERTは、長いパケットがセッションで運ばれ、単一のオブジェクトのいずれか、またはセッションで運ば複数のオブジェクトがある場合、TOIによって特定されたオブジェクトのためのセッションに送信されますどのくらいの受信者に示すために、送信者によって挿入されます。オブジェクトのERTは、時間をミリ秒単位で測定された以上2 ^ 32-1時間単位（約49日）である場合、送信者は、R = 1を設定してはいけません。
In the example R=0, which indicates that the ERT is not carried in this packet.
ERTは、このパケットで運ばれていないことを示し、例えばR = 0、です。
Close Session flag (A): 1 bit
クローズセッションフラグ（A）：1ビット
Normally, A is set to 0. The sender MAY set A to 1 when
termination of transmission of packets for the session is
imminent. A MAY be set to 1 in just the last packet
transmitted for the session, or A MAY be set to 1 in the last
few seconds of packets transmitted for the session. Once the
sender sets A to 1 in one packet, the sender SHOULD set A to 1
in all subsequent packets until termination of transmission of
packets for the session. A received packet with A set to 1
indicates to a receiver that the sender will immediately stop
sending packets for the session. When a receiver receives a
packet with A set to 1 the receiver SHOULD assume that no more
packets will be sent to the session.
In the example A=0, and thus this packet does not indicate the close of the session.
例えばA = 0であり、したがって、このパケットは、セッションの終了を示していません。
Close Object flag (B): 1 bit
クローズオブジェクトフラグ（B）：1ビット
Normally, B is set to 0. The sender MAY set B to 1 when
termination of transmission of packets for an object is
imminent. If the TOI field is in use and B is set to 1 then
termination of transmission for the object identified by the
TOI field is imminent. If the TOI field is not in use and B is
set to 1 then termination of transmission for the one object in
the session identified by out-of-band information is imminent.
B MAY be set to 1 in just the last packet transmitted for the
object, or B MAY be set to 1 in the last few seconds packets
transmitted for the object. Once the sender sets B to 1 in one
packet for a particular object, the sender SHOULD set B to 1 in
all subsequent packets for the object until termination of
transmission of packets for the object. A received packet with
B set to 1 indicates to a receiver that the sender will
immediately stop sending packets for the object. When a
receiver receives a packet with B set to 1 then it SHOULD
assume that no more packets will be sent for the object to the
session.
In the example B=0, and thus this packet does not indicate the end of sending data packets for the object.
例B = 0であり、従ってこのパケットは、オブジェクトのデータパケットの送信の終了を示すものではありません。
LCT header length (HDR_LEN): 8 bits
LCTヘッダ長（HDR_LEN）：8ビット
Total length of the LCT header in units of 32-bit words. The
length of the LCT header MUST be a multiple of 32-bits. This
field can be used to directly access the portion of the packet
beyond the LCT header, i.e., the FEC Payload ID if the packet contains a payload, or the end of the packet if the packet
contains no payload.
In the example HDR_LEN=5 to indicate that the length of the LCT header portion of the overall ALC is 5 32-bit words.
例でHDR_LEN = 5は、全体的なALCのLCTヘッダ部分の長さが5の32ビット・ワードであることを示します。
Codepoint (CP): 8 bits
コードポイント（CP）：8ビット
This field is used by ALC to carry the mapping that identifies
settings for portions of the Session Description that can
change within the session. The mapping between Codepoint
values and the settings for portions of the Session Description
is to be communicated out-of-band.
In the example the portion of the Session Description that can change within the session is the FEC Encoding ID, and the identity mapping is used between Codepoint values and FEC Encoding IDs. Thus, CP=128 identifies FEC Encoding ID 128, the "Small Block, Large Block and Expandable FEC Codes" as described in the FEC building block [10]. The FEC Payload ID associated with FEC Encoding ID 128 is 64-bits in length.
例ではセッション内で変更することができるセッション記述の部分は、FEC符号化IDであり、IDマッピングは、コードポイント値とFEC符号化IDの間に使用されます。このように、CP = 128は、FEC符号化ID 128「小ブロック、大ブロック及び拡張FECコード」FECビルディングブロック[10]に記載されているように識別する。 FEC符号化ID 128に関連付けられたFECペイロードIDは、長さが64ビットです。
Congestion Control Information (CCI): 32, 64, 96 or 128 bits
輻輳制御情報（CCI）：32、64、96または128ビット
This is field contains the Congestion Control Information as
defined by the specified multiple rate congestion control
building block. The format of this field is determined by the
multiple rate congestion control building block.
This field MUST be 32 bits if C=0. This field MUST be 64 bits if C=1. This field MUST be 96 bits if C=2. This field MUST be 128 bits if C=3.
C = 0の場合、このフィールドは32ビットでなければなりません。 C = 1の場合、このフィールドは64ビットでなければなりません。 C = 2の場合、このフィールドは96ビットでなければなりません。 C = 3であれば、このフィールドは、128ビットでなければなりません。
In the example, the CCI is 32-bits in length. The format of the CCI field for the example MUST correspond to the format for the 32-bit version of the CCI specified in the multiple rate congestion control building block.
一例では、CCIは、長さが32ビットです。例えばCCIフィールドのフォーマットは、複数のレート混雑制御ビルディングブロックで指定されたCCIの32ビットバージョンの形式に対応しなければなりません。
Transport Session Identifier (TSI): 16, 32 or 48 bits
トランスポートセッション識別子（TSI）：16、32または48ビット
The TSI uniquely identifies a session among all sessions from a
particular sender. The TSI is scoped by the sender IP address,
and thus the (sender IP address, TSI) pair uniquely identify
the session. For ALC, the TSI MUST be included in the LCT
header.
The TSI MUST be unique among all sessions served by the sender during the period when the session is active, and for a large period of time preceding and following when the session is active. A primary purpose of the TSI is to prevent receivers from inadvertently accepting packets from a sender that belong to sessions other than sessions receivers are subscribed to. For example, suppose a session is deactivated and then another session is activated by a sender and the two sessions use an overlapping set of channels. A receiver that connects and remains connected to the first session during this sender activity could possibly accept packets from the second session as belonging to the first session if the TSI for the two sessions were identical. The mapping of TSI field values to sessions is outside the scope of this document and is to be done out-of-band.
TSIは、セッションがアクティブである期間中に、送信者が提供するすべてのセッションの中で一意であること、そしてセッションがアクティブなとき、前後の時間の大期間にしなければなりません。 TSIの主な目的は、誤って受信者が加入しているセッション以外のセッションに属している送信者からのパケットを受け入れるのレシーバを防ぐためです。例えば、セッションが非アクティブ化され、その後、別のセッションが送信者によって活性化され、2つのセッションがチャネルの重複セットを使用すると仮定する。二つのセッションのためのTSIが同一であった場合に接続し、この送信者の活動中に第1のセッションに接続されたまま受信機は、おそらく最初のセッションに属しているように、第2のセッションからのパケットを受け入れることができます。セッションへのTSIフィールド値のマッピングは、この文書の範囲外であると帯域外で行われるべきです。
The length of the TSI field is 32*S + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits.
TSIフィールドの長さは32 * S + 16 * Hビットです。 TSIフィールドの集合体の長さプラスTOIフィールドは、32ビットの倍数であることに留意されたいです。
In the example the TSI is 32 bits in length.
例ではTSIは、長さが32ビットです。
Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 bits.
移送オブジェクト識別子（TOI）：0、16、32、48、64、80、96又は112ビット。
This field indicates which object within the session this
packet pertains to. For example, a sender might send a number
of files in the same session, using TOI=0 for the first file,
TOI=1 for the second one, etc. As another example, the TOI may
be a unique global identifier of the object that is being
transmitted from several senders concurrently, and the TOI
value may be the output of a hash function applied to the
object. The mapping of TOI field values to objects is outside
the scope of this document and is to be done out-of-band. The
TOI field MUST be used in all packets if more than one object
is to be transmitted in a session, i.e., the TOI field is
either present in all the packets of a session or is never
present.
The length of the TOI field is 32*O + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits.
TOIフィールドの長さは32 * O + 16 * Hビットです。 TSIフィールドの集合体の長さプラスTOIフィールドは、32ビットの倍数であることに留意されたいです。
In the example the TOI is 32 bits in length.
例でTOIは、長さが32ビットです。
Sender Current Time (SCT): 0 or 32 bits
送信側現在時刻（SCT）：0または32ビット
This field represents the current clock of the sender at the
time this packet was transmitted, measured in units of 1ms and
computed modulo 2^32 units from the start of the session.
This field MUST NOT be present if T=0 and MUST be present if T=1.
T = 0とする場合は、T = 1に存在しなければならない場合、このフィールドは存在してはなりません。
In this example the SCT is present.
この例ではSCTが存在します。
Expected Residual Time (ERT): 0 or 32 bits
予想残余時間（ERT）：0または32ビット
This field represents the sender expected residual transmission
time of packets for either the single object carried in the
session or for the object identified by the TOI if there are
multiple objects carried in the session.
This field MUST NOT be present if R=0 and MUST be present if R=1.
このフィールドは、R = 0の場合は存在してはならないとR = 1の場合に存在していなければなりません。
In this example the ERT is not present.
この例ではERTは存在しません。
FEC Payload ID: X bits
FECペイロードID：Xビット
The length and format of the FEC Payload ID depends on the FEC
Encoding ID as described in the FEC building block [10]. The
FEC Payload ID format is determined by the FEC Encoding ID that
MUST be communicated in the Session Description. The Session
Description MAY specify that more than one FEC Encoding ID is
used in the session, in which case the Session Description MUST
contain a mapping that identifies which Codepoint values
correspond to which FEC Encoding IDs. This mapping, if used,
is outside the scope of this document.
The example packet format corresponds to the format for "Small Block, Large Block and Expandable FEC Codes" as described in the FEC building block, for which the associated FEC Encoding ID 128. For FEC Encoding ID 128, the FEC Payload ID consists of the following two fields that in total are X = 64 bits in length:
例えば、パケットフォーマットは、「小ブロック、大ブロック及び拡張FECコード」FEC符号化ID 128に関連付けられたFEC符号化ID 128は、FECペイロードIDは、から構成されるFECビルディングブロック、に記載されるようにするためのフォーマットに対応します合計で、長さがX = 64ビットである2つのフィールドが次の
Source Block Number (SBN): 32 bits
ソースブロック番号（SBN）：32ビット
The Source Block Number identifies from which source block of the object the encoding symbol(s) in the payload are generated. These blocks are numbered consecutively from
ソースブロック番号は、ペイロード内のオブジェクトの符号化シンボル（複数可）のソースブロックが生成されるから識別する。これらのブロックから連続して番号が付けられています
0 to N-1, where N is the number of source blocks in the object.
N-1、Nは、オブジェクト内のソースブロックの数である0。
Encoding Symbol ID (ESI): 32 bits
符号化シンボルID（ESI）：32ビット
The Encoding Symbol ID identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload are dependent on the particular encoding algorithm used as identified by the FEC Encoding ID and by the FEC Instance ID.
符号化シンボルIDは、ソースブロックから生成された特定の符号化シンボル（s）は、パケットペイロードで運ばれる特定します。 FEC符号化IDによって、およびFECインスタンスIDによって識別されるパケットペイロードにおける符号化シンボルIDおよび符号化シンボル（S）との対応関係の正確な詳細は、使用される特定の符号化アルゴリズムに依存しています。
Encoding Symbol(s): Y bits
符号化シンボル（S）：Yビット
The encoding symbols are what the receiver uses to reconstruct
an object. The total length Y of the encoding symbol(s) in the
packet can be determined by the receiver of the packet by
computing the total length of the received packet and
subtracting off the length of the headers.
Header Extensions can be used to extend the LCT header portion of the ALC header to accommodate optional header fields that are not always used or have variable size. Header Extensions are not used in the example ALC packet format shown in the previous subsection. Examples of the use of Header Extensions include:
ヘッダ拡張が常に使用されていないオプションヘッダフィールドを収容または可変サイズを有するようにALCヘッダのLCTヘッダ部分を拡張するために使用することができます。ヘッダ拡張は、前の節で示した例ALCパケットフォーマットでは使用されません。ヘッダー拡張機能の使用例は次のとおりです。
o Extended-size versions of already existing header fields.
既存のヘッダフィールドのO拡張サイズバージョン。
o Sender and Receiver authentication information.
SenderとReceiverの認証情報O。
The presence of Header Extensions can be inferred by the LCT header length (HDR_LEN): if HDR_LEN is larger than the length of the standard header then the remaining header space is taken by Header Extension fields.
ヘッダ拡張の存在は、LCTヘッダ長（HDR_LEN）によって推測することができる：HDR_LENは標準ヘッダの長さよりも大きい場合、残りのヘッダ空間は、ヘッダ拡張フィールドによって行われます。
If present, Header Extensions MUST be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting a packet. The default action for unrecognized Header Extensions is to ignore them. This allows the future introduction of backward-compatible enhancements to ALC without changing the ALC version number. Non backward-compatible Header Extensions CANNOT be introduced without changing the ALC version number.
存在する場合、ヘッダ拡張は、彼らがどんな輻輳制御手順を実行するか、そうでない場合はパケットを受け入れる前に認識されていることを確認するために処理しなければなりません。認識できないヘッダ拡張のためのデフォルトのアクションは、それらを無視することです。これは、ALCバージョン番号を変更することなく、ALCへの下位互換性の強化、将来の導入を可能にします。非下位互換性ヘッダ拡張は、ALCのバージョン番号を変更せずに導入することができません。
There are two formats for Header Extension fields, as depicted below. The first format is used for variable-length extensions, with Header Extension Type (HET) values between 0 and 127. The second format is used for fixed length (one 32-bit word) extensions, using HET values from 127 to 255.
下記に示すように、ヘッダ拡張フィールドのための2つの形式があります。最初のフォーマットは、ヘッダ拡張タイプ（HET）の値と0と127との間に第二の形式は127〜255 HET値を使用して、固定長（1つの32ビット・ワード）の拡張のために使用される、可変長の拡張のために使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Format of additional headers
図3 - 追加ヘッダのフォーマット
The explanation of each sub-field is the following.
各サブフィールドの説明は以下の通りです。
Header Extension Type (HET): 8 bits
ヘッダ拡張タイプ（HET）：8ビット
The type of the Header Extension. This document defines a
number of possible types. Additional types may be defined in
future versions of this specification. HET values from 0 to
127 are used for variable-length Header Extensions. HET values
from 128 to 255 are used for fixed-length 32-bit Header
Extensions.
Header Extension Length (HEL): 8 bits
ヘッダ拡張長（HEL）：8ビット
The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field MUST be present for
variable-length extensions (HET between 0 and 127) and MUST NOT
be present for fixed-length extensions (HET between 128 and
255).
Header Extension Content (HEC): variable length
ヘッダー拡張コンテンツ（HEC）：可変長
The content of the Header Extension. The format of this sub-
field depends on the Header Extension type. For fixed-length
Header Extensions, the HEC is 24 bits. For variable-length
Header Extensions, the HEC field has variable size, as specified by the HEL field. Note that the length of each
Header Extension field MUST be a multiple of 32 bits. Also
note that the total size of the LCT header, including all
Header Extensions and all optional header fields, cannot exceed
255 32-bit words.
Header Extensions are further divided between general LCT extensions and Protocol Instantiation specific extensions (PI-specific). General LCT extensions have HET in the ranges 0:63 and 128:191 inclusive. PI-specific extensions have HET in the ranges 64:127 and 192:255 inclusive.
ヘッダ拡張は、さらに、一般的なLCT拡張機能やプロトコルインスタンス固有の拡張（PI固有）の間で分割されています。 191包括的な：一般LCT拡張子は範囲0:63と128でHETを持っています。 PI固有の拡張機能は、範囲64でHETを持っている：127および192：255の範囲を。
General LCT extensions are intended to allow the introduction of backward-compatible enhancements to LCT without changing the LCT version number. Non backward-compatible Header Extensions CANNOT be introduced without changing the LCT version number.
一般LCT拡張はLCTバージョン番号を変更することなく、LCTへの下位互換性の拡張機能の導入を可能にすることを意図しています。非下位互換性ヘッダ拡張は、LCTバージョン番号を変更せずに導入することができません。
PI-specific extensions are reserved for PI-specific use with semantic and default parsing actions defined by the PI.
PI固有の拡張は、PIによって定義されたセマンティックとデフォルトの構文解析アクションとPI-特定の使用のために予約されています。
The following general LCT Header Extension types are defined:
次の一般LCTヘッダ拡張タイプが定義されています。
EXT_NOP=0 No-Operation extension. The information present in this extension field MUST be ignored by receivers.
EXT_NOP = 0ノーオペレーション拡張。この拡張フィールドに存在する情報は、受信機によって無視されなければなりません。
EXT_AUTH=1 Packet authentication extension Information used to authenticate the sender of the packet. The format of this Header Extension and its processing is outside the scope of this document and is to be communicated out-of-band as part of the Session Description.
EXT_AUTH = 1つのパケット認証拡張情報は、パケットの送信者を認証するために使用されます。このヘッダー拡張とその処理の形式は、この文書の範囲外であると、セッション記述の一部として、アウトオブバンド通信されます。
It is RECOMMENDED that senders provide some form of
packet authentication. If EXT_AUTH is present,
whatever packet authentication checks that can be
performed immediately upon reception of the packet
SHOULD be performed before accepting the packet and
performing any congestion control-related action on it.
Some packet authentication schemes impose a delay of
several seconds between when a packet is received and
when the packet is fully authenticated. Any congestion
control related action that is appropriate MUST NOT be
postponed by any such full packet authentication.
All senders and receivers implementing ALC MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to parse its content.
ALCを実装するすべての送信者と受信者はEXT_NOPヘッダー拡張をサポートしなければならないとEXT_AUTHを認識しなければならないが、その内容を解析することができないかもしれません。
For this version of ALC, the following PI-specific extension is defined:
ALCのこのバージョンでは、以下のPI固有の拡張が定義されています。
EXT_FTI=64 FEC Object Transmission Information extension The purpose of this extension is to carry in-band the FEC Object Transmission Information for an object. The format of this Header Extension and its processing is outside the scope of this document and is to be communicated out-of-band as part of the Session Description.
EXT_FTI = 64 FECオブジェクト伝送情報の拡張は、この拡張の目的は、インバンドオブジェクトのFECオブジェクト伝送情報を搬送することです。このヘッダー拡張とその処理の形式は、この文書の範囲外であると、セッション記述の一部として、アウトオブバンド通信されます。
The sender operation when using ALC includes all the points made about the sender operation when using the LCT building block [11], the FEC building block [10] and the multiple rate congestion control building block.
ALCを使用して送信者の操作は、すべてのLCTビルディングブロック[11]を使用する場合、送信者の動作について点、FECビルディングブロック[10]と複数のレート混雑制御ビルディングブロックを含みます。
A sender using ALC MUST make available the required Session Description as described in Section 2.4. A sender also MUST 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 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 and 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は、パケットのペイロードで運ばれたオブジェクトの符号化シンボル（単数または複数）に対応しなければなりません。
Objects MAY be transmitted sequentially within a session, and they MAY be transmitted concurrently. However, it is good practice to only send objects concurrently in the same session if the receivers that participate in that portion of the session have interest in receiving all the objects. The reason for this is that it wastes bandwidth and networking resources to have receivers receive data for objects that they have no interest in. However, there are no rules with respect to mixing packets for different objects carried within the session. Although this issue affects the efficiency of the protocol, it does not affect the correctness nor the inter-operability of ALC between senders and receivers.
オブジェクトは、セッション内で順次伝送することができる、と彼らは同時に伝送することができます。しかし、それはセッションのその部分に参加受信機がすべてのオブジェクトを受け取ることに関心を持っている場合のみ、同じセッションで同時にオブジェクトを送信することをお勧めします。この理由は、それが受信機は、彼らがに興味を持っていないオブジェクトのデータを受信持っている帯域幅およびネットワークリソースを浪費ということです。しかし、セッション内で運ば異なるオブジェクトのためのパケットを混合に関して規則がありません。この問題は、プロトコルの効率に影響を与えるが、それは正確でも送信者と受信者の間でALCの相互運用性には影響を与えません。
Typically, the sender(s) continues to send packets in a session until the transmission is considered complete. The transmission may be considered complete when some time has expired, a certain number of packets have been sent, or some out-of-band signal (possibly from a higher level protocol) has indicated completion by a sufficient number of receivers.
典型的には、送信者（複数可）は、送信が完了したと見なされるまで、セッション内のパケットを送信し続けます。ある程度の時間が経過したとき、送信パケットの特定の数は、送信された、完了したとみなされてもよい、または（おそらくはより高いレベルのプロトコルから）いくつかのアウトオブバンド信号は、受信機のに十分な数で完了を示しました。
It is RECOMMENDED that packet authentication be used. If packet authentication is used then the Header Extensions described in Section 4.3 MUST be used to carry the authentication.
パケット認証を使用することをお勧めします。パケット認証が使用されている場合は、4.3節で説明したヘッダ拡張機能は、認証を運ぶために使用しなければなりません。
This document does not pose any restriction on packet sizes. However, network efficiency considerations recommend that the sender uses as large as possible packet payload size, but in such a way that packets do not exceed the network's maximum transmission unit size (MTU), or fragmentation coupled with packet loss might introduce severe inefficiency in the transmission. It is RECOMMENDED that all packets have the same or very similar sizes, as this can have a severe impact on the effectiveness of the multiple rate congestion control building block.
この文書では、パケットサイズ上の任意の制限をもたらすことはありません。しかし、ネットワーク効率の考慮は、送信者が可能なパケットのペイロードのサイズと同じ大き使用することをお勧めしますが、パケットはパケットロスと結合されたネットワークの最大伝送ユニットサイズ（MTU）、またはフラグメンテーションを超えないような方法での深刻な非効率性を導入するかもしれませんトランスミッション。複数のレート混雑制御ビルディングブロックの有効性に深刻な影響を与える可能性があるとして、すべてのパケットが、同じまたは非常によく似た大きさを持っていることが推奨されます。
The receiver operation when using ALC includes all the points made about the receiver operation when using the LCT building block [11], the FEC building block [10] and the multiple rate congestion control building block.
ALCを使用して受信機の動作は、すべてのLCTビルディングブロック[11]を使用する場合の受信動作について点、FECビルディングブロック[10]と複数のレート混雑制御ビルディングブロックを含みます。
To be able to participate in a session, a receiver MUST 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節に記載されているようにセッションに参加できるようにするには、受信機が必要なセッションの説明を取得する必要があります。受信機は、入手方法、セッション記述は、この文書の範囲外です。
To be able to be a receiver in a session, the receiver MUST be able to process the ALC header. The receiver MUST be able to discard, forward, store or process the other headers and the packet payload. If a receiver is not able to process the ALC header, it MUST drop from the session.
セッション中に受信することができるように、受信機は、ALCヘッダを処理できなければなりません。受信機は、前方に、廃棄格納または他のヘッダとパケットペイロードを処理できなければなりません。受信機はALCヘッダを処理できない場合は、セッションから削除する必要があります。
To be able to participate in a session, a receiver MUST implement the multiple rate congestion control building block using the Congestion Control Information field provided in the LCT header. If a receiver is not able to implement the multiple rate congestion control building block it MUST NOT join the session.
セッションに参加できるようにするために、受信機は、LCTヘッダに設けられた輻輳制御情報フィールドを使用して複数のレート混雑制御ビルディングブロックを実装しなければなりません。受信機は、複数のレート混雑制御ビルディングブロックを実装することができない場合には、セッションに参加してはなりません。
Several objects can be carried either sequentially or concurrently within the same session. In this case, each object is identified by a unique TOI. Note that even if a sender stops sending packets for an old object before starting to transmit packets for a new object, both the network and the underlying protocol layers can cause some reordering of packets, especially when sent over different channels, and thus receivers SHOULD NOT assume that the reception of a packet for a new object means that there are no more packets in transit for the previous one, at least for some amount of time.
いくつかのオブジェクトは、同じセッション内のいずれかで、順次又は同時に行うことができます。この場合、各オブジェクトは、一意のTOIによって識別されます。送信者が新しいオブジェクトのためのパケットを送信するために開始する前に、古いオブジェクトのためのパケットの送信を停止した場合でも、ネットワークおよび基礎となるプロトコル層の両方が異なるチャネルを介して送信される場合は特に、パケットのいくつかの並べ替えを引き起こす可能性があり、したがって、受信機がないように注意してください新しいオブジェクトのためのパケットの受信が少なくともある程度の時間のために、一つ前の中継にはより多くのパケットが存在しないことを意味すると仮定する。
As described in Section 2.3, a receiver MUST obtain the required FEC Object Transmission Information for each object for which the receiver receives and processes packets.
セクション2.3で説明したように、受信機は、受信機が受信したパケットを処理するための各オブジェクトに必要なFECオブジェクト伝送情報を取得しなければなりません。
A receiver MAY concurrently join multiple ALC sessions from one or more senders. The receiver MUST perform congestion control on each such session. The receiver MAY make choices to optimize the packet flow performance across multiple sessions, as long as the receiver still adheres to the multiple rate congestion control building block for each session individually.
受信機は、同時に、1つまたは複数の送信者から複数のALCセッションに参加することができます。受信機は、このような各セッションに対して輻輳制御を実行しなければなりません。受信機は、受信機がまだ個別セッションごとに複数のレート混雑制御ビルディングブロックに付着する限り、複数のセッション間でパケットフローのパフォーマンスを最適化するための選択を行うことができます。
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. If multiple packets are received that cannot be parsed then the receiver SHOULD leave the session.
（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 that the receiver is currently joined to. If there is not a match then the packet MUST be discarded without further processing. If multiple packets are received with non-matching (sender IP address, TSI) values then the receiver SHOULD leave the session. If the receiver is joined to multiple ALC sessions then the remainder of the steps are performed within the scope of the (sender IP address, TSI) session of the received packet.
（2）受信機が共にヘッダで運ばTSIと送信元IPアドレスのいずれかと一致することを確認しなければならない（送信元IPアドレスを、TSI）受信セッション記述に、その受信されたペアは、現在に接合されています。一致しない場合、パケットは、さらなる処理なしで捨てなければなりません。複数のパケットが非整合で受信された場合（送信元IPアドレス、TSI）値は、受信機がセッションを終了すべきです。受信機は、複数のALCセッションに参加している場合、ステップの残りは、受信したパケットの（送信元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 discard the packet and reduce its reception rate to a minimum before continuing to regulate its reception rate using the multiple rate congestion control.
パケット認証を使用することをお勧めします。パケット認証が使用される場合、受信機は、直ちに上記ステップ（3）に進む前に、パケットの信憑性を確認することをお勧めされています。即時のチェックが可能であり、パケットはチェックを失敗した場合、受信機は、パケットを破棄し、複数のレート輻輳制御を使用して、その受信レートを調整するために継続する前に、最小限にその受信レートを下げる必要がある場合。
Some packet authentication schemes such as TESLA [14] 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 discarded before step (5) above and reduce its reception rate to a minimum before continuing to regulate its reception rate using the multiple rate congestion control.
このようテスラ[14]などの一部のパケットの認証方式は、即時の真正性チェックを許可していません。この場合、受信機は、できるだけ早くパケットの正当性を確認する必要があり、パケットがチェックに失敗した場合、それはステップの前に捨てなければなりません（5）とその受信レートを調節するために続行する前に、最小限にその受信レートを下げます複数のレート輻輳制御を使用しました。
The same security consideration that apply to the LCT, FEC and the multiple rate congestion control building blocks also apply to ALC.
LCTに適用されるのと同じセキュリティの考慮事項は、FECと複数のレート混雑制御ビルディングブロックはまた、ALCに適用されます。
Because of the use of FEC, 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.
そのためFECの使用のため、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 FEC 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. Although there is currently no IETF standard that specifies how to do multicast packet level authentication, TESLA [14] is a known multicast packet authentication scheme that would work.
パケットレベルでは、パケットレベルの認証は、各受信パケットが指定された送信者から到着するオブジェクトのためのFECデータを含む真正と破損していないパケットであることを確実にするために使用することを推奨されています。パケットレベルの認証が破損または偽造パケットが個別に廃棄することができ、受信された認証パケットが正確にオブジェクトを再構成するために使用することができるという利点を有します。したがって、偽造パケットを注入するサービス拒否攻撃の影響は、偽造パケットの数にではなく、オブジェクトのサイズに比例します。マルチキャストパケットレベルの認証を行う方法を指定する一切IETF標準は現在ありませんが、テスラ[14]は働くだろう既知のマルチキャストパケットの認証方式です。
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. TESLA [14] 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 [14]また、このような攻撃によって引き起こされる損傷を制限するために、ある程度使用することができます。しかし、TESLAと受信機は、それが受信された後、パケットが真正数秒であり、受信機は、セッションの受信速度を遅くするために反応することができる前に、輻輳制御プロトコルに対するこのような攻撃は、数秒間有効であることができるかどうかを決定することができます。
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.
逆方向パス転送チェックがマルチキャストツリーデータパスに偽造パケットを注入悪い薬剤の可能性を制限するために受信機に送信者からのパスに沿ってすべてのネットワークルータとスイッチで有効にされるべきです。
A receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect health of the network in the path between the sender and the receiver, and may also affect the reception rates of other receivers joined to the session. It is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the Session Description needed to join the session. How receivers identify themselves as legitimate is outside the scope of this document.
複数レート輻輳制御構築ブロックの誤ったまたは破損実装と受信機は、送信機と受信機との間の経路内のネットワークの健康に影響を与えることができ、また、他の受信機の受信レートに影響を与える可能性があるセッションに参加しました。したがって、受信機は、彼らがセッションに参加するために必要なセッション記述を受ける前に、正当として自分自身を識別するために要求されることが推奨されます。どのように受信機が正当として自分自身を識別することは、この文書の範囲外です。
Another vulnerability of ALC is the potential of receivers obtaining an incorrect Session Description for the session. The consequences of this could be that legitimate receivers with the wrong Session Description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate Session Descriptions from authorized senders. How this is done is outside the scope of this document.
ALCのもう一つの脆弱性は、セッションのために間違ったセッション記述を取得する受信機の可能性です。これの結果は、間違ったセッション記述を持つ、正当な受信機が正しくセッションコンテンツを受信することができない、または受信機が誤って、それによってネットワークの一部でトラフィックを中断、彼らがすることができるよりもはるかに高いレートで受信しようということである可能性があります。これらの問題を回避するために、対策は受信機が唯一認可された送信者からの正当なセッションの説明を受け入れることを確認するために、ソースの認証を使用することにより、例えば、間違ったセッションの説明を受け入れることから、レシーバを防ぐために取られることが推奨されます。これはどのように行われ、この文書の範囲外です。
No information in this specification is directly subject to IANA registration. However, building blocks components used by ALC may introduce additional IANA considerations. In particular, the FEC building block used by ALC does require IANA registration of the FEC codecs used.
本明細書中の情報は、IANA登録に直接の対象ではありません。しかし、ALCによって使用されるビルディングブロックコンポーネントは、追加のIANAの考慮を導入することができます。特に、ALCによって使用されるFECビルディングブロックを使用FECコーデックのIANA登録が必要です。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
Thanks to Vincent Roca, Justin Chapweske and Roger Kermode for their detailed comments on this document.
このドキュメントの彼らの詳細なコメントについてヴィンセントロカ、ジャスティンChapweskeとロジャーKermodeに感謝します。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[3]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, January 1997.
[4]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616、1997年1月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[6]ハンドレー、M.、パーキンス、C.およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[7] Holbrook, H. W., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[7]ホルブルック、H. W.、 "マルチキャスト用Aチャネルモデル"、博士論文、スタンフォード大学、コンピュータサイエンス学部、スタンフォード大学、カリフォルニア州、2001年8月。
[8] Kermode, R., Vicisano, L., "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[8]、RFC 3269、2002年4月Kermode、R.、Vicisano、L.、 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書の作者のガイドライン"。
[9] 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.
[9]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（FEC）の使用"、RFC 3453、 2002年12月。
[10] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[10]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 3452、2002年12月。
[11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451 December 2002.
[11]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "階層化符号化トランスポート（LCT）ビルディングブロック"、RFC 3451 2002年12月。
[12] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[12]マンキン、A.、Romanow、A.、RFC 2357、1998年6月ブラドナー、S.およびV.パクソン、 "信頼できるマルチキャストトランスポート及びアプリケーションプロトコルを評価するためのIETF基準"。
[13] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[13]村田、M.、St.Laurent、S.およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[14] Perrig, A., Canetti, R., Song, D. and J.D. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[14] Perrig、A.、カネッティ、R.、歌、D.およびJ.D. Tygar、 "マルチキャストのための効率的で安全なソース認証"、ネットワークと分散システムセキュリティシンポジウム、NDSS 2001、頁35-46、2001年2月。
[15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[15]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[16] 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.
[16] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.及びM.ルビー、 "一対多バルクデータ転送のための信頼できるマルチキャストトランスポート・ビルディング・ブロック"、 RFC 3048、2001年1月。
Authors' Addresses
著者のアドレス
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA, USA, 94538
マイケル・ルビーデジタル噴水39141シビックセンター博士スイート300フリーモント、CA、USA、94538
EMail: luby@digitalfountain.com
メールアドレス：luby@digitalfountain.com
Jim Gemmell Microsoft Research 455 Market St. #1690 San Francisco, CA, 94105
ジム・Gemmellマイクロソフトリサーチ455市場セント＃1690サンフランシスコ、CA、94105
EMail: jgemmell@microsoft.com
メールアドレス：jgemmell@microsoft.com
Lorenzo Vicisano cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA, USA, 95134
ロレンツォVicisanoシスコシステムズ株式会社170西タスマン博士サンノゼ、CA、USA、95134
EMail: lorenzo@cisco.com
メールアドレス：lorenzo@cisco.com
Luigi Rizzo Dip. Ing. dell'Informazione, Univ. di Pisa via Diotisalvi 2, 56126 Pisa, Italy
ルイジ・リゾディップ。のIng。情報工学大学ピサディオーティソルビ2、56126ピサ、イタリア経由
EMail: luigi@iet.unipi.it
メールアドレス：luigi@iet.unipi.it
Jon Crowcroft Marconi Professor of Communications Systems University of Cambridge Computer Laboratory William Gates Building J J Thomson Avenue Cambridge CB3 0FD, UK
ケンブリッジの通信システム大学のコンピュータ研究所のウィリアム・ゲイツビルJ JトムソンアベニューケンブリッジCB3 0FD、英国のジョン・クロークロフトマルコーニ教授
EMail: Jon.Crowcroft@cl.cam.ac.uk
メールアドレス：Jon.Crowcroft@cl.cam.ac.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。