Network Working Group M. Luby
Request for Comments: 3451 Digital Fountain
Category: Experimental J. Gemmell
Microsoft
L. Vicisano
Cisco
L. Rizzo
Univ. Pisa
M. Handley
ICIR
J. Crowcroft
Cambridge Univ.
December 2002
Layered Coding Transport (LCT) Building Block
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.
階層化符号化トランスポート（LCT）信頼性の高いコンテンツ配信とストリーム配信プロトコルのトランスポートレベルのサポートを提供します。 LCTは、具体的にはIPマルチキャストを使用してプロトコルをサポートするように設計されただけでなく、ユニキャストを使用するプロトコルへのサポートを提供しています。 LCTは、受信機に複数のレート配信を提供し、また、コンテンツの信頼できる配信を提供する符号化技術と互換性のある輻輳制御と互換性があります。
Table of Contents
目次
1. Introduction...................................................2
2. Rationale......................................................3
3. Functionality..................................................4
4. Applicability..................................................7
4.1 Environmental Requirements and Considerations...............8
4.2 Delivery service models....................................10
4.3 Congestion Control.........................................11
5. Packet Header Fields..........................................12
5.1 Default LCT header format..................................12
5.2 Header-Extension Fields....................................17
6. Operations....................................................20
6.1 Sender Operation...........................................20
6.2 Receiver Operation.........................................22
7. Requirements from Other Building Blocks.......................23
8. Security Considerations.......................................24
9. IANA Considerations...........................................25
10. Acknowledgments..............................................25
11. References...................................................25
Authors' Addresses...............................................28
Full Copyright Statement.........................................29
Layered Coding Transport provides transport level support for reliable content delivery and stream delivery protocols. Layered Coding Transport is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. Layered Coding Transport is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.
階層符号化トランスポート・信頼性の高いコンテンツ配信とストリーム配信プロトコルのためのトランスポート・レベルのサポートを提供します。階層符号化交通は、特にIPマルチキャストを使用してプロトコルをサポートするように設計するだけでなく、ユニキャストを使用するプロトコルへのサポートを提供しています。階層符号化トランスポートは、受信機に複数のレート配信を提供し、また、コンテンツの信頼できる配信を提供する符号化技術と互換性のある輻輳制御と互換性があります。
This document describes a building block as defined in RFC 3048 [26]. This document is a product of the IETF RMT WG and follows the general guidelines provided in RFC 3269 [24].
RFC 3048 [26]で定義されるように、この文書は、ビルディングブロックが記載されています。この文書は、IETF RMT WGの製品であり、RFC 3269 [24]内に設けられた一般的なガイドラインに従います。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
このメモは、完全にRFC 2357を1としてRFC 2357.に従い、信頼性の高いマルチキャストトランスポートプロトコルを指定するために必要な定義の一部が含まれている、インターネットのいずれかの信頼できるマルチキャストプロトコルの使用は、適切な輻輳制御方式が必要です。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
このようなスキームを待っているが利用できるようにする、または既存のスキームのための十分な証明することが、信頼性の高いマルチキャスト交通ワーキンググループ（RMT）は「実験」カテゴリ内のコメントのためにこの要求を発行しています。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
すぐに上記の条件が満たされたとしてIETFのProposed Standardとして、この明細書を再提出するRMTの意図です。
LCT provides transport level support for massively scalable protocols using the IP multicast network service. The support that LCT provides is common to a variety of very important applications, including reliable content delivery and streaming applications.
LCTは、IPマルチキャストネットワークサービスを使用して大規模なスケーラブルなプロトコル用のトランスポート・レベルのサポートを提供します。 LCTが提供するサポートは、信頼性の高いコンテンツ配信とストリーミングアプリケーションなど、非常に重要なアプリケーションの様々な一般的です。
An LCT session comprises multiple channels originating at a single sender that are used for some period of time to carry packets pertaining to the transmission of one or more objects that can be of interest to receivers. The logic behind defining a session as originating from a single sender is that this is the right granularity to regulate packet traffic via congestion control. One rationale for using multiple channels within the same session is that there are massively scalable congestion control protocols that use multiple channels per session. These congestion control protocols are considered to be layered because a receiver joins and leaves channels in a layered order during its participation in the session. The use of layered channels is also useful for streaming applications.
LCTセッションは、受信機に関心のあることができる1つまたは複数のオブジェクトの伝送に関係するパケットを運ぶためにある期間に使用される単一の送信者から発信複数のチャネルを含みます。単一の送信者から発信されたものとしてセッションを定義するの背後にある論理は、これは輻輳制御を介してパケットトラフィックを規制する適切な粒度であることです。同じセッション内で複数のチャネルを使用するための一つの根拠は、セッションごとに複数のチャネルを使用する大規模なスケーラブルな輻輳制御プロトコルがあるということです。これらの輻輳制御プロトコルは、受信機がセッションへの参加中に積層順に結合し、チャネルを残すため層状であると考えられます。階層チャネルの使用はまた、ストリーミングアプリケーションのために有用です。
There are coding techniques that provide massively scalable reliability and asynchronous delivery which are compatible with both layered congestion control and with LCT. When all are combined the result is a massively scalable reliable asynchronous content delivery protocol that is network friendly. LCT also provides functionality that can be used for other applications as well, e.g., layered streaming applications.
層状輻輳制御の両方を有するとLCTと互換性のある大規模なスケーラブルな信頼性および非同期送達を提供する符号化技術があります。全てを組み合わせた場合の結果は、ネットワークにやさしい大規模スケーラブルな信頼性の高い非同期のコンテンツ配信プロトコルです。 LCTはまた、同様に他の用途に使用することができる官能基、例えば、層状ストリーミング・アプリケーションを提供します。
LCT avoids providing functionality that is not massively scalable. For example, LCT does not provide any mechanisms for sending information from receivers to senders, although this does not rule out protocols that both use LCT and do require sending information from receivers to senders.
LCTは、大規模な拡張性のない機能を提供する避けることができます。これは使用LCT両方のプロトコルを除外せず、送信者に受信機からの情報を送信する必要はないが、例えば、LCTは、送信者に受信機からの情報を送信するための任意のメカニズムを提供しません。
LCT includes general support for congestion control that must be used. It does not, however, specify which congestion control should be used. The rationale for this is that congestion control must be provided by any protocol that is network friendly, and yet the different applications that can use LCT will not have the same requirements for congestion control. For example, a content delivery protocol may strive to use all available bandwidth between receivers and the sender. It must, therefore, drastically back off its rate when there is competing traffic. On the other hand, a streaming delivery protocol may strive to maintain a constant rate instead of trying to use all available bandwidth, and it may not back off its rate as fast when there is competing traffic.
LCTを使用する必要があり輻輳制御のための一般的なサポートが含まれています。それは、しかし、使用されるべき輻輳制御指定されていません。この理論的根拠は、輻輳制御はネットワーク優しい任意のプロトコルによって提供されなければならない、とLCTを使用することができ、まだ別のアプリケーションが輻輳制御のための同じ要件を持っていないということです。例えば、コンテンツ配信プロトコルは、受信機と送信者との間のすべての利用可能な帯域幅を使用するように努力してもよいです。競合するトラフィックがあるときには、そのため、大幅にそのレートをバックオフしなければなりません。一方、ストリーミング配信プロトコルではなく、すべての利用可能な帯域幅を使用しようとしているの一定速度を維持するために努力すること、そしてそれが早く、競合するトラフィックがある場合にはそのレートをバックオフしない場合があります。
Beyond support for congestion control, LCT provides a number of fields and supports functionality commonly required by many protocols. For example, LCT provides a Transmission Session ID that can be used to identify which session each received packet belongs to. This is important because a receiver may be joined to many sessions concurrently, and thus it is very useful to be able to demultiplex packets as they arrive according to which session they belong to. As another example, LCT provides optional support for identifying which object each packet is carrying information about. Therefore, LCT provides many of the commonly used fields and support for functionality required by many protocols.
輻輳制御のためのサポートを越えて、LCTは、フィールドの数を提供し、一般的に多くのプロトコルに必要な機能をサポートしています。例えば、LCTは、各受信したパケットが属するセッションを識別するために使用することができる伝送セッションIDを提供します。受信機は、同時に多数のセッションに参加することができるので、これは重要であり、したがって、彼らが属するセッションに係る到着するパケットを逆多重化することができるように非常に有用です。別の例として、LCTは、各パケットについての情報を運んでどのオブジェクト識別するための任意のサポートを提供します。したがって、LCTは、一般的に使用されるフィールドと多くのプロトコルで必要とされる機能のサポートの多くを提供します。
An LCT session consists of a set of logically grouped LCT channels associated with a single sender carrying packets with LCT headers for one or more objects. An LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop receiving data packets from the channel.
LCTセッションは、1つまたは複数のオブジェクトのためのLCTヘッダを持つパケットを搬送する単一の送信者に関連した論理的にグループ化LCTチャネルのセットからなります。 LCTチャネルは、送信者の組合せと送信者がチャネルに関連付けられたアドレスによって定義されます。受信機は、送信者によってチャネルに送信されたデータ・パケットの受信を開始するためにチャンネルに参加し、受信機は、チャネルからのデータパケットの受信を停止するチャネルを残します。
LCT is meant to be combined with other building blocks so that the resulting overall protocol is massively scalable. Scalability refers to the behavior of the protocol in relation to the number of receivers and network paths, their heterogeneity, and the ability to accommodate dynamically variable sets of receivers. Scalability limitations can come from memory or processing requirements, or from the amount of feedback control and redundant data packet traffic generated by the protocol. In turn, such limitations may be a consequence of the features that a complete reliable content delivery or stream delivery protocol is expected to provide.
LCTは、得られる全体的なプロトコルは、大規模に拡張可能であるように、他のビルディングブロックと結合することを意味します。スケーラビリティは、受信機及びネットワークパスの数、それらの不均一性、及び受信機の動的変数のセットに対応する能力に関連してプロトコルの動作を指します。スケーラビリティの制限は、メモリや処理要求から、又はフィードバック制御とプロトコルによって生成された冗長データパケットのトラフィック量から来ることができます。ターンでは、このような制限は、完全な信頼性の高いコンテンツ配信やストリーム配信プロトコルを提供することが期待される機能の結果です。
The LCT header provides a number of fields that are useful for conveying in-band session information to receivers. One of the required fields is the Transmission Session ID (TSI), which allows the receiver of a session to uniquely identify received packets as part of the session. Another required field is the Congestion Control Information (CCI), which allows the receiver to perform the required congestion control on the packets received within the session. Other LCT fields provide optional but often very useful additional information for the session. For example, the Transport Object Identifier (TOI) identifies which object the packet contains data for. As other examples, the Sender Current Time (SCT) conveys the time when the packet was sent from the sender to the receiver, the Expected Residual Time (ERT) conveys the amount of time the session will be continued for, flags for indicating the close of the session and the close of sending packets for an object, and header extensions for fields that for example can be used for packet authentication.
LCTヘッダが受信機に帯域内のセッション情報を伝達するのに有用であるフィールドの数を提供します。必須フィールドの一つは、セッションの受信側が一意のセッションの一部として受信したパケットを識別することを可能にする送信セッションのID（TSI）、です。別の必須フィールドは、受信機がセッション内で受信したパケットに必要な輻輳制御を行うことを可能にする輻輳制御情報（CCI）です。その他LCTフィールドは、セッションのためのオプションですが、多くの場合、非常に有用な追加情報を提供します。例えば、トランスポート・オブジェクト識別子（TOI）がパケットのためのデータを含むオブジェクトかを識別する。他の例として、送信者の現在時刻（SCT）は、パケットが受信機に送信者から送信された時間を伝える、予想残余時間（ERT）は、セッションが継続される時間の量を伝える、閉じるを示すフラグセッションオブジェクトのためのパケットを送信するの近く、例えば、パケットの認証に使用することができるフィールドのヘッダ拡張の。
LCT provides support for congestion control. Congestion control MUST be used that conforms to RFC 2357 [13] between receivers and the sender for each LCT session. Congestion control refers to the ability to adapt throughput to the available bandwidth on the path from the sender to a receiver, and to share bandwidth fairly with competing flows such as TCP. Thus, the total flow of packets flowing to each receiver participating in an LCT session MUST NOT compete unfairly with existing flow adaptive protocols such as TCP.
LCTは、輻輳制御のためのサポートを提供します。輻輳制御は、受信機と各LCTセッションの送信者との間のRFC 2357 [13]に準拠していることに使用されなければなりません。輻輳制御は、送信側から受信側への経路上の利用可能な帯域幅にスループットを適応させる、及びTCPのような競合フローにかなりの帯域幅を共有する能力を指します。このように、LCTセッションに参加している各受信機に流れるパケットの総流量は、TCPのような既存のフローの適応プロトコルと不当競争してはなりません。
A multiple rate or a single rate congestion control protocol can be used with LCT. For multiple rate protocols, a session typically consists of more than one channel and the sender sends packets to the channels in the session at rates that do not depend on the receivers. Each receiver adjusts its reception rate during its participation in the session by joining and leaving channels dynamically depending on the available bandwidth to the sender independent of all other receivers. Thus, for multiple rate protocols, the reception rate of each receiver may vary dynamically independent of the other receivers.
複数レートまたは単一レート輻輳制御プロトコルは、LCTと一緒に使用することができます。複数のレートプロトコルでは、セッションは通常、複数のチャネルで構成され、送信者が受信機に依存しないレートでセッション中のチャンネルにパケットを送信します。各受信機は、接合し、他のすべての受信機の送信元独立に利用可能な帯域幅に応じて動的にチャネルを残すことによって、セッションへの参加中にその受信レートを調整します。このように、複数のレートプロトコルに対して、各受信機の受信レートは、他の受信機の動的独立して変化してもよいです。
For single rate protocols, a session typically consists of one channel and the sender sends packets to the channel at variable rates over time depending on feedback from receivers. Each receiver remains joined to the channel during its participation in the session. Thus, for single rate protocols, the reception rate of each receiver may vary dynamically but in coordination with all receivers.
シングルレートプロトコルでは、セッションは通常、1つのチャンネルで構成され、送信者が受信機からのフィードバックに応じて、時間の経過とともに変動金利でチャンネルにパケットを送信します。各受信機は、セッションへの参加中にチャネルに結合されたままです。したがって、単一のレートプロトコルに対して、各受信機の受信レートを動的に変化させるが、すべての受信機と連携してもよいです。
Generally, a multiple rate protocol is preferable to a single rate protocol in a heterogeneous receiver environment, since generally it more easily achieves scalability to many receivers and provides higher throughput to each individual receiver. Some possible multiple rate congestion control protocols are described in [22], [3], and [25]. A possible single rate congestion control protocol is described in [19].
一般的にはより容易に多くの受信機へのスケーラビリティを実現し、各個々の受信機へのより高いスループットを提供するので、一般的に、複数の速度プロトコルは、異種の受信環境における単一レートプロトコルに好ましいです。いくつかの可能な複数のレート輻輳制御プロトコルは[22]に記載されている、[3]、及び[25]。可能なシングルレート輻輳制御プロトコルは[19]に記載されています。
Layered coding refers to the ability to produce a coded stream of packets that can be partitioned into an ordered set of layers. The coding is meant to provide some form of reliability, and the layering is meant to allow the receiver experience (in terms of quality of playout, or overall transfer speed) to vary in a predictable way depending on how many consecutive layers of packets the receiver is receiving.
階層符号化は、層の順序集合に分割することができるパケットの符号化ストリームを生成する能力を指します。符号化は、信頼性のいくつかのフォームを提供するように意図され、そして積層は、パケット受信機のどのように多くの連続する層に応じて予測可能な方法で変化する（再生の品質、または全体的な転送速度の点で）受信機の経験を可能にすることを意味します受信しています。
The concept of layered coding was first introduced with reference to audio and video streams. For example, the information associated with a TV broadcast could be partitioned into three layers, corresponding to black and white, color, and HDTV quality. Receivers can experience different quality without the need for the sender to replicate information in the different layers.
コーディング階層の概念は、最初のオーディオおよびビデオストリームを参照して導入されました。例えば、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 [20], [18], [7], [22] and [4]. By using FEC, the data stream is transformed in such a way that reconstruction of a data object does not depend on the reception of specific data packets, but only on the number of different packets received. As a result, by increasing the number of layers a receiver is receiving from, the receiver can reduce the transfer time accordingly. Using FEC to provide reliability can increase scalability dramatically in comparison to other methods for providing reliability. More details on the use of FEC for reliable content delivery can be found in [11].
前方誤り訂正（FEC）技術は、データストリームを符号化するために使用される場合階層符号化の概念は、自然に信頼性の高いコンテンツ配信プロトコルに拡張することができます。この説明は[20]、[18]に見ることができる、[7]、[22]及び[4]。 FECを使用して、データストリームは、データオブジェクトの再構成は、特定のデータパケットの受信に、のみ受信異なるパケットの数に依存しないように変換されます。結果として、受信機から受信された層の数を増やすことによって、受信機はそれに応じて転送時間を短縮することができます。信頼性を提供するための他の方法と比較して劇的にスケーラビリティを向上させることができ、信頼性を提供するために、FECを使用しました。信頼性の高いコンテンツ配信のためのFECの使用に関する詳細は[11]に見出すことができます。
Reliable protocols aim at giving guarantees on the reliable delivery of data from the sender to the intended recipients. Guarantees vary from simple packet data integrity to reliable delivery of a precise copy of an object to all intended recipients. Several reliable content delivery protocols have been built on top of IP multicast using methods other than FEC, but scalability was not the primary design goal for many of them.
信頼性の高いプロトコルは、意図した受信者に送信者からのデータの信頼できる配信に保証を与えることを目指しています。保証は、すべての目的の受信者へのオブジェクトの正確なコピーの信頼性の高い配信に単純なパケットデータの整合性によって異なります。いくつかの信頼性の高いコンテンツ配信プロトコルは、FEC以外の方法を使用してIPマルチキャストの上に構築されているが、拡張性は、それらの多くのための主要な設計目標ではありませんでした。
Two of the key difficulties in scaling reliable content delivery using IP multicast are dealing with the amount of data that flows from receivers back to the sender, and the associated response (generally data retransmissions) from the sender. Protocols that avoid any such feedback, and minimize the amount of retransmissions, can be massively scalable. LCT can be used in conjunction with FEC codes or a layered codec to achieve reliability with little or no feedback.
IPマルチキャストを使用した信頼性の高いコンテンツ配信をスケーリングにおける主要な困難の二つは、送信者に戻って受信機から流れたデータの量、および送信者からの関連する応答（一般的にデータの再送信）を扱っています。どのようなフィードバックを回避し、再送信の量を最小化するプロトコルは、大規模な拡張性の高いことができます。 LCTは、ほとんど又は全くフィードバックを信頼性を達成するためにFECコード又は層状コーデックと共に使用することができます。
Protocol instantiations MAY be built by combining the LCT framework with other components. A complete protocol instantiation that uses LCT MUST include a congestion control protocol that is compatible with LCT and that conforms to RFC 2357 [13]. A complete protocol instantiation that uses LCT MAY include a scalable reliability protocol that is compatible with LCT, it MAY include an session control protocol that is compatible with LCT, and it MAY include other protocols such as security protocols.
プロトコルインスタンスは、他のコンポーネントとLCTのフレームワークを組み合わせることによって構築することができます。 LCTを使用する完全なプロトコルのインスタンスは、LCTと互換性があり、それは、RFC 2357 [13]に準拠し、輻輳制御プロトコルを含まなければなりません。 LCTを使用する完全なプロトコルのインスタンスは、LCTと互換性のあるセッション制御プロトコルを含むことができ、そのようなセキュリティ・プロトコルなどの他のプロトコルを含んでいてもよく、LCTと互換性のあるスケーラブルな信頼性プロトコルを含むかもしれません。
An LCT session comprises a logically related set of one or more LCT channels originating at a single sender. The channels are used for some period of time to carry packets containing LCT headers, and these headers pertain to the transmission of one or more objects that can be of interest to receivers.
LCTセッションは、単一の送信者を起点と一つ以上の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 MUST include the relevant session parameters needed by a receiver to participate in the session, including all information relevant to congestion control. The session description is determined by the sender, and is typically communicated to the receivers out-of-band. In some cases, as described later, parts of the session description that are not required to initiate a session MAY be included in the LCT header or communicated to a receiver out-of-band after the receiver has joined the session.
セッションに参加する前に、受信機は、セッションを開始するセッション記述を十分に取得する必要があります。これは、輻輳制御に関連するすべての情報を含むセッションに参加するために受信機が必要とする関連セッションパラメータを含まなければなりません。セッション記述は、送信者によって決定され、典型的にはアウトオブバンド受信機に伝達されます。受信機はセッションに参加した後に後述するように、いくつかのケースでは、セッションを開始するために必要とされていないセッション記述の部分は、LCTヘッダに含まれてもよく、またはアウトオブバンド受信機に伝達します。
An encoder MAY be used to generate the data that is placed in the packet payload in order to provide reliability. A suitable decoder is used to reproduce the original information from the packet payload. There MAY be a reliability header that follows the LCT header if such an encoder and decoder is used. The reliability header helps to describe the encoding data carried in the payload of the packet. The format of the reliability header depends on the coding used, and this is negotiated out-of-band. As an example, one of the FEC headers described in [12] could be used.
エンコーダは、信頼性を提供するために、パケットペイロード内に配置されたデータを生成するために使用され得ます。適切なデコーダがパケットペイロードから元の情報を再生するために使用されます。そのようなエンコーダおよびデコーダを使用する場合LCTヘッダに続く信頼ヘッダが存在してもよいです。信頼ヘッダは、パケットのペイロードで運ばれた符号化データを記述するのに役立ちます。信頼ヘッダのフォーマットは、使用される符号化に依存し、これは、アウトオブバンド交渉されます。一例として、[12]に記載のFECヘッダーの1つを使用することができます。
For LCT, when multiple rate congestion control is used, congestion control is achieved by sending packets associated with a given session to several LCT channels. Individual receivers dynamically join one or more of these channels, according to the network congestion as seen by the receiver. LCT headers include an opaque field which MUST be used to convey congestion control information to the receivers. The actual congestion control scheme to use with LCT is negotiated out-of-band. Some examples of congestion control protocols that may be suitable for content delivery are described in [22], [3], and [25]. Other congestion controls may be suitable when LCT is used for a streaming application.
LCTのために、複数のレート輻輳制御を使用した場合、輻輳制御は、いくつかのLCTチャネルに特定のセッションに関連付けられたパケットを送信することによって達成されます。個々の受信機は、動的に受信機によって見られるように、ネットワークの輻輳に応じて、これらのチャネルの一つ以上に参加します。 LCTヘッダは、受信機に輻輳制御情報を伝達するために使用しなければならない不透明なフィールドを含みます。 LCTで使用する実際の輻輳制御方式は、帯域外交渉されます。いくつかのコンテンツ配信に適し得る輻輳制御プロトコルの例に記載されている[22]、[3]、及び[25]。 LCTは、ストリーミングアプリケーションのために使用される場合、他の輻輳制御は、適切であり得ます。
This document does not specify and restrict the type of exchanges between LCT (or any PI built on top of LCT) and an upper application. Some upper APIs may use an object-oriented approach, where the only possible unit of data exchanged between LCT (or any PI built on top of LCT) and an application, either at a source or at a receiver, is an object. Other APIs may enable a sending or receiving application to exchange a subset of an object with LCT (or any PI built on top of LCT), or may even follow a streaming model. These considerations are outside the scope of this document.
この文書では、LCT（またはLCTの上に構築された任意PI）と上位アプリケーションとの間の交換のタイプを指定し、制限するものではありません。いくつかの上位APIは、データの唯一の可能な手段は、ソースで、または受信機のいずれかで、LCT（またはLCTの上に構築された任意PI）とアプリケーションとの間で交換さオブジェクト指向のアプローチを使用することが、目的です。他のAPIはLCT（またはLCTの上に構築された任意PI）を持つオブジェクトのサブセットを交換する送受信アプリケーションを可能にすることができる、あるいはストリーミングモデルに従うことができます。これらの考慮事項は、この文書の範囲外です。
LCT is intended for congestion controlled delivery of objects and streams (both reliable content delivery and streaming of multimedia information).
LCTは、オブジェクトおよびストリーム（信頼性の高いコンテンツ配信及びマルチメディア情報のストリーミングの両方）の輻輳制御された送達のために意図されています。
LCT can be used with both multicast and unicast delivery. LCT requires connectivity between a sender and receivers but does not require connectivity from receivers to a sender. LCT inherently works with all types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. Thus, the inherent raw scalability of LCT is unlimited. However, when other specific applications are built on top of LCT, then these applications by their very nature may limit scalability. For example, if an application requires receivers to retrieve out of band information in order to join a session, or an application allows receivers to send requests back to the sender to report reception statistics, then the scalability of the application is limited by the ability to send, receive, and process this additional data.
LCTは、マルチキャストおよびユニキャスト配信の両方で使用することができます。 LCTは、送信者と受信者間の接続が必要ですが、受信機から送信側への接続を必要としません。 LCTは、本質的にLANやWANを、イントラネット、インターネット、非対称ネットワーク、無線ネットワーク、衛星ネットワークを含むネットワークのすべてのタイプで動作します。このように、LCTの固有の生のスケーラビリティは無制限です。他の特定のアプリケーションは、LCTの上に構築されている場合しかし、その後、その性質により、これらのアプリケーションは、スケーラビリティを制限することがあります。アプリケーションは、受信機を必要とする場合たとえば、セッションに参加するために、帯域情報のうち、取得、またはアプリケーションが受信機は、受信統計情報を報告するために送信者に戻って要求を送信することを可能にするために、アプリケーションのスケーラビリティをする能力によって制限されます送信、受信、およびこの追加データを処理します。
LCT requires receivers to be able to uniquely identify and demultiplex packets associated with an LCT session. In particular, there MUST be a Transport Session Identifier (TSI) associated with each LCT session. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI MUST uniquely identify the session. If the underlying transport is UDP as described in RFC 768 [16], then the 16 bit UDP source port number MAY serve as the TSI for the session. The TSI value MUST be the same in all places it occurs within a packet. If there is no underlying TSI provided by the network, transport or any other layer, then the TSI MUST be included in the LCT header.
LCTを一意に識別し、LCTセッションに関連付けられたパケットを逆多重化することができるように受信機を必要とします。具体的には、各LCTセッションに関連付けられたトランスポートセッション識別子（TSI）が存在していなければなりません。 TSIは、送信者のIPアドレスによってスコープされ、そしてTSIと共に、送信者のIPアドレスは、セッションを一意に識別しなければなりません。 RFC 768 [16]に記載されているように、基礎となるトランスポートがUDPである場合、16ビットUDP送信元ポート番号は、セッションのTSIとして働くことができます。 TSI値は、パケット内に発生したすべての場所で同じでなければなりません。ネットワーク、トランスポート、または任意の他の層によって提供されない基礎となるTSIが存在しない場合には、TSIは、LCTヘッダに含まれなければなりません。
LCT is presumed to be used with an underlying network or transport service that is a "best effort" service that does not guarantee packet reception or packet reception order, and which does not have any support for flow or congestion control. For example, the Any-Source Multicast (ASM) model of IP multicast as defined in RFC 1112 [5] is such a "best effort" network service. While the basic service provided by RFC 1112 is largely scalable, providing congestion control or reliability should be done carefully to avoid severe scalability limitations, especially in presence of heterogeneous sets of receivers.
LCTは、パケットの受信やパケットの受信順序を保証するものではありません「ベストエフォート」のサービスである基礎となるネットワークまたはトランスポートサービスで使用していると推定され、これは、フローや輻輳制御のためのあらゆるサポートしていません。 RFC 1112で定義されたIPマルチキャストの、例えば、任意-ソースマルチキャスト（ASM）モデル[5]そのような「ベストエフォート」ネットワークサービスです。 RFC 1112が提供する基本的なサービスは、主にスケーラブルですが、輻輳制御や信頼性を提供することは、特に受信機の異質セットの存在下で、深刻なスケーラビリティの制限を回避するために、慎重に行われるべきです。
There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in RFC 1112 [5] and the Source-Specific Multicast (SSM) model as defined in [10]. LCT works with both multicast models, but in a slightly different way with somewhat different environmental concerns. When using ASM, a sender S sends packets to a multicast group G, and the LCT channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and the LCT channel address coincides with the SSM channel address.
マルチキャスト配信の2つのモデルが現在あり、RFC 1112で定義されるような任意の-ソースマルチキャスト（ASM）モデル[5]及び[10]で定義されるようにソース固有マルチキャスト（SSM）モデル。 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 attacks. In either case, receivers SHOULD use mechanisms to filter out packets from unwanted sources.
LCTチャネルとSSMチャネルが一致するので、受信機は、要求されたLCTチャネルに送信されたパケットを受信します。受信機はマルチキャストグループGを接合してLCTチャネルを結合し、Gに送信されるすべてのパケットASMと、にかかわらず、送信者、受信機によって受信されてもよいです。このように、SSMは、サービス拒否攻撃の防止のためのASM以上の魅力的なセキュリティ上の利点があります。いずれの場合においても、受信機は、不要なソースからパケットをフィルタリングするためのメカニズムを使用すべきです。
Some networks are not amenable to some congestion control protocols that could be used with LCT. In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session.
ネットワークによっては、LCTで使用することができ、いくつかの輻輳制御プロトコルに従順ではありません。具体的には、衛星または無線ネットワークのために、セッションに割り当てられた一定の伝送速度が存在し得るので、効果的に受信レートを低減するための受信機のためのメカニズムが存在しない場合があります。
LCT can support several different delivery service models. Two examples are briefly described here.
LCTは、いくつかの異なる配信サービスモデルをサポートすることができます。 2つの例をここで簡単に説明されています。
Push service model.
サービスモデルを押してください。
One way a push service model can be used for reliable content delivery is to deliver a series of objects. For example, a receiver could join the session and dynamically adapt the number of LCT channels the receiver is joined to until enough packets have been received to reconstruct an object. After reconstructing the object the receiver may stay in the session and wait for the transmission of the next object.
プッシュサービスモデルは、信頼性の高いコンテンツ配信のために使用することができる一つの方法は、一連のオブジェクトを提供することです。例えば、受信機はセッションに参加し、動的受信機が十分なパケットがオブジェクトを再構築するために受信されるまでに接合され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チャネルから構成されてもよいです。
On-demand content delivery model.
オンデマンドコンテンツ配信モデル。
For an on-demand content delivery service model, senders typically transmit for some given time period selected to be long enough to allow all the intended receivers to join the session and recover the object. For example a popular software update might be transmitted using LCT for several days, even though a receiver may be able to complete the download in one hour total of connection time, perhaps spread over several intervals of time.
オンデマンドのコンテンツ配信サービスモデルの場合、送信者は、一般的に、すべての意図した受信機がセッションに参加してオブジェクトを回復できるように十分な長さに選択いくつかの特定の期間のために送信します。例えば、人気のあるソフトウェアの更新は受信機が接続時間の1時間の合計でダウンロードを完了することができたとしても、数日間LCTを使用して送信されるかもしれない、おそらく時間のいくつかの間隔に広がります。
In this case the receivers join the session, and dynamically adapt the number of LCT channels they subscribe to according to the available bandwidth. Receivers then drop from the session when they have received enough packets to recover the object.
この場合、受信機は、セッションに参加し、動的にそれらが利用可能な帯域幅に応じてに加入LCTチャネル数を適応させます。彼らはオブジェクトを回復するのに十分なパケットを受信したときの受信機は、その後、セッションからドロップします。
As an example, assume that an object is 50 MB. The sender could send 1 KB packets to the first LCT channel at 50 packets per second, so that receivers using just this LCT channel could complete reception of the object in 1,000 seconds in absence of loss, and would be able to complete reception even in presence of some substantial amount of losses with the use of coding for reliability. Furthermore, the sender could use a number of LCT channels such that the aggregate rate of 1 KB packets to all LCT channels is 1,000 packets per second, so that a receiver could be able to complete reception of the object in as little 50 seconds (assuming no loss and that the congestion control mechanism immediately converges to the use of all LCT channels).
一例として、オブジェクトが50メガバイトであると仮定する。送信者は、ちょうどこのLCTチャネルを使用して受信機は損失の不在1,000秒でオブジェクトの受信を完了することができるように、毎秒50のパケットで最初LCTチャネルに1キロバイトのパケットを送信することができ、さらには存在の受信を完了することができるであろう信頼性のためのコーディングを使用した損失の一部、かなりの量の。さらに、送信者は、受信機は、わずか50秒でオブジェクトの受信を完了することができることができるように、すべてのLCTチャネルに1キロバイトのパケットの集約レートは、秒1,000パケットであるように（仮定をLCTチャネルの数を使用することができ輻輳制御機構は直ちに全てLCTチャネルの使用に収束することを損失しないと）。
Other service models.
その他のサービスモデル。
There are many other delivery service models that LCT can be used for that are not covered above. As examples, a live streaming or an on-demand archival content streaming service model. A description of the many potential applications, the appropriate delivery service model, and the additional mechanisms to support such functionalities when combined with LCT is beyond the scope of this document. This document only attempts to describe the minimal common scalable elements to these diverse applications using LCT as the delivery transport.
LCTは、上記カバーされていないことのために使用することができ、他の多くの配信サービスモデルがあります。例、ライブストリーミングやオンデマンドアーカイブコンテンツのストリーミングサービスモデルとして。 LCTと組み合わせた場合、このような機能をサポートするための多くの潜在的なアプリケーション、適切なデリバリサービスモデル、及び追加の機構の説明はこの文書の範囲外です。この文書は、デリバリー・トランスポートとしてLCTを使用して、これらの多様なアプリケーションに最小の共通のスケーラブルな要素を記述することを試みます。
The specific congestion control protocol to be used for LCT sessions depends on the type of content to be delivered. While the general behavior of the congestion control protocol is to reduce the throughput in presence of congestion and gradually increase it in the absence of congestion, the actual dynamic behavior (e.g. response to single losses) can vary.
LCTセッションに使用される特定の輻輳制御プロトコルは、配信されるコンテンツのタイプに依存します。輻輳制御プロトコルの一般的な挙動は、輻輳の存在下でのスループットを低下させ、徐々に輻輳の不在下でそれを増加させることであるが、実際の動的挙動（単一の損失に例えば応答）を変化させることができます。
Some possible congestion control protocols for reliable content delivery using LCT are described in [22], [3], and [25]. Different delivery service models might require different congestion control protocols.
LCTを用いた信頼性の高いコンテンツ配信のためのいくつかの可能な輻輳制御プロトコルは、に記載されている[22]、[3]、及び[25]。異なる配信サービスモデルは、異なる輻輳制御プロトコルが必要になることがあります。
Packets sent to an LCT session MUST include an "LCT header". The LCT header format described below is the default format, and this is the format that is recommended for use by protocol instantiations to ensure a uniform format across different protocol instantiations. Other LCT header formats MAY be used by protocol instantiations, but if the default LCT header format is not used by a protocol instantiation that uses LCT, then the protocol instantiation MUST specify the lengths and positions within the LCT header it uses of all fields described in the default LCT header.
LCTセッションに送信されたパケットは「LCTヘッダ」を含まなければなりません。以下に説明するLCTヘッダフォーマットは、デフォルトのフォーマットであり、これは、異なるプロトコルのインスタンスにわたって均一形式を確保するためのプロトコルのインスタンス化で使用するために推奨される形式です。他のLCTヘッダフォーマットは、プロトコルのインスタンス化で使用することができるが、デフォルトのLCTヘッダフォーマットは、LCTを使用するプロトコルのインスタンスによって使用されていない場合、プロトコルインスタンスは、に記載されているすべてのフィールドの使用LCTヘッダ内の長さと位置を指定しなければなりませんデフォルトのLCTヘッダ。
Other building blocks MAY describe some of the same fields as described for the LCT header. It is RECOMMENDED that protocol instantiations using multiple building blocks include shared fields at most once in each packet. Thus, for example, if another building block is used with LCT that includes the optional Expected Residual Time field, then the Expected Residual Time field SHOULD be carried in each packet at most once.
LCTヘッダについて記載したように他のビルディングブロックは、同じフィールドのいくつかを記述することができます。複数のビルディング・ブロックを使用してプロトコルのインスタンス化は、最高1回、各パケット内の共有フィールドを含めることをお勧めします。別のビルディングブロックは任意予想残余時間フィールドを含むLCTで使用される場合したがって、例えば、次に予想残余時間フィールドは、最大で一度各パケットに実施すべきです。
The position of the LCT header within a packet MUST be specified by any protocol instantiation that uses LCT.
パケット内のLCTヘッダの位置は、LCTを使用する任意のプロトコルのインスタンスで指定されなければなりません。
The default LCT header is of variable size, which is specified by a length field in the third byte of the header. In the LCT header, all integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. Bits designated as "padding" or "reserved" (r) MUST by set to 0 by senders and ignored by receivers. Unless otherwise noted, numeric constants in this specification are in decimal (base 10).
デフォルトのLCTヘッダは、ヘッダの第3バイトの長さフィールドで指定された可変サイズのものです。 LCTヘッダに、すべての整数フィールドが最初つまり、最上位バイト（オクテット）、「ビッグエンディアン」または「ネットワーク順」形式で行われます。ビットは送信者によって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 | r |S| O |H|T|R|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*(C+1) bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32*O+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if T = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if R = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Default LCT header format
図1 - デフォルトLCTヘッダフォーマット
The function and length of each field in the default LCT header is the following. Fields marked as "1" mean that the corresponding bits MUST be set to "1" by the sender. Fields marked as "r" or "0" mean that the corresponding bits MUST be set to "0" by the sender.
デフォルトのLCTヘッダの各フィールドの機能と長さは以下の通りです。フィールドは、対応するビットは送信者が「1」に設定しなければならないことを意味する「1」としてマーク。フィールドは、「R」又は「0」は、対応するビットは送信者が「0」に設定しなければならないことを意味としてマーク。
LCT version number (V): 4 bits
LCTバージョン番号（V）：4ビット
Indicates the LCT version number. The LCT version number for
this specification is 1.
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.
Reserved (r): 2 bits
予約済み（R）：2ビット
Reserved for future use. A sender MUST set these bits to zero
and a receiver MUST ignore these bits.
Transport Session Identifier flag (S): 1 bit
移送セッション識別子フラグ（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.
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.
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.
Sender Current Time present flag (T): 1 bit
送信側現在時刻存在フラグ（T）：1ビット
T = 0 indicates that the Sender Current Time (SCT) field is not
present. T = 1 indicates that the SCT field is present. The
SCT is inserted by senders to indicate to receivers how long
the session has been in progress.
Expected Residual Time present flag (R): 1 bit
予想残余時間存在フラグ（R）：1ビット
R = 0 indicates that the Expected Residual Time (ERT) field is
not present. R = 1 indicates that the ERT field is present.
The ERT is inserted by senders to indicate to receivers how
much longer the session / object transmission will continue.
Senders MUST NOT set R = 1 when the ERT for the session is more than 2^32-1 time units (approximately 49 days), where time is measured in units of milliseconds.
セッションのERTは、時間をミリ秒単位で測定された以上2 ^ 32-1時間単位（約49日）である場合、送信者は、R = 1を設定してはいけません。
Close Session flag (A): 1 bit
クローズセッションフラグ（A）：1ビット
Normally, A is set to 0. The sender MAY set A to 1 when
termination of transmission of packets for the session is
imminent. A MAY be set to 1 in just the last packet
transmitted for the session, or A MAY be set to 1 in the last
few seconds of packets transmitted for the session. Once the
sender sets A to 1 in one packet, the sender SHOULD set A to 1
in all subsequent packets until termination of transmission of packets for the session. A received packet with A set to 1
indicates to a receiver that the sender will immediately stop
sending packets for the session. When a receiver receives a
packet with A set to 1 the receiver SHOULD assume that no more
packets will be sent to the session.
Close Object flag (B): 1 bit
クローズオブジェクトフラグ（B）：1ビット
Normally, B is set to 0. The sender MAY set B to 1 when
termination of transmission of packets for an object is
imminent. If the TOI field is in use and B is set to 1 then
termination of transmission for the object identified by the
TOI field is imminent. If the TOI field is not in use and B is
set to 1 then termination of transmission for the one object in
the session identified by out-of-band information is imminent.
B MAY be set to 1 in just the last packet transmitted for the
object, or B MAY be set to 1 in the last few seconds packets
transmitted for the object. Once the sender sets B to 1 in one
packet for a particular object, the sender SHOULD set B to 1 in
all subsequent packets for the object until termination of
transmission of packets for the object. A received packet with
B set to 1 indicates to a receiver that the sender will
immediately stop sending packets for the object. When a
receiver receives a packet with B set to 1 then it SHOULD
assume that no more packets will be sent for the object to the
session.
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.
Codepoint (CP): 8 bits
コードポイント（CP）：8ビット
An opaque identifier which is passed to the packet payload
decoder to convey information on the codec being used for the
packet payload. The mapping between the codepoint and the
actual codec is defined on a per session basis and communicated
out-of-band as part of the session description information.
The use of the CP field is similar to the Payload Type (PT)
field in RTP headers as described in RFC 1889 [21].
Congestion Control Information (CCI): 32, 64, 96 or 128 bits
輻輳制御情報（CCI）：32、64、96または128ビット
Used to carry congestion control information. For example, the
congestion control information could include layer numbers,
logical channel numbers, and sequence numbers. This field is
opaque for the purpose of this specification.
This field MUST be 32 bits if C=0. This field MUST be 64 bits if C=1. This field MUST be 96 bits if C=2. This field MUST be 128 bits if C=3.
C = 0の場合、このフィールドは32ビットでなければなりません。 C = 1の場合、このフィールドは64ビットでなければなりません。 C = 2の場合、このフィールドは96ビットでなければなりません。 C = 3であれば、このフィールドは、128ビットでなければなりません。
Transport Session Identifier (TSI): 0, 16, 32 or 48 bits
トランスポートセッション識別子（TSI）：0、16、32または48ビット
The TSI uniquely identifies a session among all sessions from a
particular sender. The TSI is scoped by the IP address of the
sender, and thus the IP address of the sender and the TSI
together uniquely identify the session. Although a TSI in
conjunction with the IP address of the sender always uniquely
identifies a session, whether or not the TSI is included in the
LCT header depends on what is used as the TSI value. If the
underlying transport is UDP, then the 16 bit UDP source port
number MAY serve as the TSI for the session. If the TSI value
appears multiple times in a packet then all occurrences MUST be
the same value. If there is no underlying TSI provided by the
network, transport or any other layer, then the TSI MUST be
included in the LCT header.
The TSI MUST be unique among all sessions served by the sender during the period when the session is active, and for a large period of time preceding and following when the session is active. A primary purpose of the TSI is to prevent receivers from inadvertently accepting packets from a sender that belong to sessions other than the sessions receivers are subscribed to. For example, suppose a session is deactivated and then another session is activated by a sender and the two sessions use an overlapping set of channels. A receiver that connects and remains connected to the first session during this sender activity could possibly accept packets from the second session as belonging to the first session if the TSI for the two sessions were identical. The mapping of TSI field values to sessions is outside the scope of this document and is to be done out-of-band.
TSIは、セッションがアクティブである期間中に、送信者が提供するすべてのセッションの中で一意であること、そしてセッションがアクティブなとき、前後の時間の大期間にしなければなりません。 TSIの主な目的は、誤って受信者が加入しているセッション以外のセッションに属している送信者からのパケットを受け入れるのレシーバを防ぐためです。例えば、セッションが非アクティブ化され、その後、別のセッションが送信者によって活性化され、2つのセッションがチャネルの重複セットを使用すると仮定する。二つのセッションのための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 which object within the session this
packet pertains to. For example, a sender might send a number
of files in the same session, using TOI=0 for the first file,
TOI=1 for the second one, etc. As another example, the TOI may
be a unique global identifier of the object that is being
transmitted from several senders concurrently, and the TOI
value may be the output of a hash function applied to the
object. The mapping of TOI field values to objects is outside
the scope of this document and is to be done out-of-band. The
TOI field MUST be used in all packets if more than one object
is to be transmitted in a session, i.e. the TOI field is either
present in all the packets of a session or is never present.
The length of the TOI field is 32*O + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits.
TOIフィールドの長さは32 * O + 16 * Hビットです。 TSIフィールドの集合体の長さプラスTOIフィールドは、32ビットの倍数であることに留意されたいです。
Sender Current Time (SCT): 0 or 32 bits
送信側現在時刻（SCT）：0または32ビット
This field represents the current clock at the sender and at
the time this packet was transmitted, measured in units of 1ms
and computed modulo 2^32 units from the start of the session.
This field MUST NOT be present if T=0 and MUST be present if T=1.
T = 0とする場合は、T = 1に存在しなければならない場合、このフィールドは存在してはなりません。
Expected Residual Time (ERT): 0 or 32 bits
予想残余時間（ERT）：0または32ビット
This field represents the sender expected residual transmission
time for the current session or for the transmission of the
current object, measured in units of 1ms. If the packet
containing the ERT field also contains the TOI field, then ERT
refers to the object corresponding to the TOI field, otherwise
it refers to the session.
This field MUST NOT be present if R=0 and MUST be present if R=1.
このフィールドは、R = 0の場合は存在してはならないとR = 1の場合に存在していなければなりません。
Header Extensions are used in LCT to accommodate optional header fields that are not always used or have variable size. Examples of the use of Header Extensions include:
ヘッダ拡張機能は常に使用または可変サイズを持っていないオプションのヘッダーフィールドに対応するためにLCTに使用されています。ヘッダー拡張機能の使用例は次のとおりです。
o Extended-size versions of already existing header fields.
既存のヘッダフィールドのO拡張サイズバージョン。
o Sender and Receiver authentication information.
SenderとReceiverの認証情報O。
The presence of Header Extensions can be inferred by the LCT header length (HDR_LEN): if HDR_LEN is larger than the length of the standard header then the remaining header space is taken by Header Extension fields.
ヘッダ拡張の存在は、LCTヘッダ長（HDR_LEN）によって推測することができる：HDR_LENは標準ヘッダの長さよりも大きい場合、残りのヘッダ空間は、ヘッダ拡張フィールドによって行われます。
If present, Header Extensions MUST be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting a packet. The default action for unrecognized header extensions is to ignore them. This allows the future introduction of backward-compatible enhancements to LCT without changing the LCT version number. Non backward-compatible header extensions CANNOT be introduced without changing the LCT version number.
存在する場合、ヘッダ拡張は、彼らがどんな輻輳制御手順を実行するか、そうでない場合はパケットを受け入れる前に認識されていることを確認するために処理しなければなりません。認識できないヘッダ拡張のためのデフォルトのアクションは、それらを無視することです。これは、LCTバージョン番号を変更することなく、LCTに下位互換性強化の将来の導入を可能にします。非下位互換性のあるヘッダ拡張はLCTバージョン番号を変更することなく導入することができません。
Protocol instantiation MAY override this default behavior for PI-specific extensions (see below).
プロトコルのインスタンス化は、PI固有の拡張機能（下記参照）のために、このデフォルトの動作を無効にすることができます。
There are two formats for Header Extension fields, as depicted below. The first format is used for variable-length extensions, with Header Extension Type (HET) values between 0 and 127. The second format is used for fixed length (one 32-bit word) extensions, using HET values from 127 to 255.
下記に示すように、ヘッダ拡張フィールドのための2つの形式があります。最初のフォーマットは、ヘッダ拡張タイプ（HET）の値と0と127との間に第二の形式は127〜255 HET値を使用して、固定長（1つの32ビット・ワード）の拡張のために使用される、可変長の拡張のために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Format of additional headers
図2 - 追加ヘッダのフォーマット
The explanation of each sub-field is the following:
各サブフィールドの説明は以下の通りであります：
Header Extension Type (HET): 8 bits
ヘッダ拡張タイプ（HET）：8ビット
The type of the Header Extension. This document defines a
number of possible types. Additional types may be defined in future versions of this specification. HET values from 0 to
127 are used for variable-length Header Extensions. HET values
from 128 to 255 are used for fixed-length 32-bit Header
Extensions.
Header Extension Length (HEL): 8 bits
ヘッダ拡張長（HEL）：8ビット
The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field MUST be present for
variable-length extensions (HET between 0 and 127) and MUST NOT
be present for fixed-length extensions (HET between 128 and
255).
Header Extension Content (HEC): variable length
ヘッダー拡張コンテンツ（HEC）：可変長
The content of the Header Extension. The format of this sub-
field depends on the Header Extension type. For fixed-length
Header Extensions, the HEC is 24 bits. For variable-length
Header Extensions, the HEC field has variable size, as
specified by the HEL field. Note that the length of each
Header Extension field MUST be a multiple of 32 bits. Also
note that the total size of the LCT header, including all
Header Extensions and all optional header fields, cannot exceed
255 32-bit words.
Header Extensions are further divided between general LCT extensions and Protocol Instantiation specific extensions (PI-specific). General LCT extensions have HET in the ranges 0:63 and 128:191 inclusive. PI-specific extensions have HET in the ranges 64:127 and 192:255 inclusive.
ヘッダ拡張は、さらに、一般的なLCT拡張機能やプロトコルインスタンス固有の拡張（PI固有）の間で分割されています。 191包括的な：一般LCT拡張子は範囲0:63と128でHETを持っています。 PI固有の拡張機能は、範囲64でHETを持っている：127および192：255の範囲を。
General LCT extensions are intended to allow the introduction of backward-compatible enhancements to LCT without changing the LCT version number. Non backward-compatible header extensions CANNOT be introduced without changing the LCT version number.
一般LCT拡張はLCTバージョン番号を変更することなく、LCTへの下位互換性の拡張機能の導入を可能にすることを意図しています。非下位互換性のあるヘッダ拡張はLCTバージョン番号を変更することなく導入することができません。
PI-specific extensions are reserved for PI-specific use with semantic and default parsing actions defined by the PI.
PI固有の拡張は、PIによって定義されたセマンティックとデフォルトの構文解析アクションとPI-特定の使用のために予約されています。
The following general LCT Header Extension types are defined:
次の一般LCTヘッダ拡張タイプが定義されています。
EXT_NOP=0 No-Operation extension. The information present in this extension field MUST be ignored by receivers.
EXT_NOP = 0ノーオペレーション拡張。この拡張フィールドに存在する情報は、受信機によって無視されなければなりません。
EXT_AUTH=1 Packet authentication extension Information used to authenticate the sender of the packet. The format of this Header Extension and its processing is outside the scope of this document and is to be communicated out-of-band as part of the session description.
EXT_AUTH = 1つのパケット認証拡張情報は、パケットの送信者を認証するために使用されます。このヘッダー拡張とその処理の形式は、この文書の範囲外であるとセッション記述の一部として、アウトオブバンド通信されます。
It is RECOMMENDED that senders provide some form of
packet authentication. If EXT_AUTH is present,
whatever packet authentication checks that can be
performed immediately upon reception of the packet
SHOULD be performed before accepting the packet and
performing any congestion control-related action on it.
Some packet authentication schemes impose a delay of several seconds between when a packet is received and when the packet is fully authenticated. Any congestion control related action that is appropriate MUST NOT be postponed by any such full packet authentication.
いくつかのパケットの認証方式は、パケットを受信したときに、パケットが完全に認証されたときの間に、数秒の遅延を課します。適切である任意の輻輳制御に関連するアクションは、このような完全なパケット認証により延期してはなりません。
All senders and receivers implementing LCT MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to parse its content.
LCTを実装するすべての送信者と受信者はEXT_NOPヘッダー拡張をサポートしなければならないとEXT_AUTHを認識しなければならないが、その内容を解析することができないかもしれません。
Before joining an LCT session a receiver MUST obtain a session description. The session description MUST include:
LCTセッションに参加する前に、受信機は、セッション記述を取得しなければなりません。セッション記述が含まれている必要があります
o The sender IP address;
送信元の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 it is being used.
Oに十分な情報は、それが使用されている場合、パケットの認証方式が使用されているかを決定します。
The session description could also include, but is not limited to:
セッション記述も含めることができるが、これらに限定されません。
o The data rates used for each LCT channel;
各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 to be included in the session description.
LCTを使用してプロトコルのインスタンス化は、セッション記述に含まれなければならないものに追加の要件を配置することがあります。例えば、プロトコルのインスタンスは、各チャネル、またはセッション、または必要とされるかもしれない他のヘッダに関連する他の情報のためのオブジェクトにTOI値（S）のマッピングのためのデータレートは、セッション記述に含まれることを必要とするかもしれません。
The session description could be in a form such as SDP as defined in RFC 2327 [8], or XML metadata as defined in RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2068 [6], etc. It might be carried in a session announcement protocol such as SAP as defined in RFC 2974 [9], obtained using a proprietary session control protocol, located on a Web page with scheduling information, or conveyed via E-mail or other out-of-band methods. Discussion of session description format, and distribution of session descriptions is beyond the scope of this document.
RFC 2068で定義されているセッション記述は、それがかもしれない等、[6] RFC 2327で定義されるように[14] [8]、またはXMLメタデータRFC 3023で定義されるようなSDPのような形態であっても、またはHTTP / MIMEヘッダができRFC 2974で定義されている[9]、Eメールまたはその他のアウトオブバンド方法を介して、スケジューリング情報をWebページ上に配置独自のセッション制御プロトコルを用いて得られた、又は搬送SAPなどのセッションアナウンスメントプロトコルで運ばれます。セッション記述形式、およびセッション記述の分布の説明は、この文書の範囲外です。
Within an LCT session, a sender using LCT transmits a sequence of packets, each in the format defined above. Packets are sent from a sender using one or more LCT channels which together constitute a session. Transmission rates may be different in different channels and may vary over time. The specification of the other building block headers and the packet payload used by a complete protocol instantiation using LCT is beyond the scope of this document. This document does not specify the order in which packets are transmitted, nor the organization of a session into multiple channels. Although these issues affect the efficiency of the protocol, they do not affect the correctness nor the inter-operability of LCT between senders and receivers.
LCTセッション内で、LCTを使用して送信者は、上記で定義された形式で各パケットのシーケンスを送信します。パケットが一緒にセッションを構成する1つまたは複数のLCTチャネルを用いて送信者から送信されます。伝送速度は異なるチャネルで異なることができ、経時的に変化することがあります。他のビルディング・ブロック・ヘッダとLCTを用いた完全なプロトコルのインスタンスによって使用されるパケットペイロードの仕様は、この文書の範囲外です。この文書では、パケットが送信される順序、また複数のチャネルへのセッションの組織が指定されていません。これらの問題は、プロトコルの効率に影響を与えるが、それらは送信側と受信側の間で正確にもLCTの相互運用性には影響を与えません。
Several objects can be carried within the same LCT session. In this case, each object MUST be identified by a unique TOI. Objects MAY be transmitted sequentially, or they MAY be transmitted concurrently. It is good practice to only send objects concurrently in the same session if the receivers that participate in that portion of the session have interest in receiving all the objects. The reason for this is that it wastes bandwidth and networking resources to have receivers receive data for objects that they have no interest in.
複数のオブジェクトが同じLCTセッション内で行うことができます。この場合、各オブジェクトは、一意のTOIによって同定されなければなりません。オブジェクトが順次送信されてもよい、またはそれらは、同時に送信されてもよいです。セッションのその部分に参加受信機がすべてのオブジェクトを受け取ることに関心を持っている場合のみ、同じセッションで同時にオブジェクトを送信することをお勧めします。この理由は、それが受信機は、彼らがに興味を持っていないオブジェクトのデータを受信するために持っている帯域幅およびネットワークリソースを浪費ということです。
Typically, the sender(s) continues to send packets in a session until the transmission is considered complete. The transmission may be considered complete when some time has expired, a certain number of packets have been sent, or some out-of-band signal (possibly from a higher level protocol) has indicated completion by a sufficient number of receivers.
典型的には、送信者（複数可）は、送信が完了したと見なされるまで、セッション内のパケットを送信し続けます。ある程度の時間が経過したとき、送信パケットの特定の数は、送信された、完了したとみなされてもよい、または（おそらくはより高いレベルのプロトコルから）いくつかのアウトオブバンド信号は、受信機のに十分な数で完了を示しました。
For the reasons mentioned above, this document does not pose any restriction on packet sizes. However, network efficiency considerations recommend that the sender uses an as large as possible packet payload size, but in such a way that packets do not exceed the network's maximum transmission unit size (MTU), or when fragmentation coupled with packet loss might introduce severe inefficiency in the transmission.
上記の理由から、このドキュメントでは、パケットサイズ上の任意の制限をもたらすことはありません。しかし、ネットワーク効率の考慮は、送信者が可能なパケットのペイロードのサイズと同じ大きさを使用することをお勧めしますが、パケットがネットワークの最大伝送ユニットサイズ（MTU）を超えない場合、またはパケット損失と結合断片は、重篤な非効率性を導入する可能性がある場合、このような方法で伝送インチ
It is recommended that all packets have the same or very similar sizes, as this can have a severe impact on the effectiveness of congestion control schemes such as the ones described in [22], [3], and [25]. A sender of packets using LCT MUST implement the sender-side part of one of the congestion control schemes that is in accordance with RFC 2357 [13] using the Congestion Control Information field provided in the LCT header, and the corresponding receiver congestion control scheme is to be communicated out-of-band and MUST be implemented by any receivers participating in the session.
すべてのパケットが同じ又は非常に類似したサイズを有することが、これは、輻輳制御方式の有効性に深刻な影響を与えることができるように、このような[22]に記載のもののように、推奨される、[3]、及び[25]。 LCTを使用してパケットの送信元は、LCTヘッダに設けられた輻輳制御情報フィールドを使用して[13] RFC 2357に応じた輻輳制御方式の一つの送信側の一部を実装しなければなりません、そして、対応する受信機の輻輳制御方式でありますアウトオブバンド通信されると、セッションに参加する任意の受信機によって実装されなければなりません。
Receivers can operate differently depending on the delivery service model. For example, for an on demand service model, receivers may join a session, obtain the necessary packets to reproduce the object, and then leave the session. As another example, for a streaming service model, a receiver may be continuously joined to a set of LCT channels to download all objects in a session.
レシーバは、配信サービスモデルに応じて異なる動作をすることができます。例えば、オンデマンドサービスモデルのために、受信機は、セッションに参加するオブジェクトを再生するために必要なパケットを取得し、その後、セッションを終了してもよいです。別の例として、ストリーミングサービスモデルのため、受信機は、連続的に、セッション内のすべてのオブジェクトをダウンロードするLCTチャネルのセットに結合されてもよいです。
To be able to participate in a session, a receiver MUST obtain the relevant session description information as listed in Section 6.1.
セクション6.1に記載されているようにセッションに参加できるようにするために、受信機は、関連するセッション記述情報を取得しなければなりません。
If packet authentication information is present in an LCT header, it SHOULD be used as specified in Section 5.2. To be able to be a receiver in a session, the receiver MUST be able to process the LCT header. The receiver MUST be able to discard, forward, store or process the other headers and the packet payload. If a receiver is not able to process a LCT header, it MUST drop from the session.
パケットの認証情報がLCTヘッダに存在する場合、セクション5.2で指定されるように、それが使用されるべきです。セッション中に受信することができるように、受信機は、LCTヘッダを処理できなければなりません。受信機は、前方に、廃棄格納または他のヘッダとパケットペイロードを処理できなければなりません。受信機は、LCTヘッダを処理できない場合は、セッションから削除する必要があります。
To be able to participate in a session, a receiver MUST implement the congestion control protocol specified in the session description using the Congestion Control Information field provided in the LCT header. If a receiver is not able to implement the congestion control protocol used in the session, it MUST NOT join the session. When the session is transmitted on multiple LCT channels, receivers MUST initially join channels according to the specified startup behavior of the congestion control protocol. For a multiple rate congestion control protocol that uses multiple channels, this typically means that a receiver will initially join only a minimal set of LCT channels, possibly a single one, that in aggregate are carrying packets at a low rate. This rule has the purpose of preventing receivers from starting at high data rates.
セッションに参加できるようにするために、受信機は、LCTヘッダに設けられた輻輳制御情報フィールドを使用して、セッション記述で指定された輻輳制御プロトコルを実装しなければなりません。受信機がセッションで使用される輻輳制御プロトコルを実装することができない場合は、セッションに参加してはなりません。セッションが複数LCTチャネル上で送信される場合、受信機は、最初の輻輳制御プロトコルの指定された起動時の動作に応じてチャンネルに参加しなければなりません。複数のチャネルを使用する複数のレート混雑制御プロトコルのために、これは、典型的には、受信機が最初に集計に低いレートでパケットを運んでいることを、おそらくLCTチャネルの最小限のセット、単一のものに参加することを意味します。このルールは、高いデータレートで始まるからレシーバを防止する目的を持っています。
Several objects can be carried either sequentially or concurrently within the same LCT session. In this case, each object is identified by a unique TOI. Note that even if a server stops sending packets for an old object before starting to transmit packets for a new object, both the network and the underlying protocol layers can cause some reordering of packets, especially when sent over different LCT channels, and thus receivers SHOULD NOT assume that the reception of a packet for a new object means that there are no more packets in transit for the previous one, at least for some amount of time.
いくつかのオブジェクトは、同じLCTセッション内のいずれかで、順次又は同時に行うことができます。この場合、各オブジェクトは、一意のTOIによって識別されます。サーバは、新しいオブジェクトのためのパケットを送信するために開始する前に、古いオブジェクトのためのパケットの送信を停止した場合でも、ネットワークおよび基本的なプロトコル層の両方が異なるLCTチャネルを介して送信される場合は特に、パケットのいくつかの並べ替えを引き起こす可能性があり、したがって、受信機が必要があることに注意してください新しいオブジェクトのためのパケットの受信が少なくともある程度の時間のために、以前のもののために輸送中のパケットが存在しないことを意味していることを前提としません。
A receiver MAY be concurrently joined to multiple LCT sessions from one or more senders. The receiver MUST perform congestion control on each such LCT session. If the congestion control protocol allows the receiver some flexibility in terms of its actions within a session then the receiver MAY make choices to optimize the packet flow performance across the multiple LCT sessions, as long as the receiver still adheres to the congestion control rules for each LCT session individually.
受信機は、同時に一つ以上の送信者から複数LCTセッションに接合することができます。受信機は、このような各LCTセッションに輻輳制御を実行しなければなりません。輻輳制御プロトコルは、受信機にセッション内での行動の面でいくつかの柔軟性を可能にした場合、受信機は、受信機は、まだそれぞれの輻輳制御規則に準拠している限り、複数のLCTのセッション間でパケットフローのパフォーマンスを最適化するための選択を行うことができます個別LCTセッション。
As described in RFC 3048 [23], LCT is a building block that is intended to be used, in conjunction with other building blocks, to help specify a protocol instantiation. A congestion control building block that uses the Congestion Control information field within the LCT header MUST be used by any protocol instantiation that uses LCT, and other building blocks MAY also be used, such as a reliability building block.
RFC 3048 [23]に記載されているように、LCTは、プロトコルのインスタンスを指定するために役立つ、他のビルディングブロックと組み合わせて、使用されることが意図されるビルディングブロックです。 LCTヘッダ内の輻輳制御情報フィールドを使用して輻輳制御ビルディングブロックはまた、信頼性のビルディングブロックとして使用することができるLCT、及び他のビルディングブロックを使用する任意のプロトコルのインスタンスによって使用されなければなりません。
The congestion control MUST be applied to the LCT session as an entity, i.e., over the aggregate of the traffic carried by all of the LCT channels associated with the LCT session. Some possible schemes are specified in [22], [3], and [25]. The Congestion Control Information field in the LCT header is an opaque field that is reserved to carry information related to congestion control. There MAY also be congestion control Header Extension fields that carry additional information related to congestion control.
輻輳制御は、LCTセッションに関連するLCTチャネルのすべてによって運ばれるトラフィックの集合体にわたって、すなわち、エンティティとしてLCTセッションに適用されなければなりません。いくつかの可能なスキームが指定されている[22]、[3]、及び[25]。 LCTヘッダ内の輻輳制御情報フィールドは、輻輳制御に関する情報を搬送するために予約されている不透明なフィールドです。また、輻輳制御に関連する追加情報を運ぶ輻輳制御ヘッダー拡張フィールドがあるかもしれません。
The particular layered encoder and congestion control protocols used with LCT have an impact on the performance and applicability of LCT. For example, some layered encoders used for video and audio streams can produce a very limited number of layers, thus providing a very coarse control in the reception rate of packets by receivers in a session. When LCT is used for reliable data transfer, some FEC codecs are inherently limited in the size of the object they can encode, and for objects larger than this size the reception overhead on the receivers can grow substantially.
LCTで使用される特定の層状エンコーダと輻輳制御プロトコルは、LCTの性能と適用性に影響を与えます。例えば、ビデオおよびオーディオストリームに使用されるいくつかの層状のエンコーダは、このようにセッションに受信機によってパケットの受信レートに非常に粗大な制御を提供する、層の非常に限られた数を生成することができます。 LCTは、信頼性の高いデータ転送に使用される場合、いくつかのFECコーデックは、本質的に、それらがコードすることができるオブジェクトのサイズが制限され、このサイズよりも大きいオブジェクトのための受信機で受信オーバヘッドは、実質的に成長することができます。
A more in-depth description of the use of FEC in Reliable Multicast Transport (RMT) protocols is given in [11]. Some of the FEC codecs that MAY be used in conjunction with LCT for reliable content delivery are specified in [12]. The Codepoint field in the LCT header is an opaque field that can be used to carry information related to the encoding of the packet payload.
高信頼マルチキャストトランスポート（RMT）プロトコルにおけるFECの使用のより詳細な説明は、[11]に記載されています。信頼性の高いコンテンツ配信のためのLCTと組み合わせて使用することができるFECコーデックの一部は、[12]で指定されています。 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 RFC 2327 [8], or XML metadata as defined in RFC 3023 [14], or HTTP/Mime headers as defined in RFC 2068 [6], and distributed with SAP as defined in RFC 2974 [9], using HTTP, or in other ways. It is RECOMMENDED that an authentication protocol such as IPSEC [11] be used to deliver the session description to receivers to ensure the correct session description arrives.
6.1節で説明したようにLCTはまた、セッション記述を取得するために受信機を必要とします。セッション記述は、RFC 2327で定義されている[14] [8]、またはXMLメタデータRFC 3023で定義されるようなSDPのような形態であっても、またはHTTP / MIMEヘッダRFC 2068で定義されるように[6]、およびSAPと一緒に配布可能性RFC 2974で定義されている[9]、HTTPを使用して、または他の方法です。このようなIPSEC [11]などの認証プロトコルを記述が到着正しいセッションを確実にするために、受信機にセッション記述を送達するために使用することを推奨されています。
It is recommended that LCT implementors use some packet authentication scheme to protect the protocol from attacks. An example of a possibly suitable scheme is described in [15].
LCTの実装は、攻撃からプロトコルを保護するために、いくつかのパケットの認証方式を使用することをお勧めします。おそらく適切なスキームの例は、[15]に記載されています。
Some protocol instantiations that use LCT MAY use building blocks that require the generation of feedback from the receivers to the sender. However, the mechanism for doing this is outside the scope of LCT.
LCTを使用するいくつかのプロトコルのインスタンスは、受信機から送信者へのフィードバックの生成を必要とするビルディングブロックを使用するかもしれません。ただし、これを行うためのメカニズムは、LCTの範囲外です。
LCT can be subject to denial-of-service attacks by attackers which try to confuse the congestion control mechanism, or send forged packets to the session which would prevent successful reconstruction or cause inaccurate reconstruction of large portions of an object by receivers. LCT is particularly affected by such an attack since many receivers may receive the same forged packet. It is therefore RECOMMENDED that an integrity check be made on received objects before delivery to an application, e.g., by appending an MD5 hash [17] to an object before it is sent and then computing the MD5 hash once the object is reconstructed to ensure it is the same as the sent object. Moreover, in order to obtain strong cryptographic integrity protection a digital signature verifiable by the receiver SHOULD be computed on top of such a hash value. It is also RECOMMENDED that protocol instantiations that use LCT implement some form of packet authentication such as TESLA [15] to protect against such attacks. Finally, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent injecting forged packets into the multicast tree data path.
LCTは、輻輳制御機構を混乱させる、または成功した再構成を防止または受信機によって対象物の大部分の不正確な再構成を引き起こすセッションに偽造パケットを送信しようとする攻撃者によって、サービス拒否攻撃の対象にすることができます。 LCTは、特に多くの受信機が同じ偽造パケットを受信することができるので、このような攻撃の影響を受けています。それが送信され、その後、オブジェクト一度MD5ハッシュを計算することを確実にするために再構成される前に、したがって、オブジェクトに[17] MD5ハッシュを付加することによって、例えば、整合性チェックがアプリケーションに配信する前に受信されたオブジェクト上で行われることが推奨されます送信されたオブジェクトと同じです。また、強力な暗号化、完全性保護を得るために受信機によって検証デジタル署名は、ハッシュ値の上に計算されるべきです。また、LCTを使用するプロトコルのインスタンス化は、このような攻撃から保護するために、そのようなテスラ[15]などのパケット認証のいくつかのフォームを実装することが推奨されます。最後に、逆方向パス転送チェックがマルチキャストツリーデータパスに偽造パケットを注入悪い薬剤の可能性を制限するために受信機に送信者からのパスに沿ってすべてのネットワークルータとスイッチで有効にすることが推奨されます。
Another vulnerability of LCT is the potential of receivers obtaining an incorrect session description for the session. The consequences of this could be that legitimate receivers with the wrong session description are unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate Session Descriptions from authorized senders.
LCTのもう一つの脆弱性は、セッションの不正なセッション記述を取得する受信機の可能性です。これの結果は、間違ったセッション記述を持つ、正当な受信機が正しくセッションコンテンツを受信することができない、または受信機が誤って、それによってネットワークの一部でトラフィックを中断、彼らがすることができるよりもはるかに高いレートで受信しようということである可能性があります。これらの問題を回避するために、対策は受信機が唯一認可された送信者からの正当なセッションの説明を受け入れることを確認するために、ソースの認証を使用することにより、例えば、間違ったセッションの説明を受け入れることから、レシーバを防ぐために取られることが推奨されます。
A receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect health of the network in the path between the sender and the receiver, and may also affect the reception rates of other receivers joined to the session. It is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the Session Description needed to join the session. How receivers identify themselves as legitimate is outside the scope of this document.
複数レート輻輳制御構築ブロックの誤ったまたは破損実装と受信機は、送信機と受信機との間の経路内のネットワークの健康に影響を与えることができ、また、他の受信機の受信レートに影響を与える可能性があるセッションに参加しました。したがって、受信機は、彼らがセッションに参加するために必要なセッション記述を受ける前に、正当として自分自身を識別するために要求されることが推奨されます。どのように受信機が正当として自分自身を識別することは、この文書の範囲外です。
No information in this specification is subject to IANA registration.
本明細書中の情報は、IANA登録の対象となりません。
Building blocks used in conjunction with LCT MAY introduce additional IANA considerations.
LCTと組み合わせて使用するビルディングブロックは、追加のIANAの考慮を導入することができます。
Thanks to Vincent Roca and Roger Kermode for detailed comments and contributions to this document. Thanks also to Bruce Lueckenhoff, Hayder Radha and Justin Chapweske for detailed comments on this document.
詳細なコメントや、この文書への貢献のためにヴィンセントロカとロジャーKermodeに感謝します。このドキュメントの詳細なコメントにもブルースLueckenhoff、HayderラダとジャスティンChapweskeに感謝します。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., Roetter, A. and W. Shaver, "FLID-DL: Congestion Control for Layered Multicast", Proceedings of Second International Workshop on Networked Group Communications (NGC 2000), Palo Alto, CA, November 2000.
[3]バイヤーズ、JW、Frumin、M.、ホーン、G.、ルビー、M.、Mitzenmacher、M.、Roetter、A.及びW.シェーバー、 "FLID-DL：階層化マルチキャストのための輻輳制御"、議事録のネットワークグループ通信に関する第二回国際ワークショップ（2000年NGC）、カリフォルニア州パロアルト、2000年11月。
[4] Byers, J.W., Luby, M., Mitzenmacher, M. and A. Rege, "A Digital Fountain Approach to Reliable Distribution of Bulk Data", Proceedings ACM SIGCOMM'98, Vancouver, Canada, September 1998.
[4]バイヤーズ、J.W.、ルビー、M.、Mitzenmacher、M.とA.レゲ、 "バルクデータの信頼性の高い配信にデジタル泉アプローチ"、議事ACM SIGCOMM'98、バンクーバー、カナダ、1998年9月。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[5]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, January 1997.
[6]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616、1997年1月。
[7] Gemmell, J., Schooler, E. and J. Gray, "Fcast Multicast File Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.
[7] Gemmell、J.、学生はE.およびJ.グレイ、 "Fcastマルチキャストファイル配信"、IEEEネットワーク、巻。 14、第1号、頁58-68、2000年1月。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[9] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[9]ハンドレー、M.、パーキンス、C.およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[10] Holbrook, H. W., "A Channel Model for Multicast", Ph.D. Dissertation, Stanford University, Department of Computer Science, Stanford, California, August 2001.
[10]ホルブルック、H. W.、 "マルチキャスト用チャネルモデル"、博士論文、スタンフォード大学、コンピュータサイエンス学部、スタンフォード大学、カリフォルニア州、2001年8月。
[11] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[11]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（FEC）の使用"、RFC 3453、 2002年12月。
[12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[12]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 3452、2002年12月。
[13] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[13]マンキン、A.、Romanow、A.、RFC 2357、1998年6月ブラドナー、S.およびV.パクソン、 "信頼できるマルチキャストトランスポート及びアプリケーションプロトコルを評価するためのIETF基準"。
[14] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[14]村田、M.、サンローラン、S.およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[15] Perrig, A., Canetti, R., Song, D. and J.D. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[15] Perrig、A.、カネッティ、R.、歌、D.およびJ.D. Tygar、 "マルチキャストのための効率的で安全なソース認証"、ネットワークと分散システムセキュリティシンポジウム、NDSS 2001、頁35-46、2001年2月。
[16] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[16]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[17]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[18] Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, Apr 1997.
[18] Rizzo氏、L.、 "信頼性の高いコンピュータ通信プロトコルのための効果的な消去符号"、ACM SIGCOMMコンピュータコミュニケーションレビュー、Vol.27、第2号、pp.24-36、1997年4月。
[19] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast congestion control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August 2000.
[19] Rizzo氏、L、 "PGMCC：TCPフレンドリーなシングルレートのマルチキャスト輻輳制御方式"、SIGCOMM 2000の議事録、スウェーデンストックホルム、2000年8月。
[20] Rizzo, L and L. Vicisano, "Reliable Multicast Data Distribution protocol based on software FEC techniques", Proceedings of the Fourth IEEES Workshop on the Architecture and Implementation of High Performance Communication Systems, HPCS'97, Chalkidiki Greece, June 1997.
[20] Rizzo氏、LおよびL. Vicisano、「ソフトウェアFEC技術に基づいた信頼性の高いマルチキャストデータ配信プロトコル」、高性能通信システム、HPCS'97、ハルキディキギリシャ、1997年6月のアーキテクチャと実装上の第四IEEESワークショップの議事録。
[21] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[21] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[22] Vicisano, L., Rizzo, L. and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", IEEE Infocom'98, San Francisco, CA, Mar.28-Apr.1 1998.
[22] Vicisano、L.、リゾー、L.およびJ.クロウクロフト、 "階層化マルチキャストデータ転送のためのTCPのような輻輳制御"、IEEE Infocom'98、サンフランシスコ、CA、Mar.28-Apr.1 1998。
[23] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S. and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[23] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.及びM.ルビー、 "一対多バルクデータ転送のための信頼できるマルチキャストトランスポート・ビルディング・ブロック"、 RFC 3048、2001年1月。
[24] Kermode, R., Vicisano, L., "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[24] Kermode、R.、Vicisano、L.、RFC 3269、2002年4月 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書の作者のガイドライン"。
[25] Luby, M., Goyal V. K, Skaria S., Horn, G., "Wave and Equation Based Rate Control using Multicast Round-trip Time", Proceedings of ACM SIGCOMM 2002, Pittsburgh PA, August, 2002.
ルビー、M.、Goyal氏V. K、Skaria S.、ホーン、G.、 "波動と式ベースのレートコントロールは、マルチキャスト往復時間を利用して"、ACMのSIGCOMM 2002、ピッツバーグPA、2002年8月の議事録[25]。
Authors' Addresses
著者のアドレス
Michael Luby Digital Fountain 39141 Civic Center Dr. Suite 300 Fremont, CA, USA, 94538
マイケル・ルビーデジタル噴水39141シビックセンター博士スイート300フリーモント、CA、USA、94538
EMail: luby@digitalfountain.com
メールアドレス：luby@digitalfountain.com
Jim Gemmell Microsoft Research 455 Market St. #1690 San Francisco, CA, 94105
ジム・Gemmellマイクロソフトリサーチ455市場セント＃1690サンフランシスコ、CA、94105
EMail: jgemmell@microsoft.com
メールアドレス：jgemmell@microsoft.com
Lorenzo Vicisano cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA, USA, 95134
ロレンツォVicisanoシスコシステムズ株式会社170西タスマン博士サンノゼ、CA、USA、95134
EMail: lorenzo@cisco.com
メールアドレス：lorenzo@cisco.com
Luigi Rizzo Dip. Ing. dell'Informazione, Univ. di Pisa via Diotisalvi 2, 56126 Pisa, Italy
ルイジ・リゾディップ。のIng。情報工学大学ピサディオーティソルビ2、56126ピサ、イタリア経由
EMail: luigi@iet.unipi.it
メールアドレス：luigi@iet.unipi.it
Mark Handley ICIR 1947 Center St. Berkeley, CA, USA, 94704
マーク・ハンドリーICIR 1947センターセントバークレー、CA、USA、94704
EMail: mjh@icir.org
メールアドレス：mjh@icir.org
Jon Crowcroft Marconi Professor of Communications Systems University of Cambridge Computer Laboratory William Gates Building J J Thomson Avenue Cambridge CB3 0FD, UK
ケンブリッジの通信システム大学のコンピュータ研究所のウィリアム・ゲイツビルJ JトムソンアベニューケンブリッジCB3 0FD、英国のジョン・クロークロフトマルコーニ教授
EMail: Jon.Crowcroft@cl.cam.ac.uk
メールアドレス：Jon.Crowcroft@cl.cam.ac.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。