Networking Working Group M. Ramadas
Request for Comments: 5326 ISTRAC, ISRO
Category: Experimental S. Burleigh
NASA/Jet Propulsion Laboratory
S. Farrell
Trinity College Dublin
September 2008
Licklider Transmission Protocol - Specification
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). It may be considered for standardization by the IETF in the future, but the IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。これは、インターネット研究タスクフォースの遅延耐性ネットワーク（DTN）研究グループ（IRTF）のコンセンサスを表しています。これは、将来的にはIETFで標準化のために考慮することができるが、IETFが発行する決定はセキュリティのようなもののためにIETF見直し、混雑に基づいていないことを任意の目的のために特にノートに、このRFCのフィットネスの知識を否認しますコントロール、または展開されたプロトコルとの不適切な相互作用。詳細については、RFC 3932を参照してください。
Abstract
抽象
This document describes 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は、主に惑星間空間での「長距離」信頼性の高い伝送をサポートすることを目的としているが、それは、他の環境での用途を有します。
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 ....................................................3
2. Terminology .....................................................4
3. Segment Structure ...............................................9
3.1. Segment Header ............................................10
3.1.1. Segment Type Flags .................................11
3.1.2. Segment Type Codes .................................13
3.1.3. Segment Class Masks ................................14
3.1.4. Extensions Field ...................................14
3.2. Segment Content ...........................................16
3.2.1. Data Segment (DS) ..................................16
3.2.2. Report Segment (RS) ................................17
3.2.3. Report Acknowledgment Segment ......................19
3.2.4. Session Management Segments ........................20
3.3. Segment Trailer ...........................................20
4. Requests from Client Service ...................................20
4.1. Transmission Request ......................................21
4.2. Cancellation Request ......................................22
5. Requirements from the Operating Environment ....................23
6. Internal Procedures ............................................24
6.1. Start Transmission ........................................25
6.2. Start Checkpoint Timer ....................................25
6.3. Start RS Timer ............................................25
6.4. Stop Transmission .........................................25
6.5. Suspend Timers ............................................26
6.6. Resume Timers .............................................26
6.7. Retransmit Checkpoint .....................................27
6.8. Retransmit RS .............................................27
6.9. Signify Red-Part Reception ................................28
6.10. Signify Green-Part Segment Arrival .......................28
6.11. Send Reception Report ....................................28
6.12. Signify Transmission Completion ..........................30
6.13. Retransmit Data ..........................................30
6.14. Stop RS Timer ............................................31
6.15. Start Cancel Timer .......................................32
6.16. Retransmit Cancellation Segment ..........................32
6.17. Acknowledge Cancellation .................................32
6.18. Stop Cancel Timer ........................................33
6.19. Cancel Session ...........................................33
6.20. Close Session ............................................33
6.21. Handle Miscolored Segment ................................33
6.22. Handling System Error Conditions .........................34
7. Notices to Client Service ......................................35
7.1. Session Start .............................................35
7.2. Green-Part Segment Arrival ................................36
7.3. Red-Part Reception ........................................36
7.4. Transmission-Session Completion ...........................36
7.5. Transmission-Session Cancellation .........................37
7.6. Reception-Session Cancellation ............................37
7.7. Initial-Transmission Completion ...........................37
8. State Transition Diagrams ......................................38
8.1. Sender ....................................................39
8.2. Receiver ..................................................44
9. Security Considerations ........................................48
9.1. Denial of Service Considerations ..........................48
9.2. Replay Handling ...........................................49
9.3. Implementation Considerations .............................50
10. IANA Considerations ...........................................51
10.1. UDP Port Number for LTP ..................................51
10.2. LTP Extension Tag Registry ...............................51
11. Acknowledgments ...............................................51
12. References ....................................................52
12.1. Normative References .....................................52
12.2. Informative References ...................................52
This document serves as the main protocol specification of LTP and is part of a series of documents describing LTP. Other documents in this series include the motivation document [LTPMTV] and the protocol extensions document [LTPEXT]. We strongly recommend reading the protocol motivation document before reading this document, to establish sufficient background and motivation for the specification.
この文書では、LTPの主プロトコル仕様として機能し、LTPを記述する文書のシリーズの一部です。このシリーズの他の文書には、モチベーションドキュメント[LTPMTV]とプロトコル拡張ドキュメント[LTPEXT]が含まれます。私たちは強く仕様のための十分な背景や動機を確立するために、このドキュメントを読む前に、プロトコルのモチベーションの文書を読むことをお勧めします。
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は、選択的確認応答受信レポートを募集してデータ送信の自動再送要求（ARQ）を行います。それはステートフルで、何の交渉や握手を持っていません。
In an Interplanetary Internet setting deploying the Bundle Protocol that is being developed by the Delay Tolerant Networking Research Group, LTP is intended to serve as a reliable "convergence layer" protocol operating in pairwise fashion between adjacent Interplanetary Internet nodes that are in direct radio frequency (RF) communication. In that operational scenario, and potentially in some other deployments of the Bundle Protocol, LTP runs directly over a data-link layer protocol; when this is the case, forward error correction coding and/or checksum mechanisms in the underlying data-link layer protocol must ensure the integrity of the data passed between the communicating entities.
遅延耐性ネットワーク研究グループによって開発されているバンドルプロトコルを配備する惑星間インターネットの設定では、LTPは、プロトコル（直接無線周波数にある隣接惑星間インターネットノードとの間のペアワイズ様式で動作する信頼性の高い「収束層」として機能することが意図されていますRF）通信。その動作シナリオでは、潜在的にバンドルプロトコルのいくつかの他の展開で、LTPは、データリンク層プロトコル上で直接実行されます。これが事実である場合、基礎となるデータリンク層プロトコルにおける前方誤り訂正符号化および/またはチェックサムメカニズムは、通信エンティティ間で渡されるデータの整合性を保証しなければなりません。
Since no mechanisms for flow control or congestion control are included in the design of LTP, this protocol is not intended or appropriate for ubiquitous deployment in the global Internet.
フロー制御や輻輳制御のためのメカニズムがLTPの設計に含まれていないので、このプロトコルは、意図またはグローバルインターネットにおけるユビキタス配備に適していません。
When LTP is run over UDP, it must only be used for software development or in private local area networks. When LTP is not run over UDP, it must be run directly over a protocol (nominally a link-layer protocol) that meets the requirements specified in Section 5.
LTPは、UDP上で実行されると、それだけでソフトウェア開発のためのまたはプライベートローカルエリアネットワークで使用する必要があります。 LTPは、UDP上で実行されていない場合は、セクション5で指定された要件を満たしているプロトコル（名目上のリンク層プロトコル）上で直接実行する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [B97].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[B97]に記載されているように解釈されます。
(1) Engine ID
（1）エンジンID
A number that uniquely identifies a given LTP engine, within some closed set of communicating LTP engines. Note that when LTP is operating underneath the Delay-Tolerant Networking (DTN) [DTN] Bundle Protocol [BP], the convergence layer adapter mediating the two will be responsible for translating between DTN endpoint IDs and LTP engine IDs in an implementation-specific manner.
一意LTPエンジンを通信するいくつかの閉集合内に、所定のLTPエンジンを識別する番号。 LTPは、遅延耐性ネットワーク（DTN）DTN]バンドルプロトコル[BP]の下に動作している場合、両者を仲介収束層アダプタは実装固有の方法でDTNエンドポイントIDとLTPエンジンIDとの変換を担当することに注意してください。
(2) Block
（2）ブロック
An array of contiguous octets of application data handed down by the upper layer protocol (typically Bundle Protocol) to be transmitted from one LTP client service instance to another.
アプリケーションデータの連続するオクテットのアレイは、別のLTPクライアント・サービス・インスタンスから送信される上位層プロトコル（典型的には、バンドルプロトコル）によって受け継が。
Any subset of a block comprising contiguous octets beginning at the start of the block is termed a "block prefix", and any such subset of the block ending with the end of the block is termed a "block suffix".
ブロックの先頭から始まる連続したオクテットを含むブロックの任意のサブセットは、「ブロック接頭語」と呼ばれ、そのブロックの終わりで終わるブロックのそのようなサブセットは、「ブロック接尾語」と呼ばれています。
(3) Red-Part
（3）赤、パート
The block prefix that is to be transmitted reliably, i.e., subject to acknowledgment and retransmission.
即ち、了承の対象と再送、確実に伝達されるブロックプレフィックス。
(4) Green-Part
（4）グリーンパート
The block suffix that is to be transmitted unreliably, i.e., not subject to acknowledgments or retransmissions. If present, the green-part of a block begins at the octet following the end of the red-part.
肯定応答または再送信に、すなわち、対象ではない、信頼できない送信するブロックサフィックス。存在する場合、ブロックの緑色部分が赤の部分の終了後のオクテットから始まります。
(5) Session
（5）セッション
A thread of LTP protocol activity conducted between two peer engines for the purpose of transmitting a block. Data flow in a session is unidirectional: data traffic flows from the sending peer to the receiving peer, while data-acknowledgment traffic flows from the receiving peer to the sending peer.
LTPプロトコルアクティビティのスレッドは、ブロックを送信するために2つのピア機関の間で行われます。セッションにおけるデータの流れは一方向である：データ受信確認トラフィックが送信ピアに受信ピアから流れる間のデータトラフィックは、受信ピアへの送信ピアから流れます。
(6) Sender
（6）送信機
The data sending peer of a session.
データは、セッションのピアを送信します。
(7) Receiver
（7）受信機
The data receiving peer of a session.
セッションのピアデータ受信。
(8) Client Service Instance
（8）クライアントサービスインスタンス
A software entity, such as an application or a higher-layer protocol implementation, that is using LTP to transfer data.
このようなアプリケーションやデータを転送するためにLTPを使用している上位層プロトコルの実装、などのソフトウェアエンティティ。
(9) Segment
（9）セグメント
The unit of LTP data transmission activity. It is the data structure transmitted from one LTP engine to another in the course of a session. Each LTP segment is of one of the following types: data segment, report segment, report-acknowledgment segment, cancel segment, cancel-acknowledgment segment.
LTPデータ送信アクティビティのユニット。これは、セッションの途中で別のLTPエンジンから送信されたデータ構造です。報告・承認セグメント、セグメントをキャンセルし、キャンセル確認応答セグメントを、データセグメント、レポート・セグメント：各LTPセグメントは、次のいずれかのタイプです。
(10) Reception Claim
（10）受信請求
An assertion of reception of some number of contiguous octets of application data (a subset of a block) characterized by: the offset of the first received octet, and the number of contiguous octets received (beginning at the offset).
最初に受信したオクテットのオフセット、及び連続するオクテットの数（オフセットから始まる）受信：によって特徴付けられるアプリケーションデータの連続するオクテットのいくつかの数（ブロックのサブセット）の受信のアサーション。
(11) Scope
（11）スコープ
Scope identifies a subset of a block and comprises two numbers -- upper bound and lower bound.
スコープは、ブロックのサブセットを識別し、二つの数字含む - 上限と下限を。
For a data segment, lower bound is the offset of the segment's application data from the start of the block (in octets), while upper bound is the sum of the offset and length of the segment's application data (in octets). For example, a segment with a block offset of 1000 and length of 500 would have a lower bound of 1000 and upper bound of 1500.
上限を（オクテットで）セグメントのアプリケーションデータのオフセットと長さの和であるデータセグメントに対して、下限は、（オクテットで）ブロックの先頭からセグメントのアプリケーションデータのオフセットされています。例えば、1000および500の長さのオフセットブロックを有するセグメントは、下部1000の結合および1500の上限を有するであろう。
For a report segment, upper bound is the end of the block prefix to which the reception claims in the report apply, while lower bound is the end of the (smaller) interior block prefix to which the reception claims in the report do *not* apply. That is, data at any offset equal to or greater than the report's lower bound but less than its upper bound and not designated as "received" by any of the report's reception claims must be assumed not received, and therefore eligible for retransmission. For example, if a report segment carried a lower bound of 1000 and an upper bound of 5000, and the reception claims indicated reception of data within offsets 1000-1999 and 3000-4999, data within the block offsets 2000-2999 can be considered missing and eligible for retransmission.
レポートセグメント、上限の下限ながらレポートの受信の特許請求の範囲は、適用されるブロックプレフィックスの終わりには、レポートの受信クレームを行うための（小さな）内部ブロックプレフィックスの終わり*ない*です適用されます。すなわち、任意のデータが等しいか、レポートの下限が、レポートの受信の請求項のいずれかによって「受信」として受信していないと仮定し、したがって再送信の対象とする必要があり、指定の上限未満としないよりも大きいオフセット。報告セグメントはオフセット1000から1999と3000から4999内のデータの受信を示し1000の下限および5000の上限、及び受信請求を行う場合、例えば、2000から2999は、欠落ブロックオフセット内のデータを考慮することができます再送対象。
Reception reports (which may comprise multiple report segments) also have scope, as defined in Section 6.11.
6.11節で定義されるように受信レポートは、（複数のレポートのセグメントを含むことができる）も、スコープを有します。
(12) End of Block (EOB)
ブロックの（12）終了（EOB）
The last data segment transmitted as part of the original transmission of a block. This data segment also indicates that the segment's upper bound is the total length of the block (in octets).
ブロックの元の送信の一部として送信された最後のデータ・セグメント。このデータセグメントは、セグメントの上限を（オクテットで）ブロックの合計の長さであることを示しています。
(13) End of Red-Part (EORP)
レッド・パートの（13）終了（EORP）
The segment transmitted as part of the original transmission of a block containing the last octet of the block's red-part. This data segment also indicates that the segment's upper bound is the length of the block's red-part (in octets).
セグメントは、ブロックの赤色部分の最後のオクテットを含むブロックの元の送信の一部として送信されます。このデータセグメントは、セグメントの上限を（オクテットで）ブロックの赤の部分の長さであることを示しています。
(14) Checkpoint
（14）チェックポイント
A data segment soliciting a reception report from the receiving LTP engine. The EORP segment must be flagged as a checkpoint, as must the last segment of any retransmission; these are "mandatory checkpoints". All other checkpoints are "discretionary checkpoints".
受信LTPエンジンからの受信レポートを募集データセグメント。任意の再送信の最後のセグメントがなければならないのでEORPセグメントは、チェックポイントとしてフラグを立てなければなりません。これらは「必須チェックポイント」です。他のすべてのチェックポイントは、「裁量チェックポイント」です。
(15) Reception Report
（15）受信レポート
A sequence of one or more report segments reporting on all block data reception within some scope.
いくつかの範囲内の全てのブロックデータの受信のレポート1つ以上のレポート・セグメントのシーケンス。
(16) Synchronous Reception Report
（16）同期受信レポート
A reception report that is issued in response to a checkpoint.
チェックポイントに応答して発行された受信報告。
(17) Asynchronous Reception Report
（17）非同期受信報告
A reception report that is issued in response to some implementation-defined event other than the arrival of a checkpoint.
チェックポイントの到着以外のいくつかの実装で定義されたイベントに応答して発行された受信報告。
(18) Primary Reception Report
（18）一次受付レポート
A reception report that is issued in response to some event other than the arrival of a checkpoint segment that was itself issued in response to a reception report. Primary reception reports include all asynchronous reception reports and all synchronous reception reports that are sent in response to discretionary checkpoints or to the EORP segment for a session.
自身が受信報告に応答して発行されたチェックポイントセグメントの到着以外のいくつかのイベントに応答して発行された受信報告。プライマリ受信レポートは、すべての非同期受信レポートと裁量チェックポイントまたはセッションのEORPセグメントに応答して送信されるすべての同期受信レポートを含みます。
(19) Secondary Reception Report
（19）二次レセプションレポート
A reception report that is issued in response to the arrival of a checkpoint segment that was itself issued in response to a reception report.
自身が受信報告に応答して発行されたチェックポイントセグメントの到着に応答して発行された受信報告。
(20) Self-Delimiting Numeric Value (SDNV)
（20）自己区切り数値（SDNV）
The design of LTP attempts to reconcile minimal consumption of transmission bandwidth with
LTPの設計はして伝送帯域幅の最小消費電力を調整しようと
(a) extensibility to satisfy requirements not yet identified, and
（a）の拡張性は、まだ特定されていない要件を満たすために、そして
(b) scalability across a very wide range of network sizes and transmission payload sizes.
ネットワークのサイズ及び送信ペイロードサイズの非常に広い範囲にわたって（b）のスケーラビリティ。
The SDNV encoding scheme is modeled after the Abstract Syntax Notation One [ASN1] scheme for encoding Object Identifier values. In a data field encoded as an SDNV, the most significant bit (MSB) of each octet of the SDNV serves to indicate whether or not the octet is the last octet of the SDNV. An octet with an MSB of 1 indicates that it is either the first or a middle octet of a multi-octet SDNV; the octet with an MSB of 0 is the last octet of the SDNV. The value encoded in an SDNV is found by concatenating the 7 least significant bits of each octet of the SDNV, beginning at the first octet and ending at the last octet.
SDNV符号化方式は、オブジェクト識別子の値を符号化するための抽象構文記法1 [ASN1]スキームの後にモデル化されます。 SDNVとして符号化されたデータフィールドに、SDNVの各オクテットの最上位ビット（MSB）は、オクテットがSDNVの最後のオクテットであるかどうかを示すのに役立ちます。 1のMSBとのオクテットは、最初またはマルチオクテットSDNVの中間オクテットのいずれかであることを示しています。 0のMSBとのオクテットはSDNVの最後のオクテットです。 SDNVでエンコードされた値は、最初のオクテットで始まり、最後のオクテットで終わる、SDNVの各オクテットの7つの最下位ビットを連結することによって見出されます。
The following examples illustrate the encoding scheme for various hexadecimal values.
以下の実施例は、様々な進値に対する符号化方式を示します。
0xABC : 1010 1011 1100 is encoded as
0xABC：1010 1011 1100としてエンコードされます
{100 1010 1} {0 011 1100}
- -
= 10010101 00111100
＝ １００１０１０１ ００１１１１００
0x1234 : 0001 0010 0011 0100 = 1 0010 0011 0100 is encoded as
0x1234の：= 1 0010 0011 0100 0001 0010 0011 0100として符号化されます
{10 1 0010 0} {0 011 0100}
- -
= 10100100 00110100
＝ １０１００１００ ００１１０１００
0x4234 : 0100 0010 0011 0100 =100 0010 0011 0100 is encoded as
0x4234：= 100 0010 0011 0100 0100 0010 0011 0100として符号化されます
{1000000 1} {1 00 0010 0} {0 011 0100}
- - -
= 10000001 10000100 00110100
＝ １００００００１ １００００１００ ００１１０１００
0x7F : 0111 1111 =111 1111 is encoded as
0x7Fの：= 111 1111 0111 1111は、以下のように符号化されます
{0 111 1111}
-
= 01111111
＝ ０１１１１１１１
Note:
注意：
Care must be taken to make sure that the value to be encoded is padded with zeroes at the most significant bit end (NOT at the least significant bit end) to make its bitwise length a multiple of 7 before encoding.
ケアは、符号化すべき値は、符号化前のビット単位の長さ7の倍数を作るために、最上位ビット側（NOT最下位ビット端）でゼロで埋められていることを確認するために注意する必要があります。
While there is no theoretical limit on the size of an SDNV field, we note that the overhead of the SDNV scheme is 1:7, i.e., 1 bit of overhead for every 7 bits of actual data to be encoded. Thus, a
7、すなわち、実際のデータのすべての7ビットのオーバーヘッドの1ビットを符号化する：SDNVフィールドの大きさには理論的な制限はないが、我々はSDNV方式のオーバーヘッドが1であることに注意します。このように、
7-octet value (a 56-bit quantity with no leading zeroes) would be encoded in an 8-octet SDNV; an 8-octet value (a 64-bit quantity with no leading zeroes) would be encoded in a 10-octet SDNV. In general, an N-bit quantity with no leading zeroes would be encoded in a ceil(N/7) octet SDNV, where ceil is the integer ceiling function. Clearly, for fields that typically carry larger values such as RSA public keys, the SDNV overhead could become unacceptable. Hence, when adopting the SDNV scheme for other purposes related to this document, such as any protocol extensions, we RECOMMEND that if the typical data field value is expected to be larger than 8 octets, then the data field should be specified as a {LENGTH, VALUE} tuple, with the LENGTH parameter encoded as an SDNV followed by LENGTH octets housing the VALUE of the data field.
7オクテットの値（NO先行ゼロを持つ56ビットの量）は、8オクテットSDNVで符号化されるであろう。 8オクテット値（無先行ゼロを持つ64ビットの量）が10オクテットSDNVで符号化されるであろう。一般的に、無先行ゼロを有するNビット量がCEIL整数天井関数でCEIL（N / 7）オクテットSDNV、で符号化されるであろう。明らかに、典型的には、RSA公開鍵として大きな値を運ぶフィールドに、SDNVオーバーヘッドは許容できなくなる可能性があります。そのような任意のプロトコルの拡張として、この文書に関連する他の目的のためにSDNV方式を採用する場合したがって、我々は、典型的なデータ・フィールドの値は8つのオクテットよりも大きいことが予想される場合、データフィールドは、{LENGTHとして指定されるべきであることをお勧めしますデータフィールドの値を収容LENGTHオクテット続いSDNVとしてエンコードLENGTHパラメータを使用して、値}の組、。
We also note that SDNV is clearly not the best way to represent every numeric value. When the maximum possible value of a number is known without question, the cost of additional bits may not be justified. For example, an SDNV is a poor way to represent an integer whose value typically falls in the range 128 to 255. In general, though, we believe that the SDNV representation of various protocol data fields in LTP segments yields the smallest segment sizes without sacrificing scalability.
また、SDNVは明らかに、すべての数値を表現するための最良の方法ではないことに注意してください。多数の可能な最大値は、問題なしに知られている場合、追加ビットのコストは正当化されないことがあります。例えば、SDNV値、典型的には一般的に255の範囲128に入る整数を表す乏しい方法である、しかし、我々は、LTPセグメントにおける種々のプロトコル・データ・フィールドのSDNV表現が犠牲にすることなく、最小セグメントサイズが得られると考えていますスケーラビリティ。
Each LTP segment comprises
各LTPセグメント備えます
(a) a "header" in the format defined below.
（a）は、以下に定義される形式の「ヘッダ」。
(b) zero or more octets of "content".
（b）は、「コンテンツ」のゼロまたはそれ以上のオクテット。
(c) zero or more octets of "trailer" as indicated by information in the "Extensions field" of the header.
（C）ヘッダの「拡張フィールド」内の情報によって示されるように、「トレーラー」のゼロまたはそれ以上のオクテット。
LTP segments are of four general types depending on the nature of the content carried:
LTPセグメントが運ばコンテンツの性質に応じて4つの一般的な種類があります。
Data segments flow from the sender to the receiver and carry client service (application) data.
データセグメントが受信機に送信機から流れ、クライアントサービス（アプリケーション）データを運びます。
A report segment flows from the receiver to the sender and carries data reception claims together with the upper and lower bounds of the block scope to which the claims pertain.
報告セグメントは、送信側に受信機から流れ、一緒に請求項が関係たブロック範囲の上限と下限との間でデータ受信クレームを運びます。
A report-acknowledgment segment flows from the sender to the receiver and acknowledges reception of a report segment. It carries the serial number of the report being acknowledged.
レポートの肯定応答セグメントは、送信側から受信側に流れ、報告セグメントの受信を肯定応答します。これは、認知されているレポートのシリアル番号を運びます。
Session management segments may be generated by both the sender and the receiver and are of two general sub-types: cancellation and cancellation-acknowledgment. A cancellation segment initiates session cancellation procedures at the peer and carries a single byte reason-code to indicate the reason for session cancellation. Cancellation-acknowledgment segments merely acknowledge reception of a cancellation segment and have no content.
セッション管理セグメントは、送信側と受信側の両方によって生成され、二つの一般的なサブタイプであることができる：キャンセル及びキャンセル確認応答。キャンセルセグメントがピアにセッション解除手順を開始し、セッションの解除理由を示すために単一のバイト理由コードを運びます。キャンセル確認応答セグメントは、単にキャンセルセグメントの受信を確認し、内容を持ちません。
The overall segment structure is illustrated below:
全体的なセグメント構造を以下に示します：
Bit 0 1 2 3 4 5 6 7
^ +-----+-----+-----+-----+-----+-----+-----+-----+
| | Version number | Segment Type Flags | Control
| +-----------------------+-----------------------+ -byte
| | |
| / Session ID \
| \ /
Header +-----------------------+-----------------------+
| | Header Extension Cnt. | Trailer Extension Cnt.| Extensions
| +-----------------------+-----------------------+
| | |
| / Header Extensions \
| \ /
V +-----------------------------------------------+
| |
| |
| |
| Segment Content |
/ \
\ /
| |
| |
| |
^ +-----------------------------------------------+
| | |
Trailer / Trailer Extensions \
| \ /
V +-----------------------------------------------+
An LTP segment header comprises three data items: a single-octet control byte, the session ID, and the Extensions field.
単一オクテット制御バイト、セッションID、および拡張フィールド：LTPセグメントヘッダは、3つのデータ項目を含みます。
Control byte comprises the following:
制御バイトは、以下を含みます：
Version number (4 bits): MUST be set to the binary value 0000 for this version of the protocol.
バージョン番号（4ビット）：プロトコルのこのバージョンのバイナリ値0000に設定しなければなりません。
Segment type flags (4 bits): described in Section 3.1.1.
セグメントタイプフラグ（4ビット）：3.1.1項で説明。
Session ID uniquely identifies, among all transmissions between the sender and receiver, the session of which the segment is one token. It comprises the following:
セッションIDは、送信者と受信者との間のすべての通信のうち、セグメントはつのトークンとなっているセッションを識別する。これは、次を含みます：
Session originator (SDNV): the engine ID of the sender.
セッション創始者（SDNV）：送信者のエンジンID。
Session number (SDNV): typically a random number (for anti-DoS reasons), generated by the sender.
セッション数（SDNV）：（抗DoS攻撃の理由から）、通常の乱数、送信者によって生成されます。
The format and resolution of session number are matters that are private to the LTP sender; the only requirement imposed by LTP is that every session initiated by an LTP engine MUST be uniquely identified by the session ID.
セッション番号の形式と解像度は、LTPの送信者へのプライベートな事柄です。 LTPによって課される唯一の要件は、LTPエンジンによって開始されたすべてのセッションが一意のセッションIDによって識別されなければならないことです。
The Extensions field is described in Section 3.1.4.
拡張フィールドは、セクション3.1.4に記載されています。
The last 4 bits of the control byte in the segment header are flags that indicate the nature of the segment. In order (most significant bit first), these flags are CTRL, EXC, Flag 1, and Flag 0.
セグメントヘッダーの制御バイトの最後の4ビットは、セグメントの性質を示すフラグです。ために（最上位ビットが最初）、これらのフラグはCTRL、EXC、フラグ1、フラグ0です。
A value of 0 in the CTRL (Control) flag identifies the segment as a data segment, while a value of 1 identifies it as a control segment. A data segment with the EXC (Exception) flag set to 0 is a red-part segment; a data segment with EXC set to 1 is a green-part segment. For a control segment, having the EXC flag set to 1 indicates that the segment pertains to session cancellation activity. Any data segment (whether red-part or green-part) with both Flag 1 and Flag 0 set to 1 indicates EOB. Any data segment (whether red-part or green-part) with both Flag 1 and Flag 0 set to 0 indicates data without any additional protocol significance. Any red-part data segment with either flag bit non-zero is a checkpoint. Any red-part data segment with Flag 1 set to 1 indicates the end of red-part.
1の値は、制御セグメントとして識別しながら、CTRL（コントロール）フラグに0の値は、データセグメントとしてセグメントを識別する。 0に設定EXC（例外）フラグ付きデータセグメントは赤の部分セグメントです。 EXCとデータセグメントは1に設定緑色部分セグメントです。制御セグメントのために、1に設定EXCフラグを有するセグメントは、セッションキャンセル活性に関連することを示しています。 1のフラグ1とフラグ0セットの両方を有する任意のデータ・セグメントは、（赤の部分または緑色部分か）EOBを示します。 0にフラグ1とフラグ0セットの両方を有する任意のデータ・セグメントは、（赤の部分または緑色部分かどうか）は、任意の追加のプロトコル意味せずにデータを示しています。フラグビットの非ゼロのいずれかを有する任意の赤い部分データセグメントは、チェックポイントです。 1のフラグ1が設定された任意の赤い部分データセグメントは、赤の部分の終わりを示します。
Put another way:
別の言い方をすれば：
if (CTRL flag = 0) segment is a data segment if (EXC flag = 0) segment contains only red-part data if (Flag 1 = 1) segment is a checkpoint segment is the last segment in the red part of the block if (Flag 0 = 1) segment is the last segment in the block else // segment is not end of red-part if (Flag 0 = 1) segment is a checkpoint else segment contains only green-part data if (Flag 1 = 1) if (Flag 0 = 1) segment is the last segment in the block else segment is a control segment if (EXC flag = 0) segment pertains to report activity if (flag 0 = 0) segment is a report segment else segment is an acknowledgment of a report segment else segment pertains to session cancellation activity if (Flag 1 = 0) segment pertains to cancellation by block sender if (Flag 0 = 1) segment is a cancellation by sender else segment is an acknowledgment of a cancellation by sender else segment pertains to cancellation by block receiver if (Flag 0 = 1) segment is a cancellation by receiver else segment is an acknowledgment of a cancellation by receiver
（CTRLフラグ= 0）セグメントは、データセグメントである（フラグ= 1）セグメントは、チェックポイントセグメントである場合（EXCフラグ= 0）セグメントのみ赤色部分のデータが含まれている場合であれば、ブロックの赤い部分の最後のセグメントである場合（FLAG = 1 0）セグメント//セグメントは赤色部分であれば（フラグ0 = 1）セグメントの終了されていないブロックの他の最後のセグメントである（フラグ1 = 1の場合、チェックポイント他のセグメントは、グリーンパートデータが含まれています）（EXCフラグ= 0）セグメント（フラグ= 0）セグメントが他のセグメントである報告セグメントである場合に活性を報告するために属する場合（フラグ0 = 1）セグメントは、ブロック他のセグメント内の最後のセグメントが、制御セグメントがある場合（フラグが0 = 1）セグメントが送信者他のセグメントでのキャンセルは他の送信者によるキャンセルの確認応答である場合（フラグ1 = 0）セグメントがブロック送信者によってキャンセルに関する場合、レポートセグメント他のセグメントの肯定応答は、セッション解除活動に関係します（フラグが0 = 1）セグメントが受信機他のセグメントでのキャンセルがACKであれば、セグメントは、ブロックレシーバによってキャンセルに関する受信機によるキャンセルのnowledgment
Combinations of the settings of the segment type flags CTRL, EXC, Flag 1, and Flag 0 constitute segment type codes, which serve as concise representations of detailed segment nature.
セグメントタイプフラグCTRL、EXC、フラグ1、フラグ0の設定の組み合わせは、詳細なセグメントの性質のような簡潔な表現を提供セグメントタイプコードを構成します。
CTRL EXC Flag 1 Flag 0 Code Nature of segment
---- --- ------ ------ ---- ---------------------------------------
0 0 0 0 0 Red data, NOT {Checkpoint, EORP or EOB}
0 0 0 1 1 Red data, Checkpoint, NOT {EORP or EOB}
0 0 1 0 2 Red data, Checkpoint, EORP, NOT EOB
0 0 1 1 3 Red data, Checkpoint, EORP, EOB
0 1 0 0 4 Green data, NOT EOB 0 1 0 1 5 Green data, undefined 0 1 1 0 6 Green data, undefined 0 1 1 1 7 Green data, EOB
0 1 0 0 4つの緑データ、NOT EOB 0 1 0 1 5つの緑データ、不定0 1 1 0 6緑データ、不定0 1 1 1 7つの緑データ、EOB
1 0 0 0 8 Report segment 1 0 0 1 9 Report-acknowledgment segment 1 0 1 0 10 Control segment, undefined 1 0 1 1 11 Control segment, undefined
1 0 0 0 8報告セグメント1 0 0 1 9報告-肯定応答セグメント1 0 1 0 10制御セグメント、不定不定1 0 1 1 11制御セグメント、
1 1 0 0 12 Cancel segment from block sender 1 1 0 1 13 Cancel-acknowledgment segment to block sender
1 1 0 0 12ブロックの送信者から送信者をブロックする1 1 0 1 13キャンセル確認応答セグメントをセグメントキャンセル
1 1 1 0 14 Cancel segment from block receiver 1 1 1 1 15 Cancel-acknowledgment segment to block receiver
1 1 1 0 14は、ブロックレシーバからセグメントをキャンセルするキャンセル確認応答セグメント受信をブロックする1 1 1 1 15
For the purposes of this specification, some bit patterns in the segment type flags field correspond to "segment classes" that are designated by mnemonics. The mnemonics are intended to evoke the characteristics shared by all types of segments characterized by these flag bit patterns.
本明細書の目的のために、セグメントタイプフラグフィールドの一部のビットパターンがニーモニックによって指定される「セグメントクラス」に相当します。ニーモニックは、これらのフラグビットパターンによって特徴付けられるすべてのセグメントタイプによって共有特性を喚起することを意図しています。
CTRL EXC Flag 1 Flag 0 Mnemonic Description
---- --- ------ ------ -------- ---------------------------
0 0 - 1
-- or --
0 0 1 - CP Checkpoint
0 0 1 - EORP End of red-part; red-part size = offset + length
0 0 1 - 赤部分のEORP終了。赤い部分のサイズ=オフセット+長さ
0 - 1 1 EOB End of block; block size = offset + length
0 - ブロックの1 EOBエンド。ブロックサイズ=オフセット+長さ
1 0 0 0 RS Report segment; carries reception claims
1つの0 0 0 RS報告セグメントと受信クレームを運び
1 0 0 1 RA Report-acknowledgment segment
1 0 0 1 RA報告、肯定応答セグメント
1 1 0 0 CS Cancel segment from block sender
1 1 0 0 CSは、ブロック送信者からセグメントをキャンセル
1 1 0 1 CAS Cancel-acknowledgment segment to block sender
1 1 0 1 CASキャンセル確認応答の送信者をブロックするセグメント
1 1 1 0 CR Cancel segment from block receiver
1 1 1 0 CRブロックレシーバからセグメントをキャンセル
1 1 1 1 CAR Cancel-acknowledgment segment to block receiver
受信機をブロックする1 1 1 1 CARキャンセル確認応答セグメント
1 1 - 0 Cx Cancel segment (generic)
1 1 - 0のCxがセグメントをキャンセル（ジェネリック）
1 1 - 1 CAx Cancel-acknowledgment segment (generic)
1 1 - 1 CAXキャンセル確認応答セグメント（一般）
The Extensions field enables the inclusion of zero or more functional extensions to the basic LTP segment, each in type-length-value (TLV) representation as explained below.
以下に説明するように拡張フィールドは、基本的なLTPセグメント、各タイプレングス値（TLV）表現にゼロ以上の機能拡張を含めることを可能にします。
The first octet of the Extensions field indicates the number of extensions present in the segment: the high-order 4 bits indicate the number of extension TLVs in the header (immediately following the extensions count octet and preceding the segment's content), while the low-order 4 bits indicate the number of extension TLVs in the trailer (immediately following the segment's content). That is, each segment may have from 0 to 15 extension TLVs in its header and from 0 to 15 extension TLVs in its trailer. In the absence of any extension TLVs, all bits of this extensions count octet MUST be set to zero.
拡張フィールドの最初のオクテットは、セグメント内に存在する拡張機能の数を示す：上位4ビットは、低ながら、ヘッダ内の拡張のTLVの数を（直ちに次の拡張子がオクテットカウント、セグメントのコンテンツに先行する）を示します上位4ビットは、（直ちにセグメントの内容以下）トレーラーに拡張のTLVの数を示します。すなわち、各セグメントは、そのヘッダに、そのトレーラーに0~15拡張のTLV 0から15まで拡張のTLVを有することができる、です。任意の拡張子のTLVが存在しない場合には、この拡張機能のすべてのビットは、オクテットはゼロに設定しなければなりません数えます。
Note that it is valid for header extensions to be immediately followed by trailer extensions; for example, since a CAx segment has no contents, it may have header extensions immediately followed by trailer extensions.
ヘッダ拡張はすぐにトレーラーの拡張子が続くことすることが有効であることに注意してください。 CAXセグメントがないコンテンツを持っていないので、例えば、それは直ちにトレーラ拡張続くヘッダ拡張を有していてもよいです。
Each extension consists of a one-octet tag identifying the type of the extension, followed by a length parameter in SDNV form, followed by a value of the specified length.
各延長部は、指定された長さの値が続くSDNV状の長さのパラメータが続く拡張のタイプを識別する1オクテットのタグで構成されています。
The diagram below illustrates the extension TLVs as they may occur in the header or trailer.
以下の図は、それらがヘッダ又はトレーラに起こり得るように拡張TLVを示します。
+--------+----///-----///--+
|ext-tag | length | value |
+--------+-------///-------+----------///-------+
|ext-tag | length | value |
+--------+-----///-----///-+---------////-------+
|ext-tag | length | value |
+--------+----------+----------+
The IANA maintains an LTP Extension Tag registry as shown below. See the IANA considerations section below for details of code point assignment in the Unassigned range.
以下に示すようにIANAは、LTP拡張タグレジストリを維持します。割り当てられていない範囲のコードポイントの割り当ての詳細については、以下のIANAの考慮事項を参照してください。
Extension tag Meaning
------------- -------
0x00 LTP authentication extension [LTPEXT]
0x01 LTP cookie extension [LTPEXT]
0x02-0xAF Unassigned
0xB0-0xBF Reserved
0xC0-0xFF Private / Experimental Use
Note that since the last quarter of the extension-tag space is for experimental use, implementations should be aware that collisions for these tags are possible.
拡張タグスペースの最後の四半期は、実験的な使用のためであることから、実装はこれらのタグの衝突が可能であることを認識すべきであることに注意してください。
The content of a data segment includes client service data and the metadata enabling the receiving client service instance to receive and make use of that data.
データセグメントの内容は、クライアント・サービス・データを受け取ると、そのデータを利用するために、受信クライアント・サービス・インスタンスを可能にするメタデータを含みます。
Client service ID (SDNV)
クライアントサービスのID（SDNV）
The client service ID number identifies the upper-level service to which the segment is to be delivered by the receiver. It is functionally analogous to a TCP port number. If multiple instances of the client service are present at the destination, multiplexing must be done by the client service itself on the basis of information encoded within the transmitted block.
クライアントサービスID番号は、セグメントが受信機によって送達されるべき上位レベルのサービスを識別する。これは、TCPポート番号に機能的に類似しています。クライアント・サービスの複数のインスタンスが先に存在する場合、多重化は、送信されたブロック内の符号化された情報に基づいて、クライアントサービス自体によって行われなければなりません。
Offset (SDNV)
オフセット（SDNV）
Offset indicates the location of the segment's client service data within the session's transmitted block. It is the number of bytes in the block prior to the byte from which the first octet of the segment's client service data was copied.
オフセットは、セッションの送信ブロック内のセグメントのクライアントサービスデータの位置を示します。これは、前のセグメントのクライアントサービスデータの最初のオクテットがコピーされたバイトのブロックのバイト数です。
Length (SDNV)
長さ（SDNV）
The length of the ensuing client service data, in octets.
オクテットでのその後のクライアントサービスデータの長さ、。
If the data segment is a checkpoint, the segment MUST additionally include the following two serial numbers (checkpoint serial number and report serial number) to support efficient retransmission. Data segments that are not checkpoints MUST NOT have these two fields in the header and MUST continue on directly with the client service data.
データセグメントは、チェックポイントである場合、セグメントは、さらに効率的な再送信をサポートするために、以下の2つのシリアル番号（シリアル番号をチェックポイントとシリアル番号をレポート）を含まなければなりません。チェックポイントではないデータ・セグメントは、ヘッダー内のこれら2つのフィールドがあってはならないとクライアントサービスのデータを直接に継続する必要があります。
Checkpoint serial number (SDNV)
チェックポイントのシリアル番号（SDNV）
The checkpoint serial number uniquely identifies the checkpoint among all checkpoints issued by the block sender in a session. The first checkpoint issued by the sender MUST have this serial number chosen randomly for security reasons, and it is RECOMMENDED that the sender use the guidelines in [ESC05] for this. Any subsequent checkpoints issued by the sender MUST have the serial number value found by incrementing the prior checkpoint serial number by 1. When a checkpoint segment is retransmitted, however, its serial number MUST be the same as when it was originally transmitted. The checkpoint serial number MUST NOT be zero.
チェックポイントのシリアル番号は、一意のセッションでブロック送信者によって発行されたすべてのチェックポイント間でチェックポイントを識別します。送信者によって発行された最初のチェックポイントは、セキュリティ上の理由からランダムに選ばれ、このシリアル番号を持っている必要があり、送信者は、このためのガイドライン[ESC05]を使用することをお勧めします。送信者によって発行された任意の後続のチェックポイントがチェックポイントセグメントが再送される場合1だけ前のチェックポイントのシリアル番号をインクリメントすることによって見出されたシリアル番号の値を持たなければならない、しかし、そのシリアル番号は、それが最初に送信されたときと同じでなければなりません。チェックポイントのシリアル番号はゼロであるはずがありません。
Report serial number (SDNV)
シリアル番号を報告する（SDNV）
If the checkpoint was queued for transmission in response to the reception of an RS (Section 6.13), then its value MUST be the report serial number value of the RS that caused the data segment to be queued for transmission.
チェックポイントは、RS（セクション6.13）の受信に応答して、送信のためにキューに入れられた場合、その値は、データセグメントが送信のためにキューイングさせRSのレポート通し番号値でなければなりません。
Otherwise, the value of report serial number MUST be zero.
それ以外の場合は、報告書のシリアル番号の値がゼロでなければなりません。
Client service data (array of octets)
クライアントサービスデータ（オクテットの配列）
The client service data carried in the segment is a copy of a subset of the bytes in the original client service data block, starting at the indicated offset.
セグメントで運ばクライアントサービスデータを示すオフセットで始まる元のクライアントサービス・データ・ブロックのバイトのサブセットのコピーです。
The content of an RS comprises one or more data reception claims, together with the upper and lower bounds of the scope within the data block to which the claims pertain. It also includes two serial numbers to support efficient retransmission.
RSの含有量は、一緒になって請求項が関係れたデータブロック内の範囲の上限および下限と、一つ以上のデータ受信クレームを含みます。また、効率的な再送信をサポートするために、2つのシリアル番号が含まれています。
Report serial number (SDNV)
シリアル番号を報告する（SDNV）
The report serial number uniquely identifies the report among all reports issued by the receiver in a session. The first report issued by the receiver MUST have this serial number chosen randomly for security reasons, and it is RECOMMENDED that the receiver use the guidelines in [ESC05] for this. Any subsequent RS issued by the receiver MUST have the serial number value found by incrementing the last report serial number by 1. When an RS is retransmitted however, its serial number MUST be the same as when it was originally transmitted. The report serial number MUST NOT be zero.
報告書のシリアル番号は、一意のセッションで受信機によって発行されたすべてのレポートの中で報告書を識別します。受信機によって発行された最初の報告書は、セキュリティ上の理由からランダムに選ばれ、このシリアル番号を持っている必要があり、受信機が、このためのガイドライン[ESC05]を使用することをお勧めします。受信機によって発行されたそれ以降のRSはRSしかし、再送のとき1で最後のレポートのシリアル番号をインクリメントすることによって見つかったシリアル番号値を持たなければならない、そのシリアル番号は、それが最初に送信されたときと同じでなければなりません。報告書のシリアル番号がゼロであってはなりません。
Checkpoint serial number (SDNV)
チェックポイントのシリアル番号（SDNV）
The value of the checkpoint serial number MUST be zero if the report segment is NOT a response to reception of a checkpoint, i.e., the reception report is asynchronous; otherwise, it MUST be the checkpoint serial number of the checkpoint that caused the RS to be issued.
報告セグメントは、チェックポイント、すなわち、受信レポートが非同期での受信に応答していない場合は、チェックポイントのシリアル番号の値はゼロでなければなりません。それ以外の場合は、RSが発行される原因となったチェックポイントのチェックポイントのシリアル番号でなければなりません。
Upper bound (SDNV)
上限（SDNV）
The upper bound of a report segment is the size of the block prefix to which the segment's reception claims pertain.
報告セグメントの上限は、セグメントの受信クレームが関係たブロックプレフィックスのサイズです。
Lower bound (SDNV)
下限（SDNV）
The lower bound of a report segment is the size of the (interior) block prefix to which the segment's reception claims do NOT pertain.
報告セグメントの下限は、セグメントの受信クレームは関係しないと（内部）ブロックプレフィックスのサイズです。
Reception claim count (SDNV)
レセプション請求数（SDNV）
The number of data reception claims in this report segment.
データ受信の数は、このレポートセグメントに主張します。
Reception claims
レセプションクレーム
Each reception claim comprises two elements: offset and length.
オフセットと長さ：各受信クレームは、2つの要素を含みます。
Offset (SDNV)
オフセット（SDNV）
The offset indicates the successful reception of data beginning at the indicated offset from the lower bound of the RS. The offset within the entire block can be calculated by summing this offset with the lower bound of the RS.
オフセットが示されたRSの下限からのオフセットで始まるデータの受信に成功したことを示します。全体ブロック内のオフセットRSの下限とこのオフセットを加算することにより算出することができます。
Length (SDNV)
長さ（SDNV）
The length of a reception claim indicates the number of contiguous octets of block data starting at the indicated offset that have been successfully received.
受信クレームの長さが示さ正常に受信されたことオフセットから始まるブロックデータの連続するオクテットの数を示します。
Reception claims MUST conform to the following rules:
レセプション主張は、以下の規則に従わなければなりません。
A reception claim's length shall never be less than 1 and shall never exceed the difference between the upper and lower bounds of the report segment.
受信クレームの長さが1未満になることはないものとし、報告セグメントの上限と下限との間の差を超えないものとします。
The offset of a reception claim shall always be greater than the sum of the offset and length of the prior claim, if any.
もしあれば常に、先行する請求項のオフセットと長さとの和よりも大きくなければならない受信クレームのオフセット。
The sum of a reception claim's offset and length and the lower bound of the report segment shall never exceed the upper bound of the report segment.
受信請求のオフセットと長さとの報告セグメントの下限は、報告セグメントの上限を超えないものとの合計。
Implied requests for retransmission of client service data can be inferred from an RS's data reception claims. However, *nothing* can be inferred regarding reception of block data at any offset equal to or greater than the segment's upper bound or at any offset less than the segment's lower bound.
クライアントサービスデータの再送のための暗黙の要求は、RSのデータ受信クレームから推測することができます。ただし、*何も*任意のブロックデータの受信に関して推測することができないセグメントの下限未満オフセットセグメントの上限又は任意で以上にオフセット。
For example, if the scope of a report segment has lower bound 0 and upper bound 6000, and the report contains a single data reception claim with offset 0 and length 6000, then the report signifies successful reception of the first 6000 bytes of the block. If the total length of the block is 6000, then the report additionally signifies successful reception of the entire block.
0と長さ6000をオフセットレポートセグメントの範囲は下0と上限6000に結合しており、レポートが有する単一のデータ受信クレームが含まれている場合、例えば、レポートは、ブロックの最初の6000バイトの受信成功を意味します。ブロックの合計長さが6000である場合、レポートは、さらに、ブロック全体の受信成功を意味します。
If on the other hand, the scope of a report segment has lower bound 1000 and upper bound 6000, and the report contains two data reception claims, one with offset 0 and length 2000 and the other with offset 3000 and length 500, then the report signifies successful reception only of bytes 1000-2999 and 4000-4499 of the block. From this we can infer that bytes 3000-3999 and 4500-5999 of the block need to be retransmitted, but we cannot infer anything about reception of the first 1000 bytes or of any subsequent data beginning at block offset 6000.
他方場合、レポートセグメントの範囲は1000と上限6000下限を有し、そしてレポートは、2件のデータ受信クレームが含まれ、を有するものは3000及び長さ500をオフセットし、レポートして0と長さ2000と他のオフセットバイトのみ1000-2999およびブロックの4000-4499の受信に成功したことを意味します。このことから、我々はそのバイトを推測することができます3000から3999とブロックの4500から5999には、再送信する必要があるが、我々は最初の1000バイトのまたはブロックから始まる、後続のデータの受信について何が6000をオフセット推測することはできません。
The content of an RA is simply the report serial number of the RS in response to which the segment was generated.
RAの内容は、単にセグメントが生成されたに応じてRSのレポートシリアル番号です。
Report serial number (SDNV)
シリアル番号を報告する（SDNV）
This field returns the report serial number of the RS being acknowledged.
このフィールドは、認知されているRSの報告書のシリアル番号を返します。
Cancel segments (Cx) carry a single byte reason-code with the following semantics:
キャンセルセグメント（Cxが）以下のセマンティクスを有する単一バイト理由コードを運びます。
Reason-Code Mnemonic Semantics
----------- -------- ---------------------------------------
00 USR_CNCLD Client service canceled session.
01 UNREACH Unreachable client service.
01 UNREACH到達不能クライアントサービス。
02 RLEXC Retransmission limit exceeded.
02 RLEXC再送信の制限を超えました。
03 MISCOLORED Received either a red-part data segment at block offset above any green-part data segment offset or a green-part data segment at block offset below any red-part data segment offset.
03 MISCOLOREDオフセット任意の緑色部分のデータセグメントまたはオフセット任意赤色部分データセグメントの下方にオフセットブロックにおける緑色部分データセグメント上にオフセットブロックにおける赤色部分データセグメントのいずれかを受信しました。
04 SYS_CNCLD A system error condition caused unexpected session termination.
04 SYS_CNCLDシステムエラー状態が予期しないセッション終了の原因となりました。
05 RXMTCYCEXC Exceeded the Retransmission-Cycles limit.
05 RXMTCYCEXCは再送サイクルの制限を超え。
06-FF Reserved
06-FF予約
The Cancel-acknowledgments (CAx) have no content.
キャンセル・確認応答（CAX）は内容を持ちません。
Note: The reason we use different cancel segment types for the originator and recipient is to allow a loopback mode to work without disturbing any replay protection mechanism in use.
注意：私たちは、発信者と受信者のためのセグメントタイプを異なるキャンセル使う理由は、ループバック・モードは、使用中のリプレイ保護メカニズムを乱すことなく作業できるようにすることです。
The segment trailer consists of a sequence of zero to 15 extension TLVs as described in Section 3.1.4 above.
上記セクション3.1.4に記載したように、セグメントトレーラーはゼロ15の拡張のTLVの配列からなります。
In all cases, the representation of request parameters is a local implementation matter, as are validation of parameter values and notification of the client service in the event that a request is found to be invalid.
パラメータ値の検証と要求が無効であることが判明した場合に、クライアントサービスの通知されているとして、すべての場合において、リクエストパラメータの表現は、ローカルの導入問題です。
In order to request transmission of a block of client service data, the client service MUST provide the following parameters to LTP:
クライアントサービスデータのブロックの送信を要求するためには、クライアントサービスは、LTPに、以下のパラメータを提供する必要があります。
Destination client service ID.
宛先クライアントサービスID。
Destination LTP engine ID.
先LTPエンジンID。
Client service data to send, as an array of bytes.
クライアントサービスのデータは、バイトの配列として、送信します。
Length of the data to be sent.
送信するデータの長さ。
Length of the red-part of the data. This value MUST be in the range from zero to the total length of data to be sent.
データの赤の部分の長さ。この値がゼロから送信されるデータの合計長さの範囲になければなりません。
On reception of a valid transmission request from a client service, LTP proceeds as follows.
次のようにクライアントサービスからの有効な送信要求を受信すると、LTPが進行します。
First, the array of data to be sent is subdivided as necessary, with each subdivision serving as the client service data of a single new LTP data segment. The algorithm used for subdividing the data is a local implementation matter; it is expected that data size constraints imposed by the underlying communication service, if any, will be accommodated in this algorithm.
まず、送信するデータのアレイは、各サブディビジョンは、単一の新しいLTPデータセグメントのクライアントサービスデータとして用いて、必要に応じて細分化されます。データを細分化するために使用されるアルゴリズムはローカルの導入問題です。あれば、基本的な通信サービスによって課されるデータサイズの制約は、このアルゴリズムに収容されることが期待されます。
The last (and only the last) of the resulting data segments must be marked as the EOB (end of block).
得られたデータセグメントの最後の（そして唯一の最後の）EOB（ブロックの最後）としてマークされなければなりません。
Note that segment type indicates that the client service data in a given LTP segment either is or is not in the red-part of the block. To prevent segment type ambiguity, each data segment MUST contain either only red-part data or only green-part data. Therefore, when the length of the block's red-part is N, the total length of the block is M, and N is not equal to M, the (N+1)th byte of the block SHOULD be the first byte of client service data in a green-part data segment. Note that this means that at the red-part boundary, LTP may send a segment of size lesser than the link MTU size. For bandwidth efficiency reasons, implementations MAY choose to instead mark the entire segment (within which the red-part boundary falls) as red-part, causing green-part data falling within the segment to also be treated as red-part.
そのセグメントタイプは、所与のLTPセグメント内のクライアントサービスデータであるか、またはブロックの赤色部分ではないいずれかのことを示しているに注意してください。セグメントタイプの曖昧さを防ぐために、各データ・セグメントは、赤の部分データのみ緑色部分のデータのいずれかを含まなければなりません。ブロックの赤色部分の長さは、N、ブロックの合計長さがMであり、NはMに等しくない場合したがって、ブロックのバイト番目（N + 1）は、クライアントサービスの最初のバイトであるべきですグリーンパートデータセグメント内のデータ。これは赤色部分の境界で、LTPがリンクMTUサイズよりも小さいサイズのセグメントを送信することができることを意味することに留意されたいです。帯域幅効率の理由のために、実装は、代わりに、また赤一部として扱われるべきセグメント内に入る緑色部分のデータを発生させる全セグメント（赤色部分の境界が属する内）赤の部分としてをマークするために選ぶかもしれ。
If the length of the block's red-part is greater than zero, then the last data segment containing red-part data must be marked as the EORP (end of red-part) segment by setting the appropriate segment type flag bits (Section 3.1.2). Zero or more preceding data segments containing red-part data (selected according to an algorithm that is a local implementation matter) MAY additionally be marked as a CP (Checkpoint), and serve as additional discretionary checkpoints (Section 3.1.2).
ブロックの赤色部分の長さがゼロより大きい場合、赤色の部分のデータを含む最後のデータ・セグメントは、適切なセグメントタイプフラグビット（セクション3.1を設定することによりEORP（赤色部分の端部）セグメントとしてマークされなければなりません。 2）。 （ローカル実装の問題であるアルゴリズムに従って選択された）赤色の部分データを含むゼロ個以上の先行するデータセグメントは、さらに、CP（チェックポイント）としてマークされ、そしてなどの追加の裁量チェックポイント（セクション3.1.2）に役立つかもしれません。
All data segments are appended to the (conceptual) application data queue bound for the destination engine, for subsequent transmission.
すべてのデータ・セグメントは、後続の送信のために、先のエンジンに向かう（概念的な）アプリケーション・データ・キューに追加されます。
Finally, a session start notice (Section 7.1) is sent back to the client service that requested the transmission.
最後に、セッション開始通知（7.1節）が送信を要求したクライアントサービスに送り返されます。
In order to request cancellation of a session, either as the sender or as the receiver of the associated data block, the client service must provide the session ID identifying the session to be canceled.
送信者としてまたは関連するデータブロックの受信機のいずれかとして、セッションの解除を要求するために、クライアントサービスが解除されるセッションを識別するセッションIDを提供しなければなりません。
On reception of a valid cancellation request from a client service, LTP proceeds as follows.
次のようにクライアントサービスから有効な解約要求を受信すると、LTPが進行します。
First, the internal "Cancel Session" procedure (Section 6.19) is invoked.
まず、内部の「セッションのキャンセル」の手順（セクション6.19）が呼び出されます。
Next, if the session is being canceled by the sender (i.e., the session originator part of the session ID supplied in the cancellation request is the local LTP engine ID):
セッションは送信者によってキャンセルされている場合、次の、（即ち、キャンセル要求で供給セッションIDのセッション発信部は、ローカルLTPエンジンIDです）。
- If none of the data segments previously queued for transmission as part of this session have yet been de-queued and transmitted -- i.e., if the destination engine cannot possibly be aware of this session -- then the session is simply closed; the "Close Session" procedure (Section 6.20) is invoked.
- 宛先エンジンはおそらくこのセッションを認識できない場合、すなわち、 - - データセグメントのいずれも以前にこのセッションの一部として送信するためにキューに入れられていない場合、まだデキューおよび送信されたセッションは、単に閉じられます。 「クローズセッション」の手順（セクション6.20）が呼び出されます。
- Otherwise, a CS (cancel by block sender) segment with the reason-code USR_CNCLD MUST be queued for transmission to the destination LTP engine specified in the transmission request that started this session.
- それ以外の場合は、理由コードUSR_CNCLDとCS（ブロック送信者によってキャンセル）セグメントは、このセッションを開始した送信要求に指定された宛先LTPエンジンへの送信のためにキューに入れられなければなりません。
Otherwise (i.e., the session is being canceled by the receiver):
そうでない場合（すなわち、セッションが受信機によってキャンセルされています）。
- If there is no transmission queue-set bound for the sender (possibly because the local LTP engine is running on a receive-only device), then the session is simply closed; the "Close Session" procedure (Section 6.20) is invoked.
- （ローカルLTPエンジンは受信専用デバイス上で実行されているため、おそらく）送信者のためにバインドされた送信キューセットがない場合、セッションは単に閉じられます。 「クローズセッション」の手順（セクション6.20）が呼び出されます。
- Otherwise, a CR (cancel by block receiver) segment with reason-code USR_CNCLD MUST be queued for transmission to the block sender.
- そうでない場合には、CR（ブロックレシーバによってキャンセル）理由コードUSR_CNCLD有するセグメントは、ブロック送信者に送信するためにキューに入れられなければなりません。
LTP is designed to run directly over a data-link layer protocol.
LTPは、データリンク層のプロトコル上で直接実行するように設計されています。
LTP MUST only be deployed directly over UDP, for software development purposes or for use in private local area networks, for example, in a sparse sensor network where the link, when available, is only used for LTP traffic.
LTPは、唯一のリンクは、利用できる、唯一のLTPのトラフィックのために使用されているまばらなセンサネットワークでは、例えば、ソフトウェア開発の目的またはプライベートローカルエリアネットワークで使用するために、直接、UDP上で展開する必要があります。
In either case, the protocol layer immediately underlying LTP is referred to as the "local data-link layer" for the purposes of this specification.
いずれの場合においても、直ちにLTPの基礎となるプロトコル層は、本明細書の目的のための「ローカルデータリンク層」と呼ばれます。
When the local data-link layer protocol is UDP, (a) the content of each UDP datagram MUST be an integral number of LTP segments and (b) the LTP authentication [LTPEXT] extension SHOULD be used unless the end-to-end path is one in which either the likelihood of datagram content corruption is negligible or the consequences of receiving and processing corrupt LTP segments are insignificant (as during software development). In addition, 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).
ローカルデータリンク層プロトコルがUDP、各UDPデータグラムの（a）の含有量がLTPセグメントの整数倍である必要があり、（b）はLTP認証が[LTPEXT】拡張は、エンドツーエンドパスしない限り使用すべきときデータグラムのコンテンツの破損の可能性が無視できるまたは破損LTPセグメントを受信し、処理の結果は、（ソフトウェア開発時のような）重要ではないいずれかのものです。エンドツーエンドのパスがデータグラムのコンテンツの可能性が破損がごくわずかである（いくつかのプライベートローカルエリアネットワークのように）または結果のいずれかのものである場合を除きまた、LTP認証[LTPEXT]拡張は、データの整合性を確保するために使用されるべき破損LTPセグメントを受信し、処理する（おそらくソフトウェア開発時のような）重要ではありません。
When the local data-link layer protocol is not UDP, the content of each local data-link layer protocol frame MUST be an integral number of LTP segments.
ローカルデータリンク層プロトコルがUDPでない場合、各局所データ・リンク層プロトコルのフレームの内容は、LTPセグメントの整数でなければなりません。
The local data-link layer protocol MUST be a protocol that, together with the operating environment in which that protocol is implemented, satisfies the following requirements:
ローカルデータリンク層プロトコルは、一緒になって、そのプロトコルが実装されている動作環境と、以下の要件を満たし、プロトコルでなければなりません。
- It is required to inform LTP whenever the link to a specific LTP destination is brought up or torn down. Similarly, it is required to inform the local LTP engine whenever it is known that a remote LTP engine is set to begin or stop communication with the local engine based on the engines' operating schedules.
- 特定のLTP先へのリンクを育てたり解体されるたびにLTPを通知するために必要とされます。同様に、リモートLTPエンジンがエンジン運転スケジュールに基づいて、ローカルエンジンとの通信を開始または停止するように設定されていることが知られているときはいつでもローカルLTPエンジンに通知する必要があります。
- It is required to provide link state cues to LTP upon transmission of the CP, RS (report), EORP, EOB, and Cx (cancel) segments so that timers can be started.
- タイマーが起動できるように、EORP、EOB、およびCxの（キャンセル）セグメントは、CP、RS（レポート）の送信時にLTPにリンク状態の手がかりを提供するために必要とされます。
- It is required to provide, upon request, the current distance (in light seconds) to any peer engine in order to calculate timeout intervals.
- （光秒）現在の距離は、タイムアウト間隔を計算するために、任意のピア・エンジンに、要求に応じて、提供することが必要です。
A MIB (Management Information Base) with the above parameters, updated periodically by the local data-link layer and the operating environment, should be made available to the LTP engine for its operations. The details of the MIB are, however, beyond the scope of this document.
ローカルデータリンク層と動作環境によって定期的に更新された上記パラメータを持つMIB（管理情報ベース）は、その操作のLTPエンジンに利用可能にされるべきです。 MIBの詳細は、このドキュメントの範囲を超えて、しかし、です。
The underlying data-link layer is required to never deliver incompletely received LTP segments to LTP. In the absence of the use of LTP authentication [LTPEXT], LTP also requires the underlying local data-link layer protocol to perform data integrity checking of the segments received. Specifically, the local data-link layer protocol is required to detect any corrupted segments received and to silently discard them.
基礎となるデータ・リンク層は、LTPに不完全受信LTPセグメントを提供することはありませんする必要があります。 LTP認証[LTPEXT]の使用の不在下で、LTPはまた、受信セグメントのチェック、データの整合性を実行するための基礎となるローカルデータリンク層プロトコルを必要とします。具体的には、ローカルデータリンク層プロトコルは、受信した破損セグメントを検出し、静かにそれらを廃棄する必要があります。
This section describes the internal procedures that are triggered by the occurrence of various events during the lifetime of an LTP session.
このセクションでは、LTPセッションの存続期間中に様々なイベントの発生によってトリガされる内部手順を記載しています。
Whenever the content of any of the fields of the header of any received LTP segment does not conform to this specification document, the segment is assumed to be corrupt and MUST be discarded immediately and processed no further. This procedure supersedes all other procedures described below.
任意の受信されたLTPセグメントのヘッダのフィールドのいずれかの含有量は、本仕様書に準拠していないときはいつでも、セグメントが破損であると仮定され、すぐに廃棄し、さらなる処理れてはなりません。この手順は、以下に記載の他の全ての手続きを優先します。
All internal procedures described below that are triggered by the arrival of a data segment are superseded by the following procedure in the event that the client service identified by the data segment does not exist at the local LTP engine:
データセグメントの到着によってトリガされ、以下に記載されているすべての内部手続きは、データ・セグメントによって識別クライアントサービスは、ローカルLTPエンジンに存在しない場合に、以下の手順によって取って代わられています。
- If there is no transmission queue-set bound for the block sender (possibly because the local LTP engine is running on a receive-only device), then the received data segment is simply discarded.
- （ローカルLTPエンジンは受信専用デバイス上で実行されている可能性があるため）ブロック送信者のためにバインドされた送信キューセットがない場合、受信したデータセグメントは単に破棄されます。
- Otherwise, if the data segment contains data from the red-part of the block, a CR with reason-code UNREACH MUST be enqueued for transmission to the block sender. A CR with reason-code UNREACH SHOULD be similarly enqueued for transmission to the data sender even if the data segment contained data from the green-part of the block; note however that (for example) in the case where the block receiver knows that the sender of this green-part data is functioning in a "beacon" (transmit-only) fashion, a CR need not be sent. In either case, the received data segment is discarded.
- データセグメントがブロックの赤色部分からのデータが含まれている場合はそれ以外の場合は、理由コードUNREACHとCRは、ブロック送信者に送信するためにキューに登録されなければなりません。理由コードUNREACHとCRは、同様に、データセグメントがブロックの緑色部分からのデータを含んでいた場合でも、データの送信者への送信のためにキューに登録されるべきです。ブロック受信機がこの緑の部分データの送信者が「ビーコン」に機能していることを知っている場合には（例えば）（送信のみ）ことファッション但し、CRは送信される必要はありません。いずれの場合においても、受信したデータセグメントは廃棄されます。
This procedure is triggered by the arrival of a link state cue indicating the start of transmission to a specified remote LTP engine.
この手順は、指定されたリモートLTPエンジンへの送信の開始を指示するリンク状態キューの到着によってトリガされます。
Response: the de-queuing and delivery of segments to the LTP engine specified in the link state cue begins.
応答：リンク状態キューに指定されたLTPエンジンへデキューイングおよびセグメントの配信が開始されます。
This procedure is triggered by the arrival of a link state cue indicating the de-queuing (for transmission) of a CP segment.
この手順は、CPセグメントの（送信用）のデキューイングを示すリンク状態キューの到着によってトリガされます。
Response: the expected arrival time of the RS segment that will be produced on reception of this CP segment is computed, and a countdown timer is started for this arrival time. However, if it is known that the remote LTP engine has ceased transmission (Section 6.5), then this timer is immediately suspended, because the computed expected arrival time may require an adjustment that cannot yet be computed.
応答：このCPセグメントのレセプションに生成されるRSセグメントの到着予定時刻が計算され、カウントダウンタイマーは、この到着時間のために開始されます。リモートLTPエンジンがトランスミッション（セクション6.5）を停止したことが分かっている場合に計算到着予定時刻がまだ計算できない調整を必要とするかもしれないのでしかし、このタイマーは直ちに中断されます。
This procedure is triggered by the arrival of a link state cue indicating the de-queuing (for transmission) of an RS segment.
この手順は、RSセグメントの（送信用）のデキューイングを示すリンク状態キューの到着によってトリガされます。
Response: the expected arrival time of the RA (report acknowledgment) segment in response to the reception of this RS segment is computed, and a countdown timer is started for this arrival time. However, as in Section 6.2, if it is known that the remote LTP engine has ceased transmission (Section 6.5), then this timer is immediately suspended, because the computed expected arrival time may require an adjustment that cannot yet be computed.
応答：このRSセグメントの受信に応答して、RA（レポートの確認応答）セグメントの到着予定時刻が計算され、カウントダウンタイマーは、この到着時間のために開始されます。計算された到着予定時刻がまだ計算できない調整を必要とするかもしれないのでしかし、6.2節と同様に、リモートLTPエンジンがトランスミッション（セクション6.5）を停止したことが分かっている場合、このタイマーは直ちに中断されます。
This procedure is triggered by the arrival of a link state cue indicating the cessation of transmission to a specified remote LTP engine.
この手順は、指定されたリモートLTPエンジンへの送信の停止を指示するリンク状態キューの到着によってトリガされます。
Response: the de-queuing and delivery to the underlying communication system of segments from traffic queues bound for the LTP engine specified in the link state cue ceases.
応答：リンク状態キューに停止指定LTPエンジンに結合されたトラフィックキューからセグメントの基礎となる通信システムへデキューイングおよび配達。
This procedure is triggered by the arrival of a link state cue indicating the cessation of transmission from a specified remote LTP engine to the local LTP engine. Normally, this event is inferred from advance knowledge of the remote engine's planned transmission schedule.
この手順は、指定されたリモートLTPエンジンからローカルLTPエンジンへの送信の停止を指示するリンク状態キューの到着によってトリガされます。通常、このイベントは、リモートエンジンの送信予定スケジュールの事前知識から推測されます。
Response: countdown timers for the acknowledging segments that the remote engine is expected to return are suspended as necessary based on the following procedure.
応答：リモート・エンジンが返すことが期待される肯定応答セグメントのカウントダウンタイマーは、以下の手順に基づいて、必要に応じて中断されています。
The nominal remote engine acknowledge transmission time is computed as the sum of the transmission time of the original segment (to which the acknowledging segment will respond) and the one-way light time to the remote engine, plus N seconds of "additional anticipated latency" (AAL) encompassing anticipated transmission delays other than signal propagation time. N is determined in an implementation-specific manner. For example, when LTP is deployed in deep-space vehicles, the one-way light time to the remote engine may be very large while N may be relatively small, covering processing and queuing delays. N may be a network management parameter, for which 2 seconds seems like a reasonable default value. As another example, when LTP is deployed in a terrestrial "data mule" environment, one-way light time latency is effectively zero while N may need to be some dynamically computed function of the data mule circulation schedule.
送信時刻を確認公称リモートエンジンは、元のセグメント（これに肯定応答セグメントが応答する）とリモートエンジンへの一方向光時の伝送時間の和として計算、プラスN「追加の予想される待ち時間」の秒（AAL）信号伝搬時間以外の予想される伝送遅延を包含する。 Nは、実装固有の方法で決定されます。 LTPは、深宇宙ビークルに配備されたときにN処理とキューイング遅延を覆う、比較的小さいかもしれないが、例えば、リモートエンジンに一方向光時間が非常に大きくてもよいです。 Nは2秒が妥当なデフォルト値のように思えるするネットワーク管理パラメータであってもよいです。 LTPは、地上「データラバ」環境に展開されたとき、Nはデータラバ循環スケジュールの一部を動的に計算関数であることが必要かもしれない別の例として、一方向光時間遅延は事実上ゼロです。
If the nominal remote engine acknowledge transmission time is greater than or equal to the current time (i.e., the acknowledging segment may be presented for transmission during the time that transmission at the remote engine is suspended), then the countdown timer for this acknowledging segment is suspended.
送信時刻を確認公称リモートエンジン（すなわち、肯定応答セグメントは、リモートエンジンでその送信が中断される時間の間に送信するために提示されてもよい）、現在の時間以上である場合、この肯定応答セグメントのカウントダウンタイマーであります中断。
This procedure is triggered by the arrival of a link state cue indicating the start of transmission from a specified remote LTP engine to the local LTP engine. Normally, this event is inferred from advance knowledge of the remote engine's planned transmission schedule.
この手順は、指定されたリモートLTPエンジンからローカルLTPエンジンへの送信の開始を指示するリンク状態キューの到着によってトリガされます。通常、このイベントは、リモートエンジンの送信予定スケジュールの事前知識から推測されます。
Response: expected arrival time is adjusted for every acknowledging segment that the remote engine is expected to return, for which the countdown timer has been suspended. First, the transmission delay interval is calculated as follows:
回答：到着予定時刻をカウントダウンタイマーが一時停止されたリモートエンジンが返すことが期待されているすべて認めセグメントのために調整されています。まず、次のように伝送遅延間隔が計算されます。
- The nominal remote engine acknowledge transmission time is computed as the sum of the transmission time of the original segment (to which the acknowledging segment will respond) and the one-way light time to the remote engine, plus N seconds of AAL Section 6.5.
- 公称リモートエンジンは、送信時間は、元のセグメント（これに肯定応答セグメントが応答する）とリモートエンジンへの一方向光時の伝送時間の和として計算される肯定応答に加え、N AALセクション6.5秒。
- If the nominal remote engine acknowledge transmission time is greater than the current time, i.e., the remote engine resumed transmission prior to presentation of the acknowledging segment for transmission, then the transmission delay interval is zero.
- 公称リモートエンジンは、送信時間を認める場合は、すなわち、リモートエンジンは、従来の伝送のための肯定応答セグメントのプレゼンテーションへの送信を再開し、その後、伝送遅延時間がゼロである、現在の時刻よりも大きいです。
- Otherwise, the transmission delay interval is computed as the current time less the nominal remote engine acknowledge transmission time.
- そうでない場合、伝送遅延間隔は、より少ない名目リモートエンジンは、送信時刻を確認現在の時間として計算されます。
The expected arrival time is increased by the computed transmission delay interval for each of the suspended countdown timers, and the timers are resumed.
到着予定時刻が停止カウントダウンタイマーのそれぞれについて計算された伝送遅延間隔だけ増加させ、タイマーが再開されます。
This procedure is triggered by the expiration of a countdown timer associated with a CP segment.
この手順は、CPセグメントに関連付けられたカウントダウンタイマーの満了によってトリガされます。
Response: if the number of times this CP segment has been queued for transmission exceeds the checkpoint retransmission limit established for the local LTP engine by network management, then the session of which the segment is one token is canceled: the "Cancel Session" procedure (Section 6.19) is invoked, a CS with reason-code RLEXC is appended to the (conceptual) application data queue, and a transmission-session cancellation notice (Section 7.5) is sent back to the client service that requested the transmission.
応答：このCPセグメントが送信のためにキューイングされた回数は、ネットワーク管理によってローカルLTPエンジンのための確立されたチェックポイント再送信限度を超えると、セグメントは、一つのトークンが取り消されたセッションとなっている：「取消セッション」手順（セクション6.19）は（概念的な）アプリケーション・データ・キューに追加されているCS理由コードRLEXCと、呼び出され、送信セッションの解除通知（セクション7.5）が送信を要求したクライアントサービスに送り返されます。
Otherwise, a new copy of the CP segment is appended to the (conceptual) application data queue for the destination LTP engine.
そうでなければ、CPセグメントの新しいコピーが先LTPエンジンの（概念的な）アプリケーション・データ・キューに追加されます。
This procedure is triggered by either (a) the expiration of a countdown timer associated with an RS segment or (b) the reception of a CP segment for which one or more RS segments were previously issued -- a redundantly retransmitted checkpoint.
冗長再送チェックポイント - この手順は、RSセグメントまたは1つ以上のRSセグメントが以前に発行されたためにCPセグメントの（b）の受信に関連したカウントダウンタイマーのいずれかの（a）の満了によってトリガされます。
Response: if the number of times any affected RS segment has been queued for transmission exceeds the report retransmission limit established for the local LTP engine by network management, then the session of which the segment is one token is canceled: the "Cancel Session" procedure (Section 6.19) is invoked, a CR segment with
応答：影響を受けるRSセグメントが送信のためにキューイングされた回数は、ネットワーク管理によってローカルLTPエンジンのための確立されたレポートの再送信限度を超えると、セグメントは、一つのトークンが取り消されたセッションとなっている：「取消セッション」手順（セクション6.19）が呼び出され、CRセグメントと
reason-code RLEXC is queued for transmission to the LTP engine that originated the session, and a reception-session cancellation notice (Section 7.6) is sent to the client service identified in each of the data segments received in this session.
理由コードRLEXCは、セッションを開始したLTPエンジンへの送信のためにキューイングされ、そして受信セッションの解除通知（セクション7.6）がこのセッションで受信されたデータセグメントの各々において同定クライアントサービスに送信されます。
Otherwise, a new copy of each affected RS segment is queued for transmission to the LTP engine that originated the session.
それ以外の場合は、影響を受ける各RSセグメントの新しいコピーがセッションを開始したLTPエンジンへの伝送のためにキューイングされます。
This procedure is triggered by the arrival of a CP segment when the EORP for this session has been received (ensuring that the size of the data block's red-part is known; this includes the case where the CP segment itself is the EORP segment) and all data in the red-part of the block being transmitted in this session have been received.
（;これはCPセグメント自体がEORPセグメントである場合を含むデータブロックの赤の部分のサイズが既知であることを保証する）、この手順は、このセッションのためEORPが受信されたCPセグメントの到着によってトリガされますこのセッションで送信されているブロックの赤色部分内のすべてのデータが受信されています。
Response: a red-part reception notice (Section 7.3) is sent to the specified client service.
回答：赤の部分の受信通知（7.3節）が指定されたクライアントサービスに送信されます。
This procedure is triggered by the arrival of a data segment whose content is a portion of the green-part of a block.
この手順は、コンテンツブロックの緑色部分の一部であるデータセグメントの到着によってトリガされます。
Response: a green-part segment arrival notice (Section 7.2) is sent to the specified client service.
応答：緑色部分セグメントの到着通知（セクション7.2）が指定されたクライアントサービスに送信されます。
This procedure is triggered by either (a) the original reception of a CP segment (the checkpoint serial number identifying this CP is new) (b) an implementation-specific circumstance pertaining to a particular block reception session for which no EORP has yet been received ("asynchronous" reception reporting).
この手順は、（b）は、実装固有の状況が全くEORPがまだ受信されていないいる特定のブロックの受信セッションに関連する（このCPを特定するチェックポイントのシリアル番号が新しい）CPセグメントの（a）は、元の受信のいずれかによってトリガされ（「非同期」受信報告）。
Response: if the number of reception problems detected for this session exceeds a limit established for the local LTP engine by network management, then the affected session is canceled: the "Cancel Session" procedure (Section 6.19) is invoked, a CR segment with reason-code RLEXC is issued and is, in concept, appended to the queue of internal operations traffic bound for the LTP engine that originated the session, and a reception-session cancellation notice (Section 7.6) is sent to the client service identified in each of the data segments received in this session. One possible limit on reception problems would be the maximum number of reception reports that can be issued for any single session.
応答：このセッションのために検出した受信多くの問題は、ネットワーク管理によってローカルLTPエンジンのための確立された限界を超えると、影響を受けるセッションがキャンセルされた：「セッションのキャンセル」手順（セクション6.19）が呼び出され、理由がCRセグメント-code RLEXCは、セッションを開始したLTPエンジン、および受信セッション解約通知書（7.6節）に向かうトラフィックは、それぞれに特定されたクライアントサービスに送信され発行されている、という概念では、内部動作のキューに追加されますデータセグメントは、このセッションで受信しました。受信問題の一つの可能な制限は、任意の単一のセッションのために発行することができます受信レポートの最大数になります。
If such a limit is not reached, a reception report is issued as follows.
そのような限界に達していない場合は、次のように、受信レポートが発行されます。
If production of the reception report was triggered by reception of a checkpoint:
受信報告書の作成は、チェックポイントの受信によってトリガされた場合：
- The upper bound of the report SHOULD be the upper bound (the sum of the offset and length) of the checkpoint data segment, to minimize unnecessary retransmission. Note: If a discretionary checkpoint is lost but subsequent segments are received, then by the time the retransmission of the lost checkpoint is received the receiver would have segments at block offsets beyond the upper bound of the checkpoint. For deployments where bandwidth economy is not critical, the upper bound of a synchronous reception report MAY be the maximum upper bound value among all red-part data segments received so far in the affected session.
- レポートの上限は、不必要な再送を最小限に抑えるために、チェックポイント・データ・セグメントの上限（オフセットと長さの合計）であるべきです。注意：任意のチェックポイントが失われたが、その後のセグメントが受信された場合、失われたチェックポイントの再送信が受信され、その後、時間によって受信機は、チェックポイントの上限を超えてブロックオフセットでセグメントを持っているでしょう。帯域幅経済が重要ではない展開のために、同期受信レポートの上限は、すべての赤の部分データセグメントのうちの最大上限値は該当セッションでこれまでに受信されてもよいです。
- If the checkpoint was itself issued in response to a report segment, then this report is a "secondary" reception report. In that case, the lower bound of the report SHOULD be the lower bound of the report segment to which the triggering checkpoint was itself a response, to minimize unnecessary retransmission. Note: For deployments where bandwidth economy is not critical, the lower bound of the report MAY instead be zero.
- チェックポイントは報告セグメントに応答して発行そのものだった場合は、この報告書では、「二次」受信レポートです。その場合には、レポートの下限は、トリガーチェックポイントが不要な再送を最小限にするために、応答自体であったために、レポートセグメントの下限であるべきです。注：帯域幅経済が重要ではない展開では、レポートの下限ではなく、0であってもよいです。
- If the checkpoint was not issued in response to a report segment, this report is a "primary" reception report. The lower bound of the first primary reception report issued for any session MUST be zero. The lower bound of each subsequent primary reception report issued for the same session SHOULD be the upper bound of the prior primary reception report issued for the session, to minimize unnecessary retransmission. Note: For deployments where bandwidth economy is not critical, the lower bound of every primary reception report MAY be zero.
- チェックポイントが報告セグメントに応答して発行されなかった場合は、この報告書は、「プライマリ」レセプションレポートです。すべてのセッションのために発行される最初のプライマリ受信報告の下限はゼロでなければなりません。同じセッションのために発行される後続の各一次受信レポートの下限は、不必要な再送を最小限にするために、セッションのために発行された前の一次受信レポートの上限であるべきです。注：帯域幅経済が重要ではない展開では、すべての主要な受信レポートの下限はゼロであってもよいです。
If production of the reception report is "asynchronous" as noted above:
上記のように受信報告書の作成は、「非同期」の場合：
- The upper bound of the report MUST be the maximum upper bound among all red-part data segments received so far for this session.
- レポートの上限は、すべての赤の部分データセグメントのうちの最大上限は、このセッションのためにこれまでに受信されなければなりません。
- The lower bound of the first asynchronous reception report issued for any session for which no other primary reception reports have yet been issued MUST be zero. The lower bound of each subsequent asynchronous reception report SHOULD be the upper bound of the prior primary reception report issued for the session, to minimize unnecessary retransmission. Note: For deployments where bandwidth economy is not critical, the lower bound of every asynchronous reception report MAY be zero.
- 他のプライマリ受信報告はまだ発行されていないいるすべてのセッションのために発行される最初の非同期受信レポートの下限はゼロでなければなりません。各後続の非同期受信レポートの下限は、不必要な再送を最小限にするために、セッションのために発行された前の一次受信レポートの上限であるべきです。注：帯域幅経済が重要ではない展開では、すべての非同期受信レポートの下限はゼロであってもよいです。
In all cases, if the applicable lower bound of the scope of a report is determined to be greater than or equal to the applicable upper bound (for example, due to out-of-order arrival of discretionary checkpoints) then the reception report MUST NOT be issued. Otherwise:
全ての場合において、レポートの範囲の下限適用は（これは裁量チェックポイントのアウトオブオーダー到着に、例えば）よりも大きいかまたは適用上限に等しくなるように決定されたならば、受信レポートがNOT MUST発行される。そうでなければ：
As many RS segments must be produced as are needed in order to report on all data reception within the scope of the report, given whatever data size constraints are imposed by the underlying communication service. The RS segments are, in concept, appended to the queue of internal operations traffic bound for the LTP engine that originated the indicated session. The lower bound of the first RS segment of the report MUST be the reception report's lower bound. The upper bound of the last RS segment of the report MUST be the reception report's upper bound.
基本的な通信サービスでどんなデータサイズ制約を課される所与、レポートの範囲内でのすべてのデータの受信をレポートするために必要とされる限り多くのRSセグメントが生成されなければなりません。 RSセグメントは、コンセプトに、示されたセッションを開始したLTPエンジンのためにバインドされ内部動作トラフィックのキューに追加されます。下のレポートの最初のRSセグメントのバインドレセプションレポートの下界でなければなりません。レポートの最後のRSセグメントの上限は、受信レポートの上限でなければなりません。
This procedure is triggered at the earliest time at which (a) all data in the block are known to have been transmitted *and* (b) the entire red-part of the block -- if of non-zero length -- is known to have been successfully received. Condition (a) is signaled by arrival of a link state cue indicating the de-queuing (for transmission) of the EOB segment for the block. Condition (b) is signaled by reception of an RS segment whose reception claims, taken together with the reception claims of all other RS segments previously received in the course of this session, indicate complete reception of the red-part of the block.
この手順は、*（a）はブロック内のすべてのデータが送信されてきたことが知られている最も早い時間でトリガ及び*ブロックの（B）全体赤色部分である - は、非ゼロ長の場合 - 知られています正常に受信されています。条件（A）は、ブロックのEOBセグメントの（送信用）のデキューイングを示すリンク状態キューの到着によってシグナリングされます。条件（b）は、以前にこのセッションの過程で受信されたすべての他のRSセグメントの受信クレームと一緒になって、受信クレームRSセグメントの受信によって合図され、ブロックの赤色部分の受信完了を示します。
Response: a transmission-session completion notice (Section 7.4) is sent to the local client service associated with the session, and the session is closed: the "Close Session" procedure (Section 6.20) is invoked.
回答：トランスミッションセッション完了通知（7.4節）は、セッションに関連付けられたローカルクライアントサービスに送信され、セッションが閉じている：「クローズセッション」の手順（セクション6.20）が呼び出されます。
This procedure is triggered by the reception of an RS segment.
この手順は、RSセグメントの受信によってトリガされます。
Response: first, an RA segment with the same report serial number as the RS segment is issued and is, in concept, appended to the queue of internal operations traffic bound for the receiver. If the RS segment is redundant -- i.e., either the indicated session is unknown (for example, the RS segment is received after the session has been completed or canceled) or the RS segment's report serial number matches that of an RS segment that has already been received and processed -- then no further action is taken. Otherwise, the procedure below is followed.
回答：まず、同じレポートでRAセグメントはRSセグメントとしてシリアル番号が発行されているが、概念で、受信機に向かう内部動作トラフィックのキューに追加されます。 RSセグメントが冗長であるならば - つまり、どちらか示さセッションは不明です（セッションが完了またはキャンセルされた後、たとえば、RSセグメントが受信される）、またはRSセグメントの報告書のシリアル番号が既に持っているRSセグメントのことと一致して受信および処理されて - そして、それ以上のアクションは取られません。それ以外の場合は、以下の手順に従っています。
If the report's checkpoint serial number is not zero, then the countdown timer associated with the indicated checkpoint segment is deleted.
レポートのチェックポイントのシリアル番号がゼロでない場合は、指示されたチェックポイントのセグメントに関連するカウントダウンタイマーが削除されます。
Note: All retransmission buffer space occupied by data whose reception is claimed in the report segment can (in concept) be released.
注意：その受信報告セグメントに記載されている（概念に）解放することができるデータによって占めすべての再送バッファスペースを。
If the segment's reception claims indicate incomplete data reception within the scope of the report segment:
セグメントの受信クレームレポートセグメントの範囲内に不完全なデータの受信を示す場合。
- If the number of transmission problems for this session exceeds a limit established for the local LTP engine by network management, then the session of which the segment is one token is canceled: the "Cancel Session" procedure (Section 6.19) is invoked, a CS with reason-code RLEXC is appended to the transmission queue specified in the transmission request that started this session, and a transmission-session cancellation notice (Section 7.5) is sent back to the client service that requested the transmission. One possible limit on transmission problems would be the maximum number of retransmission CP segments that may be issued for any single session.
- このセッションの送信の問題の数は、ネットワーク管理によってローカルLTPエンジンのための確立された限界を超えると、セグメントは、一つのトークンが取り消されたセッションとなっている（セクション6.19）は、呼び出された「キャンセルセッション」手順理由コードRLEXCとCSは、このセッションを開始した送信要求に指定された送信キューに追加され、送信セッション解約通知書（セクション7.5）は、送信を要求したクライアントサービスに送り返されます。送信の問題に一つの可能な限界は、任意の単一のセッションのために発行することができる再送CPセグメントの最大数であろう。
- If the number of transmission problems for this session has not exceeded any limit, new data segments encapsulating all block data whose non-reception is implied by the reception claims are appended to the transmission queue bound for the receiver. The last -- and only the last -- data segment must be marked as a CP segment carrying a new CP serial number (obtained by incrementing the last CP serial number used) and the report serial number of the received RS segment.
- このセッションの送信の問題の数は、任意の制限を超えていない場合、未受信の受信請求の範囲によって包含される全てのブロックデータをカプセル化する新しいデータセグメントが受信機にバインド送信キューに追加されます。最後に - と最後の - データセグメントは、レポート受信したRSセグメントのシリアル番号（最後に使用しCPのシリアル番号をインクリメントした）新しいCPシリアル番号を搬送CPセグメントとしてマークされなければなりません。
This procedure is triggered by the reception of an RA.
この手順は、RAの受信によってトリガされます。
Response: the countdown timer associated with the original RS segment (identified by the report serial number of the RA segment) is deleted. If no other countdown timers associated with RS segments exist for this session, then the session is closed: the "Close Session" procedure (Section 6.20) is invoked.
回答：（RAセグメントの報告書のシリアル番号で識別される）元RSセグメントに関連したカウントダウンタイマーが削除されます。 RSセグメントに関連付けられた他のカウントダウンタイマーがこのセッションのために存在しない場合、セッションは閉じている：「クローズセッション」手順（セクション6.20）が呼び出されます。
This procedure is triggered by arrival of a link state cue indicating the de-queuing (for transmission) of a Cx segment.
この手順は、Cxのセグメントの（送信用）のデキューイングを示すリンク状態キューの到着によってトリガされます。
Response: the expected arrival time of the CAx segment that will be produced on reception of this Cx segment is computed and a countdown timer for this arrival time is started. However, if it is known that the remote LTP engine has ceased transmission (Section 6.5), then this timer is immediately suspended, because the computed expected arrival time may require an adjustment that cannot yet be computed.
応答：このCxのセグメントの受信時に生成されるCAXセグメントの到着予定時刻が計算され、この到着時間のカウントダウンタイマーが開始されます。リモートLTPエンジンがトランスミッション（セクション6.5）を停止したことが分かっている場合に計算到着予定時刻がまだ計算できない調整を必要とするかもしれないのでしかし、このタイマーは直ちに中断されます。
This procedure is triggered by the expiration of a countdown timer associated with a Cx segment.
この手順は、Cxのセグメントに関連付けられたカウントダウンタイマーの満了によってトリガされます。
Response: if the number of times this Cx segment has been queued for transmission exceeds the cancellation retransmission limit established for the local LTP engine by network management, then the session of which the segment is one token is simply closed: the "Close Session" procedure (Section 6.20) is invoked.
応答：このCxのセグメントが送信のためにキューイングされた回数は、ネットワーク管理によってローカルLTPエンジンのための確立されたキャンセル再送限界を超えた場合、その後、セグメントは、一つのトークンが、セッション単に閉じられているとなっている：「閉じるセッション」手順（セクション6.20）が呼び出されます。
Otherwise, a copy of the cancellation segment (retaining the same reason-code) is queued for transmission to the appropriate LTP engine.
そうでない場合は、キャンセルセグメント（同じ理由コードを保持する）のコピーが、適切なLTPエンジンへの送信のためにキューイングされます。
This procedure is triggered by the reception of a Cx segment.
この手順は、Cxのセグメントの受信によってトリガされます。
Response: in the case of a CS segment where there is no transmission queue-set bound for the sender (possibly because the receiver is a receive-only device), then no action is taken. Otherwise:
応答：送信者行きない送信キューセットは、（受信機が受信専用デバイスである可能性があるため）が存在しないCSセグメントの場合には、その後何のアクションがとられません。そうでなければ：
- If the received segment is a CS segment, a CAS (cancel acknowledgment to block sender) segment is issued and is, in concept, appended to the queue of internal operations traffic bound for the sender.
- 受信したセグメントがCSセグメントである場合は、CAS（送信者をブロックするために承認を取り消す）セグメントが発行している、という概念では、送信者のためにバインドされ内部動作トラフィックのキューに追加されます。
- If the received segment is a CR segment, a CAR (cancel acknowledgment to block receiver) segment is issued and is, in concept, appended to the queue of internal operations traffic bound for the receiver.
- 受信されたセグメントがCRセグメント、CARである場合（受信をブロックする確認応答をキャンセル）セグメントが発行されている、コンセプトに、受信機に向かう内部動作トラフィックのキューに追加されます。
It is possible that the Cx segment has been retransmitted because a previous responding acknowledgment CAx (cancel acknowledgment) segment was lost, in which case there will no longer be any record of the session of which the segment is one token. If so, no further action is taken.
もはやセグメントが1つのトークンとなっているセッションの任意のレコードがあるだろう、その場合には、以前の応答確認CAX（承認を取り消す）セグメントが失われた、ので、Cxのセグメントが再送されている可能性がありません。もしそうなら、それ以上のアクションは実行されません。
Otherwise: the "Cancel Session" procedure (Section 6.19) is invoked and a reception-session cancellation notice (Section 7.6) is sent to the client service identified in each of the data segments received in this session. Finally, the session is closed: the "Close Session" procedure (Section 6.20) is invoked.
そうでない場合は「セッションをキャンセル」手順（セクション6.19）が呼び出され、受信セッションの解除通知（セクション7.6）がこのセッションで受信されたデータセグメントの各々において同定クライアントサービスに送信されます。最後に、セッションが閉じている：「クローズセッション」の手順（セクション6.20）が呼び出されます。
This procedure is triggered by the reception of a CAx segment.
この手順は、CAXセグメントの受信によってトリガされます。
Response: the timer associated with the Cx segment is deleted, and the session of which the segment is one token is closed, i.e., the "Close Session" procedure (Section 6.20) is invoked.
応答：Cxのセグメントに関連付けられたタイマーが削除され、セッションは、セグメントは、一つのトークンが、閉じている、すなわち、「クローズセッション」手順（セクション6.20）が起動されています。
This procedure is triggered internally by one of the other procedures described above.
この手順は、上記の他の手順のいずれかによって内部でトリガされます。
Response: all segments of the affected session that are currently queued for transmission can be deleted from the outbound traffic queues. All countdown timers currently associated with the session are deleted. Note: If the local LTP engine is the sender, then all remaining data retransmission buffer space allocated to the session can be released.
回答：現在の送信のためにキューイングされている影響を受けたセッションのすべてのセグメントは、アウトバウンドトラフィックキューから削除することができます。現在のセッションに関連付けられているすべてのカウントダウンタイマーが削除されます。注意：ローカルLTPエンジンが送信者である場合は、そのセッションに割り当てられ、残りのすべてのデータ再送バッファスペースを解放することができます。
This procedure is triggered internally by one of the other procedures described above.
この手順は、上記の他の手順のいずれかによって内部でトリガされます。
Response: any remaining countdown timers associated with the session are deleted. The session state record (SSR|RSR) for the session is deleted; existence of the session is no longer recognized.
応答：セッションに関連付けられている残りのカウントダウンタイマーが削除されます。セッション状態レコード（SSR | RSR）セッションのために削除されます。セッションの存在は、もはや認識されません。
This procedure is triggered by the arrival of either (a) a red-part data segment whose block offset begins at an offset higher than the block offset of any green-part data segment previously received for the same session or (b) a green-part data segment whose block offset is lower than the block offset of any red-part data segment previously received for the same session. The arrival of a segment matching either of the above checks is a violation of the protocol requirement of having all red-part data as the block prefix and all green-part data as the block suffix.
この手順は、ブロックオフセットで始まる（a）の赤色部分データセグメントのいずれかの到着によってトリガされるオフセット以前に同じセッションまたは（b）の緑色のために受信された任意の緑色部分データセグメントのオフセットブロックよりも高いですそのブロックオフセット以前に同じセッションのために受信された任意の赤色部分データセグメントのオフセットブロックよりも低い部分データセグメント。上記のチェックのいずれかに一致するセグメントの到着は、ブロックサフィックスとしてブロックプレフィックスとすべての緑の部分のデータとして、すべての赤の部分のデータを有するのプロトコル要件の違反です。
Response: the received data segment is simply discarded.
回答：受信したデータセグメントが単に破棄されます。
The Cancel Session procedure (Section 6.19) is invoked and a CR segment with reason-code MISCOLORED SHOULD be enqueued for transmission to the data sender.
取消セッション手順（セクション6.19）が呼び出され、理由コードMISCOLOREDとCRセグメントは、データ送信者への送信のためにキューに登録されるべきです。
Note: If there is no transmission queue-set bound for the sender (possibly because the local LTP engine is running on a receive-only device), or if the receiver knows that the sender is functioning in a "beacon" (transmit-only) fashion, a CR segment need not be sent.
送信者のためにバインドされた送信キューセットがない場合（ローカルLTPエンジンは受信専用デバイス上で実行されている可能性のため）、又は受信機は、送信者が「ビーコン」に機能していることを知っている場合（送信専用：注意）ファッション、CRセグメントが送信される必要はありません。
A reception-session cancellation notice (Section 7.6) is sent to the client service.
受信セッションの解除通知（セクション7.6）は、クライアントサービスに送信されます。
It is possible (especially for long-lived LTP sessions) that an unexpected operating system error condition may occur during the lifetime of an LTP session. An example is the case where the system faces severe memory crunch forcing LTP sessions into a scenario similar to that of TCP SACK [SACK] reneging. But unlike TCP SACK reception reports, which are advisory, LTP reception reports are binding, and reneging is NOT permitted on previously made reception claims.
これは、予期しないオペレーティング・システム・エラー条件がLTPセッションの存続期間中に発生する可能性があること（特に長寿命のLTPセッションのために）可能です。例えば、システムがTCP SACK [SACK] renegingと同様のシナリオにLTPセッションを強制的に厳しいメモリ危機に直面している場合です。しかし助言されているTCP SACKのレセプションレポートとは異なり、LTP受信レポートが結合され、そしてrenegingは以前に作られた受信主張で許可されていません。
Under any such irrecoverable system error condition, the following response is to be initiated: the Cancel Session procedure (Section 6.19) is invoked. If the error condition is observed on the sender, a CS segment with reason-code SYS_CNCLD SHOULD be enqueued for transmission to the receiver, and a transmission-session cancellation notice (Section 7.5) is sent to the client service; on the other hand, if it is observed on the receiver, a CR segment with the same reason-code SYS_CNCLD SHOULD be enqueued for transmission to the sender, and a reception-session cancellation notice (Section 7.6) is sent to the client service.
どのように回復不能なシステム・エラー条件では、以下の応答が開始される：キャンセルセッション手順（セクション6.19）が呼び出されます。エラー条件が送信者に観察される場合、理由コードSYS_CNCLDとCSセグメントは、受信機への送信のために待ち行列に入れなければならず、送信セッションの解除通知（セクション7.5）は、クライアントサービスに送信されます。それは受信機で観察された場合には、同じ理由コードSYS_CNCLDとCRセグメントが送信者に送信するためにエンキューされるべきであり、受信セッションの解除通知（セクション7.6）は、クライアントサービスに送信されます。
Note that as in (Section 6.21), if there is no transmission queue-set bound for the sender (possibly because the local LTP engine is running on a receive-only device), or if the receiver knows that the sender of this green-part data is functioning in a "beacon" (transmit-only) fashion, a CR segment need not be sent.
（ローカルLTPエンジンは受信専用デバイス上で実行されている可能性のために）送信者のためにバインドされた送信キューセットが存在しない場合、または受信機が知っている場合、などに（セクション6.21）なお、この緑色の送り主パートデータが「ビーコン」（送信のみ）様式で機能して、CRセグメントが送信される必要はありません。
There may be other implementation-specific limits that may cause an LTP implementation to initiate session-cancellation procedures. One such limit is the maximum number of retransmission-cycles seen. A retransmission cycle at the LTP Sender comprises the two related events: the transmission of all outstanding CP segments from the sender, and the reception of all RS segments issued from the receiver in response to those CP segments. A similar definition would apply at the LTP Receiver but relate to the reception of the CP segments and transmission of all RS segments in response. Note that the retransmitted CP and RS segments remain part of their original retransmission-cycle. Also, a single CP segment may cause multiple RS segments to be generated if a reception report would not fit in a single data link-MTU-sized RS segment; all RS segments that are part of a reception report belong to the same retransmission cycle to which the CP segment belongs. In the presence of severe channel error conditions, many retransmission cycles may elapse before red-part transmission is deemed successful; an implementation may therefore impose a retransmission-cycle limit to shield itself from a resource-crunch situation. If an LTP sender notices the retransmission-cycle limit being exceeded, it SHOULD initiate the Cancel Session procedure (Section 6.19), queuing a CS segment with reason-code RXMTCYCEXC and sending a transmission-session cancellation notice (Section 7.5) to the client service.
LTPの実装がセッションキャンセルの手続きを開始する可能性があり、他の実装固有の制限があるかもしれません。一つのそのような制限は見再送サイクルの最大数です。送信者からのすべての未処理のCPセグメントの送信、及びそれらのCPセグメントに応答して、受信機から発行されたすべてのRSセグメントの受信：LTPセンダにおける再送周期は、二つの関連イベントを含みます。同様の定義は、LTP受信機で適用するが、応答のすべてのRSセグメントのCPセグメントおよび送信の受信に関連するであろう。再送CP及びRSセグメントは元の再送周期の一部のままであることに注意してください。また、単一のCPセグメントは、受信レポートは、単一のデータ・リンクMTUサイズのRSセグメントに収まらない場合、複数のRSセグメントを発生させてもよいです。受信レポートの一部であるすべてのRSセグメントがCPセグメントが属する同一の再送周期に属します。赤い部分の送信が成功したとみなされる前に、厳しいチャネルエラー条件の存在下で、多くの再送周期が経過してもよいです。実装は、したがって、リソースクランチ状態から自身を保護する再送サイクルの制限を課すことができます。 LTPの送信者が超過される再送周期限界に気付いた場合は、クライアントサービスに（セクション7.5）理由コードRXMTCYCEXCとCSセグメントをキューイングし、送信セッションのキャンセル通知を送信し、セッション手順（セクション6.19）をキャンセル開始すべき。
In all cases, the representation of notice parameters is a local implementation matter.
すべての場合において、通知パラメータの表現はローカルの導入問題です。
The Session Start notice returns the session ID identifying a newly created session.
セッション開始の通知は、新しく作成されたセッションを識別するセッションIDを返します。
At the sender, the session start notice informs the client service of the initiation of the transmission session. On receiving this notice the client service may, for example, release resources of its own that are allocated to the block being transmitted, or remember the session ID so that the session can be canceled in the future if necessary. At the receiver, this notice indicates the beginning of a new reception session, and is delivered upon arrival of the first data segment carrying a new session ID.
送信側では、セッション開始通知が送信セッションの開始のクライアントサービスを通知します。この通知を受けたクライアントサービスは、例えば、ブロックに割り当てられ、独自の解放リソースは、送信、または必要に応じて、セッションが将来的にキャンセルできるように、セッションIDを覚えているされていることがあります。受信機において、この通知は、新たな受信セッションの開始を示しており、新たなセッションIDを搬送する第1のデータセグメントの到着時に送達されます。
The following parameters are provided by the LTP engine when a green-part segment arrival notice is delivered:
緑色の部分セグメントの到着通知が配信される場合は、次のパラメータがLTPエンジンが提供されます。
Session ID of the transmission session.
送信セッションのセッションID。
Array of client service data bytes contained in the data segment.
データセグメントに含まれるクライアント・サービス・データ・バイトのアレイ。
Offset of the data segment's content from the start of the block.
ブロックの先頭からのデータセグメントのコンテンツのオフセット。
Length of the data segment's content.
データセグメントのコンテンツの長さ。
Indication as to whether or not the last byte of this data segment's content is also the end of the block.
このデータセグメントのコンテンツの最後のバイトは、ブロックの終わりであるか否かの指示。
Source LTP engine ID.
ソースLTPエンジンID。
The following parameters are provided by the LTP engine when a red-part reception notice is delivered:
赤い部分の受信通知が配信される場合は、次のパラメータがLTPエンジンが提供されます。
Session ID of the transmission session.
送信セッションのセッションID。
Array of client service data bytes that constitute the red-part of the block.
ブロックの赤の部分を構成するクライアント・サービス・データ・バイトのアレイ。
Length of the red-part of the block.
ブロックの赤色部分の長さ。
Indication as to whether or not the last byte of the red-part is also the end of the block.
赤色の部分の最後のバイトが、ブロックの終了であるか否かの指示。
Source LTP engine ID.
ソースLTPエンジンID。
The sole parameter provided by the LTP engine when a transmission-session completion notice is delivered is the session ID of the transmission session.
伝送セッション完了通知が配信されたLTPエンジンによって提供される唯一のパラメータは、送信セッションのセッションIDです。
A transmission-session completion notice informs the client service that all bytes of the indicated data block have been transmitted and that the receiver has received the red-part of the block.
伝送セッション完了通知は、示されたデータブロックのすべてのバイトが送信され、受信機はブロックの赤の部分を受信したことをクライアントサービスに通知します。
The parameters provided by the LTP engine when a transmission-session cancellation notice is delivered are:
送信セッションの解除通知が配信されるときLTPエンジンによって提供されるパラメータは次のとおりです。
Session ID of the transmission session.
送信セッションのセッションID。
The reason-code sent or received in the Cx segment that initiated the cancellation sequence.
理由コードは、キャンセルシーケンスを開始しCxのセグメント内で送信または受信されました。
A transmission-session cancellation notice informs the client service that the indicated session was terminated, either by the receiver or else due to an error or a resource quench condition in the local LTP engine. There is no assurance that the destination client service instance received any portion of the data block.
送信セッションのキャンセル通知を受信するか、そうでなければエラーにより又は局所LTPエンジンにおけるリソース急冷条件のいずれか、示され、セッションが終了した顧客サービスを通知します。宛先クライアントのサービスインスタンスは、データブロックのいずれかの部分を受け取ったという保証はありません。
The parameters provided by the LTP engine when a reception cancellation notice is delivered are:
受信解除通知が配信されるときLTPエンジンによって提供されるパラメータは次のとおりです。
Session ID of the transmission session.
送信セッションのセッションID。
The reason-code explaining the cancellation.
キャンセルを説明する理由コード。
A reception-session cancellation notice informs the client service that the indicated session was terminated, either by the sender or else due to an error or a resource quench condition in the local LTP engine. No subsequent delivery notices will be issued for this session.
受信セッションキャンセル通知は送信者によってまたは他のエラーや地元のLTPエンジンにおけるリソースクエンチ状態のいずれかに、示されたセッションが終了したクライアントサービスを通知します。後続配信通知は、このセッションのために発行されません。
The session ID of the transmission session is included with the initial-transmission completion notice.
送信セッションのセッションIDが初期送信完了通知に含まれています。
This notice informs the client service that all segments of a block (both red-part and green-part) have been transmitted. This notice only indicates that original transmission is complete; retransmission of any lost red-part data segments may still be necessary.
この通知は、ブロック（赤色部分と緑色部分の両方）のすべてのセグメントが送信された顧客サービスを通知します。この通知は、元の送信が完了したことを示しています。失われた赤色部分データセグメントの再送が依然として必要であるかもしれません。
The following mnemonics have been used in the sender and LTP receiver state transition diagrams that follow:
次のニーモニックは、以下送信側とLTP受信状態遷移図で使用されてきました。
TE Timer Expiry RDS Regular Red Data Segment (NOT {CP|EORP|EOB}) GDS Regular Green Data Segment (NOT EOB) RL EXC Retransmission Limit Exceeded RP Red-Part GP Green-Part FG Fully-Green
TEタイマー満了RDS通常のレッドデータセグメント（NOT {CP | EORP | EOB}）は通常のグリーンデータセグメント（NOT EOB）をGDS RL EXC再送信リミットはRPレッド・パートGPグリーン・パートFG完全グリーンを超過
Note that blocks represented in rectangles, as in
のように、ブロックは長方形で表されていることに注意してください
+---------+
| FG_XMIT |
+---------+
specify actual states in the state-transition diagrams, while blocks represented with jagged edges, as in
ブロックのように、ギザギザのエッジで表現しながら、状態遷移図に実際の状態を指定します
/\/\/\/\ | Cncld | \/\/\/\/
/ \ / \ / \ / \ | Cncld | \ / \ / \ / \ /
are either pointers to a state or place-holders for sequences of state transitions.
状態遷移のシーケンスのための状態またはプレースホルダへのポインタのいずれかです。
8.1. Sender LTP Sender State Transition Diagram
8.1. LTPは、状態遷移図を送信する送信
/\/\/\/\
| Cncld |
\/\/\/\/
+--------+ | +------+
Rcv CR; | V V V | Rcv RS;
Snd CAR | +-------------+ | Snd RA
+-------+ CLOSED +----+
+---------------------------->+------+------+
| | Blk. Trans. Req
| Zero RP +
| Xmit ________________________/ \ Non-Zero RP
| GDS; / \
| +---+ | +------------------+ | +------+
| | V V | /\/\ Rcv RS V V V |
| | +---------+ +<-| RX |<---+ +---------+ |
| +<-+ FG_XMIT | | \/\/ +---+ +--->+ Xmit RDS;
| +----+----+ | | RP_XMIT | |
| | | /\/\ +---+ +--->+ Xmit {RDS, CP};
+<--------+ +<-| CP |<---+ +-----+---+ Start CP Tmr
| Xmit \/\/ CP TE | \
| {GDS, EOB}; | |
| Xmit {RDS, CP, EORP}; | +-------+
| Start CP Tmr | |
| | |
| +------------------+ | +---+ | Xmit {RDS,
| | /\/\ Rcv RS V V V | | CP, EORP,
| +<-| RX |<---+ +---------+ | | EOB};
| | \/\/ +---+ | | | Start
| | | GP_XMIT +->+ | CP Tmr
| | /\/\ +---+ | Xmit |
| +<-| CP |<---+ +-----+---+ GDS; |
| \/\/ CP TE | |
| | |
| Xmit {GDS, EOB}; | +---------+
| | |
| +------------------+ | |
| | /\/\ Rcv RS V V V
| +<-| RX |<---+ +-------------+
| | \/\/ +---+ |
| | | WAIT_RP_ACK |
| | /\/\ +---+ |
| +<-| CP |<---+ +-----+-------+
| \/\/ CP TE | RP acknowledged fully;
| V
+----------------------------------------+
LTP Sender State Transition Diagram (contd.)
LTPの送信者状態遷移図（続き）。
/\/\ /\/\
|CP| |CX |
\/\/ \/\/
| | | Snd CS,
| | RL EXC; | Start CS Tmr;
| | |
| | /\/\ | +---+
| +------>| CX | V V |
| \/\/ +---------+ | CS TE,
| | CS_SENT | | RL NOT EXC;
V RL NOT EXC; +-+--+--+-+ | Rxmt CS,
Rxmt CP, | | | | Restart
Start CP Tmr; CS TE, | | +---+ CS Tmr
RL EXC; | |
| | Rcv CAS;
V V
/\/\/\/\
| Cncld |
\/\/\/\/
/\/\
| RX |
\/\/
| Cncl CP Tmr (if any)
V Snd RA
+---------+ +----+
| CHK_RPT | | |
+-+--+----+ RP in scope V |
| | \ NOT rcvd. fully +---------+ | Rxmt
Redundant | | RP +--------------------->| RP_RXMT | | missing
RS rcvd; | | in scope +----+--+-+ | RDS;
| | rcvd. fully | | |
V V Rxmt last | +----+
missing RDS |
(marked CP) |
Start CP Tmr; |
V
Asynchronous cancel request may be received from the local client service while the LTP sender is in any of the states shown. If it was not already in the sequence of state transitions beginning at the CX marker, the internal procedure Cancel Session (Section 6.19) is followed, and the LTP sender moves from its current state into the sequence beginning at the CX marker initiating session cancellation with reason-code USR_CNCLD. From the CX marker, the CS segment with appropriate reason-code (USR_CNCLD or RLEXC depending on how the CX sequence was entered) is queued for transmission to the LTP receiver and the sender enters the Cancel-from-Sender Sent (CS_SENT) state. The internal procedure Start Cancel Timer (Section 6.15) is started upon receiving a link state cue indicating the beginning of transmission of the CS segment. Upon receiving the acknowledging CAS segment from the receiver, the LTP sender moves to the CLOSED state (via the 'Cncld' pointer). If the CS timer expires, the internal procedure Retransmit Cancellation Segment (Section 6.16) is followed:
非同期は、LTPの送信者が示した状態のいずれかである一方、要求がローカルクライアントサービスから受信することができる取り消します。それはCXマーカーで開始する状態遷移のシーケンスではすでになかった場合は、内部の手続きは、セッション（セクション6.19）をキャンセルし、その後、シーケンスへの現在の状態からLTPの送信者が移動すると、セッションのキャンセルを開始CXマーカーで始まっています理由コードUSR_CNCLD。 CXマーカーから、適切な理由コード（CXシーケンスが入力された方法に応じてUSR_CNCLD又はRLEXC）とCSセグメントはLTP受信機への送信のためにキューに入れられ、送信者が取り消しから、送信者に送信され（CS_SENT）に入射している状態。スタートタイマーをキャンセル内部手順（セクション6.15）はCSセグメントの送信の開始を指示するリンク状態キューを受信すると開始されます。受信機から肯定応答CASセグメントを受信すると、（「Cncld」ポインタを介して）CLOSED状態にLTP送付者が移動します。 CSタイマーが満了した場合、内部手続きの再送信キャンセルセグメント（セクション6.16）が続きます。
- If the network management set retransmission limit is exceeded, the session is simply closed and the LTP sender follows the Cncld marker to the CLOSED state. If the retransmission limit is not exceeded however, the CS segment is queued for a retransmission and the LTP sender stays in the CS_SENT state. The CS timer is started upon receiving a link state cue indicating the beginning of actual transmission according to the internal procedure Start Cancel Timer (Section 6.15).
- ネットワーク管理設定再送制限を超えた場合、セッションは単純に閉じられ、LTPの送信者はCLOSED状態にCncldマーカーに従います。再送制限がしかし超えていない場合、CSセグメントは、再送とCS_SENT状態でのLTPの送信者の滞在のためにキューに入れられています。 CSタイマーがスタートタイマーをキャンセル内部手順（セクション6.15）によると、実際の送信の始まりを示すリンク状態の手がかりを受けて開始されました。
Asynchronous cancel request may also be received from the receiver LTP in the form of a CR segment when the LTP sender is in any of the states. Upon receiving such a CR segment, the internal procedure Acknowledge Cancellation (Section 6.17) is invoked: The LTP sender sends a CAR segment in response and returns to the CLOSED state.
非同期LTPの送信者が状態のいずれかである場合、要求はまた、CRセグメントの形で受信LTPから受信することができる取り消します。そのようなCRセグメントを受信すると、内部手続きはキャンセル（セクション6.17）が呼び出された肯定応答：LTP送付者はCLOSED状態に応じ戻るカーセグメントを送信します。
The LTP sender stays in the CLOSED state until receiving a Block Transmission Request (Blk. Trans. Req) from the client service instance. Upon receiving the request, it moves to either the Fully Green Transmission State (FG_XMIT) if no portion of the block was requested to be transmitted as red or to the Red-Part Transmission State (RP_XMIT) state if a non-zero block-prefix was requested to be transmitted red.
LTPの送信者は、クライアントのサービスインスタンスからブロック伝送要求（BLK。トランス。Req）を受信するまで、CLOSED状態にとどまります。ブロックのどの部分が非ゼロブロックプレフィックス場合は赤色として、または赤パート伝送状態（RP_XMIT）状態へ送信するように要求されなかった場合は要求を受信すると、それは、完全に緑色透過状態（FG_XMIT）に移動します赤送信されるように要求されました。
In the FG_XMIT state, the block is segmented as multiple green LTP data segments respecting the link MTU size and the segments are queued for transmission to the remote engine. The last such segment is marked as EOB, and the LTP sender returns to the CLOSED state after queuing it for transmission.
FG_XMIT状態では、ブロックは、リンクMTUサイズを尊重複数緑色LTPデータセグメントとしてセグメント化されるセグメントは、リモートエンジンへの送信のためにキューイングされます。最後に、このようなセグメントがEOBとしてマーク、及びLTPの送信者が送信のためにキューイングした後に閉状態に戻ります。
Similarly, from the RP_XMIT state, multiple red data segments are queued for transmission, respecting the link MTU size. The sender LTP may optionally mark some of the red data segments as asynchronous checkpoints; the internal procedure Start Checkpoint Timer (Section 6.2) is followed upon receiving a link state cue indicating the transmission of the asynchronous checkpoints. If the block transmission request comprises a non-zero green part, the LTP sender marks the last red data segment as CP and EORP, and after queuing it for transmission, moves to the Green Part Transmission (GP_XMIT) state. If the block transmission request was fully red however, the last red data segment is marked as CP, EORP, and EOB and the sender LTP moves directly to the Wait-for-Red-Part-Acknowledgment (WAIT_RP_ACK) state. In both of the above state-transitions, the internal procedure Start Checkpoint Timer (Section 6.2) is followed upon receiving a link state cue indicating the beginning of transmission of the queued CP segments. In the GP_XMIT state, the green-part of the block is segmented as green data segments and queued for transmission to the LTP receiver; the last green segment of the block is additionally marked as EOB, and after queueing it for transmission the LTP sender moves to the WAIT_RP_ACK state.
同様に、RP_XMIT状態から、複数の赤データセグメントがリンクMTUサイズを尊重し、送信のためにキューイングされます。センダLTPは、必要に応じて非同期チェックポイントとしての赤色データセグメントの一部をマークすることができます。内部手順スタートチェックポイントタイマ（セクション6.2）は、非同期チェックポイントの伝送を示すリンク状態キューを受信すると続いています。ブロックの送信要求が非ゼロの緑色部分を含む場合、LTP送付者はCPとEORPとして最後の赤のデータセグメントをマークし、送信のためにキューイングした後、グリーンパートトランスミッション（GP_XMIT）状態に移行します。ブロックの送信要求がしかし完全に赤色であった場合は、最後に赤色データセグメントはCP、EORP、およびEOBおよびLTPが待ち赤パート応答（WAIT_RP_ACK）状態に直接移動送信者としてマークされています。上記状態遷移の両方において、内部手順スタートチェックポイントタイマ（セクション6.2）がキューイングさCPセグメントの送信の開始を指示するリンク状態キューを受信すると続いています。 GP_XMIT状態では、ブロックの緑色部分は緑色データセグメントとしてセグメント化され、LTP受信機への送信のためにキューに入れられました。ブロックの最後の緑色セグメントは、さらに、EOBとしてマークされ、送信のためWAIT_RP_ACK状態にLTP送付者が移動し、それをキューイングした後。
While the LTP sender is at any of the RP_XMIT, GP_XMIT, or WAIT_RP_ACK states, it might be interrupted by the occurrence of the following events:
LTPの送信者がRP_XMIT、GP_XMIT、またはWAIT_RP_ACKの状態のいずれかであるが、それは次のイベントの発生によって中断される可能性があります。
1. An RS might be received from the LTP receiver (either in response to a previously transmitted CP segment or sent asynchronously for accelerated retransmission). The LTP sender then moves to perform the sequence of state transitions beginning at the RX marker (second part of the diagram), and retransmits data if necessary, illustrating the internal procedure Retransmit Data (Section 6.13):
1】RSは、（以前に送信されたCPセグメントに応答して又は加速再送を非同期送信のいずれか）LTP受信機から受信されるかもしれません。 LTP送付者は、その後、RXマーカー（図の第二の部分）から始まる状態遷移のシーケンスを実行するために移動し、必要に応じてデータを再送信する、内部手順再送信データ（セクション6.13）を示します。
First, if the RS segment had a non-zero CP serial number, the corresponding CP timer is canceled. Then an RA segment acknowledging the received RS segment is queued for transmission to the LTP receiver and the LTP sender moves to the Check Report state (CHK_RPT). If the RS segment was redundantly transmitted by the LTP receiver (possibly because either the last transmitted RA segment got lost or the RS segment timer expired prematurely at the receiver), the LTP sender does nothing more and returns back to the interrupted state. Similarly, if all red data within the scope of the RS segment is reported as received, there is no work to be done and the LTP sender returns to the interrupted state. However, if the RS segment indicated incomplete reception of data within its scope, the LTP sender moves to the Red-Part Retransmit state (RP_RXMT) where missing red data segments within scope are queued for transmission. The last such segment is marked as a CP, and the LTP sender returns to the interrupted state. The internal procedure (Section 6.2) is followed upon receiving a link state cue indicating the beginning of transmission of the CP segment.
RSセグメントが非ゼロCPのシリアル番号を持っていた場合、最初に、対応するCPタイマーは解除されます。受信したRSセグメントを認めるRAセグメントはLTP受信機と確認レポート状態にLTP送付者が移動（CHK_RPT）への送信のためにキューイングされます。 RSセグメントが重複LTP受信機によって送信された場合には（おそらく最後に送信されたRAセグメントのいずれかが失われてしまったためか、RSセグメントタイマーが受信機に途中で期限切れ）、LTPの送信者は、より多くの何もしない、バック、中断状態に戻ります。受信したRSセグメントの範囲内でのすべての赤のデータが報告されている場合、同様に、中断状態に行うべき作業とLTPの送信者を返さないがありません。しかし、RSセグメントは、その範囲内のデータの不完全な受信を示す場合、範囲内の欠落赤色データセグメントを送信するためにキューイングされる赤パート再送信状態（RP_RXMT）にLTP送付者が移動します。最後に、このようなセグメントがCPとしてマークされ、そしてLTP送付者は中断状態に戻ります。内部手順（セクション6.2）CPセグメントの送信の開始を指示するリンク状態キューを受信すると続いています。
2. A previously set CP timer might expire. Now the LTP sender follows the states beginning at the CP marker (second part of the diagram), and follows the internal procedure Retransmit Checkpoint (Section 6.7):
2. A以前に設定CPタイマーが期限切れになるかもしれません。今LTPの送信者は、CPマーカー（図の第二部）から始まる状態に追従し、内部手続き再送信のチェックポイント（6.7節）を、次のとおりです。
If the CP Retransmission Limit set by network management for the session has been exceeded, the LTP sender proceeds towards canceling the session (with reason-code RLEXC) as indicated by the sequence of state transitions following the CX marker. Otherwise (if the Retransmission Limit is not exceeded yet), the CP segment is queued for retransmission and the LTP sender returns to the interrupted state. The internal procedure Start Checkpoint Timer (Section 6.2) is started again upon receiving a link state cue indicating the beginning of transmission of the segment.
セッションのためのネットワーク管理によって設定されたCPの再送信限度を超えた場合には、（理由コードRLEXCで）セッションをキャンセル向かっLTP送付者の進行には、CXマーカー次の状態遷移のシーケンスによって示されます。 （再送信制限をまだ超えていない場合）、そうでなければ、CPセグメントは遮断状態に再送とLTP送付者戻るためにキューに入れられています。内部手順スタートチェックポイントタイマ（セクション6.2）セグメントの送信の開始を指示するリンク状態キューを受信すると、再度開始されます。
The LTP sender stays at the WAIT_RP_ACK state after reaching it until the red-part data is fully acknowledged as received by the receiver LTP, and then returns to the CLOSED state following the internal procedure Close Session (Section 6.20).
LTPの送信者は、受信LTPによって受信される赤色部分のデータが完全に確認されるまで、それに到達した後WAIT_RP_ACK状態に留まり、その後、内部手続き閉じるセッション（セクション6.20）以下CLOSED状態に戻ります。
Note that while at the CLOSED state, the LTP sender might receive an RS segment (if the last transmitted RA segment before session close got lost or if the LTP receiver retransmitted the RS segment prematurely), in which case it retransmits an acknowledging RA segment and stays in the CLOSED state. If the session was canceled by the receiver by issuing a CR segment, the receiver may retransmit the CR segment (either prematurely or because the acknowledging CAR segment got lost). In this case, the LTP sender retransmits the acknowledging CAR segment and stays in the CLOSED state.
（LTP受信機が早まっRSセグメントを再送した場合、セッションクローズ前の最後の送信RAセグメントが紛失またはしまった場合）CLOSED状態で、LTPの送信者はRSセグメントを受信することが可能で、その場合には、それが認めRAセグメントを再送することに注意してくださいCLOSED状態のままです。セッションがCRセグメントを発行することにより、受信機によってキャンセルされた場合、受信機は、（いずれかの早期又は認めるCARセグメントが失われてしまったため）CRセグメントを再送信することができます。この場合、LTP送付者は認めるCARセグメントを再送し、CLOSED状態に留まります。
8.2. Receiver LTP Receiver State Transition Diagram
8.2. レシーバLTP受信機状態遷移図
/\/\/\/\
+----+ +----+ Cncld |
Rcv CS; | V V \/\/\/\/
Snd CAS | +-------------+
+--+ CLOSED +<--------------------------+
+------+------+ |
+----+ | Rcv first DS |
Rcv RA; | V V |
Cncl RS Tmr | +--------+ |
+---+ DS_REC | |
+----------------------------->+-+--+-+-+<----------------------+---+ |
| Svc. does not exist | | | RS TE | | |
| /\/\ or Rcv miscolored seg. | | | /\/\ | | |
| | CX |<-----------------------+ | +------------->| RX |---->+ | |
| \/\/ | \/\/ | |
| Rcv RDS; | Rcv GDS; | |
| +-----------+------------+ | |
| V V | |
| /\/\ RS TE +--------------+ +--------+ | |
+<-| RX |<------+ RCV_RP | | RCV_GP | | |
| \/\/ +-+----+--+--+-+ +--+-+-+-+ | |
| | | | | | | | | |
| Rcvd RDS; | | | | Rcvd {RDS, CP, | | | RS TE /\/\ | |
| | | | | EORP, EOB}; | | +------>| RX |->+ |
+<----------------+ | | | Snd RS, | | \/\/ | |
| | | | Start RS Tmr | | Rcvd GDS; | |
| Rcvd {RDS, CP}; | | | | +---------------->+ |
| Snd RS, Start RS Tmr | | +-------+ +-----+ |
+<---------------------+ | | | Rcvd {GDS, EOB}; |
| | | | |
| | +-----+ | | +------+ |
| Rcvd {RDS, CP, EORP}; | | V V V V | |
| Snd RS, Start RS Tmr | | +----------------+ | Rcv RDS; |
| | | | +-->+ |
| | | | WAIT_RP_REC | | Rcv {RDS, CP}; |
| | | | +-->+ Snd RS, Start |
+<------------------------+ | +---+--+-+-+-----+ | RS Tmr |
| RS TE | | | | Rcv RA; | |
| V | | | Cncl | |
| /\/\ | | | RS Tmr | |
+---| RX | | | +-------->+ |
\/\/ | | |
/\/\ | | |
| CX |<------------------------+ | RP rcvd. fully |
\/\/ Rcv miscolored seg. +--------------------------->+
Receiver State Transition Diagram (contd.)
レシーバの状態遷移図（続き）。
/\/\
| RX |
\/\/
| |
| | RL EXC; /\/\
RL NOT EXC; | +---------->| CX |
Rxmt RS, | \/\/
Start RS Tmr |
V
/\/\
| CX |
\/\/
| Snd CR,
| Start CR Tmr;
|
| +----+
V V |
+---------+ | CR TE,
| CR_SENT | | RL NOT EXC;
+-+--+--+-+ | Rxmt CR,
| | | | Restart
CR TE, | | +---+ CR Tmr
RL EXC; | |
| | Rcv CAR;
V V
/\/\/\/\
| Cncld |
\/\/\/\/
Asynchronous cancel requests are handled in a manner similar to the way they are handled in the LTP sender. If the cancel request was made from the local client service instance and the LTP receiver was not already in the CR_SENT state, a CR segment with reason-code USR_CNCLD SHOULD be sent to the LTP sender following the sequence of state transitions beginning at the CX marker as described above. If the asynchronous cancel request is received from the LTP sender, a CAS segment is sent and the LTP receiver moves to the CLOSED state (independent of the state the LTP receiver may be in).
非同期要求は、彼らがLTPの送信者に処理されるのと同様の方法で処理され、キャンセル。キャンセル要求がローカル・クライアント・サービス・インスタンスから作られ、LTP受信機がCR_SENT状態になっていないとした場合、理由コードUSR_CNCLDとCRセグメントはCXマーカーで始まる状態遷移のシーケンス次LTPの送信者に送信されるべきです上記のように。非同期キャンセル要求がLTPの送信者から受信した場合、CASセグメントが送信され、閉状態にLTP受信機が移動（状態とは無関係にLTP受信機であってもよいです）。
The LTP receiver begins at the CLOSED state and enters the Data Segment Reception (DS_REC) state upon receiving the first data segment. If the client service ID referenced in the data segment was non-existent, a Cx segment with reason-code UNREACH SHOULD be sent to the LTP sender via the Cancellation sequence beginning with the CX marker (second part of the diagram). If the received segment was found to be miscolored, the internal procedure Handle Miscolored Segment (Section 6.21) is followed, and a CX segment with reason-code MISCOLORED SHOULD be sent to the LTP sender with the Cancellation sequence beginning with the CX marker.
LTP受信機は、CLOSED状態で始まり、第1のデータセグメントを受信するデータセグメント受信（DS_REC）状態に入ります。データセグメントで参照クライアントサービスIDは、非存在であった場合は、理由コードUNREACHとCxのセグメントは、CXマーカー（図の第二の部分）で始まるキャンセル配列を介してLTPの送信者に送信されるべきです。受信されたセグメントがmiscoloredことが見出された場合、内部手順はMiscoloredセグメントハンドル（セクション6.21）が続き、および理由コードMISCOLOREDとCXセグメントはCXマーカーで始まるキャンセル配列とLTPの送信者に送信されるべきです。
Otherwise, the LTP receiver enters the Receive Red-Part state (RCV_RP) or the Receive Green-Part state (RCV_GP) depending on whether the segment received was red or green, respectively.
そうでなければ、LTP受信機は、セグメントが受信されたかどうかに応じて受信赤パート状態（RCV_RP）または受信グリーンパート状態（RCV_GP）に入り、それぞれ、赤または緑でした。
In the RCV_RP state, a check is made of the nature of the received red DS. If the segment was a regular red data segment, the receiver LTP just returns to the DS_REC state. For red data segments marked also as CP and as CP & EORP, a responding RS segment is queued for transmission to the sender following either the internal procedure Retransmit RS (Section 6.8) or Send Reception Report (Section 6.11) depending on whether the CP segment was a retransmission (an RS segment corresponding to the checkpoint serial number in the CP segment was previously issued) or not, respectively. The LTP receiver then returns to the DS_REC state. If the block transmission was fully red and the segment was marked as CP, EORP, and EOB, the LTP receiver enters the Wait-for-Red-Part-Reception state (WAIT_RP_REC). In all cases, the internal procedure Start RS Timer (Section 6.3) is followed upon receiving link state cues indicating the beginning of transmission of the RS segments.
RCV_RP状態では、チェックが受けた赤DSの性質で作られています。セグメントは、通常の赤データ・セグメントである場合、受信機LTPだけDS_REC状態に戻ります。赤色データセグメントのためのCPとしてもマークされ、CP＆EORPとして、応答RSセグメントが送信者に送信するためにキューイングされる内部手順再送RS（セクション6.8）のいずれか以下かどうかCPセグメントに応じて受信報告（6.11）を送信再送はそれぞれ、（CPセグメント内のチェックポイントのシリアル番号に対応するRSセグメントは、以前に発行された）、またはされませんでした。 LTP受信機は、次にDS_REC状態に戻ります。ブロック送信が完全に赤色であり、セグメントがCP、EORP、およびEOBとしてマークされた場合、LTP受信機は、待ち赤パート受信状態（WAIT_RP_REC）に入ります。全ての場合において、内部手順スタートRSタイマ（セクション6.3）はRSセグメントの送信の開始を指示するリンク状態の合図を受けて続きます。
In the RCV_GP state, if the received green data segment was not marked EOB, the LTP receiver returns to the DS_REC state. Otherwise, it enters the WAIT_RP_REC state to receive the red-part of the block fully.
RCV_GP状態で、受信された緑色データセグメントがEOBとマークされなかった場合、DS_REC状態にLTP受信戻ります。そうでなければ、それは完全にブロックの赤の部分を受信するようにWAIT_RP_REC状態に入ります。
A previously set RS timer may expire and interrupt the LTP receiver while in the DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC state. If so, the internal procedure Retransmit RS (Section 6.8) is followed as illustrated in the states beginning at the RX marker (shown in the second part of the diagram) before returning to the interrupted state:
以前に設定RSタイマーが期限切れになるとLTP受信機を中断することがDS_REC、RCV_RP、RCV_GP、またはWAIT_RP_RECの状態の間。もしそうであれば、中断状態に戻る前に（図の第二の部分に示されている）RXマーカーで始まる状態に示すように、内部手順再送RS（6.8節）が続いています。
- A check is made here to see if the retransmission limit set by the network management has been exceeded in the number of RSs sent in the session. If so, a CR segment with reason-code RLEXC SHOULD be sent to the LTP sender and the sequence indicated by the CX marker is followed. Otherwise, the RS segment is queued for retransmission and the associated RS timer is started following the internal procedure Start RS Timer (Section 6.3) upon receiving a link state cue indicating the beginning of its transmission.
- チェックがネットワーク管理によって設定された再送制限がセッションで送信されたRSの数が超過しているかどうかを確認するためにここで行われています。その場合、理由コードRLEXCとCRセグメントはLTPの送信者に送信されるべきであり、CXマーカーによって示される配列が続きます。そうでなければ、RSセグメントが再送信のためにキューイングされると、関連するRSタイマがその送信の開始を指示するリンク状態キューを受信すると、内部手順スタートRSタイマ（6.3）以下が開始されます。
The LTP receiver may also receive RA segments from the sender in response to the RS segments sent while in the DS_REC state. If so, then the RS timer corresponding to the report serial number mentioned in the RA segment is canceled following the internal procedure Stop RS Timer (Section 6.14).
LTP受信機はまた、DS_REC状態にある間に送信されたRSセグメントに応答して送信者からRAセグメントを受信することができます。もしそうであれば、RAのセグメントに記載さレポートシリアル番号に対応するRSタイマは、内部手続きを停止RSタイマ（セクション6.14）以下キャンセルされます。
The LTP receiver stays in the WAIT_RP_REC state until the entire red-part of the block is received, and moves to the CLOSED state upon full red-part reception. In this state, a check is made upon reception of every red-part data segment to see if it is at a block offset higher than any green-part data segment received. If so, the internal procedure Handle Miscolored Segment (Section 6.21) is invoked and the sequence of state transitions beginning with the CX marker is followed; a CX segment with reason-code MISCOLORED SHOULD be sent to the LTP sender with the Cancellation sequence beginning with the CX marker.
LTP受信機は、ブロックの全体の赤の部分が受信されるまでWAIT_RP_REC状態に留まり、フル赤パート受信時に閉状態に移行します。この状態では、チェックは、任意の緑色部分データセグメントが受信されたよりも高いオフセットがブロックであるかどうかを確認するために、すべての赤の部分データセグメントの受信時に行われます。もしそうであれば、内部手順はMiscoloredセグメント（セクション6.21）が呼び出され、続いてCXマーカーで始まる状態遷移のシーケンスを処理します。理由コードMISCOLOREDとCXセグメントはCXマーカーで始まるキャンセル配列とLTPの送信者に送信する必要があります。
Note that if there were no red data segments received in the session yet, including the case where the session was indeed fully green or the pathological case where the entire red-part of the block gets lost but at least the green data segment marked EOB is received (the LTP receiver has no indication of whether the session had a red-part transmission), the LTP receiver assumes the "RP rcvd. fully" condition to be true and moves to the CLOSED state from the WAIT_RP_REC state.
セッションが実際に完全に緑色またはブロックの全体の赤色部分は失われるが、少なくとも緑色データセグメントがEOBであるとマーク病的な場合であった場合を含め、まだセッションで受信した赤いデータセグメントが存在しない場合、ことに注意してください（LTP受信機がセッションは、赤色の部分の送信があったかどうかの兆候を持っていない）、LTP受信機が真であることが条件「十分。RPのRCVD」前提とWAIT_RP_REC状態からCLOSED状態に移行しました。
In the WAIT_RP_REC state, the LTP receiver may receive the retransmitted red data segments. Upon receiving red data segments marked CP, it queues the responding RS segment for transmission based on either internal procedure Retransmit RS (Section 6.8) or Send Reception Report (Section 6.11) depending on whether the CP was found to be a retransmission or not, respectively. The internal procedure Start RS Timer is invoked upon receiving a link state cue indicating the beginning of transmission of the RS segment. If an RA segment is received, the RS timer corresponding to the report segment mentioned is canceled and the LTP receiver stays in the state until the entire red-part is received.
WAIT_RP_REC状態では、LTP受信機は、再送赤色データセグメントを受信することができます。赤色データセグメントをマークされたCPを受信すると、それぞれ、内部手順再送RS（セクション6.8）のいずれかに基づいて、送信のための応答RSセグメントをキューイングまたはCPが再送であることが見出されたかどうかに応じて受信報告（6.11）を送信するか否か。内部手順スタートRSタイマは、RSセグメントの送信の開始を指示するリンク状態キューを受信すると呼び出されます。 RAセグメントが受信された場合、上述レポートセグメントに対応するRSタイマはキャンセルされ、全体の赤の部分が受信されるまでLTP受信機状態に留まります。
In the sequence of state transitions beginning at the CX marker, the CR segment with the given reason-code (depending on how the sequence is entered) is queued for transmission, and the CR timer is started upon reception of the link state cue indicating actual transmission following the internal procedure Start Cancel Timer (Section 6.15). If the CAR segment is received from the LTP sender, the LTP receiver returns to the CLOSED state (via the Cncld marker) following the internal procedure Stop Cancel Timer (Section 6.18). If the CR timer expires asynchronously, the internal procedure Retransmit Cancellation Segment (Section 6.16) is followed:
CXマーカーで始まる状態遷移のシーケンスでは、（シーケンスが入力された方法に応じて）所与の理由コードを有するCRセグメントが送信のためにキューイングされ、そしてCRタイマが実際示すリンク状態キューの受信時に開始されます内部手続開始後の送信タイマ（6.15節）をキャンセルします。 CARセグメントはLTPの送信者から受信した場合、内部手続きを停止下記（Cncldマーカーを介して）CLOSED状態にLTP受信復帰タイマ（セクション6.18）をキャンセル。 CRタイマーが非同期的に期限切れになった場合、内部手続きの再送信キャンセルセグメント（セクション6.16）が続きます。
- A check is made to see if the retransmission limit set by the network management for the number of CR segments per session has been exceeded. If so, the LTP receiver returns to the CLOSED state following the Cncld marker. Otherwise, a CR segment is scheduled for retransmission with the CR timer being started following the internal procedure Start Cancel Timer (Section 6.15) upon reception of a link state cue indicating actual transmission.
- チェックは、セッションごとCRセグメントの数のネットワーク管理によって設定された再送の上限を超えたかどうかを確認するために行われます。もしそうなら、LTP受信機はCncldマーカー以下CLOSED状態に戻ります。そうでない場合、CRセグメントは、CRタイマが内部手続開始後に開始されると、再送信のためにスケジュールされている実際の送信を指示するリンク状態キューの受信時にタイマ（セクション6.15）をキャンセル。
The LTP receiver might also receive a retransmitted CS segment at the CLOSED state (either if the CAS segment previously transmitted was lost or if the CS timer expired prematurely at the LTP sender). In such a case, the CAS is scheduled for retransmission.
LTP受信機はまた、CLOSED状態で、再送CSセグメントを受信する場合があります（いずれかの以前に送信CASセグメントが失われたりしている場合CSタイマーは、LTPの送信者に時期尚早の有効期限が切れている場合）。このような場合、CASは再送信に予定されています。
Implementers SHOULD consider the likelihood of the following Denial of Service (DoS) attacks:
実装者は、以下のサービス拒否（DoS）攻撃の可能性を検討する必要があります。
- A fake Cx could be inserted, thus bringing down a session.
- 偽Cxとは、このようにセッションをダウンさせ、挿入することができます。
- Various acknowledgment segments (RA, RS, etc.) could be deleted, causing timers to expire, and having the potential to disable communication altogether if done with a knowledge of the communications schedule. This could be achieved either by mounting a DoS attack on a lower-layer service in order to prevent it from sending an acknowledgment segment, or by simply jamming the transmission (all of which are more likely for terrestrial applications of LTP).
- 様々な肯定応答セグメント（RA、RS、等）タイマーが満了させ、通信スケジュールの知識を用いて行った場合に完全に通信を無効にする可能性を有する、削除することができます。これは、肯定応答セグメントを送信するのを防止するために、または単に（LTPの地上用途にやすい全てが）送信を妨害することによって、下位層サービスにDoS攻撃を実装することによってのいずれかで達成することができます。
- An attacker might also corrupt some bits, which is tantamount to deleting that segment.
- 攻撃者は、そのセグメントを削除することに等しい破損一部のビットもあります。
- An attacker may flood an LTP engine with segments for the internal operations queue and prevent transmission of legitimate data segments.
- 攻撃者が内部操作キューのセグメントとLTPエンジンをフラッディングし、正当なデータセグメントの送信を防止することができます。
- An attacker could attempt to fill up the storage in an engine by sending many large messages to it. In terrestrial LTP applications, this may be much more serious since spotting the additional traffic may not be possible from any network management point.
- 攻撃者がそれに多くの大きなメッセージを送信することにより、エンジン内のストレージを埋めるためにしようとすることができます。追加のトラフィックをスポッティングすると、任意のネットワークの管理ポイントから可能ではないかもしれないので、地上LTPのアプリケーションでは、これははるかに深刻かもしれません。
If any of the above DoS attacks is likely, then one or more of the following anti-DoS mechanisms ought to be employed:
：上記のDoS攻撃のいずれかの可能性がある場合は、次の抗DoS攻撃メカニズムの1つ以上が採用されるべきです
- Session numbers SHOULD be partly random making it harder to insert valid segments.
- セッション番号は、それが難しく、有効なセグメントを挿入するようになって、部分的にランダムであるべきです。
- An engine that suspects that either it or its peer is under DoS attack could frequently checkpoint its data segments (if it were the sender) or send asynchronous RSs (if it were the receiver), thus eliciting an earlier response from its peer or timing out earlier due to the failure of an attacker to respond.
- このようにして、そのピアまたはタイミングより早い応答を誘発すること、またはそのピアのどちらかが頻繁に（それが送信者であった場合）は、そのデータセグメントのチェックポイントまたは（それが受信した場合）、非同期RSを送信することができるDoS攻撃下にあることを疑うエンジンアウト以前に伴う対応するため、攻撃者が失敗します。
- Serial numbers (checkpoint serial numbers, report serial numbers) MUST begin each session anew using random numbers rather than from 0.
- シリアル番号（チェックポイントのシリアル番号、シリアル番号をレポート）は乱数を用いて新たにではなく、0から各セッションを開始する必要があります。
- The authentication header [LTPEXT].
- 認証ヘッダ[LTPEXT]。
The following algorithm is given as an example of how an LTP implementation MAY handle replays.
次のアルゴリズムは、LTPの実装は、リプレイを処理することができる方法の例として与えられています。
1. On receipt of an LTP segment, check against a cache for replay. If this is a replay segment and if a pre-cooked response is available (stored from the last time this segment was processed), then send the pre-cooked response. If there is no pre-cooked response, then silently drop the inbound segment. This can all be done without attempting to decode the buffer.
LTPセグメントの受信1.は、リプレイのキャッシュに対してチェック。これは、再生セグメントであり、事前調理応答が利用可能である場合（このセグメントが処理された最後の時から記憶された）場合には、事前調理応答を送信します。何の調理応答がない場合は、静かにインバウンドセグメントをドロップします。これは、すべてのバッファを解読しようとせずに行うことができます。
2. If the inbound segment does not decode correctly, then silently drop the segment. If the segment decodes properly, then add its hash to the replay cache and return a handle to the entry.
2.インバウンドセグメントが正しくデコードしない場合は、静かにセグメントをドロップします。セグメントが正しく復号化した場合、リプレイ・キャッシュにそのハッシュを追加し、エントリへのハンドルを返します。
3. For those cases where a pre-cooked response should be stored, store the response using the handle received from the previous step. These cases include:
3.調理応答を格納しなければならないような場合は、前のステップから受け取ったハンドルを使用して応答を格納します。これらの例は次のとおりです。
(a) when the inbound packet is a CP segment, the RS segment sent in response gets stored as pre-cooked,
（a）は、着信パケットがCP区間である場合に事前調理のように、応答で送信されたRSセグメントが格納されます、
(b) when the Incoming packet is an RS segment, the RA segment is stored as pre-cooked, and
着信パケットがRSセグメントである場合（B）、RAセグメントは予め調理されたとして格納され、及び
(c) when the incoming packet is a Cx segment, the CAx segment sent in response gets stored pre-cooked.
着信パケットは、Cxのセグメントである場合（C）、応答して送信さCAXセグメントは予め調理保存されます。
4. Occasionally clean out the replay cache -- how frequently this happens is an implementation issue.
4.時々リプレイキャッシュを一掃 - これが起こる頻度実装の問題です。
The downside of this algorithm is that receiving a totally bogus segment still results in a replay cache search and attempted LTP decode operation. It is not clear that it is possible to do much better though, since all an attacker would have to do to get past the replay cache would be to tweak a single bit in the inbound segment each time, which is certainly cheaper than the hash+lookup+decode combination, though also certainly more expensive than simply sending the same octets many times.
このアルゴリズムの欠点は完全に偽のセグメントを受信すると、まだリプレイ・キャッシュ検索をもたらし、LTPのデコード動作をしようとしたことです。すべての攻撃者は、確かにハッシュ+よりも安くなる、リプレイキャッシュがインバウンドセグメント内の各時間を単一のビットを微調整することであろう乗り越えるために何しなければならないので、しかしはるかに優れて行うことが可能であることは明らかではありません検索+デコード組み合わせ、しかしまた確かに、より高価なだけで同じオクテットを何度も送信するよりも。
The benefit of doing this is that implementers no longer need to analyze many bugs/attacks based on replaying packets, which in combination with the use of LTP authentication should defeat many attempted DoS attacks.
これを行うことの利点は、実装者は、もはや多くを倒す必要がありLTP認証の使用との組み合わせでDoS攻撃を試みた再生パケットに基づいて、多くのバグ/攻撃を分析する必要がないということです。
SDNV
SDNV
Implementations SHOULD make sanity checks on SDNV length fields and SHOULD check that no SDNV field is too long when compared with the overall segment length.
実装はSDNV長フィールド上の健全性チェックを行う必要がありますし、全体的なセグメント長と比較して何SDNVフィールドが長すぎないことを確認する必要があります。
Implementations SHOULD check that SDNV values are within suitable ranges where possible.
実装はSDNV値は、可能な限り適切な範囲内にあることを確認する必要があります。
Byte ranges
バイト範囲
Various report and other segments contain offset and length fields. Implementations MUST ensure that these are consistent and sane.
様々なレポートおよび他のセグメントは、オフセットおよび長さフィールドを含みます。実装は、これらが一貫して正気であることを保証しなければなりません。
Randomness
ランダム性
Various fields in LTP (e.g., serial numbers) MUST be initialized using random values. Good sources of randomness that are not easily guessable SHOULD be used [ESC05]. The collision of random values is subject to the birthday paradox, which means that a collision is likely after roughly the square root of the space has been seen (e.g., 2^16 in the case of a 32-bit random value).
LTPにおける様々な分野（例えば、シリアル番号）は、ランダム値を用いて初期化されなければなりません。簡単に推測されないランダムの良いソースは、[ESC05]使用されるべきです。ランダムな値の衝突が空間の略平方根が見られた後、衝突の可能性があることを意味誕生日パラドックス、対象（例えば、2 ^ 16個の32ビットのランダム値の場合）。
Implementers MUST ensure that they use sufficiently long random values so that the birthday paradox doesn't cause a problem in their environment.
実装者は、誕生日のパラドックスは、その環境で問題を起こさないように、彼らは十分に長いランダムな値を使用していることを確認しなければなりません。
The UDP port number 1113 with the name "ltp-deepspace" has been reserved for LTP deployments. An LTP implementation may be implemented to operate over UDP datagrams using this port number for study and testing over the Internet.
名前「LTP-deepspace」とUDPポート番号1113は、LTPの展開のために予約されています。 LTPの実装は、インターネット上で研究とテストのためにこのポート番号を使用してUDPデータグラム上で動作するように実装することができます。
The IANA has created and now maintains a registry for known LTP Extension Tags (as indicated in Section 3.1). The registry has been populated using the initial values given in Section 3.1 above. IANA may assign LTP Extension Tag values from the range 0x02-0xAF (inclusive) using the Specification Required rule [GUIDE]. The specification concerned can be an RFC (whether Standards Track, Experimental, or Informational), or a specification from any other standards development organization recognized by IANA or with a liaison with the IESG, specifically including CCSDS (http://www.ccsds.org/). Any use of Reserved values (0xB0-0xBF inclusive) requires an update this specification.
IANAは、作成され、現在（3.1節に示したように）既知のLTP拡張タグのレジストリを維持しています。レジストリは、上記のセクション3.1で与えられた初期値を使用して取り込まれています。 IANAは、仕様が必要ルール[GUIDE]を使用して範囲0x02-0xAF（両端を含む）からLTP拡張タグ値を割り当てることができます。 //www.ccsds：関係する仕様はRFC（標準化過程、実験的、または情報かどうか）、またはIANAによってか、具体的CCSDS（HTTPなどのIESGとの連携、と認識し、他の規格開発組織からの指定することができます。 ORG /）。予約値（0xB0-0xBF含む）の使用は、アップデートにこの仕様が必要です。
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, Dovel Myers, and Jayram Deshpande 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マイヤーズ、およびオハイオ大学のJayramデシュパンデによるものです。 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契約の一環として、トリニティ・カレッジ・ダブリンで行われました。
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[ガイド] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[LTPMTV] Burleigh, S., Ramadas, M., and S. Farrell,"Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.
【LTPMTV]バーレイ、S.、Ramadas、M.、およびS.ファレル、 "リックライダー伝送プロトコル - 動機"、RFC 5325、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月。
[ASN1] Abstract Syntax Notation One (ASN.1). ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER). ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002.
[ASN1]抽象構文記法1（ASN.1）。 ASN.1符号化規則：基本符号化規則（BER）、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）の仕様。 ITU-T勧告。 X.690（2002）| ISO / IEC 8825から1：2002。
[BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[BP]スコット、K.およびS.バーリー、 "バンドルプロトコル仕様"、RFC 5050、2007年11月。
[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月。
[ESC05] D. Eastlake, J. Schiller and S. Crockerr, "Randomness Recommendations for Security", RFC 4086, June 2005.
[ESC05] D.イーストレイク、J.シラーとS. Crockerr、 "セキュリティのためのランダム性に関する推奨事項"、RFC 4086、2005年6月。
[SACK] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
[SACK] M.マシス、J. Mahdavi、S.フロイド、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
Authors' Addresses
著者のアドレス
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
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S: 301-490 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から490パサデナ、CA 91109から8099電話：+1（818）393から3353ファックス：+1（818）354から1075 Eメール：Scott.Burleigh @ jpl.nasa.gov
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
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（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に情報を記述してください。