[要約] RFC 3450は、非同期層状コーディング（ALC）プロトコルのインスタンス化に関する情報を提供する。目的は、ALCプロトコルの実装と使用に関するガイドラインを提供し、効果的なデータ転送を実現することである。
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
非同期層コーディング（ALC）プロトコルインスタンス化
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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の製品であり、RFC 3269 [8]で提供される一般的なガイドラインに従います。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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提案標準として再提出することは、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.
プッシュモデルとは、選択したレシーバーへのオブジェクトの同時配信を開始した送信者です。プッシュサービスモデルは、たとえば、100 GBファイルなどの大きなオブジェクトの信頼できる配信に使用できます。送信者はセッションの説明アナウンスをコントロールチャネルに送信することができ、受信機はこのチャネルを監視し、関心のセッションの説明が到着するたびにセッションに参加できます。セッションの説明を受け取ると、各レシーバーはセッションに参加して、オブジェクトを再構築するのに十分なパケットが到着するまでパケットを受け取ることができました。送信者は、すべてのレシーバーが再構成の成功を報告するか、他の条件が満たされるまで、オブジェクトのパケットをセッションに送信し続けることを決定できます。この例では、送信者は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がプッシュモデルをサポートするために提供するいくつかの機能があります。たとえば、送信者はオプションでパケットヘッダーに予想残差時間（ERT）を含めることができます。これには、セッション内に運ばれた単一オブジェクトまたは伝送オブジェクト識別子（TOI）によって識別されたオブジェクトのいずれかのパケット伝送の予想残留時間を示すことができます。セッションに運ばれた複数のオブジェクトがある場合。これは、セッションに十分な時間が残っているかどうかを判断するために、オブジェクトを回復するのに十分な追加パケットを正常に受信するのに十分な時間があるかどうかを判断することができます。たとえば、十分な時間がない場合、プッシュアプリケーションは受信機に送信者に報告して、オブジェクトを再構築するのに十分なパケットを取得できるように、オブジェクトのパケットの送信を十分な時間拡張させる可能性があります。送信者は、オブジェクトの各後続のパケットヘッダーの拡張オブジェクト伝送時間に基づいて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.
プッシュモデルは、衛星ネットワークとワイヤレスネットワークで特に魅力的です。これらの環境では、セッションには1つのチャネルが含まれる場合があり、送信者はこのチャネルに固定金利でパケットを送信できますが、混雑制御なしで固定レートで送信することは、このドキュメントの範囲外です。
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.
オンデマンドコンテンツ配信サービスモデルの場合、送信者は通常、意図したすべての受信機がセッションに参加して単一のオブジェクトを回復できるように十分な長さであると選択された特定の期間を送信します。たとえば、人気のあるソフトウェアの更新は、ALCを使用して数日間送信される場合がありますが、受信機は接続時間の合計1時間でダウンロードを完了することができ、おそらく数回の時間間隔で広がる可能性があります。この場合、受信機はアクティブな時点でセッションに参加します。受信者は、オブジェクトを回復するのに十分なパケットを受け取ったときにセッションを去ります。たとえば、受信機は、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 送信者にとって、セッションに1人のレシーバーが結合されたり、100万（または任意の数の）レシーバーがセッションに参加している場合、レシーバーが参加して出発した場合とは無関係に、負荷または発信率に違いはありません。
o No feedback packets are required from receivers to the sender.
o 受信者から送信者までのフィードバックパケットは必要ありません。
o Almost all packets in the session that pass through a bottleneck link are utilized by downstream receivers, and the session shares the link with competing flows fairly in proportion to their utility.
o ボトルネックリンクを通過するセッション内のほとんどすべてのパケットは、ダウンストリームレシーバーによって使用され、セッションはユーティリティに比例して競合するフローとリンクを共有します。
Thus, ALC provides a massively scalable content delivery transport that is network friendly.
したがって、ALCは、ネットワークに優しい非常にスケーラブルなコンテンツ配信トランスポートを提供します。
ALC intentionally omits any application specific features that could potentially limit its scalability. By doing so, ALC provides a minimal protocol that is massively scalable. Applications may be built on top of ALC to provide additional features that may limit the scalability of the application. Such applications are outside the scope of this document.
ALCは、スケーラビリティを制限する可能性のあるアプリケーション固有の機能を意図的に省略します。そうすることで、ALCは非常にスケーラブルな最小限のプロトコルを提供します。アプリケーションをALCの上に構築して、アプリケーションのスケーラビリティを制限する可能性のある追加機能を提供することができます。このようなアプリケーションは、このドキュメントの範囲外です。
All of the environmental requirements and considerations that apply to the LCT building block [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アドレスによってスコープされ、送信者のIPアドレスはTSIと一緒にセッションを一意に識別します。したがって、送信者のIPアドレスとその送信者からのセッションのTSIに基づいて、非gultiplexingを行う必要があります。
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マルチキャストネットワークまたは輸送サービスで使用されると推定されます。現在、RFC 1112 [3]で定義されている任意のソースマルチキャスト（ASM）モデルと、[7]で定義されているソース固有のマルチキャスト（SSM）モデル、マルチキャスト配信の2つのモデルがあります。ALCは両方のマルチキャストモデルで動作しますが、やや異なる方法で環境上の懸念が異なります。ASMを使用する場合、送信者SはマルチキャストグループGにパケットを送信し、ALCチャネルアドレスはペア（s、g）で構成されます。ここで、sは送信者のIPアドレスであり、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マルチキャストグループアドレスを一意に選択する必要があります。これにより、ALCチャネルアドレスの割り当てがASMでより困難になります。
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つの懸念を引き起こします。チャネルへの結合が送信されたときと最初のパケットが到着したときの時間差は、Rendezvousポイント（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.
Packetの一部が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は、RFC 2357 [12]に準拠した複数のレートの混雑制御ビルディングブロックを使用して、フィードバックを含まない渋滞制御を提供します。受信者は、セッションに関連付けられたチャネルに参加および離れることにより、レセプション率を個別に調整します。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.
ALCのセッションの定義は、LCTと同じです。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マルチキャストネットワークサービスで使用するように設計されています。この仕様では、ALCは、パケットのIPマルチキャスト配信をサポートするUDPトランスポートプロトコル[15]のペイロードとして定義しています。この仕様の将来のバージョンまたはコンパニオンドキュメントは、ALCを拡張してIPネットワークレイヤーサービスを直接使用する場合があります。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 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].
ALCパケットヘッダーはすぐにUDPヘッダーに続き、[11]で説明されているデフォルトのLCTヘッダーで構成され、[10]で説明されているFECペイロードIDが続きます。LCTヘッダー内の混雑制御情報フィールドには、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）フィールドが含まれています。LCTヘッダーには、CCIフィールドの長さを指定するフィールドがあり、複数レートの混雑制御ビルディングブロックは、この長さに対応するCCIフィールドの形式を一意に識別する必要があります。
The LCT header contains a Codepoint field that MAY be used to communicate to a receiver the settings for information that may vary during a session. If used, the mapping between settings and Codepoint values is to be communicated in the Session Description, and this mapping is outside the scope of this document. For example, the FEC Encoding ID that is part of the FEC Object Transmission Information as specified in the FEC building block [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ヘッダーには、セッション中に異なる可能性のある情報の設定を受信者と通信するために使用できるCodePointフィールドが含まれています。使用すると、設定とCodePoint値の間のマッピングはセッションの説明で通知され、このマッピングはこのドキュメントの範囲外です。たとえば、FECビルディングブロック[10]で指定されているFECオブジェクトトランスミッション情報の一部であるFECエンコードIDは、セッションで携帯されている各オブジェクトごとに異なる可能性があり、CodePoint値を使用してFECエンコードIDを通知できます。各オブジェクトに使用されます。FECエンコードIDとCodePointの間のマッピングは、たとえば、IDマッピングである可能性があります。
If more than one object is to be carried within a session then the Transmission Object Identifier (TOI) MUST be used in the LCT header to identify which packets are to be associated with which objects. In this case the receiver MUST use the TOI to associate received packets with objects. The TOI is scoped by the IP address of the sender and the TSI, i.e., the TOI is scoped by the session. The TOI for each object is REQUIRED to be unique within a session, but 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.
セッション内で複数のオブジェクトを携帯する場合は、LCTヘッダーで送信オブジェクト識別子（TOI）を使用して、どのパケットがどのオブジェクトに関連付けられるかを識別する必要があります。この場合、受信者はTOIを使用して、受信したパケットをオブジェクトに関連付ける必要があります。TOIは、送信者のIPアドレスとTSI、つまりTOIがセッションによってスコープされます。各オブジェクトのTOIは、セッション内で一意である必要がありますが、セッション全体で一意ではない場合があります。さらに、同じオブジェクトが異なるセッションで異なるTOIを持っている可能性があります。TOIとセッションで運ばれるオブジェクトの間のマッピングは、このドキュメントの範囲外です。
If only one object is carried within a session then the TOI MAY be omitted from the LCT header.
セッション内で1つのオブジェクトのみが運ばれる場合、TOIはLCTヘッダーから省略できます。
The 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の長さの1つに対応する必要があります。この長さは、セッションに送信されたすべてのパケットで同じでなければなりません。また、複数レートの輻輳制御ビルディングブロックで指定されている長さに対応するCCI形式は、LCTヘッダーのCCIフィールドに使用される形式でなければなりません。
When using a multiple rate congestion control building block a sender sends packets in the session to several channels at potentially different rates. Then, individual receivers adjust their reception rate within a session by adjusting 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ビルディングブロックに準拠した形式のFECペイロードIDを含める必要があります[10]。FECペイロードIDは、各パケットのペイロードを構成するエンコーディングシンボルを一意に識別し、受信者はFECペイロードIDを使用して、Packetのペイロードに掲載されたエンコードシンボルがFECビルディングで説明されているようにオブジェクトから生成された方法を決定する必要があります。ブロック。
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.
o FECエンコーディングID。
o If an Under-Specified FEC Encoding ID is used then the FEC Instance ID associated with the FEC Encoding ID.
o 不足しているFECエンコードIDが使用される場合、FECエンコードIDに関連付けられたFECインスタンスID。
o For each object in the session, the 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.
o FECビルディングブロックで規定されているFECエンコードIDの追加の必要なFECオブジェクト伝送情報[10]。たとえば、FECエンコーディングIDの場合、必要な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オブジェクト伝送情報は、オブジェクトの時間パケットがセッションから受信されるか、または前に受信機に動的に通信することができます。これは、CodePointフィールドまたはヘッダー拡張機能、またはこれらの方法の任意の組み合わせを使用して、帯域外のメカニズム、帯域内の帯域を使用して達成できます。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;
o 送信者IPアドレス。
o The number of channels in the session;
o セッション内のチャネルの数。
o The address and port number used for each channel in the session;
o セッション内の各チャネルに使用されるアドレスとポート番号。
o The Transport Session ID (TSI) to be used for the session;
o セッションに使用されるトランスポートセッションID（TSI）。
o An indication of whether or not the session carries packets for more than one object;
o セッションが複数のオブジェクトのパケットを搭載しているかどうかの兆候。
o If Header Extensions are to be used, the format of these Header Extensions.
o ヘッダー拡張機能を使用する場合、これらのヘッダー拡張機能の形式。
o Enough information to determine the packet authentication scheme being used, if 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部分内のCodePointフィールドを使用して、セッション内で動的に変化する情報の一部を帯域内に通信できます。これを行うには、CodePoint値とさまざまな動的設定の間のマッピングをセッションの説明に含める必要があり、使用する設定は各パケットに配置されたCodePoint値を介して通知されます。たとえば、同じセッション内で複数のオブジェクトが配信され、異なるタイプのオブジェクトに異なるFECエンコードアルゴリズムが使用される可能性があります。次に、セッションの説明には、CodePoint値とFECエンコードIDの間のマッピングが含まれます。別の例として、セッションに送信されるさまざまなパケットに別のパケット認証スキームが使用される可能性があります。この場合、パケット認証スキームとCodePoint値の間のマッピングをセッションの説明で提供できます。設定の組み合わせは、CodePoint値にもマッピングできます。たとえば、FECエンコーディングIDとパケット認証スキームの特定の組み合わせは、CodePoint値に関連付けられている可能性があります。
The Session Description could also include, but is not limited to:
セッションの説明には含めることもできますが、以下に限定されません。
o The mappings between combinations of settings and Codepoint values;
o 設定の組み合わせとCodePoint値の間のマッピング。
o The data rates used for each channel;
o 各チャネルに使用されるデータレート。
o The length of the packet payload;
o パケットペイロードの長さ。
o Any information that is relevant to each object being transported, such as the Object Transmission Information for each object, when the object will be available within the session and for how long.
o 各オブジェクトのオブジェクト伝送情報、セッション内でオブジェクトが利用可能になる場合、どのくらいの期間、輸送される各オブジェクトに関連する情報。
The Session Description could be in a form such as 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 2327 [5]で定義されているSDP、RFC 3023 [13]で定義されているXMLメタデータ、またはRFC 2068 [4]などで定義されているHTTP/MIMEヘッダーなどの形式である可能性があります。RFC 2974 [6]で定義されている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が使用するパケット形式は、UDPヘッダーに続いてデフォルトのLCTヘッダーが続いてFECペイロードIDが続き、パケットペイロードが続きます。デフォルトの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のバージョン番号は1です。これは、この仕様で使用されているLCTビルディングブロック[11]のバージョン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パケット形式を図1に示します。パケットはIPv4またはIPv6のいずれかのIPパケットであり、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ビット単語、残りは次の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番目のバイトの長さフィールドで指定されているさまざまなサイズです。すべての整数フィールドは、「ビッグエンディアン」または「ネットワーク注文」形式で運ばれます。つまり、最も重要なバイト（オクテット）です。「パディング」または「予約済み」（R）として指定されたビットは、送信者によって0に設定され、受信機によって無視される必要があります。特に明記しない限り、この仕様の数値定数は10進数です（ベース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.
ALCバージョン番号を示します。この仕様のALCバージョン番号は1です。これはLCTバージョン番号でもあります。
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.
複数のレートの混雑制御ビルディングブロックによって指定された輻輳制御情報（CCI）フィールドの長さは32ビットの倍数です。複数レートの輻輳制御ビルディングブロックは、CCIの形式を指定する必要があります。混雑制御ビルディングブロックは、可能な長さのセットが32、64、96、または128ビットであるさまざまなCCI長の形式を指定する場合があります。Cの値は、輻輳制御ビルディングブロックの可能な形式の1つの長さと一致する必要があり、この形式はCCIフィールドに使用する必要があります。Cの値は、セッションに送信されるすべてのパケットで同じでなければなりません。
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
トランスポートセッション識別子フラグ：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.
これは、TSIフィールドの完全な32ビット語の数です。TSIフィールドの長さは32*s 16*hビットです。ALCの場合、TSIフィールドの長さはゼロ以外である必要があります。これは、設定s = 0およびh = 0を使用してはならないことを意味します。
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.
これは、TOIフィールドの32ビットの完全な単語の数です。TOIフィールドの長さは32*o 16*hビットです。セッションで複数のオブジェクトを配信する場合、TOIを使用する必要があります。その場合、設定o = 0とh = 0を使用してはなりません。
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.
TSIとTOIフィールドは、どちらも32ビットと長さ16*hビットの倍数です。これにより、TSIおよびTOIフィールドの長さを半ワード（16ビット）の倍数にすることができ、TSIフィールドとTOIフィールドの総長が32ビットの倍数であることを保証します。
In the example H=0 which indicates that both TSI and TOI are both multiples of 32-bits in length.
例H = 0では、TSIとTOIの両方が両方とも長さ32ビットの倍数であることを示しています。
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.
t = 0は、送信者現在の時間（SCT）フィールドが存在しないことを示します。t = 1は、SCTフィールドが存在することを示します。SCTは送信者によって挿入され、セッションが進行中の期間レシーバーに示されます。
In the example T=1, which indicates that the SCT is carried in this packet.
例t = 1では、SCTがこのパケットで運ばれていることを示しています。
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.
R = 0は、予想される残差時間（ERT）フィールドが存在しないことを示します。R = 1は、ERTフィールドが存在することを示します。
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.
r = 0の例では、このパケットにERTが運ばれないことを示します。
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.
通常、Aは0に設定されています。Senderは、セッションのパケットの送信の終了が差し迫っているときにAを1に設定できます。Aは、セッション用に送信された最後のパケットのみで1に設定されるか、セッション用に送信された最後の数秒で1に設定できます。送信者が1つのパケットを1つに1に設定すると、送信者はセッションのパケットの送信が終了するまで、後続のすべてのパケットで1にAを設定する必要があります。セットが1にある受信パケットは、受信者に、送信者がセッションのパケットの送信をすぐに停止することを示します。受信者が1にセットを備えたパケットを受信すると、受信機はこれ以上パケットがセッションに送信されないと想定する必要があります。
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.
通常、Bは0に設定されています。送信者は、オブジェクトのパケットの送信の終了が差し迫っているときにBを1に設定できます。TOIフィールドが使用されており、Bが1に設定されている場合、TOIフィールドによって識別されるオブジェクトの伝送の終了が差し迫っています。TOIフィールドが使用されておらず、Bが1に設定されている場合、帯域外情報によって識別されるセッション内の1つのオブジェクトの送信の終了が差し迫っています。bは、オブジェクトに送信された最後のパケットのみで1に設定されます。または、オブジェクト用に送信された最後の数秒のパケットでBを1に設定できます。送信者が特定のオブジェクトの1つのパケットにBを1つに設定すると、送信者はオブジェクトのパケットの送信を終了するまで、オブジェクトの後続のすべてのパケットでBにBを設定する必要があります。Bを1に設定した受信パケットは、受信者に、送信者がオブジェクトのパケットの送信をすぐに停止することを示します。レシーバーがBを1に設定したパケットを受信した場合、セッションにオブジェクトのパケットが送信されないと仮定する必要があります。
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.
32ビット語の単位単位でのLCTヘッダーの全長。LCTヘッダーの長さは、32ビットの倍数でなければなりません。このフィールドを使用して、LCTヘッダーを超えてパケットの部分、つまりパケットにペイロードが含まれている場合はFECペイロードID、またはパケットにペイロードが含まれていない場合はパケットの最後に直接アクセスできます。
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
CodePoint（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.
このフィールドは、ALCによって使用されて、セッション内で変更できるセッション説明の一部の設定を識別するマッピングを伝達します。CodePoint値とセッション説明の一部の設定との間のマッピングは、帯域外に通知されます。
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マッピングはCodePoint値とFECエンコードIDの間で使用されます。したがって、CP = 128は、FECビルディングブロック[10]で説明されているように、FECを識別します。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.
TSIは、特定の送信者からのすべてのセッション間でセッションを一意に識別します。TSIは送信者IPアドレスによってスコープされているため、（送信者IPアドレス、TSI）ペアがセッションを一意に識別します。ALCの場合、TSIはLCTヘッダーに含める必要があります。
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つのセッションが重複するチャネルセットを使用しているとします。この送信者のアクティビティ中に接続して最初のセッションに接続したままでいるレシーバーは、2つのセッションのTSIが同一である場合、最初のセッションに属する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.
このフィールドは、このパケットが関係するセッション内のオブジェクトを示します。たとえば、送信者は同じセッションで多くのファイルを送信する場合があり、最初のファイルにTOI = 0、2番目のファイルでTOI = 1などを使用します。別の例として、TOIはオブジェクトの一意のグローバル識別子である場合がありますそれは複数の送信者から同時に送信されており、TOI値はオブジェクトに適用されるハッシュ関数の出力である可能性があります。ObjectsへのTOIフィールド値のマッピングは、このドキュメントの範囲外であり、帯域外で行われます。TOIフィールドは、セッションで複数のオブジェクトを送信する場合、つまりTOIフィールドがセッションのすべてのパケットに存在するか、存在しない場合、すべてのパケットで使用する必要があります。
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
Sender Current Time（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.
このフィールドは、このパケットが送信された時点での送信者の現在のクロックを表し、1MSの単位で測定し、セッションの開始時から計算されたmodulo 2^32ユニットです。
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.
このフィールドは、セッションで運ばれた単一のオブジェクトまたはセッションに運ばれた複数のオブジェクトがある場合、TOIによって識別されるオブジェクトのいずれかの場合、パケットの予想される予想される残留送信時間を表します。
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.
FECペイロードIDの長さと形式は、FECビルディングブロック[10]で説明されているように、FECエンコードIDに依存します。FECペイロードID形式は、セッションの説明で通信する必要があるFECエンコードIDによって決定されます。セッションの説明では、セッションで複数のFECエンコードIDが使用されていることを指定する場合があります。この場合、セッションの説明には、FECエンコードIDに対応するCodePoint値を識別するマッピングを含める必要があります。このマッピングは、使用すると、このドキュメントの範囲外です。
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コード」の形式に対応します。合計で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.
ソースブロック番号は、ペイロード内のエンコードシンボルが生成されるオブジェクトのソースブロックを識別します。これらのブロックには、0からn-1まで連続して番号が付けられ、nはオブジェクト内のソースブロックの数です。
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は、ソースブロックから生成された特定のエンコードシンボルがパケットペイロード内で運ばれるかを識別します。エンコードシンボルIDとパケットペイロードのエンコードシンボルとの対応の正確な詳細は、FECエンコードIDとFECインスタンスIDによって識別される特定のエンコードアルゴリズムに依存します。
Encoding Symbol(s): Y bits
エンコードシンボル：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.
エンコーディングシンボルは、受信者がオブジェクトを再構築するために使用するものです。パケット内のエンコードシンボルの総長さyは、受信したパケットの全長を計算し、ヘッダーの長さを減算することにより、パケットの受信機によって決定できます。
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.
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つの形式があります。最初の形式は、0〜127の間のヘッダー拡張型（HET）値を持つ可変長拡張機能に使用されます。2番目の形式は、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.
ヘッダー拡張機能のタイプ。このドキュメントでは、可能な多くのタイプを定義します。追加のタイプは、この仕様の将来のバージョンで定義できます。0〜127のHET値は、可変長ヘッダー拡張に使用されます。128〜255のHET値は、固定長32ビットヘッダー拡張機能に使用されます。
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).
ヘッダー拡張フィールド全体の長さは、32ビット語の倍数で表されます。このフィールドは、可変長拡張機能（0〜127の間）に存在する必要があり、固定長拡張（128〜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.
ヘッダー拡張機能の内容。このサブフィールドの形式は、ヘッダー拡張タイプに依存します。固定長ヘッダー拡張機能の場合、HECは24ビットです。可変長ヘッダー拡張機能の場合、HECフィールドは、HELフィールドで指定されているように、可変サイズです。各ヘッダー拡張フィールドの長さは、32ビットの倍数でなければならないことに注意してください。また、すべてのヘッダー拡張機能とすべてのオプションのヘッダーフィールドを含むLCTヘッダーの合計サイズは、255 32ビット単語を超えることはできないことに注意してください。
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固有）の間でさらに分割されます。一般的なLCT拡張機能には、範囲0:63および128：191が包括的である。PI固有の拡張機能は、範囲64：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.
送信者は、何らかの形のパケット認証を提供することをお勧めします。ext_authが存在する場合、パケットを受け入れ、混雑制御関連のアクションを実行する前に、パケットの受信後すぐに実行できるパケット認証チェックを実行する必要があります。一部のパケット認証スキームは、パケットが受信されたときとパケットが完全に認証されているときの間に数秒の遅延を課します。適切な混雑制御関連のアクションは、このような完全なパケット認証によって延期されてはなりません。
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.
ALCを使用する送信者は、セクション2.4で説明されているように、必要なセッションの説明を利用できるようにする必要があります。送信者は、セクション2.3で説明されているように、必要なFECオブジェクト伝送情報を利用可能にする必要があります。
Within a session a sender transmits a sequence of packets to the channels associated with the session. The ALC sender MUST obey the rules for filling in the CCI field in the packet headers and 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) 受信者は、セッションの説明で受信された（送信者IPアドレス、TSI）ペアの1つであるヘッダーマッチで送信されるTSIと一緒に送信者IPアドレスが一緒に、レシーバーが現在結合されていることを確認する必要があります。一致していない場合は、パケットをさらに処理せずに破棄する必要があります。非マッチング（送信者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) レシーバーは、他のヘッダーフィールドを適切に解釈するなど、残りのパケットを処理する必要があります。
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）を進める前に、受信者がパケットの信ity性を直ちに確認することをお勧めします。即時のチェックが可能で、パケットがチェックに障害が発生した場合、受信者はパケットを破棄し、複数レートの混雑制御を使用して受信率を調整し続ける前に、受信率を最小限に抑える必要があります。
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.
Tesla [14]などの一部のパケット認証スキームは、即時の信頼性チェックを許可していません。この場合、受信者はできるだけ早くパケットの信ity性をチェックし、パケットがチェックに障害が発生した場合、上記のステップ（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は、多くのレシーバーが同じ鍛造パケットを受け取る可能性があるため、このような攻撃の影響を特に受けます。このような攻撃から保護する方法は2つあります。1つはアプリケーションレベルとパケットレベルで1つあります。両方のレベルで予防を提供することをお勧めします。
At the application level, it is RECOMMENDED that an integrity check on the entire received object be done once the object is reconstructed to ensure it is the same as the sent object. Moreover, in order to obtain strong cryptographic integrity protection a digital signature verifiable by the receiver SHOULD be used to provide this application level integrity check. However, if even one corrupted or forged packet is used to reconstruct the object, it is likely that the received object will be reconstructed incorrectly. This will appropriately cause the integrity check to fail and in this case the inaccurately reconstructed object SHOULD be discarded. Thus, the acceptance of a single forged packet can be an effective denial of service attack for distributing objects, but an object integrity check at least prevents inadvertent use of inaccurately reconstructed objects. The specification of an application level integrity check of the received object is outside the scope of this document.
アプリケーションレベルでは、受信オブジェクト全体の整合性チェックを行うことをお勧めします。さらに、強力な暗号整合性保護を取得するには、受信機が検証可能なデジタル署名を使用して、このアプリケーションレベルの整合性チェックを提供する必要があります。ただし、オブジェクトを再構築するために破損したパケットまたは偽造パケットが1つさえ使用されている場合、受信オブジェクトが誤って再構築される可能性があります。これにより、整合性チェックが適切に失敗し、この場合、不正確に再構築されたオブジェクトを破棄する必要があります。したがって、単一の鍛造パケットの受け入れは、オブジェクトを配布するための効果的なサービス拒否攻撃になる可能性がありますが、オブジェクトの整合性チェックは、少なくとも不正確に再構築されたオブジェクトの不注意な使用を防ぎます。受信したオブジェクトのアプリケーションレベルの整合性チェックの仕様は、このドキュメントの範囲外です。
At the packet level, it is RECOMMENDED that a packet level authentication be used to ensure that each received packet is an authentic and uncorrupted packet containing 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標準はありませんが、Tesla [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のもう1つの脆弱性は、セッションのセッションの説明が誤っている可能性があることです。この結果、セッションの説明が間違っている正当な受信者がセッションコンテンツを正しく受信できないこと、または受信者が誤って能力よりもはるかに高いレートで受け取ることを試み、それによりネットワークの一部のトラフィックを破壊することです。これらの問題を回避するために、レシーバーが誤ったセッションの説明を受け入れるのを防ぐための措置を講じることをお勧めします。これがどのように行われるかは、このドキュメントの範囲外です。
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.
この文書に関する詳細なコメントをしてくれたVincent Roca、Justin Chapweske、Roger Kermodeに感謝します。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[3] Deering、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1997年1月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[6] Handley、M.、Perkins、C。and E. Whelan、「セッションアナウンスプロトコル」、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] Holbrook、H。W.、「マルチキャストのチャネルモデル」、博士号論文、スタンフォード大学、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] Kermode、R.、Vicisano、L。、「信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、2002年4月。
[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] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（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] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「フォワードエラー補正（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] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L.、Handley、M。and J. Crowcroft、「レイヤードコーディングトランスポート（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] Mankin、A.、Romanow、A.、Bradner、S。and V. Paxson、「信頼できるマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[13] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[13] Murata、M.、St.Laurent、S。およびD. Kohn、「XML Media Types」、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.、Canetti、R.、Song、D。and J.D. Tygar、「マルチキャストの効率的かつ安全なソース認証」、ネットワークおよび分散システムセキュリティシンポジウム、NDSS 2001、pp。35-46、2001年2月。
[15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[15] Postel、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.、Handley、M.、Floyd、S。、およびM. Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
Authors' Addresses
著者のアドレス
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA, USA, 94538
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont、CA、USA、94538
EMail: luby@digitalfountain.com
Jim Gemmell Microsoft Research 455 Market St. #1690 San Francisco, CA, 94105
Jim Gemmell Microsoft Research 455 Market St.＃1690 San Francisco、CA、94105
EMail: jgemmell@microsoft.com
Lorenzo Vicisano cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA, USA, 95134
Lorenzo Vicisano Cisco Systems、Inc。170 West Tasman Dr. San Jose、CA、USA、95134
EMail: lorenzo@cisco.com
Luigi Rizzo Dip. Ing. dell'Informazione, Univ. di Pisa via Diotisalvi 2, 56126 Pisa, Italy
Luigi Rizzo Dip。ing。Dell'informazione、大学ディオティサルヴィ2、56126イタリアのピサ経由のディピサ
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。