RFC 5325 - Licklider Transmission Protocol

RFC 5325 - Licklider Transmission Protocol - Motivation 日本語訳

URL : https://tools.ietf.org/html/rfc5325
タイトル : RFC 5325 - リックライダー伝送プロトコル - 動機
翻訳編集 : 自動生成

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

Status of This Memo

このメモのステータス

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。

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はインターネットStandardのどんなレベルの候補ではありません。これは、インターネット研究タスクフォースの遅延耐性ネットワーク（DTN）研究グループ（IRTF）のコンセンサスを表しています。詳細については、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の）および/または接続が頻繁に中断することを特徴とリンク上で再送信ベースの信頼性を提供するように設計リックライダー伝送プロトコル（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は、選択的確認応答受信レポートを募集してデータ送信の自動再送要求（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

1. Introduction

1. はじめに

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.

リックライダー伝送プロトコル（LTP）は、非常に長いメッセージ往復時間及び/または接続が頻繁に中断することを特徴とリンク上で再送ベースの信頼性を提供するように設計されています。惑星間空間でのコミュニケーションは、環境のこの種の最も顕著な例であり、LTPは、主に深宇宙RFリンク上「長距離」信頼性の高い伝送をサポートすることを目的としています。具体的には、LTPは、データリンクが非常に長い往復時間によって特徴付けられるDTN展開における遅延耐性ネットワーク（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リックライダーに敬意を表して名付けられています。

2. Problem

2.問題

2.1. IPN Operating Environment

2.1. IPN動作環境

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よりも大きい大きさのオーダーであってもよいです。タイムアウト間隔の計算のためのさまざまなメカニズムが必要とされています。

2.2. Why Not TCP or SCTP?

2.2. なぜTCPまたはSCTP？

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を使用します。私たちは与えられた定常状態のスループットを達成するために必要な損失イベント率（p）を計算することができます[TFRC]からTCPスループット方程式を使用。、、（地球に最も近いアプローチで火星への光遅延の一方向速度が4分）地球から火星への最小RTTは8分であると仮定すると1500バイトのパケット・サイズを仮定すると、受信機は、他のすべてのパケットを認めると仮定そしてpは無視できる高次の項を無視する（すなわち、TCPスループット方程式の分母における第二の添加剤の項を無視する）、我々は、さまざまなスループット値を達成するために必要な損失イベント率を以下の表を得ました。

      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ウェイハンドシェイクの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.

LTPが行うようにストリーム制御伝送プロトコル（SCTP）SCTPは、（SCTP用語の「関連」と呼ばれる）の単層接続を介して、複数のセッションのための「チャンク」（アプリケーションデータの単位）を多重化することができるが、それでも、複数の必要IPNオペレーティング環境のニーズに合わせていないので、はっきりとセッションセットアップのためのアプリケーション・データを送信し、前のラウンドトリップ。

3. Protocol Overview

3.プロトコルの概要

3.1. Nominal Operation

3.1. 公称操作

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は二つの部分を含むように、データの各ブロックに関して。いずれかの部分の長さがゼロであってもよいです。つまり、任意の所与のブロックは、（ブロックのどの部分を認めないか、再送される）、または完全に緑色（ブロック全体の受信が受信機によってアサートされるまで再送信が継続）完全赤色指定されてもよいです。したがって、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を指定するLTPの実装のアプリケーション・プログラミング・インタフェース、送信すべきデータの位置、送信されるデータの合計長さを使用し、そして「赤」のデータとして確実に伝達される先頭のデータ・バイトの数。送信エンジンは、このブロックの送信セッションを開始し、セッションが開始されたことをクライアントのサービスインスタンスに通知します。ご了承ください

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通信セッションパラメータをネゴシエートされていないが、代わりに一方的にアサートされ、アプリケーション・レベルのネットワーク管理アクティビティを受けます。送信エンジンは、リモート・クライアント・サービス・インスタンスのエンジンとのセッションの開始を交渉していません。

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.

各ローカルデータリンク層プロトコルデータユニット（リンク層フレームまたはUDPデータグラム）の含有量は、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.

「受信レポート」 - - TCPのようなデータセグメントに便乗することはできませんLTPデータフローが単方向であることから、LTPのデータ確認応答があることに注意してください。それらは、代わりに別のセグメントタイプで運ばれます。

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.

次の機会に、エンキュー報告セグメントは、直ちに送信エンジンに送信され、応答がない場合は報告セグメントは自動的に再送信することができるようにタイマーをスタートさせます。

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ためのタイマーをオフに受信エンジンに送信するためにエンキューレポートの肯定応答セグメント、およびブロックの赤色部分が正常に送信されたことをローカル・クライアント・サービス・インスタンスに通知します。セッションの赤い部分の送信が今終わりました。

At the next opportunity, the enqueued report-acknowledgment segment is immediately transmitted to the receiving engine.

次の機会に、エンキューレポート-確認応答セグメントは、直ちに受信エンジンに送信されます。

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.

受信エンジンは、レポートの肯定応答セグメントを受信し、レポートセグメントのタイマーをオフにします。セッションの赤い部分の受信が今終了し、ブロックの送信が完了しています。

3.1.1. Link State Cues

3.1.1. リンク状態キュー

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エンジン（s）は現在ローカルに送信されなければならないことを言って、LTPにLTPの機能は、リンク状態に関する情報を渡すことができるとした動作環境は、（このドキュメントの「リンク状態の手がかり」と呼ばれる）と仮定しますLTPエンジンとその逆。動作環境自体は正しく通信リンクのハードウェアを構成するためにこの情報を持っている必要があります。

3.1.2. Deferred Transmission

3.1.2. 繰延送信

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つのキューのいずれかに追加されます。そのようなトラフィックキューは、そのキューセットの「内部操作キュー」です。その他には、キューセットのためのアプリケーションデータキューです。セグメントのデキューイングは常に即時送信のための基本的な通信システムに配信を意味します。内部操作のキューが空でないときはいつでも、そのキュー内の最も古いセグメントが次のセグメントデキューイングさ宛先に送信するためです。他のすべての時点で、アプリケーション・データ・キュー内の最も古いセグメントが次のセグメントが宛先に送信するためのデキューイングされます。

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.

概念的には、特定の宛先に向かうトラフィックキューからセグメントのデキューイングは、基礎となる通信システムは、現在その宛先に送信していることを示すリンク状態キューの受信時に開始されます。すなわち、その宛先へのリンクがアクティブになりました。これは、基本的な通信システムがもはやその宛先に送信していることを示していないリンク状態キューを受信すると停止します。すなわち、その宛先へのリンクはもはやアクティブではありません。

3.1.3. Timers

3.1.3. タイマー

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.

すなわち、十分に正確RTT推定値はで個別に計算することができる - 往復履歴から派生統計情報が安全に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.

- 私たちは、単に先に知られている一方向光倍加時間、およびそのようなキューイングおよび送信の両端の処理遅延などの任意の追加の予想される待ち時間のために任意のマージンを追加することによってRTTの最初の近似値を計算します。深宇宙の操作については、マージン値は、通常、全体の秒数が少ないです。そのような余裕はインターネット標準によって巨大ではあるが、それは深宇宙での往復時間の双方向光時間部品に比べて軽微であります。私たちは、不必要に貴重な帯域幅を消費し、それによって全体的なパフォーマンスが低下します早すぎる再送信に優先して、比較的小さな増分だけ一つのブロックの配信を延期する遅刻再送を、リスクを選択します。

- 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:

二つのメカニズムは、アウトバウンドキューイング遅延は無視できるために使用されています。

- 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.

セッションの各端部での放射線の遅延は、単に、送信データレートで割ったセグメントサイズです。これは、（LTPヘッダオーバヘッドは、例えば、そのようなデータレートの下であまりにも多くのことができる）LTPの使用は、他の理由のために得策であり得る場合には、（例えば、10のBPS）データレートが非常に低い場合を除き、重要ではありません。したがって、放射線遅延は、通常、無視できるものとします。

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.

したがって、各認めるセグメントの最初の到着予定時刻は、通常処理を説明するために元のセグメントの放射線が始まることを一瞬、プラス二回片道光時間、プラスマージンの2 * N秒で簡単に現在の時間として計算され、遅延をキューイングし、両端の照射時間のために。 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.

これは、一つだけの未知の、認めるセグメントの送信側の接続性の損失によって導入された追加のラウンドトリップ時間を残します。これを説明するために、我々は再び外部リンク状態手がかりに依存しています。リモートLTPエンジンでの伝送の中断がリンク状態キューによって通知されるたびに、私たちはそのエンジンから期待されるすべて認めるセグメントのカウントダウンタイマーを一時停止します。変速機は、エンジンで再開したことを信号に、我々は各到着予定時刻にタイマサスペンション間隔の長さを加算（実質的に）した後、それらのタイマーを再開する。

3.2. Retransmission

3.2. 再送信

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つ以上の赤色部分データセグメントの損失は、データの再送をトリガ：受信エンジンは、（以下に記載されるいかなる裁量チェックポイントが受信されなかったと仮定すると、）受信赤色部分データの全ての連続する範囲を詳述した受信レポートを返します。受信レポートは、通常、固有のレポートのシリアル番号と被覆赤色部データの範囲を運ぶ単一のレポート・セグメントで送信されます。そして全てが、範囲内のセグメント[500：600]：例えば、赤色部分のデータは、ブロックオフセット[1000 0]覆われた場合に受信された、固有のシリアル番号（100言う）とスコープを持つレポートセグメント[0：1000 （0：500）及び（600：1000）2つのレポート項目を運ぶであろう。報告セグメントの最大サイズは、全てのLTPセグメントと同様に、データリンクMTUによって制限されます。多くの非連続セグメントが大きいブロック送信中に失われた及び/又はデータリンクMTUが比較的小さい場合には、複数のレポートセグメントが生成される必要があります。この場合、LTPが必要と同じ数のレポート・セグメントを生成し、それらの各々が自分で立つことができるように複数のレポートセグメントを横切って被覆赤色部データの範囲を分割します。 3つの報告セグメントは、範囲内の赤色の部分のデータをカバーする受信レポート[0：1,000,000]の一部として生成される場合、例えば、彼らはこのようになります。RS 19、範囲[0 30万]、RS 20、スコープ

[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.

[30万：95万]、及びRS 21、範囲[95万：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.

レポートの肯定応答セグメントを受信すると、受信機は、参照レポートセグメントのタイマーをオフにします。

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）に示すように、受信機によって明示的なセッション終了セグメントと応答確認応答に（順番に終了イントランジット損失又は破損した場合に必要となる終端セグメントのためのタイマーをオフにするために必要セグメントは）多少、プロトコルを複雑に帯域幅の消費を増加させ、送信者のセッション状態のリソースの解放を遅らせるだろう。ここで再び我々は、現在のデザインはシンプルでより効率的であると信じています。

3.3. Accelerated Retransmission

3.3. アクセラ再送信

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]報告非同期受信のこの種の例であることに注意してください。加速再送信のために生成された受信レポートは、標準的な受信レポートとまったく同じように処理されます。

3.4. Session Cancellation

3.4. セッションのキャンセル

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.

対応するエンジンは、キャンセルセグメントを受信キャンセルエンジンに送信するためにエンキューキャンセル確認応答セグメント、示さセッションの他のすべての現在キューに入れられたセグメントを削除し、ブロックを解除し、その状態のレコードを閉鎖されたことをローカル・クライアント・サービス・インスタンスに通知しますセッションのため。

At the next opportunity, the enqueued cancellation-acknowledgment segment is immediately transmitted to the canceling engine.

次の機会に、キューに入れキャンセル確認応答セグメントはすぐにキャンセルエンジンに送信されます。

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.

キャンセルセグメントのまたは応答キャンセル確認応答の損失は相殺セグメントタイマーが期限切れになります。これが発生すると、キャンセルエンジンキャンセルセグメントを再送します。

4. Security Considerations

4.セキュリティについての考慮事項

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.

このため、機密性、完全性、および抗DoS攻撃（サービス拒否）セキュリティサービスとメカニズムのための潜在的な要求があります。

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）自体におけるDoSの機会を提供することができる受信セグメントの復号を試みるLTPエンジンを強制。

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認証機構は、セグメントのコンテンツに先行する暗号スイート識別子及びオプションキー識別子を含むLTPセグメントの拡張に加え、セグメントの内容を次の認証値（メッセージ認証コードまたはデジタル署名のいずれか）です。暗号スイートIDは、認証値の長さと形式を示すために使用されます。認証機構は、選択された暗号スイートと鍵管理体制、その信憑性に応じて、セグメントの完全性を保証するのに役立ちます。

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クッキー機構は、「クッキー」を含むLTPセグメントの拡張です。簡単に本物でないデータ・ソースによって予測することができないセグメントのバイト数を増加させることにより、このバイトの正しい値を欠いているセグメントが静かに捨てられることを要求することにより、クッキー機構が成功拒否オブの取付困難を増加させますLTPエンジンのサービス攻撃。

The above mechanisms are defined in detail in the LTP extensions document [LTPEXT].

上記のメカニズムは[LTPEXT】LTP拡張文書に詳細に定義されています。

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]を参照してください。

5. IANA Considerations

5. IANAの考慮事項

Please see the IANA Considerations sections of [LTPSPEC] and [LTPEXT].

[LTPEXT] [LTPSPEC]のIANAの考慮事項のセクションを参照してくださいしてください。

6. Acknowledgments

6.謝辞

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.

このプロトコルに自分の考えや遅延耐性ネットワークアーキテクチャにおけるその役割のためのティム・レイ、ヴィントン・サーフ、ボブ・ダースト、ケビン秋、エイドリアンフック、キース・スコット、リーTorgerson、エリック・トラヴィス、とハウィーワイスに感謝します。

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タスクプラン番号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.

おかげで、様々な設計上の決定を行う際に彼らの提案やアドバイスにもショーンOstermann、ハンス・クルーゼ、およびオハイオ大学のDovelマイヤーズによるものです。 Manikantan Ramadasは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.

この作品の一部は、アイルランド政府商務庁の研究イノベーションファンドが出資SeNDT契約の一環として、トリニティ・カレッジ・ダブリンで行われました。

7. References

7.参考

7.1. Informative References

7.1. 参考文献

[LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.

【LTPSPEC] Ramadas、M.、バーレイ、S.、およびS.ファレル、 "リックライダー伝送プロトコル - 仕様"、RFC 5326、2008年9月。

[LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider Transmission Protocol - Security Extensions", RFC 5327, September 2008.

[LTPEXT]ファレル、S.、Ramadas、M.、およびS.バーリー、 "リックライダー伝送プロトコル - セキュリティ拡張機能"、RFC 5327、2008年9月。

[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[AH]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。

[BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.

[BP]スコット、K.およびS.バーリー、 "バンドルプロトコル仕様"、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 BLUE BOOK問題1、2002年10月。

[DDJ] I. Goldberg and E. Wagner, "Randomness and the Netscape Browser", Dr. Dobb's Journal, 1996, (pages 66-70).

[DDJ] I.ゴールドバーグとE.ワグナー、 "ランダム性およびNetscapeブラウザ"、博士ドッブのジャーナル、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]ディープ・スペース・ミッションシステム通信リンクの設計ハンドブック（810から005）は、Webページ、「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.秋、ACMのSIGCOMM 2003の議事録には「チャレンジインターネットのための遅延・トレラント・ネットワーク・アーキテクチャ」、カールスルーエ、ドイツ、2003年8月。

[IPN] InterPlanetary Internet Special Interest Group web page, "http://www.ipnsig.org".

[IPN]惑星間インターネットスペシャル・インタレスト・グループのウェブページ、「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]ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、 "TCPフレンドリーレート制御（TFRC）：プロトコル仕様"、RFC 3448、2003年1月。

[HSTCP] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, December 2003.

[HSTCP]フロイド、S.、 "大混雑Windows用高速TCP"、RFC 3649、2003年12月。

[SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.

[SCTP]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。

[PRNG] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.

[PRNG]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためにランダム要件"、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

スコットC.バーレイジェット推進研究所4800オークグローブドライブM / S：301-485Bパサデナ、CA 91109から8099電話：+1（818）393から3353ファックス：+1（818）354から1075 Eメール：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テレメトリー追跡およびコマンドネットワーク（ISTRAC）インド宇宙研究機関（ISRO）プロット＃12＆13、第三のメイン、第二期Peenya工業区のバンガロール560097インド電話：+91 80 2364 2602 Eメール：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 Eメール：stephen.farrell@cs.tcd.ie

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。