[要約] RFC 5651は、Layered Coding Transport（LCT）ビルディングブロックに関する標準化ドキュメントです。LCTは、エラー訂正やフロー制御などの機能を提供し、信頼性の高いデータ転送を実現するために設計されています。
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マルチキャストを使用してプロトコルをサポートするように特別に設計されていますが、Unicastを使用するプロトコルのサポートも提供します。LCTは、受信機に複数のレート配信を提供する混雑制御と互換性があり、コンテンツの信頼できる配信を提供するコーディング技術とも互換性があります。このドキュメントは、RFC 3451を廃止します。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。
Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Rationale .......................................................3
3. Functionality ...................................................4
4. Applicability ...................................................7
4.1. Environmental Requirements and Considerations ..............9
4.2. Delivery Service Models ...................................10
4.3. Congestion Control ........................................13
5. Packet Header Fields ...........................................13
5.1. LCT Header Format .........................................13
5.2. Header-Extension Fields ...................................18
5.2.1. General ............................................18
5.2.2. EXT_TIME Header Extension ..........................20
6. Operations .....................................................23
6.1. Sender Operation ..........................................23
6.2. Receiver Operation ........................................25
7. Requirements from Other Building Blocks ........................26
8. Security Considerations ........................................28
8.1. Session and Object Multiplexing and Termination ...........28
8.2. Time Synchronization ......................................29
8.3. Data Transport ............................................29
9. IANA Considerations ............................................29
9.1. Namespace Declaration for LCT Header Extension Types ......29
9.2. LCT Header Extension Type Registration ....................30
10. Acknowledgments ...............................................30
11. Changes from RFC 3451 .........................................31
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. Layered Coding Transport is specifically designed to support protocols using IP multicast, but it also provides support to protocols that use unicast. Layered Coding Transport is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.
レイヤードコーディングトランスポート（LCT）は、信頼できるコンテンツ配信およびストリーム配信プロトコルのトランスポートレベルサポートを提供します。レイヤードコーディングトランスポートは、IPマルチキャストを使用してプロトコルをサポートするように特別に設計されていますが、Unicastを使用するプロトコルへのサポートも提供します。レイヤードコーディングトランスポートは、受信機に複数のレート配信を提供する混雑制御と互換性があり、コンテンツの信頼できる配信を提供するコーディング技術とも互換性があります。
This document describes a building block as defined in [RFC3048]. This document is a product of the IETF RMT WG and follows the general guidelines provided in [RFC3269].
このドキュメントでは、[RFC3048]で定義されているビルディングブロックについて説明しています。このドキュメントは、IETF RMT WGの製品であり、[RFC3269]で提供される一般的なガイドラインに従います。
[RFC3451], which was published in the "Experimental" category and which is obsoleted by this document, contained a previous version of the protocol.
[RFC3451]は、「実験的」カテゴリで公開され、このドキュメントで廃止されたプロトコルの以前のバージョンが含まれていました。
This Proposed Standard specification is thus based on and backwards compatible with the protocol defined in [RFC3451] updated according to accumulated experience and growing protocol maturity since its original publication. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
したがって、この提案された標準仕様は、元の出版物以降、累積経験とプロトコルの成長の成長に従って更新された[RFC3451]で定義されたプロトコルと互換性があることに基づいて互換性があります。上記の経験は、この仕様自体と、この仕様の使用に関連する混雑制御戦略の両方に適用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
LCT provides transport level support for massively scalable protocols using the IP multicast network service. The support that LCT provides is common to a variety of very important applications, including reliable content delivery and streaming applications.
LCTは、IPマルチキャストネットワークサービスを使用して、大規模なスケーラブルプロトコルのトランスポートレベルサポートを提供します。LCTが提供するサポートは、信頼できるコンテンツ配信やストリーミングアプリケーションなど、さまざまな非常に重要なアプリケーションに共通しています。
An LCT session comprises multiple channels originating at a single sender that are used for some period of time to carry packets pertaining to the transmission of one or more objects that can be of interest to receivers. The logic behind defining a session as originating from a single sender is that this is the right granularity to regulate packet traffic via congestion control. One rationale for using multiple channels within the same session is that there are massively scalable congestion control protocols that use multiple channels per session. These congestion control protocols are considered to be layered because a receiver joins and leaves channels in a layered order during its participation in the session.
LCTセッションは、レシーバーにとって興味深い1つ以上のオブジェクトの送信に関連するパケットを運ぶために、ある期間使用される単一の送信者を発信する複数のチャネルで構成されています。単一の送信者からのセッションを定義する背後にあるロジックは、これが混雑制御を介してパケットトラフィックを調節するための適切な粒度であるということです。同じセッション内で複数のチャネルを使用するための1つの根拠は、セッションごとに複数のチャネルを使用する非常にスケーラブルな混雑制御プロトコルがあることです。これらの混雑制御プロトコルは、セッションへの参加中にレシーバーが結合し、階層化された順序でチャネルを去るため、階層化されていると見なされます。
The use of layered channels is also useful for streaming applications.
階層化されたチャネルの使用は、アプリケーションのストリーミングにも役立ちます。
There are coding techniques that provide massively scalable reliability and asynchronous delivery that are compatible with both layered congestion control and with LCT. When all are combined, the result is a massively scalable reliable asynchronous content delivery protocol that is network friendly. LCT also provides functionality that can be used for other applications as well, e.g., layered streaming applications.
層状の混雑制御とLCTの両方と互換性のある非常にスケーラブルな信頼性と非同期送達を提供するコーディング手法があります。すべてが組み合わされると、結果は、ネットワークに優しい非常にスケーラブルな信頼性のない非同期コンテンツ配信プロトコルになります。LCTは、他のアプリケーションにも使用できる機能を提供します。たとえば、層状ストリーミングアプリケーション。
LCT avoids providing functionality that is not massively scalable. For example, LCT does not provide any mechanisms for sending information from receivers to senders, although this does not rule out protocols that both use LCT and do require sending information from receivers to senders.
LCTは、大きくスケーラブルではない機能を提供することを避けます。たとえば、LCTは受信者から送信者に情報を送信するためのメカニズムを提供しませんが、これはLCTを使用し、受信者から送信者に情報を送信する必要があるプロトコルを除外していません。
LCT includes general support for congestion control that must be used. It does not, however, specify which congestion control should be used. The rationale for this is that congestion control must be provided by any protocol that is network friendly, and yet the different applications that can use LCT will not have the same requirements for congestion control. For example, a content delivery protocol may strive to use all available bandwidth between receivers and the sender. It must, therefore, drastically back off its rate when there is competing traffic. On the other hand, a streaming delivery protocol may strive to maintain a constant rate instead of trying to use all available bandwidth, and it may not back off its rate as fast when there is competing traffic.
LCTには、使用する必要がある混雑制御に対する一般的なサポートが含まれています。ただし、どの輻輳制御を使用すべきかを指定しません。これの理論的根拠は、ネットワークに優しいプロトコルによって混雑制御を提供する必要があるが、LCTを使用できるさまざまなアプリケーションは、混雑制御のために同じ要件を持たないということです。たとえば、コンテンツ配信プロトコルは、受信機と送信者の間で利用可能なすべての帯域幅を使用するよう努めている場合があります。したがって、競合するトラフィックがある場合、レートを大幅に削減する必要があります。一方、ストリーミング配信プロトコルは、利用可能なすべての帯域幅を使用しようとするのではなく、一定の速度を維持するよう努めている可能性があり、競合するトラフィックがある場合、そのレートを速く後退させない場合があります。
Beyond support for congestion control, LCT provides a number of fields and supports functionality commonly required by many protocols. For example, LCT provides a Transmission Session ID that can be used to identify to which session each received packet belongs. This is important because a receiver may be joined to many sessions concurrently, and thus it is very useful to be able to demultiplex packets as they arrive according to the session to which they belong. As another example, there are optional fields within the LCT packet header for identifying the object about which information is carried in the packet payload.
混雑制御のサポートを超えて、LCTは多くのフィールドを提供し、多くのプロトコルで一般的に必要な機能をサポートしています。たとえば、LCTは、受信した各パケットが属するセッションを識別するために使用できる送信セッションIDを提供します。これは、受信者が同時に多くのセッションに結合される可能性があるため、これは重要です。したがって、属するセッションに応じて到着するにつれてパケットが到着するにつれてパケットを非難することができることは非常に便利です。別の例として、LCTパケットヘッダー内には、パケットペイロードにどの情報が送られているかについてオブジェクトを識別するためのオプションのフィールドがあります。
An LCT session consists of a set of logically grouped LCT channels associated with a single sender carrying packets with LCT headers for one or more objects. An LCT channel is defined by the combination of a sender and an address associated with the channel by the sender. A receiver joins a channel to start receiving the data packets sent to the channel by the sender, and a receiver leaves a channel to stop receiving data packets from the channel.
LCTセッションは、1つ以上のオブジェクトのLCTヘッダーを備えた単一の送信者を運ぶ単一の送信者に関連付けられた一連の論理的にグループ化されたLCTチャネルで構成されています。LCTチャネルは、送信者の組み合わせと、送信者によるチャネルに関連付けられたアドレスの組み合わせによって定義されます。レシーバーがチャネルに結合して、送信者からチャンネルに送信されたデータパケットの受信を開始し、レシーバーがチャネルを離れてチャネルからデータパケットの受信を停止します。
LCT is meant to be combined with other building blocks so that the resulting overall protocol is massively scalable. Scalability refers to the behavior of the protocol in relation to the number of receivers and network paths, their heterogeneity, and the ability to accommodate dynamically variable sets of receivers. Scalability limitations can come from memory or processing requirements, or from the amount of feedback control and redundant data packet traffic generated by the protocol. In turn, such limitations may be a consequence of the features that a complete reliable content delivery or stream delivery protocol is expected to provide.
LCTは、他のビルディングブロックと組み合わせることを目的としているため、結果の全体的なプロトコルが非常にスケーラブルになります。スケーラビリティとは、受信機とネットワークパスの数、それらの不均一性、および動的に変動する受信機セットに対応する能力に関連するプロトコルの動作を指します。スケーラビリティの制限は、メモリまたは処理要件、またはプロトコルによって生成されたフィードバック制御の量と冗長データパケットトラフィックから生じる可能性があります。次に、そのような制限は、完全に信頼できるコンテンツ配信またはストリーム配信プロトコルが提供することが期待される機能の結果である可能性があります。
The LCT header provides a number of fields that are useful for conveying in-band session information to receivers. One of the required fields is the Transmission Session ID (TSI), which allows the receiver of a session to uniquely identify received packets as part of the session. Another required field is the Congestion Control Information (CCI), which allows the receiver to perform the required congestion control on the packets received within the session. Other LCT fields provide optional but often very useful additional information for the session. For example, the Transport Object Identifier (TOI) identifies for which object the packet contains data and flags are included for indicating the close of the session and the close of sending packets for an object. Header extensions can carry additional fields that, for example, can be used for packet authentication or to convey various kinds of timing information: the Sender Current Time (SCT) conveys the time when the packet was sent from the sender to the receiver, the Expected Residual Time (ERT) conveys the amount of time the session or transmission object will be continued for, and Session Last Change (SLC) conveys the time when objects have been added, modified, or removed from the session.
LCTヘッダーは、帯域内のセッション情報を受信機に伝えるのに役立つ多くのフィールドを提供します。必要なフィールドの1つは、送信セッションID（TSI）です。これにより、セッションの受信者がセッションの一部として受信パケットを一意に識別できます。もう1つの必要なフィールドは、渋滞制御情報（CCI）です。これにより、受信機はセッション内で受信したパケットで必要な渋滞制御を実行できます。他のLCTフィールドは、オプションであるが、多くの場合、セッションに非常に有用な追加情報を提供します。たとえば、トランスポートオブジェクト識別子（TOI）は、オブジェクトにデータが含まれているオブジェクトとフラグが含まれている識別と、セッションの終了とオブジェクトの送信パケットの終了を示すために含まれています。ヘッダー拡張機能は、たとえばパケット認証やさまざまな種類のタイミング情報を伝えるために使用できる追加のフィールドを運ぶことができます。残留時間（ERT）は、セッションまたは送信オブジェクトの継続時間を伝え、セッション最後の変更（SLC）は、セッションからオブジェクトが追加、変更、または削除された時間を伝えます。
LCT provides support for congestion control. Congestion control MUST be used that conforms to [RFC2357] between receivers and the sender for each LCT session. Congestion control refers to the ability to adapt throughput to the available bandwidth on the path from the sender to a receiver, and to share bandwidth fairly with competing flows such as TCP. Thus, the total flow of packets flowing to each receiver participating in an LCT session MUST NOT compete unfairly with existing flow-adaptive protocols such as TCP.
LCTは、混雑制御のサポートを提供します。各LCTセッションの受信機と送信者の間の[RFC2357]に適合する混雑制御を使用する必要があります。輻輳制御とは、送信者から受信機へのパス上の利用可能な帯域幅にスループットを適応させ、TCPなどの競合するフローと帯域幅を公正に共有する能力を指します。したがって、LCTセッションに参加する各受信機に流れるパケットの総流量は、TCPなどの既存のフロー適応プロトコルと不当に競合してはなりません。
A multiple rate or a single rate congestion control protocol can be used with LCT. For multiple rate protocols, a session typically consists of more than one channel, and the sender sends packets to the channels in the session at rates that do not depend on the receivers. Each receiver adjusts its reception rate during its participation in the session by joining and leaving channels dynamically depending on the available bandwidth to the sender independent of all other receivers. Thus, for multiple rate protocols, the reception rate of each receiver may vary dynamically independent of the other receivers.
LCTで複数のレートまたは単一レートの混雑制御プロトコルを使用できます。複数のレートプロトコルの場合、セッションは通常複数のチャネルで構成され、送信者は受信機に依存しないレートでセッション内のチャネルにパケットを送信します。各レシーバーは、他のすべてのレシーバーとは無関係に、利用可能な帯域幅に応じて、チャネルに動的にチャンネルに参加および離れることにより、セッションへの参加中に受信率を調整します。したがって、複数のレートプロトコルの場合、各レシーバーの受信率は、他の受信機から動的に異なる場合があります。
For single rate protocols, a session typically consists of one channel and the sender sends packets to the channel at variable rates over time depending on feedback from receivers. Each receiver remains joined to the channel during its participation in the session. Thus, for single rate protocols, the reception rate of each receiver may vary dynamically but in coordination with all receivers.
単一レートプロトコルの場合、セッションは通常1つのチャネルで構成され、送信者はレシーバーからのフィードバックに応じて、時間の経過とともに変動レートでパケットをチャネルに送信します。各レシーバーは、セッションへの参加中にチャンネルに結合されたままです。したがって、単一レートプロトコルの場合、各受信機の受信率は動的に異なる場合がありますが、すべての受信機と協調しています。
Generally, a multiple rate protocol is preferable to a single rate protocol in a heterogeneous receiver environment, since generally it more easily achieves scalability to many receivers and provides higher throughput to each individual receiver. Use of the multiple rate congestion control scheme defined in [RFC3738] is RECOMMENDED. Alternative multiple rate congestion control protocols are described in [VIC1998] and [BYE2000]. A possible single rate congestion control protocol is described in [RIZ2000].
一般に、複数のレートプロトコルは、不均一なレシーバー環境の単一レートプロトコルよりも好ましいです。これは、一般に多くのレシーバーにとってより簡単にスケーラビリティを実現し、個々のレシーバーにより高いスループットを提供するためです。[RFC3738]で定義されている複数のレートの混雑制御スキームの使用が推奨されます。代替の複数レートの輻輳制御プロトコルは、[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マルチキャストを使用して信頼できるコンテンツ配信をスケーリングする際の重要な困難の2つは、受信者から送信者に戻るデータの量と、送信者からの関連する応答（一般的にデータ再送信）を扱うことです。そのようなフィードバックを回避し、再送信の量を最小化するプロトコルは、非常にスケーラブルになる可能性があります。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フレームワークと他のコンポーネントを組み合わせることにより、構築できます。LCTを使用する完全なプロトコルインスタンス化には、LCTと互換性があり、[RFC2357]に適合する輻輳制御プロトコルを含める必要があります。LCTを使用する完全なプロトコルインスタンス化には、LCTと互換性のあるスケーラブルな信頼性プロトコルが含まれる場合があり、LCTと互換性のあるセッション制御プロトコルが含まれ、セキュリティプロトコルなどの他のプロトコルが含まれる場合があります。
An LCT session comprises a logically related set of one or more LCT channels originating at a single sender. The channels are used for some period of time to carry packets containing LCT headers, and these headers pertain to the transmission of one or more objects that can be of interest to receivers.
LCTセッションは、単一の送信者から発信される1つ以上のLCTチャネルの論理的に関連するセットで構成されています。チャネルは、LCTヘッダーを含むパケットを運ぶために一定期間使用され、これらのヘッダーはレシーバーにとって興味深い1つ以上のオブジェクトの送信に関係しています。
LCT is most applicable for delivery of objects or streams in a session of substantial length, i.e., objects or streams that range in aggregate length from hundreds of kilobytes to many gigabytes, and where the duration of the session is on the order of tens of seconds or more.
LCTは、実質的な長さのセッションでのオブジェクトまたはストリームの配信に最も適用できます。つまり、数百キロバイトから多くのギガバイトに至るまでの総長さの範囲のオブジェクトまたはストリーム、およびセッションの期間は数秒の順序です以上。
As an example, an LCT session could be used to deliver a TV program using three LCT channels. Receiving packets from the first LCT channel could allow black and white reception. Receiving the first two LCT channels could also permit color reception. Receiving all three channels could allow HDTV quality reception. Objects in this example could correspond to individual TV programs being transmitted.
例として、LCTセッションを使用して、3つのLCTチャネルを使用してテレビ番組を提供できます。最初のLCTチャネルからパケットを受信すると、白黒レセプションが可能になります。最初の2つのLCTチャネルを受信すると、カラーレセプションが可能になります。3つのチャネルすべてを受信すると、HDTV品質の受信が可能になります。この例のオブジェクトは、送信される個々のテレビ番組に対応できます。
As another example, a reliable LCT session could be used to reliably deliver hourly updated weather maps (objects) using ten LCT channels at different rates, using FEC coding. A receiver may join and concurrently receive packets from subsets of these channels, until it has enough packets in total to recover the object, then leave the session (or remain connected listening for session description information only) until it is time to receive the next object. In this case, the quality metric is the time required to receive each object.
別の例として、信頼性の高いLCTセッションを使用して、FECコーディングを使用して、10のLCTチャネルを使用して10のLCTチャネルを使用して1時間ごとの更新された天気マップ（オブジェクト）を確実に配信できます。受信者は、これらのチャネルのサブセットから合計で十分なパケットがあるまでパケットを合わせて受け取ることができます。。この場合、品質メトリックは各オブジェクトを受信するのに必要な時間です。
Before joining a session, the receivers must obtain enough of the session description to start the session. This 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.
セッションに参加する前に、受信機はセッションを開始するために十分なセッションの説明を取得する必要があります。これには、メッキcontrolに関連するすべての情報を含め、セッションに参加するために受信者が必要とする関連セッションパラメーターが含まれます。セッションの説明は送信者によって決定され、通常、帯域外のレシーバーに通信されます。場合によっては、後で説明したように、セッションを開始するために必要ではないセッション説明の一部をLCTヘッダーに含めるか、受信者がセッションに参加した後にレシーバー外の帯域外に通信することがあります。
An encoder MAY be used to generate the data that is placed in the packet payload in order to provide reliability. A suitable decoder is used to reproduce the original information from the packet payload. There MAY be a reliability header that follows the LCT header if such an encoder and decoder is used. The reliability header helps to describe the encoding data carried in the payload of the packet. The format of the reliability header depends on the coding used, and this is negotiated out-of-band. As an example, one of the FEC headers described in [RFC5052] could be used.
エンコーダーを使用して、信頼性を提供するためにパケットペイロードに配置されたデータを生成することができます。適切なデコーダーを使用して、パケットペイロードから元の情報を再現します。そのようなエンコーダーとデコーダーを使用する場合、LCTヘッダーに続く信頼性ヘッダーがある場合があります。信頼性ヘッダーは、パケットのペイロードにあるエンコードデータを説明するのに役立ちます。信頼性ヘッダーの形式は、使用されるコーディングに依存し、これは帯域外で交渉されます。例として、[RFC5052]で説明されているFECヘッダーの1つを使用できます。
For LCT, when multiple rate congestion control is used, congestion control is achieved by sending packets associated with a given session to several LCT channels. Individual receivers dynamically join one or more of these channels, according to the network congestion as seen by the receiver. LCT headers include an opaque field that MUST be used to convey congestion control information to the receivers. The actual congestion control scheme to use with LCT is negotiated out-of-band. Some examples of congestion control protocols that may be suitable for content delivery are described in [VIC1998], [BYE2000], and [RFC3738]. Other congestion controls may be suitable when LCT is used for a streaming application.
LCTの場合、複数のレートの混雑制御を使用すると、特定のセッションに関連付けられたパケットをいくつかのLCTチャネルに送信することにより、うっ血制御が達成されます。レシーバーが見たネットワークの混雑によると、個々のレシーバーはこれらのチャネルの1つ以上を動的に結合します。LCTヘッダーには、混雑制御情報を受信機に伝えるために使用する必要がある不透明フィールドが含まれています。LCTで使用する実際の混雑制御スキームは、帯域外で交渉されます。コンテンツの配信に適している可能性のある混雑制御プロトコルの例は、[VIC1998]、[BYE2000]、および[RFC3738]で説明されています。LCTがストリーミングアプリケーションに使用される場合、他の混雑コントロールが適している場合があります。
This document does not specify and restrict the type of exchanges between LCT (or any protocol instantiation built on top of LCT) and an upper application. Some upper APIs may use an object-oriented approach, where the only possible unit of data exchanged between LCT (or any protocol instantiation built on top of LCT) and an application, either at a source or at a receiver, is an object. Other APIs may enable a sending or receiving application to exchange a subset of an object with LCT (or any PI built on top of LCT), or may even follow a streaming model. These considerations are outside the scope of this document.
このドキュメントでは、LCT（またはLCTの上に構築されたプロトコルインスタンス化）と上部アプリケーションの間の交換の種類を指定および制限しません。一部のアッパーAPIは、LCT（またはLCTの上に構築されたプロトコルインスタンス化）とソースまたはレシーバーでのアプリケーションの間で交換されるデータの唯一の単位がオブジェクトであるため、オブジェクト指向のアプローチを使用する場合があります。他のAPIは、送信または受信アプリケーションを有効にして、LCT（またはLCTの上に構築されたPI）とオブジェクトのサブセットを交換したり、ストリーミングモデルに従っている場合もあります。これらの考慮事項は、このドキュメントの範囲外です。
LCT is intended for congestion controlled delivery of objects and streams (both reliable content delivery and streaming of multimedia information).
LCTは、オブジェクトとストリームの混雑制御された配信（信頼できるコンテンツ配信とマルチメディア情報のストリーミングの両方）を対象としています。
LCT can be used with both multicast and unicast delivery. LCT requires connectivity between a sender and receivers, but it does not require connectivity from receivers to a sender. LCT inherently works with all types of networks, including LANs, WANs, Intranets, the Internet, asymmetric networks, wireless networks, and satellite networks. Thus, the inherent raw scalability of LCT is unlimited. However, when other specific applications are built on top of LCT, then these applications, by their very nature, may limit scalability. For example, if an application requires receivers to retrieve out-of-band information in order to join a session, or an application allows receivers to send requests back to the sender to report reception statistics, then the scalability of the application is limited by the ability to send, receive, and process this additional data.
LCTは、マルチキャストとユニキャストの両方の配信で使用できます。LCTには、送信者と受信機間の接続が必要ですが、受信者から送信者への接続は必要ありません。LCTは、LAN、WAN、イントラネット、インターネット、非対称ネットワーク、ワイヤレスネットワーク、衛星ネットワークなど、あらゆる種類のネットワークで本質的に動作します。したがって、LCTの固有の生のスケーラビリティは無制限です。ただし、他の特定のアプリケーションがLCTの上に構築されている場合、これらのアプリケーションは、その性質上、スケーラビリティを制限する可能性があります。たとえば、アプリケーションでセッションに参加するために受信機がバンド外情報を取得する必要がある場合、またはアプリケーションが受信者が送信者に返信を送信して受信統計を報告できる場合、アプリケーションのスケーラビリティは制限されます。この追加データを送信、受信、および処理する機能。
LCT requires receivers to be able to uniquely identify and demultiplex packets associated with an LCT session. In particular, there MUST be a Transport Session Identifier (TSI) associated with each LCT session. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI MUST uniquely identify the session. If the underlying transport is UDP, as described in [RFC0768], then the 16-bit UDP source port number MAY serve as the TSI for the session. The TSI value MUST be the same in all places it occurs within a packet. If there is no underlying TSI provided by the network, transport, or any other layer, then the TSI MUST be included in the LCT header.
LCTでは、レシーバーがLCTセッションに関連付けられているユニークな識別と逆Tiplexパケットを可能にする必要があります。特に、各LCTセッションに関連付けられたトランスポートセッション識別子（TSI）が必要です。TSIは送信者のIPアドレスによってスコープされ、送信者のIPアドレスとTSIがセッションを一意に識別する必要があります。[RFC0768]で説明されているように、基礎となる輸送がUDPの場合、16ビットのUDPソースポート番号はセッションのTSIとして機能する可能性があります。TSI値は、パケット内で発生するすべての場所で同じでなければなりません。ネットワーク、トランスポート、またはその他のレイヤーによって提供される基礎となるTSIがない場合は、TSIをLCTヘッダーに含める必要があります。
LCT is presumed to be used with an underlying network or transport service that is a "best effort" service that does not guarantee packet reception or packet reception order, and 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.
LCTは、パケット受信またはパケット受信オーダーを保証しない「最良の努力」サービスであり、フローや渋滞制御をサポートしていない「最良の努力」サービスであると推定されます。たとえば、[RFC1112]で定義されているIPマルチキャストの任意のソースマルチキャスト（ASM）モデルは、このような「最良の努力」ネットワークサービスです。[RFC1112]が提供する基本的なサービスは大部分がスケーラブルですが、特にレシーバーの不均一なセットが存在する場合、深刻なスケーラビリティの制限を回避するために、混雑制御または信頼性を慎重に提供する必要があります。
There are currently two models of multicast delivery, the Any-Source Multicast (ASM) model as defined in [RFC1112] and the Source-Specific Multicast (SSM) model as defined in [RFC4607]. LCT works with both multicast models, but in a slightly different way with somewhat different environmental concerns. When using ASM, a sender S sends packets to a multicast group G, and the LCT channel address consists of the pair (S,G), where S is the IP address of the sender and G is a multicast group address. When using SSM, a sender S sends packets to an SSM channel (S,G), and the LCT channel address coincides with the SSM channel address.
現在、[RFC1112]で定義されている任意のソースマルチキャスト（ASM）モデルと、[RFC4607]で定義されているソース固有のマルチキャスト（SSM）モデル、マルチキャスト配信の2つのモデルがあります。LCTは両方のマルチキャストモデルで動作しますが、やや異なる方法で環境上の懸念が異なります。ASMを使用する場合、送信者SはマルチキャストグループGにパケットを送信し、LCTチャネルアドレスはペア（s、g）で構成されます。ここで、Sは送信者のIPアドレスであり、Gはマルチキャストグループアドレスです。SSMを使用する場合、送信者SはパケットをSSMチャネル（S、G）に送信し、LCTチャネルアドレスはSSMチャネルアドレスと一致します。
A sender can locally allocate unique SSM channel addresses, and this makes allocation of LCT channel addresses easy with SSM. To allocate LCT channel addresses using ASM, the sender must uniquely chose the ASM multicast group address across the scope of the group, and this makes allocation of LCT channel addresses more difficult with ASM.
送信者は一意のSSMチャネルアドレスをローカルに割り当てることができ、これによりLCTチャネルアドレスの割り当てがSSMで簡単になります。ASMを使用してLCTチャネルアドレスを割り当てるには、送信者はグループの範囲全体でASMマルチキャストグループアドレスを一意に選択する必要があり、これによりLCTチャネルアドレスの割り当てがASMでより困難になります。
LCT channels and SSM channels coincide, and thus the receiver will only receive packets sent to the requested LCT channel. With ASM, the receiver joins an LCT channel by joining a multicast group G, and all packets sent to G, regardless of the sender, may be received by the receiver. Thus, SSM has compelling security advantages over ASM for prevention of denial-of-service (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に送信されるすべてのパケットが受信者が受信する場合があります。したがって、SSMには、サービス拒否（DOS）攻撃の防止のためにASMよりも説得力のあるセキュリティの利点があります。どちらの場合でも、受信機はパケット認証メカニズムを使用してそのような攻撃を軽減する必要があります（セクション6.2および7を参照）。
Some networks are not amenable to some congestion control protocols that could be used with LCT. In particular, for a satellite or wireless network, there may be no mechanism for receivers to effectively reduce their reception rate since there may be a fixed transmission rate allocated to the session.
一部のネットワークは、LCTで使用できるいくつかの混雑制御プロトコルに適していません。特に、衛星またはワイヤレスネットワークの場合、セッションに割り当てられた固定伝送速度がある可能性があるため、受信機が受信率を効果的に引き下げるメカニズムはない場合があります。
LCT is compatible with both IPv4 and IPv6 as no part of the packet is IP version specific.
LCTは、IPv4とIPv6の両方と互換性があります。これは、パケットの一部がIPバージョン固有ではないためです。
LCT can support several different delivery service models. Two examples are briefly described here.
LCTは、いくつかの異なる配信サービスモデルをサポートできます。ここでは、2つの例について簡単に説明します。
Push service model
プッシュサービスモデル
One way a push service model can be used for reliable content delivery is to deliver a series of objects. For example, a receiver could join the session and dynamically adapt the number of LCT channels the receiver is joined to until enough packets have been received to reconstruct an object. After reconstructing the object, the receiver may stay in the session and wait for the transmission of the next object.
信頼できるコンテンツ配信にプッシュサービスモデルを使用できる1つの方法は、一連のオブジェクトを配信することです。たとえば、受信機はセッションに参加し、オブジェクトを再構築するのに十分なパケットが受信されるまで、レシーバーが結合されるLCTチャネルの数を動的に適応させることができます。オブジェクトを再構築した後、受信者はセッションにとどまり、次のオブジェクトの送信を待つことができます。
The push model is particularly attractive in satellite networks and wireless networks. In these cases, a session may consist of one fixed rate LCT channel.
プッシュモデルは、衛星ネットワークとワイヤレスネットワークで特に魅力的です。これらの場合、セッションは1つの固定レートLCTチャネルで構成されている場合があります。
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ファイルなどの大きなオブジェクトの信頼できる配信には、プッシュサービスモデルを使用できます。送信者はセッションの説明アナウンスをコントロールチャネルに送信することができ、受信機はこのチャネルを監視し、関心のセッションの説明が到着するたびにセッションに参加できます。セッションの説明を受け取ると、各レシーバーはセッションに参加して、オブジェクトを再構築するのに十分なパケットが到着するまでパケットを受信できます。送信者は、すべてのレシーバーが再構成の成功を報告するか、他の条件が満たされるまで、オブジェクトのパケットをセッションに送信し続けることを決定できます。
There are several features Asynchronous Layered Coding (ALC) provides to support the push model. For example, the sender can optionally include an Expected Residual Time (ERT) in the packet header extension that indicates the expected remaining time of packet transmission for either the single object carried in the session or for the object identified by the Transmission Object Identifier (TOI) if there are multiple objects carried in the session. This can be used by receivers to determine if there is enough time remaining in the session to successfully receive enough additional packets to recover the object. If, for example, there is not enough time, then the push application may have receivers report back to the sender to extend the transmission of packets for the object for enough time to allow the receivers to obtain enough packets to reconstruct the object. The sender could then include an ERT based on the extended object transmission time in each subsequent packet header for the object. As other examples, the LCT header optionally can contain a Close Session flag that indicates when the sender is about to stop sending packets to the session and a Close Object flag that indicates when the sender is about to stop sending packets to the session for the object identified by the Transmission Object ID. However, these flags are not a completely reliable mechanism and thus the Close Session flag should only be used as a hint of when the session is about to close, and the Close Object flag should only be used as a hint of when transmission of packets for the object is about to end.
プッシュモデルをサポートするために、非同期層コーディング（ALC）が提供するいくつかの機能があります。たとえば、送信者はオプションでパケットヘッダー拡張機能に予想される残差時間（ERT）を含めることができます。これには、セッションに携帯されている単一オブジェクトまたは送信オブジェクト識別子（TOI）のいずれかのパケット伝送の予想残留時間を示すことができます。）セッションには複数のオブジェクトが掲載されている場合。これをレシーバーが使用して、オブジェクトを回復するのに十分な追加パケットを正常に受信するのに十分な時間がセッションに残っているかどうかを判断できます。たとえば、十分な時間がない場合、プッシュアプリケーションは受信機に送信者に報告して、オブジェクトを再構築するのに十分なパケットを取得できるように、オブジェクトのパケットの送信を十分な時間に拡張できる場合があります。送信者は、オブジェクトの各後続のパケットヘッダーの拡張オブジェクト伝送時間に基づいてERTを含めることができます。他の例として、LCTヘッダーはオプションで、送信者がセッションにパケットの送信を停止しようとしているときを示す緊密なセッションフラグと、送信者がオブジェクトのセッションにパケットをセッションに送信するのを停止しようとしていることを示す緊密なオブジェクトフラグを含めることができますトランスミッションオブジェクトIDによって識別されます。ただし、これらのフラグは完全に信頼性の高いメカニズムではないため、セッションのフラグはセッションが閉じようとしているときのヒントとしてのみ使用する必要があり、クローズオブジェクトフラグは、パケットの送信時のヒントとしてのみ使用する必要があります。オブジェクトは終了しようとしています。
On-demand content delivery model
オンデマンドコンテンツ配信モデル
For an on-demand content delivery service model, senders typically transmit for some given time period selected to be long enough to allow all the intended receivers to join the session and recover the object. For example, a popular software update might be transmitted using LCT for several days, even though a receiver may be able to complete the download in one hour total of connection time, perhaps spread over several intervals of time. In this case, the receivers join the session at any point in time when it is active. Receivers leave the session when they have received enough packets to recover the object. The receivers, for example, obtain a Session Description by contacting a web server.
オンデマンドコンテンツ配信サービスモデルの場合、送信者は通常、意図したすべての受信機がセッションに参加してオブジェクトを回復できるように十分な長さであると選択された特定の期間を送信します。たとえば、レシーバーが接続時間の合計1時間でダウンロードを完了することができ、おそらく数回の時間間隔で広がる場合でも、人気のあるソフトウェアアップデートは数日間LCTを使用して送信される場合があります。この場合、受信機はアクティブな時点でセッションに参加します。受信者は、オブジェクトを回復するのに十分なパケットを受け取ったときにセッションを去ります。たとえば、受信機は、Webサーバーに連絡してセッションの説明を取得します。
In this case, the receivers join the session, and dynamically adapt the number of LCT channels to which they subscribe according to the available bandwidth. Receivers then drop from the session when they have received enough packets to recover the object.
この場合、受信機がセッションに参加し、利用可能な帯域幅に従ってサブスクライブするLCTチャネルの数を動的に適応させます。その後、受信機は、オブジェクトを回復するのに十分なパケットを受け取ったときにセッションからドロップします。
As an example, assume that an object is 50 MB. The sender could send 1 KB packets to the first LCT channel at 50 packets per second, so that receivers using just this LCT channel could complete reception of the object in 1,000 seconds in absence of loss, and would be able to complete reception even in presence of some substantial amount of losses with the use of coding for reliability. Furthermore, the sender could use a number of LCT channels such that the aggregate rate of 1 KB packets to all LCT channels is 1,000 packets per second, so that a receiver could be able to complete reception of the object in as little 50 seconds (assuming no loss and that the congestion control mechanism immediately converges to the use of all LCT channels).
例として、オブジェクトが50 MBであると仮定します。送信者は、1秒あたり50パケットで1 kbのパケットを最初のLCTチャネルに送信できます。そのため、このLCTチャネルを使用してレシーバーは、損失がない場合に1,000秒でオブジェクトの受信を完了し、存在下でも受信を完了することができます。信頼性のためにコーディングを使用したいくつかのかなりの量の損失の。さらに、送信者は多くのLCTチャネルを使用して、すべてのLCTチャネルへの1 kbパケットの集計レートが1秒あたり1,000パケットであるため、レシーバーは50秒でオブジェクトの受信を完了することができます（仮定してください。損失はなく、混雑制御メカニズムがすぐにすべてのLCTチャネルの使用に収束すること。
Other service models
その他のサービスモデル
There are many other delivery service models for which LCT can be used that are not covered above. As examples, a live streaming or an on-demand archival content streaming service model. A description of the many potential applications, the appropriate delivery service model, and the additional mechanisms to support such functionalities when combined with LCT is beyond the scope of this document. This document only attempts to describe the minimal common scalable elements to these diverse applications using LCT as the delivery transport.
LCTを使用できる他の多くの配信サービスモデルがあり、上にカバーされていません。例として、ライブストリーミングまたはオンデマンドアーカイブコンテンツストリーミングサービスモデル。多くの潜在的なアプリケーション、適切な配信サービスモデル、およびLCTと組み合わせた場合にそのような機能をサポートする追加のメカニズムの説明は、このドキュメントの範囲を超えています。このドキュメントは、配信輸送としてLCTを使用して、これらの多様なアプリケーションに対して最小限の一般的なスケーラブルな要素を記述しようとします。
The specific congestion control protocol to be used for LCT sessions depends on the type of content to be delivered. While the general behavior of the congestion control protocol is to reduce the throughput in presence of congestion and gradually increase it in the absence of congestion, the actual dynamic behavior (e.g., response to single losses) can vary.
LCTセッションに使用される特定の混雑制御プロトコルは、配信されるコンテンツのタイプに依存します。輻輳制御プロトコルの一般的な動作は、輻輳の存在下でスループットを減らし、混雑がない場合に徐々に増加させることですが、実際の動的な動作（単一の損失に対する反応など）は異なる場合があります。
It is RECOMMENDED that the congestion control mechanism specified in [RFC3738] be used. Some alternative possible congestion control protocols for reliable content delivery using LCT are described in [VIC1998] and [BYE2000]. Different delivery service models might require different congestion control protocols.
[RFC3738]で指定された輻輳制御メカニズムを使用することをお勧めします。LCTを使用した信頼できるコンテンツ配信のためのいくつかの代替の混雑制御プロトコルは、[VIC1998]および[BYE2000]で説明されています。異なる配信サービスモデルには、異なる混雑制御プロトコルが必要になる場合があります。
Packets sent to an LCT session MUST include an "LCT header". The LCT header format is described below.
LCTセッションに送信されたパケットには、「LCTヘッダー」を含める必要があります。LCTヘッダー形式については、以下に説明します。
Other building blocks MAY describe some of the same fields as described for the LCT header. It is RECOMMENDED that protocol instantiations using multiple building blocks include shared fields at most once in each packet. Thus, for example, if another building block is used with LCT that includes the optional Expected Residual Time field, then the Expected Residual Time field SHOULD be carried in each packet at most once.
他のビルディングブロックは、LCTヘッダーについて説明したのと同じフィールドの一部を記述する場合があります。複数のビルディングブロックを使用したプロトコルインスタンス化には、各パケットにせいぜい1回共有フィールドを含めることをお勧めします。したがって、たとえば、オプションの予想残留時間フィールドを含むLCTで別のビルディングブロックを使用している場合、予想される残留時間フィールドは、せいぜい1回、各パケットに携帯する必要があります。
The position of the LCT header within a packet MUST be specified by any protocol instantiation that uses LCT.
パケット内のLCTヘッダーの位置は、LCTを使用するプロトコルインスタンス化によって指定する必要があります。
The LCT header is of variable size, which is specified by a length field in the third byte of the header. In the LCT header, all integer fields are carried in "big-endian" or "network order" format, that is, most significant byte (octet) first. Bits designated as "padding" or "reserved" (r) MUST by set to 0 by senders and ignored by receivers in this version of the specification. Unless otherwise noted, numeric constants in this specification are in decimal form (base 10).
LCTヘッダーは可変サイズで、ヘッダーの3番目のバイトの長さフィールドで指定されています。LCTヘッダーでは、すべての整数フィールドが「ビッグエンディアン」または「ネットワーク注文」形式で運ばれます。つまり、最初に最も重要なバイト（Octet）です。「パディング」または「予約済み」（r）として指定されたビットは、送信者によって0に設定され、このバージョンの仕様のレシーバーが無視する必要があります。特に明記しない限り、この仕様の数値定数は10進形式です（ベース10）。
The format of the default LCT header is depicted in Figure 1.
デフォルトのLCTヘッダーの形式を図1に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | C |PSI|S| O |H|Res|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI, length = 32*(C+1) bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Session Identifier (TSI, length = 32*S+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, length = 32*O+16*H bits) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Default LCT Header Format
図1：デフォルトのLCTヘッダー形式
The function and length of each field in the default LCT header is the following.
デフォルトのLCTヘッダーの各フィールドの関数と長さは次のとおりです。
LCT version number (V): 4 bits
LCTバージョン番号（v）：4ビット
Indicates the LCT version number. The LCT version number for this specification is 1.
LCTバージョン番号を示します。この仕様のLCTバージョン番号は1です。
Congestion control flag (C): 2 bits
混雑制御フラグ（c）：2ビット
C=0 indicates the Congestion Control Information (CCI) field is 32 bits in length. C=1 indicates the CCI field is 64 bits in length. C=2 indicates the CCI field is 96 bits in length. C=3 indicates the CCI field is 128 bits in length.
C = 0は、輻輳制御情報（CCI）フィールドの長さが32ビットのことを示します。C = 1は、CCIフィールドの長さが64ビットのことを示します。C = 2は、CCIフィールドの長さが96ビットのことを示します。C = 3は、CCIフィールドの長さが128ビットのことを示します。
Protocol-Specific Indication (PSI): 2 bits
プロトコル固有の表示（PSI）：2ビット
The usage of these bits, if any, is specific to each protocol instantiation that uses the LCT building block. If no protocol-instantiation-specific usage of these bits is defined, then a sender MUST set them to zero and a receiver MUST ignore these bits.
これらのビットの使用は、もしあれば、LCTビルディングブロックを使用する各プロトコルインスタンス化に固有です。これらのBITのプロトコル固有の使用が定義されていない場合、送信者はそれらをゼロに設定する必要があり、レシーバーはこれらのビットを無視する必要があります。
Transport Session Identifier flag (S): 1 bit
トランスポートセッション識別子フラグ：1ビット
This is the number of full 32-bit words in the TSI field. The TSI field is 32*S + 16*H bits in length, i.e., the length is either 0 bits, 16 bits, 32 bits, or 48 bits.
これは、TSIフィールドの完全な32ビット語の数です。TSIフィールドの長さは32*s 16*hビットです。つまり、長さは0ビット、16ビット、32ビット、または48ビットのいずれかです。
Transport Object Identifier flag (O): 2 bits
輸送オブジェクト識別子フラグ（O）：2ビット
This is the number of full 32-bit words in the TOI field. The TOI field is 32*O + 16*H bits in length, i.e., the length is either 0 bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112 bits.
これは、TOIフィールドの32ビットの完全な単語の数です。TOIフィールドの長さは32*o 16*hビットです。つまり、長さは0ビット、16ビット、32ビット、48ビット、64ビット、80ビット、96ビット、または112ビットのいずれかです。
Half-word flag (H): 1 bit
ハーフワードフラグ（H）：1ビット
The TSI and the TOI fields are both multiples of 32 bits plus 16*H bits in length. This allows the TSI and TOI field lengths to be multiples of a half-word (16 bits), while ensuring that the aggregate length of the TSI and TOI fields is a multiple of 32 bits.
TSIとTOIフィールドは、両方とも32ビットの倍数と長さ16*hビットです。これにより、TSIおよびTOIフィールドの長さを半ワード（16ビット）の倍数にすることができ、TSIフィールドとTOIフィールドの総長が32ビットの倍数であることを保証します。
Reserved (Res): 2 bits
予約済み（res）：2ビット
These bits are reserved. In this version of the specification, they MUST be set to zero by senders and MUST be ignored by receivers.
これらのビットは予約されています。仕様のこのバージョンでは、送信者がゼロに設定する必要があり、受信機は無視する必要があります。
Close Session flag (A): 1 bit
セッションフラグを閉じる（a）：1ビット
Normally, A is set to 0. The sender MAY set A to 1 when termination of transmission of packets for the session is imminent. A MAY be set to 1 in just the last packet transmitted for the session, or A MAY be set to 1 in the last few seconds of packets transmitted for the session. Once the sender sets A to 1 in one packet, the sender SHOULD set A to 1 in all subsequent packets until termination of transmission of packets for the session. A received packet with A set to 1 indicates to a receiver that the sender will immediately stop sending packets for the session. When a receiver receives a packet with A set to 1, the receiver SHOULD assume that no more packets will be sent to the session.
通常、Aは0に設定されています。Senderは、セッションのパケットの送信の終了が差し迫っているときにAを1に設定できます。Aは、セッション用に送信された最後のパケットのみで1に設定されるか、セッション用に送信された最後の数秒のパケットで1に設定できます。送信者が1つのパケットに1を設定すると、送信者はセッションのパケットの送信が終了するまで、後続のすべてのパケットで1を設定する必要があります。セットが1にある受信パケットは、受信機に、送信者がセッションのパケットの送信をすぐに停止することを示します。受信者がセットを1に搭載したパケットを受信すると、受信機はこれ以上パケットがセッションに送信されないと想定する必要があります。
Close Object flag (B): 1 bit
オブジェクトフラグを閉じる（b）：1ビット
Normally, B is set to 0. The sender MAY set B to 1 when termination of transmission of packets for an object is imminent. If the TOI field is in use and B is set to 1, then termination of transmission for the object identified by the TOI field is imminent. If the TOI field is not in use and B is set to 1, then termination of transmission for the one object in the session identified by out-of-band information is imminent. B MAY be set to 1 in just the last packet transmitted for the object, or B MAY be set to 1 in the last few seconds that packets are transmitted for the object. Once the sender sets B to 1 in one packet for a particular object, the sender SHOULD set B to 1 in all subsequent packets for the object until termination of transmission of packets for the object. A received packet with B set to 1 indicates to a receiver that the sender will immediately stop sending packets for the object. When a receiver receives a packet with B set to 1, then it SHOULD assume that no more packets will be sent for the object to the session.
通常、Bは0に設定されます。送信者は、オブジェクトのパケットの送信の終了が差し迫っているときにBを1に設定できます。TOIフィールドが使用されており、Bが1に設定されている場合、TOIフィールドによって識別されるオブジェクトの伝送の終了が差し迫っています。TOIフィールドが使用されておらず、Bが1に設定されている場合、帯域外情報によって識別されるセッション内の1つのオブジェクトの送信の終了が差し迫っています。bは、オブジェクトに送信された最後のパケットのみで1に設定される場合があります。または、パケットがオブジェクト用に送信される最後の数秒でBを1に設定できます。送信者が特定のオブジェクトの1つのパケットにBを1に設定すると、送信者はオブジェクトのパケットの送信を終了するまで、オブジェクトの後続のすべてのパケットでBにBを設定する必要があります。Bを1に設定した受信パケットは、受信機に、送信者がオブジェクトのパケットの送信をすぐに停止することを示します。レシーバーがBを1に設定したパケットを受信すると、セッションにオブジェクトのパケットが送信されないと仮定する必要があります。
LCT header length (HDR_LEN): 8 bits
LCTヘッダー長（HDR_LEN）：8ビット
Total length of the LCT header in units of 32-bit words. The length of the LCT header MUST be a multiple of 32 bits. This field can be used to directly access the portion of the packet beyond the LCT header, i.e., to the first other header if it exists, or to the packet payload if it exists and there is no other header, or to the end of the packet if there are no other headers or packet payload.
32ビット語の単位単位でのLCTヘッダーの全長。LCTヘッダーの長さは、32ビットの倍数でなければなりません。このフィールドを使用して、LCTヘッダーを超えてパケットの部分に直接アクセスできます。つまり、存在する場合は他の最初のヘッダー、または存在する場合はパケットペイロードがあり、他のヘッダーがない場合、または他のヘッダーやパケットペイロードがない場合はパケット。
Codepoint (CP): 8 bits
CodePoint（CP）：8ビット
An opaque identifier 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ヘッダーのペイロードタイプ（PT）フィールドに似ています。
Congestion Control Information (CCI): 32, 64, 96, or 128 bits
混雑制御情報（CCI）：32、64、96、または128ビット
Used to carry congestion control information. For example, the congestion control information could include layer numbers, logical channel numbers, and sequence numbers. This field is opaque for the purpose of this specification.
混雑制御情報を運ぶために使用されます。たとえば、混雑制御情報には、レイヤー番号、論理チャネル番号、シーケンス番号が含まれます。このフィールドは、この仕様の目的で不透明です。
This field MUST be 32 bits if C=0.
C = 0の場合、このフィールドは32ビットでなければなりません。
This field MUST be 64 bits if C=1.
C = 1の場合、このフィールドは64ビットでなければなりません。
This field MUST be 96 bits if C=2.
C = 2の場合、このフィールドは96ビットでなければなりません。
This field MUST be 128 bits if C=3.
C = 3の場合、このフィールドは128ビットでなければなりません。
Transport Session Identifier (TSI): 0, 16, 32, or 48 bits
トランスポートセッション識別子（TSI）：0、16、32、または48ビット
The TSI uniquely identifies a session among all sessions from a particular sender. The TSI is scoped by the IP address of the sender, and thus the IP address of the sender and the TSI together uniquely identify the session. Although a TSI in conjunction with the IP address of the sender always uniquely identifies a session, whether or not the TSI is included in the LCT header depends on what is used as the TSI value. If the underlying transport is UDP, then the 16-bit UDP source port number MAY serve as the TSI for the session. If the TSI value appears multiple times in a packet, then all occurrences MUST be the same value. If there is no underlying TSI provided by the network, transport or any other layer, then the TSI MUST be included in the LCT header.
TSIは、特定の送信者からのすべてのセッション間でセッションを一意に識別します。TSIは送信者のIPアドレスによってスコープされているため、送信者のIPアドレスとTSIが一緒にセッションを一意に識別します。送信者のIPアドレスと組み合わせたTSIは常にセッションを一意に識別しますが、TSIがLCTヘッダーに含まれるかどうかは、TSI値として使用されるものによって異なります。基礎となる輸送がUDPの場合、16ビットのUDPソースポート番号がセッションのTSIとして機能する可能性があります。TSI値がパケットに複数回表示される場合、すべての発生は同じ値でなければなりません。ネットワーク、トランスポート、またはその他のレイヤーによって提供される基礎となるTSIがない場合は、TSIをLCTヘッダーに含める必要があります。
The TSI MUST be unique among all sessions served by the sender during the period when the session is active, and for a large period of time preceding and following when the session is active. A primary purpose of the TSI is to prevent receivers from inadvertently accepting packets from a sender that belong to sessions other than the sessions to which receivers are subscribed. For example, suppose a session is deactivated and then another session is activated by a sender and the two sessions use an overlapping set of channels. A receiver that connects and remains connected to the first session during this sender activity could possibly accept packets from the second session as belonging to the first session if the TSI for the two sessions were identical. The mapping of TSI field values to sessions is outside the scope of this document and is to be done out-of-band.
TSIは、セッションがアクティブである期間中に送信者が提供するすべてのセッションの中で、およびセッションがアクティブである前後の大規模な期間の間にユニークでなければなりません。TSIの主な目的は、受信者がサブスクライブするセッション以外のセッションに属する送信者から受信者が不注意にパケットを受け入れるのを防ぐことです。たとえば、セッションが非アクティブ化され、次に別のセッションが送信者によってアクティブ化され、2つのセッションが重複するチャネルセットを使用しているとします。この送信者のアクティビティ中に接続して最初のセッションに接続したままでいるレシーバーは、2つのセッションのTSIが同一である場合、2番目のセッションのパケットを最初のセッションに属するものとして受け入れる可能性があります。セッションへのTSIフィールド値のマッピングは、このドキュメントの範囲外であり、帯域外で行われます。
The length of the TSI field is 32*S + 16*H bits. Note that the aggregate lengths of the TSI field plus the TOI field is a multiple of 32 bits.
TSIフィールドの長さは32*s 16*hビットです。TSIフィールドとTOIフィールドの骨材の長さは32ビットの倍数であることに注意してください。
Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96, or 112 bits.
輸送オブジェクト識別子（TOI）：0、16、32、48、64、80、96、または112ビット。
This field indicates 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値はオブジェクトに適用されるハッシュ関数の出力である可能性があります。ObjectsへのTOIフィールド値のマッピングは、このドキュメントの範囲外であり、帯域外で行われます。TOIフィールドは、セッションで複数のオブジェクトを送信する場合、つまりTOIフィールドがセッションのすべてのパケットに存在するか、存在しない場合、すべてのパケットで使用する必要があります。
The length of the TOI field is 32*O + 16*H bits. Note that the aggregate length of the TSI field plus the TOI field is a multiple of 32 bits.
TOIフィールドの長さは32*o 16*hビットです。TSIフィールドとTOIフィールドの総長さは32ビットの倍数であることに注意してください。
Header Extensions are used in LCT to accommodate optional header fields that are not always used or have variable size. Examples of the use of Header Extensions include:
ヘッダー拡張機能は、LCTで使用され、常に使用されていない、または可変サイズのオプションのヘッダーフィールドに対応します。ヘッダー拡張機能の使用の例は次のとおりです。
o Extended-size versions of already existing header fields.
o 既存のヘッダーフィールドの拡張サイズのバージョン。
o Sender and receiver authentication information.
o 送信者および受信者認証情報。
o Transmission of timing information.
o タイミング情報の送信。
The presence of Header Extensions can be inferred by the LCT header length (HDR_LEN). If HDR_LEN is larger than the length of the standard header, then the remaining header space is taken by Header Extension fields.
ヘッダー拡張の存在は、LCTヘッダー長（HDR_LEN）によって推測できます。HDR_LENが標準ヘッダーの長さよりも大きい場合、残りのヘッダースペースはヘッダー拡張フィールドによって取得されます。
If present, Header Extensions MUST be processed to ensure that they are recognized before performing any congestion control procedure or otherwise accepting a packet. The default action for unrecognized Header Extensions is to ignore them. This allows the future introduction of backward-compatible enhancements to LCT without changing the LCT version number. Non-backward-compatible Header Extensions CANNOT be introduced without changing the LCT version number.
存在する場合、ヘッダー拡張機能を処理して、輻輳制御手順を実行するか、パケットを受け入れる前に認識されることを確認する必要があります。認識されていないヘッダー拡張機能のデフォルトのアクションは、それらを無視することです。これにより、LCTバージョン番号を変更せずに、LCTへの後方互換拡張機能の将来の導入が可能になります。LCTバージョン番号を変更せずに、非バックワード互換ヘッダー拡張機能を導入することはできません。
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に示すように、ヘッダーエクステンションフィールドには2つの形式があります。最初の形式は、0〜127の間のヘッダー拡張タイプ（HET）値を持つ可変長拡張機能に使用されます。32ビットワード）拡張機能、127から255までのHET値を使用。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of Additional Headers
図2：追加のヘッダーの形式
The explanation of each sub-field is the following:
各サブフィールドの説明は次のとおりです。
Header Extension Type (HET): 8 bits
ヘッダー拡張タイプ（HET）：8ビット
The type of the Header Extension. This document defines a number of possible types. Additional types may be defined in future versions of this specification. HET values from 0 to 127 are used for variable-length Header Extensions. HET values from 128 to 255 are used for fixed-length 32-bit Header Extensions.
ヘッダー拡張機能のタイプ。このドキュメントでは、可能な多くのタイプを定義します。追加のタイプは、この仕様の将来のバージョンで定義できます。0〜127のHET値は、可変長ヘッダー拡張に使用されます。128〜255のHET値は、固定長32ビットヘッダー拡張機能に使用されます。
Header Extension Length (HEL): 8 bits
ヘッダー拡張長（HEL）：8ビット
The length of the whole Header Extension field, expressed in multiples of 32-bit words. This field MUST be present for variable-length extensions (HETs between 0 and 127) and MUST NOT be present for fixed-length extensions (HETs between 128 and 255).
32ビット語の倍数で表されるヘッダー拡張フィールド全体の長さ。このフィールドは、可変長拡張機能（0〜127のHET）に存在する必要があり、固定長拡張（128〜255のHETS）には存在しないでください。
Header Extension Content (HEC): variable length
ヘッダー拡張コンテンツ（HEC）：可変長
The content of the Header Extension. The format of this sub-field depends on the Header Extension Type. For fixed-length Header Extensions, the HEC is 24 bits. For variable-length Header Extensions, the HEC field has variable size, as specified by the HEL field. Note that the length of each Header Extension field MUST be a multiple of 32 bits. Also note that the total size of the LCT header, including all Header Extensions and all optional header fields, cannot exceed 255 32-bit words.
ヘッダー拡張機能の内容。このサブフィールドの形式は、ヘッダー拡張タイプに依存します。固定長ヘッダー拡張機能の場合、HECは24ビットです。可変長ヘッダー拡張機能の場合、HECフィールドは、HELフィールドで指定されているように、可変サイズです。各ヘッダー拡張フィールドの長さは、32ビットの倍数でなければならないことに注意してください。また、すべてのヘッダー拡張機能とすべてのオプションのヘッダーフィールドを含むLCTヘッダーの合計サイズは、255 32ビット単語を超えることはできないことに注意してください。
The following LCT Header Extensions are defined by this specification:
次のLCTヘッダー拡張機能は、この仕様で定義されています。
EXT_NOP, HET=0 No-Operation extension. The information present in this extension field MUST be ignored by receivers.
ext_nop、het = 0術なし拡張。この拡張機能フィールドに存在する情報は、受信機によって無視する必要があります。
EXT_AUTH, HET=1 Packet authentication extension. Information used to authenticate the sender of the packet. The format of this Header Extension and its processing is outside the scope of this document and is to be communicated out-of-band as part of the session description.
ext_auth、het = 1パケット認証拡張機能。パケットの送信者を認証するために使用される情報。このヘッダー拡張機能とその処理の形式は、このドキュメントの範囲外であり、セッションの説明の一部として帯域外に伝えられます。
It is RECOMMENDED that senders provide some form of packet authentication. If EXT_AUTH is present, whatever packet authentication checks that can be performed immediately upon reception of the packet SHOULD be performed before accepting the packet and performing any congestion-control-related action on it.
送信者は、何らかの形のパケット認証を提供することをお勧めします。ext_authが存在する場合、パケットを受け入れ、混雑コントロール関連のアクションを実行する前に、パケットの受信後すぐに実行できるパケット認証チェックを実行する必要があります。
Some packet authentication schemes impose a delay of several seconds between when a packet is received and when the packet is fully authenticated. Any congestion control related action that is appropriate SHOULD NOT be postponed by any such full packet authentication.
一部のパケット認証スキームは、パケットが受信されたときとパケットが完全に認証されたときの間に数秒の遅延を課します。適切な混雑制御関連のアクションは、このような完全なパケット認証によって延期されるべきではありません。
EXT_TIME, HET=2 Time Extension. This extension is used to carry several types of timing information. It includes general purpose timing information, namely the Sender Current Time (SCT), Expected Residual Time (ERT), and Sender Last Change (SLC) time extensions described in the present document. It can also be used for timing information with narrower applicability (e.g., defined for a single protocol instantiation); in this case, it will be described in a separate document.
ext_time、het = 2時間延長。この拡張機能は、いくつかのタイミング情報を運ぶために使用されます。これには、汎用タイミング情報、つまり、現在のドキュメントで説明されている送信者現在の時間（SCT）、予想残留時間（ERT）、および送信者の最後の変更（SLC）時間延長が含まれます。また、より狭い適用可能性を備えたタイミング情報に使用することもできます（たとえば、単一のプロトコルインスタンス化に対して定義されています）。この場合、別のドキュメントで説明されます。
All senders and receivers implementing LCT MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH and EXT_TIME, but are not required to be able to parse their content.
LCTを実装するすべての送信者と受信者は、ext_nopヘッダー拡張機能をサポートする必要があり、ext_authとext_timeを認識する必要がありますが、コンテンツを解析する必要はありません。
This section defines the timing Header Extensions with general applicability. The time values carried in this Header Extension are related to the server's wall clock. The server MUST maintain consistent relative time during a session (i.e., insignificant clock drift). For some applications, system or even global synchronization of server wall clock may be desirable, such as using the Network Time Protocol (NTP) [RFC1305] to ensure actual time relative to 00:00 hours GMT, January 1st 1900. Such session-external synchronization is outside the scope of this document.
このセクションでは、一般的な適用性を備えたタイミングヘッダー拡張機能を定義します。このヘッダー拡張機能で運ばれる時間値は、サーバーの壁の時計に関連しています。サーバーは、セッション中に一貫した相対時間を維持する必要があります（つまり、取るに足らないクロックドリフト）。一部のアプリケーションでは、ネットワークタイムプロトコル（NTP）[RFC1305]を使用して、1900年1月1日の00:00時間に比べて実際の時間を確保するなど、サーバーウォールクロックのシステムまたはグローバル同期が望ましい場合があります。同期は、このドキュメントの範囲外です。
The EXT_TIME Header Extension uses the format depicted in Figure 3.
ext_timeヘッダー拡張機能は、図3に示す形式を使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 2 | HEL >= 1 | Use (bit field) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| first time value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (other time values (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EXT_TIME Header Extension Format
図3：ext_timeヘッダー拡張形式
The "Use" bit field indicates the semantic of the following 32-bit time value(s).
「使用」ビットフィールドは、次の32ビット時間値のセマンティックを示します。
It is divided into two parts:
2つの部分に分かれています。
o 8 bits are reserved for general purpose timing information. This information is applicable to any protocol that makes use of LCT.
o 8ビットは、汎用のタイミング情報のために予約されています。この情報は、LCTを使用する任意のプロトコルに適用できます。
o 8 bits are reserved for PI-specific timing information. This information is out of the scope of this document.
o 8ビットは、PI固有のタイミング情報のために予約されています。この情報は、このドキュメントの範囲外です。
The format of the "Use" bit field is depicted in Figure 4.
「使用」ビットフィールドの形式を図4に示します。
2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|SCT|SCT|ERT|SLC| reserved | PI-specific |
|Hi |Low| | | by LCT | use |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 4: "Use" Bit Field Format
図4：ビットフィールド形式を「使用します」
Several "time value" fields MAY be present in a given EXT_TIME Header Extension, as specified in the "Use-field". When several "time value" fields are present, they MUST appear in the order specified by the associated flag position in the "Use-field": first SCT-High (if present), then SCT-Low (if present), then ERT (if present), then SLC (if present). Receivers SHOULD ignore additional fields within the EXT_TIME Header Extension that they do not support.
「ユースフィールド」で指定されているように、特定のext_timeヘッダー拡張機能にいくつかの「時間値」フィールドが存在する場合があります。いくつかの「時間値」フィールドが存在する場合、「ユースフィールド」の関連フラグ位置で指定された順序で表示されなければなりません：最初のSCT-High（存在する場合）、次にSCT-low（存在する場合）、次にert（存在する場合）、次にSLC（存在する場合）。レシーバーは、サポートしていないExt_timeヘッダー拡張機能内の追加のフィールドを無視する必要があります。
The fields for the general purpose EXT_TIME timing information are:
汎用ext_timeタイミング情報のフィールドは次のとおりです。
Sender Current Time (SCT): SCT-High flag, SCT-Low flag, corresponding time value (one or two 32-bit words).
Sender Current Time（SCT）：SCT-HIGHフラグ、SCT-LOWフラグ、対応する時間値（1つまたは2つの32ビットワード）。
This timing information represents the current time at the sender at the time this packet was transmitted.
このタイミング情報は、このパケットが送信された時点での送信者の現在の時刻を表します。
When the SCT-High flag is set, the associated 32-bit time value provides an unsigned integer representing the time in seconds of the sender's wall clock. In the particular case where NTP is used, these 32 bits provide an unsigned integer representing the time in seconds relative to 00:00 hours GMT, January 1st 1900, (i.e., the most significant 32 bits of a full 64-bit NTP time value). In that case, handling of wraparound of the 32-bit time is outside the scope of NTP and LCT.
SCT-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/2 ^^ 32の倍数を表す符号なし整数を提供します。SCT-lowフラグが設定されている場合、SCT-Highフラグも設定する必要があります。NTPが使用される特定のケースでは、これらの32ビットは、64ビットNTPタイムスタンプの32ビットを提供します。
Expected Residual Time (ERT): ERT flag, corresponding 32-bit time value.
予想残留時間（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.
セッションLast Chanded（SLC）：SLCフラグ、対応する32ビット時間値。
The Session Last Changed time value is the server wall clock time, in seconds, at which the last change to session data occurred. That is, it expresses the time at which the last (most recent) Transport Object addition, modification, or removal was made for the delivery session. In the case of modifications and additions, it indicates that new data will be transported that was not transported prior to this time. In the case of removals, SLC indicates that some prior data will no longer be transported.
最後の変更時間値は、セッションデータの最後の変更が発生したサーバーウォールクロック時間の秒単位です。つまり、配達セッションのために最後の（最新の）輸送オブジェクトの追加、変更、または除去が行われた時間を表しています。修正と追加の場合、これはこの時期に輸送されなかった新しいデータが輸送されることを示しています。取り外しの場合、SLCは、一部の以前のデータが輸送されなくなったことを示しています。
When the SLC flag is set, the associated 32-bit time value provides an unsigned integer representing a time in seconds. In the particular case where NTP is used, these 32 bits provide an unsigned integer representing the time in seconds relative to 00:00 hours GMT, January 1st 1900, (i.e., the most significant 32 bits of a full 64-bit NTP time value). In that case, handling of wraparound of the 32-bit time is outside the scope of NTP and LCT.
SLCフラグが設定されている場合、関連する32ビット時間値は、秒単位の時間を表す署名のない整数を提供します。NTPが使用される特定のケースでは、これらの32ビットは、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ヘッダー拡張機能を含むパケットに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.
このバージョンの仕様では、これらのビットは送信者によってゼロに設定され、受信機が無視する必要があります。
PI-specific use (8 bits):
PI固有の使用（8ビット）：
These bits are out of the scope of this document. The bits that are not specified by the PI built on top of LCT SHOULD be set to zero.
これらのビットは、このドキュメントの範囲外です。LCTの上に構築されたPIによって指定されていないビットは、ゼロに設定する必要があります。
The total EXT_TIME length is carried in the HEL, since this Header Extension is of variable length. It also enables clients to skip this Header Extension altogether if not supported (but recognized).
このヘッダーの拡張はさまざまな長さであるため、総ext_timeの長さはHELで運ばれます。また、クライアントがサポートされていない場合（ただし、認識されている）場合、このヘッダー拡張機能を完全にスキップできます。
Before joining an LCT session, a receiver MUST obtain a session description. The session description MUST include:
LCTセッションに参加する前に、受信者はセッションの説明を取得する必要があります。セッションの説明には以下を含める必要があります。
o The sender IP address;
o 送信者IPアドレス。
o The number of LCT channels;
o LCTチャネルの数。
o The addresses and port numbers used for each LCT channel;
o 各LCTチャネルに使用されるアドレスとポート番号。
o The Transport Session ID (TSI) to be used for the session;
o セッションに使用されるトランスポートセッションID（TSI）。
o Enough information to determine the congestion control protocol being used;
o 使用されている混雑制御プロトコルを決定するのに十分な情報。
o Enough information to determine the packet authentication scheme being used (if 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を使用したプロトコルのインスタンス化は、セッションの説明に含める必要があるものに追加の要件を置く場合があります。たとえば、プロトコルのインスタンス化では、各チャネルのデータレート、セッションのオブジェクトへの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.
セッションの説明は、[RFC4566]で定義されているSDPなどの形式、または特定のアプリケーションに適した別の形式などの形式である可能性があります。[RFC2974]で定義されているSAPなどのセッションアナウンスプロトコルで、独自のセッション制御プロトコルを使用して取得したり、スケジューリング情報を備えたWebページにある、または電子メールまたはその他の帯域外の方法で伝えられます。セッションの説明形式の説明、およびセッションの説明の配布は、このドキュメントの範囲を超えています。
Within an LCT session, a sender using LCT transmits a sequence of packets, each in the format defined above. Packets are sent from a sender using one or more LCT channels, which together constitute a session. Transmission rates may be different in different channels and may vary over time. The specification of the other building block headers and the packet payload used by a complete protocol instantiation using LCT is beyond the scope of this document. This document does not specify the order in which packets are transmitted, nor the organization of a session into multiple channels. Although these issues affect the efficiency of the protocol, they do not affect the correctness nor the inter-operability of LCT between senders and receivers.
LCTセッション内で、LCTを使用する送信者は、それぞれ上記の形式で一連のパケットを送信します。パケットは、1つ以上のLCTチャネルを使用して送信者から送信され、セッションを構成します。伝送速度は異なるチャネルで異なる場合があり、時間とともに異なる場合があります。LCTを使用した完全なプロトコルインスタンス化で使用される他のビルディングブロックヘッダーとパケットペイロードの仕様は、このドキュメントの範囲を超えています。このドキュメントでは、パケットが送信される順序も、セッションの組織化を複数のチャネルに指定しません。これらの問題はプロトコルの効率に影響しますが、送信者と受信機の間のLCTの正確性や相互運用性には影響しません。
Several objects can be carried within the same LCT session. In this case, each object MUST be identified by a unique TOI. Objects MAY be transmitted sequentially, or they MAY be transmitted concurrently. It is good practice to only send objects concurrently in the same session if the receivers that participate in that portion of the session have interest in receiving all the objects. The reason for this is that it wastes bandwidth and networking resources to have receivers receive data for objects in which they have no interest.
同じLCTセッション内でいくつかのオブジェクトを運ぶことができます。この場合、各オブジェクトは一意のTOIによって識別される必要があります。オブジェクトは連続的に送信されるか、同時に送信される場合があります。セッションのその部分に参加する受信機がすべてのオブジェクトを受信することに関心がある場合、同じセッションでオブジェクトを同時に送信することをお勧めします。この理由は、帯域幅とネットワーキングリソースを無駄にして、受信機に興味のないオブジェクトのデータを受け取らせるからです。
Typically, the sender(s) continues to send packets in a session until the transmission is considered complete. The transmission may be considered complete when some time has expired, a certain number of packets have been sent, or some out-of-band signal (possibly from a higher level protocol) has indicated completion by a sufficient number of receivers.
通常、送信者は、送信が完了すると見なされるまでセッションでパケットを送信し続けます。ある程度の期限が切れたとき、特定の数のパケットが送信された場合、または帯域外の信号（おそらくより高いレベルのプロトコルから）が十分な数の受信機による完了を示している場合、送信は完全であると見なされる場合があります。
For the reasons mentioned above, this document does not pose any restriction on packet sizes. However, network efficiency considerations recommend that the sender uses an as large as possible packet payload size, but in such a way that packets do not exceed the network's maximum transmission unit size (MTU), or when fragmentation coupled with packet loss might introduce severe inefficiency in the transmission.
上記の理由により、このドキュメントはパケットサイズに制限をもたらさない。ただし、ネットワーク効率の考慮事項は、送信者がパケットペイロードサイズを可能な限り大きいように使用することを推奨していますが、パケットがネットワークの最大送信ユニットサイズ（MTU）を超えないように、またはパケットの損失と結合した断片化が重度の非効率性をもたらす可能性があることを推奨しています。トランスミッション。
It is recommended that all packets have the same or very similar sizes, as this can have a severe impact on the effectiveness of congestion control schemes such as the ones described in [VIC1998], [BYE2000], and [RFC3738]. A sender of packets using LCT MUST implement the sender-side part of one of the congestion control schemes that is in accordance with [RFC2357] using the Congestion Control Information field provided in the LCT header, and the corresponding receiver congestion control scheme is to be communicated out-of-band and MUST be implemented by any receivers participating in the session.
[VIC1998]、[BYE2000]、[RFC3738]に記載されているものなどの混雑制御スキームの有効性に深刻な影響を与える可能性があるため、すべてのパケットが同じまたは非常に類似したサイズを持つことをお勧めします。LCTを使用したパケットの送信者は、LCTヘッダーで提供される輻輳制御情報フィールドを使用して[RFC2357]に従って、輻輳制御スキームの1つの送信者側部分を実装する必要があり、対応する受信機の混雑制御スキームは帯域外に通信し、セッションに参加しているレシーバーによって実装する必要があります。
Receivers can operate differently depending on the delivery service model. For example, for an on-demand service model, receivers may join a session, obtain the necessary packets to reproduce the object, and then leave the session. As another example, for a streaming service model, a receiver may be continuously joined to a set of LCT channels to download all objects in a session.
受信機は、配達サービスモデルに応じて異なる動作をすることができます。たとえば、オンデマンドサービスモデルの場合、受信機はセッションに参加し、オブジェクトを再現するために必要なパケットを取得してからセッションを去ることができます。別の例として、ストリーミングサービスモデルの場合、レシーバーを継続的にLCTチャネルに結合して、セッション内のすべてのオブジェクトをダウンロードできます。
To be able to participate in a session, a receiver MUST obtain the relevant session description information as listed in Section 6.1.
セッションに参加できるようにするには、セクション6.1にリストされているように、レシーバーは関連するセッションの説明情報を取得する必要があります。
If packet authentication information is present in an LCT header, it SHOULD be used as specified in Section 5.2. To be able to be a receiver in a session, the receiver MUST be able to process the LCT header. The receiver MUST be able to discard, forward, store, or process the other headers and the packet payload. If a receiver is not able to process an LCT header, it MUST drop from the session.
パケット認証情報がLCTヘッダーに存在する場合、セクション5.2で指定されているように使用する必要があります。セッションで受信機になるには、レシーバーがLCTヘッダーを処理できる必要があります。受信者は、他のヘッダーとパケットペイロードを廃棄、転送、保存、または処理できる必要があります。レシーバーがLCTヘッダーを処理できない場合、セッションからドロップする必要があります。
To be able to participate in a session, a receiver MUST implement the congestion control protocol specified in the session description using the Congestion Control Information field provided in the LCT header. If a receiver is not able to implement the congestion control protocol used in the session, it MUST NOT join the session. When the session is transmitted on multiple LCT channels, receivers MUST initially join channels according to the specified startup behavior of the congestion control protocol. For a multiple rate congestion control protocol that uses multiple channels, this typically means that a receiver will initially join only a minimal set of LCT channels, possibly a single one, that in aggregate are carrying packets at a low rate. This rule has the purpose of preventing receivers from starting at high data rates.
セッションに参加できるようにするには、受信者は、LCTヘッダーに記載されている渋滞制御情報フィールドを使用して、セッション説明で指定された輻輳制御プロトコルを実装する必要があります。受信者がセッションで使用されている混雑制御プロトコルを実装できない場合、セッションに参加してはなりません。セッションが複数のLCTチャネルで送信される場合、受信機は最初に輻輳制御プロトコルの指定されたスタートアップ動作に従ってチャネルに参加する必要があります。複数のチャネルを使用する複数のレートの混雑制御プロトコルの場合、これは通常、受信者が最初に最小限のLCTチャネル、おそらく単一のセットのみに参加することを意味します。このルールには、レシーバーが高いデータレートで開始するのを防ぐ目的があります。
Several objects can be carried either sequentially or concurrently within the same LCT session. In this case, each object is identified by a unique TOI. Note that even if a server stops sending packets for an old object before starting to transmit packets for a new object, both the network and the underlying protocol layers can cause some reordering of packets, especially when sent over different LCT channels, and thus receivers SHOULD NOT assume that the reception of a packet for a new object means that there are no more packets in transit for the previous one, at least for some amount of time.
いくつかのオブジェクトは、同じLCTセッション内で順番にまたは同時に携帯することができます。この場合、各オブジェクトは一意のTOIによって識別されます。サーバーが新しいオブジェクトのパケットを送信し始める前に古いオブジェクトのパケットの送信を停止した場合でも、ネットワークと基礎となるプロトコルレイヤーの両方が、特に異なるLCTチャネルで送信される場合、パケットの並べ替えを引き起こす可能性があることに注意してください。新しいオブジェクトのパケットの受信は、少なくともある程度の時間は、前のパケットのパケットがこれ以上ないことを意味すると仮定しないでください。
A receiver MAY be concurrently joined to multiple LCT sessions from one or more senders. The receiver MUST perform congestion control on each such LCT session. If the congestion control protocol allows the receiver some flexibility in terms of its actions within a session, then the receiver MAY make choices to optimize the packet flow performance across the multiple LCT sessions, as long as the receiver still adheres to the congestion control rules for each LCT session individually.
レシーバーは、1つ以上の送信者からの複数のLCTセッションに同時に結合される場合があります。受信者は、このようなLCTセッションごとに混雑制御を実行する必要があります。輻輳制御プロトコルがセッション内のアクションに関して受信者にある程度の柔軟性を可能にする場合、受信者は、受信者がまだ渋滞制御ルールを順守している限り、複数のLCTセッション全体でパケットフローパフォーマンスを最適化するために選択することができます。各LCTセッションは個別に。
As described in [RFC3048], LCT is a building block that is intended to be used, in conjunction with other building blocks, to help specify a protocol instantiation. A congestion control building block that uses the Congestion Control information field within the 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を使用するプロトコルインスタンス化によって使用する必要があります。信頼性のビルディングブロックなど、他のビルディングブロックも使用できます。
The congestion control MUST be applied to the LCT session as an entity, i.e., over the aggregate of the traffic carried by all of the LCT channels associated with the LCT session. The Congestion Control Information field in the LCT header is an opaque field that is reserved to carry information related to congestion control. There MAY also be congestion control Header Extension fields that carry additional information related to congestion control.
輻輳制御は、エンティティとしてLCTセッションに適用する必要があります。つまり、LCTセッションに関連付けられたすべてのLCTチャネルによって運ばれるトラフィックの集合体にわたって適用する必要があります。LCTヘッダーの輻輳制御情報フィールドは、混雑制御に関連する情報を運ぶために予約されている不透明なフィールドです。また、混雑制御に関連する追加情報を運ぶ混雑制御ヘッダー拡張フィールドもある場合があります。
The particular layered encoder and congestion control protocols used with LCT have an impact on the performance and applicability of LCT. For example, some layered encoders used for video and audio streams can produce a very limited number of layers, thus providing a very coarse control in the reception rate of packets by receivers in a session. When LCT is used for reliable data transfer, some FEC codecs are inherently limited in the size of the object they can encode, and for objects larger than this size the reception overhead on the receivers can grow substantially.
LCTで使用される特定の層状エンコーダーおよび輻輳制御プロトコルは、LCTのパフォーマンスと適用性に影響を与えます。たとえば、ビデオストリームやオーディオストリームに使用される一部のレイヤードエンコーダーは、非常に限られた数のレイヤーを生成する可能性があるため、セッションで受信機によるパケットの受信率に非常に粗いコントロールが提供されます。LCTが信頼できるデータ転送に使用される場合、一部のFECコーデックは、エンコードできるオブジェクトのサイズが本質的に制限されており、このサイズよりも大きいオブジェクトの場合、レシーバーのオーバーヘッドは大幅に成長できます。
A more in-depth description of the use of FEC in Reliable Multicast Transport (RMT) protocols is given in [RFC3453]. Some of the FEC codecs that MAY be used in conjunction with LCT for reliable content delivery are specified in [RFC5052]. The Codepoint field in the LCT header is an opaque field that can be used to carry information related to the encoding of the packet payload.
[RFC3453]には、信頼性の高いマルチキャスト輸送（RMT）プロトコルにおけるFECの使用に関するより詳細な説明が示されています。信頼できるコンテンツ配信のためにLCTと併せて使用できるFECコーデックの一部は、[RFC5052]で指定されています。LCTヘッダーのCodePointフィールドは、パケットペイロードのエンコードに関連する情報を携帯するために使用できる不透明なフィールドです。
LCT also requires receivers to obtain a session description, as described in Section 6.1. The session description could be in a form such as SDP as defined in [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.
LCTでは、セクション6.1で説明されているように、受信機にセッションの説明を取得する必要があります。セッションの説明は、[RFC4566]で定義されているSDPなどの形式、または特定のアプリケーションに適した別の形式などの形式であり、[RFC2974]で定義されたSAP、HTTP、またはその他の方法で配布することができます。認証プロトコルを使用して、セッションの説明を受信機に配信して、正しいセッションの説明が届くようにすることをお勧めします。
It is RECOMMENDED that LCT implementors use some packet authentication scheme to protect the protocol from attacks. An example of a possibly suitable scheme is described in [Perrig2001].
LCT実装者は、プロトコルを攻撃から保護するために、パケット認証スキームを使用することをお勧めします。おそらく適切なスキームの例は、[perrig2001]で説明されています。
Some protocol instantiations that use LCT MAY use building blocks that require the generation of feedback from the receivers to the sender. However, the mechanism for doing this is outside the scope of LCT.
LCTを使用する一部のプロトコルインスタンス化は、受信機から送信者へのフィードバックの生成を必要とするビルディングブロックを使用する場合があります。ただし、これを行うメカニズムはLCTの範囲外です。
LCT is a building block as defined in [RFC3048] and as such does not define a complete protocol. Protocol instantiations that use the LCT building block MUST address the potential vulnerabilities described in the following sections. For an example, see [ALC-PI].
LCTは[RFC3048]で定義されているビルディングブロックであり、そのため、完全なプロトコルを定義しません。LCTビルディングブロックを使用するプロトコルインスタンス化は、次のセクションで説明する潜在的な脆弱性に対処する必要があります。たとえば、[ALC-PI]を参照してください。
Protocol instantiations could address the vulnerabilities described below by taking measures to prevent receivers from accepting incorrect packets, for example, by using a source authentication and content integrity mechanism. See also Sections 6.2 and 7 for discussion of packet authentication requirements.
プロトコルのインスタンス化は、たとえば、ソース認証とコンテンツの整合性メカニズムを使用して、受信機が誤ったパケットを受け入れるのを防ぐための措置を講じることにより、以下の脆弱性に対処できます。パケット認証要件の説明については、セクション6.2および7も参照してください。
Note that for correct operation, LCT assumes availability of session description information (see Sections 4 and 7). Incorrect or maliciously modified session description information may result in receivers being unable to correctly receive the session content, or that receivers inadvertently try to receive at a much higher rate than they are capable of, thereby disrupting traffic in portions of the network. Protocol instantiations MUST address this potential vulnerability, for example, by providing source authentication and integrity mechanisms for the session description. Additionally, these mechanisms MUST allow the receivers to securely verify the correspondence between session description and LCT data packets.
正しい操作のために、LCTはセッションの説明情報の可用性を想定していることに注意してください（セクション4および7を参照）。誤ったまたは悪意のあるセッションの説明情報は、受信者がセッションコンテンツを正しく受信できない場合、または受信者が誤って能力よりもはるかに高いレートで受信しようとする可能性があります。プロトコルのインスタンス化は、たとえば、セッションの説明にソース認証と整合性メカニズムを提供することにより、この潜在的な脆弱性に対処する必要があります。さらに、これらのメカニズムは、受信機がセッションの説明とLCTデータパケットの間の対応を安全に検証できるようにする必要があります。
The following sections consider further each of the services provided by LCT.
次のセクションでは、LCTが提供する各サービスをさらに検討します。
The Transport Session Identifier and the Transport Object Identifier in the LCT header provide for multiplexing of sessions and objects. Modification of these fields by an attacker could have the effect of depriving a session or object of data and potentially directing incorrect data to another session or object, in both cases effecting a denial-of-service attack.
LCTヘッダーのトランスポートセッション識別子とトランスポートオブジェクト識別子は、セッションとオブジェクトの多重化を提供します。攻撃者によるこれらのフィールドの変更は、データのセッションまたはオブジェクトを奪い、両方の場合に誤った攻撃を行うことにおいて、別のセッションまたはオブジェクトに誤ったデータを潜在的に向ける可能性があります。
Additionally, injection of forged packets with fake TSI or TOI values may cause receivers to allocate resources for additional sessions or objects, again potentially effecting a DoS attack.
さらに、偽のTSI値またはTOI値を使用した偽造パケットを注入すると、受信機が追加のセッションまたはオブジェクトにリソースを割り当て、DOS攻撃に潜在的に影響を与える可能性があります。
The Close Object and Close Session bits in the LCT header provide for signaling of the end of a session or object. Modification of these fields by an attacker could cause receivers to incorrectly behave as if the session or object had ended, resulting in a denial-of-service attack, or conversely to continue to unnecessarily utilize resources after the session or object has ended (although resource utilization in this case is largely an implementation issue).
LCTヘッダーのクローズオブジェクトとクローズセッションビットは、セッションまたはオブジェクトの終了のシグナリングを提供します。攻撃者によるこれらのフィールドの変更により、受信機がセッションまたはオブジェクトが終了したかのように誤って振る舞う可能性があり、サービス拒否攻撃になります。この場合の利用は、主に実装の問題です）。
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms).
上記の脆弱性の結果として、これらのフィールドは、プロトコルインスタンス化セキュリティメカニズム（たとえば、ソース認証とデータの整合性メカニズムなど）によって保護する必要があります。
The SCT and ERT mechanisms provide rudimentary time synchronization features which can both be subject to attacks. Indeed an attacker can easily de-synchronize clients, sending erroneous SCT information, or mount a DoS attack by informing all clients that the session (respectively, a particular object) is about to be closed.
SCTおよびERTメカニズムは、両方とも攻撃の影響を受ける可能性のある初歩的な時間同期機能を提供します。実際、攻撃者はクライアントを簡単に非表示にしたり、誤ったSCT情報を送信したり、すべてのクライアントにセッション（それぞれ特定のオブジェクト）が閉じようとしていることを通知することでDOS攻撃を実施できます。
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms).
上記の脆弱性の結果として、これらのフィールドは、プロトコルインスタンス化セキュリティメカニズム（たとえば、ソース認証とデータの整合性メカニズムなど）によって保護する必要があります。
The LCT protocol provides for transport of information for other building blocks, specifically the PSI field for the protocol instantiation, the Congestion Control field for the Congestion Control building block, the Codepoint field for the FEC building block, the EXT-AUTH Header Extension (used by the protocol instantiation) and the packet payload itself.
LCTプロトコルは、他のビルディングブロックの情報の輸送、特にプロトコルインスタンス化のPSIフィールド、混雑制御構築ブロックの輻輳制御フィールド、FECビルディングブロックのコードポイントフィールド、エクストーオーストヘッダー拡張機能（プロトコルのインスタンス化によって）およびパケットペイロード自体。
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またはパケットペイロードの変更は、再構成の成功を防ぐか、受信機によるオブジェクトの大部分の不正確な再構築を引き起こす可能性があります。輻輳制御フィールドの変更により、受信機は間違った速度で受信しようとする可能性があり、潜在的に悪化したり、混雑の状況を引き起こしたり、DOS攻撃をもたらしたりすることがあります。
As a result of the above vulnerabilities, these fields MUST be protected by protocol instantiation security mechanisms (for example, source authentication and data integrity mechanisms).
上記の脆弱性の結果として、これらのフィールドは、プロトコルインスタンス化セキュリティメカニズム（たとえば、ソース認証とデータの整合性メカニズムなど）によって保護する必要があります。
This document defines a new namespace for "LCT Header Extension Types". Values in this namespace are integers between 0 and 255 (inclusive).
このドキュメントでは、「LCTヘッダー拡張タイプ」の新しい名前空間を定義します。この名前空間の値は、0〜255（包括的）の整数です。
Values in the range 0 to 63 (inclusive) are reserved for use for variable-length LCT Header Extensions and assignments shall be made through "IETF Review" as defined in [RFC5226].
範囲0〜63（包括的）の値は、[RFC5226]で定義されているように、「IETFレビュー」を通じて、可変長さのLCTヘッダー拡張機能に使用するために予約されています。
Values in the range 64 to 127 (inclusive) are reserved for variable-length LCT Header Extensions and assignments shall be made on the "Specification Required" basis as defined in [RFC5226].
範囲64〜127（包括的）の値は、[RFC5226]で定義されているように、変数長さのLCTヘッダー拡張および割り当てを「必要な仕様」ベースで行う必要があります。
Values in the range 128 to 191 (inclusive) are reserved for use for fixed-length LCT Header Extensions and assignments shall be made through "IETF Review" as defined in [RFC5226].
範囲128から191（包括的）の値は、固定長ヘッダー拡張機能に使用するために予約されており、[RFC5226]で定義されている「IETFレビュー」を通じて割り当てが行われます。
Values in the range 192 to 255 (inclusive) are reserved for fixed-length LCT Header Extensions and assignments shall be made on the "Specification Required" basis as defined in [RFC5226].
範囲192〜255（包括的）の値は、固定長LCTヘッダー拡張機能のために予約されており、[RFC5226]で定義されているように、「仕様が必要」に基づいて割り当てが行われます。
Initial values for the LCT Header Extension Type registry are defined in Section 9.2.
LCTヘッダー拡張タイプレジストリの初期値は、セクション9.2で定義されています。
Note that the previous Experimental version of this specification reserved values in the ranges [64, 127] and [192, 255] for PI-specific LCT Header Extensions. In the interest of simplification and since there were no overlapping allocations of these LCT Header Extension Type values by PIs, this document specifies a single flat space for LCT Header Extension Types.
この仕様の以前の実験バージョンは、PI固有のLCTヘッダー拡張機能の範囲[64、127]および[192、255]の範囲[192、255]に予約されていることに注意してください。簡素化のために、PISによるこれらのLCTヘッダー拡張タイプの値の重複割り当てがなかったため、このドキュメントはLCTヘッダー拡張タイプの単一のフラットスペースを指定します。
This document registers three values in the LCT Header Extension Type namespace as follows:
このドキュメントは、次のように、LCTヘッダーエクステンションタイプの名前空間の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の著者によるものです。ブルース・ルッケンホフ、ヘイダー・ラダ、ジャスティン・チャプウェスケもRFC 3451に貢献しました。
This section summarizes the changes that were made from the Experimental version of this specification published as RFC 3451 [RFC3451]:
このセクションでは、RFC 3451 [RFC3451]として公開されたこの仕様の実験バージョンから作成された変更を要約します。
o Removed the 'Statement of Intent' from the introduction. (The statement of intent was meant to clarify the "Experimental" status of RFC 3451.)
o はじめに「意図の声明」を削除しました。（意図の声明は、RFC 3451の「実験的」ステータスを明確にすることを目的としていました。）
o Inclusion of material from ALC that is applicable in the more general LCT context.
o より一般的なLCTコンテキストに適用可能なALCからの材料を含める。
o Creation of an IANA registry for LCT Header Extensions.
o LCTヘッダー拡張機能のIANAレジストリの作成。
o Allocation of the 2 'reserved' bits in the LCT header as "Protocol-Specific Indication" - usage to be defined by protocol instantiations.
o 「プロトコル固有の適応」としてLCTヘッダーに2つの「予約済み」ビットを割り当てる - プロトコルインスタンス化によって定義される使用法。
o Removal of the Sender Current Time and Expected Residual Time LCT header fields.
o 送信者の現在の時間と予想される残留時間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を置き換え、タイミング機能の将来の拡張を提供するために、新しいヘッダー拡張機能ext_timeを含める。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052] Watson、M.、Luby、M.、およびL. Vicisano、「フォワードエラー補正（FEC）ビルディングブロック」、RFC 5052、2007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[ALC-PI] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", Work in Progress, September 2009.
[ALC-PI] Luby、M.、Watson、M。、およびL. Vicisano、「非同期層コーディング（ALC）プロトコルインスタンス化」、2009年9月、進行中の作業。
[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.、およびA. Rege、「バルクデータの信頼できる分布への噴水アプローチ」、Proceedings ACM Sigcomm'98、バンクーバー、カナダ、1998年9月。
[BYE2000] Byers, J., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., Rotter, A., and W. Shaver, "FLID-DL: Congestion Control for Layered Multicast", Proceedings of Second International Workshop on Networked Group Communications (NGC 2000), Palo Alto, CA, November 2000.
[Bye2000] Byers、J.、Frumin、M.、Horn、G.、Luby、M.、Mitzenmacher、M.、Rotter、A。、およびW. Shaver、 "Flid-dl：層状マルチキャストの混雑制御"、2000年11月、カリフォルニア州パロアルトのネットワークグループコミュニケーション（NGC 2000）に関する第2回国際ワークショップの議事録。
[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。、およびJ. Gray、「Fcast Multicast File Distribution」、IEEE Network、Vol。14、No。1、pp。58-68、2000年1月。
[Perrig2001] Perrig, A., Canetti, R., Song, D., and J. Tyger, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[Perrig2001] Perrig、A.、Canetti、R.、Song、D。、およびJ. Tyger、「マルチキャストの効率的かつ安全なソース認証」、ネットワークおよび分散システムセキュリティシンポジウム、NDSS 2001、pp。35-46、2月2001年。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装」、RFC 1305、1992年3月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357] Mankin、A.、Romanov、A.、Bradner、S。、およびV. Paxson、「信頼できるマルチキャスト輸送およびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048] Whetten、B.、Vicisano、L.、Kermode、R.、Handley、M.、Floyd、S。、およびM. Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269] Kermode、R。およびL. Vicisano、「信頼できるマルチキャスト輸送（RMT）ビルディングブロックとプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、2002年4月。
[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。、およびJ. Crowcroft、「レイヤードコーディング輸送（LCT）ビルディングブロック」、RFC 3451、2002年12月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738] Luby、M。およびV. Goyal、「波と方程式ベースのレート制御（WEBRC）ビルディングブロック」、RFC 3738、2004年4月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、2006年8月。
[RIZ1997a] Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, April 1997.
[Riz1997a] Rizzo、L。、「信頼できるコンピューター通信プロトコルの効果的な消去コード」、ACM Sigcomm Computer Communication Review、Vol.27、No.2、pp.24-36、1997年4月。
[RIZ1997b] Rizzo, L. and L. Vicisano, "Reliable Multicast Data Distribution protocol based on software FEC techniques", Proceedings of the Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communication Systems, HPCS'97, Chalkidiki Greece, June 1997.
[Riz1997b] Rizzo、L。およびL. Vicisano、「ソフトウェアFEC技術に基づく信頼できるマルチキャストデータ分布プロトコル」、高性能通信システムのアーキテクチャと実装に関する第4回IEEEワークショップの議事録、HPCS'97、Chalkidiki Greece、6月1997年。
[RIZ2000] Rizzo, L., "PGMCC: A TCP-friendly single-rate multicast congestion control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August 2000.
[Riz2000] Rizzo、L。、「PGMCC：TCPフレンドリーなシングルレートマルチキャスト混雑制御スキーム」、Sigcomm 2000の議事録、2000年8月、ストックホルムスウェーデンの議事録。
[VIC1998] Vicisano, L., Rizzo, L., and J. Crowcroft, "TCP-like Congestion Control for Layered Multicast Data Transfer", IEEE Infocom'98, San Francisco, CA, March 1998.
[VIC1998] Vicisano、L.、Rizzo、L。、およびJ. Crowcroft、「層状マルチキャストデータ転送のためのTCP様うっ血制御」、IEEE InfoCom'98、サンフランシスコ、CA、1998年3月。
Authors' Addresses
著者のアドレス
Michael Luby Qualcomm, Inc. 3165 Kifer Rd. Santa Clara, CA 95051 US
Michael Luby Qualcomm、Inc。3165 Kifer Rd。サンタクララ、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。サンタクララ、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。サンタクララ、CA 95051 US
EMail: vicisano@qualcomm.com