RFC5325 日本語訳
5325 Licklider Transmission Protocol - Motivation. S. Burleigh, M.Ramadas, S. Farrell. September 2008. (Format: TXT=57016 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループS.バーレイの要求をネットワークでつないでください: 5325年のNASA/ジェット推進委研究所カテゴリ: 情報のM.Ramadas ISTRAC、ISRO S.ファレル・トリニティー・カレッジダブリン2008年9月
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.
このメモはインターネットコミュニティのために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のどんなレベルの候補ではありません。 それはインターネットResearch Task Force(IRTF)のDelay Tolerant Networking(DTN)研究Groupのコンセンサスを表します。 詳しい情報に関してRFC3932を見てください。
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.
このドキュメントは接続性で非常に長いメッセージ往復の倍(RTTs)特徴付けられたリンク、そして/または、頻繁な中断の上に「再-トランスミッション」ベースの信頼性を提供するように設計されたLicklider Transmissionプロトコル(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.
Bundleプロトコルを配備するInterplanetaryインターネット設定では、単一のホップ宇宙空間無線周波数(RF)の上の信頼できる集合層がリンクされるときLTPが役立つことを意図します。 LTPは、選択している承認レセプションレポートに請求することによって、データ伝送のAutomatic Repeat reQuest(ARQ)をします。 それは、statefulで、どんな交渉も握手も持っていません。
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.
このドキュメントは、Delay Tolerant Networking Research Groupの製品であり、そのグループによって再検討されました。 RFCとしての公表への反論は全く上げられませんでした。
Burleigh, et al. Experimental [Page 1] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[1ページ]RFC5325LTP--動機2008年9月
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. 序論…2 2. 問題…3 2.1. IPN操作環境…3 2.2. なぜTCPではありませんかそれともSCTPではありませんか? .......................................5 3. 概観について議定書の中で述べてください…6 3.1. 名目上の操作…6 3.1.1. 州の手がかりをリンクしてください…9 3.1.2. トランスミッションを延期します…9 3.1.3. タイマ…10 3.2. Retransmission…13 3.3. Retransmissionを加速します…16 3.4. セッションキャンセル…17 4. セキュリティ問題…17 5. IANA問題…20 6. 承認…20 7. 参照…20 7.1. 有益な参照…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.
Licklider Transmissionプロトコル(LTP)は、接続性で非常に長いメッセージ往復の倍特徴付けられたリンク、そして/または、頻繁な中断の上に「再-トランスミッション」ベースの信頼性を提供するように設計されています。 惑星間空間のコミュニケーションはこの種類の環境の最も際立った例です、そして、LTPは主に宇宙空間の上の「長期」信頼できるトランスミッションRFリンクを支えるのを目的とされます。 明確に、LTPが信頼できる「集合層」プロトコルとして機能することを意図します、DTN展開におけるDelay許容性があるNetworking(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の名誉で命名されます。
Burleigh, et al. Experimental [Page 2] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[2ページ]RFC5325LTP--動機2008年9月
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].
地球のコミュニケーションのための環境(インターネットで見られて)とInterplanetaryインターネット(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.
この過剰購読は、パケットによって経験された往復の回が信号伝播遅延と掩蔽で影響を受けるだけではなく、スケジューリングでも影響を受けて、地球ベースのリソースの経営者側によって課された遅れを列に並ばせることを意味します: 与えられた目的地に送られるパケットは次の予定されている接触の期間まで列に並ばせられなければならないかもしれません。(それは、時間、日、または何週間も後にさえあるかもしれません)。
Burleigh, et al. Experimental [Page 3] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[3ページ]RFC5325LTP--動機2008年9月
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.
- 長い往復の回はブロックの目的地から1ブロックのデータの伝達と承認のレセプションの間のかなりの遅れを意味します、ブロックの到着に合図して。 到着の承認を受けるまで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は「statefulです」。 それが送ったデータの1ブロックのレセプションを確実にして、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個の単方向のリンクを使用することで実行されます。
Burleigh, et al. Experimental [Page 4] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[4ページ]RFC5325LTP--動機2008年9月
- 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を使用するのは実行不可能になります。 [TFRC]からTCPスループット方程式を使用して、私たちは、損失イベントレート(p)が与えられた一定の州のスループットを達成するのが必要であると見込むことができます。 地球から火星に最小のRTTを仮定するのは、8分(地球への最接近における火星への片道光速遅れは4分である)です、他のあらゆるパケットであり、p(すなわち、TCPスループット方程式の分母における2番目の付加的な用語を無視する)で取るにたらない高次な用語を無視して、私たちが様々なスループット値を達成するのに必要である損失イベント率の以下のテーブルを入手すると1500バイト、受信機が承認する仮定のパケットサイズに仮定して。
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)
スループットLossイベントレート(p)---------- ------------------- 10 Mbps4.68*10^(-12)1Mbps4.68*10^(-10)100キロビット毎秒4.68*10^(-8)10キロビット毎秒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.
TCPスループット方程式[TFRC]で独身のRTTで遭遇する複数の損失が単一の損失出来事として扱われますが、そのような損失イベント率が宇宙空間のリンクでまだ非現実的であることに注意してください。
For the purposes of this discussion, we are not considering the more aggressive TCP throughput equation that characterizes HighSpeed TCP [HSTCP].
この議論の目的のために、私たちはHighSpeed TCP[HSTCP]を特徴付けるより攻撃的なTCPスループット方程式を考えていません。
Burleigh, et al. Experimental [Page 5] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[5ページ]RFC5325LTP--動機2008年9月
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の特性はさらなる障害です、3方向ハンドシェイクの遅れと遅れた出発の追加遅れが長時間の遅延環境で法外であるかもしれないので。
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.
Stream Control Transmissionプロトコル(SCTP)[SCTP]が単一層の上のLTPとしての複数のセッション接続(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.
クライアントサービス例が、リモートクライアントサービス例に1ブロックのデータを送るように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に指定するのにLTP実現のアプリケーションプログラミングインターフェースを使用します。 送付エンジンは、トランスミッションセッションをこのブロックに始めて、セッションが始められたことをクライアントサービス例に通知します。 それに注意してください。
Burleigh, et al. Experimental [Page 6] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[6ページ]RFC5325LTP--動機2008年9月
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
それぞれの地方のデータリンク層プロトコルデータ単位(リンク層のフレームかUDPデータグラム)の内容が整数のLTPセグメントになるのに必要です、そして、ローカルのデータリンク層プロトコルが、受信LTPエンジンに不完全なLTPセグメントを決して伝達しないように必要です。 ローカルのデータリンク層プロトコルがUDPであるときに、LTP認証[LTPEXT]拡張子は、終わりから端への経路がデータグラム内容不正の見込みが取るにたらないか(いくつかの私設のローカル・エリア・ネットワークのように)、または不正なLTPセグメントを受けて、処理する結果がわずかであるもの(恐らくソフトウェア開発のように)でないならデータ保全を確実にするのに使用されるべきです。 LTP認証拡張子はいつではありませんか。
Burleigh, et al. Experimental [Page 7] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[7ページ]RFC5325LTP--動機2008年9月
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.
使用されていて、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データフローが単方向ので、TCPのようにデータ・セグメントで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.
受信エンジンは、レポート確認応答セグメントを受けて、レポートセグメントのためにタイマをオフにします。 セッションの赤い部分レセプションは現在終わりました、そして、ブロックの伝達は終了しています。
Burleigh, et al. Experimental [Page 8] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[8ページ]RFC5325LTP--動機2008年9月
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が機能する操作環境がリンク状態(本書では「リンク州の手がかり」と呼ばれる)の情報を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つの待ち行列の1つに追加します。 そのような待ち行列の交通1つはその待ち行列セットの「社内業務待ち行列」です。 もう片方が待ち行列セットのためのアプリケーションデータ待ち行列です。 セグメントをデキューするのは、即座のトランスミッションの基本的な通信系にそれを渡しながら、いつも含意します。 社内業務待ち行列が非空であるときはいつも、その待ち行列で最も古いセグメントは目的地への伝送のためデキューされた次のセグメントです。 他のすべての回、アプリケーションデータ待ち行列で最も古いセグメントは目的地への伝送のためデキューされた次のセグメントです。
The production and enqueuing of a segment and the subsequent actual transmission of that segment are in principle wholly asynchronous.
セグメントを生産と待ち行列に入れるのとそのセグメントのその後の実際の送信は原則として完全に非同期です。
Burleigh, et al. Experimental [Page 9] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[9ページ]RFC5325LTP--動機2008年9月
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は、先を見越す「再-トランスミッション」がいつ必要であるかを知るためにレポートと確認応答セグメントのための予想された到着時間の正確な計算に依存します。 1時間わずかに計算された前半であったとしても、結果は高価な不要な「再-トランスミッション」でしょうに。 他方では、数秒が遅れていたなら、計算された到着時間は安全にそうするかもしれません: 遅いタイムアウトと「再-トランスミッション」のための唯一の刑罰は、セッションリソースのわずかに遅らせたデータ配送とわずかに遅らせたリリースです。
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.
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.
This computation is performed in two stages:
This computation is performed in two stages:
- 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
- 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
Burleigh, et al. Experimental [Page 10] RFC 5325 LTP - Motivation September 2008
Burleigh, et al. Experimental [Page 10] RFC 5325 LTP - Motivation September 2008
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.
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.
- 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.
- 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.
The following discussion is the basis for LTP's expected arrival time calculations.
The following discussion is the basis for LTP's expected arrival time calculations.
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:
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.
- 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.
- 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.)
- 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.
- 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.
- 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.
Burleigh, et al. Experimental [Page 11] RFC 5325 LTP - Motivation September 2008
Burleigh, et al. Experimental [Page 11] RFC 5325 LTP - Motivation September 2008
- 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.
- 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.
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.
Inbound queuing delay is also assumed to be negligible because, even on small spacecraft, LTP processing speeds are high compared to data transmission rates.
Two mechanisms are used to make outbound queuing delay negligible:
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.
- 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'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'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.
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.
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.
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.
Burleigh, et al. Experimental [Page 12] RFC 5325 LTP - Motivation September 2008
Burleigh, et al. Experimental [Page 12] RFC 5325 LTP - Motivation September 2008
We assume that one-way light time to the nearest second can always be known (for example, provided by the operating environment).
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.
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.
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.
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.
3.2. Retransmission
3.2. Retransmission
Loss or corruption of transmitted segments may cause the operation of LTP to deviate from the nominal sequence of events described above.
Loss or corruption of transmitted segments may cause the operation of LTP to deviate from the nominal sequence of events described above.
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
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
Burleigh, et al. Experimental [Page 13] RFC 5325 LTP - Motivation September 2008
Burleigh, et al. Experimental [Page 13] RFC 5325 LTP - Motivation September 2008
[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], 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.
On reception of each report segment, the sending engine responds as follows:
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 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.
- 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.
- 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 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 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:
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.
- 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.
Burleigh, et al. Experimental [Page 14] RFC 5325 LTP - Motivation September 2008
Burleigh, et al. Experimental [Page 14] RFC 5325 LTP - Motivation September 2008
- 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.
- 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.
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 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:
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:
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.
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.
Burleigh, et al. Experimental [Page 15] RFC 5325 LTP - Motivation September 2008
Burleigh, et al. Experimental [Page 15] RFC 5325 LTP - Motivation September 2008
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.
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.
3.3. Accelerated Retransmission
3.3. Accelerated Retransmission
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:
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:
- 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.
- 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.
- 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.
- 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.
Burleigh, et al. Experimental [Page 16] RFC 5325 LTP - Motivation September 2008
Burleigh, et al. Experimental [Page 16] RFC 5325 LTP - Motivation September 2008
3.4. Session Cancellation
3.4. Session Cancellation
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. Security Considerations
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.
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.
Burleigh, et al. Experimental [Page 17] RFC 5325 LTP - Motivation September 2008
Burleigh, et al. Experimental [Page 17] RFC 5325 LTP - Motivation September 2008
Hence, there is a potential requirement for confidentiality, integrity, and anti-DoS (Denial of Service) security services and mechanisms.
Hence, there is a potential requirement for confidentiality, integrity, and anti-DoS (Denial of Service) security services and mechanisms.
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.
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.
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.
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.
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].
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].
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.
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.
The Application layer (above-LTP)
The Application layer (above-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.
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.
The LTP layer
The LTP layer
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.
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.
Burleigh, et al. Experimental [Page 18] RFC 5325 LTP - Motivation September 2008
Burleigh, et al. Experimental [Page 18] RFC 5325 LTP - Motivation September 2008
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.
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.
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.
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.
The Data-link layer (below-LTP)
The Data-link layer (below-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.
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.
In light of these considerations, LTP includes the following security mechanisms:
In light of these considerations, LTP includes the following security mechanisms:
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.
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.
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エンジンの上に攻撃してください。
Burleigh, et al. Experimental [Page 19] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[19ページ]RFC5325LTP--動機2008年9月
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チェックポイントとレポートの通し番号が整数が手当たりしだいに選ばれるのに必要です、そして、implementersが手当たりしだいにまた、セッション番号を選ぶよう奨励されます。 この偶発性はDoS攻撃に対する保護のさらなる増分を加えます。 偶発性に関連する推薦に関して[PRNG]を見てください。
5. IANA Considerations
5. IANA問題
Please see the IANA Considerations sections of [LTPSPEC] and [LTPEXT].
[LTPSPEC]と[LTPEXT]のIANA Considerations部を見てください。
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.
Delay許容性があるNetworking構造におけるこのプロトコルとその役割に関する彼らの考えのためにティム・レイ、Vintサーフ、ボブDurst、ケビンFall、エードリアン・フック、キース・スコット、リー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 Contract DAA-B07 00-CC201、DARPA AO H912の下でこの仕事をしました。 DARPA AO H870、JPLはプランNo.80-5045に仕事を課します。 そして、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.
感謝は様々なデザイン決定をすることにおける彼らの提案とアドバイスを求めるオハイオ大学のショーン・オステルマン、ハンス・クルーゼ、およびDovelマイアーズのもためです。 Manikantan RamadasがEECS部の大学院生であったときに、この仕事をしました、オハイオ大学、Internetworking Research Group研究所で。
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.ファレル、「Lickliderトランスミッションは議定書を作ります--仕様」、RFC5326、9月2008日
Burleigh, et al. Experimental [Page 20] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[20ページ]RFC5325LTP--動機2008年9月
[LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
Transmission Protocol - Security Extensions", RFC 5327,
September 2008.
[LTPEXT]ファレル、S.、Ramadas、M.、S.バーレイ、「Lickliderトランスミッションは議定書を作ります--セキュリティ拡大」、RFC5327、9月2008日
[AH] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[ああ] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification",
RFC 5050, November 2007.
[BP] スコットとK.とS.バーレイ、「バンドルプロトコル仕様」、RFC5050、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.ゴールドバーグ、E.ワグナー、および「偶発性とネットスケープブラウザ」、ドッブ博士のジャーナル、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]深いSpace Mission Systems Telecommunications Link Design Handbook(810-005)ウェブページ、" 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 SIGCOMM2003、カールスルーエ(ドイツ)、2003年8月の議事における「挑戦されたインターネットのための遅れ許容性があるネットワークアーキテクチャ。」
[IPN] InterPlanetary Internet Special Interest Group web page,
"http://www.ipnsig.org".
[IPN] InterPlanetaryインターネット特別利益団体Groupウェブページ、" 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)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。
[HSTCP] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, December 2003.
[HSTCP]フロイド、2003年12月のS.、「大きい混雑WindowsのためのHighSpeed TCP」RFC3649。
[SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[SCTP] スチュワート、R.、エド、「流れの制御伝動プロトコル」、RFC4960、9月2007日
[PRNG] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[PRNG]イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
Burleigh, et al. Experimental [Page 21] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[21ページ]RFC5325LTP--動機2008年9月
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-485 Bパサディナ、カリフォルニア91109-8099に電話をします: +1 (818) 393-3353Fax: +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遠隔測定法の追跡とコマンドネットワーク(ISTRAC)インド宇宙研究機構(ISRO)陰謀#12と13(第3メイン)は2番目にPeenya工業地域バンガロール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
Burleigh, et al. Experimental [Page 22] RFC 5325 LTP - Motivation September 2008
バーレイ、他 実験的な[22ページ]RFC5325LTP--動機2008年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78と 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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Burleigh, et al. Experimental [Page 23]
バーレイ、他 実験的[23ページ]
一覧
スポンサーリンク
