[要約] 要約：RFC 5325は、Licklider Transmission Protocol（LTP）の動機を説明しています。LTPは、不確実なネットワーク環境での信頼性の高いデータ転送を可能にするプロトコルです。目的：RFC 5325の目的は、LTPの開発と普及を促進し、不確実なネットワーク環境での信頼性の高いデータ転送を実現することです。
Network Working Group S. Burleigh
Request for Comments: 5325 NASA/Jet Propulsion Laboratory
Category: Informational M. Ramadas
ISTRAC, ISRO
S. Farrell
Trinity College Dublin
September 2008
Licklider Transmission Protocol - Motivation
Licklider送信プロトコル - 動機付け
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. It represents the consensus of the Delay Tolerant Networking (DTN) Research Group of the Internet Research Task Force (IRTF). See RFC 3932 for more information.
このRFCは、インターネット標準のレベルの候補者ではありません。これは、インターネット研究タスクフォース（IRTF）の遅延耐性ネットワーキング（DTN）研究グループのコンセンサスを表しています。詳細については、RFC 3932を参照してください。
Abstract
概要
This document describes the motivation for the development of the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.
このドキュメントでは、非常に長いメッセージラウンドトリップ時間（RTT）および/または接続の頻繁な中断を特徴とするリンクに対する再送信ベースの信頼性を提供するように設計されたLicklider Transmission Protocol（LTP）の開発の動機について説明します。惑星間空間全体の通信はこの種の環境の最も顕著な例であるため、LTPは主に惑星間空間での「長距離」信頼できる送信をサポートすることを目的としていますが、他の環境にも用途があります。
In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes.
バンドルプロトコルを展開する惑星間インターネット設定では、LTPはシングルホップディープスペース無線周波数（RF）リンクを介した信頼できる収束層として機能することを目的としています。LTPは、Selective-cnowledmentの受信レポートを勧誘することにより、データ送信の自動リピートリクエスト（ARQ）を実行します。それはステートフルであり、交渉や握手はありません。
This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
このドキュメントは、遅延耐性ネットワーキング研究グループの製品であり、そのグループによってレビューされています。RFCとしての出版に対する異議は提起されませんでした。
Table of Contents
目次
1. Introduction ....................................................2
2. Problem .........................................................3
2.1. IPN Operating Environment ..................................3
2.2. Why Not TCP or SCTP? .......................................5
3. Protocol Overview ...............................................6
3.1. Nominal Operation ..........................................6
3.1.1. Link State Cues .....................................9
3.1.2. Deferred Transmission ...............................9
3.1.3. Timers .............................................10
3.2. Retransmission ............................................13
3.3. Accelerated Retransmission ................................16
3.4. Session Cancellation ......................................17
4. Security Considerations ........................................17
5. IANA Considerations ............................................20
6. Acknowledgments ................................................20
7. References .....................................................20
7.1. Informative References ....................................20
The Licklider Transmission Protocol (LTP) is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times and/or frequent interruptions in connectivity. Communication in interplanetary space is the most prominent example of this sort of environment, and LTP is principally aimed at supporting "long-haul" reliable transmission over deep-space RF links. Specifically, LTP is intended to serve as a reliable "convergence layer" protocol, underlying the Delay-Tolerant Networking (DTN) [DTN] Bundle protocol [BP], in DTN deployments where data links are characterized by very long round-trip times.
Licklider Transmission Protocol（LTP）は、非常に長いメッセージの往復時間や接続性の頻繁な中断を特徴とするリンクよりも再送信ベースの信頼性を提供するように設計されています。惑星間空間での通信は、この種の環境の最も顕著な例であり、LTPは主に、ディープスペースRFリンクを介した「長距離」信頼できる送信をサポートすることを目的としています。具体的には、LTPは、遅延耐性ネットワーキング（DTN）[DTN]バンドルプロトコル[BP]の根底にある信頼できる「収束層」プロトコルとして機能することを目的としています。
This document describes the motivation for LTP, its features, functions, and overall design. It is part of a series of documents describing LTP. Other documents in the series include the main protocol specification document [LTPSPEC] and the protocol extensions document [LTPEXT].
このドキュメントでは、LTPの動機、その機能、機能、および全体的な設計について説明しています。LTPを説明する一連のドキュメントの一部です。シリーズのその他のドキュメントには、メインプロトコル仕様ドキュメント[LTPSPEC]およびプロトコル拡張ドキュメント[LTPEXT]が含まれます。
The protocol is named in honor of ARPA/Internet pioneer JCR Licklider.
このプロトコルは、ARPA/インターネットパイオニアJCR Lickliderに敬意を表して命名されています。
There are a number of fundamental differences between the environment for terrestrial communications (such as seen in the Internet) and the operating environments envisioned for the Interplanetary Internet (IPN) [IPN].
地上通信の環境（インターネットに見られるなど）と、惑星間インターネット（IPN）[IPN]に想定される操作環境との間には、多くの根本的な違いがあります。
The most challenging difference between communication among points on Earth and communication among planets is round-trip delay, of which there are two main sources, both relatively intractable: physics and economics.
地球上のポイント間のコミュニケーションと惑星間のコミュニケーションの間の最も挑戦的な違いは、往復遅延であり、そのうちの2つの主要なソースがあります。
The more obvious type of delay imposed by nature is signal propagation time. Round-trip times between Earth and Jupiter's moon Europa, for example, run between 66 and 100 minutes.
本質的に課されるより明白なタイプの遅延は、信号伝播時間です。たとえば、地球と木星の月ヨーロッパの間の往復時間は、66〜100分です。
Less obvious and more dynamic is the delay imposed by occultation. Communication between planets must be by radiant transmission, which is usually possible only when the communicating entities are in line of sight of each other. During the time that communication is impossible, delivery is impaired and messages must wait in a queue for later transmission.
あまり明白ではなく、よりダイナミックでは、オカルトによって課される遅延です。惑星間のコミュニケーションは放射伝達によるものでなければなりません。これは、通常、通信エンティティが互いに並んでいる場合にのみ可能です。通信が不可能である間、配信が損なわれ、メッセージは後の送信のためにキューで待つ必要があります。
Round-trip times and occultations can at least be readily computed given the ephemerides of the communicating entities. Additional delay that is less easily predictable is introduced by discontinuous transmission support, which is rooted in economics.
通信エンティティのエフェメリデスを考えると、往復時間と潜在性は少なくとも容易に計算できます。あまり容易に予測できない追加の遅延は、経済学に根ざした不連続な送信サポートによって導入されます。
Communicating over interplanetary distances requires expensive special equipment: large antennas, high-performance receivers, etc.
惑星間距離で通信するには、大規模なアンテナ、高性能レシーバーなど、高価な特別な機器が必要です。
For most deep-space missions, even non-NASA ones, these are currently provided by NASA's Deep Space Network (DSN) [DSN]. The communication resources of the DSN are currently oversubscribed and will probably remain so for the foreseeable future. Radio contact via the DSN must therefore be carefully scheduled and is often severely limited.
ほとんどのディープスペースミッション、非NASAミッションでさえ、これらは現在NASAのディープスペースネットワーク（DSN）[DSN]によって提供されています。DSNの通信リソースは現在、過度にサブスクライブされており、おそらく近い将来にはそうであるでしょう。したがって、DSNを介した無線接触は慎重にスケジュールされる必要があり、しばしば厳しく制限されています。
This over-subscription means that the round-trip times experienced by packets will be affected not only by the signal propagation delay and occultation, but also by the scheduling and queuing delays imposed by the management of Earth-based resources: packets to be sent to a given destination may have to be queued until the next scheduled contact period, which may be hours, days, or even weeks away.
この過剰サブスクリプションは、パケットが経験する往復時間が、信号伝播の遅延とオカルト化だけでなく、地球ベースのリソースの管理によって課されるスケジューリングとキューイングの遅延によっても影響を受けることを意味します。特定の目的地は、次のスケジュールされた連絡先まで列に並ぶ必要があります。これは、数時間、数日、または数週間先になる場合があります。
These operating conditions imply a number of additional constraints on any protocol designed to ensure reliable communication over deep-space links.
これらの動作条件は、ディープスペースリンクを介した信頼できる通信を確保するために設計されたプロトコルに対する多くの追加の制約を意味します。
- Long round-trip times mean substantial delay between the transmission of a block of data and the reception of an acknowledgment from the block's destination, signaling arrival of the block. If LTP postponed transmission of additional blocks of data until it received acknowledgment of the arrival of all prior blocks, valuable opportunities to utilize what little deep-space transmission bandwidth is available would be forever lost. Multiple parallel data block transmission "sessions" must be in progress concurrently in order to avoid under-utilization of the links.
- 長い往復時間は、データのブロックの送信とブロックの宛先からの確認の受信との間の大幅な遅延、ブロックの到着を意味します。LTPがすべての以前のブロックの到着を認められるまで、追加のデータブロックの送信を延期した場合、小さな深海伝送帯域幅が利用可能なものを利用する貴重な機会は永遠に失われます。複数の並列データブロック送信「セッション」は、リンクの過少利用を避けるために同時に進行する必要があります。
- Like any reliable transport service employing ARQ, LTP is "stateful". In order to ensure the reception of a block of data it has sent, LTP must retain for possible retransmission all portions of that block that might not have been received yet. In order to do so, it must keep track of which portions of the block are known to have been received so far and which are not, together with any additional information needed for purposes of retransmitting part or all of that block.
- ARQを採用している信頼できる輸送サービスと同様に、LTPは「ステートフル」です。送信したデータブロックの受信を確保するために、LTPは、まだ受信されていない可能性のあるすべての部分を再送信するために保持する必要があります。そうするためには、ブロックのどの部分がこれまでに受信されたことが知られているかを追跡する必要があり、どちらではないかは、そのブロックの一部またはすべてを再送信するために必要な追加情報とともにそうではありません。
- In the IPN, round-trip times may be so long and communication opportunities so brief that a negotiation exchange, such as an adjustment of transmission rate, might not be completed before connectivity is lost. Even if connectivity is uninterrupted, waiting for negotiation to complete before revising data transmission parameters might well result in costly under-utilization of link resources.
- IPNでは、往復時間は非常に長く、コミュニケーションの機会が非常に短いため、送信レートの調整などの交渉交換は、接続が失われる前に完了しない可能性があります。接続性が中断されていなくても、データ送信パラメーターを改訂する前に交渉が完了するのを待つと、リンクリソースが費用がかかる可能性があります。
- Another respect in which LTP differs from TCP is that, while TCP connections are bidirectional (blocks of application data may be flowing in both directions on any single connection), LTP sessions are unidirectional. This design decision derives from the fact that the flow of data in deep-space flight missions is usually unidirectional. (Long round-trip times make interactive spacecraft operation infeasible, so spacecraft are largely autonomous and command traffic is very light.) Bidirectional data flow, where possible, is performed using two unidirectional links in opposite directions and at different data rates.
- LTPがTCPと異なる別の点では、TCP接続は双方向であるが（アプリケーションデータのブロックが単一の接続で両方向に流れる可能性がある）、LTPセッションは単方向であるということです。この設計上の決定は、ディープスペースの飛行ミッションにおけるデータの流れが通常一方向であるという事実に由来します。（長い往復時間はインタラクティブな宇宙船の操作を実行不可能にするため、宇宙船は大部分が自律的であり、コマンドトラフィックは非常に軽いです。）可能であれば、双方向データフローは、反対方向と異なるデータレートで2つの単方向リンクを使用して実行されます。
- Finally, the problem of timeout interval computation in the environment for which LTP is mainly intended is different from the analogous problem in the Internet. Since multiple sessions can be conducted in parallel, retardation of transmission on any single session while awaiting a timeout need not degrade communication performance on the association as a whole. Timeout intervals that would be intolerably optimistic in TCP don't necessarily degrade LTP's bandwidth utilization.
- 最後に、LTPが主に意図されている環境でのタイムアウト間隔計算の問題は、インターネットの類似の問題とは異なります。複数のセッションは並行して実施できるため、タイムアウトを待っている間、任意のセッションで送信を遅らせる必要はありません。TCPで耐えられるほど楽観的であるタイムアウト間隔は、必ずしもLTPの帯域幅の利用を分解するわけではありません。
But the reciprocal half-duplex nature of LTP communication makes it infeasible to use statistical analysis of round-trip history as a means of predicting round-trip time. The round-trip time for transmitted segment N could easily be orders of magnitude greater than that for segment N-1 if there happened to be a transient loss of connectivity between the segment transmissions. A different mechanism for timeout interval computation is needed.
しかし、LTP通信の相互半二重性の性質により、往復時間を予測する手段として往復履歴の統計分析を使用することは実行不可能です。送信されたセグメントnの往復時間は、セグメント送信の間に一時的な接続の損失があった場合、セグメントn-1の往復時間よりも簡単に大きくなる可能性があります。タイムアウト間隔計算のための別のメカニズムが必要です。
These environmental characteristics -- long and highly variable delays, intermittent connectivity, and relatively high error rates -- make using unmodified TCP for end-to-end communications in the IPN infeasible. Using the TCP throughput equation from [TFRC] we can calculate the loss event rate (p) required to achieve a given steady-state throughput. Assuming the minimum RTT to Mars from planet Earth is 8 minutes (one-way speed of light delay to Mars at its closest approach to Earth is 4 minutes), assuming a packet size of 1500 bytes, assuming that the receiver acknowledges every other packet, and ignoring negligible higher-order terms in p (i.e., ignoring the second additive term in the denominator of the TCP throughput equation), we obtain the following table of loss event rates required to achieve various throughput values.
これらの環境特性 - 長くて非常に多様な遅延、断続的な接続、および比較的高いエラー率 - は、IPNのエンドツーエンド通信に変更されていないTCPを使用して実行不可能にします。[TFRC]のTCPスループット方程式を使用して、特定の定常状態のスループットを達成するために必要な損失イベント率（P）を計算できます。惑星地球からの火星への最小RTTが8分であると仮定すると、レシーバーが他のすべてのパケットを認めていると仮定して、1500バイトのパケットサイズを想定して、地球への最も近いアプローチでの火星への一元配置速度の遅延は4分です）と仮定すると、Pの無視できる高次用語を無視します（つまり、TCPスループット方程式の分母の2番目の添加剤項を無視します）、さまざまなスループット値を達成するために必要な損失イベント率の次の表を取得します。
Throughput Loss event rate (p)
---------- -------------------
10 Mbps 4.68 * 10^(-12)
1 Mbps 4.68 * 10^(-10)
100 Kbps 4.68 * 10^(-8)
10 Kbps 4.68 * 10^(-6)
Note that although multiple losses encountered in a single RTT are treated as a single loss event in the TCP throughput equation [TFRC], such loss event rates are still unrealistic on deep-space links.
単一のRTTで遭遇した複数の損失は、TCPスループット方程式[TFRC]で単一の損失イベントとして扱われますが、このような損失イベント率は、深部スペースリンクではまだ非現実的です。
For the purposes of this discussion, we are not considering the more aggressive TCP throughput equation that characterizes HighSpeed TCP [HSTCP].
この議論の目的のために、高速TCP [HSTCP]を特徴付ける、より積極的なTCPスループット方程式を考慮していません。
The TCP characteristic of an initial three-way handshake for each new connection, followed by slow-start, is a further obstacle, because the delay of the three-way handshake and the additional delay of slow-start could be exorbitant in a long-delay environment.
3方向の握手の遅延とスロースタートの追加の遅延が長期にわたって外交する可能性があるため、新しい接続ごとに最初の3方向握手のTCP特性はさらなる障害です。遅延環境。
The Stream Control Transmission Protocol (SCTP) [SCTP] can multiplex "chunks" (units of application data) for multiple sessions over a single-layer connection (called an 'association' in SCTP terminology) as LTP does, but it still requires multiple round trips prior to transmitting application data for session setup and so clearly does not suit the needs of the IPN operating environment.
ストリーム制御伝送プロトコル（SCTP）[SCTP]は、LTPがそうであるように、単一層接続（SCTP用語の「関連付け」と呼ばれる）で複数のセッションで「チャンク」（アプリケーションデータの単位）を多重化できますが、それでも複数の複数の必要がありますセッションセットアップのためにアプリケーションデータを送信する前の往復では、IPN運用環境のニーズには明らかに適合しません。
The nominal sequence of events in an LTP transmission session is as follows.
LTP送信セッションの一連のイベントは次のとおりです。
Operation begins when a client service instance asks an LTP engine to transmit a block of data to a remote client service instance.
操作は、クライアントサービスインスタンスがLTPエンジンにデータブロックをリモートクライアントサービスインスタンスに送信するように要求するときに始まります。
LTP regards each block of data as comprising two parts: a "red-part", whose delivery must be assured by acknowledgment and retransmission as necessary, followed by a "green-part" whose delivery is attempted, but not assured. The length of either part may be zero; that is, any given block may be designated entirely red (retransmission continues until reception of the entire block has been asserted by the receiver) or entirely green (no part of the block is acknowledged or retransmitted). Thus, LTP can provide both TCP-like and UDP-like functionality concurrently on a single session.
LTPは、データの各ブロックを2つの部分で構成されると見なしています。「赤い部分」。必要に応じて承認と再送信によって配信が保証されなければならない、その後に配信が試みられているが保証されていない「グリーンパート」が続く。どちらの部分の長さがゼロになる場合があります。つまり、特定のブロックは完全に赤く指定される場合があります（再送信は、ブロック全体が受信機によって主張されるまで継続します）または完全に緑色（ブロックの一部は認められないか、再送信されません）。したがって、LTPは、単一のセッションでTCP様およびUDP様の両方の機能を同時に提供できます。
Note that in a red-green block transmission, the red-part data does NOT have any urgency or higher-priority semantics relative to the block's green-part data. The red-part data is merely data for which the user has requested reliable transmission, possibly (though not necessarily) data without which the green-part data may be useless, such as an application-layer header or other metadata.
赤緑色のブロック伝送では、赤い部分データには、ブロックのグリーンパートデータに対する緊急性や優先度のセマンティクスがないことに注意してください。レッドパートデータは、ユーザーが信頼できる送信を要求しているデータ、おそらく（必ずしもそうではない）データであり、アプリケーション層ヘッダーや他のメタデータなど、グリーンパートデータが役に立たない場合があります。
The client service instance uses the LTP implementation's application programming interface to specify to LTP the identity of the remote client service instance to which the data must be transmitted, the location of the data to be transmitted, the total length of data to be transmitted, and the number of leading data bytes that are to be transmitted reliably as "red" data. The sending engine starts a transmission session for this block and notifies the client service instance that the session has been started. Note that LTP communication session parameters are not negotiated but are instead asserted unilaterally, subject to application-level network management activity; the sending engine does not negotiate the start of the session with the remote client service instance's engine.
クライアントサービスインスタンスは、LTP実装のアプリケーションプログラミングインターフェイスを使用して、データを送信する必要があるリモートクライアントサービスインスタンスのID、送信されるデータの位置、送信されるデータの全長、および送信されるデータの長さを指定します。「赤い」データとして確実に送信される主要なデータバイトの数。送信エンジンは、このブロックの送信セッションを開始し、セッションが開始されたことをクライアントサービスインスタンスに通知します。LTP通信セッションのパラメーターは交渉されていませんが、代わりにアプリケーションレベルのネットワーク管理アクティビティを条件として、一方的に主張されていることに注意してください。送信エンジンは、リモートクライアントサービスインスタンスのエンジンとセッションの開始を交渉しません。
The sending engine then initiates the original transmission: it queues for transmission as many data segments as are necessary to transmit the entire block, within the constraints on maximum segment size imposed by the underlying communication service. The last segment of the red-part of the block is marked as the end of red-part (EORP) indicating the end of red-part data for the block, and as a checkpoint (identified by a unique checkpoint serial number) indicating that the receiving engine must issue a reception report upon receiving the segment. The last segment of the block overall is marked end of block (EOB) indicating that the receiving engine can calculate the size of the block by summing the offset and length of the data in the segment.
その後、送信エンジンは元の送信を開始します。これは、基礎となる通信サービスによって課される最大セグメントサイズの制約内で、ブロック全体を送信するために必要な多くのデータセグメントを送信するためのキューです。ブロックのレッドパートの最後のセグメントは、ブロックのレッドパートデータの終了を示す赤部部（EORP）の終わりとしてマークされ、チェックポイント（一意のチェックポイントシリアル番号で識別）としてマークされています。受信エンジンは、セグメントを受け取ったときに受信レポートを発行する必要があります。ブロック全体の最後のセグメントは、ブロックの端（EOB）のマークとマークされています。これは、受信エンジンがセグメント内のデータのオフセットと長さを合計することにより、ブロックのサイズを計算できることを示しています。
LTP is designed to run directly over a data-link layer protocol, but it may instead be deployed directly over UDP in some cases (i.e., for software development or in private local area networks). In either case, the protocol layer immediately underlying LTP is here referred to as the "local data-link layer".
LTPは、データリンクレイヤープロトコルを直接実行するように設計されていますが、代わりにUDP上に直接展開される場合があります（つまり、ソフトウェア開発またはプライベートローカルエリアネットワークで）。どちらの場合でも、LTPのすぐ根底にあるプロトコル層は、ここでは「ローカルデータリンクレイヤー」と呼ばれます。
At the next opportunity, subject to allocation of bandwidth to the queue into which the block data segments were written, the enqueued segments and their lengths are passed to the local data-link layer protocol (which might be UDP/IP) via the API supported by that protocol, for transmission to the LTP engine serving the remote client service instance.
次の機会に、ブロックデータセグメントが記述されたキューに帯域幅の割り当てを条件として、エンキューセグメントとその長さは、サポートされているAPIを介してローカルデータリンクレイヤープロトコル（UDP/IPである可能性がある）に渡されます。そのプロトコルにより、リモートクライアントサービスインスタンスにサービスを提供するLTPエンジンへの送信用。
A timer is started for the EORP, so that it can be retransmitted automatically if no response is received.
EORPのタイマーが開始されるため、応答がない場合は自動的に再送信できます。
The content of each local data-link layer protocol data unit (link-layer frame or UDP datagram) is required to be an integral number of LTP segments, and the local data-link layer protocol is required never to deliver incomplete LTP segments to the receiving LTP engine. When the local data-link layer protocol is UDP, the LTP authentication [LTPEXT] extension should be used to ensure data integrity unless the end-to-end path is one in which either the likelihood of datagram content corruption is negligible (as in some private local area networks) or the consequences of receiving and processing corrupt LTP segments are insignificant (as perhaps during software development). When the LTP authentication extension is not used, LTP requires the local data-link layer protocol to perform integrity checking of all segments received; specifically, the local data-link layer protocol is required to detect any corrupted segments that are received and to discard them silently.
各ローカルデータリンクレイヤープロトコルデータユニット（Link-Layer FrameまたはUDP Datagram）のコンテンツは、積分数のLTPセグメントであるために必要であり、ローカルデータリンクレイヤープロトコルは、不完全なLTPセグメントを提供しないために必要でありません。LTPエンジンの受信。ローカルデータリンクレイヤープロトコルがUDPの場合、エンドツーエンドのパスがデータグラムのコンテンツの可能性が無視できるかのいずれかである場合を除き、LTP認証[LTPext]拡張機能をデータの整合性を確保するために使用する必要があります（一部の場合のようにプライベートローカルエリアネットワーク）または腐敗したLTPセグメントの受信と処理の結果は重要ではありません（おそらくソフトウェア開発中）。LTP認証拡張機能を使用していない場合、LTPは、受信したすべてのセグメントの整合性チェックを実行するためにローカルデータリンクレイヤープロトコルを必要とします。具体的には、受信された破損したセグメントを検出し、静かに廃棄するために、ローカルデータリンクレイヤープロトコルが必要です。
Received segments that are not discarded are passed up to the receiving LTP engine via the API supported by the local data-link layer protocol.
廃棄されていない受信セグメントは、ローカルデータリンクレイヤープロトコルでサポートされているAPIを介して受信LTPエンジンに渡されます。
On reception of the first data segment for the block, the receiving engine starts a reception session for this block and notifies the local instance of the relevant client service that the session has been started. In the nominal case, it receives all segments of the original transmission without error. Therefore, on reception of the EORP data segment, it responds by (a) queuing for transmission to the sending engine a report segment indicating complete reception and (b) delivering the received red-part of the block to the local instance of the client service: on reception of each data segment of the green-part, it responds by immediately delivering the received data to the local instance of the client service.
ブロックの最初のデータセグメントを受信すると、受信エンジンはこのブロックの受信セッションを開始し、関連するクライアントサービスのローカルインスタンスにセッションが開始されたことを通知します。名目上の場合、エラーなしで元の伝送のすべてのセグメントを受信します。したがって、EORPデータセグメントを受信すると、（a）送信エンジンへの送信のためにキューイングすることで応答します。完全な受信を示すレポートセグメントと（b）ブロックのレッドパートをクライアントサービスのローカルインスタンスに配信する：グリーンパートの各データセグメントを受信すると、受信したデータをすぐにクライアントサービスのローカルインスタンスに配信することで応答します。
All delivery of data and protocol event notices to the local client service instance is performed using the LTP implementation's application programming interface.
LTP実装のアプリケーションプログラミングインターフェイスを使用して、データおよびプロトコルイベントの通知のすべての配信がローカルクライアントサービスインスタンスへのインスタンスへの通知が実行されます。
Note that since LTP data flows are unidirectional, LTP's data acknowledgments -- "reception reports" -- can't be piggybacked on data segments as in TCP. They are instead carried in a separate segment type.
LTPデータフローは単方向であるため、LTPのデータ承認（「受信レポート」）は、TCPのようにデータセグメントで豚バックをかけることはできません。代わりに、個別のセグメントタイプで運ばれます。
At the next opportunity, the enqueued report segment is immediately transmitted to the sending engine and a timer is started so that the report segment can be retransmitted automatically if no response is received.
次の機会に、Enqueuedレポートセグメントがすぐに送信エンジンに送信され、応答がない場合にレポートセグメントを自動的に再送信できるようにタイマーが開始されます。
The sending engine receives the report segment, turns off the timer for the EORP, enqueues for transmission to the receiving engine a report-acknowledgment segment, and notifies the local client service instance that the red-part of the block has been successfully transmitted. The session's red-part transmission has now ended.
送信エンジンはレポートセグメントを受信し、EORPのタイマーをオフにし、受信エンジンに送信するためのENQUEUSをレポート継承セグメントに電源としてオフにし、ブロックの赤い部分が正常に送信されたことをローカルクライアントサービスインスタンスに通知します。セッションのレッドパートトランスミッションはこれで終了しました。
At the next opportunity, the enqueued report-acknowledgment segment is immediately transmitted to the receiving engine.
次の機会に、Enqueued Report-cooknowledmentセグメントはすぐに受信エンジンに送信されます。
The receiving engine receives the report-acknowledgment segment and turns off the timer for the report segment. The session's red-part reception has now ended and transmission of the block is complete.
受信エンジンは、レポートの承認セグメントを受信し、レポートセグメントのタイマーをオフにします。セッションのレッドパートレセプションが終了し、ブロックの送信が完了しました。
Establishing a communication link across interplanetary distances may entail hardware configuration changes based on the presumed operational state of the remote communicating entity, for example:
惑星間距離全体に通信リンクを確立するには、リモート通信エンティティの推定される運用状態に基づいてハードウェア構成の変更が必要になる場合があります。
o orienting a directional antenna correctly;
o 方向アンテナを正しく向けます。
o tuning a transponder to pre-selected transmission and/or reception frequencies; and
o 事前に選択されたトランスミッションおよび/または受信周波数へのトランスポンダーを調整します。と
o diverting precious electrical power to the transponder at the last possible moment, and for the minimum necessary length of time.
o 可能な限り最後の瞬間に、そして必要な時間の最小時間に、トランスポンダーに貴重な電力を迂回させます。
We therefore assume that the operating environment in which LTP functions is able to pass information on the link status (termed "link state cues" in this document) to LTP, telling it which remote LTP engine(s) should currently be transmitting to the local LTP engine and vice versa. The operating environment itself must have this information in order to configure communication link hardware correctly.
したがって、LTP機能がリンクステータス（このドキュメントの「リンク状態キュー」と呼ばれる）に関する情報をLTPに渡すことができる動作環境が、現在ローカルに送信されるリモートLTPエンジンが現在どのリモートLTPエンジンに送信されるかを伝えることができると想定しています。LTPエンジンとその逆。通信リンクハードウェアを正しく構成するには、動作環境自体がこの情報を持っている必要があります。
Link state cues also notify LTP when it is and isn't possible to transmit segments. In deep-space communications, at no moment can there ever be any expectation of two-way connectivity. It is always possible for LTP to be generating outbound segments -- in response to received segments, timeouts, or requests from client services -- that cannot immediately be transmitted. These segments must be queued for transmission at a later time when a link has been established, as signaled by a link state cue.
リンク状態のキューは、セグメントを送信することができない場合にLTPに通知します。ディープスペース通信では、双方向の接続性の期待があることはありません。LTPは、受け取ったセグメント、タイムアウト、またはクライアントサービスからのリクエストに応じて、アウトバウンドセグメントを生成することが常に可能です。これらのセグメントは、リンク状態のキューで合図されるように、リンクが確立された後の時期に伝送用にキューに入れる必要があります。
In concept, every outbound LTP segment is appended to one of two queues -- forming a queue-set -- of traffic bound for the LTP engine that is that segment's destination. One such traffic queue is the "internal operations queue" of that queue set; the other is the application data queue for the queue set. The de-queuing of a segment always implies delivering it to the underlying communication system for immediate transmission. Whenever the internal operations queue is non-empty, the oldest segment in that queue is the next segment de-queued for transmission to the destination; at all other times, the oldest segment in the application data queue is the next segment de-queued for transmission to the destination.
概念として、すべてのアウトバウンドLTPセグメントは、そのセグメントの宛先であるLTPエンジンにバインドされたトラフィックの2つのキューのいずれか（キューセットを形成する）に追加されます。そのようなトラフィックキューの1つは、そのキューセットの「内部操作キュー」です。もう1つは、キューセットのアプリケーションデータキューです。セグメントを排除することは、常にそれを基礎となる通信システムに届けるためにそれを即座に送信することを意味します。内部操作のキューが空でないときはいつでも、そのキューで最も古いセグメントは、目的地への送信のために排除される次のセグメントです。他のすべての場合、アプリケーションデータキューで最も古いセグメントは、目的地への送信用に定められた次のセグメントです。
The production and enqueuing of a segment and the subsequent actual transmission of that segment are in principle wholly asynchronous.
セグメントの生産とエンキューとその後のそのセグメントの実際の伝送は、原則として完全に非同期です。
In the event that (a) a transmission link to the destination is currently active and (b) the queue to which a given outbound segment is appended is otherwise empty and (c) either this queue is the internal operations queue or else the internal operations queue is empty, the segment will be transmitted immediately upon production. Transmission of a newly queued segment is necessarily deferred in all other circumstances.
（a）宛先への送信リンクが現在アクティブであり、（b）特定のアウトバウンドセグメントが追加されるキューが空である場合、（c）このキューは内部操作キューまたは内部操作ですキューは空で、セグメントは生産時にすぐに送信されます。新しくキューに囲まれたセグメントの送信は、他のすべての状況で必然的に延期されます。
Conceptually, the de-queuing of segments from traffic queues bound for a given destination is initiated upon reception of a link state cue indicating that the underlying communication system is now transmitting to that destination; i.e., the link to that destination is now active. It ceases upon reception of a link state cue indicating that the underlying communication system is no longer transmitting to that destination; i.e., the link to that destination is no longer active.
概念的には、特定の宛先に縛られた交通キューからのセグメントの排除は、リンク状態のキューを受信すると開始され、基礎となる通信システムが現在その目的地に送信されていることを示しています。つまり、その目的地へのリンクがアクティブになりました。それは、基礎となる通信システムがもはやその目的地に送信されていないことを示すリンク状態のキューを受信すると停止します。つまり、その目的地へのリンクはもはやアクティブではありません。
LTP relies on accurate calculation of expected arrival times for report and acknowledgment segments in order to know when proactive retransmission is required. If a calculated time were even slightly early, the result would be costly unnecessary retransmission. On the other hand, calculated arrival times may safely be several seconds late: the only penalties for late timeout and retransmission are slightly delayed data delivery and slightly delayed release of session resources.
LTPは、積極的な再送信が必要な時期を知るために、レポートおよび承認セグメントの予想される到着時間の正確な計算に依存しています。計算された時間がわずかに早い場合、結果は不必要な再送信に費用がかかります。一方、計算された到着時間は安全に数秒遅れます。遅延タイムアウトと再送信に対する唯一の罰則は、データ配信がわずかに遅れ、セッションリソースのわずかに遅れたリリースです。
Since statistics derived from round-trip history cannot safely be used as a predictor of LTP round-trip times, we have to assume that round-trip timing is at least roughly deterministic -- i.e., that sufficiently accurate RTT estimates can be computed individually in real time from available information.
往復履歴から導出された統計は、LTPラウンドトリップ時間の予測因子として安全に使用できないため、往復タイミングは少なくともほぼ決定論的であると仮定する必要があります。利用可能な情報からのリアルタイム。
This computation is performed in two stages:
この計算は、2つの段階で実行されます。
- We calculate a first approximation of RTT by simply doubling the known one-way light time to the destination and adding an arbitrary margin for any additional anticipated latency, such as queuing and processing delay at both ends of the transmission. For deep-space operations, the margin value is typically a small number of whole seconds. Although such a margin is enormous by Internet standards, it is insignificant compared to the two-way light time component of round-trip time in deep space. We choose to risk tardy retransmission, which will postpone delivery of one block by a relatively tiny increment, in preference to premature retransmission, which will unnecessarily consume precious bandwidth and thereby degrade overall performance.
- 既知の一方向の光時間を宛先に2倍にし、伝送の両端でのキューイングや処理遅延など、予想される追加のレイテンシーに対して任意のマージンを追加するだけで、RTTの最初の近似を計算します。ディープスペース操作の場合、マージン値は通常、少数の秒です。このようなマージンはインターネットの基準では膨大ですが、ディープスペースでの往復時間の双方向の光時間コンポーネントと比較して重要ではありません。遅刻の再送信を危険にさらすことを選択します。これは、比較的小さな増分によって1つのブロックの配信を延期し、早期の再送信を好み、不必要に貴重な帯域幅を消費し、それによって全体的なパフォーマンスを低下させるでしょう。
- Then, to account for the additional delay imposed by interrupted connectivity, we dynamically suspend timers during periods when the relevant remote LTP engines are known to be unable to transmit responses. This knowledge of the operational state of remote entities is assumed to be provided by link state cues from the operating environment.
- 次に、中断された接続によって課される追加の遅延を説明するために、関連するリモートLTPエンジンが応答を送信できないことが知られている期間中にタイマーを動的に停止します。リモートエンティティの運用状態に関するこの知識は、運用環境からのリンク状態のキューによって提供されると想定されています。
The following discussion is the basis for LTP's expected arrival time calculations.
次の議論は、LTPの予想される到着時間計算の基礎です。
The total time consumed in a single "round trip" (transmission and reception of the original segment, followed by transmission and reception of the acknowledging segment) has the following components:
単一の「往復」（元のセグメントの送信と受信、その後に確認セグメントの送信と受信が続く）で合計時間がかかります。次のコンポーネントがあります。
- Protocol processing time: The time consumed in issuing the original segment, receiving the original segment, generating and issuing the acknowledging segment, and receiving the acknowledging segment.
- プロトコル処理時間：元のセグメントの発行、元のセグメントの受信、承認セグメントの生成と発行、および承認セグメントの受信時に時間がかかります。
- Outbound queuing delay: The delay at the sender of the original segment while that segment is in a queue waiting for transmission, and delay at the sender of the acknowledging segment while that segment is in a queue waiting for transmission.
- アウトバウンドキューイングの遅延：元のセグメントの送信者での遅延そのセグメントが送信を待っているキューにあり、そのセグメントが送信を待っているキューにある承認セグメントの送信者での遅延。
- Radiation time: The time that passes while all bits of the original segment are being radiated, and the time that passes while all bits of the acknowledging segment are being radiated. (This is significant only at extremely low data transmission rates.)
- 放射時間：元のセグメントのすべてのビットが放射されている間に通過する時間、および承認セグメントのすべてのビットが放射されている間に通過する時間。（これは、非常に低いデータ送信速度でのみ重要です。）
- Round-trip light time: The signal propagation delay at the speed of light, in both directions.
- 往復光時間：両方向の光の速度での信号伝播遅延。
- Inbound queuing delay: Delay at the receiver of the original segment while that segment is in a reception queue, and delay at the receiver of the acknowledging segment while that segment is in a reception queue.
- インバウンドキューイングの遅延：元のセグメントの受信者での遅延そのセグメントがレセプションキューにあり、そのセグメントがレセプションキューにあるときに、確認セグメントの受信者で遅延します。
- Delay in transmission of the original segment or the acknowledging segment due to loss of connectivity -- that is, interruption in outbound link activity at the sender of either segment due to occultation, scheduled end of tracking pass, etc.
- 接続の喪失による元のセグメントまたは承認セグメントの送信の遅延 - つまり、オカルト、追跡パスのスケジュールされた端など、いずれかのセグメントの送信者でのアウトバウンドリンクアクティビティの中断。
In this context, where errors on the order of seconds or even minutes may be tolerated, protocol processing time at each end of the session is assumed to be negligible.
この文脈では、秒または数分のオーダーのエラーが許容される場合がある場合、セッションの各端でのプロトコル処理時間は無視できると想定されます。
Inbound queuing delay is also assumed to be negligible because, even on small spacecraft, LTP processing speeds are high compared to data transmission rates.
インバウンドキューイングの遅延も無視できると想定されています。なぜなら、小さな宇宙船であっても、LTP処理速度はデータ送信速度と比較して高いからです。
Two mechanisms are used to make outbound queuing delay negligible:
2つのメカニズムを使用して、アウトバウンドキューイングの遅延を無視できるようにします。
- The expected arrival time of an acknowledging segment is not calculated until the moment the underlying communication system notifies LTP that radiation of the original segment has begun. All outbound queuing delay for the original segment has already been incurred at that point.
- 承認セグメントの予想される到着時間は、基礎となる通信システムが元のセグメントの放射が始まったことをLTPに通知する瞬間まで計算されません。元のセグメントのすべてのアウトバウンドキューイング遅延は、その時点ですでに発生しています。
- LTP's deferred transmission model minimizes latency in the delivery of acknowledging segments (reports and acknowledgments) to the underlying communication system. That is, acknowledging segments are (in concept) appended to the internal operations queue rather than the application data queue, so they have higher transmission priority than any other outbound segments, i.e., they should always be de-queued for transmission first. This limits outbound queuing delay for a given acknowledging segment to the time needed to de-queue and radiate all previously generated acknowledging segments that have not yet been de-queued for transmission. Since acknowledging segments are sent infrequently and are normally very small, outbound queuing delay for a given acknowledging segment is likely to be minimal.
- LTPの繰延送信モデルは、基礎となる通信システムへの確認セグメント（レポートと承認）の配信の遅延を最小限に抑えます。つまり、承認セグメントは（概念上）アプリケーションデータキューではなく内部操作キューに追加されているため、他のどのアウトバウンドセグメントよりも伝送の優先度が高くなります。これにより、特定の承認セグメントのアウトバウンドキューイング遅延は、伝送用にまだ定義されていない以前に生成されたすべての確認セグメントを除外して放射するために必要な時間に制限されます。承認セグメントはまれに送信され、通常は非常に小さいため、特定の確認セグメントのアウトバウンドキューイング遅延は最小限である可能性があります。
Deferring calculation of the expected arrival time of the acknowledging segment until the moment at which the original segment is radiated has the additional effect of removing from consideration any original segment transmission delay due to loss of connectivity at the original segment sender.
元のセグメントが放射される瞬間まで、承認セグメントの予想される到着時間の計算を延期することは、元のセグメント送信者での接続の損失による元のセグメント伝送遅延の考慮事項から削除する追加の効果があります。
Radiation delay at each end of the session is simply segment size divided by transmission data rate. It is insignificant except when the data rate is extremely low (for example, 10 bps), in which case the use of LTP may well be inadvisable for other reasons (LTP header overhead, for example, could be too much under such data rates). Therefore, radiation delay is normally assumed to be negligible.
セッションの各端での放射遅延は、単にセグメントサイズを送信データレートで割ったものです。データレートが非常に低い場合（たとえば、10 bps）場合を除き、LTPの使用は他の理由では容認できない場合があります（たとえば、LTPヘッダーオーバーヘッドは、そのようなデータレートでは多すぎる可能性があります）。したがって、放射線遅延は通常無視できると想定されます。
We assume that one-way light time to the nearest second can always be known (for example, provided by the operating environment).
最も近い秒までの一方向の光の時間は、常に既知であると仮定します（たとえば、操作環境によって提供される）。
So the initial expected arrival time for each acknowledging segment is typically computed as simply the current time at the moment that radiation of the original segment begins, plus twice the one-way light time, plus 2*N seconds of margin to account for processing and queuing delays and for radiation time at both ends. N is a parameter set by network management for which 2 seconds seem to be a reasonable default value.
したがって、各確認セグメントの最初の予想される到着時間は、通常、元のセグメントの放射が始まる瞬間に現在の時間として単に計算されます。キューイングの遅延と両端での放射時間の場合。nは、2秒が合理的なデフォルト値と思われるネットワーク管理によって設定されたパラメーターです。
This leaves only one unknown, the additional round-trip time introduced by loss of connectivity at the sender of the acknowledging segment. To account for this, we again rely on external link state cues. Whenever interruption of transmission at a remote LTP engine is signaled by a link state cue, we suspend the countdown timers for all acknowledging segments expected from that engine. Upon a signal that transmission has resumed at that engine, we resume those timers after (in effect) adding to each expected arrival time the length of the timer suspension interval.
これにより、1つの不明な残りが残り、確認セグメントの送信者での接続性の喪失によって導入された追加の往復時間です。これを説明するために、私たちは再び外部リンク状態のキューに依存しています。リモートLTPエンジンでのトランスミッションの中断がリンク状態キューによって信号を送るたびに、そのエンジンから予想されるすべての確認セグメントに対してカウントダウンタイマーを一時停止します。そのエンジンでトランスミッションが再開されたという信号がある場合、私たちは、予想される各到着時間にタイマーサスペンション間隔の長さを追加した後に（実際に）タイマーを再開します。
Loss or corruption of transmitted segments may cause the operation of LTP to deviate from the nominal sequence of events described above.
送信されたセグメントの損失または腐敗により、LTPの操作が上記の一連のイベントから逸脱する可能性があります。
Loss of one or more red-part data segments other than the EORP segment triggers data retransmission: the receiving engine returns a reception report detailing all the contiguous ranges of red-part data received (assuming no discretionary checkpoints were received, which are described below). The reception report is normally sent in a single report segment that carries a unique report serial number and the scope of red-part data covered. For example, if the red-part data covered block offsets [0:1000] and all but the segment in range [500:600] were received, the report segment with a unique serial number (say 100) and scope [0:1000] would carry two report entries: (0:500) and (600:1000). The maximum size of a report segment, like all LTP segments, is constrained by the data-link MTU; if many non-contiguous segments were lost in a large block transmission and/or the data-link MTU was relatively small, multiple report segments need to be generated. In this case, LTP generates as many report segments as are necessary and splits the scope of red-part data covered across multiple report segments so that each of them may stand on their own. For example, if three report segments are to be generated as part of a reception report covering red-part data in range [0:1,000,000], they could look like this: RS 19, scope [0:300,000], RS 20, scope
EORPセグメント以外の1つまたは複数のレッドパートデータセグメントの損失は、データの再送信をトリガーします。受信エンジンは、受信したレッドパートデータのすべての連続した範囲を詳述するレセプションレポートを返します（裁量チェックポイントが受け取られていないと仮定します。。受信レポートは通常、一意のレポートシリアル番号とカバーされたレッドパートデータの範囲を伴う単一のレポートセグメントで送信されます。たとえば、レッドパートデータでカバーされたブロックオフセット[0：1000]および範囲のセグメントを除くすべてを除くすべてのもの[500：600]を受信した場合、一意のシリアル番号（たとえば100）とスコープ[0：1000のレポートセグメントが受信された場合] 2つのレポートエントリ：（0：500）と（600：1000）。すべてのLTPセグメントと同様に、レポートセグメントの最大サイズは、データリンクMTUによって制約されます。大きなブロック伝送で多くの非連続セグメントが失われた場合、および/またはデータリンクMTUが比較的小さい場合、複数のレポートセグメントを生成する必要があります。この場合、LTPは必要に応じて多くのレポートセグメントを生成し、複数のレポートセグメントでカバーされているレッドパートデータの範囲を分割して、それぞれが独自に立つことができます。たとえば、3つのレポートセグメントが範囲[0：1,000,000]のレッドパートデータをカバーする受信レポートの一部として生成する場合、Rs 19、Scope [0：300,000]、Rs 20、Scopeのように見えることがあります。
[300,000:950,000], and RS 21, scope [950,000:1,000,000]. In all cases, a timer is started upon transmission of each report segment of the reception report.
[300,000：950,000]、およびRs 21、スコープ[950,000：1,000,000]。すべての場合において、受信レポートの各レポートセグメントの送信時にタイマーが開始されます。
On reception of each report segment, the sending engine responds as follows:
各レポートセグメントを受信すると、送信エンジンは次のように応答します。
- It turns off the timer for the checkpoint referenced by the report segment, if any.
- レポートセグメントで参照されるチェックポイントのタイマーをオフにします。
- It enqueues a reception-acknowledgment segment acknowledging the report segment (to turn off the report retransmission timer at the receiving engine). This segment is sent immediately at the next transmission opportunity.
- レポートセグメントを認めているレポートの再送信タイマーをオフにするために）レポートセグメントを認める受信承認セグメントを紹介します。このセグメントは、次の送信機会にすぐに送信されます。
- If the reception claims in the report segment indicate that not all data within the scope have been received, it normally initiates a retransmission by enqueuing all data segments not yet received. The last such segment is marked as a checkpoint and contains the report serial number of the report segment to which the retransmission is a response. These segments are likewise sent at the next transmission opportunity, but only after all data segments previously queued for transmission to the receiving engine have been sent. A timer is started for the checkpoint, so that it can be retransmitted automatically if no responsive report segment is received.
- レポートセグメントの受信の主張が、スコープ内のすべてのデータが受信されているわけではないことを示している場合、通常、まだ受信していないすべてのデータセグメントを排除することで再送信を開始します。最後のそのようなセグメントはチェックポイントとしてマークされており、再送信が応答であるレポートセグメントのレポートシリアル番号が含まれています。これらのセグメントは、次の送信機会で同様に送信されますが、受信エンジンへの送信のために以前にキューにキューになったすべてのデータセグメントが送信されました。チェックポイントのタイマーが開始されるため、応答性のあるレポートセグメントが受信されない場合は自動的に再送信できます。
- On the other hand, if the reception claims in the report segment indicate that all data within the scope of the report segment have been received, and the union of all reception claims received so far in this session indicates that all data in the red-part of the block have been received, then the sending engine notifies the local client service instance that the red-part of the block has been successfully transmitted; the session's red-part transmission has ended.
- 一方、レポートセグメントの受信請求がレポートセグメントの範囲内のすべてのデータが受信されたことを示している場合、このセッションでこれまでに受け取ったすべての受信請求の連合は、赤い部分のすべてのデータが示されています。ブロックを受信した後、送信エンジンは、ブロックの赤い部分が正常に送信されたことをローカルクライアントサービスインスタンスに通知します。セッションのレッドパートトランスミッションは終了しました。
On reception of a report-acknowledgment segment, the receiver turns off the timer for the referenced report segment.
Report-Nowledmentセグメントを受信すると、Receiverは参照されるレポートセグメントのタイマーをオフにします。
On reception of a checkpoint segment with a non-zero report serial number, the receiving engine responds as follows:
ゼロ以外のレポートシリアル番号を備えたチェックポイントセグメントを受信すると、受信エンジンは次のように応答します。
- It returns a reception report comprising as many report segments as are needed in order to report in detail on all data reception within the scope of the referenced report segment, and a timer is started for each report segment.
- 参照されるレポートセグメントの範囲内のすべてのデータ受信について詳細にレポートするために必要な数のレポートセグメントを含む受信レポートを返し、各レポートセグメントのタイマーが開始されます。
- If at this point all data in the red-part of the block have been received, the receiving engine delivers the received block's red-part to the local instance of the client service and, upon reception of reception-acknowledgment segments acknowledging all report segments, the session's red-part reception ends and transmission of the block is complete. Otherwise, the data retransmission cycle continues.
- この時点で、ブロックの赤い部分のすべてのデータを受信した場合、受信エンジンは、受信したブロックのレッドパートをクライアントサービスのローカルインスタンスに配信します。セッションのレッドパートレセプションは終了し、ブロックの送信が完了します。それ以外の場合、データの再送信サイクルが続きます。
Loss of a checkpoint segment or the report segment generated in response causes timer expiry; when this occurs, the sending engine normally retransmits the checkpoint segment. Similarly, the loss of a report segment or the corresponding report-acknowledgment segment causes the report segment's timer to expire; when this occurs, the receiving engine normally retransmits the report segment.
チェックポイントセグメントの損失または応答中に生成されたレポートセグメントは、タイマーの有効期限を引き起こします。これが発生すると、送信エンジンは通常、チェックポイントセグメントを再送信します。同様に、レポートセグメントの損失または対応するレポート承認セグメントセグメントにより、レポートセグメントのタイマーが期限切れになります。これが発生すると、受信エンジンは通常、レポートセグメントを再送信します。
Note that the redundant reception of a report segment (i.e., one that was already received and processed by the sender), retransmitted due to loss of the corresponding report-acknowledgment segment for example, causes another report-acknowledgment segment to be transmitted in response but is otherwise ignored. If any of the data segments retransmitted in response to the original reception of the report segment were lost, further retransmission of those data segments will be requested by the reception report generated in response to the last retransmitted data segment marked as a checkpoint. Thus, unnecessary retransmission is suppressed.
報告書セグメントの冗長受容（つまり、既に送信者によって受信および処理されたもの）は、たとえば、対応するレポート承認セグメントセグメントの損失のために再送信され、別のレポート承認セグメントが応答して送信されるが、それに応じて送信されることに注意してください。それ以外の場合は無視されます。レポートセグメントの元の受信に応じて再送信されたデータセグメントのいずれかが失われた場合、チェックポイントとしてマークされた最後の再送信データセグメントに応じて生成されたレセプションレポートによって、これらのデータセグメントのさらなる再送信が要求されます。したがって、不必要な再送信が抑制されます。
Note also that the responsibility for responding to segment loss in LTP is shared between the sender and receiver of a block: the sender retransmits checkpoint segments in response to checkpoint timeouts, and retransmits missing data in response to reception reports indicating incomplete reception, while the receiver retransmits report segments in response to timeouts. An alternative design would have been to make the sender responsible for all retransmission, in which case the receiver would not expect report-acknowledgment segments and would not retransmit report segments. There are two disadvantages to this approach:
また、LTPのセグメント損失への応答の責任は、ブロックの送信者と受信者の間で共有されていることに注意してください。チェックポイントのタイムアウトに応じて、送信者がチェックポイントセグメントを再送信し、受信レポートに応答して欠損データを再送信します。再送信は、タイムアウトに応じてセグメントをレポートします。代替設計は、すべての再送信に対して送信者に責任を負わせることでした。その場合、受信者はレポートの承認セグメントを期待せず、レポートセグメントを再送信しません。このアプローチには2つの欠点があります。
First, because of constraints on segment size that might be imposed by the underlying communication service, it is at least remotely possible that the response to any single checkpoint might be multiple report segments. An additional sender-side mechanism for detecting and appropriately responding to the loss of some proper subset of those reception reports would be needed. We believe that the current design is simpler.
第一に、基礎となる通信サービスによって課される可能性のあるセグメントサイズに制約があるため、単一のチェックポイントへの応答が複数のレポートセグメントである可能性が少なくともリモートで可能です。これらの受信レポートの適切なサブセットの損失を検出し、適切に対応するための追加の送信者側メカニズムが必要になります。現在の設計はよりシンプルだと考えています。
Second, an engine that receives a block needs a way to determine when the session can be closed. In the absence of explicit final report acknowledgment (which entails retransmission of the report in case of the loss of the report acknowledgment), the alternatives are (a) to close the session immediately on transmission of the report segment that signifies complete reception and (b) to close the session on receipt of an explicit authorization from the sender. In case (a), loss of the final report segment would cause retransmission of a checkpoint by the sender, but the session would no longer exist at the time the retransmitted checkpoint arrived. The checkpoint could reasonably be interpreted as the first data segment of a new block, most of which was lost in transit, and the result would be redundant retransmission of the entire block. In case (b), the explicit session termination segment and the responsive acknowledgment by the receiver (needed in order to turn off the timer for the termination segment, which in turn would be needed in case of in-transit loss or corruption of the termination segment) would somewhat complicate the protocol, increase bandwidth consumption, and retard the release of session state resources at the sender. Here again we believe that the current design is simpler and more efficient.
第二に、ブロックを受け取るエンジンは、セッションをいつ閉じることができるかを判断する方法が必要です。明示的な最終報告書の承認がない場合（報告書の承認が失われた場合に報告書の再送信を伴う）、代替案は（a）完全な受信を意味するレポートセグメントの送信で直ちにセッションを閉じることと（b）送信者からの明示的な許可を受け取ったときにセッションを閉じる。（a）の場合、最終レポートセグメントの喪失は送信者によるチェックポイントの再送信を引き起こしますが、再送信チェックポイントが到着した時点ではセッションは存在しなくなります。チェックポイントは、新しいブロックの最初のデータセグメントとして合理的に解釈される可能性があり、そのほとんどは輸送中に失われ、結果はブロック全体の冗長な再送信になります。場合（b）、明示的なセッション終了セグメントと受信機による応答性の認識（終了セグメントのタイマーをオフにするために必要です。セグメント）は、プロトコルをある程度複雑にし、帯域幅の消費を増やし、送信者でのセッション状態リソースのリリースを遅らせます。ここでも、現在の設計はよりシンプルで効率的であると信じています。
Data segment retransmission occurs only on receipt of a report segment indicating incomplete reception; report segments are normally transmitted only at the end of original transmission of the red-part of a block or at the end of a retransmission. For some applications, it may be desirable to trigger data segment retransmission incrementally during the course of red-part original transmission so that the missing segments are recovered sooner. This can be accomplished in two ways:
データセグメントの再送信は、不完全な受信を示すレポートセグメントの受領時にのみ発生します。レポートセグメントは通常、ブロックの赤い部分の元の伝送の終わりまたは再送信の終わりにのみ送信されます。一部のアプリケーションでは、不足しているセグメントがより早く回収されるように、赤いパートの元の伝送の過程でデータセグメントの再送信を段階的にトリガーすることが望ましい場合があります。これは2つの方法で達成できます。
- Any red-part data segment prior to the EORP can additionally be flagged as a checkpoint. Reception of each such "discretionary" checkpoint causes the receiving engine to issue a reception report.
- EORPより前の赤い部分データセグメントは、さらにチェックポイントとしてフラグを立てることができます。このような「裁量的」チェックポイントを受信すると、受信エンジンが受信レポートを発行します。
- At any time during the original transmission of a block's red-part (that is, prior to reception of any data segment of the block's green-part), the receiving engine can unilaterally issue additional asynchronous reception reports. Note that the CFDP protocol's "Immediate" mode is an example of this sort of asynchronous reception reporting [CFDP]. The reception reports generated for accelerated retransmission are processed in exactly the same way as the standard reception reports.
- ブロックのレッドパートの元のトランスミッション（つまり、ブロックの緑地のデータセグメントを受信する前）のいつでも、受信エンジンは追加の非同期受信レポートを一方的に発行する可能性があります。CFDPプロトコルの「即時」モードは、この種の非同期受信レポート[CFDP]の例であることに注意してください。加速された再送信のために生成された受信レポートは、標準の受信レポートとまったく同じ方法で処理されます。
A transmission session may be canceled by either the sending or the receiving engine in response either to a request from the local client service instance or to an LTP operational failure as noted earlier. Session cancellation is accomplished as follows.
送信セッションは、ローカルクライアントサービスインスタンスからのリクエストまたは前述のようにLTP運用障害のいずれかに応じて、送信または受信エンジンのいずれかによってキャンセルされる場合があります。セッションのキャンセルは次のように達成されます。
The canceling engine deletes all currently queued segments for the session and notifies the local instance of the affected client service that the session is canceled. If no segments for this session have yet been sent to or received from the corresponding LTP engine, then at this point the canceling engine simply closes its state record for the session and cancellation is complete.
キャンセルエンジンは、セッションの現在キューにキューに登録されているすべてのセグメントを削除し、影響を受けたクライアントサービスのローカルインスタンスにセッションがキャンセルされていることを通知します。このセッションのセグメントが対応するLTPエンジンにまだ送信または受信されていない場合、この時点でキャンセルエンジンはセッションの状態記録を閉じるだけで、キャンセルが完了します。
Otherwise, a session cancellation segment is queued for transmission. At the next opportunity, the enqueued cancellation segment is immediately transmitted to the LTP engine serving the remote client service instance. A timer is started for the segment, so that it can be retransmitted automatically if no response is received.
それ以外の場合、セッションキャンセルセグメントが送信用にキューに登録されています。次の機会に、エンキューキャンセルセグメントは、リモートクライアントサービスインスタンスにサービスを提供するLTPエンジンに直ちに送信されます。セグメントのタイマーが開始されるため、応答がない場合は自動的に再送信できます。
The corresponding engine receives the cancellation segment, enqueues for transmission to the canceling engine a cancellation-acknowledgment segment, deletes all other currently queued segments for the indicated session, notifies the local client service instance that the block has been canceled, and closes its state record for the session.
対応するエンジンは、キャンセルセグメントを受け取り、キャンセルエンジンへの伝送用エンキューキャンセルA-継続セグメントセグメントを削除し、示されたセッションの他のすべての現在キューに登録されているセグメントを削除し、ブロックがキャンセルされたことをローカルクライアントサービスインスタンスに通知し、その状態記録を閉じますセッションのために。
At the next opportunity, the enqueued cancellation-acknowledgment segment is immediately transmitted to the canceling engine.
次の機会に、Enqueued Cancellation-Nowledmentセグメントはすぐにキャンセルエンジンに送信されます。
The canceling engine receives the cancellation-acknowledgment, turns off the timer for the cancellation segment, and closes its state record for the session.
キャンセルエンジンは、キャンセルの継続的なものを受け取り、キャンセルセグメントのタイマーをオフにし、セッションの州記録を閉じます。
Loss of a cancellation segment or of the responsive cancellation-acknowledgment causes the cancellation segment timer to expire. When this occurs, the canceling engine retransmits the cancellation segment.
キャンセルセグメントまたは応答性のあるキャンセルと継続の損失により、キャンセルセグメントタイマーが失効します。これが発生すると、キャンセルエンジンはキャンセルセグメントを再送信します。
There is a clear risk that unintended receivers can listen in on LTP transmissions over satellite and other radio broadcast data links. Such unintended recipients of LTP transmissions may also be able to manipulate LTP segments at will.
意図しない受信機が衛星やその他の無線ブロードキャストデータリンクを介したLTP送信に耳を傾けることができるという明確なリスクがあります。LTPトランスミッションのこのような意図しない受信者は、LTPセグメントを自由に操作できる場合もあります。
Hence, there is a potential requirement for confidentiality, integrity, and anti-DoS (Denial of Service) security services and mechanisms.
したがって、機密性、完全性、および反DO（サービス拒否）セキュリティサービスとメカニズムには潜在的な要件があります。
In particular, DoS problems are more severe for LTP compared to typical Internet protocols because LTP inherently retains state for long periods and has very long time-out values. Further, it could be difficult to reset LTP nodes to recover from an attack. Thus, any adversary who can actively attack an LTP transmission has the potential to create severe DoS conditions for the LTP receiver.
特に、LTPは長期間状態を本質的に保持し、非常に長いタイムアウト値を持っているため、DOSの問題は典型的なインターネットプロトコルと比較してLTPでより深刻です。さらに、LTPノードをリセットして攻撃から回復することは困難です。したがって、LTP伝送を積極的に攻撃できる敵は、LTPレシーバーに深刻なDOS条件を作成する可能性があります。
To give a terrestrial example: were LTP to be used in a sparse sensor network, DoS attacks could be mounted resulting in nodes missing critical information, such as communications schedule updates. In such cases, a single successful DoS attack could take a node entirely off the network until the node was physically visited and reset.
地上の例を示すために、LTPがスパースセンサーネットワークで使用されていた場合、DOS攻撃を取り付けて、通信スケジュールの更新などの重要な情報が欠落していることになります。そのような場合、単一の成功したDOS攻撃は、ノードが物理的に訪問されてリセットされるまで、ネットワークから完全にノードを取得する可能性があります。
Even for deep-space applications of LTP, we need to consider certain terrestrial attacks, in particular those involving insertion of messages into an ongoing session (usually without having seen the exact bytes of the previous messages in the session). Such attacks are likely in the presence of firewall failures at various nodes in the network, or due to Trojan software running on an authorized host. Many message insertion attacks will depend on the attacker correctly "guessing" something about the state of the LTP peers, but experience shows that successful guesses are easier than might be thought [DDJ].
LTPのディープスペースアプリケーションであっても、特定の陸生攻撃、特に継続的なセッションにメッセージを挿入することを含むものを検討する必要があります（通常、セッションで以前のメッセージの正確なバイトを見たことがありません）。このような攻撃は、ネットワーク内のさまざまなノードでファイアウォール障害が存在する場合、または承認されたホストで実行されているトロイの木馬ソフトウェアによる可能性があります。多くのメッセージ挿入攻撃は、攻撃者がLTPピアの状態について何かを正しく「推測」することに依存しますが、経験は、成功した推測が考えられるよりも簡単であることを示しています[DDJ]。
We now consider the appropriate layer(s) at which security mechanisms can be deployed to increase the security properties of LTP, and the trade-offs entailed in doing so.
ここで、LTPのセキュリティプロパティを増やすためにセキュリティメカニズムを展開できる適切なレイヤーを検討します。
The Application layer (above-LTP)
アプリケーションレイヤー（LTP上記）
Higher-layer security mechanisms clearly protect LTP payload, but leave LTP headers open. Such mechanisms provide little or no protection against DoS type attacks against LTP, but may well provide sufficient data integrity and ought to be able to provide data confidentiality.
高層セキュリティメカニズムはLTPペイロードを明確に保護しますが、LTPヘッダーを開いたままにします。このようなメカニズムは、LTPに対するDOSタイプの攻撃に対する保護をほとんどまたはまったく提供しませんが、十分なデータの完全性を提供し、データの機密性を提供できるはずです。
The LTP layer
LTPレイヤー
An authentication header (similar to IPsec [AH]) can help protect against replay attacks and other bogus packets. However, an adversary may still see the LTP header of segments passing by in the ether. This approach also requires some key management infrastructure to be in place in order to provide strong authentication, which may not always be an acceptable overhead. Such an authentication header could mitigate many DoS attacks.
認証ヘッダー（IPSEC [AH]に類似）は、リプレイ攻撃やその他の偽のパケットから保護するのに役立ちます。ただし、敵は、エーテルを通り過ぎるセグメントのLTPヘッダーを依然として見ることができます。また、このアプローチでは、強力な認証を提供するために、いくつかの主要な管理インフラストラクチャを導入する必要があります。このような認証ヘッダーは、多くのDOS攻撃を軽減する可能性があります。
Similarly, a confidentiality service could be defined for LTP payload and (some) header fields. However, this seems less attractive since (a) confidentiality is arguably better provided either above or below the LTP layer, (b) key management for such a service is harder (in a high-delay context) than for an integrity service, and (c) forcing LTP engines to attempt decryption of incoming segments can in itself provide a DoS opportunity.
同様に、LTPペイロードおよび（一部の）ヘッダーフィールドに対して、機密保持サービスを定義できます。ただし、（a）LTPレイヤーの上または下のいずれかで、（b）そのようなサービスの主要な管理が（高遅延の文脈では）整合性サービスよりも難しい場合、秘密性は間違いなくより良くなるため、これは魅力的ではないようです。c）LTPエンジンが着信セグメントの復号化を試みるように強制すること自体がDOSの機会を提供することができます。
Further, within the LTP layer we can make various design decisions to reduce the probability of successful DoS attacks. In particular, we can mandate that values for certain fields in the header (session numbers, for example) be chosen randomly.
さらに、LTPレイヤー内で、DOS攻撃を成功させる確率を減らすために、さまざまな設計上の決定を下すことができます。特に、ヘッダー内の特定のフィールド（たとえば、セッション番号など）のその値をランダムに義務付けることができます。
The Data-link layer (below-LTP)
データリンクレイヤー（LTP未満）
The lower layers can clearly provide confidentiality and integrity services, although such security may result in unnecessary overhead if the cryptographic service provided is not required for all data. For example, it can be harder to manage lower layers so that only the data that requires encryption is in fact encrypted. Encrypting all data could represent a significant overhead for some LTP use cases. However, the lower layers are often the place where compression and error-correction is done, and so may well also be the optimal place to do encryption since the same issues with applying or not applying the service apply to both encryption and compression.
下層層は明確に機密性と整合性サービスを提供できますが、そのようなセキュリティは、すべてのデータに提供される暗号化サービスが必要ない場合、不必要なオーバーヘッドにつながる可能性があります。たとえば、暗号化を必要とするデータのみが実際に暗号化されるように、下層層を管理するのが難しい場合があります。すべてのデータを暗号化すると、一部のLTPユースケースの重要なオーバーヘッドを表す可能性があります。ただし、下層層は、多くの場合、圧縮とエラーの修正が行われる場所であるため、暗号化と圧縮の両方に適用されるかどうかと同じ問題があるため、暗号化を行うのに最適な場所である可能性があります。
In light of these considerations, LTP includes the following security mechanisms:
これらの考慮事項に照らして、LTPには次のセキュリティメカニズムが含まれています。
The optional LTP Authentication mechanism is an LTP segment extension comprising a ciphersuite identifier and optional key identifier that precede the segment's content, plus an authentication value (either a message authentication code or a digital signature) that follows the segment's content; the ciphersuite ID is used to indicate the length and format of the authentication value. The authentication mechanism serves to assure the segment's integrity and, depending on the ciphersuite selected and the key management regime, its authenticity.
オプションのLTP認証メカニズムは、セグメントのコンテンツに先行するCiphersuite識別子とオプションのキー識別子に加えて、セグメントのコンテンツに従う認証値（メッセージ認証コードまたはデジタル署名）を含むLTPセグメント拡張です。Ciphersuite IDは、認証値の長さと形式を示すために使用されます。認証メカニズムは、セグメントの完全性を保証するのに役立ち、選択されたCiphersuiteと主要な管理体制に応じて、その信ity性を保証します。
The optional LTP cookie mechanism is an LTP segment extension comprising a "cookie" -- a randomly chosen numeric value -- that precedes the segment's content. By increasing the number of bytes in a segment that cannot be easily predicted by an inauthentic data source, and by requiring that segments lacking the correct values of these bytes be silently discarded, the cookie mechanism increases the difficulty of mounting a successful denial-of-service attack on an LTP engine.
オプションのLTP Cookieメカニズムは、セグメントのコンテンツに先行する「Cookie」（ランダムに選択された数値）を含むLTPセグメント拡張です。セグメント内のバイト数を増やすことで、不正なデータソースでは簡単に予測できず、これらのバイトの正しい値を欠くセグメントを静かに破棄することを要求することにより、Cookieメカニズムは、成功した否定を取り付けることの難しさを増加させます。LTPエンジンへのサービス攻撃。
The above mechanisms are defined in detail in the LTP extensions document [LTPEXT].
上記のメカニズムは、LTPエクステンションドキュメント[LTPext]で詳細に定義されています。
In addition, the serial numbers of LTP checkpoints and reports are required to be randomly chosen integers, and implementers are encouraged to choose session numbers randomly as well. This randomness adds a further increment of protection against DoS attacks. See [PRNG] for recommendations related to randomness.
さらに、LTPチェックポイントとレポートのシリアル番号は、ランダムに選択される整数を選択する必要があり、実装者はセッション番号もランダムに選択することをお勧めします。このランダム性は、DOS攻撃に対する保護のさらなる増加を追加します。ランダム性に関連する推奨事項については、[PRNG]を参照してください。
Please see the IANA Considerations sections of [LTPSPEC] and [LTPEXT].
[ltpspec]および[ltpext]のIANAに関する考慮事項セクションをご覧ください。
Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for their thoughts on this protocol and its role in Delay-Tolerant Networking architecture.
ティム・レイ、ヴィント・ケルフ、ボブ・ダースト、ケビン・フォール、エイドリアン・フック、キース・スコット、リー・トーガーソン、エリック・トラビス、ハウィー・ワイスに感謝します。
Part of the research described in this document was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. This work was performed under DOD Contract DAA-B07- 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407.
この文書に記載されている研究の一部は、国立航空宇宙局との契約の下で、カリフォルニア工科大学のジェット推進研究所で実施されました。この作業は、DOD契約DAA-B07-00-CC201、DARPA AO H912で実行されました。JPLタスクプランNo. 80-5045、DARPA AO H870;およびNASA契約NAS7-1407。
Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers at Ohio University for their suggestions and advice in making various design decisions. This work was done when Manikantan Ramadas was a graduate student at the EECS Dept., Ohio University, in the Internetworking Research Group Laboratory.
また、Shawn Ostermann、Hans Kruse、およびDovel Myersのおかげで、さまざまなデザインの決定を下すための提案とアドバイスに感謝します。この作業は、マニカンタン・ラマダスがオハイオ大学のEECS部門のインターネットワーキング研究グループ研究所の大学院生だったときに行われました。
Part of this work was carried out at Trinity College Dublin as part of the SeNDT contract funded by Enterprise Ireland's research innovation fund.
この作業の一部は、エンタープライズアイルランドのResearch Innovation Fundが資金提供するSendt契約の一環として、Trinity College Dublinで実施されました。
[LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.
[LTPSPEC] Ramadas、M.、Burleigh、S。、およびS. Farrell、「Licklider Transmission Protocol -Specification」、RFC 5326、2008年9月。
[LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider Transmission Protocol - Security Extensions", RFC 5327, September 2008.
[ltpext] Farrell、S.、Ramadas、M。、およびS. Burleigh、「Licklider Transmission Protocol -Security Extensions」、RFC 5327、2008年9月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[BP] Scott、K。およびS. Burleigh、「バンドルプロトコル仕様」、RFC 5050、2007年11月。
[CFDP] CCSDS File Delivery Protocol (CFDP). Recommendation for Space Data System Standards, CCSDS 727.0-B-2 BLUE BOOK Issue 1, October 2002.
[CFDP] CCSDSファイル配信プロトコル（CFDP）。宇宙データシステム標準の推奨、CCSDS 727.0-B-2ブルーブック問題1、2002年10月。
[DDJ] I. Goldberg and E. Wagner, "Randomness and the Netscape Browser", Dr. Dobb's Journal, 1996, (pages 66-70).
[DDJ] I. GoldbergおよびE. Wagner、「ランダム性とNetscapeブラウザ」、Dr。Dobb's Journal、1996、（66-70ページ）。
[DSN] Deep Space Mission Systems Telecommunications Link Design Handbook (810-005) web-page, "http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/"
[DSN] DEEP SPACE MISSION SYSTEMS TeleCommunications Link Design Handbook（810-005）Web-Page、 "http://eis.jpl.nasa.gov/deepspace/dsndocs/810-005/"
[DTN] K. Fall, "A Delay-Tolerant Network Architecture for Challenged Internets", In Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, Aug 2003.
[DTN] K. Fall、「挑戦されたインターネットのための遅延耐性ネットワークアーキテクチャ」、ACM Sigcomm 2003、Karlsruhe、ドイツ、2003年8月の議事録。
[IPN] InterPlanetary Internet Special Interest Group web page, "http://www.ipnsig.org".
[IPN]惑星間インターネット特別利益グループWebページ、「http://www.ipnsig.org」。
[TFRC] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[TFRC] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendry Rate Control（TFRC）：プロトコル仕様」、RFC 3448、2003年1月。
[HSTCP] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, December 2003.
[HSTCP] Floyd、S。、「大輻輳窓用の高速TCP」、RFC 3649、2003年12月。
[SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[SCTP] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[PRNG] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[PRNG] EastLake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
Authors' Addresses
著者のアドレス
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 301-485B Pasadena, CA 91109-8099 Telephone: +1 (818) 393-3353 Fax: +1 (818) 354-1075 EMail: Scott.Burleigh@jpl.nasa.gov
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S：301-485B Pasadena、CA 91109-8099電話：1（818）393-3353 FAX：1（818）354-1075メール：scott.burleigh@jpl。NASA.GOV
Manikantan Ramadas ISRO Telemetry Tracking and Command Network (ISTRAC) Indian Space Research Organization (ISRO) Plot # 12 & 13, 3rd Main, 2nd Phase Peenya Industrial Area Bangalore 560097 India Telephone: +91 80 2364 2602 EMail: mramadas@gmail.com
Manikantan Ramadas Isro Telemetry Tracking and Command Network（ISTRAC）Indian Space Research Organization（ISRO）PLOT＃12＆13、3番目のメイン、第2フェーズPeenya Industrial Area Bangalore 560097インド電話：91 80 2364 2602メール：mramadas@gmail.com
Stephen Farrell Computer Science Department Trinity College Dublin Ireland Telephone: +353-1-896-1761 EMail: stephen.farrell@cs.tcd.ie
スティーブンファレルコンピューターサイエンス部門トリニティカレッジダブリンアイルランド電話：353-1-896-1761メール：stephen.farrell@cs.tcd.ie
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびhttp://www.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。