[要約] RFC 3451は、Layered Coding Transport（LCT）ビルディングブロックに関する標準仕様です。LCTは、エラー訂正やフロー制御などの機能を提供し、信頼性の高いデータ転送を実現することを目的としています。
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
Layered Coding Transport (LCT) Building Block
層状コーディングトランスポート（LCT）ビルディングブロック
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
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）は、信頼できるコンテンツ配信およびストリーム配信プロトコルの輸送レベルのサポートを提供します。LCTは、IPマルチキャストを使用してプロトコルをサポートするように特別に設計されていますが、ユニキャストを使用するプロトコルのサポートも提供します。LCTは、受信機に複数のレート配信を提供する混雑制御と互換性があり、コンテンツの信頼できる配信を提供するコーディング技術とも互換性があります。
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
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.
階層化されたコーディングトランスポートは、信頼できるコンテンツ配信およびストリーム配信プロトコルの輸送レベルのサポートを提供します。層状コーディングトランスポートは、IPマルチキャストを使用してプロトコルをサポートするように特別に設計されていますが、ユニキャストを使用するプロトコルのサポートも提供します。レイヤードコーディングトランスポートは、受信機に複数のレート配信を提供する輻輳制御と互換性があり、コンテンツの信頼できる配信を提供するコーディング技術とも互換性があります。
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].
このドキュメントでは、RFC 3048 [26]で定義されているビルディングブロックについて説明しています。このドキュメントは、IETF RMT WGの製品であり、RFC 3269 [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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [2]に記載されているように解釈される。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
このメモには、RFC 2357に従って信頼性の高いマルチキャストトランスポートプロトコルを完全に指定するために必要な定義の一部が含まれています。RFC2357によると、インターネットでの信頼できるマルチキャストプロトコルの使用には、適切な渋滞制御スキームが必要です。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
このようなスキームが利用可能になるか、既存のスキームが適切であることが証明されるのを待っている間、信頼性の高いマルチキャストトランスポートワーキンググループ（RMT）は、「実験的」カテゴリでこのコメントのリクエストを公開します。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
上記の条件が満たされるとすぐに、この仕様をIETF提案標準として再提出することは、RMTの意図です。
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つの根拠は、セッションごとに複数のチャネルを使用する非常にスケーラブルな輻輳制御プロトコルがあることです。これらの混雑制御プロトコルは、セッションへの参加中に受信機が結合し、階層化された順序でチャンネルを去るため、階層化されていると見なされます。階層化されたチャネルの使用は、アプリケーションのストリーミングにも役立ちます。
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は、他のアプリケーションにも使用できる機能を提供します。たとえば、層状ストリーミングアプリケーション。
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は、受信した各パケットが属するセッションを識別するために使用できる送信セッションIDを提供します。これは、受信者が多くのセッションに同時に結合される可能性があるため、これは重要です。したがって、どのセッションに属しているかに応じて到着するにつれてパケットを非難することができることは非常に便利です。別の例として、LCTは、各パケットが情報を伝達しているオブジェクトを識別するためのオプションのサポートを提供します。したがって、LCTは、多くのプロトコルで必要な一般的に使用されるフィールドと機能のサポートの多くを提供します。
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 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.
LCTは、他のビルディングブロックと組み合わせることを目的としているため、結果の全体的なプロトコルが非常にスケーラブルになります。スケーラビリティとは、受信機とネットワークパスの数、それらの不均一性、および動的に可変のレシーバーセットに対応する能力に関連するプロトコルの動作を指します。スケーラビリティの制限は、メモリまたは処理要件、またはプロトコルによって生成されたフィードバック制御の量と冗長データパケットトラフィックから生じる可能性があります。次に、このような制限は、完全に信頼できるコンテンツ配信またはストリーム配信プロトコルが提供することが期待される機能の結果である可能性があります。
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つは、送信セッションID（TSI）です。これにより、セッションの受信者がセッションの一部として受信パケットを一意に識別できます。もう1つの必要なフィールドは、渋滞制御情報（CCI）です。これにより、受信機はセッション内で受信したパケットで必要な渋滞制御を実行できます。他のLCTフィールドは、オプションであるが、多くの場合、セッションに非常に有用な追加情報を提供します。たとえば、トランスポートオブジェクト識別子（TOI）は、パケットにデータが含まれるオブジェクトを識別します。他の例として、送信者の現在の時刻（SCT）は、パケットが送信者から受信機に送信された時間を伝えます。セッションとオブジェクトの送信パケットの終了、たとえばパケット認証に使用できるフィールドのヘッダー拡張機能。
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セッションのレシーバーと送信者間のRFC 2357 [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では、複数のレートまたは単一レートの混雑制御プロトコルを使用できます。複数のレートプロトコルの場合、セッションは通常、複数のチャネルで構成され、送信者は受信機に依存しないレートでセッション内のチャネルにパケットを送信します。各レシーバーは、他のすべてのレシーバーとは無関係に送信者への利用可能な帯域幅に応じて、チャネルに動的にチャンネルに参加および離れることにより、セッションへの参加中に受信率を調整します。したがって、複数のレートプロトコルの場合、各レシーバーの受信率は、他の受信機から動的に異なる場合があります。
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つのチャネルで構成され、送信者はレシーバーからのフィードバックに応じて、時間の経過とともに変動するレートでパケットをチャネルに送信します。各レシーバーは、セッションへの参加中にチャンネルに参加したままです。したがって、単一レートプロトコルの場合、各受信機の受信率は動的に異なる場合がありますが、すべての受信機と協調しています。
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.
レイヤードコーディングとは、順序付けられたレイヤーセットに分割できるパケットのコード化されたストリームを生成する機能を指します。コーディングは何らかの形の信頼性を提供することを目的としており、レイヤー化は、レシーバーのエクスペリエンス（プレイアウトの品質、または全体的な転送速度の観点から）を、受信機のパケットの連続層の数に応じて予測可能な方法で変化させることを目的としています。受け取っています。
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.
レイヤードコーディングの概念は、オーディオおよびビデオストリームを参照して最初に導入されました。たとえば、テレビ放送に関連する情報は、白黒、色、およびHDTV品質に対応する3つのレイヤーに分割できます。受信者は、送信者が異なるレイヤーで情報を複製する必要なく、異なる品質を体験できます。
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].
レイヤードコーディングの概念は、データストリームのコーディングに使用される前方エラー補正（FEC）手法が使用される場合、自然に信頼できるコンテンツ配信プロトコルに拡張できます。これの説明は、[20]、[18]、[7]、[22]、[4]にあります。FECを使用することにより、データストリームは、データオブジェクトの再構築が特定のデータパケットの受信ではなく、受信した異なるパケットの数のみに依存するように変換されます。その結果、受信機が受信している層の数を増やすことにより、受信機はそれに応じて転送時間を短縮できます。FECを使用して信頼性を提供すると、信頼性を提供するための他の方法と比較して、スケーラビリティを劇的に向上させることができます。信頼できるコンテンツ配信のためのFECの使用の詳細については、[11]をご覧ください。
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.
信頼できるプロトコルは、送信者から意図した受信者へのデータの信頼できる配信を保証することを目的としています。保証は、単純なパケットデータの完全性から、オブジェクトの正確なコピーの信頼できる配信、すべての意図された受信者にさまざまです。FEC以外の方法を使用して、いくつかの信頼できるコンテンツ配信プロトコルがIPマルチキャストの上に構築されていますが、スケーラビリティはそれらの多くの主要な設計目標ではありませんでした。
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 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.
IPマルチキャストを使用した信頼できるコンテンツ配信のスケーリングにおける2つの重要な困難は、受信者から送信者に流れるデータの量、および送信者からの関連する応答（一般的にデータ再送信）を扱うことです。そのようなフィードバックを回避し、再送信の量を最小化するプロトコルは、非常にスケーラブルになる可能性があります。LCTは、FECコードまたはレイヤードコーデックと組み合わせて使用して、フィードバックをほとんどまたはまったく使用しない信頼性を実現できます。
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.
Protocolインスタンス化は、LCTフレームワークと他のコンポーネントを組み合わせることで構築できます。LCTを使用する完全なプロトコルインスタンス化には、LCTと互換性があり、RFC 2357に適合する輻輳制御プロトコルを含める必要があります[13]。LCTを使用する完全なプロトコルインスタンス化には、LCTと互換性のあるスケーラブルな信頼性プロトコルが含まれる場合があり、LCTと互換性のあるセッション制御プロトコルが含まれ、セキュリティプロトコルなどの他のプロトコルが含まれる場合があります。
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.
例として、LCTセッションを使用して、3つのLCTチャネルを使用してテレビ番組を提供できます。最初の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.
別の例として、信頼性の高いLCTセッションを使用して、FECコーディングを使用して、10のLCTチャネルを異なるレートで10個のLCTチャネルを使用して、1時間ごとの天気マップ（オブジェクト）を確実に配信できます。レシーバーは、これらのチャネルのサブセットから合計で十分なパケットがあるまで結合して同時にパケットを受け取ることができます。。この場合、品質メトリックは各オブジェクトを受信するのに必要な時間です。
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 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ヘッダーの1つを使用できます。
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チャネルに送信することにより、うっ血制御が達成されます。レシーバーが見たネットワークの輻輳によると、個々のレシーバーはこれらのチャネルの1つ以上を動的に結合します。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（またはLCTの上に構築されたPI）とアッパーアプリケーションの間の交換の種類を指定および制限しません。一部の上部APIは、LCT（またはLCTの上に構築されたPI）とソースまたはレシーバーでのアプリケーションの間で交換される唯一の可能なデータ単位がオブジェクトであるオブジェクト指向アプローチを使用する場合があります。他のAPIは、送信または受信アプリケーションを有効にして、LCT（またはLCTの上に構築されたPI）とオブジェクトのサブセットを交換するか、ストリーミングモデルに従うこともできます。これらの考慮事項は、このドキュメントの範囲外です。
LCT is intended for congestion controlled delivery of objects and streams (both reliable content delivery and streaming of multimedia information).
LCTは、オブジェクトとストリームの混雑制御された配信（信頼できるコンテンツ配信とマルチメディア情報のストリーミングの両方）を対象としています。
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セッションに関連付けられたトランスポートセッション識別子（TSI）が必要です。TSIは送信者のIPアドレスによってスコープされ、送信者のIPアドレスとTSIがセッションを一意に識別する必要があります。RFC 768 [16]で説明されているように、基礎となる輸送がUDPである場合、16ビットUDPソースポート番号はセッションのTSIとして機能する可能性があります。TSI値は、パケット内で発生するすべての場所で同じでなければなりません。ネットワーク、トランスポート、またはその他のレイヤーによって提供される基礎となるTSIがない場合は、TSIを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は、パケット受信またはパケット受信オーダーを保証しない「最良の努力」サービスであり、フローや渋滞制御をサポートしていない「最良の」サービスである基礎となるネットワークまたは輸送サービスで使用されると推定されます。たとえば、RFC 1112 [5]で定義されているIPマルチキャストの任意のソースマルチキャスト（ASM）モデルは、このような「最良の努力」ネットワークサービスです。RFC 1112が提供する基本的なサービスは大部分がスケーラブルですが、特にレシーバーの不均一なセットの存在下で、深刻なスケーラビリティの制限を回避するために、混雑制御または信頼性を慎重に提供する必要があります。
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.
現在、RFC 1112 [5]で定義されている任意のソースマルチキャスト（ASM）モデルと、[10]で定義されているソース固有のマルチキャスト（SSM）モデル、マルチキャスト配信の2つのモデルがあります。LCTは両方のマルチキャストモデルで動作しますが、やや異なる方法で環境上の懸念が異なります。ASMを使用する場合、送信者SはマルチキャストグループGにパケットを送信し、LCTチャネルアドレスはペア（s、g）で構成されます。ここで、Sは送信者のIPアドレスであり、Gはマルチキャストグループアドレスです。SSMを使用する場合、送信者SはパケットをSSMチャネル（S、G）に送信し、LCTチャネルアドレスはSSMチャネルアドレスと一致します。
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よりも説得力のあるセキュリティの利点があります。どちらの場合でも、受信機はメカニズムを使用して、不要なソースからパケットを除外する必要があります。
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で使用できるいくつかの混雑制御プロトコルに適していません。特に、衛星またはワイヤレスネットワークの場合、セッションに割り当てられた固定伝送速度がある可能性があるため、受信機が受信率を効果的に引き下げるメカニズムがない場合があります。
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 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).
例として、オブジェクトが50 MBであると仮定します。送信者は、1秒あたり50パケットで1 kbのパケットを最初のLCTチャネルに送信できます。そのため、このLCTチャネルを使用してレシーバーは、損失がない場合に1,000秒でオブジェクトの受信を完了し、存在下でも受信を完了することができます。信頼性のためにコーディングを使用したかなりの量の損失のうち。さらに、送信者は多くのLCTチャネルを使用して、すべてのLCTチャネルへの1 kbパケットの集合レートが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を使用して、これらの多様なアプリケーションに対して最小限の一般的なスケーラブルな要素を記述しようとします。
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]で説明されています。異なる配信サービスモデルには、異なる混雑制御プロトコルが必要になる場合があります。
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ヘッダーについて説明したのと同じフィールドの一部を記述する場合があります。複数のビルディングブロックを使用したプロトコルインスタンス化には、各パケットにせいぜい1回共有フィールドを含めることをお勧めします。したがって、たとえば、オプションの予想残留時間フィールドを含むLCTで別のビルディングブロックが使用される場合、予想される残留時間フィールドは、せいぜい1回、各パケットに携帯する必要があります。
The position of the LCT header within a packet MUST be specified by any protocol instantiation that uses LCT.
パケット内のLCTヘッダーの位置は、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ヘッダーでは、すべての整数フィールドが「ビッグエンディアン」または「ネットワーク注文」形式で運ばれます。つまり、最も重要なバイト（Octet）が最初に行われます。「パディング」または「予約済み」（R）として指定されたビットは、送信者によって0に設定され、受信機によって無視される必要があります。特に明記しない限り、この仕様の数値定数は10進数です（ベース10）。
The format of the default LCT header is depicted in Figure 1.
デフォルトのLCTヘッダーの形式を図1に示します。
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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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は、輻輳制御情報（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.
将来の使用のために予約されています。送信者はこれらのビットをゼロに設定する必要があり、レシーバーはこれらのビットを無視する必要があります。
Transport Session Identifier flag (S): 1 bit
トランスポートセッション識別子フラグ：1ビット
This is the number of full 32-bit words in the TSI field. The TSI field is 32*S + 16*H bits in length, 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
輸送オブジェクト識別子フラグ（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フィールドの長さを半ワード（16ビット）の倍数にすることができ、TSIフィールドとTOIフィールドの総長が32ビットの倍数であることを保証します。
Sender Current Time present flag (T): 1 bit
送信者現在の時刻現在のフラグ（t）：1ビット
T = 0 indicates that the Sender Current Time (SCT) field is not present. T = 1 indicates that the SCT field is present. The SCT is inserted by senders to indicate to receivers how long the session has been in progress.
t = 0は、送信者現在の時間（SCT）フィールドが存在しないことを示します。t = 1は、SCTフィールドが存在することを示します。SCTは送信者によって挿入され、セッションが進行中の期間レシーバーに示されます。
Expected Residual Time present flag (R): 1 bit
予想残留時間プレゼントフラグ（R）：1ビット
R = 0 indicates that the Expected Residual Time (ERT) field is not present. R = 1 indicates that the ERT field is present. The ERT is inserted by senders to indicate to receivers how much longer the session / object transmission will continue.
R = 0は、予想される残差時間（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.
セッションのERTが2^32-1時間ユニット（約49日）を超える場合、送信者はr = 1を設定してはなりません。ここで、時間はミリ秒単位で測定されます。
Close Session flag (A): 1 bit
セッションフラグを閉じます（a）：1ビット
Normally, A is set to 0. The sender MAY set A to 1 when termination of transmission of packets for the session is imminent. A MAY be set to 1 in just the last packet transmitted for the session, or A MAY be set to 1 in the last few seconds of packets transmitted for the session. Once the sender sets A to 1 in one packet, the sender SHOULD set A to 1 in all subsequent packets until termination of transmission of packets for the session. A received packet with A set to 1 indicates to a receiver that the sender will immediately stop sending packets for the session. When a receiver receives a packet with A set to 1 the receiver SHOULD assume that no more packets will be sent to the session.
通常、Aは0に設定されています。Senderは、セッションのパケットの送信の終了が差し迫っているときにAを1に設定できます。Aは、セッション用に送信された最後のパケットのみで1に設定されるか、セッション用に送信された最後の数秒で1に設定できます。送信者が1つのパケットを1つに1に設定すると、送信者はセッションのパケットの送信が終了するまで、後続のすべてのパケットで1にAを設定する必要があります。セットが1にある受信パケットは、受信者に、送信者がセッションのパケットの送信をすぐに停止することを示します。受信者が1にセットを備えたパケットを受信すると、受信機はこれ以上パケットがセッションに送信されないと想定する必要があります。
Close Object flag (B): 1 bit
オブジェクトフラグを閉じる（b）：1ビット
Normally, B is set to 0. The sender MAY set B to 1 when termination of transmission of packets for an object is imminent. If the TOI field is in use and B is set to 1 then termination of transmission for the object identified by the TOI field is imminent. If the TOI field is not in use and B is set to 1 then termination of transmission for the one object in the session identified by out-of-band information is imminent. B MAY be set to 1 in just the last packet transmitted for the object, or B MAY be set to 1 in the last few seconds packets transmitted for the object. Once the sender sets B to 1 in one packet for a particular object, the sender SHOULD set B to 1 in all subsequent packets for the object until termination of transmission of packets for the object. A received packet with B set to 1 indicates to a receiver that the sender will immediately stop sending packets for the object. When a receiver receives a packet with B set to 1 then it SHOULD assume that no more packets will be sent for the object to the session.
通常、Bは0に設定されています。送信者は、オブジェクトのパケットの送信の終了が差し迫っているときにBを1に設定できます。TOIフィールドが使用されており、Bが1に設定されている場合、TOIフィールドによって識別されるオブジェクトの伝送の終了が差し迫っています。TOIフィールドが使用されておらず、Bが1に設定されている場合、帯域外情報によって識別されるセッション内の1つのオブジェクトの送信の終了が差し迫っています。bは、オブジェクトに送信された最後のパケットのみで1に設定されます。または、オブジェクト用に送信された最後の数秒のパケットでBを1に設定できます。送信者が特定のオブジェクトの1つのパケットにBを1つに設定すると、送信者はオブジェクトのパケットの送信を終了するまで、オブジェクトの後続のすべてのパケットでBにBを設定する必要があります。Bを1に設定した受信パケットは、受信者に、送信者がオブジェクトのパケットの送信をすぐに停止することを示します。レシーバーがBを1に設定したパケットを受信した場合、セッションにオブジェクトのパケットが送信されないと仮定する必要があります。
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と実際のコーデックの間のマッピングは、セッションごとに定義され、セッションの説明情報の一部として帯域外に通知されます。CPフィールドの使用は、RFC 1889で説明されているRTPヘッダーのペイロードタイプ（PT）フィールドに似ています[21]。
Congestion Control Information (CCI): 32, 64, 96 or 128 bits
混雑制御情報（CCI）：32、64、96、または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）：0、16、32、または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アドレスによってスコープされているため、送信者とTSIのIPアドレスが一緒にセッションを一意に識別します。送信者のIPアドレスと組み合わせたTSIは常にセッションを一意に識別しますが、TSIがLCTヘッダーに含まれるかどうかは、TSI値として使用されるものによって異なります。基礎となる輸送がUDPの場合、16ビットUDPソースポート番号がセッションのTSIとして機能する可能性があります。パケットにTSI値が複数回表示される場合、すべての発生は同じ値でなければなりません。ネットワーク、トランスポート、またはその他のレイヤーによって提供される基礎となるTSIがない場合は、TSIをLCTヘッダーに含める必要があります。
The TSI MUST be unique among all sessions served by the sender during the period when the session is active, and for a large period of time preceding and following when the session is active. A primary purpose of the TSI is to prevent receivers from inadvertently accepting packets from a sender that belong to sessions other than 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は、セッションがアクティブである期間中に送信者が提供するすべてのセッションの中で、およびセッションがアクティブであるときとその後の大規模な期間の間で一意でなければなりません。TSIの主な目的は、受信者がセッションレシーバー以外のセッションに属する送信者からパケットを不注意に受け入れることを防ぐことです。たとえば、セッションが非アクティブ化され、次に別のセッションが送信者によってアクティブ化され、2つのセッションが重複するチャネルセットを使用しているとします。この送信者のアクティビティ中に接続して最初のセッションに接続したままでいるレシーバーは、2つのセッションのTSIが同一である場合、最初のセッションに属する2番目のセッションのパケットを受け入れる可能性があります。セッションへのTSIフィールド値のマッピングは、このドキュメントの範囲外であり、帯域外で行われます。
The length of the TSI field is 32*S + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits.
TSIフィールドの長さは32*s 16*hビットです。TSIフィールドとTOIフィールドの総長さは32ビットの倍数であることに注意してください。
Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112 bits.
輸送オブジェクト識別子（TOI）：0、16、32、48、64、80、96または112ビット。
This field indicates which object within the session this packet pertains to. For example, a sender might send a number of files in the same session, using TOI=0 for the first file, TOI=1 for the second one, etc. As another example, the TOI may be a unique global identifier of the object that is being transmitted from several senders concurrently, and the TOI value may be the output of a hash function applied to the object. The mapping of TOI field values to objects is outside the scope of this document and is to be done out-of-band. The TOI field MUST be used in all packets if more than one object is to be transmitted in a session, i.e. the TOI field is either present in all the packets of a session or is never present.
このフィールドは、このパケットが関係するセッション内のオブジェクトを示します。たとえば、送信者は同じセッションで多くのファイルを送信する場合があり、最初のファイルにTOI = 0、2番目のファイルでTOI = 1などを使用します。別の例として、TOIはオブジェクトの一意のグローバル識別子である場合がありますそれは複数の送信者から同時に送信されており、TOI値はオブジェクトに適用されるハッシュ関数の出力である可能性があります。ObjectsへのTOIフィールド値のマッピングは、このドキュメントの範囲外であり、帯域外で行われます。TOIフィールドは、セッションで複数のオブジェクトを送信する場合、つまりTOIフィールドがセッションのすべてのパケットに存在するか、存在しない場合、すべてのパケットで使用する必要があります。
The length of the TOI field is 32*O + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits.
TOIフィールドの長さは32*o 16*hビットです。TSIフィールドとTOIフィールドの総長さは32ビットの倍数であることに注意してください。
Sender Current Time (SCT): 0 or 32 bits
Sender Current Time（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の単位で測定され、セッションの開始から計算されたmodulo 2^32ユニットで測定されたときに送信されました。
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の単位で測定された現在のオブジェクトの送信の送信者が予想される残留送信時間を表します。ERTフィールドを含むパケットにTOIフィールドも含まれている場合、ERTはTOIフィールドに対応するオブジェクトを指します。
This field MUST NOT be present if R=0 and MUST be present if R=1.
このフィールドはr = 0の場合は存在しないでください。r = 1の場合は存在する必要があります。
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:
ヘッダー拡張機能は、LCTで使用され、常に使用されていない、または可変サイズのオプションのヘッダーフィールドに対応します。ヘッダー拡張機能の使用の例は次のとおりです。
o Extended-size versions of already existing header fields.
o 既存のヘッダーフィールドの拡張サイズのバージョン。
o Sender and Receiver authentication information.
o 送信者および受信者認証情報。
The presence of Header Extensions can be inferred by the LCT header length (HDR_LEN): if HDR_LEN is larger than the length of the standard header then the remaining header space is taken by Header Extension fields.
ヘッダー拡張の存在は、LCTヘッダー長（HDR_LEN）によって推測できます。HDR_LENが標準ヘッダーの長さよりも大きい場合、残りのヘッダースペースはヘッダー拡張フィールドによって取得されます。
If present, Header Extensions MUST be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting a packet. The default action for unrecognized header extensions is to ignore them. This allows the future introduction of backward-compatible enhancements to LCT without changing the LCT version number. Non backward-compatible header extensions CANNOT be introduced without changing the LCT version number.
存在する場合は、ヘッダー拡張機能を処理して、輻輳制御手順を実行するか、パケットを受け入れる前に認識されることを確認する必要があります。認識されていないヘッダー拡張機能のデフォルトのアクションは、それらを無視することです。これにより、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.
以下に示すように、ヘッダー拡張フィールドには2つの形式があります。最初の形式は、0〜127の間のヘッダー拡張型（HET）値を持つ可変長拡張機能に使用されます。2番目の形式は、127から255のHET値を使用して、固定長（1つの32ビットワード）拡張に使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Format of additional headers
図2-追加のヘッダーの形式
The explanation of each sub-field is the following:
各サブフィールドの説明は次のとおりです。
Header Extension Type (HET): 8 bits
ヘッダー拡張タイプ（HET）：8ビット
The type of the Header Extension. This document defines a number of possible types. Additional types may be defined in future versions of this specification. HET values from 0 to 127 are used for variable-length Header Extensions. HET values from 128 to 255 are used for fixed-length 32-bit Header Extensions.
ヘッダー拡張機能のタイプ。このドキュメントでは、可能な多くのタイプを定義します。追加のタイプは、この仕様の将来のバージョンで定義できます。0〜127のHET値は、可変長ヘッダー拡張に使用されます。128〜255のHET値は、固定長32ビットヘッダー拡張機能に使用されます。
Header Extension Length (HEL): 8 bits
ヘッダー拡張長（HEL）：8ビット
The length of the whole Header Extension field, expressed in multiples of 32-bit words. This field MUST be present for variable-length extensions (HET between 0 and 127) and MUST NOT be present for fixed-length extensions (HET between 128 and 255).
ヘッダー拡張フィールド全体の長さは、32ビット語の倍数で表されます。このフィールドは、可変長拡張機能（0〜127の間）に存在する必要があり、固定長拡張（128〜255の間）には存在しないでください。
Header Extension Content (HEC): variable length
ヘッダー拡張コンテンツ（HEC）：可変長
The content of the Header Extension. The format of this sub-field depends on the Header Extension type. For fixed-length Header Extensions, the HEC is 24 bits. For variable-length Header Extensions, the HEC field has variable size, as specified by the HEL field. Note that the length of each Header Extension field MUST be a multiple of 32 bits. Also note that the total size of the LCT header, including all Header Extensions and all optional header fields, cannot exceed 255 32-bit words.
ヘッダー拡張機能の内容。このサブフィールドの形式は、ヘッダー拡張タイプに依存します。固定長ヘッダー拡張機能の場合、HECは24ビットです。可変長ヘッダー拡張機能の場合、HECフィールドは、HELフィールドで指定されているように、可変サイズです。各ヘッダー拡張フィールドの長さは、32ビットの倍数でなければならないことに注意してください。また、すべてのヘッダー拡張機能とすべてのオプションのヘッダーフィールドを含むLCTヘッダーの合計サイズは、255 32ビット単語を超えることはできないことに注意してください。
Header Extensions are further divided between general LCT extensions and Protocol Instantiation specific extensions (PI-specific). General LCT extensions have HET in the ranges 0:63 and 128:191 inclusive. PI-specific extensions have HET in the ranges 64:127 and 192:255 inclusive.
ヘッダー拡張機能は、一般的なLCT拡張機能とプロトコルインスタンス化固有の拡張（PI固有）の間でさらに分割されます。一般的なLCT拡張機能には、範囲0:63および128：191が包括的である。PI固有の拡張機能は、範囲64：127および192：255の範囲にあります。
General LCT extensions are intended to allow the introduction of backward-compatible enhancements to LCT without changing the LCT version number. Non backward-compatible header extensions CANNOT be introduced without changing the LCT version number.
一般的なLCT拡張機能は、LCTバージョン番号を変更せずにLCTに逆互換の拡張を導入できるようにすることを目的としています。LCTバージョン番号を変更せずに、非逆互換ヘッダー拡張機能を導入することはできません。
PI-specific extensions are reserved for PI-specific use with semantic and default parsing actions defined by the PI.
PI固有の拡張機能は、PIによって定義されたセマンティックおよびデフォルトの解析アクションを使用したPI固有の使用のために予約されています。
The following general LCT Header Extension types are defined:
次の一般的なLCTヘッダー拡張タイプが定義されています。
EXT_NOP=0 No-Operation extension. The information present in this extension field MUST be ignored by receivers.
ext_nop = 0操作なし拡張。この拡張フィールドに存在する情報は、受信機によって無視する必要があります。
EXT_AUTH=1 Packet authentication extension Information used to authenticate the sender of the packet. The format of this Header Extension and its processing is outside the scope of this document and is to be communicated out-of-band as part of the session description.
ext_auth = 1パケットの送信者を認証するために使用されるパケット認証拡張情報。このヘッダー拡張機能とその処理の形式は、このドキュメントの範囲外であり、セッションの説明の一部として帯域外に伝えられます。
It is RECOMMENDED that senders provide some form of packet authentication. If EXT_AUTH is present, whatever packet authentication checks that can be performed immediately upon reception of the packet SHOULD be performed before accepting the packet and performing any congestion control-related action on it.
送信者は、何らかの形のパケット認証を提供することをお勧めします。ext_authが存在する場合、パケットを受け入れ、混雑制御関連のアクションを実行する前に、パケットの受信後すぐに実行できるパケット認証チェックを実行する必要があります。
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を実装するすべての送信者と受信機は、Ext_NOPヘッダー拡張機能をサポートする必要があり、Ext_Authを認識する必要がありますが、コンテンツを解析できない場合があります。
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 セッションに使用されるトランスポートセッション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 パケットペイロードの長さ。
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を使用したプロトコルのインスタンス化は、セッションの説明に含める必要があるものに追加の要件を置く場合があります。たとえば、プロトコルのインスタンス化では、各チャネルのデータレート、セッションのオブジェクトへの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.
セッションの説明は、RFC 2327 [8]で定義されているSDP、またはRFC 3023 [14]で定義されているXMLメタデータ、またはRFC 2068 [6]などで定義されているHTTP/MIMEヘッダーなどの形式である可能性があります。RFC 2974 [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 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を使用したパケットの送信者は、LCTヘッダーで提供される輻輳制御情報フィールドを使用して、RFC 2357 [13]に従って、輻輳制御スキームの1つの送信者側部分を実装する必要があり、対応する受信機の混雑制御スキームは帯域外に伝えられ、セッションに参加しているレシーバーが実装する必要があります。
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.
レシーバーは、配達サービスモデルに応じて異なる動作をすることができます。たとえば、オンデマンドサービスモデルの場合、受信機はセッションに参加し、オブジェクトを再現するために必要なパケットを取得してからセッションを去ることができます。別の例として、ストリーミングサービスモデルの場合、レシーバーを一連の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ヘッダーに存在する場合、セクション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 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.
セッションに参加できるようにするには、レシーバーは、LCTヘッダーに記載されている混雑制御情報フィールドを使用して、セッション説明で指定された輻輳制御プロトコルを実装する必要があります。受信者がセッションで使用されている混雑制御プロトコルを実装できない場合、セッションに参加してはなりません。セッションが複数のLCTチャネルで送信される場合、受信機は最初に渋滞制御プロトコルの指定されたスタートアップ動作に従ってチャネルに参加する必要があります。複数のチャネルを使用する複数のレートの輻輳制御プロトコルの場合、これは通常、受信者が最初に最小限の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チャネルで送信される場合、受信機が送信される場合、パケットの並べ替えを引き起こす可能性があることに注意してください。新しいオブジェクトのパケットの受信は、少なくともある程度の間、前のパケットにはこれ以上のパケットがないことを意味すると仮定しないでください。
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セッションを個別に。
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.
RFC 3048 [23]で説明されているように、LCTは、他のビルディングブロックと組み合わせて使用することを目的としたビルディングブロックです。LCTヘッダー内の輻輳制御情報フィールドを使用する輻輳制御ビルドブロックは、LCTを使用するプロトコルインスタンス化で使用する必要があり、信頼性ビルディングブロックなどの他のビルディングブロックも使用できます。
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ヘッダーの混雑制御情報フィールドは、渋滞制御に関連する情報を運ぶために予約されている不透明なフィールドです。また、混雑制御に関連する追加情報を運ぶ混雑制御ヘッダー拡張フィールドもある場合があります。
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]には、信頼性の高いマルチキャストトランスポート（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で説明されているように、受信機にセッションの説明を取得する必要があります。セッションの説明は、RFC 2327 [8]で定義されているSDP、RFC 3023 [14]で定義されているXMLメタデータ、またはRFC 2068 [6]で定義され、SAPで配布されるHTTP/MIMEヘッダーなどの形式である可能性があります。RFC 2974 [9]で定義されているように、HTTPまたは他の方法で。IPSEC [11]などの認証プロトコルを使用して、セッションの説明を受信機に配信して、正しいセッションの説明が確実に届くようにすることをお勧めします。
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を使用する一部のプロトコルインスタンス化は、受信機から送信者へのフィードバックの生成を必要とするビルディングブロックを使用する場合があります。ただし、これを行うメカニズムはLCTの範囲外です。
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 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.
LCTは、攻撃者によるサービス拒否攻撃の対象となる可能性があります。攻撃者は、混雑制御メカニズムを混乱させようとするか、セッションに偽造パケットを送信し、再構成の成功を妨げたり、受信機によるオブジェクトの大部分の再構築を不正確にしたりします。LCTは、多くの受信機が同じ鍛造パケットを受け取る可能性があるため、このような攻撃の影響を特に受けます。したがって、アプリケーションに配信する前に、受信オブジェクトに整合性チェックを行うことをお勧めします。たとえば、MD5ハッシュ[17]を送信する前にオブジェクトに追加してから、オブジェクトが再構築されたらMD5ハッシュを計算して確認することをお勧めします。送信されたオブジェクトと同じです。さらに、強力な暗号整合性保護を取得するには、受信機が検証可能なデジタル署名を、このようなハッシュ値の上に計算する必要があります。また、LCTを使用するプロトコルインスタンス化は、Tesla [15]などの何らかの形のパケット認証を実装して、そのような攻撃から保護することをお勧めします。最後に、すべてのネットワークルーターで逆パス転送チェックを有効にし、送信者から受信機にパスに沿って切り替えて、鍛造パケットをマルチキャストツリーデータパスに注入する可能性を制限することをお勧めします。
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のもう1つの脆弱性は、セッションの誤ったセッションの説明を取得するレシーバーの可能性です。この結果、セッションの説明が間違っている正当な受信者がセッションコンテンツを正しく受信できないこと、または受信者が誤って能力よりもはるかに高いレートで受け取ることを試み、それによりネットワークの一部のトラフィックを破壊することです。これらの問題を回避するために、レシーバーが誤ったセッションの説明を受け入れるのを防ぐための措置を講じることをお勧めします。
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.
複数のレートの混雑制御ビルディングブロックの誤ったまたは破損した実装を持つレシーバーは、送信者と受信機の間のパスのネットワークの健康に影響を与える可能性があり、セッションに結合された他の受信者の受信率にも影響する可能性があります。したがって、受信者は、セッションに参加するために必要なセッションの説明を受け取る前に、自分自身を正当であると特定する必要があることをお勧めします。受信者が自分自身を合法として識別する方法は、このドキュメントの範囲外です。
No information in this specification is subject to IANA registration.
この仕様の情報は、IANA登録の対象となりません。
Building blocks used in conjunction with LCT MAY introduce additional IANA considerations.
LCTと組み合わせて使用されるビルディングブロックは、IANAの追加の考慮事項を導入する場合があります。
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.
この文書への詳細なコメントと貢献について、Vincent RocaとRoger Kermodeに感謝します。このドキュメントに関する詳細なコメントをしてくれたブルース・ルッケンホフ、ヘイダー・ラダ、ジャスティン・チャップウェスケにも感謝します。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] 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] Byers、J.W.、Frumin、M.、Horn、G.、Luby、M.、Mitzenmacher、M.、Roetter、A。and W. Shaver、 "Flid-dl：層状マルチキャストの混雑制御"、2番目の国際ワークショップの議事録2000年11月、カリフォルニア州パロアルト、ネットワークグループコミュニケーション（NGC 2000）について。
[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] Byers、J.W.、Luby、M.、Mitzenmacher、M.、A。Rege、「バルクデータの信頼できる分布へのデジタル噴水アプローチ」、Proceedings ACM SigComm'98、バンクーバー、カナダ、1998年9月。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[5] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、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。and J. Gray、「Fcast Multicast File Distribution」、IEEE Network、Vol。14、No。1、pp。58-68、2000年1月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[9] Handley、M.、Perkins、C。and E. Whelan、「セッションアナウンスプロトコル」、RFC 2974、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] Holbrook、H。W.、「マルチキャストのチャネルモデル」、博士号論文、スタンフォード大学、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.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、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.、Rizzo、L.、Handley、M。and J. Crowcroft、「Forward Error Correction（FEC）ビルディングブロック」、RFC 3452、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] Mankin、A.、Romanow、A.、Bradner、S。and V. Paxson、「信頼できるマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[14] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[14] Murata、M.、St。Laurent、S。およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[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.、Canetti、R.、Song、D。and J.D. Tygar、「マルチキャストの効率的かつ安全なソース認証」、ネットワークおよび分散システムセキュリティシンポジウム、NDSS 2001、pp。35-46、2001年2月。
[16] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[16] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[17] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[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] Rizzo、L。、「信頼できるコンピューター通信プロトコルの効果的な消去コード」、ACM Sigcomm Computer 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] Rizzo、L、「PGMCC：TCPフレンドリーなシングルレートマルチキャスト輻輳制御スキーム」、2000年8月、ストックホルムスウェーデンのSigcomm 2000の議事録。
[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] Rizzo、LおよびL. Vicisano、「ソフトウェアFEC技術に基づく信頼性の高いマルチキャストデータ分布プロトコル」、1997年6月、HPCS'97、Chalkidiki Greeceのアーキテクチャと実装に関する第4 IEEESワークショップの議事録。
[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.、Frederick、R。and V. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、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.、Rizzo、L。、およびJ. Crowcroft、「層状マルチキャストデータ転送のためのTCP様渋滞制御」、IEEE Infocom'98、カリフォルニア州サンフランシスコ、3月1日1998年3月1日。
[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.、Kermode、R.、Handley、M.、Floyd、S。、およびM. Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、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] Kermode、R.、Vicisano、L。、「信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、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 V. K、Skaria S.、Horn、G。、「マルチキャスト往復時間を使用した波と方程式ベースのレート制御」、ACM Sigcomm 2002の議事録、Pittsburgh PA、2002年8月。
Authors' Addresses
著者のアドレス
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA, USA, 94538
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont、CA、USA、94538
EMail: luby@digitalfountain.com
Jim Gemmell Microsoft Research 455 Market St. #1690 San Francisco, CA, 94105
Jim Gemmell Microsoft Research 455 Market St.＃1690 San Francisco、CA、94105
EMail: jgemmell@microsoft.com
Lorenzo Vicisano cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA, USA, 95134
Lorenzo Vicisano Cisco Systems、Inc。170 West Tasman Dr. San Jose、CA、USA、95134
EMail: lorenzo@cisco.com
Luigi Rizzo Dip. Ing. dell'Informazione, Univ. di Pisa via Diotisalvi 2, 56126 Pisa, Italy
Luigi Rizzo Dip。ing。Dell'informazione、大学ディオティサルヴィ2、56126イタリアのピサ経由のディピサ
EMail: luigi@iet.unipi.it
Mark Handley ICIR 1947 Center St. Berkeley, CA, USA, 94704
マークハンドリーICIR 1947センターセントバークレー、カリフォルニア州、米国、94704
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。