Network Working Group M. Luby
Request for Comments: 5651 M. Watson
Obsoletes: 3451 L. Vicisano
Category: Standards Track Qualcomm, Inc.
October 2009
Layered Coding Transport (LCT) Building Block
Abstract
抽象
The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but it 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. This document obsoletes RFC 3451.
階層符号化トランスポート（LCT）ビルディングブロックは、信頼性の高いコンテンツ配信とストリーム配信プロトコルのためのトランスポート・レベルのサポートを提供します。 LCTは、特にIPマルチキャストを使用してプロトコルをサポートするために設計されたが、それはまた、ユニキャストを使用するプロトコルへのサポートを提供しています。 LCTは、受信機に複数のレート配信を提供し、また、コンテンツの信頼できる配信を提供する符号化技術と互換性のある輻輳制御と互換性があります。この文書はRFC 3451を廃止します。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。
Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Rationale .......................................................3
3. Functionality ...................................................4
4. Applicability ...................................................7
4.1. Environmental Requirements and Considerations ..............9
4.2. Delivery Service Models ...................................10
4.3. Congestion Control ........................................13
5. Packet Header Fields ...........................................13
5.1. LCT Header Format .........................................13
5.2. Header-Extension Fields ...................................18
5.2.1. General ............................................18
5.2.2. EXT_TIME Header Extension ..........................20
6. Operations .....................................................23
6.1. Sender Operation ..........................................23
6.2. Receiver Operation ........................................25
7. Requirements from Other Building Blocks ........................26
8. Security Considerations ........................................28
8.1. Session and Object Multiplexing and Termination ...........28
8.2. Time Synchronization ......................................29
8.3. Data Transport ............................................29
9. IANA Considerations ............................................29
9.1. Namespace Declaration for LCT Header Extension Types ......29
9.2. LCT Header Extension Type Registration ....................30
10. Acknowledgments ...............................................30
11. Changes from RFC 3451 .........................................31
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Layered Coding Transport (LCT) 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 it 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.
階層化符号化トランスポート（LCT）信頼性の高いコンテンツ配信とストリーム配信プロトコルのトランスポートレベルのサポートを提供します。階層符号化交通は、特にIPマルチキャストを使用してプロトコルをサポートするために設計されたが、それはまた、ユニキャストを使用するプロトコルへのサポートを提供しています。階層符号化トランスポートは、受信機に複数のレート配信を提供し、また、コンテンツの信頼できる配信を提供する符号化技術と互換性のある輻輳制御と互換性があります。
This document describes a building block as defined in [RFC3048]. This document is a product of the IETF RMT WG and follows the general guidelines provided in [RFC3269].
[RFC3048]で定義されている。この文書では、ビルディングブロックについて説明します。この文書は、IETF RMT WGの製品であり、[RFC3269]に提供される一般的なガイドラインに従います。
[RFC3451], which was published in the "Experimental" category and which is obsoleted by this document, contained a previous version of the protocol.
[RFC3451]、「実験」カテゴリに掲載された、この文書により廃止されたが、プロトコルの以前のバージョンを含んでいました。
This Proposed Standard specification is thus based on and backwards compatible with the protocol defined in [RFC3451] updated according to accumulated experience and growing protocol maturity since its original publication. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
この提案された標準仕様従ってに基づいて、[RFC3451]で定義されたプロトコルと下位互換性が更新され蓄積された経験によると、その元の出版以来プロトコル成熟を成長させます。経験は、この仕様自体には、本明細書の使用に関連する輻輳制御戦略の両方に適用されると述べました。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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.
LCTセッションは、受信機に関心のあることができる1つまたは複数のオブジェクトの伝送に関係するパケットを運ぶためにある期間に使用される単一の送信者から発信複数のチャネルを含みます。単一の送信者から発信されたものとしてセッションを定義するの背後にある論理は、これは輻輳制御を介してパケットトラフィックを規制する適切な粒度であることです。同じセッション内で複数のチャネルを使用するための一つの根拠は、セッションごとに複数のチャネルを使用する大規模なスケーラブルな輻輳制御プロトコルがあるということです。これらの輻輳制御プロトコルは、受信機がセッションへの参加中に積層順に結合し、チャネルを残すため層状であると考えられます。
The use of layered channels is also useful for streaming applications.
階層チャネルの使用はまた、ストリーミングアプリケーションのために有用です。
There are coding techniques that provide massively scalable reliability and asynchronous delivery that 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 to which session each received packet belongs. 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 the session to which they belong. As another example, there are optional fields within the LCT packet header for identifying the object about which information is carried in the packet payload.
輻輳制御のためのサポートを越えて、LCTは、フィールドの数を提供し、一般的に多くのプロトコルに必要な機能をサポートしています。例えば、LCTは、各受信したパケットが属するセッションを識別するために使用することができる伝送セッションIDを提供します。受信機は、同時に多数のセッションに参加することができるので、これは重要であり、したがって、彼らが属するセッションに係る到着するパケットを逆多重化することができるように非常に有用です。別の例として、情報がパケットペイロードで運ばれるどのオブジェクトを識別するための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 for which object the packet contains data and flags are included for indicating the close of the session and the close of sending packets for an object. Header extensions can carry additional fields that, for example, can be used for packet authentication or to convey various kinds of timing information: 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 or transmission object will be continued for, and Session Last Change (SLC) conveys the time when objects have been added, modified, or removed from the session.
LCTヘッダが受信機に帯域内のセッション情報を伝達するのに有用であるフィールドの数を提供します。必須フィールドの一つは、セッションの受信側が一意のセッションの一部として受信したパケットを識別することを可能にする送信セッションのID（TSI）、です。別の必須フィールドは、受信機がセッション内で受信したパケットに必要な輻輳制御を行うことを可能にする輻輳制御情報（CCI）です。その他LCTフィールドは、セッションのためのオプションですが、多くの場合、非常に有用な追加情報を提供します。例えば、トランスポート・オブジェクト識別子（TOI）をれるパケットがデータを含んでおり、フラグは、セッションのクローズおよびオブジェクトの送信パケットの終了を示すために含まれるオブジェクトを識別する。ヘッダ拡張は、例えば、パケット認証のために使用することができるか、タイミング、各種の情報を伝えるために、追加のフィールドを運ぶことができます：送信者の現在時刻（SCT）は、パケットが受信機に送信者から送信された時刻を伝え、期待残り時間（ERT）は、セッションまたは送信オブジェクトが継続される時間の量を伝え、そしてセッション最終更新（SLC）は、オブジェクトが追加、変更、またはセッションから削除された時間を伝えます。
LCT provides support for congestion control. Congestion control MUST be used that conforms to [RFC2357] 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]に準拠していることに使用されなければなりません。輻輳制御は、送信側から受信側への経路上の利用可能な帯域幅にスループットを適応させる、及び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. Use of the multiple rate congestion control scheme defined in [RFC3738] is RECOMMENDED. Alternative multiple rate congestion control protocols are described in [VIC1998] and [BYE2000]. A possible single rate congestion control protocol is described in [RIZ2000].
一般的にはより容易に多くの受信機へのスケーラビリティを実現し、各個々の受信機へのより高いスループットを提供するので、一般的に、複数の速度プロトコルは、異種の受信環境における単一レートプロトコルに好ましいです。 [RFC3738]で定義された複数のレート輻輳制御方式の使用が推奨されます。代替の複数のレート輻輳制御プロトコルは、[BYE2000] [VIC1998]に記載されています。可能なシングルレート輻輳制御プロトコルは、[RIZ2000]に記載されています。
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.
コーディング階層の概念は、最初のオーディオおよびビデオストリームを参照して導入されました。例えば、TV放送に関連する情報は、白黒、カラー、及び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 [RIZ1997a], [RIZ1997b], [GEM2000], [VIC1998], and [BYE1998]. 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 from which a receiver is receiving, 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 [RFC3453].
前方誤り訂正（FEC）技術は、データストリームを符号化するために使用される場合階層符号化の概念は、自然に信頼性の高いコンテンツ配信プロトコルに拡張することができます。この説明は、[BYE1998] [VIC1998]、[RIZ1997b]、[GEM2000]、[RIZ1997a]で発見することができ。 FECを使用して、データストリームは、データオブジェクトの再構成は、特定のデータパケットの受信に、のみ受信異なるパケットの数に依存しないように変換されます。結果として、受信機は受信された層の数を増やすことによって、受信機はそれに応じて転送時間を短縮することができます。信頼性を提供するための他の方法と比較して劇的にスケーラビリティを向上させることができ、信頼性を提供するために、FECを使用しました。信頼性の高いコンテンツ配信のためのFECの使用に関する詳細は、[RFC3453]に見出すことができます。
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マルチキャストを使用した信頼性の高いコンテンツ配信をスケーリングにおける主要な困難の二つは、送信者と送信者からの関連する応答（一般的にデータの再送信）を受信機から流出データ量を扱っています。どのようなフィードバックを回避し、再送信の量を最小化するプロトコルは、大規模な拡張性の高いことができます。 LCTは、ほとんど又は全くフィードバックを信頼性を達成するためにFECコード又は層状コーデックと共に使用することができます。
Protocol instantiations (PIs) 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 [RFC2357]. A complete protocol instantiation that uses LCT MAY include a scalable reliability protocol that is compatible with LCT, it MAY include a session control protocol that is compatible with LCT, and it MAY include other protocols such as security protocols.
プロトコルインスタンス（主任研究者）は、他の成分とLCTフレームワークを組み合わせることによって構築することができます。 LCTを使用する完全なプロトコルのインスタンスは、LCTと互換性があり、それは、[RFC2357]に準拠し、輻輳制御プロトコルを含まなければなりません。 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セッションは、単一の送信者を起点と一つ以上の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チャネルを使用した時間ごとに更新天気図（オブジェクト）を提供するために使用することができます。受信機は、参加と同時に、これらのチャネルのサブセットからパケットを受信し、それがオブジェクトを回復するために、合計で十分なパケットを有するまで、次のオブジェクトを受信するための時間になるまで、セッションを残す（または唯一のセッション記述情報をリッスン接続されたまま）してもよいです。この場合、品質メトリックは、各オブジェクトを受信するために必要な時間です。
Before joining a session, the receivers must obtain enough of the session description to start the session. This includes 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 [RFC5052] could be used.
エンコーダは、信頼性を提供するために、パケットペイロード内に配置されたデータを生成するために使用され得ます。適切なデコーダがパケットペイロードから元の情報を再生するために使用されます。そのようなエンコーダおよびデコーダを使用する場合LCTヘッダに続く信頼ヘッダが存在してもよいです。信頼ヘッダは、パケットのペイロードで運ばれた符号化データを記述するのに役立ちます。信頼ヘッダのフォーマットは、使用される符号化に依存し、これは、アウトオブバンド交渉されます。一例として、[RFC5052]に記載の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 that 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 [VIC1998], [BYE2000], and [RFC3738]. Other congestion controls may be suitable when LCT is used for a streaming application.
LCTのために、複数のレート輻輳制御を使用した場合、輻輳制御は、いくつかのLCTチャネルに特定のセッションに関連付けられたパケットを送信することによって達成されます。個々の受信機は、動的に受信機によって見られるように、ネットワークの輻輳に応じて、これらのチャネルの一つ以上に参加します。 LCTヘッダは、受信機に輻輳制御情報を伝達するために使用しなければならない不透明なフィールドを含みます。 LCTで使用する実際の輻輳制御方式は、帯域外交渉されます。コンテンツ配信のために適切であり得る輻輳制御プロトコルのいくつかの例は、[VIC1998]、[BYE2000]、および[RFC3738]に記載されています。 LCTは、ストリーミングアプリケーションのために使用される場合、他の輻輳制御は、適切であり得ます。
This document does not specify and restrict the type of exchanges between LCT (or any protocol instantiation 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 protocol instantiation 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の上に構築された任意のプロトコルのインスタンス）と上位アプリケーションとの間の交換のタイプを指定し、制限するものではありません。いくつかの上位APIは、データの唯一の可能な手段は、ソースで、または受信機のいずれかで、LCT（またはLCTの上に構築された任意のプロトコルのインスタンス）とアプリケーションとの間で交換さオブジェクト指向のアプローチを使用することが、目的です。他の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 it 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 [RFC0768], 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アドレスによってスコープされ、そしてTSIと共に、送信者のIPアドレスは、セッションを一意に識別しなければなりません。基礎となるトランスポートがUDPである場合は、[RFC0768]に記載されているように、その後、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 that does not have any support for flow or congestion control. For example, the Any-Source Multicast (ASM) model of IP multicast as defined in [RFC1112]
LCTは、パケットの受信やパケットの受信順序を保証するものではありません「ベストエフォート」のサービスである基礎となるネットワークまたはトランスポートサービスで使用していると推定され、それは、フローや輻輳制御のためのあらゆるサポートしていません。 [RFC1112]で定義されるようにIPマルチキャストの、例えば、任意-ソースマルチキャスト（ASM）モデル
is such a "best effort" network service. While the basic service provided by [RFC1112] is largely scalable, providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially in the presence of heterogeneous sets of receivers.
そのような「ベストエフォート」のネットワークサービスです。 [RFC1112]によって提供される基本的なサービスは、主にスケーラブルですが、輻輳制御や信頼性を提供することは、特に受信機の異質セットの存在下で、深刻なスケーラビリティの制限を回避するために、慎重に行われるべきです。
There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in [RFC1112] and the Source-Specific Multicast (SSM) model as defined in [RFC4607]. 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.
[RFC4607]で定義されるように[RFC1112]とソース固有マルチキャスト（SSM）モデルで定義されたマルチキャスト配信の二つのモデル、任意-ソースマルチキャスト（ASM）モデルは、現在存在しています。 LCTは、両方のマルチキャストモデルで動作しますが、多少異なる環境への懸念と少し異なる方法インチASMを使用する場合、送信者Sは、マルチキャストグループGにパケットを送信し、LCTチャネルアドレスは、Sは、送信者のIPアドレスでありGはマルチキャストグループアドレスである対（S、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チャンネルアドレスを割り当てることができ、そしてこれは、SSMとLCTチャネル・アドレスの割り当てが容易になります。 ASMを使用して、LCTチャネルアドレスを割り当てるために、送信者は、一意のグループの範囲を横切るASMマルチキャストグループアドレスを選択しなければならず、これは、ASMとLCTチャネルアドレスの割り当てをより困難にします。
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 (DoS) attacks. In either case, receivers SHOULD use packet authentication mechanisms to mitigate such attacks (see Sections 6.2 and 7).
LCTチャネルとSSMチャネルが一致するので、受信機は、要求されたLCTチャネルに送信されたパケットを受信します。受信機はマルチキャストグループGを接合してLCTチャネルを結合し、Gに送信されるすべてのパケットASMと、にかかわらず、送信者、受信機によって受信されてもよいです。このように、SSMは、サービス拒否（DoS）攻撃の防止のためのASM以上の魅力的なセキュリティ上の利点があります。いずれの場合においても、受信機は、（セクション6.2および7を参照）、このような攻撃を軽減するために、パケットの認証メカニズムを使用すべきです。
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 is compatible with both IPv4 and IPv6 as no part of the packet is IP version specific.
パケットのどの部分が、IPバージョン特定されないようにLCTは、IPv4とIPv6の両方に対応しています。
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.
プッシュサービスモデルは、信頼性の高いコンテンツ配信のために使用することができる一つの方法は、一連のオブジェクトを提供することです。例えば、受信機はセッションに参加し、動的受信機が十分なパケットがオブジェクトを再構築するために受信されるまでに接合され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.
プッシュモデルは、衛星ネットワークと無線ネットワークにおいて特に魅力的です。これらのケースでは、セッションは、一つの固定レートLCTチャネルから構成されてもよいです。
A push service model can be used, for example, for reliable delivery of a large object such as a 100 GB file. The sender could send a Session Description announcement to a control channel and receivers could monitor this channel and join a session whenever a Session Description of interest arrives. Upon receipt of the Session Description, each receiver could join the session to receive packets until enough packets have arrived to reconstruct the object, at which point the receiver could report back to the sender that its reception was completed successfully. The sender could decide to continue sending packets for the object to the session until all receivers have reported successful reconstruction or until some other condition has been satisfied.
プッシュサービスモデルは、100GBのファイルのような大きな物体の信頼できる配信のために、例えば、使用することができます。送信者は、制御チャネルにセッション記述の発表を送ることができるし、受信機は、このチャネルを監視し、関心のセッション記述が到着するたびにセッションに参加することができます。セッション記述を受信すると、各受信機は、十分なパケットが受信機はその受信が正常に完了したことを送信者に報告することがあり、その時点で対象物を、再構築するために到着するまでパケットを受信するセッションに参加できます。送信者は、すべての受信機が成功した再構成を報告したり他のいくつかの条件が満たされたまでするまでセッションへのオブジェクトのためのパケットの送信を継続することを決定することもできます。
There are several features Asynchronous Layered Coding (ALC) provides to support the push model. For example, the sender can optionally include an Expected Residual Time (ERT) in the packet header extension that indicates the expected remaining time of packet transmission for either the single object carried in the session or for the object identified by the Transmission Object Identifier (TOI) if there are multiple objects carried in the session. This can be used by receivers to determine if there is enough time remaining in the session to successfully receive enough additional packets to recover the object. If, for example, there is not enough time, then the push application may have receivers report back to the sender to extend the transmission of packets for the object for enough time to allow the receivers to obtain enough packets to reconstruct the object. The sender could then include an ERT based on the extended object transmission time in each subsequent packet header for the object. As other examples, the LCT header optionally can contain a Close Session flag that indicates when the sender is about to stop sending packets to the session and a Close Object flag that indicates when the sender is about to stop sending packets to the session for the object identified by the Transmission Object ID. However, these flags are not a completely reliable mechanism and thus the Close Session flag should only be used as a hint of when the session is about to close, and the Close Object flag should only be used as a hint of when transmission of packets for the object is about to end.
コーディング非同期階層（ALC）はプッシュモデルをサポートするために提供し、いくつかの機能があります。例えば、送信者は、必要に応じてセッションまたは送信対象識別子（TOIによって識別されたオブジェクトのために行わ単一のオブジェクトのいずれかのパケット送信の予想される残り時間を示すパケットヘッダ拡張で予想残余時間（ERT）を含むことができます）セッションで運ばれ、複数のオブジェクトがある場合。これが成功したオブジェクトを回復するために十分な追加のパケットを受信するためのセッションの残りの十分な時間があるかどうかを判断するために受信機で使用することができます。例えば、十分な時間がない場合は、プッシュアプリケーションは、受信機は受信機がオブジェクトを再構築するのに十分なパケットを得ることができるように十分な時間のためのオブジェクトのためのパケットの送信を拡張するために送信者に報告しています。送信者は、オブジェクトのための後続の各パケットヘッダの拡張オブジェクトの伝送時間に基づいて、ERTを含むことができます。他の例として、LCTヘッダは、必要に応じて、送信者がセッションへのパケットの送信を停止しようとしているときを示すクローズセッションフラグと送信者がオブジェクトのセッションへのパケットの送信を停止しようとしているときを示すクローズオブジェクトフラグを含むことができ送信対象のIDで識別されます。しかしながら、これらのフラグは、完全に信頼性の高いメカニズムではないので、クローズセッションフラグは、セッションがクローズしようとしているときのヒントとして使用されるべきである、と近距離物体フラグはパケットのみの場合に送信のためのヒントとして使用されるべきですオブジェクトは、終了しようとしています。
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. In this case, the receivers join the session at any point in time when it is active. Receivers leave the session when they have received enough packets to recover the object. The receivers, for example, obtain a Session Description by contacting a web server.
オンデマンドのコンテンツ配信サービスモデルの場合、送信者は、一般的に、すべての意図した受信機がセッションに参加してオブジェクトを回復できるように十分な長さに選択いくつかの特定の期間のために送信します。たとえば、人気のあるソフトウェアの更新は、受信機は、おそらく時間のいくつかの間隔に広がっ接続時間の1時間の合計でダウンロードを完了することができたとしても、数日間LCTを使用して送信される可能性があります。それがアクティブである場合この場合、受信機は、任意の時点でセッションに参加します。彼らはオブジェクトを回復するのに十分なパケットを受信したときの受信機がセッションを終了します。受信機は、例えば、Webサーバを接触させることにより、セッション記述を得ます。
In this case, the receivers join the session, and dynamically adapt the number of LCT channels to which they subscribe 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メガバイトであると仮定する。送信者は、ちょうどこのLCTチャネルを使用して受信機は損失の不在1,000秒でオブジェクトの受信を完了することができるように、毎秒50のパケットで最初LCTチャネルに1キロバイトのパケットを送信することができ、さらには存在の受信を完了することができるであろう信頼性のためのコーディングを使用した損失の一部、かなりの量の。さらに、送信者は、受信機は、わずか50秒でオブジェクトの受信を完了することができることができるように、すべてのLCTチャネルに1キロバイトのパケットの集約レートは、秒1,000パケットであるように（仮定をLCTチャネルの数を使用することができ輻輳制御機構は直ちに全てLCTチャネルの使用に収束することを損失しないと）。
Other service models
その他のサービスモデル
There are many other delivery service models for which LCT can be used 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セッションに使用される特定の輻輳制御プロトコルは、配信されるコンテンツのタイプに依存します。輻輳制御プロトコルの一般的な挙動は、輻輳の存在下でのスループットを低下させ、徐々に輻輳の不在下でそれを増加させることであるが、実際の動的挙動（例えば、単一の損失に対する応答）を変化させることができます。
It is RECOMMENDED that the congestion control mechanism specified in [RFC3738] be used. Some alternative possible congestion control protocols for reliable content delivery using LCT are described in [VIC1998] and [BYE2000]. Different delivery service models might require different congestion control protocols.
[RFC3738]で指定された輻輳制御機構を使用することを推奨されています。 LCTを用いた信頼性の高いコンテンツ配信のためのいくつかの代替可能な輻輳制御プロトコルは、[BYE2000] [VIC1998]に記載されています。異なる配信サービスモデルは、異なる輻輳制御プロトコルが必要になることがあります。
Packets sent to an LCT session MUST include an "LCT header". The LCT header format is described below.
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で使用される場合したがって、例えば、次に予想残余時間フィールドは、最大で一度各パケットに実施すべきです。
The position of the LCT header within a packet MUST be specified by any protocol instantiation that uses LCT.
パケット内のLCTヘッダの位置は、LCTを使用する任意のプロトコルのインスタンスで指定されなければなりません。
The 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 in this version of the specification. Unless otherwise noted, numeric constants in this specification are in decimal form (base 10).
LCTヘッダは、ヘッダの第3バイトの長さフィールドで指定された可変サイズのものです。 LCTヘッダに、すべての整数フィールドが最初つまり、最上位バイト（オクテット）、「ビッグエンディアン」または「ネットワーク順」形式で行われます。ビットは送信者によって0に設定することによって「パディング」または「予約」（登録商標）MUSTとして指定され、仕様のこのバージョンでは受信機によって無視されます。特に断りのない限り、本明細書中の数値定数は小数点形式（ベース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 |PSI|S| O |H|Res|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) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
デフォルトのLCTヘッダの各フィールドの機能と長さは以下の通りです。
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ビットであることを示します。
Protocol-Specific Indication (PSI): 2 bits
プロトコル固有の表示（PSI）：2ビット
The usage of these bits, if any, is specific to each protocol instantiation that uses the LCT building block. If no protocol-instantiation-specific usage of these bits is defined, then a sender MUST set them to zero and a receiver MUST ignore these bits.
これらのビットの使用は、もしあれば、LCTビルディングブロックを使用する各プロトコルのインスタンス化に固有です。これらのビットのないプロトコルインスタンス固有用法が定義されていない場合、送信者はゼロにそれらを設定しなければなりませんし、受信機は、これらのビットを無視しなければなりません。
Transport Session Identifier flag (S): 1 bit
移送セッション識別子フラグ（S）：1ビット
This is the number of full 32-bit words in the TSI field. The TSI field is 32*S + 16*H bits in length, 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フィールドの総計長さが32ビットの倍数であることを保証しながらこれは、TSIとTOIフィールド長がハーフワード（16ビット）の倍数にすることができます。
Reserved (Res): 2 bits
予約（RES）：2ビット
These bits are reserved. In this version of the specification, they MUST be set to zero by senders and MUST be ignored by receivers.
これらのビットは予約されています。このバージョンの仕様では、彼らは、送信者によってゼロに設定しなければならなくて、受信機で無視しなければなりません。
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に設定されている送信者が1に設定してもよいです。セッションのために送信さだけで最後のパケットに1に設定されてもよいし、Aは、セッションのために送信されるパケットの最後の数秒で1に設定されるかもしれません。送信者が一つのパケットを1に設定した後、送信者は、セッションのパケットの送信が終了するまで、後続のすべてのパケットに1に設定すべきです。 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 that packets are 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は、オブジェクトに対するパケットの送信の終了が差し迫っている場合、送信者が1にBを設定することが0に設定されます。 TOIフィールドが使用中であり、Bが1に設定されている場合、TOIフィールドによって識別されたオブジェクトのための伝送の終了が迫っています。 TOIフィールドが使用されておらず、Bが1に設定されている場合、アウト・オブ・バンド情報によって識別されるセッション内の1つのオブジェクトの伝送の終了が迫っています。 Bは、オブジェクトに対して送信だけで最後のパケットに1に設定されてもよいし、Bはパケットがオブジェクトに対して送信された最後の数秒で1に設定されるかもしれません。送信者が特定の目的のために一つのパケットを1にBを設定した後、送信者は、オブジェクトに対するパケットの送信が終了するまで、オブジェクトのすべての後続のパケットで1にBを設定する必要があります。 1〜Bが設定された受信パケットは、送信者がすぐにオブジェクトのパケットの送信を停止することを受信機に示します。受信機が1にBがセットされたパケットを受信すると、それはもはやパケットがセッションへのオブジェクトのために送られないことを想定すべきです。
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
コードポイント（CP）：8ビット
An opaque identifier that 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 [RFC3550].
コーデックに関する情報を伝達するために、パケットペイロード復号器に渡される不透明な識別子は、パケット・ペイロードのために使用されています。コードポイントと実際のコーデックとの間のマッピングは、セッションごとに定義され、セッション記述情報の一部として、アウトオブバンド通信されます。 [RFC3550]で説明されるようにCPフィールドの使用は、RTPヘッダ内のペイロードタイプ（PT）フィールドに類似しています。
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.
C = 0の場合、このフィールドは32ビットでなければなりません。
This field MUST be 64 bits if C=1.
C = 1の場合、このフィールドは64ビットでなければなりません。
This field MUST be 96 bits if C=2.
C = 2の場合、このフィールドは96ビットでなければなりません。
This field MUST be 128 bits if C=3.
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アドレスによってスコープされ、したがって、送信者のIPアドレスとTSIは一緒にセッションを一意に識別する。送信元の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 to which receivers are subscribed. For example, suppose a session is deactivated and then another session is activated by a sender and the two sessions use an overlapping set of channels. A receiver that connects and remains connected to the first session during this sender activity could possibly accept packets from the second session as belonging to the first session if the TSI for the two sessions were identical. The mapping of TSI field values to sessions is outside the scope of this document and is to be done out-of-band.
TSIは、セッションがアクティブである期間中に、送信者が提供するすべてのセッションの中で一意であること、そしてセッションがアクティブなとき、前後の時間の大期間にしなければなりません。 TSIの主な目的は、誤って受信機がサブスクライブされたセッション以外のセッションに属している送信者からのパケットを受け入れるの受信を防止するためです。例えば、セッションが非アクティブ化され、その後、別のセッションが送信者によって活性化され、2つのセッションがチャネルの重複セットを使用すると仮定する。二つのセッションのためのTSIが同一であった場合に接続し、この送信者の活動中に第1のセッションに接続されたまま受信機は、おそらく最初のセッションに属しているように、第2のセッションからのパケットを受け入れることができます。セッションへのTSIフィールド値のマッピングは、この文書の範囲外であると帯域外で行われるべきです。
The length of the TSI field is 32*S + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits.
TSIフィールドの長さは32 * S + 16 * Hビットです。 TSIフィールドの集合体の長さプラスTOIフィールドは、32ビットの倍数であることに留意されたいです。
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 to which object within the session this packet pertains. 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.
このフィールドは、このパケットが属するセッション内のオブジェクトしているかを示します。例えば、送信者は、別の例として第1、等のために、最初のファイルのTOI = 0を使用して、TOI = 1を同じセッション内のファイル数を送信するかもしれない、TOIは、オブジェクトの一意のグローバル識別子であってもよいですそれは、同時にいくつかの送信者から送信されている、及びTOI値がオブジェクトに適用されるハッシュ関数の出力であってもよいです。オブジェクトにTOIフィールド値のマッピングは、この文書の範囲外であると帯域外で行われるべきです。複数のオブジェクト、すなわち、TOIフィールドは、セッションのすべてのパケットに存在であるか、または存在し決して、セッションで送信される場合TOIフィールドは、すべてのパケットで使用されなければなりません。
The length of the TOI field is 32*O + 16*H bits. Note that the aggregate length of the TSI field plus the TOI field is a multiple of 32 bits.
TOIフィールドの長さは32 * O + 16 * Hビットです。 TSIフィールドの総計長さプラスTOIフィールドは、32ビットの倍数であることに留意されたいです。
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。
o Transmission of timing information.
タイミング情報の入出力伝送。
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バージョン番号を変更せずに導入することができません。
There are two formats for Header Extension fields, as depicted in Figure 2. 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.
ヘッダ拡張タイプ（HET）は、第2のフォーマットは、固定長のために使用されて0と127の間の値（一方で、最初のフォーマットは可変長の拡張のために使用される図2に示されるように、ヘッダ拡張フィールドのための2つの形式があります127から255までHET値を使用して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 (HETs between 0 and 127) and MUST NOT be present for fixed-length extensions (HETs between 128 and 255).
全体ヘッダー拡張フィールドの長さは、32ビットワードの倍数で表しました。このフィールドは、（0と127の間のHETS）可変長の拡張のために存在しなければならず、固定長の延長部（128と255との間のHETS）のために存在してはなりません。
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ビットです。 HELフィールドによって指定された可変長ヘッダ拡張のために、HECフィールドは、可変サイズを有しています。各ヘッダ拡張フィールドの長さが32ビットの倍数でなければならないことに留意されたいです。また、すべてのヘッダ拡張し、すべてのオプションのヘッダーフィールドを含むLCTヘッダの合計サイズは、255の32ビットワードを超えることができないことに注意してください。
The following LCT Header Extensions are defined by this specification:
以下のLCTヘッダ拡張は、この仕様で定義されています。
EXT_NOP, HET=0 No-Operation extension. The information present in this extension field MUST be ignored by receivers.
EXT_NOP、HETは0ノーオペレーションの拡張子を=。この拡張フィールドに存在する情報は、受信機によって無視されなければなりません。
EXT_AUTH, HET=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、HETは、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 SHOULD NOT be postponed by any such full packet authentication.
いくつかのパケットの認証方式は、パケットを受信したときに、パケットが完全に認証されたときの間に、数秒の遅延を課します。適切である任意の輻輳制御に関連するアクションは、このような完全なパケット認証によって延期されるべきではありません。
EXT_TIME, HET=2 Time Extension. This extension is used to carry several types of timing information. It includes general purpose timing information, namely the Sender Current Time (SCT), Expected Residual Time (ERT), and Sender Last Change (SLC) time extensions described in the present document. It can also be used for timing information with narrower applicability (e.g., defined for a single protocol instantiation); in this case, it will be described in a separate document.
EXT_TIME、HET = 2時間延長。この拡張機能は、タイミング情報のいくつかのタイプを運ぶために使用されます。これは、汎用のタイミング情報は、本文書に記述すなわち残留時間（ERT）期待送信者の現在の時刻（SCT）、および送信者最終更新（SLC）の時間拡張を含んでいます。また狭い適用してタイミング情報のために使用することができる（例えば、単一のプロトコルのインスタンスに対して定義されました）。この場合には、それは別の文書で説明します。
All senders and receivers implementing LCT MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH and EXT_TIME, but are not required to be able to parse their content.
LCTを実装するすべての送信者と受信者はEXT_NOPヘッダー拡張をサポートしなければならないとEXT_AUTHとEXT_TIMEを認識しなければならないが、その内容を解析できるようにする必要はありません。
This section defines the timing Header Extensions with general applicability. The time values carried in this Header Extension are related to the server's wall clock. The server MUST maintain consistent relative time during a session (i.e., insignificant clock drift). For some applications, system or even global synchronization of server wall clock may be desirable, such as using the Network Time
このセクションでは、一般的な適用とタイミングヘッダ拡張を定義します。このヘッダー拡張で運ばれた時間値は、サーバの壁時計に関連しています。サーバは、セッション（すなわち、無意味クロックドリフト）の間に一貫した相対的な時間を維持しなければなりません。いくつかの適用のために、システムまたはサーバウォールクロックの偶数グローバル同期は、ネットワークタイムを使用するなど、望ましいかもしれません
Protocol (NTP) [RFC1305] to ensure actual time relative to 00:00 hours GMT, January 1st 1900. Such session-external synchronization is outside the scope of this document.
GMT、1月1日1900このようなセッションの外部同期は、この文書の範囲外である00:00までの実際の時間と比較を確保するプロトコル（NTP）[RFC1305]。
The EXT_TIME Header Extension uses the format depicted in Figure 3.
EXT_TIMEヘッダ拡張は、図3に示されているフォーマットを使用します。
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 = 2 | HEL >= 1 | Use (bit field) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first time value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (other time values (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EXT_TIME Header Extension Format
図3：EXT_TIMEヘッダ拡張フォーマット
The "Use" bit field indicates the semantic of the following 32-bit time value(s).
ビットフィールドは、以下の32ビットの時間値（S）の意味を示す「使用します」。
It is divided into two parts:
これは2つの部分に分かれています。
o 8 bits are reserved for general purpose timing information. This information is applicable to any protocol that makes use of LCT.
O 8ビットは、汎用タイミング情報のために予約されています。この情報は、LCTを使用する任意のプロトコルに適用されます。
o 8 bits are reserved for PI-specific timing information. This information is out of the scope of this document.
O 8ビットは、PI-特定のタイミング情報のために予約されています。この情報は、このドキュメントの範囲外です。
The format of the "Use" bit field is depicted in Figure 4.
「使用」ビットフィールドのフォーマットは、図4に示されています。
2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|SCT|SCT|ERT|SLC| reserved | PI-specific |
|Hi |Low| | | by LCT | use |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 4: "Use" Bit Field Format
図4：ビットフィールドフォーマットを「使用します」
Several "time value" fields MAY be present in a given EXT_TIME Header Extension, as specified in the "Use-field". When several "time value" fields are present, they MUST appear in the order specified by the associated flag position in the "Use-field": first SCT-High (if present), then SCT-Low (if present), then ERT (if present), then SLC (if present). Receivers SHOULD ignore additional fields within the EXT_TIME Header Extension that they do not support.
いくつかの「時間値」フィールドが「使用・フィールド」で指定され、与えられたEXT_TIMEヘッダー拡張中に存在することができます。いくつかの「時間値」フィールドが存在する場合、それらは「使用フィールド」に対応するフラグの位置によって指定された順序で現れなければならない：第一SCTハイ（存在する場合）（存在する場合）、次いでSCT低、次にERT （存在する場合）、次いで、SLC（存在する場合）。レシーバは、彼らがサポートしていないことをEXT_TIMEヘッダ拡張内に追加のフィールドを無視する必要があります。
The fields for the general purpose EXT_TIME timing information are:
タイミング情報を汎用EXT_TIMEのためのフィールドは、次のとおりです。
Sender Current Time (SCT): SCT-High flag, SCT-Low flag, corresponding time value (one or two 32-bit words).
送信側現在時刻（SCT）：SCT-高フラグ、SCT低フラグ、対応する時間値（一つまたは2つの32ビットワード）。
This timing information represents the current time at the sender at the time this packet was transmitted.
このタイミング情報は、このパケットが送信された時点で、送信者に現在の時刻を表します。
When the SCT-High flag is set, the associated 32-bit time value provides an unsigned integer representing the time in seconds of the sender's wall clock. In the particular case where NTP is used, these 32 bits provide an unsigned integer representing the time in seconds relative to 00:00 hours GMT, January 1st 1900, (i.e., the most significant 32 bits of a full 64-bit NTP time value). In that case, handling of wraparound of the 32-bit time is outside the scope of NTP and LCT.
SCT-高フラグがセットされている場合、関連する32ビットの時間値は、送信者の壁時計の秒数を表す符号無し整数を提供します。 NTPが使用されている特定の場合において、これらの32ビットは00:00 GMTに対する秒単位の時間を表す符号無し整数、1月1日1900与える（すなわち、完全な64ビットのNTPタイム値の最上位32ビット）。その場合、32ビット時間のラップアラウンドの取り扱いは、NTPとLCTの範囲外です。
When the SCT-Low flag is set, the associated 32-bit time value provides an unsigned integer representing a multiple of 1/2^^32 of a second, in order to allow sub-second precision. When the SCT-Low flag is set, the SCT-High flag MUST be set, too. In the particular case where NTP is used, these 32 bits provide the 32 least significant bits of a 64-bit NTP timestamp.
SCT低フラグがセットされている場合、関連する32ビットの時間値は、サブ秒の精度を可能にするために、第二の/ 2 ^^ 32の倍数を表す符号なし整数を提供します。 SCT-低フラグが設定されている場合、SCT-ハイフラグも設定しなければなりません。 NTPが使用されている特定の場合において、これらの32ビットは、64ビットのNTPタイムスタンプの32個の最下位ビットを提供します。
Expected Residual Time (ERT): ERT flag, corresponding 32-bit time value.
予想残余時間（ERT）：32ビットの時間値に対応するERTフラグ。
This timing information represents the sender expected residual transmission time for the transmission of the current object. If the packet containing the ERT timing information also contains the TOI field, then ERT refers to the object corresponding to the TOI field; otherwise, it refers to the only object in the session.
このタイミング情報は、現在のオブジェクトの送信のために送信者予想残余伝送時間を表します。また、ERTタイミング情報を含むパケットは、TOIフィールドが含まれている場合、ERTは、TOIフィールドに対応するオブジェクトを指します。それ以外の場合は、セッション内のオブジェクトのみを参照します。
When the ERT flag is set, it is expressed as a number of seconds. The 32 bits provide an unsigned integer representing this number of seconds.
ERTフラグがセットされている場合は、秒数として表現されます。 32ビットは、この秒数を表す符号無し整数を与えます。
Session Last Changed (SLC): SLC flag, corresponding 32-bit time value.
変更されたセッションの最後（SLC）：SLCフラグ、対応する32ビットの時間値。
The Session Last Changed time value is the server wall clock time, in seconds, at which the last change to session data occurred. That is, it expresses the time at which the last (most recent)
セッションの最後に変更された時間値は、セッションデータへの最後の変更が発生した秒でサーバーウォールクロック時間、です。つまり、それは時間を表している最後（最新）
Transport Object addition, modification, or removal was made for the delivery session. In the case of modifications and additions, it indicates that new data will be transported that was not transported prior to this time. In the case of removals, SLC indicates that some prior data will no longer be transported.
トランスポートオブジェクトの追加、変更、または削除は配信セッションのために作られました。変更および追加の場合には、新たなデータが、この時間の前に輸送されなかったことに輸送されることを示しています。削除の場合には、SLCは、いくつかの前のデータがもはや運ばないことを示しています。
When the SLC flag is set, the associated 32-bit time value provides an unsigned integer representing a time in seconds. In the particular case where NTP is used, these 32 bits provide an unsigned integer representing the time in seconds relative to 00:00 hours GMT, January 1st 1900, (i.e., the most significant 32 bits of a full 64-bit NTP time value). In that case, handling of wraparound of the 32-bit time is outside the scope of NTP and LCT.
SLCフラグが設定されている場合、関連する32ビットの時間値は、秒単位の時間を表す符号なし整数を提供します。 NTPが使用されている特定の場合において、これらの32ビットは00:00 GMTに対する秒単位の時間を表す符号無し整数、1月1日1900与える（すなわち、完全な64ビットのNTPタイム値の最上位32ビット）。その場合、32ビット時間のラップアラウンドの取り扱いは、NTPとLCTの範囲外です。
In some cases, it may be appropriate that a packet containing an EXT_TIME Header Extension with SLC information also contain an SCT-High information.
場合によっては、SLC情報をEXT_TIMEヘッダ拡張を含むパケットもSCT-高情報を含むことが適切であり得ます。
Reserved by LCT for future use (4 bits):
（4ビット）は、将来の使用のためにLCTによって予約。
In this version of the specification, these bits MUST be set to zero by senders and MUST be ignored by receivers.
仕様のこのバージョンでは、これらのビットは送信者によってゼロに設定しなければならなくて、受信機で無視しなければなりません。
PI-specific use (8 bits):
PI-特定の使用（8ビット）：
These bits are out of the scope of this document. The bits that are not specified by the PI built on top of LCT SHOULD be set to zero.
これらのビットは、この文書の範囲外です。 LCTの上に構築されたPIによって指定されていないビットはゼロに設定されるべきです。
The total EXT_TIME length is carried in the HEL, since this Header Extension is of variable length. It also enables clients to skip this Header Extension altogether if not supported (but recognized).
このヘッダ拡張が可変長であるため、総EXT_TIME長は、HELで運ばれます。また、サポート（しかし、認識される）でない場合は完全にこの拡張ヘッダをスキップするためにクライアントを可能にします。
Before joining an LCT session, a receiver MUST obtain a session description. The session description MUST include:
LCTセッションに参加する前に、受信機は、セッション記述を取得しなければなりません。セッション記述が含まれている必要があります
o The sender IP address;
送信元のIPアドレスO;
o The number of LCT channels;
LCTチャネルの数O;
o The addresses and port numbers used for each LCT channel;
各LCTチャネルに使用されるアドレスとポート番号O;
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 one is being used).
（一方が使用されている場合）が使用されているパケットの認証方式を決定するために十分な情報を、O。
The session description could also include, but is not limited to:
セッション記述も含めることができるが、これらに限定されません。
o The data rates used for each LCT channel;
各LCTチャネルに使用されるデータレートO;
o The length of the packet payload;
パケットペイロードの長さがOであり;
o The mapping of TOI value(s) to objects for the session;
セッションのオブジェクトにTOI値（S）のマッピングO;
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 be included in the session description.
LCTを使用してプロトコルのインスタンス化は、セッション記述に含まれなければならないものに追加の要件を配置することがあります。例えば、プロトコルのインスタンスは、各チャネル、またはセッションのオブジェクトにTOI値（S）のマッピング、または必要とされるかもしれない他のヘッダに関連する他の情報のためのデータレートは、セッション記述に含まれることを必要とするかもしれません。
The session description could be in a form such as SDP as defined in [RFC4566], or another format appropriate to a particular application. It might be carried in a session announcement protocol such as SAP as defined in [RFC2974], obtained using a proprietary session control protocol, located on a Web page with scheduling information, or conveyed via email or other out-of-band methods. Discussion of session description format, and distribution of session descriptions is beyond the scope of this document.
[RFC4566]、または特定の用途に適した別の形式で定義されているセッション記述は、SDPのような形態であってもよいです。 [RFC2974]で定義されるように、それは、SAPなどのセッションアナウンスメントプロトコルで運ばれるかもしれない、電子メールまたは他の帯域外方法を介して、スケジューリング情報をWebページ上に配置独自のセッション制御プロトコルを用いて、又は搬送得ます。セッション記述形式、およびセッション記述の分布の説明は、この文書の範囲外です。
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 in which they have no interest.
複数のオブジェクトが同じ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 [VIC1998], [BYE2000], and [RFC3738]. A sender of packets using LCT MUST implement the sender-side part of one of the congestion control schemes that is in accordance with [RFC2357] 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.
すべてのパケットが同じ又は非常に類似したサイズを有することが、これは、輻輳制御方式の有効性に深刻な影響を与えることができるように、このような[VIC1998]に記載のもの、[BYE2000]、および[RFC3738]として、推奨されます。 LCTを使用してパケットの送信元は[RFC2357]に従ってLCTヘッダに設けられた輻輳制御情報フィールドを使用している輻輳制御方式の一つの送信側の一部を実装しなければなりません、そして、対応する受信機の輻輳制御方式があることがありますアウトオブバンド通信され、セッションに参加しているいずれかの受信機によって実装されなければなりません。
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 an 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.
受信機は、同時に一つ以上の送信者から複数LCTセッションに接合することができます。受信機は、このような各LCTセッションに輻輳制御を実行しなければなりません。輻輳制御プロトコルは、受信機にセッション内での行動の面でいくつかの柔軟性を可能にした場合、受信機は、受信機がまだのための輻輳制御ルールに準拠している限り、複数のLCTのセッション間でパケットフローのパフォーマンスを最適化するための選択を行うことができます個別LCTセッション。
As described in [RFC3048], 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
[RFC3048]に記載されているように、LCTは、プロトコルのインスタンスを指定するために役立つ、他のビルディングブロックと組み合わせて、使用されることが意図されるビルディングブロックです。内の輻輳制御情報フィールドを使用して輻輳制御ビルディングブロック
LCT header MUST be used by any protocol instantiation that uses LCT; other building blocks MAY also be used, such as a reliability building block.
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. 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セッションに適用されなければなりません。 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 [RFC3453]. Some of the FEC codecs that MAY be used in conjunction with LCT for reliable content delivery are specified in [RFC5052]. 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.
高信頼マルチキャストトランスポート（RMT）プロトコルにおけるFECの使用のより詳細な説明は、[RFC3453]に記載されています。信頼性の高いコンテンツ配信のためにLCTと組み合わせて使用することができるFECコーデックの中には、[RFC5052]で指定されています。 LCTヘッダ内のコードポイントフィールドは、パケットのペイロードの符号化に関連した情報を搬送するために使用することができる不透明なフィールドです。
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 [RFC4566], or another format appropriate to a particular application and may be distributed with SAP as defined in [RFC2974], using HTTP, or in other ways. It is RECOMMENDED that an authentication protocol be used to deliver the session description to receivers to ensure the correct session description arrives.
6.1節で説明したようにLCTはまた、セッション記述を取得するために受信機を必要とします。 [RFC4566]で定義された、または特定のアプリケーションに別の形式の適切な及び[RFC2974]で定義されるようにSAPと一緒に配布されてもよい、HTTPを使用して、または他の方法で、セッション記述は、SDPとしての形態であってもよいです。認証プロトコルが記述が到着正しいセッションを確実にするために、受信機にセッション記述を送達するために使用することを推奨されています。
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 [Perrig2001].
LCTの実装は、攻撃からプロトコルを保護するために、いくつかのパケットの認証方式を使用することをお勧めします。おそらく適切なスキームの一例は、[Perrig2001]に記載されています。
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 is a building block as defined in [RFC3048] and as such does not define a complete protocol. Protocol instantiations that use the LCT building block MUST address the potential vulnerabilities described in the following sections. For an example, see [ALC-PI].
LCTは、[RFC3048]で定義されるように構築ブロックであり、そのようなものとして、完全なプロトコルを定義していません。 LCTのビルディングブロックを使用するプロトコルのインスタンスは、次のセクションで説明した潜在的な脆弱性に対処しなければなりません。たとえば、[ALC-PI]を参照してください。
Protocol instantiations could address the vulnerabilities described below by taking measures to prevent receivers from accepting incorrect packets, for example, by using a source authentication and content integrity mechanism. See also Sections 6.2 and 7 for discussion of packet authentication requirements.
プロトコルのインスタンス化は、例えば、ソース認証とコンテンツの完全性メカニズムを使用することにより、不正なパケットを受け入れるのレシーバを防止するための措置をとることによって、以下の脆弱性に対処することができます。パケットの認証要件の議論については、セクション6.2と7をも参照してください。
Note that for correct operation, LCT assumes availability of session description information (see Sections 4 and 7). Incorrect or maliciously modified session description information may result in receivers being 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. Protocol instantiations MUST address this potential vulnerability, for example, by providing source authentication and integrity mechanisms for the session description. Additionally, these mechanisms MUST allow the receivers to securely verify the correspondence between session description and LCT data packets.
（セクション4および7を参照）の正しい動作のために、LCTは、セッション記述情報の利用可能性を想定しています。不正または悪意を持って変更されたセッション記述情報は、受信機が正しくセッションコンテンツを受信、または受信機が誤って彼らがそれによってネットワークの一部でトラフィックを中断、可能であるよりもはるかに高いレートで受信するように試みることができないことをもたらすことができます。プロトコルのインスタンス化は、例えば、セッション記述のソースの認証と完全性機構を提供することにより、この潜在的な脆弱性に対処しなければなりません。さらに、これらのメカニズムは、受信機が確実にセッション記述とLCTデータパケットとの対応関係を確認することができなければなりません。
The following sections consider further each of the services provided by LCT.
次のセクションでは、さらに、各LCTが提供するサービスのことを検討してください。
The Transport Session Identifier and the Transport Object Identifier in the LCT header provide for multiplexing of sessions and objects. Modification of these fields by an attacker could have the effect of depriving a session or object of data and potentially directing incorrect data to another session or object, in both cases effecting a denial-of-service attack.
トランスポートセッション識別子及びLCTヘッダ内のトランスポート・オブジェクト識別子は、セッションおよびオブジェクトの多重化を提供します。攻撃者によるこれらのフィールドの変更は、データのセッションまたはオブジェクトを奪って、潜在的にサービス拒否攻撃を行う両方のケースでは、別のセッションまたはオブジェクトに誤ったデータを向けるの影響を与える可能性があります。
Additionally, injection of forged packets with fake TSI or TOI values may cause receivers to allocate resources for additional sessions or objects, again potentially effecting a DoS attack.
また、偽のTSIまたはTOI値を持つ偽造パケットの注入は再び潜在的にDoS攻撃を行う、追加のセッションまたはオブジェクトのためのリソースを割り当てるために受信機が発生することがあります。
The Close Object and Close Session bits in the LCT header provide for signaling of the end of a session or object. Modification of these fields by an attacker could cause receivers to incorrectly behave as if the session or object had ended, resulting in a denial-of-service attack, or conversely to continue to unnecessarily utilize resources after the session or object has ended (although resource utilization in this case is largely an implementation issue).
LCTヘッダ内の近距離物体と閉じるセッションビットがセッションまたはオブジェクトの終了のシグナルを提供します。リソースが攻撃者によって、これらのフィールドの変更は、（サービス拒否攻撃で、その結果、セッションまたはオブジェクトが終了したかのように受信機が正しく動作する可能性があり、あるいは逆にセッションまたはオブジェクトが終了した後に、不必要なリソースを活用し続けることこの場合、利用）は、主に実装の問題です。
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms).
上記脆弱性の結果として、これらのフィールドは、（例えば、ソース認証およびデータの整合性メカニズムのため）プロトコルのインスタンスのセキュリティメカニズムによって保護されなければなりません。
The SCT and ERT mechanisms provide rudimentary time synchronization features which can both be subject to attacks. Indeed an attacker can easily de-synchronize clients, sending erroneous SCT information, or mount a DoS attack by informing all clients that the session (respectively, a particular object) is about to be closed.
SCTとERTメカニズムは、両方の攻撃を受けることができる基本的な時刻同期機能を提供します。実際に攻撃者が容易に脱同期させることができ、誤ったSCT情報を送信し、クライアント、またはセッション（それぞれ、特定のオブジェクト）が閉鎖されようとしていることをすべてのクライアントに通知することにより、DoS攻撃をマウントします。
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms).
上記脆弱性の結果として、これらのフィールドは、（例えば、ソース認証およびデータの整合性メカニズムのため）プロトコルのインスタンスのセキュリティメカニズムによって保護されなければなりません。
The LCT protocol provides for transport of information for other building blocks, specifically the PSI field for the protocol instantiation, the Congestion Control field for the Congestion Control building block, the Codepoint field for the FEC building block, the EXT-AUTH Header Extension (used by the protocol instantiation) and the packet payload itself.
LCTプロトコルはプロトコルのインスタンス化のために、他のビルディングブロックの情報を搬送するために、具体的にPSIフィールドを提供し、輻輳制御ビルディングブロックの輻輳制御フィールドは、FECビルディングブロックのコードポイントフィールドは、EXT-AUTHヘッダ拡張機能（使用しますプロトコルインスタンス）およびパケットペイロード自体による。
Modification of any of these fields by an attacker may result in a denial-of-service attack. In particular, modification of the Codepoint or packet payload may prevent successful reconstruction or cause inaccurate reconstruction of large portions of an object by receivers. Modification of the Congestion Control field may cause receivers to attempt to receive at an incorrect rate, potentially worsening or causing a congestion situation and thereby effecting a DoS attack.
攻撃者によるこれらのフィールドのいずれかの変更はDoS攻撃をもたらすことができます。具体的には、コードポイントまたはパケットペイロードの変更は成功再構成を防止することができる、または受信することによって、オブジェクトの大部分の不正確な再構成を引き起こします。輻輳制御フィールドの変更は、潜在的に悪化や混雑状況を引き起こし、それによってDoS攻撃を行う、受信機は、誤ったレートで受信しようとする可能性があります。
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms).
上記脆弱性の結果として、これらのフィールドは、（例えば、ソース認証およびデータの整合性メカニズムのため）プロトコルのインスタンスのセキュリティメカニズムによって保護されなければなりません。
This document defines a new namespace for "LCT Header Extension Types". Values in this namespace are integers between 0 and 255 (inclusive).
この文書は、「LCTヘッダ拡張タイプ」のための新しい名前空間を定義します。この名前空間の値は0〜255（両端を含む）の間の整数です。
Values in the range 0 to 63 (inclusive) are reserved for use for variable-length LCT Header Extensions and assignments shall be made through "IETF Review" as defined in [RFC5226].
[RFC5226]で定義されるように「IETFレビュー」を通じて行われなければならない範囲は0〜63（両端を含む）の値は、可変長LCTヘッダ拡張および割り当てのための使用のために予約されています。
Values in the range 64 to 127 (inclusive) are reserved for variable-length LCT Header Extensions and assignments shall be made on the "Specification Required" basis as defined in [RFC5226].
範囲内の値64〜127（両端を含む）可変長LCTヘッダ拡張および割り当てのために予約されている[RFC5226]で定義されるように「仕様が必要」に基づいて行わなければなりません。
Values in the range 128 to 191 (inclusive) are reserved for use for fixed-length LCT Header Extensions and assignments shall be made through "IETF Review" as defined in [RFC5226].
範囲128〜191（両端を含む）の値は[RFC5226]で定義されるように「IETFレビュー」を通じて行われなければならない固定長LCTヘッダ拡張および割り当てのための使用のために予約されています。
Values in the range 192 to 255 (inclusive) are reserved for fixed-length LCT Header Extensions and assignments shall be made on the "Specification Required" basis as defined in [RFC5226].
範囲内の値192〜255（両端を含む）固定長LCTヘッダ拡張および割り当てのために予約されている[RFC5226]で定義されるように「仕様が必要」に基づいて行わなければなりません。
Initial values for the LCT Header Extension Type registry are defined in Section 9.2.
LCTヘッダ拡張タイプレジストリの初期値は、9.2節で定義されています。
Note that the previous Experimental version of this specification reserved values in the ranges [64, 127] and [192, 255] for PI-specific LCT Header Extensions. In the interest of simplification and since there were no overlapping allocations of these LCT Header Extension Type values by PIs, this document specifies a single flat space for LCT Header Extension Types.
なお、PI特異LCTヘッダ拡張のための範囲[64、127]及び[192、255]で本明細書予約値以前の実験バージョン。簡素化の利益のために、これらLCTヘッダ拡張タイプ値の重複割り当てが主任研究者でなかったことから、この文書では、LCTヘッダ拡張タイプのための単一のフラットなスペースを指定します。
This document registers three values in the LCT Header Extension Type namespace as follows:
次のようにこの文書では、LCTヘッダ拡張タイプの名前空間に三つの値を登録します。
+-------+----------+--------------------+
| Value | Name | Reference |
+-------+----------+--------------------+
| 0 | EXT_NOP | This specification |
| | | |
| 1 | EXT_AUTH | This specification |
| | | |
| 2 | EXT_TIME | This specification |
+-------+----------+--------------------+
This specification is substantially based on RFC 3451 [RFC3451] and thus credit for the authorship of this document is primarily due to the authors of RFC 3451: Mike Luby, Jim Gemmel, Lorenzo Vicisano, Luigi Rizzo, Mark Handley, and Jon Crowcroft. Bruce Lueckenhoff,
この仕様は、実質的にRFC 3451 [RFC3451]に基づいて、したがって、本書の著者のためのクレジットは、主にRFC 3451の作者によるものです：マイク・ルビー、ジムGemmel、ロレンツォVicisano、ルイジ・リゾ、マーク・ハンドリー、そしてジョン・クロークロフト。ブルースLueckenhoff、
Hayder Radha, and Justin Chapweske also contributed to RFC 3451. Additional thanks are due to Vincent Roca, Rod Walsh, and Toni Paila for contributions to this update to Proposed Standard.
Hayderラダ、およびジャスティンChapweskeも3451.追加のおかげで、標準案にこの更新への貢献のためにヴィンセントロカ、ロッド・ウォルシュ、そしてトニーPailaに起因するものであるRFCに貢献しました。
This section summarizes the changes that were made from the Experimental version of this specification published as RFC 3451 [RFC3451]:
このセクションでは、RFC 3451 [RFC3451]として発行され、この明細書の実験のバージョンから行われた変更を要約したものです。
o Removed the 'Statement of Intent' from the introduction. (The statement of intent was meant to clarify the "Experimental" status of RFC 3451.)
O導入から「意向書」を削除しました。 （意図の文は、RFC 3451.の「実験」の状態を明確にするためのものでした）
o Inclusion of material from ALC that is applicable in the more general LCT context.
より一般的なLCTコンテキストに適用可能であるALCからの材料のO含めます。
o Creation of an IANA registry for LCT Header Extensions.
O LCTヘッダ拡張のためのIANAレジストリの作成。
o Allocation of the 2 'reserved' bits in the LCT header as "Protocol-Specific Indication" - usage to be defined by protocol instantiations.
O「プロトコル固有の表示」としてLCTヘッダ内の2「予約」ビットの割り当て - 使用は、プロトコルのインスタンスによって定義されます。
o Removal of the Sender Current Time and Expected Residual Time LCT header fields.
送信者の現在時刻と期待残余時間LCTヘッダフィールドのOの除去。
o Inclusion of a new Header Extension, EXT_TIME, to replace the SCT and ERT and provide for future extension of timing capabilities.
O新しいヘッダー拡張、EXT_TIME、の包含は、SCTとERTを交換し、タイミング機能の将来の拡張のために提供します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112、1989年8月 "IPマルチキャスティングのためのホスト拡大"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]ワトソン、M.、ルビー、M.、およびL. Vicisano、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 5052、2007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[ALC-PI] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", Work in Progress, September 2009.
[ALC-PI]ルビー、M.、ワトソン、M.、およびL. Vicisanoは、進行中、仕事、2009年9月の "非同期階層は（ALC）プロトコルインスタンスのコーディング"。
[BYE1998] Byers, J., Luby, M., Mitzenmacher, M., and A. Rege, "Fountain Approach to Reliable Distribution of Bulk Data", Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.
[BYE1998]バイヤーズ、J.、ルビー、M.、Mitzenmacher、M.、およびA.レゲ、 "バルクデータの信頼性の高い配信に泉アプローチ"、議事ACM SIGCOMM'98、バンクーバー、カナダ、1998年9月。
[BYE2000] Byers, J., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., Rotter, 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.
【BYE2000]バイヤーズ、J.、Frumin、M.、ホーン、G.、ルビー、M.、Mitzenmacher、M.、ロッター、A.、およびW.シェーバー、 "FLID-DL：階層化マルチキャストのための輻輳制御"、ネットワークグループ通信に関する第2回国際ワークショップ（NGC 2000）、カリフォルニア州パロアルト、2000年11月の議事。
[GEM2000] Gemmell, J., Schooler, E., and J. Gray, "Fcast Multicast File Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.
【GEM2000] Gemmell、J.、学生はE.、およびJ.グレイ、 "Fcastマルチキャストファイル配信"、IEEEネットワーク、巻。 14、第1号、頁58-68、2000年1月。
[Perrig2001] Perrig, A., Canetti, R., Song, D., and J. Tyger, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[Perrig2001] Perrig、A.、カネッティ、R.、歌、D.、およびJ.タイガー、 "マルチキャストのための効率的で安全なソース認証"、ネットワークと分散システムセキュリティシンポジウム、NDSS 2001、頁35-46、2月2001。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装"、RFC 1305、1992年3月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357]マンキン、A.、ロマノフ、A.、RFC 2357、1998年6月ブラドナーの、S.、およびV.パクソン、 "信頼性の高いマルチキャストトランスポートとアプリケーションプロトコルを評価するためのIETF基準"。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]ハンドリー、M.、パーキンス、C.、およびE.ウィーラン、 "セッションアナウンスメントプロトコル"、RFC 2974、2000年10月。
[RFC3048] 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.
[RFC3048] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.、およびM.ルビー、 "信頼できるマルチキャストトランスポート・ビルディング・ブロック一対多バルクデータ転送のための" 、RFC 3048、2001年1月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269] Kermode、R.とL. Vicisano、RFC 3269、2002年4月 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書の作者のガイドライン"。
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[RFC3451]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "階層化符号化トランスポート（LCT）ビルディングブロック"、RFC 3451、2002年12月。
[RFC3453] 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.
[RFC3453]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（FEC）の使用"、RFC 3453 、2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738]ルビー、M.およびV. Goyal氏、 "波動と式ベースのレート制御（WEBRC）ビルディングブロック"、RFC 3738、2004年4月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。
[RIZ1997a] Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, April 1997.
[RIZ1997a] Rizzo氏、L.、 "信頼性の高いコンピュータ通信プロトコルのための効果的な消去符号"、ACM SIGCOMMコンピュータコミュニケーションレビュー、Vol.27、第2号、pp.24-36、1997年4月。
[RIZ1997b] Rizzo, L. and L. Vicisano, "Reliable Multicast Data Distribution protocol based on software FEC techniques", Proceedings of the Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communication Systems, HPCS'97, Chalkidiki Greece, June 1997.
[RIZ1997b] Rizzo氏、L.およびL. Vicisano、「ソフトウェアFEC技術に基づいた信頼性の高いマルチキャストデータ配信プロトコル」、高性能通信システム、HPCS'97、ハルキディキギリシャ、6月のアーキテクチャと実装第4回IEEEワークショップの議事録1997。
[RIZ2000] Rizzo, L., "PGMCC: A TCP-friendly single-rate multicast congestion control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August 2000.
[RIZ2000] Rizzo氏、L.、 "PGMCC：TCPフレンドリーなシングルレートのマルチキャスト輻輳制御方式"、SIGCOMM 2000の議事録、スウェーデンストックホルム、2000年8月。
[VIC1998] Vicisano, L., Rizzo, L., and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", IEEE Infocom'98, San Francisco, CA, March 1998.
[VIC1998] Vicisano、L.、リゾー、L.、およびJ.クロウクロフト、 "階層化マルチキャストデータ転送のためのTCPのような輻輳制御"、IEEE Infocom'98、サンフランシスコ、CA、1998年3月。
Authors' Addresses
著者のアドレス
Michael Luby Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
マイケル・ルビークアルコム社3165なぜRdを。サンタクララ、カリフォルニア州95051米国
EMail: luby@qualcomm.com
メールアドレス：luby@qualcomm.com
Mark Watson Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
マーク・ワトソンクアルコム社3165なぜRdを。サンタクララ、カリフォルニア州95051米国
EMail: watson@qualcomm.com
メールアドレス：watson@qualcomm.com
Lorenzo Vicisano Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
ロレンツォVicisanoクアルコム社3165なぜRdを。サンタクララ、カリフォルニア州95051米国
EMail: vicisano@qualcomm.com
メールアドレス：vicisano@qualcomm.com