[要約] RFC 5326は、Licklider Transmission Protocol（LTP）の仕様を定義しています。LTPは、高信頼性のデータ転送を提供するために設計されており、遠隔地間の通信に使用されます。このRFCの目的は、LTPの機能と動作を明確にし、ネットワークコミュニティにLTPの実装と使用を促進することです。
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
Licklider送信プロトコル - 仕様
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. It represents the consensus of the Delay Tolerant Networking (DTN) Research Group of the Internet Research Task Force (IRTF). 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は、インターネット標準のレベルの候補者ではありません。これは、インターネット研究タスクフォース（IRTF）の遅延耐性ネットワーキング（DTN）研究グループのコンセンサスを表しています。将来のIETFによる標準化が検討される場合がありますが、IETFは、このRFCのフィットネスに関する知識をあらゆる目的で否認します。特に、公開する決定はセキュリティ、混雑などのIETFレビューに基づいていないことに注意してください。展開されたプロトコルとの制御、または不適切な相互作用。詳細については、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）および/または接続性の頻繁な中断を特徴とするリンクにわたって再送信に基づいた信頼性を提供するように設計されたLicklider Transmission Protocol（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を説明する一連のドキュメントの一部です。このシリーズのその他のドキュメントには、Motivation Document [LTPMTV]およびProtocol Extensions Document [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は、Selective-cnowledmentの受信レポートを勧誘することにより、データ送信の自動リピートリクエスト（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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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]の下で動作している場合、2つを媒介する収束レイヤーアダプターは、実装特有の方法で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.
1つのLTPクライアントサービスインスタンスから別の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.
ブロックを送信する目的で、2つのピアエンジン間で行われたLTPプロトコルアクティビティのスレッド。セッションのデータフローは一方向です。データトラフィックは、送信ピアから受信ピアに流れ、データ承認のトラフィックは受信ピアから送信ピアに流れます。
(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エンジンに送信されるデータ構造です。各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.
スコープはブロックのサブセットを識別し、上限と下限の2つの数値で構成されています。
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の下限と5000の上限を掲載し、受信請求がオフセット1000-1999および3000-4999内のデータの受信を示した場合、ブロックオフセット内のデータは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の最後のオクテットであるかどうかを示すのに役立ちます。MSB 1のオクテットは、それがマルチオクテットSDNVの最初または中央のオクテットであることを示します。MSBが0のオクテットは、SDNVの最後のオクテットです。SDNVでエンコードされた値は、最初のオクテットから始まり、最後のオクテットで終了するSDNVの各オクテットの7つの最も有意なビットを連結することにより発見されます。
The following examples illustrate the encoding scheme for various hexadecimal values.
次の例は、さまざまな16進値のエンコーディングスキームを示しています。
0xABC : 1010 1011 1100 is encoded as
0XABC：1010 1011 1100がエンコードされています
{100 1010 1} {0 011 1100}
- -
= 10010101 00111100
= 10010111100
0x1234 : 0001 0010 0011 0100 = 1 0010 0011 0100 is encoded as
0x1234：0001 0010 0011 0100 = 1 0010 0011 0100がエンコードされています
{10 1 0010 0} {0 011 0100}
- -
= 10100100 00110100
= 10100100 00110100
0x4234 : 0100 0010 0011 0100 =100 0010 0011 0100 is encoded as
0x4234：0100 0010 0011 0100 = 100 0010 0011 0100がエンコードされています
{1000000 1} {1 00 0010 0} {0 011 0100}
- - -
= 10000001 10000100 00110100
= 100001 10000100 00110100
0x7F : 0111 1111 =111 1111 is encoded as
0x7f：0111 1111 = 111 1111は次のようにエンコードされています
{0 111 1111} -
{0 111 1111} -
= 01111111
= 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の倍数にするために、エンコードする値が最も重要なビット端（少なくとも重要なビット端ではない）でゼロがパッドで埋められていることを確認するように注意する必要があります。
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-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.
SDNVフィールドのサイズに理論的な制限はありませんが、SDNVスキームのオーバーヘッドは1：7、つまり、エンコードする実際のデータの7ビットごとに1ビットのオーバーヘッドであることに注意してください。したがって、8オクテットのSDNVで7オクテット値（先頭ゼロのない56ビット数量）がエンコードされます。10オクテットのSDNVでエンコードされます。一般に、先行ゼロのないNビット量は、天井（n/7）Octet SDNVにエンコードされます。明らかに、通常、RSAパブリックキーなどのより大きな値を運ぶフィールドの場合、SDNVオーバーヘッドは受け入れられない可能性があります。したがって、プロトコル拡張など、このドキュメントに関連する他の目的のためにSDNVスキームを採用する場合、典型的なデータフィールド値が8オクテットより大きくなると予想される場合は、データフィールドを{長さとして指定することをお勧めします。、value}タプル、長さパラメーターがSDNVとしてエンコードされ、その後にデータフィールドの値を収容する長さのオクテットが続きます。
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は、値が通常128〜255の範囲にある整数を表す貧弱な方法です。しかし、一般的に、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.
セッション管理セグメントは、送信者と受信機の両方によって生成される場合があり、2つの一般的なサブタイプのキャンセルとキャンセル - 継続格子です。キャンセルセグメントは、ピアでセッションキャンセル手順を開始し、セッションのキャンセルの理由を示すために単一のバイトの理由コードを運びます。キャンセル - 承認セグメントセグメントは、キャンセルセグメントの受容を認めるだけで、内容がありません。
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.
LTPセグメントヘッダーには、単一オクテット制御バイト、セッションID、および拡張フィールドの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は、送信者と受信機の間のすべての送信の中で、セグメントが1つのトークンであるセッションを一意に識別します。以下で構成されています。
Session originator (SDNV): the engine ID of the sender.
Session Originator（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、Flag 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.
CTRL（コントロール）フラグの値は、セグメントをデータセグメントとして識別し、1の値はコントロールセグメントとして識別します。0に設定されたExc（例外）フラグを備えたデータセグメントは、赤い部分セグメントです。excを1に設定したデータセグメントは、グリーンパートセグメントです。制御セグメントの場合、excフラグを1に設定すると、セグメントがセッションキャンセルアクティビティに関係していることが示されます。フラグ1とフラグ0の両方を備えたデータセグメント（レッドパートまたはグリーンパート）は、EOBを示します。フラグ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
if（ctrl flag = 0）セグメントはデータセグメントです（exc flag = 0）セグメントにレッドパートデータのみが含まれている場合、（フラグ1 = 1）セグメントがチェックポイントセグメントである場合、ブロックの赤い部分の最後のセグメントです。（フラグ0 = 1）セグメントはブロックの最後のセグメントです。）（flag 0 = 1）セグメントがブロックの最後のセグメントである場合、それ以外のセグメントはコントロールセグメントです（excフラグ= 0）セグメントがアクティビティを報告することに関係します（フラグ0 = 0）セグメントはレポートセグメントです。レポートセグメントの承認他のセグメントは、セッションのキャンセルアクティビティに関係します（フラグ1 = 0）セグメントがブロック送信者によるキャンセルに関係している場合、（フラグ0 = 1）セグメントが送信者によるキャンセルである場合、他のセグメントは送信者によるキャンセルの認識ですセグメントは、ブロックレシーバーによるキャンセルに関係しています（フラグ0 = 1）セグメントが受信機によるキャンセルである場合、セグメントは受信機によるキャンセルの認識です
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、Flag 1、およびFlag 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緑のデータ、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 Report-cookNowledmentセグメント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 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 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 - 1 1 EOB End of block;
block size = offset + length
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 Report-COCKNOWLEDMINGセグメント
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 CANCEL-CONKNOWLEDMENTセグメントセグメントをブロックする
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レシーバーをブロックするための車のキャンセル - 承認セグメントセグメント
1 1 - 0 Cx Cancel segment (generic)
1 1-0 cxキャンセルセグメント（ジェネリック）
1 1 - 1 CAx Cancel-acknowledgment segment (generic)
1 1-1 CAX Cancel -cooknowledmentセグメント（ジェネリック）
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.
エクステンションフィールドにより、以下で説明するように、それぞれ型長値（TLV）表現の基本的なLTPセグメントにゼロ以上の機能拡張を含めることができます。
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.
各拡張機能は、拡張機能のタイプを識別する1オクテットのタグで構成され、その後にSDNV形式の長さパラメーターが続き、その後に指定された長さの値が続きます。
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のコンテンツは、1つ以上のデータ受信クレームを含み、クレームが関係するデータブロック内のスコープの上限と下限とともに構成されています。また、効率的な再送信をサポートする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は、最後のレポートシリアル番号を1で増やすことでシリアル番号の値を見つける必要があります。ただし、RSが再送信された場合、そのシリアル番号は元々送信されたときと同じでなければなりません。レポートのシリアル番号はゼロではありません。
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つのデータ受信クレームが含まれています。ブロックのバイト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の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到達不可能なクライアントサービスの届かない。
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 Missoloredは、ブロックオフセットでのレッドパートデータセグメントを、グリーンパートデータセグメントオフセットを上回るか、レッドパートデータセグメントオフセットを下回るブロックオフセットでグリーンパートデータセグメントを受け取りました。
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.
Cancel-cooknowledgments（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）第3バイトはクライアントサービスデータの最初のバイトでなければなりませんグリーンパートデータセグメントで。これは、赤い部分の境界では、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).
ブロックのレッドパートの長さがゼロより大きい場合、適切なセグメントタイプフラグビットを設定することにより、赤いパートデータを含む最後のデータセグメントはEORP（赤部分の端）セグメントとしてマークする必要があります（セクション3.1。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.
- それ以外の場合は、このセッションを開始した送信要求で指定された宛先LTPエンジンへの送信のために、CS（ブロック送信者によるキャンセルによるブロック送信者によるキャンセル）セグメントをキューに掲載する必要があります。
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.
- それ以外の場合は、Block Senderへの送信のために、CR（ブロックレシーバーによるキャンセルによるブロックレシーバーによるキャンセル）セグメントをキューに掲載する必要があります。
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は、UDP、ソフトウェア開発の目的で、またはプライベートローカルエリアネットワークでのみ使用する必要があります。たとえば、リンクが利用可能な場合、LTPトラフィックにのみ使用されるスパースセンサーネットワークでの使用。
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の場合、（a）各UDPデータグラムのコンテンツは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.
- CP、RS（レポート）、EORP、EOB、およびCX（キャンセル）セグメントの送信時に、タイマーを開始できるように、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.
- それ以外の場合、データセグメントにブロックの赤い部分からのデータが含まれている場合、ブロック送信者への送信のために、理論コードのないCRを除いてEnqueuedする必要があります。データセグメントにブロックのグリーンパートからのデータが含まれていても、データセンダーへの送信のために、理論コードのない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.
応答：リンク状態キューCEASで指定された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.
- 公称リモートエンジンは、伝送時間を確認すると、元のセグメントの送信時間の合計（承認セグメントが応答します）とリモートエンジンへの一方向の光時間、さらにAALセクション6.5のn秒として計算されます。
- 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エンジンに確立されたチェックポイント再送信制限を超えると、セグメントが1つのトークンであるセッションがキャンセルされます。「キャンセルセッション」手順（セクション6.19）が呼び出され、合理コードREXCを備えたCSが（概念的な）アプリケーションデータキューに追加され、送信セッションキャンセル通知（セクション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.
この手順は、（a）RSセグメントに関連付けられたカウントダウンタイマーの有効期限、または（b）1つ以上のRSセグメントが以前に発行されたCPセグメントの受信 - 冗長な再送信チェックポイントのいずれかによってトリガーされます。
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 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.
回答：影響を受けるRSセグメントが送信用にキューに掲載されている場合、ネットワーク管理によってローカルLTPエンジンに確立されたレポート再送信制限を超えると、セグメントが1つのトークンであるセッションがキャンセルされます。「キャンセルセッション」手順（セクション6.19）が呼び出され、合理コードREXCを備えたCRセグメントがセッションを発信した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.
この手順は、このセッションのEORPが受信されたときにCPセグメントの到着によってトリガーされます（データブロックの赤部分のサイズがわかっていることを確認します。これには、CPセグメント自体がEORPセグメントである場合が含まれます）、およびこのセッションで送信されるブロックの赤い部分のすべてのデータが受信されました。
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).
この手順は、（a）CPセグメントの元の受信（このCPを識別するチェックポイントシリアル番号は新しい）のいずれかによってトリガーされます（b）EORPがまだ受け取っていない特定のブロック受信セッションに関する実装固有の状況（「非同期」受信報告）。
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）が呼び出されます。-CodeRLEXCが発行され、概念として、セッションを発信するLTPエンジンにバインドされた内部操作トラフィックのキューに追加され、レセプションセッションキャンセル通知（セクション7.6）は、それぞれで識別されたクライアントサービスに送信されます。このセッションで受け取ったデータセグメント。レセプションの問題の1つの制限は、1つのセッションで発行できるレセプションレポートの最大数です。
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.
- レポートセグメントに応じてチェックポイント自体が発行された場合、このレポートは「二次」受信レポートです。その場合、レポートの下限は、不必要な再送信を最小限に抑えるために、トリガーチェックポイント自体が応答であるレポートセグメントの下限である必要があります。注：帯域幅の経済が重要ではない展開の場合、レポートの下限はゼロになる可能性があります。
- 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:
すべての場合において、レポートの範囲の該当する下限が該当する上限（たとえば、裁量的なチェックポイントの秩序外到着のために）以上であると判断された場合、受信レポートはそうではありません発行される。さもないと：
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.
応答：最初に、RSセグメントと同じレポートシリアル番号を持つRAセグメントが発行され、概念として、レシーバーに縛られた内部操作トラフィックのキューに追加されます。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エンジンに確立された制限を超える場合、セグメントが1つのトークンであるセッションがキャンセルされます。「キャンセルセッション」手順（セクション6.19）が呼び出されます。Reason Codeを使用すると、REXCはこのセッションを開始する送信要求で指定された送信キューに追加され、送信セッションキャンセル通知（セクション7.5）が送信を要求したクライアントサービスに返送されます。送信の問題の1つの可能な制限は、単一セッションで発行される可能性のある再送信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.
- このセッションの伝送の問題の数が制限を超えていない場合、受信請求によって非寛解が暗示されているすべてのブロックデータをカプセル化する新しいデータセグメントは、受信機にバインドされた送信キューに追加されます。最後の - 最後のデータセグメントは、新しいCPシリアル番号（使用された最後のCPシリアル番号を増加させることで取得）と受信したRSセグメントのレポートシリアル番号を運ぶ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.
応答：元のRSセグメントに関連付けられたカウントダウンタイマー（RAセグメントのレポートシリアル番号で識別）が削除されます。このセッションには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エンジンに確立されたキャンセル再送信制限を超えると、セグメントが1つのトークンであるセッションは単純に閉じられています。（セクション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セグメントである場合、車（レシーバーをブロックするためのキャンセル承認）セグメントが発行され、概念として、レシーバーに拘束される内部操作トラフィックのキューに追加されます。
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.
CXセグメントが再送信された可能性があります。これは、以前の応答承認CAX（キャンセル承認）セグメントが失われたため、セグメントが1つのトークンであるセッションの記録がなくなるためです。もしそうなら、それ以上の措置は取られません。
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セグメントに関連付けられたタイマーが削除され、セグメントが1つのトークンであるセッションが閉じられています。つまり、「クローズセッション」手順（セクション6.20）が呼び出されます。
This procedure is triggered internally by one of the other procedures described above.
この手順は、上記の他の手順の1つによって内部的にトリガーされます。
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.
この手順は、上記の他の手順の1つによって内部的にトリガーされます。
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）が呼び出され、理由コードの誤った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セッションの場合）。例は、システムが重度のメモリクランチに直面して、LTPセッションをTCP Sack [sack] Renegingのシナリオと同様のシナリオに強制する場合です。しかし、アドバイザリーであるTCPサックレセプションレポートとは異なり、LTPレセプションレポートは拘束力があり、以前に作られたレセプションの請求では復geは許可されていません。
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）が呼び出されます。送信者でエラー条件が観察される場合、Reason-Code 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.
（セクション6.21）のように、送信者にバインドされている送信キューセットがない場合（おそらくローカルLTPエンジンが受信のみのデバイスで実行されているため）、または受信者がこのグリーンの送信者を知っている場合 - 部品データは「ビーコン」（送信専用）ファッションで機能しています。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実装がセッションのキャンセル手順を開始する可能性のある他の実装固有の制限がある場合があります。そのような制限の1つは、見られる再送信サイクルの最大数です。LTP送信者の再送信サイクルは、2つの関連するイベントで構成されています。送信者からのすべての未解決のCPセグメントの送信、およびそれらのCPセグメントに応じて受信機から発行されたすべてのRSセグメントの受信です。同様の定義はLTP受信機に適用されますが、CPセグメントの受信とすべてのRSセグメントの送信に関連しています。再送信されたCPおよびRSセグメントは、元の再送信サイクルの一部であり続けることに注意してください。また、単一のCPセグメントでは、受信レポートが単一のデータリンクMTUサイズのRSセグメントに収まらない場合、複数のRSセグメントが生成される場合があります。受信レポートの一部であるすべてのRSセグメントは、CPセグメントが属するのと同じ再送信サイクルに属します。重度のチャネルエラー条件が存在する場合、赤い部分の伝達が成功すると見なされる前に、多くの再送信サイクルが経過する可能性があります。したがって、実装は、リソースクランチの状況からそれ自体を保護するために再送信サイクルの制限を課す可能性があります。LTP送信者が再送信サイクルの制限を超えていることに気付いた場合、キャンセルセッションの手順（セクション6.19）を開始し、CSセグメントを「RXMTCYCEXCのCSセグメント」と、クライアントサービスに送信セッションキャンセル通知（セクション7.5）を送信する必要があります。。
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を運ぶ最初のデータセグメントの到着時に配信されます。
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通常の赤データセグメント（{cp | eorp | eob}ではありません）GDSレギュラーグリーンデータセグメント（EOBではない）
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. Sender LTP Sender State Transition Diagram
/\/\/\/\
| 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マーカー開始セッションのキャンセルで始まるシーケンスに移動します。Reason-Code USR_CNCLD。CXマーカーから、適切な合理コード（CXシーケンスの入力方法に応じてUSR_CNCLDまたはRLEXC）を備えたCSセグメントは、LTPレシーバーへの送信のためにキューに入り、送信者はCancel-From-Sender（CS_SENT）状態に入ります。内部手順の開始キャンセルタイマー（セクション6.15）は、CSセグメントの送信の開始を示すリンク状態キューを受信すると開始されます。レシーバーから確認するCASセグメントを受信すると、LTP送信者は閉じた状態に移動します（「CNCLD」ポインターを介して）。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送信者はCNCLDマーカーに従って閉じた状態になります。ただし、再送信の制限を超えない場合、CSセグメントは再送信のためにキューに留められ、LTP送信者はCS_SENT状態にとどまります。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送信者は応答して自動車セグメントを送信し、閉じた状態に戻ります。
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。trans。req）を受信するまで、閉じた状態にとどまります。リクエストを受信すると、ブロックの一部が赤として送信されるように要求されていない場合、または非ゼロブロック-PREFIXの場合は赤パート伝送状態（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サイズを尊重するために、伝送のために複数の赤いデータセグメントがキューに入っています。Sender LTPは、オプションで赤いデータセグメントの一部を非同期チェックポイントとしてマークする場合があります。内部手順の開始チェックポイントタイマー（セクション6.2）は、非同期チェックポイントの送信を示すリンク状態のキューを受信したときに追跡されます。ブロック送信要求がゼロ以外の緑色の部分で構成されている場合、LTP送信者は最後の赤いデータセグメントをCPとEORPとしてマークし、伝送のためにキューインした後、緑色の送信（gp_xmit）状態に移動します。ただし、ブロック送信要求が完全に赤い場合、最後の赤いデータセグメントはCP、EORP、およびEOBとしてマークされ、Sender LTPはRed-Part-Part-AckNowledgment（Wait_rp_ack）状態に直接移動します。上記の両方の状態移動の両方で、内部手順はチェックポイントタイマーを開始し（セクション6.2）、キューのCPセグメントの送信の開始を示すリンク状態のキューを受信したときに追跡されます。gp_xmit状態では、ブロックのグリーンパートはグリーンデータセグメントとしてセグメント化され、LTPレシーバーへの送信のためにキューに囲まれています。ブロックの最後のグリーンセグメントは、EOBとしてさらにマークされており、送信のためにキューインした後、LTP送信者はwait_rp_ack状態に移動します。
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はLTPレシーバーから受信される可能性があります（以前に送信されたCPセグメントに応じて、または加速した再送信のために非同期に送信されます）。LTP送信者は、RXマーカー（図の第2部）で始まる一連の状態遷移を実行し、必要に応じてデータを再送信し、内部手順を再確認することを実行します（セクション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セグメントがその範囲内でデータの不完全な受信を示した場合、LTP送信者は、スコープ内の赤いデータセグメントが欠落しているレッドパート再送信状態（RP_RXMT）に移動します。最後のこのようなセグメントは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): 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.
2. 以前に設定されたCPタイマーの有効期限が切れる可能性があります。LTP送信者は、CPマーカー（図の第2部）から始まる状態に従い（図の第2部）、内部手順の再送信チェックポイント（セクション6.7）に従います。送信者は、CXマーカーに続く一連の状態遷移によって示されるように、セッションのキャンセル（REASON-CODE REXCを使用）に向けて進みます。それ以外の場合は（再送信制限がまだ超えていない場合）、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）。
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セグメントが失われた場合、またはLTPレシーバーがRSセグメントを早期に再送信した場合）。閉じた状態にとどまります。CRセグメントを発行することによりセッションが受信機によってキャンセルされた場合、受信機はCRセグメントを再送信することができます（早期的に、または確認する車セグメントが迷子になったため）。この場合、LTP送信者は、承認の自動車セグメントを再送信し、閉じた状態にとどまります。
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状態にない場合、CXマーカーで始まる一連の状態遷移に従って、Reason-Code USR_CNCLDを持つCRセグメントを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レシーバーは閉じた状態で始まり、最初のデータセグメントを受信すると、データセグメント受信（DS_REC）状態に入ります。データセグメントで参照されているクライアントサービスIDが存在しない場合、CXマーカー（図の第2部）から始まるキャンセルシーケンスを介して、合理コードのないCXセグメントをLTP送信者に送信する必要があります。受信したセグメントが誤っていることがわかった場合、内部手順は誤ったセグメント（セクション6.21）を処理し、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（セクション6.8）の再送信（セクション6.8）または受信レポート（セクション6.11）のいずれかに続いて、送信者に送信するために応答するRSセグメントがキューにキューになります。それぞれ再送信（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とマークされていない場合、LTPレシーバーはDS_REC状態に戻ります。それ以外の場合は、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タイマーは、DS_REC、RCV_RP、RCV_GP、またはWAIT_RP_REC状態で、LTPレシーバーの有効期限が切れ、中断される場合があります。その場合、中断された状態に戻る前に、RXマーカー（図の第2部に示す）で始まる状態で説明されているように、内部手順を再送信します（セクション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.
- ここでは、セッションで送信されたRSSの数でネットワーク管理によって設定された再送信制限を超えているかどうかを確認するためにチェックが行われます。その場合、Reason-Code REXCを備えた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の状態にとどまり、完全な赤部分レセプションで閉じた状態に移動します。この状態では、すべてのレッドパートデータセグメントの受信時にチェックが行われ、受け取った緑のパートデータセグメントよりも高いブロックオフセットにあるかどうかを確認します。その場合、内部手順はミスコレーションセグメント（セクション6.21）を処理し、CXマーカーから始まる状態遷移のシーケンスに従います。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状態から閉じた状態に移動します。
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とマークされた赤いデータセグメントを受信すると、CPがそれぞれ再送信であることがわかったかどうかに応じて、内部手順の再送信（セクション6.8）または受信レポート（セクション6.11）のいずれかに基づいて、送信用の応答RSセグメントをキュートします。。内部手順の開始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）。LTP送信者から車セグメントが受信された場合、LTPレシーバーは内部手順の後に閉じた状態（CNCLDマーカーを介して）に戻り、キャンセルタイマーを停止します（セクション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マーカーに続いて閉じた状態に戻ります。それ以外の場合、CRセグメントは、実際の伝送を示すリンク状態のキューを受信すると、内部手順を開始したCARタイマーのキャンセルタイマー（セクション6.15）に続いて開始されたCRセグメントが再送信される予定です。
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レシーバーは、閉じた状態で再送信された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など）を削除して、タイマーの有効期限が切れ、通信スケジュールの知識を持って行われた場合、コミュニケーションを完全に無効にする可能性があります。これは、下層層サービスへのDOS攻撃を確認して、確認セグメントを送信するのを防ぐために、または単にトランスミッションをジャミングすることによって達成できます（すべてがLTPの地上でのアプリケーションでより可能性が高い）。
- 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攻撃のいずれかが可能性がある場合は、次の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.
- ITまたはそのピアがDOS攻撃を受けていると疑うエンジンは、そのデータセグメント（送信者の場合）を頻繁にチェックポイントしたり、非同期RSSを送信したりすることができます（受信者の場合）。攻撃者が応答できなかったため、以前。
- 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.
1. LTPセグメントを受け取ったら、リプレイについてキャッシュに対して確認してください。これがリプレイセグメントであり、事前に調理された応答が利用可能である場合（このセグメントが最後に処理された時点から保存されています）、事前に調理された応答を送信します。調理された応答がない場合は、インバウンドセグメントを静かにドロップします。これはすべて、バッファーをデコードしようとすることなく行うことができます。
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
(b) 着信パケットがRSセグメントである場合、RAセグメントは事前に調理されたものとして保存され、
(c) when the incoming packet is a Cx segment, the CAx segment sent in response gets stored pre-cooked.
(c) 着信パケットがCXセグメントである場合、それに応じて送信された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デコード操作の試みが依然として行われることです。しかし、すべての攻撃者がリプレイキャッシュを通過するためにしなければならないことは、毎回インバウンドセグメントで1つのビットを調整することであるため、それがはるかに良くなることは明らかではありません。これはハッシュルックアップよりも確かに安価です組み合わせをデコードしますが、同じオクテットを何度も送信するよりも確かに高価です。
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]。ランダム値の衝突は、誕生日のパラドックスの対象となります。つまり、衝突は、スペースのほぼ平方根が見られた後に見られる可能性があります（たとえば、32ビットのランダム値の場合、2^16）。
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展開のために予約されています。このポート番号を使用して、インターネット上でのテストのために、このポート番号を使用してUDPデータグラムを操作するようにLTP実装を実装できます。
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は、既知のLTP拡張タグのレジストリを作成し、維持しています（セクション3.1で示されています）。レジストリは、上記のセクション3.1に示されている初期値を使用して入力されています。IANAは、仕様が必要なルール[ガイド]を使用して、範囲0x02-0XAF（包括的）の範囲からLTP拡張タグ値を割り当てることができます。関係する仕様は、RFC（標準の追跡、実験、情報のいずれか）、またはIANAによって認識されたその他の標準開発組織からの仕様、またはCCSDSを含むIESGとのリエゾン（http：//www.ccsdsの仕様です。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.
ティム・レイ、ヴィント・ケルフ、ボブ・ダースト、ケビン・フォール、エイドリアン・フック、キース・スコット、リー・トーガーソン、エリック・トラビス、ハウィー・ワイスに感謝します。
Part of the research described in this document was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. This work was performed under DOD Contract DAA-B07- 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407.
この文書に記載されている研究の一部は、国立航空宇宙局との契約の下で、カリフォルニア工科大学のジェット推進研究所で実施されました。この作業は、DOD契約DAA-B07-00-CC201、DARPA AO H912で実行されました。JPLタスクプランNo. 80-5045、DARPA AO H870;およびNASA契約NAS7-1407。
Thanks are also due to Shawn Ostermann, Hans Kruse, 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.
また、ショーンオスターマン、ハンスクルーゼ、ドベルマイヤーズ、およびオハイオ大学のジェイラムデシュパンデが、さまざまなデザインの決定を提案し、アドバイスしてくれたことにも感謝します。この作業は、マニカンタン・ラマダスがオハイオ大学のEECS部門のインターネットワーキング研究グループ研究所の大学院生だったときに行われました。
Part of this work was carried out at Trinity College Dublin as part of the SeNDT contract funded by Enterprise Ireland's research innovation fund.
この作業の一部は、エンタープライズアイルランドのResearch Innovation Fundが資金提供するSendt契約の一環として、Trinity College Dublinで実施されました。
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Burleigh、S.、Ramadas、M。、およびS. Farrell、「Licklider Transmission Protocol -Motivation」、RFC 5325、2008年9月。
[LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider Transmission Protocol - Security Extensions", RFC 5327, September 2008.
[ltpext] Farrell、S.、Ramadas、M。、およびS. Burleigh、「Licklider Transmission Protocol -Security Extensions」、RFC 5327、2008年9月。
[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）、標準エンコードルール（CER）、および区別エンコードルール（DER）の仕様。itu-t rec。X.690（2002）|ISO/IEC 8825-1：2002。
[BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[BP] Scott、K。およびS. Burleigh、「バンドルプロトコル仕様」、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. Fall、「挑戦されたインターネットのための遅延耐性ネットワークアーキテクチャ」、ACM Sigcomm 2003、Karlsruhe、ドイツ、2003年8月の議事録。
[ESC05] D. Eastlake, J. Schiller and S. Crockerr, "Randomness Recommendations for Security", RFC 4086, June 2005.
[ESC05] D. Eastlake、J。Schillerおよび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. Mathis、J。Mahdavi、S。Floyd、およびA. Romanow、「TCP Selective Auncement Options」、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 Telemetry Tracking and Command Network（ISTRAC）Indian Space Research Organization（ISRO）PLOT＃12＆13、3番目のメイン、第2フェーズPeenya Industrial Area Bangalore 560097インド電話：91 80 2364 2602メール：mramadas@gmail.com
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
Scott C. Burleigh Jet Propulsion Laboratory 4800 Oak Grove Drive M/S：301-490 Pasadena、CA 91109-8099電話：1（818）393-3353 FAX：1（818）354-1075メール：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メール：stephen.farrell@cs.tcd.ie
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびhttp://www.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。