[要約] RFC 5651は、一斉配信プロトコルにおいて、大規模なデータを階層化して効率的に転送するための共通コンポーネント「LCT（Layered Coding Transport）ビルディングブロック」の最新仕様を定義しています。セッション管理、輻輳制御、およびオブジェクト識別などの機能を抽象化して提供し、信頼性の高いマルチキャスト配信プロトコル（ALCやFLUTEなど）を構築するための基盤となります（RFC 3451の後継）。
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
階層符号化トランスポート（LCT）ビルディングブロック
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.
本書は、インターネットコミュニティ向けのインターネット標準化過程にあるプロトコルを規定し、改善に向けた議論や提案を求めています。このプロトコルの標準化上の状態については、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。この文書の配布に制限はありません。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2009 IETF Trustおよび本書に著者として記載された各人に帰属します。すべての権利を留保します。
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文書に関するIETF Trustの法的条項（http://trustee.ietf.org/license-info）が適用されます。本書に関する権利と制限が記載されているため、これらの文書をよく確認してください。本書から抜き出したコードコンポーネントには、Trustの法的条項のセクション4.eに記載されたSimplified BSD Licenseの文面を含める必要があります。また、BSD Licenseに記載されているとおり、保証なしで提供されます。
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.
本書には、2008年11月10日より前に公開された、または一般に入手可能となったIETF文書やIETF寄稿物の内容が含まれている場合があります。これらの内容の一部の著作権者は、IETF標準化過程の外でその内容を変更することをIETF Trustが許可する権利を付与していない可能性があります。
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標準化過程の外で変更することはできず、本書の派生著作物も同過程の外では作成できません。ただし、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）は、信頼性の高いコンテンツ配信プロトコルとストリーミング配信プロトコルに、トランスポート層の機能を提供します。LCTはIPマルチキャストを使うプロトコル向けに設計されていますが、ユニキャストを使うプロトコルもサポートします。LCTは、受信側に複数の伝送レートで配信する輻輳制御と、信頼性の高いコンテンツ配信を実現する符号化方式の両方と互換性があります。
[RFC3451], which was published in the "Experimental" category and which is obsoleted by this document, contained a previous version of the protocol.
「Experimental」カテゴリで公開され、本書によって廃止される[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.
したがって、本書のProposed Standard仕様は、当初の公開以降に蓄積された経験と高まったプロトコルの成熟度を踏まえて更新された[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"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"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マルチキャストネットワークサービスを使う、大規模な拡張性を備えたプロトコルにトランスポート層の機能を提供します。この機能は、信頼性の高いコンテンツ配信やストリーミングなど、さまざまな重要なアプリケーションで共通して必要とされます。
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つ以上のオブジェクトの送信に関するパケットを、一定期間運びます。セッションを単一の送信者から始まるものとして定義するのは、この粒度が輻輳制御によってパケットトラフィックを調整するのに適しているためです。同じセッション内で複数のチャネルを使う理由の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はTransmission Session 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ヘッダーには、セッション情報を帯域内で受信側に伝えるためのフィールドがいくつかあります。必須フィールドの1つであるTransmission Session ID（TSI）を使うと、受信側は受信パケットがどのセッションに属するかを一意に識別できます。もう1つの必須フィールドであるCongestion Control Information（CCI）により、受信側はそのセッションで受信するパケットに必要な輻輳制御を行えます。そのほかのLCTフィールドは、任意ながらセッションに役立つ追加情報を提供します。たとえば、Transport Object Identifier（TOI）はパケットのデータがどのオブジェクトのものかを示し、フラグはセッションの終了や、オブジェクトに対するパケット送信の終了を示します。ヘッダー拡張には、パケット認証や各種の時刻情報を伝えるフィールドを追加できます。Sender Current Time（SCT）は送信側がパケットを送信した時刻、Expected Residual Time（ERT）はセッションまたは伝送オブジェクトが継続する残り時間、Session Last Change（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]に準拠する輻輳制御を使用しなければなりません (MUST)。輻輳制御とは、送信側から受信側への経路で利用できる帯域幅にスループットを適応させ、TCPなど競合するフローと帯域幅を公平に共有する機能です。したがって、LCTセッションに参加する各受信側へ流れるパケットの総量は、TCPなど既存のフロー適応型プロトコルと不公平に競合してはなりません (MUST NOT)。
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]で定義された複数レート輻輳制御方式を使用することが推奨されます (SHOULD)。代替となる複数レート輻輳制御プロトコルは[VIC1998]および[BYE2000]に記載されています。単一レート輻輳制御プロトコルの例は[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.
階層符号化の概念は、音声や映像のストリームを対象に最初に導入されました。たとえば、テレビ放送の情報を、白黒、カラー、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）を使う場合、階層符号化の概念を信頼性の高いコンテンツ配信プロトコルに自然に拡張できます。その説明は[RIZ1997a]、[RIZ1997b]、[GEM2000]、[VIC1998]、[BYE1998]に記載されています。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.
プロトコルインスタンス化（PI）は、LCTフレームワークと他の構成要素を組み合わせて構築してもかまいません (MAY)。LCTを使う完全なプロトコルインスタンス化には、LCTと互換性があり、[RFC2357]に準拠する輻輳制御プロトコルを含めなければなりません (MUST)。そのようなインスタンス化には、LCTと互換性のあるスケーラブルな信頼性プロトコルを含めてもかまいません (MAY)。LCTと互換性のあるセッション制御プロトコルを含めてもかまいません (MAY)。さらに、セキュリティプロトコルなど他のプロトコルを含めてもかまいません (MAY)。
An LCT session comprises a logically related set of one or more LCT channels originating at a single sender. The channels are used for some period of time to carry packets containing LCT headers, and these headers pertain to the transmission of one or more objects that can be of interest to receivers.
LCTセッションは、単一の送信側から始まる、論理的に関連付けられた1つ以上のLCTチャネルで構成されます。各チャネルは一定期間、LCTヘッダーを含むパケットを運びます。そのヘッダーは、受信側が関心を持つ1つ以上のオブジェクトの伝送に関する情報を含みます。
LCT is most applicable for delivery of objects or streams in a session of substantial length, i.e., objects or streams that range in aggregate length from hundreds of kilobytes to many gigabytes, and where the duration of the session is on the order of tens of seconds or more.
LCTは、相当量のデータを扱うセッションでオブジェクトやストリームを配信する用途に最も適しています。たとえば、合計で数百キロバイトから数ギガバイトに及ぶオブジェクトやストリームを、数十秒以上続くセッションで配信する場合です。
As an example, an LCT session could be used to deliver a TV program using three LCT channels. Receiving packets from the first LCT channel could allow black and white reception. Receiving the first two LCT channels could also permit color reception. Receiving all three channels could allow HDTV quality reception. Objects in this example could correspond to individual TV programs being transmitted.
たとえば、LCTセッションで3つのLCTチャネルを使ってテレビ番組を配信できます。最初のチャネルのパケットを受信すると白黒で視聴でき、最初の2つのチャネルを受信するとカラーで視聴できます。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.
別の例として、FEC符号化を使い、異なるレートの10個のLCTチャネルで、1時間ごとに更新される天気図（オブジェクト）を確実に配信する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ヘッダーに含めるか、受信側がセッションに参加した後にその情報を帯域外で伝えてもかまいません (MAY)。
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.
信頼性を実現するため、エンコーダーを使ってパケットペイロードに格納するデータを生成してもかまいません (MAY)。適切なデコーダーを使い、パケットペイロードから元の情報を再現します。このようなエンコーダーとデコーダーを使う場合、LCTヘッダーの後に信頼性ヘッダーを置いてもかまいません (MAY)。信頼性ヘッダーは、パケットペイロードに格納された符号化データの説明に役立ちます。その形式は使用する符号化方式に依存し、帯域外でネゴシエーションします。たとえば、[RFC5052]に記載されたFECヘッダーのいずれかを使えます。
For LCT, when multiple rate congestion control is used, congestion control is achieved by sending packets associated with a given session to several LCT channels. Individual receivers dynamically join one or more of these channels, according to the network congestion as seen by the receiver. LCT headers include an opaque field 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チャネルに送ることで輻輳制御を実現します。受信側は、受信側から見たネットワークの輻輳状況に応じて、これらのチャネルのうち1つ以上に動的に参加します。LCTヘッダーには不透明なフィールドがあり、輻輳制御情報を受信側に伝えるために使用しなければなりません (MUST)。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セッションにはTransport Session Identifier（TSI）が関連付けられていなければなりません (MUST)。TSIは送信側のIPアドレスの範囲内で使われ、送信側のIPアドレスとTSIの組み合わせでセッションを一意に識別しなければなりません (MUST)。基盤となるトランスポートが、[RFC0768]に記載されたUDPである場合、16ビットのUDP送信元ポート番号をそのセッションのTSIとして使ってもかまいません (MAY)。パケット内のすべての箇所でTSI値を同じにしなければなりません (MUST)。ネットワーク層、トランスポート層、その他の層からTSIが提供されない場合は、TSIをLCTヘッダーに含めなければなりません (MUST)。
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] 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.
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.
現在、マルチキャスト配信には、[RFC1112]で定義されたAny-Source Multicast（ASM）モデルと、[RFC4607]で定義されたSource-Specific Multicast（SSM）モデルがあります。LCTはどちらのモデルでも動作しますが、方式によって動作と環境上の考慮事項が多少異なります。ASMでは、送信側SがマルチキャストグループGにパケットを送り、LCTチャネルアドレスは(S,G)の組になります。ここでSは送信側のIPアドレス、Gはマルチキャストグループアドレスです。SSMでは、送信側SがSSMチャネル(S,G)にパケットを送り、LCTチャネルアドレスはSSMチャネルアドレスと同じです。
A sender can locally allocate unique SSM channel addresses, and this makes allocation of LCT channel addresses easy with SSM. To allocate LCT channel addresses using ASM, the sender must uniquely chose the ASM multicast group address across the scope of the group, and this makes allocation of LCT channel addresses more difficult with ASM.
送信側はSSMチャネルアドレスをローカルで一意に割り当てられるため、SSMではLCTチャネルアドレスを容易に割り当てられます。ASMでLCTチャネルアドレスを割り当てるには、送信側がグループの適用範囲内で一意となるASMマルチキャストグループアドレスを選ぶ必要があるため、SSMより難しくなります。
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チャネルに送られたパケットだけです。ASMでは、受信側はマルチキャストグループGに参加してLCTチャネルに加わり、送信側に関係なくGに送られるすべてのパケットを受信する可能性があります。そのため、サービス拒否（DoS）攻撃の防止において、SSMにはASMより明確なセキュリティ上の利点があります。いずれの場合も、受信側はこのような攻撃を軽減するため、パケット認証方式を使うべきです (SHOULD)（セクション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.
プッシュ型サービスモデルで信頼性の高いコンテンツを配信する方法の1つは、一連のオブジェクトを送ることです。たとえば、受信側はセッションに参加し、オブジェクトを復元するのに十分なパケットを受信するまで、参加するLCTチャネル数を動的に調整できます。オブジェクトを復元した後もセッションにとどまり、次のオブジェクトの送信を待つことができます。
The push model is particularly attractive in satellite networks and wireless networks. In these cases, a session may consist of one fixed rate LCT channel.
プッシュ型モデルは、特に衛星ネットワークや無線ネットワークに適しています。このような場合、セッションは固定レートのLCTチャネル1つで構成されることがあります。
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.
たとえば、100 GBのファイルのような大きなオブジェクトを信頼性高く配信するために、プッシュ型サービスモデルを使えます。送信側はSession Descriptionの通知を制御チャネルに送り、受信側はそのチャネルを監視して、関心のあるSession Descriptionが届くたびにセッションへ参加できます。Session Descriptionを受け取ると、各受信側はオブジェクトを復元するのに十分な数のパケットが届くまでセッションに参加し、その時点で受信が正常に完了したことを送信側へ報告できます。送信側は、すべての受信側から復元成功の報告が届くまで、または他の条件が満たされるまで、そのオブジェクトのパケットをセッションに送り続けることができます。
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.
Asynchronous Layered Coding（ALC）には、プッシュ型モデルを支える機能がいくつかあります。たとえば送信側は、パケットヘッダー拡張にExpected Residual Time（ERT）を任意で含められます。ERTは、セッションに単一のオブジェクトが含まれる場合はそのオブジェクトのパケット送信に残る見込み時間を、複数のオブジェクトが含まれる場合はTransmission Object Identifier（TOI）で識別されるオブジェクトのパケット送信に残る見込み時間を示します。受信側はこの情報を使い、オブジェクトの復元に必要な追加パケットを受信する時間がセッションに十分残っているか判断できます。たとえば時間が足りない場合、プッシュ型アプリケーションは受信側から送信側へ報告させ、オブジェクトの復元に必要な数のパケットを受信できるよう送信期間を延長することがあります。送信側はその後、延長後のオブジェクト送信時間に基づくERTを、そのオブジェクトの各後続パケットのヘッダーに含められます。ほかにも、LCTヘッダーにはClose SessionフラグとClose Objectフラグを任意で含められます。Close Sessionフラグは送信側がセッションへのパケット送信をまもなく停止することを示し、Close ObjectフラグはTransmission Object IDで識別されるオブジェクトについて、送信側がセッションへのパケット送信をまもなく停止することを示します。ただし、これらのフラグは完全に信頼できる仕組みではありません。そのため、Close Sessionフラグはセッション終了が近いことを示す手がかりとしてのみ、Close Objectフラグはそのオブジェクトのパケット送信終了が近いことを示す手がかりとしてのみ使うべきです。
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.
オンデマンド型コンテンツ配信では、送信側は通常、対象となるすべての受信側がセッションに参加してオブジェクトを復元できるよう、十分な長さの期間にわたって送信します。たとえば、人気のあるソフトウェア更新を数日間LCTで配信する一方、受信側は複数の時間帯に分けた合計1時間の接続でダウンロードを完了できる場合があります。この場合、受信側はセッションが有効な間ならいつでも参加できます。オブジェクトを復元するのに十分なパケットを受信したら、セッションから離脱します。受信側は、たとえばWebサーバーに問い合わせてSession Descriptionを取得します。
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 MBとします。送信側は最初のLCTチャネルに1 KBのパケットを毎秒50個送れます。このチャネルだけを使う受信側は、損失がなければ1,000秒でオブジェクトを受信できます。また、信頼性のために符号化を使えば、かなりの量のパケット損失があっても受信を完了できます。さらに送信側は、すべてのLCTチャネルへの1 KBパケットの合計送信レートが毎秒1,000個となるよう、複数のLCTチャネルを使えます。この場合、損失がなく、輻輳制御がすぐにすべてのLCTチャネルを使う状態に収束すると仮定すれば、受信側は最短約50秒でオブジェクトを受信できます。
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]で規定された輻輳制御方式を使うことが推奨されます (SHOULD)。LCTを使った信頼性の高いコンテンツ配信に利用できる代替の輻輳制御プロトコルは[VIC1998]および[BYE2000]に記載されています。配信サービスモデルによって、必要となる輻輳制御プロトコルが異なる場合があります。
Packets sent to an LCT session MUST include an "LCT header". The LCT header format is described below.
LCTセッション宛てに送信するパケットには、「LCTヘッダー」を含めなければなりません (MUST)。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ヘッダーで説明するフィールドの一部を同様に規定する場合があります (MAY)。複数のビルディングブロックを使うプロトコルインスタンス化では、共有フィールドを各パケットに1回まで含めることが推奨されます (SHOULD)。たとえば、Expected Residual Timeフィールドを任意で含む別のビルディングブロックをLCTと併用する場合、そのフィールドは各パケットに1回まで含めるべきです (SHOULD)。
The position of the LCT header within a packet MUST be specified by any protocol instantiation that uses LCT.
LCTを使う各プロトコルインスタンス化は、パケット内のLCTヘッダーの位置を規定しなければなりません (MUST)。
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ヘッダー内のすべての整数フィールドは、「ビッグエンディアン」または「ネットワークバイト順」で格納します。つまり、最上位のバイト（オクテット）を先にします。この仕様の本バージョンでは、「padding」または「reserved」（r）として指定されたビットを送信側は0に設定し、受信側は無視しなければなりません (MUST)。特に指定のない数値定数は、10進数（基数10）です。
The format of the default LCT header is depicted in Figure 1.
デフォルトのLCTヘッダー形式を図1に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C |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
The function and length of each field in the default LCT header is the following.
デフォルトのLCTヘッダーに含まれる各フィールドの役割と長さは、次のとおりです。
LCT version number (V): 4 bits
LCT version number (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
Congestion control flag (C): 2ビット
C=0 indicates the Congestion Control Information (CCI) field is 32 bits in length. C=1 indicates the CCI field is 64 bits in length. C=2 indicates the CCI field is 96 bits in length. C=3 indicates the CCI field is 128 bits in length.
C=0はCongestion Control Information（CCI）フィールドの長さが32ビットであることを示します。C=1はCCIフィールドが64ビット、C=2は96ビット、C=3は128ビットであることを示します。
Protocol-Specific Indication (PSI): 2 bits
Protocol-Specific Indication (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ビルディングブロックを使う各プロトコルインスタンス化で個別に定めます。用途が定義されていない場合、送信側はこれらのビットを0に設定しなければなりません (MUST)。受信側はこれらのビットを無視しなければなりません (MUST)。
Transport Session Identifier flag (S): 1 bit
Transport Session Identifier flag (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
Transport Object Identifier flag (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
Half-word flag (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ビットを加えた長さです。これにより、両フィールドの合計長を32ビットの倍数に保ちながら、各フィールドの長さを16ビット（ハーフワード）の倍数にできます。
Reserved (Res): 2 bits
Reserved (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.
このビット列は予約済みです。本仕様のこのバージョンでは、送信側はこれらのビットを0に設定しなければならず (MUST)、受信側は無視しなければなりません (MUST)。
Close Session flag (A): 1 bit
Close Session flag (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に設定します。セッションのパケット送信終了が近づいたとき、送信側はAを1に設定してもかまいません (MAY)。Aは、セッションで送信する最後のパケットだけで1にしてもかまいません (MAY)。または、最後の数秒間に送信するパケットで1にしてもかまいません (MAY)。あるパケットでAを1にした後は、セッションへのパケット送信が終了するまで、後続のすべてのパケットでもAを1にすべきです (SHOULD)。Aが1の受信パケットは、送信側がセッションへのパケット送信を直ちに停止することを受信側に示します。Aが1のパケットを受信した受信側は、セッションにそれ以上パケットが送られないと想定すべきです (SHOULD)。
Close Object flag (B): 1 bit
Close Object flag (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は0に設定します。オブジェクトのパケット送信終了が近づいたとき、送信側はBを1に設定してもかまいません (MAY)。TOIフィールドを使い、Bが1の場合、TOIフィールドで識別されるオブジェクトの送信終了が近いことを示します。TOIフィールドを使わずBが1の場合、帯域外情報で識別されるセッション内の唯一のオブジェクトの送信終了が近いことを示します。Bは、そのオブジェクトについて送信する最後のパケットだけで1にしてもかまいません (MAY)。また、オブジェクトのパケットを送信する最後の数秒間にBを1にしてもかまいません (MAY)。特定のオブジェクトのあるパケットでBを1にした後は、そのオブジェクトのパケット送信が終了するまで、後続のすべてのパケットでもBを1にすべきです (SHOULD)。Bが1の受信パケットは、送信側がそのオブジェクトのパケット送信を直ちに停止することを受信側に示します。Bが1のパケットを受信した受信側は、そのオブジェクトのパケットがセッションにそれ以上送られないと想定すべきです (SHOULD)。
LCT header length (HDR_LEN): 8 bits
LCT header length (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.
LCTヘッダー全体の長さを32ビット語の単位で示します。LCTヘッダーの長さは32ビットの倍数でなければなりません (MUST)。このフィールドを使うと、LCTヘッダーより後のパケット部分へ直接アクセスできます。つまり、後続ヘッダーがあればその先頭へ、後続ヘッダーがなくペイロードがあればその先頭へ、後続ヘッダーもペイロードもなければパケット末尾へアクセスできます。
Codepoint (CP): 8 bits
Codepoint (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].
パケットペイロードのデコーダーに渡す不透明な識別子で、そのペイロードに使われているコーデックの情報を伝えます。Codepointと実際のコーデックの対応はセッションごとに定め、セッション記述情報の一部として帯域外で伝えます。CPフィールドの用途は、[RFC3550]で説明されているRTPヘッダーのPayload Type（PT）フィールドと似ています。
Congestion Control Information (CCI): 32, 64, 96, or 128 bits
Congestion Control Information (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ビットでなければなりません (MUST)。
This field MUST be 64 bits if C=1.
C=1の場合、このフィールドは64ビットでなければなりません (MUST)。
This field MUST be 96 bits if C=2.
C=2の場合、このフィールドは96ビットでなければなりません (MUST)。
This field MUST be 128 bits if C=3.
C=3の場合、このフィールドは128ビットでなければなりません (MUST)。
Transport Session Identifier (TSI): 0, 16, 32, or 48 bits
Transport Session Identifier (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を組み合わせるとセッションを一意に識別できます。この組み合わせは常にセッションを一意に識別しますが、TSIをLCTヘッダーに含めるかどうかは、TSI値として何を使うかによって異なります。基盤となるトランスポートがUDPの場合、16ビットのUDP送信元ポート番号をセッションのTSIとして使ってもかまいません (MAY)。TSI値がパケット内に複数回現れる場合、すべて同じ値でなければなりません (MUST)。ネットワーク層、トランスポート層、または他の層からTSIが提供されない場合、TSIをLCTヘッダーに含めなければなりません (MUST)。
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は、セッションが有効な期間中、およびその前後の十分に長い期間にわたり、送信側が提供するすべてのセッションの中で一意でなければなりません (MUST)。TSIの主な目的は、受信側が参加しているセッション以外に属するパケットを、送信側から誤って受け入れないようにすることです。たとえば、あるセッションが停止した後、送信側が別のセッションを開始し、両セッションで一部重複するチャネルを使うとします。この送信側の活動中に最初のセッションへ接続したままの受信側は、両セッションのTSIが同じなら、2番目のセッションのパケットを最初のセッションに属するものとして受け入れる可能性があります。TSIフィールド値とセッションの対応付けは本書の対象範囲外であり、帯域外で行います。
The length of the TSI field is 32*S + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits.
TSIフィールドの長さは32*S + 16*Hビットです。TSIフィールドとTOIフィールドの合計長は32ビットの倍数です。
Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96, or 112 bits.
Transport Object Identifier (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.
このフィールドは、パケットがセッション内のどのオブジェクトに関係するかを示します。たとえば、送信側は同じセッションで複数のファイルを送り、最初のファイルにはTOI=0、2番目にはTOI=1というように割り当てられます。別の例として、TOIは複数の送信側から同時に送信されるオブジェクトの一意なグローバル識別子であり、その値をオブジェクトに適用したハッシュ関数の出力にすることもできます。TOIフィールド値とオブジェクトの対応付けは本書の対象範囲外であり、帯域外で行います。セッションで複数のオブジェクトを送る場合、すべてのパケットでTOIフィールドを使わなければなりません (MUST)。つまり、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.
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 header length（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.
Header Extensionが存在する場合は、輻輳制御を実行する前、またはパケットを受け入れる前に処理し、認識できるようにしなければなりません (MUST)。認識できないHeader Extensionの既定の動作は無視することです。これにより、LCTのバージョン番号を変更せず、将来のバージョンとの後方互換性がある拡張を導入できます。後方互換性のないHeader Extensionは、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.
図2に示すように、Header Extensionフィールドには2つの形式があります。1つ目は可変長拡張用で、Header Extension Type（HET）の値は0～127です。2つ目は固定長（32ビット語1個）の拡張用で、HETの値は127～255です。
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
The explanation of each sub-field is the following:
各サブフィールドを次に説明します。
Header Extension Type (HET): 8 bits
Header Extension Type (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の種類を示します。本書では複数の種類を定義しており、この仕様の将来の版で種類を追加することもできます。HET値0～127は可変長のHeader Extensionに使います。HET値128～255は固定長32ビットのHeader Extensionに使います。
Header Extension Length (HEL): 8 bits
Header Extension Length (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).
Header Extensionフィールド全体の長さを32ビット語の倍数で表します。可変長拡張（HETが0～127）ではこのフィールドを含めなければなりません (MUST)。固定長拡張（HETが128～255）ではこのフィールドを含めてはなりません (MUST NOT)。
Header Extension Content (HEC): variable length
Header Extension Content (HEC): 可変長
The content of the Header Extension. The format of this sub-field depends on the Header Extension Type. For fixed-length Header Extensions, the HEC is 24 bits. For variable-length Header Extensions, the HEC field has variable size, as specified by the HEL field. Note that the length of each Header Extension field MUST be a multiple of 32 bits. Also note that the total size of the LCT header, including all Header Extensions and all optional header fields, cannot exceed 255 32-bit words.
Header Extensionの内容です。このサブフィールドの形式はHeader Extension Typeによって異なります。固定長Header ExtensionではHECは24ビットです。可変長Header Extensionでは、HECフィールドの長さはHELフィールドで指定します。各Header Extensionフィールドの長さは32ビットの倍数でなければなりません (MUST)。また、すべてのHeader Extensionと任意のヘッダーフィールドを含むLCTヘッダー全体は、32ビット語で255個を超えることはできません。
The following LCT Header Extensions are defined by this specification:
本仕様では、次のLCT Header Extensionを定義します。
EXT_NOP, HET=0 No-Operation extension. The information present in this extension field MUST be ignored by receivers.
EXT_NOP、HET=0: No-Operation拡張です。この拡張フィールドに含まれる情報は、受信側が無視しなければなりません (MUST)。
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: パケット認証拡張です。パケット送信側の認証に使う情報を含みます。このHeader Extensionの形式と処理は本書の対象範囲外であり、セッション記述の一部として帯域外で伝えます。
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.
送信側は、何らかのパケット認証方式を提供することが推奨されます (SHOULD)。EXT_AUTHがある場合、パケット受信直後に実施できる認証検査は、パケットを受け入れる前、およびパケットに対する輻輳制御関連の処理を行う前に実施すべきです (SHOULD)。
Some packet authentication schemes impose a delay of several seconds between when a packet is received and when the packet is fully authenticated. Any congestion control related action that is appropriate SHOULD NOT be postponed by any such full packet authentication.
一部のパケット認証方式では、パケットの受信から認証完了までに数秒かかります。適切な輻輳制御関連の処理を、そのような完全なパケット認証のために遅らせるべきではありません (SHOULD NOT)。
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: 時刻拡張です。この拡張は複数種類の時刻情報を運びます。本書で定義する汎用の時刻情報には、Sender Current Time（SCT）、Expected Residual Time（ERT）、Sender Last Change（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 Header Extensionをサポートしなければなりません (MUST)。また、EXT_AUTHとEXT_TIMEを認識しなければなりません (MUST)。ただし、それらの内容を解析できる必要はありません。
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.
このセクションでは、一般的な用途の時刻Header Extensionを定義します。このHeader Extensionが運ぶ時刻値は、サーバーの壁時計（wall clock）に基づきます。サーバーはセッション中、一貫した相対時刻を保たなければなりません (MUST)（つまり、クロックドリフトを無視できる程度に小さくします）。一部のアプリケーションでは、Network Time Protocol（NTP）[RFC1305]を使って、1900年1月1日00:00 GMTを基準とする実時刻に合わせるなど、サーバーの壁時計をシステム間または全世界で同期させることが望ましい場合があります。このようなセッション外の同期は本書の対象範囲外です。
The EXT_TIME Header Extension uses the format depicted in Figure 3.
EXT_TIME Header Extensionの形式を図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
The "Use" bit field indicates the semantic of the following 32-bit time value(s).
Useビットフィールドは、後続する32ビットの時刻値の意味を示します。
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.
Useビットフィールドの形式を図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
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.
1つのEXT_TIME Header Extensionに複数の「時刻値」フィールドを含めてもかまいません (MAY)。その場合、各フィールドはUseフィールド内の対応するフラグの位置で指定された順序で並べなければなりません (MUST)。順序は、SCT-High（存在する場合）、SCT-Low（存在する場合）、ERT（存在する場合）、SLC（存在する場合）です。受信側は、サポートしていないEXT_TIME Header Extension内の追加フィールドを無視すべきです (SHOULD)。
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).
Sender Current Time (SCT): SCT-Highフラグ、SCT-Lowフラグ、および対応する時刻値（32ビット語1個または2個）。
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-Highフラグが設定されている場合、対応する32ビット時刻値は、送信側の壁時計の時刻を秒単位で表す符号なし整数です。NTPを使う場合、この32ビット値は1900年1月1日00:00 GMTを基準とする秒数を表す符号なし整数、つまり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-Lowフラグが設定されている場合、対応する32ビット時刻値は、1秒を1/2^^32ずつに分割した単位の整数倍を表す符号なし整数です。これにより、1秒未満の精度を表せます。SCT-Lowフラグが設定されている場合は、SCT-Highフラグも設定しなければなりません (MUST)。NTPを使う場合、この32ビット値は64ビットNTPタイムスタンプの下位32ビットです。
Expected Residual Time (ERT): ERT flag, corresponding 32-bit time value.
Expected Residual Time (ERT): ERTフラグと、対応する32ビット時刻値。
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.
Session Last Changed (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.
Session Last Changedの時刻値は、セッションデータが最後に変更された時点のサーバーの壁時計時刻を秒単位で表します。つまり、配信セッションでTransport Objectが最後に追加、変更、または削除された時刻です。オブジェクトの変更や追加の場合、この時刻より前には伝送されていなかった新しいデータが伝送されることを示します。削除の場合、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ビット値は1900年1月1日00:00 GMTを基準とする秒数を表す符号なし整数、つまり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 Header ExtensionのパケットにSCT-High情報も含めるのが適切です。
Reserved by LCT for future use (4 bits):
LCTが将来のために予約しているフィールド（4ビット）：
In this version of the specification, these bits MUST be set to zero by senders and MUST be ignored by receivers.
本仕様のこのバージョンでは、送信側はこれらのビットを0に設定しなければならず (MUST)、受信側は無視しなければなりません (MUST)。
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が用途を定義していないビットは、0に設定すべきです (SHOULD)。
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).
このHeader Extensionは可変長であるため、EXT_TIME全体の長さはHELで示します。これにより、クライアントはEXT_TIMEを認識していても内容をサポートしない場合に、拡張全体を読み飛ばせます。
Before joining an LCT session, a receiver MUST obtain a session description. The session description MUST include:
LCTセッションに参加する前に、受信側はセッション記述を取得しなければなりません (MUST)。セッション記述には、次の情報を含めなければなりません (MUST)。
o The sender IP address;
o 送信側のIPアドレス。
o The number of LCT channels;
o LCTチャネルの数。
o The addresses and port numbers used for each LCT channel;
o 各LCTチャネルに使うアドレスとポート番号。
o The Transport Session ID (TSI) to be used for the session;
o セッションで使用するTransport Session ID（TSI）。
o Enough information to determine the congestion control protocol being used;
o 使用する輻輳制御プロトコルを特定するための十分な情報。
o Enough information to determine the packet authentication scheme being used (if 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;
o 各LCTチャネルで使うデータレート。
o The length of the packet payload;
o パケットペイロードの長さ。
o The mapping of TOI value(s) to objects for the session;
o セッション内のオブジェクトとTOI値との対応付け。
o Any information that is relevant to each object being transported, such as when it will be available within the session, for how long, and the length of the object;
o セッション内で利用可能になる時期や期間、オブジェクトの長さなど、伝送する各オブジェクトに関係する情報。
Protocol instantiations using LCT MAY place additional requirements on what must be included in the session description. For example, a protocol instantiation might require that the data rates for each channel, or the mapping of TOI value(s) to objects for the session, or other information related to other headers that might be required be included in the session description.
LCTを使うプロトコルインスタンス化では、セッション記述に含める情報について追加要件を定めてもかまいません (MAY)。たとえば、各チャネルのデータレート、セッション内のオブジェクトとTOI値との対応付け、または必要となる他のヘッダーに関係する情報をセッション記述に含めるよう、プロトコルインスタンス化で求めることがあります。
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.
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で識別しなければなりません (MUST)。オブジェクトは順次伝送してもかまいません (MAY)。同時に伝送してもかまいません (MAY)。セッションの該当部分に参加する受信側がすべてのオブジェクトを受信したい場合に限って、同じセッション内でオブジェクトを同時に送るのが望ましい方法です。関心のないオブジェクトのデータまで受信側に受け取らせると、帯域幅とネットワーク資源を浪費するためです。
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.
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に挙げた関連するセッション記述情報を取得しなければなりません (MUST)。
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に従って使用すべきです (SHOULD)。セッションの受信側になるには、LCTヘッダーを処理できなければなりません (MUST)。さらに、他のヘッダーとパケットペイロードを破棄、転送、保存、または処理できなければなりません (MUST)。LCTヘッダーを処理できない場合、受信側はセッションから離脱しなければなりません (MUST)。
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ヘッダーのCongestion Control Informationフィールドを使い、セッション記述で指定された輻輳制御プロトコルを実装しなければなりません (MUST)。セッションで使う輻輳制御プロトコルを実装できない場合、受信側はセッションに参加してはなりません (MUST NOT)。セッションが複数のLCTチャネルで伝送される場合、受信側は輻輳制御プロトコルで規定された起動時の動作に従って、最初にチャネルへ参加しなければなりません (MUST)。複数チャネルを使う複数レートの輻輳制御プロトコルでは、通常、受信側は最小限のLCTチャネル群（場合によっては1つだけ）に参加します。これらのチャネルが運ぶパケットの合計レートは低くなります。この規則は、受信側が高いデータレートで受信を始めるのを防ぐためのものです。
Several objects can be carried either sequentially or concurrently within the same LCT session. In this case, each object is identified by a unique TOI. Note that even if a server stops sending packets for an old object before starting to transmit packets for a new object, both the network and the underlying protocol layers can cause some reordering of packets, especially when sent over different LCT channels, and thus receivers SHOULD NOT assume that the reception of a packet for a new object means that there are no more packets in transit for the previous one, at least for some amount of time.
同じLCTセッション内で複数のオブジェクトを順次または同時に伝送できます。この場合、各オブジェクトは一意なTOIで識別します。サーバーが新しいオブジェクトのパケット送信を始める前に古いオブジェクトの送信を停止していても、ネットワークや下位プロトコル層によって、特に異なるLCTチャネルで送ったパケットの順序が入れ替わることがあります。そのため、新しいオブジェクトのパケットを受信したからといって、少なくともしばらくの間は、前のオブジェクトのパケットがすべて到着済みだと想定すべきではありません (SHOULD NOT)。
A receiver MAY be concurrently joined to multiple LCT sessions from one or more senders. The receiver MUST perform congestion control on each such LCT session. If the congestion control protocol allows the receiver some flexibility in terms of its actions within a session, then the receiver MAY make choices to optimize the packet flow performance across the multiple LCT sessions, as long as the receiver still adheres to the congestion control rules for each LCT session individually.
受信側は、1つ以上の送信側から複数のLCTセッションに同時に参加してもかまいません (MAY)。受信側は各LCTセッションで輻輳制御を実行しなければなりません (MUST)。輻輳制御プロトコルがセッション内の動作にある程度の柔軟性を認める場合、各セッションの輻輳制御規則を個別に守る限り、受信側は複数セッション全体のパケットフロー性能を最適化する選択をしてもかまいません (MAY)。
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 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.
[RFC3048]に記載されているように、LCTは、プロトコルインスタンス化の規定を支援するため、他のビルディングブロックと組み合わせて使うことを想定したビルディングブロックです。LCTを使うプロトコルインスタンス化は、LCTヘッダー内のCongestion Control Informationフィールドを利用する輻輳制御ビルディングブロックを使わなければなりません (MUST)。信頼性ビルディングブロックなど、他のビルディングブロックも使ってかまいません (MAY)。
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セッション全体に対して適用しなければなりません (MUST)。LCTヘッダーのCongestion Control Informationフィールドは、輻輳制御に関する情報を運ぶための不透明なフィールドです。輻輳制御に関する追加情報を運ぶHeader Extensionフィールドを設けてもかまいません (MAY)。
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.
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.
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の実装者は、攻撃からプロトコルを保護するため、何らかのパケット認証方式を使うことが推奨されます (SHOULD)。適用できる可能性のある方式の例は[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を使うプロトコルインスタンス化の中には、受信側から送信側へのフィードバック生成を必要とするビルディングブロックを使ってもよいものがあります (MAY)。ただし、そのための仕組みは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ビルディングブロックを使うプロトコルインスタンス化は、以下の各セクションで説明する潜在的な脆弱性に対処しなければなりません (MUST)。例は[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.
正しく動作するために、LCTはセッション記述情報が利用できることを前提とします（セクション4および7を参照）。誤った、または悪意を持って変更されたセッション記述情報により、受信側がセッションの内容を正しく受信できなくなることがあります。また、受信側が自身の能力を大幅に上回るレートで誤って受信しようとし、ネットワークの一部でトラフィックを妨げることもあります。プロトコルインスタンス化は、たとえばセッション記述に送信元認証と完全性検証の仕組みを設けるなどして、この潜在的な脆弱性に対処しなければなりません (MUST)。さらに、これらの仕組みは、受信側がセッション記述とLCTデータパケットの対応関係を安全に検証できるようにしなければなりません (MUST)。
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ヘッダーのTransport Session IdentifierとTransport Object Identifierは、セッションとオブジェクトの多重化に使います。攻撃者がこれらのフィールドを変更すると、セッションやオブジェクトがデータを受け取れなくなったり、誤ったデータが別のセッションやオブジェクトに送られたりする可能性があり、いずれもサービス拒否攻撃につながります。
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値を使った偽造パケットを注入すると、受信側が追加のセッションやオブジェクト用にリソースを割り当てることになり、サービス拒否攻撃につながる可能性があります。
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ヘッダーのClose ObjectビットとClose Sessionビットは、オブジェクトまたはセッションの終了を通知します。攻撃者がこれらのフィールドを変更すると、受信側がセッションやオブジェクトは終了したと誤認して動作し、サービス拒否攻撃につながる可能性があります。逆に、終了後も受信側が不要なリソースを使い続けることもあります（ただし、この場合のリソース使用は主に実装上の問題です）。
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).
以上の脆弱性があるため、プロトコルインスタンス化のセキュリティ機構（たとえば送信元認証やデータ完全性の機構）で、これらのフィールドを保護しなければなりません (MUST)。
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情報を送ってクライアント間の時刻同期を簡単に崩せます。また、セッション（または特定のオブジェクト）がまもなく終了すると全クライアントに誤って通知し、サービス拒否攻撃を仕掛けることもできます。
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).
以上の脆弱性があるため、プロトコルインスタンス化のセキュリティ機構（たとえば送信元認証やデータ完全性の機構）で、これらのフィールドを保護しなければなりません (MUST)。
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フィールド、輻輳制御ビルディングブロック向けのCongestion Controlフィールド、FECビルディングブロック向けのCodepointフィールド、プロトコルインスタンス化が使うEXT-AUTH Header Extension、およびパケットペイロード自体です。
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.
攻撃者がこれらのフィールドのいずれかを変更すると、サービス拒否攻撃につながる可能性があります。特にCodepointやパケットペイロードを変更すると、オブジェクトを復元できなくなったり、受信側がオブジェクトの大部分を誤って復元したりする可能性があります。Congestion Controlフィールドを変更すると、受信側が誤ったレートで受信しようとし、輻輳を悪化または発生させて、サービス拒否攻撃につながる可能性があります。
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).
以上の脆弱性があるため、プロトコルインスタンス化のセキュリティ機構（たとえば送信元認証やデータ完全性の機構）で、これらのフィールドを保護しなければなりません (MUST)。
This document defines a new namespace for "LCT Header Extension Types". Values in this namespace are integers between 0 and 255 (inclusive).
本書は「LCT Header Extension Types」の新しい名前空間を定義します。この名前空間の値は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].
0～63（両端を含む）の値は可変長LCT Header Extension用に予約されています。割り当ては[RFC5226]で定義された「IETF Review」を通じて行います。
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 Header Extension用に予約されています。割り当ては[RFC5226]で定義された「Specification Required」の方式で行います。
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（両端を含む）の値は固定長LCT Header Extension用に予約されています。割り当ては[RFC5226]で定義された「IETF Review」を通じて行います。
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 Header Extension用に予約されています。割り当ては[RFC5226]で定義された「Specification Required」の方式で行います。
Initial values for the LCT Header Extension Type registry are defined in Section 9.2.
LCT Header Extension Typeレジストリの初期値は、セクション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.
本仕様の旧Experimental版では、範囲[64, 127]および[192, 255]の値をPI固有のLCT Header Extension用に予約していました。簡素化のため、またPI間でこれらのLCT Header Extension Type値の割り当てが重複していなかったため、本書ではLCT Header Extension Typeに単一のフラットな名前空間を定めます。
This document registers three values in the LCT Header Extension Type namespace as follows:
本書では、LCT Header Extension Typeの名前空間に次の3つの値を登録します。
+-------+----------+--------------------+
| 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, 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.
本仕様はRFC 3451 [RFC3451]に大きく基づいているため、本書の執筆に関する主な功績はRFC 3451の著者、Mike Luby、Jim Gemmel、Lorenzo Vicisano、Luigi Rizzo、Mark Handley、Jon Crowcroftにあります。Bruce Lueckenhoff、Hayder Radha、Justin ChapweskeもRFC 3451に貢献しました。また、本仕様をProposed Standardに更新するにあたり貢献したVincent Roca、Rod Walsh、Toni Pailaにも感謝します。
This section summarizes the changes that were made from the Experimental version of this specification published as RFC 3451 [RFC3451]:
このセクションでは、RFC 3451 [RFC3451]として公開された本仕様のExperimental版からの変更点をまとめます。
o Removed the 'Statement of Intent' from the introduction. (The statement of intent was meant to clarify the "Experimental" status of RFC 3451.)
o はじめにあった「Statement of Intent」を削除しました（この記述はRFC 3451の「Experimental」という位置付けを明確にするためのものでした）。
o Inclusion of material from ALC that is applicable in the more general LCT context.
o より一般的なLCTの文脈に適用できるALCの内容を追加しました。
o Creation of an IANA registry for LCT Header Extensions.
o LCT Header Extensionの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ビットを「Protocol-Specific Indication」に割り当てました。用途はプロトコルインスタンス化ごとに定義します。
o Removal of the Sender Current Time and Expected Residual Time LCT header fields.
o Sender Current TimeおよびExpected Residual TimeのLCTヘッダーフィールドを削除しました。
o Inclusion of a new Header Extension, EXT_TIME, to replace the SCT and ERT and provide for future extension of timing capabilities.
o SCTとERTを置き換え、時刻情報の機能を将来拡張できるよう、新しいHeader ExtensionであるEXT_TIMEを追加しました。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[ALC-PI] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", Work in Progress, September 2009.
[ALC-PI] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", Work in Progress, September 2009.
[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] 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.
[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] 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.
[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., Schooler, E., and J. Gray, "Fcast Multicast File Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.
[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., 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.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[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] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[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., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[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. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[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] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[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] 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.
[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., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[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., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, April 1997.
[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. 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.
[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: A TCP-friendly single-rate multicast congestion control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August 2000.
[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., Rizzo, L., and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", IEEE Infocom'98, San Francisco, CA, March 1998.
Authors' Addresses
著者の連絡先
Michael Luby Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
Michael Luby Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
EMail: luby@qualcomm.com
Mark Watson Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
Mark Watson Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
EMail: watson@qualcomm.com
Lorenzo Vicisano Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
Lorenzo Vicisano Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
EMail: vicisano@qualcomm.com