RFC3451 日本語訳
3451 Layered Coding Transport (LCT) Building Block. M. Luby, J.Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT=72594 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Luby
Request for Comments: 3451 Digital Fountain
Category: Experimental J. Gemmell
Microsoft
L. Vicisano
Cisco
L. Rizzo
Univ. Pisa
M. Handley
ICIR
J. Crowcroft
Cambridge Univ.
December 2002
Lubyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3451年のデジタル噴水カテゴリ: 実験的なJ.のL.VicisanoコクチマスL.リゾーGemmellマイクロソフト大学 ピサM.ハンドレーICIR J.クロウクロフトケンブリッジ大学 2002年12月
Layered Coding Transport (LCT) Building Block
層にされたコード化輸送(LCT)ブロック
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
要約
Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.
(LCT)が提供する層にされたCoding Transportは信頼できる内容物配送とストリーム配送プロトコルの平らなサポートを輸送します。 LCTはIPマルチキャストを使用することでプロトコルをサポートするように明確に設計されていますが、ユニキャストを使用するプロトコルにサポートをまた提供します。 LCTも複数のレート配送を受信機に供給する輻輳制御と互換性があって、また、内容の信頼できる配信を提供するコーディング技法と互換性があります。
Luby, et. al. Experimental [Page 1] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [1ページ]実験的なRFC3451LCTブロック2002年12月
Table of Contents
目次
1. Introduction...................................................2
2. Rationale......................................................3
3. Functionality..................................................4
4. Applicability..................................................7
4.1 Environmental Requirements and Considerations...............8
4.2 Delivery service models....................................10
4.3 Congestion Control.........................................11
5. Packet Header Fields..........................................12
5.1 Default LCT header format..................................12
5.2 Header-Extension Fields....................................17
6. Operations....................................................20
6.1 Sender Operation...........................................20
6.2 Receiver Operation.........................................22
7. Requirements from Other Building Blocks.......................23
8. Security Considerations.......................................24
9. IANA Considerations...........................................25
10. Acknowledgments..............................................25
11. References...................................................25
Authors' Addresses...............................................28
Full Copyright Statement.........................................29
1. 序論…2 2. 原理…3 3. 機能性…4 4. 適用性…7 4.1の環境要求事項と問題…8 4.2 デリバリ・サービスはモデル化されます…10 4.3 混雑コントロール…11 5. パケットのヘッダー分野…12 5.1 デフォルトLCTヘッダー形式…12 5.2 ヘッダー拡大分野…17 6. 操作…20 6.1 送付者操作…20 6.2 受信機操作…22 7. 他のブロックからの要件…23 8. セキュリティ問題…24 9. IANA問題…25 10. 承認…25 11. 参照…25人の作者のアドレス…28 完全な著作権宣言文…29
1. Introduction
1. 序論
Layered Coding Transport provides transport level support for reliable content delivery and stream delivery protocols. Layered Coding Transport is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. Layered Coding Transport is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.
層にされたCoding Transportはレベルが信頼できる内容物配送とストリーム配送のためにサポートする輸送にプロトコルを提供します。 層にされたCoding TransportはIPマルチキャストを使用することでプロトコルをサポートするように明確に設計されていますが、ユニキャストを使用するプロトコルにサポートをまた提供します。 層にされたCoding Transportも複数のレート配送を受信機に供給する輻輳制御と互換性があって、また、内容の信頼できる配信を提供するコーディング技法と互換性があります。
This document describes a building block as defined in RFC 3048 [26]. This document is a product of the IETF RMT WG and follows the general guidelines provided in RFC 3269 [24].
このドキュメントはRFC3048[26]で定義されるようにブロックについて説明します。 このドキュメントは、IETF RMT WGの製品であり、RFC3269[24]に提供された一般的ガイドラインに従います。
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])で説明されるように本書では解釈されることであるべきです。
Luby, et. al. Experimental [Page 2] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [2ページ]実験的なRFC3451LCTブロック2002年12月
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully
specify a Reliable Multicast Transport protocol in accordance with
RFC 2357. As per RFC 2357, 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がこの仕様を再提出する意図です。
2. Rationale
2. 原理
LCT provides transport level support for massively scalable protocols using the IP multicast network service. The support that LCT provides is common to a variety of very important applications, including reliable content delivery and streaming applications.
LCTは、IPマルチキャストネットワーク・サービスを使用することで膨大にスケーラブルなプロトコルの輸送レベルサポートを提供します。 LCTが提供するサポートはさまざまな非常に重要なアプリケーションに共通です、信頼できる内容物配送とストリーミング・アプリケーションを含んでいて。
An LCT 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. The logic behind defining a session as originating from a single sender is that this is the right granularity to regulate packet traffic via congestion control. One rationale for using multiple channels within the same session is that there are massively scalable congestion control protocols that use multiple channels per session. These congestion control protocols are considered to be layered because a receiver joins and leaves channels in a layered order during its participation in the session. The use of layered channels is also useful for streaming applications.
LCTセッションは受信機に興味がある場合がある1個以上のオブジェクトのトランスミッションに関係するパケットを運ぶのにいつかの期間の間に使用される独身の送付者で起因する複数のチャンネルを包括します。 独身の送付者から発するとセッションを定義する後ろの論理はこれが輻輳制御でパケットトラフィックを規制する正しい粒状であるということです。 同じセッション中に複数のチャンネルを使用するための1つの原理は複数の1セッションあたりのチャンネルを使用する膨大にスケーラブルな混雑制御プロトコルがあるということです。 受信機がセッションにおける参加の間、層にされたオーダーにチャンネルに加わって、残すのでこれらの混雑制御プロトコルが層にされると考えられます。 また、層にされたチャンネルの使用もストリーミング・アプリケーションの役に立ちます。
There are coding techniques that provide massively scalable reliability and asynchronous delivery which are compatible with both layered congestion control and with LCT. When all are combined the result is a massively scalable reliable asynchronous content delivery protocol that is network friendly. LCT also provides functionality that can be used for other applications as well, e.g., layered streaming applications.
輻輳制御とLCTと共に層にされる両方と互換性がある膨大にスケーラブルな信頼性と非同期な配送を提供するコーディング技法があります。 すべてが結合されているとき、結果はネットワーク好意的な膨大にスケーラブルな信頼できる非同期な内容物配送プロトコルです。 また、LCTはまた、他のアプリケーション、例えば、層にされたストリーミング・アプリケーションに使用できる機能性を提供します。
Luby, et. al. Experimental [Page 3] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [3ページ]実験的なRFC3451LCTブロック2002年12月
LCT avoids providing functionality that is not massively scalable. For example, LCT does not provide any mechanisms for sending information from receivers to senders, although this does not rule out protocols that both use LCT and do require sending information from receivers to senders.
LCTは、膨大にスケーラブルでない機能性を提供するのを避けます。 例えば、LCTは受信機から送付者までどんなメカニズムも送付情報に提供しません、これが受信機から送付者までLCTを使用して、情報を送るのを必要とするプロトコルを除外しませんが。
LCT includes general support for congestion control that must be used. It does not, however, specify which congestion control should be used. The rationale for this is that congestion control must be provided by any protocol that is network friendly, and yet the different applications that can use LCT will not have the same requirements for congestion control. For example, a content delivery protocol may strive to use all available bandwidth between receivers and the sender. It must, therefore, drastically back off its rate when there is competing traffic. On the other hand, a streaming delivery protocol may strive to maintain a constant rate instead of trying to use all available bandwidth, and it may not back off its rate as fast when there is competing traffic.
LCTは使用しなければならない輻輳制御の一般的なサポートを含んでいます。 しかしながら、それは、どの輻輳制御が使用されるべきであるかを指定しません。 これのための原理はどんなネットワーク好意的なプロトコルでも輻輳制御を提供しなければならないということですが、LCTを使用できる異なったアプリケーションは輻輳制御のための同じ要件を持たないでしょう。 例えば、内容物配送プロトコルは、受信機と送付者の間のすべての利用可能な帯域幅を使用するように努力するかもしれません。 したがって、競争しているトラフィックがあるとき、それはレートを抜本的に戻さなければなりません。 他方では、ストリーミングの配送プロトコルは、すべての利用可能な帯域幅を使用しようとすることの代わりに一定のレートを維持するように努力するかもしれません、そして、競争しているトラフィックがあるとき、それは速いとしてレートを戻さないかもしれません。
Beyond support for congestion control, LCT provides a number of fields and supports functionality commonly required by many protocols. For example, LCT provides a Transmission Session ID that can be used to identify which session each received packet belongs to. This is important because a receiver may be joined to many sessions concurrently, and thus it is very useful to be able to demultiplex packets as they arrive according to which session they belong to. As another example, LCT provides optional support for identifying which object each packet is carrying information about. Therefore, LCT provides many of the commonly used fields and support for functionality required by many protocols.
輻輳制御のサポートを超えて、LCTは多くの野原を供給して、多くのプロトコルによって一般的に必要とされた機能性をサポートします。 例えば、LCTはそれぞれの容認されたパケットがどのセッションに属すかを特定するのに使用できるTransmission Session IDを提供します。 受信機が同時に多くのセッションにつながれるかもしれないので、これは重要です、そして、その結果、属すどのセッションに従って到着するかとき、「反-マルチプレックス」パケットにできるのは非常に役に立ちます。 別の例として、LCTは各パケットがどのオブジェクトで情報を運ぶかを特定する任意のサポートを提供します。 したがって、LCTは一般的に使用された野原の多くを供給します、そして、機能性のサポートが多くのプロトコルが必要です。
3. Functionality
3. 機能性
An LCT session consists of a set of logically grouped LCT channels associated with a single sender carrying packets with LCT headers for one or more objects. An LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop receiving data packets from the channel.
LCTセッションは1個以上のオブジェクトのためにLCTヘッダーと共にパケットを運ぶ独身の送付者に関連している論理的に分類されたLCTチャンネルのセットから成ります。 LCTチャンネルは送付者の組み合わせと送付者でチャンネルに関連しているアドレスによって定義されます。 パケットが送付者でチャンネルに送って、チャンネルが受信機で止めるデータを受信するのがチャンネルからデータ・パケットを受け始めるように、受信機はチャンネルに加わります。
LCT is meant to be combined with other building blocks so that the resulting overall protocol is massively scalable. Scalability refers to the behavior of the protocol in relation to the number of receivers and network paths, their heterogeneity, and the ability to accommodate dynamically variable sets of receivers. Scalability limitations can come from memory or processing requirements, or from the amount of feedback control and redundant data packet traffic
LCTが他のブロックに結合されることになっているので、結果として起こる総合的なプロトコルは膨大にスケーラブルです。 スケーラビリティは受信機、ネットワーク経路、それらの異種性、およびダイナミックに可変セットの受信機を収容する能力の数と関連してプロトコルの振舞いについて言及します。 スケーラビリティ制限はメモリか処理所要か、フィードバック制御と冗長データパケットトラフィックの量から来ることができます。
Luby, et. al. Experimental [Page 4] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [4ページ]実験的なRFC3451LCTブロック2002年12月
generated by the protocol. In turn, such limitations may be a consequence of the features that a complete reliable content delivery or stream delivery protocol is expected to provide.
プロトコルで、生成されます。 順番に、そのような制限は完全な信頼できる内容物配送かストリーム配送プロトコルが提供すると予想される特徴の結果であるかもしれません。
The LCT header provides a number of fields that are useful for conveying in-band session information to receivers. One of the required fields is the Transmission Session ID (TSI), which allows the receiver of a session to uniquely identify received packets as part of the session. Another required field is the Congestion Control Information (CCI), which allows the receiver to perform the required congestion control on the packets received within the session. Other LCT fields provide optional but often very useful additional information for the session. For example, the Transport Object Identifier (TOI) identifies which object the packet contains data for. As other examples, the Sender Current Time (SCT) conveys the time when the packet was sent from the sender to the receiver, the Expected Residual Time (ERT) conveys the amount of time the session will be continued for, flags for indicating the close of the session and the close of sending packets for an object, and header extensions for fields that for example can be used for packet authentication.
LCTヘッダーはバンドにおけるセッション情報を受信機に伝えることの役に立つ多くの野原を供給します。 必須項目の1つはTransmission Session ID(TSI)です。(そのIDは容認されたパケットがセッションの一部であるとセッションの受信機を唯一認識させます)。 別の必須項目はCongestion Control情報(CCI)です。(受信機はその情報でセッション中に受け取られたパケットに必要な輻輳制御を実行できます)。 他のLCT分野はセッションのための任意の、しかし、しばしば非常に役に立つ追加情報を提供します。 例えば、Transport Object Identifier(TOI)は、パケットがどのオブジェクトに関してデータを含むかを特定します。 他の例として、Sender Current Time(SCT)はパケットが送付者から受信機に送られた時を伝えます、とExpected Residual Timeはセッションが続けられている時間を伝えます(ERT)、セッションの閉鎖とオブジェクトのためにパケットを発信させて、例えばパケット認証に使用できる分野にヘッダー拡大を発信させる閉鎖を示すための旗。
LCT provides support for congestion control. Congestion control MUST be used that conforms to RFC 2357 [13] between receivers and the sender for each LCT session. Congestion control refers to the ability to adapt throughput to the available bandwidth on the path from the sender to a receiver, and to share bandwidth fairly with competing flows such as TCP. Thus, the total flow of packets flowing to each receiver participating in an LCT session MUST NOT compete unfairly with existing flow adaptive protocols such as TCP.
LCTは輻輳制御のサポートを提供します。 それぞれのLCTセッションのために受信機と送付者の間でRFC2357[13]に従う輻輳制御を使用しなければなりません。 輻輳制御は送付者から受信機まで経路における利用可能な帯域幅にスループットを適合させて、TCPなどの競争している流れと帯域幅を公正に共有する能力について言及します。 したがって、LCTセッションのときに関与する各受信機に注ぐパケットの全流量は不公平にTCPなどの既存の流れ適応型のプロトコルと競争してはいけません。
A multiple rate or a single rate congestion control protocol can be used with LCT. For multiple rate protocols, a session typically consists of more than one channel and the sender sends packets to the channels in the session at rates that do not depend on the receivers. Each receiver adjusts its reception rate during its participation in the session by joining and leaving channels dynamically depending on the available bandwidth to the sender independent of all other receivers. Thus, for multiple rate protocols, the reception rate of each receiver may vary dynamically independent of the other receivers.
LCTと共に複数のレートか単一賃率輻輳制御プロトコルを使用できます。 複数のレートプロトコルのために、セッションは1個以上のチャンネルから通常成ります、そして、送付者はセッションのときに受信機に依存しないレートでパケットをチャンネルに送ります。 他のすべての受信機の如何にかかわらず送付者への利用可能な帯域幅によって、各受信機は、セッションにおける参加の間、ダイナミックにチャンネルに加わって、残すことによって、レセプション率を調整します。 したがって、複数のレートプロトコルのために、それぞれの受信機のレセプション率は他の受信機の如何にかかわらずダイナミックに異なるかもしれません。
For single rate protocols, a session typically consists of one channel and the sender sends packets to the channel at variable rates over time depending on feedback from receivers. Each receiver remains joined to the channel during its participation in the session. Thus, for single rate protocols, the reception rate of each receiver may vary dynamically but in coordination with all receivers.
単一賃率プロトコルのために、セッションは1個のチャンネルから通常成ります、そして、送付者は時間がたつにつれて、受信機からチャンネルへの変動金利におけるパケットをフィードバックによらせます。 各受信機はセッションにおける参加の間、チャンネルで加わられたままで残っています。 したがって、ダイナミックに異なりますが、単一賃率プロトコルのために、それぞれの受信機のレセプション率はすべての受信機でコーディネートでそうするかもしれません。
Luby, et. al. Experimental [Page 5] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [5ページ]実験的なRFC3451LCTブロック2002年12月
Generally, a multiple rate protocol is preferable to a single rate protocol in a heterogeneous receiver environment, since generally it more easily achieves scalability to many receivers and provides higher throughput to each individual receiver. Some possible multiple rate congestion control protocols are described in [22], [3], and [25]. A possible single rate congestion control protocol is described in [19].
一般に、複数のレートプロトコルが異種の受信機環境における単一賃率プロトコルより望ましい、より容易に多くの受信機にスケーラビリティを達成して、個々の受信機それぞれへの何らかの可能な倍数をより高いスループットに提供するので、レート混雑制御プロトコルは[22]、[3]、および[25]で説明されます。 可能な単一賃率混雑制御プロトコルは[19]で説明されます。
Layered coding refers to the ability to produce a coded stream of packets that can be partitioned into an ordered set of layers. The coding is meant to provide some form of reliability, and the layering is meant to allow the receiver experience (in terms of quality of playout, or overall transfer speed) to vary in a predictable way depending on how many consecutive layers of packets the receiver is receiving.
層にされたコード化は1つの順序集合の層に仕切ることができるパケットのコード化された流れを起こす能力について言及します。 コード化は何らかのフォームの信頼性を提供することになっています、そして、レイヤリングは受信機がいくつの連続した層のパケットを受けているかによるという予測できる方法で変える経験(再生の品質、または総合的な転送速度に関する)を受信機に許すことになっています。
The concept of layered coding was first introduced with reference to audio and video streams. For example, the information associated with a TV broadcast could be partitioned into three layers, corresponding to black and white, color, and HDTV quality. Receivers can experience different quality without the need for the sender to replicate information in the different layers.
層にされたコード化の概念は最初に、オーディオとビデオストリームに関して紹介されました。例えば、テレビ放送に関連している情報を3つの層に仕切ることができました、白黒、色、およびHDTV品質に対応しています。 受信機は送付者が異なった層で情報を模写する必要性なしで異なった品質を経験できます。
The concept of layered coding can be naturally extended to reliable content delivery protocols when Forward Error Correction (FEC) techniques are used for coding the data stream. Descriptions of this can be found in [20], [18], [7], [22] and [4]. By using FEC, the data stream is transformed in such a way that reconstruction of a data object does not depend on the reception of specific data packets, but only on the number of different packets received. As a result, by increasing the number of layers a receiver is receiving from, the receiver can reduce the transfer time accordingly. Using FEC to provide reliability can increase scalability dramatically in comparison to other methods for providing reliability. More details on the use of FEC for reliable content delivery can be found in [11].
Forward Error Correction(FEC)のテクニックがデータ・ストリームをコード化するのに使用されるとき、自然に信頼できる内容物配送プロトコルに層にされたコード化の概念について敷衍できます。 [20]、[18]、[7]、[22]、および[4]でこの記述を見つけることができます。 FECを使用することによって、データ・ストリームをデータ・オブジェクトの再建が特定のデータ・パケットのレセプションによらないような方法で変えますが、異なったパケットの数だけで受けます。 その結果、受信機が受信している層の数を増強することによって、受信機はそれに従って、転送時間を短縮できます。 信頼性を提供するのにFECを使用すると、比較で信頼性を提供するための他のメソッドにスケーラビリティを劇的に増強できます。 [11]でFECの信頼できる内容物配送の使用に関するその他の詳細を見つけることができます。
Reliable protocols aim at giving guarantees on the reliable delivery of data from the sender to the intended recipients. Guarantees vary from simple packet data integrity to reliable delivery of a precise copy of an object to all intended recipients. Several reliable content delivery protocols have been built on top of IP multicast using methods other than FEC, but scalability was not the primary design goal for many of them.
信頼できるプロトコルはデータの送付者から意図している受取人までの信頼できる配信のときに保証を与えるのを目的とします。 保証は簡単なパケットデータ保全からすべての意図している受取人へのオブジェクトの正確なコピーの信頼できる配信に異なります。 いくつかの信頼できる内容物配送プロトコルがIPマルチキャストの上でFEC以外のメソッドを使用することで築き上げられましたが、スケーラビリティはそれらの多くのプライマリデザイン目標ではありませんでした。
Two of the key difficulties in scaling reliable content delivery using IP multicast are dealing with the amount of data that flows from receivers back to the sender, and the associated response (generally data retransmissions) from the sender. Protocols that
IPマルチキャストを使用することで信頼できる内容物配送をスケーリングすることにおける2つの主要な苦労が送付者から受信機から送付者まで流れるデータ量、および関連応答(一般にデータ「再-トランスミッション」)に対処しています。 プロトコル、それ
Luby, et. al. Experimental [Page 6] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [6ページ]実験的なRFC3451LCTブロック2002年12月
avoid any such feedback, and minimize the amount of retransmissions, can be massively scalable. LCT can be used in conjunction with FEC codes or a layered codec to achieve reliability with little or no feedback.
あらゆるそのようなフィードバックを避けてください、そして、「再-トランスミッション」の量を最小にしてください、そして、膨大にスケーラブルである場合があります。 フィードバックでまず信頼性を獲得しないようにFECコードか層にされたコーデックに関連してLCTを使用できます。
Protocol instantiations MAY be built by combining the LCT framework with other components. A complete protocol instantiation that uses LCT MUST include a congestion control protocol that is compatible with LCT and that conforms to RFC 2357 [13]. A complete protocol instantiation that uses LCT MAY include a scalable reliability protocol that is compatible with LCT, it MAY include an session control protocol that is compatible with LCT, and it MAY include other protocols such as security protocols.
プロトコル具体化は、LCTフレームワークを他のコンポーネントに結合することによって、築き上げられるかもしれません。 LCT MUSTを使用する完全なプロトコル具体化はLCTと互換性があって、RFC2357[13]に従う混雑制御プロトコルを含んでいます。 LCT MAYを使用する完全なプロトコル具体化はLCTと互換性があるスケーラブルな信頼性のプロトコルを含んでいます、そして、LCTと互換性があるセッション制御プロトコルを含むかもしれません、そして、それはセキュリティプロトコルなどの他のプロトコルを含むかもしれません。
4. Applicability
4. 適用性
An LCT session comprises a logically related set of one or more LCT channels originating at a single sender. The channels are used for some period of time to carry packets containing LCT headers, and these headers pertain to the transmission of one or more objects that can be of interest to receivers.
LCTセッションは独身の送付者で起因する1個以上のLCTチャンネルの論理的に関連するセットを包括します。 チャンネルはLCTヘッダーを含むパケットを運ぶのにいつかの期間の間、使用されます、そして、これらのヘッダーは受信機に興味がある場合がある1個以上のオブジェクトのトランスミッションに関係します。
LCT is most applicable for delivery of objects or streams in a session of substantial length, i.e., objects or streams that range in aggregate length from hundreds of kilobytes to many gigabytes, and where the duration of the session is on the order of tens of seconds or more.
オブジェクトかストリームの配送に、LCTは集合何百キロバイトからも多くのギガバイトまでの長さ、および何十もの秒か以上の注文にはセッションの持続時間があるところで及ぶかなりの長さ、すなわち、オブジェクトまたはストリームのセッションのときに最も適切です。
As an example, an LCT session could be used to deliver a TV program using three LCT channels. Receiving packets from the first LCT channel could allow black and white reception. Receiving the first two LCT channels could also permit color reception. Receiving all three channels could allow HDTV quality reception. Objects in this example could correspond to individual TV programs being transmitted.
例として、3個のLCTチャンネルを使用することでテレビ番組を提供するのにLCTセッションを使用できました。 第1代LCTチャンネルからパケットを受けると、白黒のレセプションは許容されるかもしれません。 また、最初の2個のLCTチャンネルを受けると、色のレセプションは可能にするかもしれません。 すべての3個のチャンネルを受けると、上質のレセプションはHDTVに許容されるかもしれません。 この例のオブジェクトは伝えられる個々のテレビ番組に対応できました。
As another example, a reliable LCT session could be used to reliably deliver hourly-updated weather maps (objects) using ten LCT channels at different rates, using FEC coding. A receiver may join and concurrently receive packets from subsets of these channels, until it has enough packets in total to recover the object, then leave the session (or remain connected listening for session description information only) until it is time to receive the next object. In this case, the quality metric is the time required to receive each object.
別の例として、異なった速度で10個のLCTチャンネルを使用することで一時間アップデートされた天気図(オブジェクト)を確かに提供するのに信頼できるLCTセッションを使用できました、FECコード化を使用して。 受信機は、接合して、同時にこれらのチャンネルの部分集合からパケットを受けるかもしれません、もう次のオブジェクトを受け取るべき時間になるまでのセッション(接続されていたままで、セッション記述情報だけの聞こうとしながら、残る)のときに合計でオブジェクトを回収して、次に、いなくなることができるくらいのパケットを持つまで。 この場合、品質メートル法であることは、各オブジェクトを受け取るのに必要である時間です。
Before joining a session, the receivers MUST obtain enough of the session description to start the session. This MUST include the relevant session parameters needed by a receiver to participate in
接合する前に、セッション、受信機はセッション記述がセッションを始める十分を得なければなりません。 これはパラメタが受信機で参加する必要があった関連セッションを含まなければなりません。
Luby, et. al. Experimental [Page 7] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [7ページ]実験的なRFC3451LCTブロック2002年12月
the session, including all information relevant to congestion control. The session description is determined by the sender, and is typically communicated to the receivers out-of-band. In some cases, as described later, parts of the session description that are not required to initiate a session MAY be included in the LCT header or communicated to a receiver out-of-band after the receiver has joined the session.
輻輳制御に関連しているすべての情報を含むセッション。 セッション記述は、送付者によって決定されて、バンドの外で受信機に通常伝えられます。 いくつかの場合、受信機がセッションに参加した後に、セッションを開始する必要はないセッション記述の部品は、後述のように、LCTヘッダーで含められているか、またはバンドの外で受信機に伝えられるかもしれません。
An encoder MAY be used to generate the data that is placed in the packet payload in order to provide reliability. A suitable decoder is used to reproduce the original information from the packet payload. There MAY be a reliability header that follows the LCT header if such an encoder and decoder is used. The reliability header helps to describe the encoding data carried in the payload of the packet. The format of the reliability header depends on the coding used, and this is negotiated out-of-band. As an example, one of the FEC headers described in [12] could be used.
エンコーダは、信頼性を提供するためにパケットペイロードに置かれるデータを生成するのに使用されるかもしれません。 適当なデコーダは、パケットペイロードからオリジナルの情報を再生させるのに使用されます。 そのようなエンコーダであるならLCTヘッダーについて来る信頼性のヘッダーがあるかもしれません、そして、デコーダは使用されています。 信頼性のヘッダーは、パケットのペイロードで運ばれたデータを暗号化について説明するのを助けます。 信頼性のヘッダーの形式を使用されるコード化であることに依存します、そして、これはバンドの外で交渉されます。 例として、[12]で説明されたFECヘッダーのひとりを使用できました。
For LCT, when multiple rate congestion control is used, congestion control is achieved by sending packets associated with a given session to several LCT channels. Individual receivers dynamically join one or more of these channels, according to the network congestion as seen by the receiver. LCT headers include an opaque field which MUST be used to convey congestion control information to the receivers. The actual congestion control scheme to use with LCT is negotiated out-of-band. Some examples of congestion control protocols that may be suitable for content delivery are described in [22], [3], and [25]. Other congestion controls may be suitable when LCT is used for a streaming application.
複数のレート輻輳制御が使用されているとき、LCTに関しては、輻輳制御は与えられたセッションに関連している送付パケットによって数個のLCTチャンネルに達成されます。 個々の受信機はダイナミックにこれらのチャンネルのより多くのひとりを接合します、受信機によって見られるネットワークの混雑に従って。LCTヘッダーは混雑制御情報を受信機に伝えるのに使用しなければならない不透明な分野を入れます。 LCTと共に使用する実際の輻輳制御体系はバンドの外で交渉されます。 内容物配送に適するかもしれない混雑制御プロトコルに関するいくつかの例が[22]、[3]、および[25]で説明されます。 LCTがストリーミング・アプリケーションに使用されるとき、他の輻輳制御は適当であるかもしれません。
This document does not specify and restrict the type of exchanges between LCT (or any PI built on top of LCT) and an upper application. Some upper APIs may use an object-oriented approach, where the only possible unit of data exchanged between LCT (or any PI built on top of LCT) and an application, either at a source or at a receiver, is an object. Other APIs may enable a sending or receiving application to exchange a subset of an object with LCT (or any PI built on top of LCT), or may even follow a streaming model. These considerations are outside the scope of this document.
このドキュメントは、LCT(どんなPIもLCTの上に建てた)と上側のアプリケーションの間の交換のタイプを指定して、制限しません。 いくつかの上側のAPIがオブジェクト指向アプローチを使用するかもしれません、LCT(どんなPIもLCTの上に建てた)とアプリケーションの間、または、ソースにおいて、または、受信機において交換された唯一の可能なユニットのデータがオブジェクトであるところで。 他のAPIは、送付かアプリケーションを受け取るとLCT(どんなPIもLCTの上に建てた)がオブジェクトの部分集合を交換されるのを可能にするか、またはストリーミングのモデルに従いさえするかもしれません。 このドキュメントの範囲の外にこれらの問題があります。
4.1 Environmental Requirements and Considerations
4.1 環境要件と問題
LCT is intended for congestion controlled delivery of objects and streams (both reliable content delivery and streaming of multimedia information).
LCTはオブジェクトとストリーム(信頼できる内容物配送とマルチメディア情報のストリーミングの両方)の混雑の制御配送のために意図します。
Luby, et. al. Experimental [Page 8] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [8ページ]実験的なRFC3451LCTブロック2002年12月
LCT can be used with both multicast and unicast delivery. LCT requires connectivity between a sender and receivers but does not require connectivity from receivers to a sender. LCT 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 LCT is unlimited. However, when other specific applications are built on top of LCT, then these applications by their very nature may limit scalability. For example, if an application requires receivers to retrieve out of band information in order to join a session, or an application allows receivers to send requests back to the sender to report reception statistics, then the scalability of the application is limited by the ability to send, receive, and process this additional data.
マルチキャストとユニキャスト配送の両方と共にLCTを使用できます。 LCTは送付者と受信機の間で接続性を必要としますが、受信機から送付者まで接続性は必要としません。 LCTは本来すべてのタイプのネットワークと共に働いています、LAN、WAN、イントラネット、インターネット、非対称のネットワーク、ワイヤレス・ネットワーク、および衛星ネットワークを含んでいて。 したがって、LCTの固有の生のスケーラビリティは無制限です。 しかしながら、他の特定のアプリケーションがLCTの上で組立てられるとき、そして、彼らのまさしくその本質によるこれらのアプリケーションはスケーラビリティを制限するかもしれません。 例えば、セッションに参加して、アプリケーションがバンドから情報を検索するために受信機を必要とするか、またはアプリケーションが、受信機がレセプション統計を報告するために要求を送付者に送り返すのを許容するなら、アプリケーションのスケーラビリティはこの追加データを送って、受け取って、処理する能力によって制限されます。
LCT requires receivers to be able to uniquely identify and demultiplex packets associated with an LCT session. In particular, there MUST be a Transport Session Identifier (TSI) associated with each LCT session. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI MUST uniquely identify the session. If the underlying transport is UDP as described in RFC 768 [16], then the 16 bit UDP source port number MAY serve as the TSI for the session. The TSI value MUST be the same in all places it occurs within a packet. If there is no underlying TSI provided by the network, transport or any other layer, then the TSI MUST be included in the LCT header.
LCTは、受信機がLCTセッションに関連している唯一特定できて、「反-マルチプレックス」のパケットであることを必要とします。 特に、それぞれのLCTセッションに関連しているTransport Session Identifier(TSI)があるに違いありません。 TSIはIP送信者のアドレスによって見られます、そして、TSI MUSTに伴うIP送信者のアドレスは唯一セッションを特定します。 基本的な輸送がRFC768[16]で説明されるようにUDPであるなら、16ビットのUDPソースポート番号はセッションのためにTSIとして機能するかもしれません。 TSI値はそれがパケットの中に起こるすべての場所で同じであるに違いありません。 提供されたどんな基本的なTSIもなければ、ネットワークか輸送か次に、いかなる他の層、TSI MUSTによっても、LCTヘッダーに含まれてください。
LCT is presumed to be used with an underlying network or transport service that is a "best effort" service that does not guarantee packet reception or packet reception order, and which does not have any support for flow or congestion control. For example, the Any- Source Multicast (ASM) model of IP multicast as defined in RFC 1112 [5] is such a "best effort" network service. While the basic service provided by RFC 1112 is largely scalable, providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially in presence of heterogeneous sets of receivers.
LCTはあえてパケットレセプションかパケット収容命令を保証しないで、また流れか輻輳制御の少しのサポートも持っていない「ベストエフォート型」のサービスである基本的なネットワークか輸送サービスと共に使用されます。 例えば、RFC1112[5]の定義されるとしてのIPマルチキャストのAnyソースMulticast(ASM)モデルはそのように「ベストエフォート型」のネットワーク・サービスです。 RFC1112によって提供された基本サービスが主にスケーラブルである間、厳しいスケーラビリティ制限を避けるために慎重に輻輳制御か信頼性を提供するべきです、特に種々雑多なセットの受信機の存在で。
There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in RFC 1112 [5] and the Source- Specific Multicast (SSM) model as defined in [10]. LCT 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 the LCT channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and the LCT channel address coincides with the SSM channel address.
現在、マルチキャスト配送の2つのモデル、RFC1112[5]で定義されるAny-ソースMulticast(ASM)モデル、および[10]で定義されるSource特定のMulticast(SSM)モデルがあります。 LCTは両方のマルチキャストモデル、しかし、いくらか異なった環境問題があるわずかに異なった方法で働いています。 ASMを使用して、送付者SがマルチキャストグループGにパケットを送って、LCTチャンネル・アドレスが組(S、G)から成るとき、SがどこのIP送信者のアドレスとGであるかはマルチキャストグループアドレスです。 SSMを使用するとき、送付者SはSSMチャンネル(S、G)にパケットを送ります、そして、LCTチャンネル・アドレスはSSMチャンネル・アドレスと一致しています。
Luby, et. al. Experimental [Page 9] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [9ページ]実験的なRFC3451LCTブロック2002年12月
A sender can locally allocate unique SSM channel addresses, and this makes allocation of LCT channel addresses easy with SSM. To allocate LCT channel addresses using ASM, the sender must uniquely chose the ASM multicast group address across the scope of the group, and this makes allocation of LCT channel addresses more difficult with ASM.
送付者は局所的にユニークなSSMチャンネル・アドレスを割り当てることができます、そして、これで、LCTチャンネル・アドレスの配分はSSMで簡単になります。 唯一ASM、送付者を使用するのがそうしなければならないチャンネル・アドレスをLCTに割り当てるのはグループの範囲の向こう側にASMマルチキャストグループアドレスを選びました、そして、これで、LCTの配分はASMによって、より難しいアドレスを向けます。
LCT channels and SSM channels coincide, and thus the receiver will only receive packets sent to the requested LCT channel. With ASM, the receiver joins an LCT 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.
LCTチャンネルとSSMチャンネルは一致します、そして、その結果、受信機は要求されたLCTチャンネルに送られたパケットを受けるだけでしょう。 ASMに、マルチキャストグループGに加わることによって、受信機はLCTチャンネルに加わります、そして、受信機は送付者にかかわらずGに送られたすべてのパケットを受け取るかもしれません。その結果、SSMはサービス不能攻撃の防止のためのASMの上に無視できないセキュリティ上の利点を持っています。 どちらの場合ではも、受信機SHOULDは、求められていないソースからパケットを無視するのにメカニズムを使用します。
Some networks are not amenable to some congestion control protocols that could be used with LCT. 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.
ネットワークの中にはLCTと共に使用できたいくつかの混雑制御プロトコルに従順でないものもあります。 衛星かワイヤレス・ネットワークのために、セッションまで割り当てられた固定通信速度があるかもしれないので事実上、受信機がそれらのレセプション率を低下させるメカニズムは全く特にないかもしれません。
4.2 Delivery service models
4.2 デリバリ・サービスモデル
LCT can support several different delivery service models. Two examples are briefly described here.
LCTは数個の異なったデリバリ・サービスモデルをサポートできます。 2つの例がここで簡潔に説明されます。
Push service model.
サービスモデルを押してください。
One way a push service model can be used for reliable content delivery is to deliver a series of objects. For example, a receiver could join the session and dynamically adapt the number of LCT channels the receiver is joined to until enough packets have been received to reconstruct an object. After reconstructing the object the receiver may stay in the session and wait for the transmission of the next object.
信頼できる内容物配送にプッシュサービスモデルを使用できる1つの方法は一連のオブジェクトを提供することです。 例えば、受信機は、オブジェクトを再建するために十分なパケットを受け取るまでセッションに参加して、ダイナミックに受信機が加わられるLCTチャンネルの数を適合させるかもしれません。 オブジェクトを再建した後に、受信機は、セッションのときに滞在して、次のオブジェクトのトランスミッションを待つかもしれません。
The push model is particularly attractive in satellite networks and wireless networks. In these cases, a session may consist of one fixed rate LCT channel.
プッシュモデルは衛星ネットワークとワイヤレス・ネットワークで特に魅力的です。 これらの場合では、セッションは1個の定率LCTチャンネルから成るかもしれません。
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 the object. For example a popular software update might be transmitted
要求次第の内容物配送サービスモデルのために、すべての所定の受信者がセッションに参加して、オブジェクトを回収するのを許容できるくらい長いのが選択されて、送付者はいつかの与えられた期間、通常伝わります。 例えばポピュラーなソフトウェアアップデートは伝えられるかもしれません。
Luby, et. al. Experimental [Page 10] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [10ページ]実験的なRFC3451LCTブロック2002年12月
using LCT 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.
受信機が接続時間の1時間の合計におけるダウンロードを終了できるかもしれませんが、数日間LCTを使用するのは恐らく時間のいくつかの間隔にわたって広まりました。
In this case the receivers join the session, and dynamically adapt the number of LCT channels they subscribe to according to the available bandwidth. Receivers then drop from the session when they have received enough packets to recover the object.
この場合、受信機は、セッションに参加して、ダイナミックに利用可能な帯域幅に従って彼らが加入するLCTチャンネルの数を適合させます。 そして、受信機は彼らがオブジェクトを回収できるくらいのパケットを受けたセッションから低下します。
As an example, assume that an object is 50 MB. The sender could send 1 KB packets to the first LCT channel at 50 packets per second, so that receivers using just this LCT channel could complete reception of the object in 1,000 seconds in absence of loss, and would be able to complete reception even in presence of some substantial amount of losses with the use of coding for reliability. Furthermore, the sender could use a number of LCT channels such that the aggregate rate of 1 KB packets to all LCT channels is 1,000 packets per second, so that a receiver could be able to complete reception of the object in as little 50 seconds (assuming no loss and that the congestion control mechanism immediately converges to the use of all LCT channels).
例として、オブジェクトが50MBであると仮定してください。 送付者は第1代1秒あたり50のパケットのLCTチャンネルに1KBのパケットを送ることができました、まさしくこのLCTチャンネルを使用する受信機が損失の欠如で1,000秒でオブジェクトのレセプションを完成できて、コード化の信頼性の使用によるいくらかのかなりの量の損失の存在におけるさえレセプションを終了できるように。 その上、送付者は多くのLCTチャンネルに、したがって、1KBのパケット対すべてのLCTチャンネルの集合レートが1秒あたり1,000のパケットであるように受信機が同じくらい少ししか50秒にオブジェクトのレセプションを終了できなかったものを使用できました(損失がなくて、混雑制御機構がすぐにすべてのLCTチャンネルの使用に一点に集まると仮定して)。
Other service models.
他のサービスはモデル化されます。
There are many other delivery service models that LCT can be used for that are not covered above. As examples, a live streaming or an on- demand archival content streaming service model. A description of the many potential applications, the appropriate delivery service model, and the additional mechanisms to support such functionalities when combined with LCT is beyond the scope of this document. This document only attempts to describe the minimal common scalable elements to these diverse applications using LCT as the delivery transport.
他の配送がカバーされていないそのLCTを使用できるモデルにサービスを提供する多くがあります。 または、例、ライブストリーミング、オンである、記録保管所の満足しているストリーミングのサービスモデルを要求してください。 LCTに結合されると、多くの潜在的アプリケーション、適切なデリバリ・サービスモデル、およびそのような機能性をサポートする追加メカニズムの記述はこのドキュメントの範囲を超えています。 このドキュメントは、配送輸送としてLCTを使用することで最小量の一般的なスケーラブルな要素をこれらのさまざまのアプリケーションに説明するのを試みるだけです。
4.3 Congestion Control
4.3 輻輳制御
The specific congestion control protocol to be used for LCT sessions depends on the type of content to be delivered. While the general behavior of the congestion control protocol is to reduce the throughput in presence of congestion and gradually increase it in the absence of congestion, the actual dynamic behavior (e.g. response to single losses) can vary.
LCTセッションに使用されるべき特定の混雑制御プロトコルは提供される内容のタイプに頼っています。 混雑制御プロトコルの一般的な振舞いが混雑の存在でスループットを減らして、混雑がないとき徐々にそれを増強することですが、実際の動的挙動(例えば、単一の損失への応答)は異なることができます。
Some possible congestion control protocols for reliable content delivery using LCT are described in [22], [3], and [25]. Different delivery service models might require different congestion control protocols.
LCTを使用する信頼できる内容物配送のためのいくつかの可能な混雑制御プロトコルが[22]、[3]、および[25]で説明されます。 異なったデリバリ・サービスモデルは異なった混雑制御プロトコルを必要とするかもしれません。
Luby, et. al. Experimental [Page 11] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [11ページ]実験的なRFC3451LCTブロック2002年12月
5. Packet Header Fields
5. パケットのヘッダー分野
Packets sent to an LCT session MUST include an "LCT header". The LCT header format described below is the default format, and this is the format that is recommended for use by protocol instantiations to ensure a uniform format across different protocol instantiations. Other LCT header formats MAY be used by protocol instantiations, but if the default LCT header format is not used by a protocol instantiation that uses LCT, then the protocol instantiation MUST specify the lengths and positions within the LCT header it uses of all fields described in the default LCT header.
LCTセッションに送られたパケットは「LCTヘッダー」を含まなければなりません。 以下で説明されたLCTヘッダー形式は省略時書式です、そして、これはプロトコル具体化による使用が異なったプロトコル具体化の向こう側に一定の形式を確実にすることが勧められる書式です。 他のLCTヘッダー形式はプロトコル具体化によって使用されるかもしれませんが、デフォルトLCTヘッダー形式がLCTを使用するプロトコル具体化によって使用されないなら、プロトコル具体化はそれが使用するデフォルトLCTヘッダーで説明されたすべての分野のLCTヘッダーの中に長さと位置を指定しなければなりません。
Other building blocks MAY describe some of the same fields as described for the LCT header. It is RECOMMENDED that protocol instantiations using multiple building blocks include shared fields at most once in each packet. Thus, for example, if another building block is used with LCT that includes the optional Expected Residual Time field, then the Expected Residual Time field SHOULD be carried in each packet at most once.
他のブロックは、同じ分野のいくつかがLCTヘッダーのために説明されていると記述するかもしれません。 複数のブロックを使用するプロトコル具体化が各パケットに高々一度共有された分野を含んでいるのは、RECOMMENDEDです。 別のブロックが使用されているなら、このようにして、例えば、任意のExpected Residual Time分野、次に、Expected Residual Time分野SHOULDを含んでいるLCTと共に各パケットで高々一度運ばれてください。
The position of the LCT header within a packet MUST be specified by any protocol instantiation that uses LCT.
LCTを使用するどんなプロトコル具体化でもパケットの中のLCTヘッダーの位置を指定しなければなりません。
5.1 Default LCT header format
5.1 デフォルトLCTヘッダー形式
The default LCT header is of variable size, which is specified by a length field in the third byte of the header. In the LCT 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).
デフォルトLCTヘッダーは可変サイズのものです。(それは、ヘッダーの3番目のバイトにおける長さの分野によって指定されます)。 LCTヘッダーでは、すべての整数野原が最初に、すなわち、「ビッグエンディアン」か「ネットワークオーダー」形式、最も重要なバイト(八重奏)で運ばれます。 「詰め物」か「予約された」(r)が0へのセットによって指定されなければならないように送付者によって指定されて、受信機によって無視されたビット。 別の方法で注意されない場合、小数(ベース10)にはこの仕様による数値定数があります。
The format of the default LCT header is depicted in Figure 1.
デフォルトLCTヘッダーの書式は図1に表現されます。
Luby, et. al. Experimental [Page 12] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [12ページ]実験的なRFC3451LCTブロック2002年12月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*(C+1) bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32*O+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if T = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if R = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V| C| r|S| O|H|T|R|A|B| HDR_レン| Codepoint(CP)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 混雑Control情報(32*(C+1)CCI、長さ=ビット)| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 輸送Session Identifier(32*S+16*H TSI、長さ=ビット)| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 輸送Object Identifier(32*O+16*H TOI、長さ=ビット)| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者電流時間、(SCT T=1であるなら| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 残りの時間を予想する、(ERT R=1であるなら| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヘッダーExtensions(適切であるなら)| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Default LCT header format
図1--デフォルトLCTヘッダー形式
The function and length of each field in the default LCT header is the following. Fields marked as "1" mean that the corresponding bits MUST be set to "1" by the sender. Fields marked as "r" or "0" mean that the corresponding bits MUST be set to "0" by the sender.
デフォルトLCTヘッダーのそれぞれの分野の機能と長さは以下です。 分野、マークされる、「1インチは、「送付者による1インチ」に対応するビットを設定しなければならないことを意味します。 または、分野が「r」としてマークした、「0インチは、「送付者による0インチ」に対応するビットを設定しなければならないことを意味します。
LCT version number (V): 4 bits
LCTバージョン番号(V): 4ビット
Indicates the LCT version number. The LCT version number for
this specification is 1.
LCTバージョン番号を示します。 この仕様のLCTバージョン番号は1です。
Congestion control flag (C): 2 bits
輻輳制御旗(C): 2ビット
C=0 indicates the Congestion Control Information (CCI) field is
32-bits in length. C=1 indicates the CCI field is 64-bits in
length. C=2 indicates the CCI field is 96-bits in length. C=3
indicates the CCI field is 128-bits in length.
C=0は、長さがCongestion Control情報(CCI)分野が32ビットであることを示します。 C=1は、長さがCCI分野が64ビットであることを示します。 C=2は、長さがCCI分野が96ビットであることを示します。 C=3は、長さがCCI分野が128ビットであることを示します。
Reserved (r): 2 bits
予約された(r): 2ビット
Reserved for future use. A sender MUST set these bits to zero
and a receiver MUST ignore these bits.
今後の使用のために、予約されます。 送付者はこれらのビットをゼロに設定しなければなりません、そして、受信機はこれらのビットを無視しなければなりません。
Luby, et. al. Experimental [Page 13] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [13ページ]実験的なRFC3451LCTブロック2002年12月
Transport Session Identifier flag (S): 1 bit
Session Identifier旗(S)を輸送してください: 1ビット
This is the number of full 32-bit words in the TSI field. The
TSI field is 32*S + 16*H bits in length, i.e. the length is
either 0 bits, 16 bits, 32 bits, or 48 bits.
これはTSI分野の完全な32ビットの単語の数です。 長さがTSI分野が32*S+16*Hビットである、すなわち、長さは0ビット(16ビット、32ビット、または48ビットビット)どちらかです。
Transport Object Identifier flag (O): 2 bits
Object Identifier旗(O)を輸送してください: 2ビット
This is the number of full 32-bit words in the TOI field. The
TOI field is 32*O + 16*H bits in length, i.e., the length is
either 0 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96
bits, or 112 bits.
これはTOI分野の完全な32ビットの単語の数です。 長さがTOI分野が32*O+16*Hビットである、すなわち、長さは、0ビット、16ビット、32ビット、48ビット、64ビット、80ビット、96ビット、または112ビットです。
Half-word flag (H): 1 bit
旗(H)を半分言い表してください: 1ビット
The TSI and the TOI fields are both multiples of 32-bits plus
16*H bits in length. This allows the TSI and TOI field lengths
to be multiples of a half-word (16 bits), while ensuring that
the aggregate length of the TSI and TOI fields is a multiple of
32-bits.
TSIとTOI分野は長さが32ビットのプラス16*Hビットの両方の倍数です。 TSIとTOI分野の集合長さが32ビットの倍数であることを確実にしている間、これは、TSIとTOIフィールド長がハーフ・ワード(16ビット)の倍数であることを許容します。
Sender Current Time present flag (T): 1 bit
送付者Current Timeは旗(T)を提示します: 1ビット
T = 0 indicates that the Sender Current Time (SCT) field is not
present. T = 1 indicates that the SCT field is present. The
SCT is inserted by senders to indicate to receivers how long
the session has been in progress.
T=0は、Sender Current Time(SCT)分野が存在していないのを示します。 T=1は、SCT分野が存在しているのを示します。 SCTは、セッションは進行中がどれくらい長いかを受信機に示すために送付者によって挿入されます。
Expected Residual Time present flag (R): 1 bit
予想されたResidual Timeは旗(R)を提示します: 1ビット
R = 0 indicates that the Expected Residual Time (ERT) field is
not present. R = 1 indicates that the ERT field is present.
The ERT is inserted by senders to indicate to receivers how
much longer the session / object transmission will continue.
R=0は、Expected Residual Time(ERT)分野が存在していないのを示します。 R=1は、ERT分野が存在しているのを示します。 ERTは、セッション/オブジェクトトランスミッションがどれほど長い間続くかを受信機に示すために送付者によって挿入されます。
Senders MUST NOT set R = 1 when the ERT for the session is more
than 2^32-1 time units (approximately 49 days), where time is
measured in units of milliseconds.
SendersはセッションのためのERTが2^32-1タイム・ユニット(およそ49日間)以上であることのR=1を設定してはいけません。そこでは、時間がユニットのミリセカンドで測定されます。
Close Session flag (A): 1 bit
Session旗(A)を閉じてください: 1ビット
Normally, A is set to 0. The sender MAY set A to 1 when
termination of transmission of packets for the session is
imminent. A MAY be set to 1 in just the last packet
transmitted for the session, or A MAY be set to 1 in the last
few seconds of packets transmitted for the session. Once the
sender sets A to 1 in one packet, the sender SHOULD set A to 1
in all subsequent packets until termination of transmission of
通常、Aは0に設定されます。 セッションのためのパケットのトランスミッションの終了が差し迫っているとき、送付者は1にAを設定するかもしれません。 Aがまさしくセッションのために伝えられた最後のパケットの1に設定されるかもしれませんか、またはAはセッションのために伝えられた最後の数秒のパケットの1に設定されるかもしれません。 送付者がいったん1つのパケットに1へのAをはめ込むと、送付者SHOULDはトランスミッションの終了まですべてのその後のパケットの1にAを設定します。
Luby, et. al. Experimental [Page 14] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [14ページ]実験的なRFC3451LCTブロック2002年12月
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.
セッションのためのパケット。 1に設定されたAがある容認されたパケットは、送付者が、すぐにセッションのためにパケットを送るのを止めるのを受信機に示します。 受信機が1に設定されたAと共にパケットを受けるとき、受信機SHOULDは、それ以上のパケットが全くセッションに送られないと仮定します。
Close Object flag (B): 1 bit
Object旗(B)を閉じてください: 1ビット
Normally, B is set to 0. The sender MAY set B to 1 when
termination of transmission of packets for an object is
imminent. If the TOI field is in use and B is set to 1 then
termination of transmission for the object identified by the
TOI field is imminent. If the TOI field is not in use and B is
set to 1 then termination of transmission for the one object in
the session identified by out-of-band information is imminent.
B MAY be set to 1 in just the last packet transmitted for the
object, or B MAY be set to 1 in the last few seconds packets
transmitted for the object. Once the sender sets B to 1 in one
packet for a particular object, the sender SHOULD set B to 1 in
all subsequent packets for the object until termination of
transmission of packets for the object. A received packet with
B set to 1 indicates to a receiver that the sender will
immediately stop sending packets for the object. When a
receiver receives a packet with B set to 1 then it SHOULD
assume that no more packets will be sent for the object to the
session.
通常、Bは0に設定されます。 オブジェクトのためのパケットのトランスミッションの終了が差し迫っているとき、送付者は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は、それ以上のパケットが全くオブジェクトのためにセッションに送られないと仮定します。
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., to the first other header if it
exists, or to the packet payload if it exists and there is no
other header, or to the end of the packet if there are no other
headers or packet payload.
ユニットの32ビットの単語によるLCTヘッダーの全長。 LCTヘッダーの長さは32ビットの倍数であるに違いありません。 存在していて、他のヘッダーが全くないか、またはパケットの端まで使用されるなら、それが存在しているか、またはパケットペイロードに使用されるなら、直接すなわち、LCTヘッダー、他の最初のヘッダーにパケットの一部にアクセスするのにこの分野を使用できます。どんな他のヘッダーもパケットペイロードもなければ。
Codepoint (CP): 8 bits
Codepoint(CP): 8ビット
An opaque identifier which is passed to the packet payload
decoder to convey information on the codec being used for the
packet payload. The mapping between the codepoint and the
actual codec is defined on a per session basis and communicated
out-of-band as part of the session description information.
The use of the CP field is similar to the Payload Type (PT)
field in RTP headers as described in RFC 1889 [21].
コーデックの上で情報を伝達するためにパケットペイロードに使用されることでパケットペイロードデコーダに通過される不明瞭な識別子。 codepointと実際のコーデックの間のマッピングは、セッション記述情報の一部としてセッション基礎あたりのaで定義されて、バンドの外で伝えられます。 CP分野の使用はRFC1889[21]で説明されるようにRTPヘッダーの有効搭載量Type(太平洋標準時の)分野と同様です。
Luby, et. al. Experimental [Page 15] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [15ページ]実験的なRFC3451LCTブロック2002年12月
Congestion Control Information (CCI): 32, 64, 96 or 128 bits
輻輳制御情報(CCI): 64ビットか96ビットか32ビットか128ビット
Used to carry congestion control information. For example, the
congestion control information could include layer numbers,
logical channel numbers, and sequence numbers. This field is
opaque for the purpose of this specification.
混雑制御情報を運ぶのにおいて、使用されています。 例えば、混雑制御情報は層の番号、論理チャネル番号、および一連番号を含むかもしれません。 この分野はこの仕様の目的のために不透明です。
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ビットでなければなりません。
Transport Session Identifier (TSI): 0, 16, 32 or 48 bits
セッション識別子(TSI)を輸送してください: 16ビットか32ビットか0ビットか48ビット
The TSI uniquely identifies a session among all sessions from a
particular sender. The TSI is scoped by the IP address of the
sender, and thus the IP address of the sender and the TSI
together uniquely identify the session. Although a TSI in
conjunction with the IP address of the sender always uniquely
identifies a session, whether or not the TSI is included in the
LCT header depends on what is used as the TSI value. If the
underlying transport is UDP, then the 16 bit UDP source port
number MAY serve as the TSI for the session. If the TSI value
appears multiple times in a packet then all occurrences MUST be
the same value. If there is no underlying TSI provided by the
network, transport or any other layer, then the TSI MUST be
included in the LCT header.
TSIはすべてのセッションのときに特定の送付者からセッションを唯一特定します。 TSIはIP送信者のアドレスによって見られます、そして、その結果、IP送信者のアドレスと一緒にTSIは唯一セッションを特定します。 IP送信者のアドレスに関連したTSIはいつも唯一セッションを特定しますが、TSIがLCTヘッダーに含まれているかどうかがTSIが評価するように何が使用されているかによります。 基本的な輸送がUDPであるなら、16ビットのUDPソースポート番号はセッションのためにTSIとして機能するかもしれません。 TSI値がパケットに複数の回現れるなら、すべての発生が同じ値であるに違いありません。 提供されたどんな基本的なTSIもなければ、ネットワークか輸送か次に、いかなる他の層、TSI MUSTによっても、LCTヘッダーに含まれてください。
The TSI MUST be unique among all sessions served by the sender
during the period when the session is active, and for a large
period of time preceding and following when the session is
active. A primary purpose of the TSI is to prevent receivers
from inadvertently accepting packets from a sender that belong
to sessions other than the 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ビットの倍数であることに注意してください。
Luby, et. al. Experimental [Page 16] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [16ページ]実験的なRFC3451LCTブロック2002年12月
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ビットの倍数であることに注意してください。
Sender Current Time (SCT): 0 or 32 bits
送付者電流時間(SCT): 0ビットか32ビット
This field represents the current clock at the sender and 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であるなら存在していなければなりません。
Expected Residual Time (ERT): 0 or 32 bits
残りの時間(ERT)は予想しました: 0ビットか32ビット
This field represents the sender expected residual transmission
time for the current session or for the transmission of the
current object, measured in units of 1ms. If the packet
containing the ERT field also contains the TOI field, then ERT
refers to the object corresponding to the TOI field, otherwise
it refers to the session.
この分野は現在のセッションか現在のオブジェクトのトランスミッションのための送付者の予想された残りのトランスミッション時間を表します。ユニットの1ms. Ifで測定されて、また、ERT分野を含むパケットはTOI分野を含んでいます。次に、ERTはTOI分野に対応するオブジェクトについて言及します。さもなければ、それはセッションを参照します。
This field MUST NOT be present if R=0 and MUST be present if
R=1.
この分野は、R=0であるなら存在しているはずがなくて、R=1であるなら存在していなければなりません。
5.2 Header-Extension Fields
5.2 ヘッダー拡大分野
Header Extensions are used in LCT to accommodate optional header fields that are not always used or have variable size. Examples of the use of Header Extensions include:
ヘッダーExtensionsは、いつも使用されるというわけではない任意のヘッダーフィールドを収容するか、または可変サイズを持つのにLCTで使用されます。 Header Extensionsの使用に関する例は:
o Extended-size versions of already existing header fields.
o 既に既存のヘッダーフィールドの拡張サイズバージョン。
Luby, et. al. Experimental [Page 17] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [17ページ]実験的なRFC3451LCTブロック2002年12月
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 LCT without changing the LCT version number. Non backward-compatible header extensions CANNOT be introduced without changing the LCT version number.
存在しているなら、どんな輻輳制御手順も実行するか、または別の方法でパケットを受け入れる前に彼らが認識されるのを保証するためにHeader Extensionsを処理しなければなりません。 認識されていないヘッダー拡大のためのデフォルト動作はそれらを無視することです。 LCTバージョン番号を変えないで、これは後方コンパチブル増進の今後の導入をLCTに許します。 非後方、コンパチブル、LCTバージョン番号を変えないで、ヘッダー拡大は導入されません。
Protocol instantiation MAY override this default behavior for PI- specific extensions (see below).
プロトコル具体化はPIの特定の拡張子のためのこのデフォルトの振舞いをくつがえすかもしれません(以下を見てください)。
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 2 - Format of additional headers
図2--追加ヘッダーの形式
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
Header Extensionのタイプ。 このドキュメントは多くの可能なタイプを定義します。 追加タイプは中で定義されるかもしれません。
Luby, et. al. Experimental [Page 18] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [18ページ]実験的なRFC3451LCTブロック2002年12月
future versions of this specification. HET values from 0 to
127 are used for variable-length Header Extensions. HET values
from 128 to 255 are used for fixed-length 32-bit Header
Extensions.
この仕様の将来のバージョン。 0〜127までのHET値は可変長の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
specified by the HEL field. Note that the length of each
Header Extension field MUST be a multiple of 32 bits. Also
note that the total size of the LCT header, including all
Header Extensions and all optional header fields, cannot exceed
255 32-bit words.
Header Extensionの内容。 このサブ分野の形式はHeader Extensionタイプに頼っています。 固定長Header Extensionsに関しては、HECは24ビットです。 可変長のHeader Extensionsに関しては、HEC分野には、可変サイズが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バージョン番号を変えないで、ヘッダー拡大は導入されません。
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
EXT_AUTH=1 Packet認証拡大情報は以前はよくパケットの送付者を認証していました。 そして、このHeader Extensionの形式、それ
Luby, et. al. Experimental [Page 19] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [19ページ]実験的なRFC3451LCTブロック2002年12月
processing is outside the scope of this document and is
to be communicated out-of-band as part of the session
description.
処理は、セッション記述の一部としてこのドキュメントの範囲の外にあって、バンドの外でコミュニケートされることです。
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.
送付者が何らかの形式のパケット認証を提供するのは、RECOMMENDEDです。 EXT_AUTHが存在しているなら、すぐパケットを受け入れる前に、実行されて、どんな混雑のコントロール関連の動作もそれに実行するパケットSHOULDのレセプションにそれをチェックするどんなパケット認証も実行できます。
Some packet authentication schemes impose a delay of
several seconds between when a packet is received and
when the packet is fully authenticated. Any congestion
control related action that is appropriate MUST NOT be
postponed by any such full packet authentication.
いくつかのパケット認証計画がパケットが受け取られている時、パケットが完全に認証されるときに時数秒の遅れを課します。 そのようなどんな完全なパケット認証でもどんな適切な輻輳制御関連する動きも延期してはいけません。
All senders and receivers implementing LCT MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to parse its content.
すべての送付者とLCT MUSTを実行する受信機は、EXT_NOP Header Extensionを支持して、EXT_AUTHを認識しなければなりませんが、内容を分析できないかもしれません。
6. Operations
6. 操作
6.1 Sender Operation
6.1 送付者操作
Before joining an LCT session a receiver MUST obtain a session description. The session description MUST include:
LCTセッションに参加する前に、受信機はセッション記述を得なければなりません。 セッション記述は以下を含まなければなりません。
o The sender IP address;
o 送付者IPアドレス。
o The number of LCT channels;
o LCTチャンネルの数。
o The addresses and port numbers used for each LCT channel;
o それぞれのLCTチャンネルに使用されるアドレスとポートナンバー。
o The Transport Session ID (TSI) to be used for the session;
o セッションに使用されるべきTransport Session ID(TSI)。
o Enough information to determine the congestion control protocol
being used;
o 使用される混雑制御プロトコルは決定できるくらいの情報。
o Enough information to determine the packet authentication scheme
being used if it is being used.
o それが使用されているなら使用されるパケット認証計画は決定できるくらいの情報。
The session description could also include, but is not limited to:
また、含むことができましたが、セッション記述は制限されません:
o The data rates used for each LCT channel;
o それぞれのLCTチャンネルに使用されるデータ信号速度。
o The length of the packet payload;
o パケットペイロードの長さ。
Luby, et. al. Experimental [Page 20] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [20ページ]実験的なRFC3451LCTブロック2002年12月
o The mapping of TOI value(s) to objects for the session;
o セッションのための物へのTOI価値に関するマッピング。
o Any information that is relevant to each object being
transported, such as when it will be available within the
session, for how long, and the length of the object;
o セッション中にいつどれくらい長く利用可能であるかなるだろうか、そして、物の長さなどのように輸送される各物に関連しているどんな情報も。
Protocol instantiations using LCT MAY place additional requirements on what must be included in the session description. For example, a protocol instantiation might require that the data rates for each channel, or the mapping of TOI value(s) to objects for the session, or other information related to other headers that might be required to be included in the session description.
LCT MAYを使用するプロトコル具体化がセッション記述に含まなければならないことに追加要件を置きます。 例えば、プロトコル具体化は、各チャンネルのためのデータ信号速度、セッションのための物へのTOI価値に関するマッピング、またはそれが他のヘッダーであるかもしれないのに伝える他の情報がセッション記述に含まれるのが必要であることを必要とするかもしれません。
The session description could be in a form such as SDP as defined in RFC 2327 [8], or XML metadata as defined in RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2068 [6], etc. It might be carried in a session announcement protocol such as SAP as defined in RFC 2974 [9], 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 format, and distribution of session descriptions is beyond the scope of this document.
セッション記述がRFC2327[8]、RFC3023[14]で定義されるXMLメタデータ、またはRFC2068[6]で定義されるHTTP/パントマイムヘッダーなどで定義されるようにSDPなどの形にあるかもしれません。 それはRFC2974[9]で定義されるようにSAPなどのセッション発表プロトコルで運ばれるかもしれなくて、独占セッション制御プロトコルであって、ウェブページに位置している情報の、または、何らかのメールを通して運ばれたスケジューリングはバンドの外にある状態で得られた使用が方法です。 セッション記述形式の議論、および記述がこのドキュメントの範囲を超えているセッションの分配。
Within an LCT session, a sender using LCT transmits a sequence of packets, each in the format defined above. Packets are sent from a sender using one or more LCT channels which together constitute a session. Transmission rates may be different in different channels and may vary over time. The specification of the other building block headers and the packet payload used by a complete protocol instantiation using LCT is beyond the scope of this document. This document does not specify the order in which packets are transmitted, nor the organization of a session into multiple channels. Although these issues affect the efficiency of the protocol, they do not affect the correctness nor the inter-operability of LCT between senders and receivers.
LCTセッション以内に、LCTを使用している送付者はそれぞれ上で定義された書式でのパケットの系列を伝えます。 送付者から1つを使用することでパケットを送るか、または、より多くのLCTがどれに一緒にチャネルを開設するか。セッションを構成してください。 通信速度は、異なったチャンネルにおいて異なるかもしれなくて、時間がたつにつれて、異なるかもしれません。 完全なプロトコル具体化によってLCTを使用することで使用される他のブロックヘッダーとパケットペイロードの仕様はこのドキュメントの範囲を超えています。 このドキュメントはパケットが伝えられる注文、およびセッションの組織を複数のチャンネルに指定しません。 これらの問題はプロトコルの効率に影響しますが、それらは正当性に影響しません。または、送付者と受信機の間のLCTの相互運用性。
Several objects can be carried within the same LCT session. In this case, each object MUST be identified by a unique TOI. Objects MAY be transmitted sequentially, or they MAY be transmitted concurrently. 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.
同じLCTセッション中に数個の物を運ぶことができます。 この場合、ユニークなTOIは各物を特定しなければなりません。 物が連続して伝えられるかもしれませんか、またはそれらは同時に伝えられるかもしれません。 セッションのその部分に参加する受信機がすべての物を受けるのに関心を持っているなら、同じセッションのときに同時に物を唯一の送るのは、良い習慣です。 この理由は中でそれらが持っている物のための受信機受信データを無利子にするのに帯域幅とネットワークリソースを浪費するということです。
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
通常、送付者は、トランスミッションが完全であると考えられるまでセッションのときにパケットを送り続けています。 トランスミッションは時間が吐き出したいくつか、ある数であるなら完全であると考えられるかもしれません。
Luby, et. al. Experimental [Page 21] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [21ページ]実験的なRFC3451LCTブロック2002年12月
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.
パケットを送ったか、または何らかのバンドで出ている信号(ことによるとより高い平らなプロトコルからの)が十分な数の受信機で完成を示しました。
For the reasons mentioned above, this document does not pose any restriction on packet sizes. However, network efficiency considerations recommend that the sender uses an 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 when fragmentation coupled with packet loss might introduce severe inefficiency in the transmission.
前記のように理由で、このドキュメントはパケットサイズにおける少しの制限も引き起こしません。 しかしながら、問題が推薦する送付者が使用する効率をネットワークでつないでください、しかし、パケットペイロードサイズ、そのようなもののパケットがネットワークのマキシマム・トランスミッション・ユニットサイズ(MTU)を超えていないか、または断片化がいつパケット損失に結合したかがトランスミッションにおける厳しい非能率を導入するかもしれないできるだけ大きい方法。
It is recommended that all packets have the same or very similar sizes, as this can have a severe impact on the effectiveness of congestion control schemes such as the ones described in [22], [3], and [25]. A sender of packets using LCT MUST implement the sender- side part of one of the congestion control schemes that is in accordance with RFC 2357 [13] using the Congestion Control Information field provided in the LCT header, and the corresponding receiver congestion control scheme is to be communicated out-of-band and MUST be implemented by any receivers participating in the session.
すべてのパケットには同じであるか非常に同様のサイズがあるのは、お勧めです、これが[22]、[3]、および[25]で説明されたものなどの輻輳制御計画の有効性に厳しい影響力を持つことができるとき。 LCT MUSTを使用するパケットの送付者を対応する受信機輻輳制御計画がRFC2357[13]に応じてCongestion Control情報分野を使用するのがLCTヘッダーに供給されて、バンドの外でコミュニケートすることであるということである輻輳制御計画の1つの送付者サイド一部を実行して、セッションのときに関与するどんな受信機でも実行しなければなりません。
6.2 Receiver Operation
6.2 受信機操作
Receivers can operate differently depending on the delivery service model. For example, for an on demand service model, receivers may join a session, obtain the necessary packets to reproduce the object, and then leave the session. As another example, for a streaming service model, a receiver may be continuously joined to a set of LCT channels to download all objects in a session.
デリバリ・サービスモデルに異なって頼っていて、受信機は動作できます。 例えば、受信機は、オンデマンドのサービスモデルのために、セッションに参加して、物を再生させるために必要なパケットを得て、次に、セッションを出発するかもしれません。 別の例として、ストリーミングのサービスモデルにおいて、受信機は、セッションのときにすべての物をダウンロードするために1セットのLCTチャンネルで絶え間なく加わられるかもしれません。
To be able to participate in a session, a receiver MUST obtain the relevant session description information as listed in Section 6.1.
会議に参加できるように、受信機はセクション6.1に記載されているように関連セッション記述情報を得なければなりません。
If packet authentication information is present in an LCT header, it SHOULD be used as specified in Section 5.2. To be able to be a receiver in a session, the receiver MUST be able to process the LCT 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 a LCT header, it MUST drop from the session.
パケット認証情報はLCTヘッダーに存在していて、それはSHOULDです。指定されるとして、セクション5.2で使用されてください。 セッション、受信機の受信機であることでできるのはLCTヘッダーを処理できなければなりません。 受信機は、他のヘッダーとパケットペイロードを捨てなければならないか、進めなければならないか、格納しなければならないか、または処理できなければなりません。 受信機がLCTヘッダーを処理できないなら、それはセッションから低下しなければなりません。
To be able to participate in a session, a receiver MUST implement the congestion control protocol specified in the session description using the Congestion Control Information field provided in the LCT header. If a receiver is not able to implement the congestion control protocol used in the session, it MUST NOT join the session. When the session is transmitted on multiple LCT channels, receivers MUST
会議に参加できるように、受信機はセッション記述でLCTヘッダーに提供されたCongestion Control情報野原を使用することで指定された混雑制御プロトコルを実行しなければなりません。 受信機がセッションのときに使用された混雑制御プロトコルを実行できないなら、それはセッションに参加してはいけません。 セッションが複数のLCTチャンネルで伝えられるとき、受信機は伝えられなければなりません。
Luby, et. al. Experimental [Page 22] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [22ページ]実験的なRFC3451LCTブロック2002年12月
initially join channels according to the specified startup behavior of the congestion control protocol. For a multiple rate congestion control protocol that uses multiple channels, this typically means that a receiver will initially join only a minimal set of LCT channels, possibly a single one, that in aggregate are carrying packets at a low rate. This rule has the purpose of preventing receivers from starting at high data rates.
初めは、混雑制御プロトコルの指定された始動の振舞いに従って、チャンネルに加わってください。 複数のチャンネルを使用する複数のレート混雑制御プロトコルのために、これは、受信機が初めは1人の極小集合のLCTチャンネルだけ、ことによると低率で集合でパケットを運ぶただ一つのものを接合することを通常意味します。 この規則には、受信機が高いデータ信号速度で始動するのを防ぐ目的があります。
Several objects can be carried either sequentially or concurrently within the same LCT session. In this case, each object is identified by a unique TOI. Note that even if a server 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 LCT 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.
同じLCTセッション中に連続するか同時に数個の物を運ぶことができます。 この場合、各物はユニークなTOIによって特定されます。 前のものと、少なくともいつかの時間、サーバが、新しい物のためにパケットを伝え始める前に古い物のためにパケットを送るのを止めても、ネットワークと基本的なプロトコル層の両方が特に異なったLCTチャンネルの上に送るとパケットを再命令しながらいくつかを引き起こす場合があって、その結果、受信機SHOULD NOTが、新しい物のためのパケットのレセプションが、トランジットにはそれ以上のパケットが全くないことを意味すると仮定することに注意してください。
A receiver MAY be concurrently joined to multiple LCT sessions from one or more senders. The receiver MUST perform congestion control on each such LCT session. If the congestion control protocol allows the receiver some flexibility in terms of its actions within a session then the receiver MAY make choices to optimize the packet flow performance across the multiple LCT sessions, as long as the receiver still adheres to the congestion control rules for each LCT session individually.
受信機は同時に1人以上の送付者から複数のLCTセッションにつながれるかもしれません。 受信機はそのようなそれぞれのLCTセッションのときに輻輳制御を実行しなければなりません。 受信機は複数のLCTセッションの向こう側にパケット流れ性能を最適化するために選択をするかもしれません、混雑制御プロトコルがセッション以内に動作で何らかの柔軟性を受信機に許容するなら受信機がまだ個別にそれぞれのLCTセッションのための混雑制御規則を固く守っている限り。
7. Requirements from Other Building Blocks
7. 他のブロックからの要件
As described in RFC 3048 [23], LCT is a building block that is intended to be used, in conjunction with other building blocks, to help specify a protocol instantiation. A congestion control building block that uses the Congestion Control information field within the LCT header MUST be used by any protocol instantiation that uses LCT, and other building blocks MAY also be used, such as a reliability building block.
RFC3048[23]で説明されるように、LCTはプロトコル具体化を指定するのを助けるのに他のブロックに関連して使用されることを意図するブロックです。 LCTを使用するどんなプロトコル具体化でもLCTヘッダーの中にCongestion Control情報フィールドを使用する混雑制御建家を使用しなければなりません、そして、また、他のブロックは使用されるかもしれません、信頼性のブロックのように。
The congestion control MUST be applied to the LCT session as an entity, i.e., over the aggregate of the traffic carried by all of the LCT channels associated with the LCT session. Some possible schemes are specified in [22], [3], and [25]. The Congestion Control Information field in the LCT header is an opaque field that is reserved to carry information related to congestion control. There MAY also be congestion control Header Extension fields that carry additional information related to congestion control.
実体としてLCTセッションに輻輳制御を適用しなければなりません、すなわち、LCTセッションに関連づけられたLCTチャンネルのすべてによって運ばれた交通の集合の上で。 いくつかの可能な計画が[22]、[3]、および[25]で指定されます。 LCTヘッダーのCongestion Control情報分野は輻輳制御に関連する情報を運ぶために予約される不透明な分野です。 また、輻輳制御に関連する追加情報を運ぶ輻輳制御Header Extension分野があるかもしれません。
Luby, et. al. Experimental [Page 23] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [23ページ]実験的なRFC3451LCTブロック2002年12月
The particular layered encoder and congestion control protocols used with LCT have an impact on the performance and applicability of LCT. For example, some layered encoders used for video and audio streams can produce a very limited number of layers, thus providing a very coarse control in the reception rate of packets by receivers in a session. When LCT is used for reliable data transfer, some FEC codecs are inherently limited in the size of the object they can encode, and for objects larger than this size the reception overhead on the receivers can grow substantially.
プロトコルがLCTと共に使用した特定の層にされたエンコーダと輻輳制御はLCTの性能と適用性に影響を与えます。 例えば、或るものはビデオに使用されるエンコーダを層にしました、そして、オーディオストリームは非常に限られた数の層を作り出すことができます、その結果、受信機はセッションのときに非常に下品なコントロールをパケットのレセプション率に提供します。 LCTが本来信頼できるデータ転送に使用されるとき、いくつかのFECコーデックがそれらがコード化できる物のサイズ、および受信機の上のレセプションオーバーヘッドがこのサイズに実質的に伸びることができるより大きい物のために制限されます。
A more in-depth description of the use of FEC in Reliable Multicast Transport (RMT) protocols is given in [11]. Some of the FEC codecs that MAY be used in conjunction with LCT for reliable content delivery are specified in [12]. The Codepoint field in the LCT header is an opaque field that can be used to carry information related to the encoding of the packet payload.
[11]でReliable Multicast Transport(RMT)プロトコルにおけるFECの使用の、より徹底的な記述を与えます。 信頼できる内容物配送のためのLCTに関連して使用されるかもしれないFECコーデックのいくつかが[12]で指定されます。 LCTヘッダーのCodepoint分野はパケットペイロードのコード化に関連する情報を運ぶのに使用できる不透明な分野です。
LCT also requires receivers to obtain a session description, as described in Section 6.1. The session description could be in a form such as SDP as defined in RFC 2327 [8], or XML metadata as defined in RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2068 [6], and distributed with SAP as defined in RFC 2974 [9], using HTTP, or in other ways. It is RECOMMENDED that an authentication protocol such as IPSEC [11] be used to deliver the session description to receivers to ensure the correct session description arrives.
また、LCTは、セッション記述を得るためにセクション6.1で説明されるように受信機を必要とします。 セッション記述がRFC2068[6]で定義されるRFC3023[14]、またはHTTP/パントマイムヘッダーで定義されて、HTTPを使用して、SAPと共にRFC2974[9]で定義されるように分配されるRFC2327[8]か、XMLメタデータか他の道で定義されるようにSDPなどの形にあるかもしれません。 IPSEC[11]などの認証プロトコルが正しいセッション記述が到着するのを保証するためにセッション記述を受信機に渡すのに使用されるのは、RECOMMENDEDです。
It is recommended that LCT implementors use some packet authentication scheme to protect the protocol from attacks. An example of a possibly suitable scheme is described in [15].
LCT作成者が攻撃からプロトコルを保護するのに何らかのパケット認証計画を使用するのは、お勧めです。 ことによると適当な計画に関する例は[15]で説明されます。
Some protocol instantiations that use LCT MAY use building blocks that require the generation of feedback from the receivers to the sender. However, the mechanism for doing this is outside the scope of LCT.
LCT MAYを使用するいくつかのプロトコル具体化が受信機から送付者まで世代にフィードバックを要求するブロックを使用します。 しかしながら、LCTの範囲の外にこれをするためのメカニズムがあります。
8. Security Considerations
8. セキュリティ問題
LCT can be subject to denial-of-service attacks by attackers which try to confuse the congestion control mechanism, or send forged packets to the session which would prevent successful reconstruction or cause inaccurate reconstruction of large portions of an object by receivers. LCT is particularly affected by such an attack since many receivers may receive the same forged packet. It is therefore RECOMMENDED that an integrity check be made on received objects before delivery to an application, e.g., by appending an MD5 hash [17] to an object before it is sent and then computing the MD5 hash once the object is reconstructed to ensure it is the same as the sent object. Moreover, in order to obtain strong cryptographic integrity
LCTは攻撃者による混雑制御機構を混乱させようとするサービス不能攻撃を受けることがあるか、または受信機でうまくいっている再建か原因を防ぐ偽造セッションまでのパケットに物の大半の不正確な再構成を送ることができます。 多くの受信機が同じ偽造パケットを受けるかもしれないので、LCTはそのような攻撃で特に影響を受けます。 したがって、配送の前に容認された物の上に保全チェックをアプリケーションにするのは、RECOMMENDEDです、例えば、それを送る前にMD5細切れ肉料理[17]を物に追加して、次に、物がそれが送られた物と同じであることを保証するためにいったん再建されるとMD5細切れ肉料理を計算することによって。 そのうえ、強い暗号の保全を得ます。
Luby, et. al. Experimental [Page 24] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [24ページ]実験的なRFC3451LCTブロック2002年12月
protection a digital signature verifiable by the receiver SHOULD be computed on top of such a hash value. It is also RECOMMENDED that protocol instantiations that use LCT implement some form of packet authentication such as TESLA [15] to protect against such attacks. Finally, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent injecting forged packets into the multicast tree data path.
証明可能な保護aデジタル署名、そのようなハッシュ値の上で受信機SHOULDによって計算されてください。 また、LCTを使用するプロトコル具体化がそのような攻撃から守るために何らかの形式のテスラ[15]などのパケット認証を実行するのは、RECOMMENDEDです。 最終的に、Reverse Path Forwardingチェックがすべてのネットワークルータで可能にされるのが、RECOMMENDEDであり、送付者から悪いエージェントが注入する可能性を制限する受信機までの経路に沿ったスイッチはマルチキャスト木のデータ経路にパケットを鍛造しました。
Another vulnerability of LCT 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.
LCTの別の脆弱性はセッションのために不正確なセッション記述を得る受信機の可能性です。 この結果は間違ったセッション記述がある正統の受信機が正しくセッション内容を受け取ろうとすることができないか、または受信機がそれらができるよりはるかに高いレートでうっかり受信しようとするということであるかもしれません、その結果、ネットワークの一部の交通を中断します。 対策が受信機が不正確なSession記述を受け入れるのを防ぐために実施されるのは、これらの問題を避けるためには、RECOMMENDEDです、例えば、受信機が認可された送付者から正統のSession記述を受け入れるだけであるのを保証するのにソース認証を使用することによって。
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です。 このドキュメントの範囲の外に受信機が、自分たちが正統であるとどう認識するかがあります。
9. IANA Considerations
9. IANA問題
No information in this specification is subject to IANA registration.
この仕様によるどんな情報もIANA登録を受けることがありません。
Building blocks used in conjunction with LCT MAY introduce additional IANA considerations.
LCT MAYに関連して使用されるブロックは追加IANA問題を紹介します。
10. Acknowledgments
10. 承認
Thanks to Vincent Roca and Roger Kermode for detailed comments and contributions to this document. Thanks also to Bruce Lueckenhoff, Hayder Radha and Justin Chapweske for detailed comments on this document.
詳細なコメントとこのドキュメントへの貢献をヴィンセント・ロカとロジャー・カーモードをありがとうございます。 また、このドキュメントの詳細なコメントをブルースLueckenhoff、Hayderラダ、およびジャスティンChapweskeをありがとうございます。
11. References
11. 参照
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
Luby, et. al. Experimental [Page 25] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [25ページ]実験的なRFC3451LCTブロック2002年12月
[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] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,
Roetter, A. and W. Shaver, "FLID-DL: Congestion Control for
Layered Multicast", Proceedings of Second International Workshop
on Networked Group Communications (NGC 2000), Palo Alto, CA,
November 2000.
[3] バイアーズ、J.W.、Frumin、M.、角、G.、Luby、M.、Mitzenmacher、M.、Roetter、A.、およびW.シェーバー、「FLID-dl:」 「層にされたマルチキャストのための輻輳制御」、(NGC2000)、ネットワークでつながれたグループCommunicationsパロアルト(カリフォルニア)(2000年11月)における第2国際ワークショップの議事。
[4] Byers, J.W., Luby, M., Mitzenmacher, M. and A. Rege, "A Digital
Fountain Approach to Reliable Distribution of Bulk Data",
Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.
[4] バイアーズとJ.W.とLubyとM.とMitzenmacherとM.とA.リージ、「大量のデータの信頼できる分配へのデジタル噴水アプローチ」、議事ACM SIGCOMM98年(バンクーバー(カナダ)1998年9月)。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[5] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2616, January 1997.
[6] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1997年ハイパーテキスト転送プロトコル--1月」。
[7] Gemmell, J., Schooler, E. and J. Gray, "Fcast Multicast File
Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January
2000.
[7]GemmellとJ.とSchoolerとE.とJ.グレー、「Fcastマルチキャストファイル分配」、IEEE Network、Vol.14、No.1、ページ 58-68と、2000年1月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[8] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[9] ハンドレーとM.とパーキンスとC.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[10] Holbrook, H. W., "A Channel Model for Multicast", Ph.D.
Dissertation, Stanford University, Department of Computer
Science, Stanford, California, August 2001.
[10]ホルブルック、H.W.、「マルチキャストのためのチャンネルモデル」、博士号Dissertation、スタンフォード大学、コンピュータサイエンス学部、スタンフォード、カリフォルニア(2001年8月)。
[11] 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.
[11]LubyとM.とVicisanoとL.とGemmellとJ.とリゾーとL.とハンドレーとM.とJ.クロウクロフト、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」、RFC3453、2002年12月。
[12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
J. Crowcroft, "Forward Error Correction (FEC) Building Block",
RFC 3452, December 2002.
[12] Luby(M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト)は「エラー修正(FEC)ブロックを進めます」、RFC3452、2002年12月。
[13] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[13] マンキン、A.、Romanow、A.、ブラドナー、S.、および「信頼できるマルチキャスト輸送とアプリケーション・プロトコルを評価するIETF評価基準」、RFC2357(1998年6月)対パクソン
[14] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[14] ムラタとM.と聖ローランとS.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
Luby, et. al. Experimental [Page 26] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [26ページ]実験的なRFC3451LCTブロック2002年12月
[15] 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.
[15]PerrigとA.とカネッティとR.とSongとD.とJ.D.Tygarと「マルチキャストのための効率的で安全なソース認証」とNetworkとDistributed System Security Symposium、NDSS2001、ページ 35-46と、2001年2月。
[16] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[16] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[17] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[18] Rizzo, L., "Effective Erasure Codes for Reliable Computer
Communication Protocols", ACM SIGCOMM Computer Communication
Review, Vol.27, No.2, pp.24-36, Apr 1997.
[18] リゾー、L.、「有効な消去は高信頼のコンピュータのために通信プロトコルをコード化します」、ACM SIGCOMMコンピュータCommunication Review、Vol.27、No.2、pp.24-36、1997年4月。
[19] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast
congestion control scheme", Proceedings of SIGCOMM 2000,
Stockholm Sweden, August 2000.
[19] リゾー、L、「PGMCC:」 SIGCOMM2000のProceedings、ストックホルムスウェーデン2000年8月の「TCPに優しい単一賃率マルチキャスト輻輳制御計画。」
[20] Rizzo, L and L. Vicisano, "Reliable Multicast Data Distribution
protocol based on software FEC techniques", Proceedings of the
Fourth IEEES Workshop on the Architecture and Implementation of
High Performance Communication Systems, HPCS'97, Chalkidiki
Greece, June 1997.
[20] リゾーとLとL.Vicisano、「信頼できるMulticast Data DistributionはソフトウェアFECのテクニックに基づいて議定書を作る」Architectureの上のFourth IEEES WorkshopとHighパフォーマンスCommunication Systems、HPCS97年、Chalkidikiギリシア(1997年6月)のImplementationのProceedings。
[21] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[21]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[22] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion
Control for Layered Multicast Data Transfer", IEEE Infocom'98,
San Francisco, CA, Mar.28-Apr.1 1998.
[22]VicisanoとL.とリゾーとL.とJ.クロウクロフト、「層にされたマルチキャストデータ転送のためのTCPのような輻輳制御」、IEEE Infocomサンフランシスコ(カリフォルニア)1998年3月28日-4月1日98年。
[23] 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.
[23]WhettenとB.とVicisanoとL.とカーモードとR.とハンドレーとM.とフロイドとS.とM.Luby、「多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送」、RFC3048、2001年1月。
[24] Kermode, R., Vicisano, L., "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol
Instantiation documents", RFC 3269, April 2002.
[24] カーモード、R.、Vicisano(L.)は「ドキュメントをBlocksとプロトコルInstantiationに造って、Reliable Multicast Transport(RMT)のためにGuidelinesを書きます」、RFC3269、2002年4月。
[25] Luby, M., Goyal V. K, Skaria S., Horn, G., "Wave and Equation
Based Rate Control using Multicast Round-trip Time", Proceedings
of ACM SIGCOMM 2002, Pittsburgh PA, August, 2002.
[25] Luby、M.、Goyal(Skaria S.)対KはG.と、「波とマルチキャストの往復の時間を費やす方程式のベースの速度制御」と角で突きます、ACM SIGCOMM2002、ピッツバーグPAの議事、2002年8月。
Luby, et. al. Experimental [Page 27] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [27ページ]実験的なRFC3451LCTブロック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
Mark Handley ICIR 1947 Center St. Berkeley, CA, USA, 94704
マークハンドレーICIR1947センター聖バークレー(カリフォルニア)、米国94704
EMail: mjh@icir.org
メール: mjh@icir.org
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 28] RFC 3451 LCT Building Block December 2002
et Luby、アル。 [28ページ]実験的なRFC3451LCTブロック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 29]
et Luby、アル。 実験的[29ページ]
一覧
スポンサーリンク
