RFC3450 日本語訳
3450 Asynchronous Layered Coding (ALC) Protocol Instantiation. M.Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft. December 2002. (Format: TXT=86022 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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
Lubyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3450年のデジタル噴水カテゴリ: 実験的なJ.のL.VicisanoコクチマスL.リゾーGemmellマイクロソフト大学 ピサJ.クロウクロフトケンブリッジ大学 2002年12月
Asynchronous Layered Coding (ALC) Protocol Instantiation
非同期な層にされたコード化(ALC)プロトコル具体化
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントはAsynchronous Layered Coding(ALC)プロトコル、膨大にスケーラブルな信頼できる内容物配送プロトコルについて説明します。 混雑を供給するLayered Coding Transport(LCT)ブロック、倍数が混雑制御建家とForward Error Correction(FEC)ブロックを評定する非同期なLayered Codingコンバインは独身の送付者から無制限な数の同時発生の受信機に内容の信頼できる非同期な配送を制御しました。
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
1. 序論…2 1.1 デリバリ・サービスはモデル化されます…3 1.2スケーラビリティ…5 1.3の環境要求事項と問題…6 2. アーキテクチャ定義…8 2.1LCTブロック…9 2.2 複数のレート混雑制御建家…10 2.3FECブロック…11 2.4 セッション記述…13
Luby, et. al. Experimental [Page 1] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[1ページ]RFC3450ALCプロトコル具体化2002年12月
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
2.5パケット認証ブロック…14 3. 順応声明…14 4. 機能性定義…14 4.1 ALCによって使用されたパケット形式…15 4.2 ALCによって使用されたPacket形式の詳細なExample…16 4.3 ヘッダー拡大分野…23 4.4 送付者操作…26 4.5 受信機操作…27 5. セキュリティ問題…29 6. IANA問題…31 7. 知的所有権問題…31 8. 承認…31 9. 参照…31人の作者のアドレス…33 完全な著作権宣言文…34
1. Introduction
1. 序論
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.
このドキュメントは膨大にスケーラブルな信頼できる内容物配送プロトコルについて説明します、Asynchronous Layered Coding(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
オブジェクトに基づくパケットがセッション中に提供されて、適切にフォーマットされたパケットを送ることであると生成するのからALCの送付者側面は適切なレートでセッションに関連しているチャンネルに成ります。 そしてALCの受信機側面はセッションに関連している適切なチャンネルに加わるのから成ります、検出された混雑に対応してセッションに関連している接合チャンネルのセットを調整することによって輻輳制御を実行して。
Luby, et. al. Experimental [Page 2] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[2ページ]RFC3450ALCプロトコル具体化2002年12月
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 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は受信機によって必要とされたSession記述を指定しますが、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の製品であり、RFC3269[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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[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によると、Reliable Multicast Transportプロトコルを完全に指定するのに必要な定義の一部を含んでいます。 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.
そのような体系が利用可能であるか、または既存の体系が適切であると立証されるのを待っている間、Reliable Multicast Transportワーキンググループ(RMT)はCommentsのために「実験的な」カテゴリでこのRequestを発行します。
It is the intent of RMT to re-submit this specification as an IETF
Proposed Standard as soon as the above condition is met.
それは上記の状態の次第IETF Proposed Standardが会われるときRMTがこの仕様を再提出する意図です。
1.1 Delivery service models
1.1 デリバリ・サービスモデル
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
プッシュモデルは選択されたセットの受信機へのオブジェクトの送付者の開始している同時発生の配送です。 例えば、100GBのファイルなどの大きいオブジェクトの信頼できる配信にプッシュサービスモデルを使用できます。 送付者はSession記述発表をaに送ることができました。
Luby, et. al. Experimental [Page 3] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[3ページ]RFC3450ALCプロトコル具体化2002年12月
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.
興味があるSession記述が到着するときはいつも、制御チャンネルと受信機は、このチャンネルをモニターして、セッションに参加するかもしれません。 Session記述を受け取り次第、各受信機は十分なパケットがオブジェクトを再建するために到着するまでパケットを受けるためにセッションに参加するかもしれません、レセプションが首尾よく終了したという受信機が送付者に戻ると報告できたどのポイントで。 送付者は、すべての受信機がうまくいっている再建を報告するまでのセッションかある他の状態が満たされるまでオブジェクトのためにパケットを送り続けていると決めることができました。 この例では、送付者はオブジェクトに基づくパケットを生成して、セッションに関連しているチャンネルにパケットを送るのに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がプッシュモデルをサポートするために提供するいくつかの特徴があります。 例えば、送付者はセッションのときに運ばれた複数のオブジェクトがあれば単一のオブジェクトがセッションのときに運んだか、またはオブジェクトTransmission Object Identifierで特定したどちらか(TOI)のためにパケット伝送の予想された残っている時間を示すパケットのヘッダーで任意に、Expected Residual Time(ERT)を入れることができます。 これは受信機によって使用されて、セッションのときに首尾よくオブジェクトを回収できるくらいの追加パケットを受けるために残りながら、時間が十分あるかどうか決定できます。 例えば、十分な時間がなければ、プッシュアプリケーションで、受信機は受信機がオブジェクトを再建できるくらいのパケットを得るのを許容できるくらいの時間のオブジェクトのためにパケットのトランスミッションを広げると送付者に報告して戻るかもしれません。 そして、送付者はオブジェクトのためのそれぞれのその後のパケットのヘッダーで拡張対象トランスミッション時間に基づくERTを入れることができました。 他の例として、LCTヘッダーは任意にパケットをセッションに送りながら送付者がいつ終わろうとしているかを示すClose Session旗とTransmission Object IDによって特定されたオブジェクトのためのセッションにパケットを送りながら送付者がいつ終わろうとしているかを示すClose Object旗を含むことができます。 しかしながら、これらの旗は完全な信頼できるメカニズムであるというわけではありません、そして、その結果、セッションが終えられようとしている時に関するヒントとClose Object旗がオブジェクトのためのパケットのトランスミッションが終わろうとしている時に関するヒントとして使用されるだけであるべきであるとき、Close Session旗は使用されるだけであるべきです。
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個のチャンネルと送付者は定率でこのチャンネルにパケットを送るかもしれませんが、このドキュメントの範囲の外に定率で輻輳制御なしで発信するのがあります。
Luby, et. al. Experimental [Page 4] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[4ページ]RFC3450ALCプロトコル具体化2002年12月
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時間の合計におけるダウンロードを終了できて、恐らく時間のいくつかの間隔にわたって広げられるかもしれませんが。 この場合、受信機は時間内にのそれがアクティブである任意な点でのセッションのときに接合します。 受信機で、彼らが十分なパケットを受けたセッションはオブジェクトを回収します。 例えば、受信機は、ウェブサーバーに連絡することによって、Session記述を得ます。
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に結合されると、潜在的アプリケーション、適切なデリバリ・サービスモデル、およびそのような機能性をサポートする追加メカニズムの記述はこのドキュメントの範囲を超えています。
1.2 Scalability
1.2 スケーラビリティ
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 セッションにおけるボトルネックリンクを通り抜けるほとんどすべてのパケットが川下の受信機によって利用されます、そして、セッションはそれらのユーティリティに比例して競争している流れとのリンクを公正に共有します。
Luby, et. al. Experimental [Page 5] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[5ページ]RFC3450ALCプロトコル具体化2002年12月
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の上で組立てられるかもしれません。 このドキュメントの範囲の外にそのような利用があります。
1.3 Environmental Requirements and Considerations
1.3 環境要件と問題
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]、複数のレート混雑制御建家とALCが使用するどんな追加ブロックへのFECブロック[10]にも適用される環境要求事項と問題のすべてが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は、セッションとこのいくつかの実装に参加するとスケーラビリティが制限されるかもしれない前にバンドの外でSession記述を得るために受信機を必要とします。
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セッションにつながれるなら、正しいセッションまで受信機は唯一特定できて、「反-マルチプレックス」パケットであるに違いありません。 各パケットのヘッダーに現れなければならないTransmission Session Identifier(TSI)はこのために使用されます。 TSIはIP送信者のアドレスによって見られます、そして、TSIに伴うIP送信者のアドレスは唯一セッションを特定します。 したがって、IP送信者のアドレスとその送付者からのセッションのTSIに基づいて逆多重化をしなければなりません。
ALC is presumed to be used with an underlying IP multicast network or transport service that is a "best effort" service that does not guarantee packet reception, packet reception order, and which does not have any support for flow or congestion control. There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in RFC 1112 [3] and the Source-Specific Multicast (SSM) model as defined in [7]. ALC works with both multicast models, but in a slightly different way with somewhat different environmental concerns. When using ASM, a sender S sends packets to a multicast group G, and an ALC channel address consists of the pair (S,G), where S is the IP address of the sender and G is a
ALCはあえてパケットレセプション、パケット収容命令を保証しないで、また流れか輻輳制御の少しのサポートも持っていない「ベストエフォート型」のサービスである基本的なIPマルチキャストネットワークか輸送サービスと共に使用されます。 現在、マルチキャスト配送の2つのモデル、RFC1112[3]で定義されるAny-ソースMulticast(ASM)モデル、および[7]で定義されるSource特有のMulticast(SSM)モデルがあります。 ALCは両方のマルチキャストモデル、しかし、いくらか異なった環境問題があるわずかに異なった方法で働いています。 ASMを使用して、送付者SがマルチキャストグループGにパケットを送って、ALCチャンネル・アドレスが組(S、G)から成ると、SがどこのIP送信者のアドレスとGであるかはaです。
Luby, et. al. Experimental [Page 6] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[6ページ]RFC3450ALCプロトコル具体化2002年12月
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.
マルチキャストグループアドレス。 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チャンネル・アドレスを割り当てることができます、そして、これで、ALCチャンネル・アドレスの配分はSSMで簡単になります。 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の上に無視できないセキュリティ上の利点を持っています。 どちらの場合ではも、受信機SHOULDは、求められていないソースからパケットを無視するのにメカニズムを使用します。
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と対話する方法です。 混雑制御建家はaがaにつなぐ時の間のチャンネルを送って、チャンネルからの最初のパケットが受信機レセプション率を測定するのに到着する時代の間、測定違いを使用するかもしれません。 また、制御建家がそうする混雑は損失を測定するのに1チャンネルあたりのパケット一連番号を使用します、そして、また、これは、受信機レセプション率を測定するのに使用されます。 これらの特徴はASMに関して2回の関心を高めます: そして、間の時差、いつ、チャンネルを送って、最初のパケットがRendezvous Pointsの使用への重要な支払われるべきものが(RPs)とMSDPプロトコルであったかもしれないなら到着して、スイッチでパケットを失う場合があるaに接合するか、(*、G)がRPにつなぐ、(S、G)は直接送付者につなぎます。 これらの問題の両方が潜在的に実質的に受信機のレセプション率を下げるかもしれません。 これらの関心を改善するために、RPができるだけ送付者に近いのは、RECOMMENDEDです。 SSMはこれらの同じ関心を共有しません。 これらの問題の、よりふくよかな考慮には、複数のレート混雑制御建家に相談してください。
Some networks are not amenable to some congestion control protocols that could be used with ALC. In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session.
ネットワークの中にはALCと共に使用できたいくつかの混雑制御プロトコルに従順でないものもあります。 衛星かワイヤレス・ネットワークのために、セッションまで割り当てられた固定通信速度があるかもしれないので事実上、受信機がそれらのレセプション率を低下させるメカニズムは全く特にないかもしれません。
ALC is compatible with either IPv4 or IPv6 as no part of the packet is IP version specific.
パケットのどんな一部もIPバージョン特有でないときに、ALCはIPv4かIPv6のどちらかと互換性があります。
Luby, et. al. Experimental [Page 7] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[7ページ]RFC3450ALCプロトコル具体化2002年12月
2. Architecture Definition
2. アーキテクチャ定義
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は複数の無料でフィードバックである輻輳制御を提供するRFC2357[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セッションが独身の送付者に制限されるという事実は同じオブジェクトのために複数の送付者からパケットを受ける可能性を排除しません。 しかしながら、各送付者は輻輳制御が個別に適用されるa異なったセッションにパケットを送るでしょう。 同時に複数のセッションを受け取るのは許されていますが、このドキュメントの範囲の外にアプリケーションレベルでどうこれをするかがあります。
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はRFC3048[16]で定義されるようにプロトコル具体化です。 このドキュメントは[11]で説明されたLCTのバージョン1を使用しなければならないALCのバージョン1について説明します。 LCTのように、ALCは、IPマルチキャストネットワーク・サービスと共に使用されるように設計されています。 この仕様はIPマルチキャストパケットの配信をサポートするUDPトランスポート・プロトコル[15]のペイロードとALCを定義します。 この将来のバージョンは、直接IPネットワーク層サービスを利用するためにALCを広げるかもしれません仕様、または仲間が、ドキュメントである。 ユニキャストUDPなどの異なった基本的なネットワーク・サービスを使用するプロトコルを設計する基礎としてALCを使用できましたが、このドキュメントの範囲の外にそのようなプロトコルのデザインがあります。
An ALC packet header immediately follows the UDP header and consists of the default LCT header that is described in [11] followed by the FEC Payload ID that is described in [10]. The Congestion Control Information field within the LCT header carries the required
ALCパケットのヘッダーは、すぐに、UDPヘッダーについて来て、[10]で説明されるFEC Payload IDによって続かれた[11]で説明されるデフォルトLCTヘッダーから成ります。 LCTヘッダーの中のCongestion Control情報分野は必要を運びます。
Luby, et. al. Experimental [Page 8] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[8ページ]RFC3450ALCプロトコル具体化2002年12月
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].
指定された複数のRFC2357[12]で言いなりになっているレート混雑制御建家で説明される混雑Control情報。 ALCパケットのヘッダーに続くパケットペイロードは[10]で説明されるようにFEC Payload 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セッションに参加する前にSession記述を得るのに必要です。 後述のように、Session記述はバンドの外にLCT、FEC、および複数のレート混雑制御建家に必要である情報を含んでいます。 FECブロック[10]で指定されたFEC Object Transmission情報が各オブジェクトが受信機でバンドの外で受信機とコミュニケートできるか、またはバンドにHeader Extensionを使用することで受け取られるのが必要です。 このドキュメントの範囲の外にSession記述とFEC Object Transmission情報を受信機に伝えるための手段があります。
2.1 LCT building block
2.1 LCTブロック
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はこの要件を引き継いで、強化します。 Transport Session Identifier(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ヘッダーは指定された倍数レート混雑制御プロトコルからCongestion Control情報を運ぶのに使用しなければならないCongestion Control情報(CCI)分野を含んでいます。 分野がCCI分野の長さを指定するLCTヘッダーにあります、そして、複数のレート混雑制御建家が唯一この長さに対応するCCI分野の形式を特定しなければなりません。
The LCT header contains a Codepoint field that MAY be used to communicate to a receiver the settings for information that may vary during a session. If used, the mapping between settings and Codepoint values is to be communicated in the Session Description, and this mapping is outside the scope of this document. For example, the FEC Encoding ID that is part of the FEC Object Transmission Information as specified in the FEC building block [10] could vary for each object carried in the session, and the Codepoint value could be used to communicate the FEC Encoding ID to be used for each object. The mapping between FEC Encoding IDs and Codepoints could be, for example, the identity mapping.
LCTヘッダーはセッションの間に異なるかもしれない情報のために設定を受信機に伝えるのに使用されるかもしれないCodepoint分野を含んでいます。 使用されるなら、設定とCodepoint値の間のマッピングがSession記述でコミュニケートすることであり、このドキュメントの範囲の外にこのマッピングはあります。 例えば、FECブロック[10]における指定されるとしてのFEC Object Transmission情報の一部であるFEC Encoding IDはセッションのときに運ばれた各オブジェクトのために異なることができました、そして、各オブジェクトに使用されるためにFEC Encoding IDを伝えるのにCodepoint値は使用できました。 例えば、FEC Encoding IDとCodepointsの間のマッピングはアイデンティティマッピングであるかもしれません。
Luby, et. al. Experimental [Page 9] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[9ページ]RFC3450ALCプロトコル具体化2002年12月
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.
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.
If only one object is carried within a session then the TOI MAY be omitted from the LCT header.
If only one object is carried within a session then the TOI MAY be omitted from the LCT header.
The default LCT header from version 1 of the LCT building block [11] MUST be used.
The default LCT header from version 1 of the LCT building block [11] MUST be used.
2.2 Multiple rate congestion control building block
2.2 Multiple rate congestion control building block
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.
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.
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.
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.
Luby, et. al. Experimental [Page 10] RFC 3450 ALC protocol instantiation December 2002
Luby, et. al. Experimental [Page 10] RFC 3450 ALC protocol instantiation December 2002
2.3 FEC building block
2.3 FEC building block
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.
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.
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:
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:
o The FEC Encoding ID.
o The FEC Encoding ID.
o If an Under-Specified FEC Encoding ID is used then the FEC
Instance ID associated with the FEC Encoding ID.
o If an Under-Specified FEC Encoding ID is used then the FEC Instance ID associated with the FEC Encoding ID.
o For each object in the session, the length of the object in
bytes.
o For each object in the session, the length of the object in bytes.
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 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.
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.
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.
Luby, et. al. Experimental [Page 11] RFC 3450 ALC protocol instantiation December 2002
Luby, et. al. Experimental [Page 11] RFC 3450 ALC protocol instantiation December 2002
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.
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.
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.
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.
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.
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.
Luby, et. al. Experimental [Page 12] RFC 3450 ALC protocol instantiation December 2002
Luby, et. al. Experimental [Page 12] RFC 3450 ALC protocol instantiation December 2002
2.4 Session Description
2.4 Session Description
The Session Description that a receiver is REQUIRED to obtain before joining an ALC session MUST contain the following information:
The Session Description that a receiver is REQUIRED to obtain before joining an ALC session MUST contain the following information:
o The multiple rate congestion control building block to be used
for the session;
o The multiple rate congestion control building block to be used for the session;
o The sender IP address;
o The sender IP address;
o The number of channels in the session;
o The number of channels in the session;
o The address and port number used for each channel in the session;
o The address and port number used for each channel in the session;
o The Transport Session ID (TSI) to be used for the session;
o The Transport Session ID (TSI) to be used for the session;
o An indication of whether or not the session carries packets for
more than one object;
o An indication of whether or not the session carries packets for more than one object;
o If Header Extensions are to be used, the format of these Header
Extensions.
o If Header Extensions are to be used, the format of these Header Extensions.
o Enough information to determine the packet authentication scheme
being used, if it is being used.
o Enough information to determine the packet authentication scheme being used, if it is being used.
How the Session Description is communicated to receivers is outside the scope of this document.
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.
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.
Luby, et. al. Experimental [Page 13] RFC 3450 ALC protocol instantiation December 2002
Luby, et. al. Experimental [Page 13] RFC 3450 ALC protocol instantiation December 2002
The Session Description could also include, but is not limited to:
The Session Description could also include, but is not limited to:
o The mappings between combinations of settings and Codepoint
values;
o The mappings between combinations of settings and Codepoint values;
o The data rates used for each channel;
o The data rates used for each channel;
o The length of the packet payload;
o The length of the packet payload;
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 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.
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.
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.
2.5 Packet authentication building block
2.5 Packet authentication building block
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.
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.
3. Conformance Statement
3. Conformance Statement
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].
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].
4. Functionality Definition
4. Functionality Definition
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.
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.
Luby, et. al. Experimental [Page 14] RFC 3450 ALC protocol instantiation December 2002
Luby, et. al. Experimental [Page 14] RFC 3450 ALC protocol instantiation December 2002
4.1 Packet format used by ALC
4.1 Packet format used by 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.
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.
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.
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.
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].
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].
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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Figure 1 - Overall ALC packet format
Luby, et. al. Experimental [Page 15] RFC 3450 ALC protocol instantiation December 2002
Luby, et. al. Experimental [Page 15] RFC 3450 ALC protocol instantiation December 2002
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.
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.
4.2 Detailed Example of Packet format used by ALC
4.2 Detailed Example of Packet format used by ALC
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.
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.
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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Figure 2 - A detailed example of the ALC packet format
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).
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).
Luby, et. al. Experimental [Page 16] RFC 3450 ALC protocol instantiation December 2002
Luby, et. al. Experimental [Page 16] RFC 3450 ALC protocol instantiation December 2002
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.
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 version number (V): 4 bits
Indicates the ALC version number.
The ALC version number for this specification is 1 as shown.
This is also the LCT version number.
Indicates the ALC version number. The ALC version number for this specification is 1 as shown. This is also the LCT version number.
Congestion control flag (C): 2 bits
Congestion control flag (C): 2 bits
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.
The Congestion Control Information (CCI) field specified by the multiple rate congestion control building block is a multiple of 32-bits in length. The multiple rate congestion control building block MUST specify a format for the CCI. The congestion control building block MAY specify formats for different CCI lengths, where the set of possible lengths is 32, 64, 96 or 128 bits. The value of C MUST match the length of exactly one of the possible formats for the congestion control building block, and this format MUST be used for the CCI field. The value of C MUST be the same for all packets sent to a session.
C=0 indicates the 32-bit CCI field format is to be used.
C=1 indicates the 64-bit CCI field format is to be used.
C=2 indicates the 96-bit CCI field format is to be used.
C=3 indicates the 128-bit CCI field format is to be used.
C=0 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.
In the example C=0 indicates that a 32-bit format is to be
used.
In the example C=0 indicates that a 32-bit format is to be used.
Reserved (r): 2 bits
Reserved (r): 2 bits
Reserved for future use. A sender MUST set these bits to zero
and a receiver MUST ignore these bits.
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.
As required, these bits are set to 0 in the example.
Transport Session Identifier flag (S): 1 bit
Transport Session Identifier flag (S): 1 bit
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.
This is the number of full 32-bit words in the TSI field. The TSI field is 32*S + 16*H bits in length. For ALC the length of the TSI field is REQUIRED to be non-zero. This implies that the setting S=0 and H=0 MUST NOT be used.
In the example S=1 and H=0, and thus the TSI is 32-bits in
length.
In the example S=1 and H=0, and thus the TSI is 32-bits in length.
Luby, et. al. Experimental [Page 17] RFC 3450 ALC protocol instantiation December 2002
Luby, et. al. Experimental [Page 17] RFC 3450 ALC protocol instantiation December 2002
Transport Object Identifier flag (O): 2 bits
Transport Object Identifier flag (O): 2 bits
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.
This is the number of full 32-bit words in the TOI field. The TOI field is 32*O + 16*H bits in length. If more than one object is to be delivered in the session then the TOI MUST be used, in which case the setting O=0 and H=0 MUST NOT be used.
In the example O=1 and H=0, and thus the TOI is 32-bits in
length.
In the example O=1 and H=0, and thus the TOI is 32-bits in length.
Half-word flag (H): 1 bit
Half-word flag (H): 1 bit
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.
The TSI and the TOI fields are both multiples of 32-bits plus 16*H bits in length. This allows the TSI and TOI field lengths to be multiples of a half-word (16 bits), while ensuring that the aggregate length of the TSI and TOI fields is a multiple of 32-bits.
In the example H=0 which indicates that both TSI and TOI are
both multiples of 32-bits in length.
In the example H=0 which indicates that both TSI and TOI are both multiples of 32-bits in length.
Sender Current Time present flag (T): 1 bit
Sender Current Time present flag (T): 1 bit
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 indicates that the Sender Current Time (SCT) field is not present. T = 1 indicates that the SCT field is present. The SCT is inserted by senders to indicate to receivers how long the session has been in progress.
In the example T=1, which indicates that the SCT is carried in
this packet.
In the example T=1, which indicates that the SCT is carried in this packet.
Expected Residual Time present flag (R): 1 bit
Expected Residual Time present flag (R): 1 bit
R = 0 indicates that the Expected Residual Time (ERT) field is
not present.
R = 1 indicates that the ERT field is present.
R = 0 indicates that the Expected Residual Time (ERT) field is not present. R = 1 indicates that the ERT field is present.
The ERT is inserted by senders to indicate to receivers how
much longer packets will be sent to the session for either the
single object carried in the session or for the object
identified by the TOI if there are multiple objects carried in
the session. Senders MUST NOT set R = 1 when the ERT for the
object is more than 2^32-1 time units (approximately 49 days),
where time is measured in units of milliseconds.
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.
In the example R=0, which indicates that the ERT is not carried
in this packet.
In the example R=0, which indicates that the ERT is not carried in this packet.
Luby, et. al. Experimental [Page 18] RFC 3450 ALC protocol instantiation December 2002
Luby, et. al. Experimental [Page 18] RFC 3450 ALC protocol instantiation December 2002
Close Session flag (A): 1 bit
Close Session flag (A): 1 bit
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.
Normally, A is set to 0. The sender MAY set A to 1 when termination of transmission of packets for the session is imminent. A MAY be set to 1 in just the last packet transmitted for the session, or A MAY be set to 1 in the last few seconds of packets transmitted for the session. Once the sender sets A to 1 in one packet, the sender SHOULD set A to 1 in all subsequent packets until termination of transmission of packets for the session. A received packet with A set to 1 indicates to a receiver that the sender will immediately stop sending packets for the session. When a receiver receives a packet with A set to 1 the receiver SHOULD assume that no more packets will be sent to the session.
In the example A=0, and thus this packet does not indicate the
close of the session.
In the example A=0, and thus this packet does not indicate the close of the session.
Close Object flag (B): 1 bit
Close Object flag (B): 1 bit
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に設定されます。 オブジェクトのためのパケットのトランスミッションの終了が差し迫っているとき、送付者は1にBを設定するかもしれません。 TOI分野が使用中であり、Bが1に設定されるなら、TOI分野によって特定されたオブジェクトのためのトランスミッションの終了は差し迫っています。 TOI分野が使用中でなく、Bが1に設定されるなら、セッションにおける1個のオブジェクトがバンドの外による情報を特定したので、トランスミッションの終了は差し迫っています。 Bがまさしくオブジェクトのために伝えられた最後のパケットの1に設定されるかもしれませんか、またはBはパケットがオブジェクトのために伝えた最後の数秒で1に設定されるかもしれません。 一度、送付者は特定のオブジェクト(オブジェクトのためのパケットのトランスミッションの終了までのオブジェクトのためのすべてのその後のパケットの1への送付者SHOULDセットB)のために1つのパケットに1へのBをはめ込みます。 1に設定されたBがある容認されたパケットは、送付者が、すぐにオブジェクトのためにパケットを送るのを止めるのを受信機に示します。 受信機がBと共にパケットを受けたらそして1にそれを設定してください。SHOULDは、それ以上のパケットが全くオブジェクトのためにセッションに送られないと仮定します。
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
ユニットの32ビットの単語によるLCTヘッダーの全長。 LCTヘッダーの長さは32ビットの倍数であるに違いありません。 この分野はパケットであるなら直接すなわち、LCTヘッダー、パケット以遠FEC Payload IDの部分にアクセスするのにおいて使用されている場合があります。
Luby, et. al. Experimental [Page 19] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[19ページ]RFC3450ALCプロトコル具体化2002年12月
contains a payload, or the end of the packet if the packet
contains no payload.
パケットがペイロードを全く含んでいないなら、ペイロード、またはパケットの端を含んでいます。
In the example HDR_LEN=5 to indicate that the length of the LCT
header portion of the overall ALC is 5 32-bit words.
例のHDR_LEN=5では、それを示すために、総合的なALCのLCTヘッダー部分の長さは5つの32ビットの単語です。
Codepoint (CP): 8 bits
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.
この分野は、セッション中に変化できるSession記述の部分に設定を特定するマッピングを運ぶのにALCによって使用されます。 Session記述の部分への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.
例では、セッション中に変化できるSession記述の部分はFEC Encoding IDです、そして、アイデンティティマッピングはCodepoint値とFEC Encoding IDの間で使用されます。 したがって、CP=128はFECブロック[10]で説明されるようにFEC Encoding ID128と、「わずかなブロック、大量株、および拡張可能なFECコード」を特定します。 FEC Encoding ID128に関連しているFEC Payload IDは長さが64ビットです。
Congestion Control Information (CCI): 32, 64, 96 or 128 bits
輻輳制御情報(CCI): 64ビットか96ビットか32ビットか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.
これによる分野が指定された倍数レート混雑制御建家によって定義されるようにCongestion Control情報を含んでいるということです。 この分野の形式は複数のレート混雑制御建家のそばで決定しています。
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)を輸送してください: 32ビットか16ビットか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 MUST、LCTヘッダーで含められてください。
Luby, et. al. Experimental [Page 20] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[20ページ]RFC3450ALCプロトコル具体化2002年12月
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 MUSTがセッションがセッションが活発である期間の送付者で役立ったすべて中でユニークであり、大きい期間の間、先行して、セッションが活発であるときに、続きます。 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ビットです。 TOIがさばくTSI分野プラスの集合長さが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)を輸送してください: 16ビットか32ビットか48ビットか64ビットか80ビットか96ビットか0ビットか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番目の1などのためのTOI=1 別の例として、TOIは同時に数人の送付者から伝えられているオブジェクトのユニークなグローバルな識別子であるかもしれません、そして、TOI値はオブジェクトに適用されたハッシュ関数の出力であるかもしれません。 オブジェクトへのTOI分野値に関するマッピングは、このドキュメントの範囲の外にあって、バンドの外ですることです。 1個以上のオブジェクトがセッションのときに伝えられるつもりであるならすべてのパケットで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ビットです。 TOIがさばくTSI分野プラスの集合長さが32ビットの倍数であることに注意してください。
In the example the TOI is 32 bits in length.
例では、TOIは長さが32ビットです。
Luby, et. al. Experimental [Page 21] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[21ページ]RFC3450ALCプロトコル具体化2002年12月
Sender Current Time (SCT): 0 or 32 bits
送付者電流時間(SCT): 0ビットか32ビット
This field represents the current clock of the sender at the
time this packet was transmitted, measured in units of 1ms and
computed modulo 2^32 units from the start of the session.
このパケットが伝えられて、ユニットの1msで測定して、セッションの始まりから^32ユニット離れたところで法2を計算したとき、この分野は送付者の現在の時計を表します。
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 Payload 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 Payload IDの長さと形式はFECブロック[10]で説明されるようにFEC Encoding IDに依存します。 FEC有効搭載量ID形式はSession記述で伝えなければならないFEC Encoding IDのそばで決定しています。 Session記述は、1FEC EncodingのIDがセッションのときに使用されると指定するかもしれません、その場合、Session記述がどのCodepoint値がどのFEC Encoding IDに対応するかを特定するマッピングを含まなければなりません。 使用されるなら、このマッピングはこのドキュメントの範囲の外のそうです。
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コード」のための形式に対応している、どれ、関連FEC Encoding ID128 FEC Encoding ID128のために、FEC Payload IDは長さ64合計でXである以下の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
Source Block Numberは、ペイロードのコード化シンボルがオブジェクトのどのソースブロックから発生しているかを特定します。 これらのブロックから、一連番号をつけられます。
Luby, et. al. Experimental [Page 22] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[22ページ]RFC3450ALCプロトコル具体化2002年12月
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
Symbol 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.
Encoding Symbol IDは、ソースブロックから生成されたどの特定のコード化シンボルがパケットペイロードで運ばれるかを特定します。 Encoding Symbol IDの間の通信の正確な詳細とパケットペイロードのコード化シンボルはFEC Encoding IDとFEC Instance 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は、パケットの受信機で容認されたパケットの全長を計算して、ヘッダーの長さで引くことによって、決定できます。
4.3 Header-Extension Fields
4.3 ヘッダー拡大分野
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ヘッダー部分を広げるのにヘッダーExtensionsを使用できます。 ヘッダーExtensionsは前の小区分で示された例のALCパケット・フォーマットに使用されません。 Header Extensionsの使用に関する例は:
o Extended-size versions of already existing header fields.
o 既に既存のヘッダーフィールドの拡張サイズバージョン。
o Sender and Receiver authentication information.
o 送付者とReceiver認証情報。
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)でHeader Extensionsの存在を推論できます: HDR_LENが標準のヘッダーの長さより大きいなら、Header Extension分野で残っているヘッダースペースを取ります。
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.
存在しているなら、どんな輻輳制御手順も実行するか、または別の方法でパケットを受け入れる前に彼らが認識されるのを保証するためにHeader Extensionsを処理しなければなりません。 認識されていないHeader Extensionsのためのデフォルト動作は彼らを無視することです。 ALCバージョン番号を変えないで、これは後方コンパチブル増進の今後の導入をALCに許します。 非後方、コンパチブル、ALCバージョン番号を変えないで、Header Extensionsは導入されません。
Luby, et. al. Experimental [Page 23] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[23ページ]RFC3450ALCプロトコル具体化2002年12月
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.
Header Extension分野への2つの形式が以下に表現されるようにあります。 最初の形式は可変長の延長部分に0と127の間のHeader Extension Type(HET)値で使用されます。 127〜255までHET値を使用して、2番目の形式は固定長(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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 興奮しています(<=127)。| ヘル| | …++++++++++++++++++ヘッダー拡大含有量(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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 興奮しています(>=128)。| ヘッダー拡大含有量(HEC)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Format of additional headers
図3--追加ヘッダーの形式
The explanation of each sub-field is the following.
それぞれのサブ分野に関する説明は以下です。
Header Extension Type (HET): 8 bits
ヘッダー拡大タイプ(興奮の): 8ビット
The type of the Header Extension. This document defines a
number of possible types. Additional types may be defined in
future versions of this specification. HET values from 0 to
127 are used for variable-length Header Extensions. HET values
from 128 to 255 are used for fixed-length 32-bit Header
Extensions.
Header Extensionのタイプ。 このドキュメントは多くの可能なタイプを定義します。 追加タイプはこの仕様の将来のバージョンで定義されるかもしれません。 0〜127までのHET値は可変長のHeader Extensionsに使用されます。 128〜255までのHET値は固定長の32ビットのHeader Extensionsに使用されます。
Header Extension Length (HEL): 8 bits
ヘッダー拡大の長さ(HEL): 8ビット
The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field MUST be present for
variable-length extensions (HET between 0 and 127) and MUST NOT
be present for fixed-length extensions (HET between 128 and
255).
32ビットの単語の倍数で言い表された全体のHeader Extension分野の長さ。 この分野は、可変長の延長部分(0と127の間のHET)のために存在していなければならなくて、固定長拡大(128と255の間のHET)のために存在しているはずがありません。
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
Header Extensionの内容。 このサブ分野の形式はHeader Extensionタイプに頼っています。 固定長Header Extensionsに関しては、HECは24ビットです。 可変長のHeader Extensionsに関しては、HEC分野には、可変サイズがあります。
Luby, et. al. Experimental [Page 24] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[24ページ]RFC3450ALCプロトコル具体化2002年12月
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.
HEL分野で、指定されています。 それぞれのHeader Extension分野の長さが32ビットの倍数であるに違いないことに注意してください。 また、すべてのHeader Extensionsとすべての任意のヘッダーフィールドを含む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.
ヘッダーExtensionsは一般的なLCT拡張子とプロトコルのInstantiationの特定の拡張子(PI特有の)の間でさらに分割されます。 一般LCT拡張子で、範囲0:63と128: 191におけるHETは包括的になります。 PI特有の拡大で、範囲64:127と192: 255におけるHETは包括的になります。
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バージョン番号を変えないで、Header Extensionsは導入されません。
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 Header Extensionタイプは定義されます:
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 Packet認証拡大情報は以前はよくパケットの送付者を認証していました。 このHeader Extensionとその処理の形式は、Session記述の一部としてこのドキュメントの範囲の外にあって、バンドの外でコミュニケートされることです。
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.
送付者が何らかの形式のパケット認証を提供するのは、RECOMMENDEDです。 EXT_AUTHが存在しているなら、すぐパケットを受け入れる前に、実行されて、どんな混雑のコントロール関連の動作もそれに実行するパケットSHOULDのレセプションにそれをチェックするどんなパケット認証も実行できます。 いくつかのパケット認証体系がパケットが受け取られている時、パケットが完全に認証されるときに時数秒の遅れを課します。 そのようなどんな完全なパケット認証でもどんな適切な輻輳制御関連する動きも延期してはいけません。
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 MUSTを実装する受信機は、EXT_がNOP Header Extensionであるとサポートして、EXT_AUTHを認めなければなりませんが、内容を分析できないかもしれません。
Luby, et. al. Experimental [Page 25] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[25ページ]RFC3450ALCプロトコル具体化2002年12月
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 Object Transmission情報拡張子はオブジェクトのためのバンドにおけるFEC Object Transmission情報を運びます。 このHeader Extensionとその処理の形式は、Session記述の一部としてこのドキュメントの範囲の外にあって、バンドの外でコミュニケートされることです。
4.4 Sender Operation
4.4 送付者操作
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 MUSTがセクション2.4で説明されて、必要なSession記述を利用可能にする送付者。 送付者もセクション2.3で説明されるように必要なFEC Object Transmission情報を利用可能にしなければなりません。
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セッション中に提供されるかもしれません。 1個以上のオブジェクトがセッション以内に提供されるつもりであるなら、送付者はTOI分野を使用しなければなりません、そして、ユニークなTOIはセッション中に各オブジェクトを特定しなければなりません、そして、送付者は同じオブジェクトに関係するすべてのパケットに対応するTOIを使用しなければなりません。 FEC Payload 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
オブジェクトはセッション以内に連続して伝えられるかもしれません、そして、それらは同時に伝えられるかもしれません。 しかしながら、セッションのその部分に参加する受信機がすべてのオブジェクトを受けるのに関心を持っているなら、同じセッションのときに同時にオブジェクトを唯一の送るのは、良い習慣です。 この理由は中でそれらが持っているオブジェクトのための受信機受信データを無利子にするのに帯域幅とネットワークリソースを浪費するということです。 しかしながら、セッション中に運ばれた異なったオブジェクトのためにパケットを混合することに関して規則が全くありません。 この問題は効率に影響します。
Luby, et. al. Experimental [Page 26] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[26ページ]RFC3450ALCプロトコル具体化2002年12月
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.
パケット認証が使用されるのは、RECOMMENDEDです。 パケット認証が使用されているなら、認証を運ぶのにセクション4.3で説明されたHeader Extensionsを使用しなければなりません。
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)を超えていないか、またはパケット損失に結びつけられた断片化がトランスミッションにおける厳しい非能率を導入するかもしれないできるだけ大きい方法を使用することを勧めます。 すべてのパケットには同じであるか非常に同様のサイズがあるのは、RECOMMENDEDです、これが複数のレート混雑制御建家の有効性に厳しい影響力を持つことができるとき。
4.5 Receiver Operation
4.5 受信機操作
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に記載されているようにREQUIRED Session記述を得なければなりません。 このドキュメントの範囲の外に受信機がどうSession記述を得るかがあります。
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ヘッダーに提供されたCongestion Control情報野原を使用して、受信機は、複数のレート混雑が制御建家であると実装しなければなりません。 受信機が、複数のレート混雑が制御建家であると実装することができないなら、それはセッションに参加してはいけません。
Luby, et. al. Experimental [Page 27] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[27ページ]RFC3450ALCプロトコル具体化2002年12月
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によって特定されます。 前のものと、少なくともいつかの時間、送付者が、新しいオブジェクトのためにパケットを伝え始める前に古いオブジェクトのためにパケットを送るのを止めても、ネットワークと基本的なプロトコル層の両方が特に異なったチャンネルの上に送るとパケットを再命令しながらいくつかを引き起こす場合があって、その結果、受信機SHOULD NOTが、新しいオブジェクトのためのパケットのレセプションが、トランジットにはそれ以上のパケットが全くないことを意味すると仮定することに注意してください。
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 Object Transmission情報を得なければなりません。
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) 受信機は、パケットのヘッダーを分析して、それが有効なヘッダーであることを確かめなければなりません。 それが有効でないなら、さらなる処理なしでパケットを捨てなければなりません。 複数のパケットが受け取られているなら、それを分析できないで、次に、受信機SHOULDはセッションを残します。
(2) The receiver MUST verify that the sender IP address together with
the TSI carried in the header matches one of the (sender IP
address, TSI) pairs that was received in a Session Description
and that the receiver is currently joined to. If there is not a
match then the packet MUST be discarded without further
processing. If multiple packets are received with non-matching
(sender IP address, TSI) values then the receiver SHOULD leave
the session. If the receiver is joined to multiple ALC sessions
then the remainder of the steps are performed within the scope of
the (sender IP address, TSI) session of the received packet.
(2) 受信機は、TSIに伴う送付者IPアドレスがヘッダーマッチにSession記述で受け取られた(送付者IPアドレス、TSI)組のひとりを載せて、受信機が現在つながれることを確かめなければなりません。 マッチがなければ、さらなる処理なしでパケットを捨てなければなりません。 非合っている(送付者IPアドレス、TSI)値で複数のパケットを受け取るなら、受信機SHOULDはセッションを残します。 受信機が複数の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) 1個以上のオブジェクトがセッションのときに運ばれるなら、受信機は、LCTヘッダーで運ばれたTOIが有効であることを確かめなければなりません。 TOIが有効でないなら、さらなる処理なしでパケットを捨てなければなりません。
Luby, et. al. Experimental [Page 28] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[28ページ]RFC3450ALCプロトコル具体化2002年12月
(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) 受信機SHOULDはパケットの残りを処理します、対応するオブジェクトを再建するのにペイロードで適切に他のヘッダーフィールドを解釈して、FEC Payload IDとコード化シンボルを使用するのを含んでいて。
It is RECOMMENDED that packet authentication be used. If packet authentication is used then it is RECOMMENDED that the receiver immediately check the authenticity of a packet before proceeding with step (3) above. If immediate checking is possible and if the packet fails the check then the receiver MUST discard the packet and reduce its reception rate to a minimum before continuing to regulate its reception rate using the multiple rate congestion control.
パケット認証が使用されるのは、RECOMMENDEDです。 パケット認証が使用されているなら、受信機が上でステップ(3)で続く前にすぐにパケットの信憑性をチェックするのは、RECOMMENDEDです。 即座の照合が可能であり、パケットがチェックに失敗するなら、受信機は、複数のレート輻輳制御を使用することでレセプション率を規制し続ける前に、最小限までパケットを捨てて、レセプション率を低下させなければなりません。
Some packet authentication schemes such as TESLA [14] do not allow an immediate authenticity check. In this case the receiver SHOULD check the authenticity of a packet as soon as possible, and if the packet fails the check then it MUST be discarded before step (5) above and reduce its reception rate to a minimum before continuing to regulate its reception rate using the multiple rate congestion control.
テスラ[14]などのいくつかのパケット認証体系は即座の信憑性チェックを許しません。 受信機SHOULDができるだけ早く、この場合、パケットの信憑性をチェックして、パケットがチェックに失敗するなら、それは、複数のレート輻輳制御を使用することでレセプション率を規制し続ける前に、ステップ(5)の前に上で捨てられて、レセプション率を最小限まで低下させなければなりません。
5. Security Considerations
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があります。 両方のレベルで防止を提供するのは、RECOMMENDEDです。
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
アプリケーションレベルでは、それが送られたオブジェクトと同じであることを保証するためにいったんオブジェクトを再建すると全体の容認されたオブジェクトの保全チェックをするのは、RECOMMENDEDです。 そのうえ、受信機SHOULDが証明可能な強い暗号の保全保護aデジタル署名を得て、使用されて、このアプリケーションレベル保全チェックを提供してください。 しかしながら、1つの崩壊したか偽造しているパケットさえオブジェクトを再建するのに使用されると、容認されたオブジェクトは不当に再建されそうでしょう。 捨てられて、これは適切に失敗する保全チェックとこの場合不正確に再建されたオブジェクトSHOULDを引き起こすでしょう。 したがって、単一の偽造パケットの承認はオブジェクト、しかし、保全チェックが不正確に不注意な使用を少なくとも防ぐオブジェクトを分配するためのサービス攻撃の有効な否定であるかもしれません。
Luby, et. al. Experimental [Page 29] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[29ページ]RFC3450ALCプロトコル具体化2002年12月
reconstructed objects. The specification of an application level integrity check of the received object is outside the scope of this document.
オブジェクトを再建しました。 このドキュメントの範囲の外に容認されたオブジェクトのアプリケーションレベル保全チェックの仕様があります。
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データを含む正統の、そして、腐敗していないパケットであることを保証するのに使用されるのは、RECOMMENDEDです。 個別に偽造パケットを捨てることができます、そして、パケット・レベル認証で利点がそんなに不正になるか、または正確にオブジェクトを再建するのに容認された認証されたパケットは使用できます。 したがって、偽造パケットを注入するサービス不能攻撃の効果はオブジェクトサイズではなく、偽造パケットの数だけに比例しています。 現在、マルチキャストパケット・レベル認証をする方法を指定するIETF規格が全くありませんが、テスラ[14]はうまくいく知られているマルチキャストパケット認証体系です。
In addition to providing protection against reconstruction of inaccurate objects, packet level authentication can also provide some protection against denial of service attacks on the multiple rate congestion control. Attackers can try to inject forged packets with incorrect congestion control information into the multicast stream, thereby potentially adversely affecting network elements and receivers downstream of the attack, and much less significantly the rest of the network and other receivers. Thus, it is also RECOMMENDED that packet level authentication be used to protect against such attacks. TESLA [14] can also be used to some extent to limit the damage caused by such attacks. However, with TESLA a receiver can only determine if a packet is authentic several seconds after it is received, and thus an attack against the congestion control protocol can be effective for several seconds before the receiver can react to slow down the session reception rate.
また、不正確なオブジェクトの再建に対する保護を提供することに加えて、パケット・レベル認証は複数のレート輻輳制御のときにサービス不能攻撃に対する何らかの保護を提供できます。 攻撃者はマルチキャストストリームへの不正確な混雑制御情報を偽造パケットに注射しようとすることができます、その結果、潜在的に、攻撃のネットワーク要素と受信機川下にまして、かなり悪影響を与えます。ネットワークと他の受信機の残り。 したがって、また、パケット・レベル認証がそのような攻撃から守るのに使用されるのは、RECOMMENDEDです。 また、そのような攻撃でもたらされた損害を制限するのにテスラ[14]をある程度使用できます。 しかしながら、テスラと共に、受信機は、それが受け取られていた数秒後にパケットが正統であるかどうか決定できるだけです、そして、その結果、受信機がセッションレセプション率を減速させるために反応できる前に混雑制御プロトコルに対する攻撃は数秒間、有効である場合があります。
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.
逆のPath ForwardingチェックSHOULDは、悪いエージェントがマルチキャスト木のデータ経路に偽造パケットを注ぐ可能性を制限するためにすべてのネットワークルータで可能にされて、経路に沿って送付者から受信機に切り替わります。
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.
複数のレート混雑制御建家の不正確であるか崩壊した実装がある受信機は、送付者と受信機の間の経路のネットワークの健康に影響して、また、セッションに接合された他の受信機のレセプション率に影響するかもしれません。 したがって、彼らが記述がセッションに参加する必要があったSessionを受ける前に受信機が、自分たちが正統であると認識しなければならないのは、RECOMMENDEDです。 このドキュメントの範囲の外に受信機が、自分たちが正統であるとどう認識するかがあります。
Luby, et. al. Experimental [Page 30] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[30ページ]RFC3450ALCプロトコル具体化2002年12月
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の別の脆弱性はセッションのために不正確なSession記述を得る受信機の可能性です。 この結果は間違ったSession記述がある正統の受信機が正しくセッション内容を受け取ろうとすることができないか、または受信機がそれらができるよりはるかに高いレートでうっかり受信しようとするということであるかもしれません、その結果、ネットワークの一部でトラフィックを混乱させます。 対策が受信機が不正確なSession記述を受け入れるのを防ぐために実施されるのは、これらの問題を避けるためには、RECOMMENDEDです、例えば、受信機が認可された送付者から正統のSession記述を受け入れるだけであるのを保証するのにソース認証を使用することによって。 このドキュメントの範囲の外にこれがどう完了しているかがあります。
6. IANA Considerations
6. IANA問題
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登録を必要とします。
7. Intellectual Property Issues
7. 知的所有権問題
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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
8. Acknowledgments
8. 承認
Thanks to Vincent Roca, Justin Chapweske and Roger Kermode for their detailed comments on this document.
このドキュメントの彼らの詳細なコメントをヴィンセント・ロカ、ジャスティンChapweske、およびロジャー・カーモードをありがとうございます。
9. References
9. 参照
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[3] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2616, January 1997.
[4] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1997年ハイパーテキスト転送プロトコル--1月」。
Luby, et. al. Experimental [Page 31] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[31ページ]RFC3450ALCプロトコル具体化2002年12月
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[6] ハンドレーとM.とパーキンスとC.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[7] Holbrook, H. W., "A Channel Model for Multicast", Ph.D.
Dissertation, Stanford University, Department of Computer
Science, Stanford, California, August 2001.
[7]ホルブルック、H.W.、「マルチキャストのためのチャンネルモデル」、博士号Dissertation、スタンフォード大学、コンピュータサイエンス学部、スタンフォード、カリフォルニア(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] カーモード、R.、Vicisano(L.)は「ドキュメントをBlocksとプロトコルInstantiationに造って、Reliable Multicast Transport(RMT)のためにGuidelinesを書きます」、RFC3269、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.とリゾーとL.とハンドレーとM.とJ.クロウクロフト、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」、RFC3453、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.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、「前進型誤信号訂正(FEC)ブロック」、RFC3452(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.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト)は「コード化輸送(LCT)ブロックを層にしました」、RFC3451 2002年12月。
[12] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[12] マンキン、A.、Romanow、A.、ブラドナー、S.、および「信頼できるマルチキャスト輸送とアプリケーション・プロトコルを評価するIETF評価基準」、RFC2357(1998年6月)対パクソン
[13] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[13] ムラタとM.と聖ローランとS.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[14] Perrig, A., Canetti, R., Song, D. and J.D. Tygar, "Efficient and
Secure Source Authentication for Multicast", Network and
Distributed System Security Symposium, NDSS 2001, pp. 35-46,
February 2001.
[14]PerrigとA.とカネッティとR.とSongとD.とJ.D.Tygarと「マルチキャストのための効率的で安全なソース認証」とNetworkとDistributed System Security Symposium、NDSS2001、ページ 35-46と、2001年2月。
[15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[15] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、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.とカーモードとR.とハンドレーとM.とフロイドとS.とM.Luby、「多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送」、RFC3048、2001年1月。
Luby, et. al. Experimental [Page 32] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[32ページ]RFC3450ALCプロトコル具体化2002年12月
Authors' Addresses
作者のアドレス
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA, USA, 94538
マイケルLubyのデジタル噴水39141シビック・センターSuite300フレモント(カリフォルニア)、米国博士94538
EMail: luby@digitalfountain.com
メール: luby@digitalfountain.com
Jim Gemmell Microsoft Research 455 Market St. #1690 San Francisco, CA, 94105
ジムGemmellマイクロソフトResearch455はサンフランシスコ、聖#1690カリフォルニア 94105を売り出します。
EMail: jgemmell@microsoft.com
メール: jgemmell@microsoft.com
Lorenzo Vicisano cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA, USA, 95134
ロレンツォVicisanoコクチマスSystems Inc.170の西タスマンサンノゼ博士(カリフォルニア)(米国)95134
EMail: lorenzo@cisco.com
メール: lorenzo@cisco.com
Luigi Rizzo Dip. Ing. dell'Informazione, Univ. di Pisa via Diotisalvi 2, 56126 Pisa, Italy
ルーイジリゾーDip。 Ing dell'Informazione、Diotisalvi2、56126ピサ、イタリア経由で大学ディピサ
EMail: luigi@iet.unipi.it
メール: luigi@iet.unipi.it
Jon Crowcroft Marconi Professor of Communications Systems University of Cambridge Computer Laboratory William Gates Building J J Thomson Avenue Cambridge CB3 0FD, UK
ケンブリッジコンピュータ研究所ウィリアムゲイツビルJ JトムソンアベニューケンブリッジCB3 0FDの通信網大学のイギリスのジョンクロウクロフトマルコニー教授
EMail: Jon.Crowcroft@cl.cam.ac.uk
メール: Jon.Crowcroft@cl.cam.ac.uk
Luby, et. al. Experimental [Page 33] RFC 3450 ALC protocol instantiation December 2002
et Luby、アル。 実験的な[33ページ]RFC3450ALCプロトコル具体化2002年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Luby, et. al. Experimental [Page 34]
et Luby、アル。 実験的[34ページ]
一覧
スポンサーリンク
