RFC5326 日本語訳
5326 Licklider Transmission Protocol - Specification. M. Ramadas, S.Burleigh, S. Farrell. September 2008. (Format: TXT=120567 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
ネットワークワーキンググループM.Ramadasはコメントのために以下を要求します。 5326ISTRAC、ISROカテゴリ: 実験的なS.バーレイNASA/ジェット推進委研究所S.ファレルトリニティー・カレッジダブリン2008年9月
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. It represents the consensus of the Delay Tolerant Networking (DTN) Research Group of the Internet Research Task Force (IRTF). It may be considered for standardization by the IETF in the future, but the IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 それはインターネットResearch Task Force(IRTF)のDelay Tolerant Networking(DTN)研究Groupのコンセンサスを表します。 それは将来、標準化のためにIETFによって考えられるかもしれませんが、IETFは配備されたプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 詳しい情報に関してRFC3932を見てください。
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.
このドキュメントは接続性で非常に長いメッセージ往復の倍(RTTs)特徴付けられたリンク、そして/または、頻繁な中断の上に「再-トランスミッション」ベースの信頼性を提供するように設計されたLicklider Transmissionプロトコル(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.
このドキュメントは、Delay Tolerant Networking Research Groupの製品であり、そのグループによって再検討されました。 RFCとしての公表への反論は全く上げられませんでした。
Ramadas, et al. Experimental [Page 1] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[1ページ]RFC5326LTP--仕様2008年9月
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
1. 序論…3 2. 用語…4 3. セグメント構造…9 3.1. セグメントヘッダー…10 3.1.1. セグメントタイプは弛みます…11 3.1.2. セグメントタイプコード…13 3.1.3. セグメントクラス仮面…14 3.1.4. 拡大分野…14 3.2. セグメント内容…16 3.2.1. データ・セグメント(DS)…16 3.2.2. セグメント(RS)を報告してください…17 3.2.3. 確認応答セグメントを報告してください…19 3.2.4. セッション管理セグメント…20 3.3. セグメントトレーラ…20 4. クライアントサービスからの要求…20 4.1. トランスミッション要求…21 4.2. 解約請求…22 5. 操作環境からの要件…23 6. 内部手続き…24 6.1. 伝送を始めてください…25 6.2. チェックポイントタイマを始動してください…25 6.3. RSタイマを始動してください…25 6.4. トランスミッションを止めてください…25 6.5. タイマを吊してください…26 6.6. タイマを再開してください…26 6.7. チェックポイントを再送してください…27 6.8. RSを再送してください…27 6.9. 赤い部分レセプションを意味してください…28 6.10. 葉の部分セグメント到着を意味してください…28 6.11. レセプションレポートを送ってください…28 6.12. トランスミッション完成を意味してください…30 6.13. データを再送してください…30 6.14. RSタイマを止めてください…31 6.15. キャンセルタイマを始動してください…32 6.16. キャンセルセグメントを再送してください…32 6.17. キャンセルを承諾してください…32 6.18. キャンセルタイマを止めてください…33 6.19. キャンセルセッション…33 6.20. 厳密なセッション…33 6.21. Miscoloredセグメントを扱ってください…33 6.22. 取り扱いシステムエラー条件…34 7. クライアントサービスへの通知…35 7.1. セッション始め…35 7.2. 葉の部分セグメント到着…36 7.3. 赤い部分レセプション…36 7.4. トランスミッションセッション完成…36
Ramadas, et al. Experimental [Page 2] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[2ページ]RFC5326LTP--仕様2008年9月
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
7.5. トランスミッションセッションキャンセル…37 7.6. レセプションセッションキャンセル…37 7.7. 初期のトランスミッション完成…37 8. 変遷ダイヤグラムを述べてください…38 8.1. 送付者…39 8.2. 受信機…44 9. セキュリティ問題…48 9.1. サービス妨害問題…48 9.2. 取り扱いを再演してください…49 9.3. 実現問題…50 10. IANA問題…51 10.1. UDPはLTPの数を移植します…51 10.2. LTP拡大タグ登録…51 11. 承認…51 12. 参照…52 12.1. 標準の参照…52 12.2. 有益な参照…52
1. Introduction
1. 序論
This document serves as the main protocol specification of LTP and is part of a series of documents describing LTP. Other documents in this series include the motivation document [LTPMTV] and the protocol extensions document [LTPEXT]. We strongly recommend reading the protocol motivation document before reading this document, to establish sufficient background and motivation for the specification.
このドキュメントは、LTPの主なプロトコル仕様として機能して、LTPについて説明するドキュメントのシリーズの一部です。 このシリーズにおける他のドキュメントは動機ドキュメント[LTPMTV]とプロトコル拡大ドキュメント[LTPEXT]を含んでいます。 私たちは、仕様に関する十分なバックグラウンドと動機を証明するためにこのドキュメントを読む前にプロトコル動機ドキュメントを読むことを強く勧めます。
LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful, and has no negotiation or handshakes.
LTPは、選択している承認レセプションレポートに請求することによって、データ伝送のAutomatic Repeat reQuest(ARQ)をします。 それは、statefulで、どんな交渉も握手も持っていません。
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.
Delay Tolerant Networking Research Groupによって開発されているBundleプロトコルを配備するInterplanetaryインターネット設定では、LTPがダイレクト無線周波数(RF)コミュニケーションにある隣接しているInterplanetaryインターネット接続装置の間の対状ファッションで作動する信頼できる「集合層」プロトコルとして機能することを意図します。 その操作上のシナリオに、潜在的に、Bundleプロトコルのある他の展開では、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のデザインに含まれていないので、世界的なインターネットでの遍在している展開には、このプロトコルは、意図していなくて、また適切ではありません。
Ramadas, et al. Experimental [Page 3] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[3ページ]RFC5326LTP--仕様2008年9月
When LTP is run over UDP, it must only be used for software development or in private local area networks. When LTP is not run over UDP, it must be run directly over a protocol (nominally a link- layer protocol) that meets the requirements specified in Section 5.
LTPがUDPの上を走るとき、ソフトウェア開発か私設のローカル・エリア・ネットワークにそれを使用するだけでよいです。 LTPがUDPの上を走らないとき、それはセクション5で指定された必要条件を満たすプロトコル(名目上は、リンク層は議定書を作る)の直接上の走行であるに違いありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [B97].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[B97]で説明されるように本書では解釈されることであるべきですか?
2. Terminology
2. 用語
(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がDelay許容性があるNetworking(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.
上側の層のプロトコル(通常Bundleプロトコル)によって伝えられた、1つの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".
ブロックの始めで始まる隣接の八重奏を包括する1ブロックのどんな部分集合も「ブロック接頭語」と呼ばれます、そして、ブロックの端があるブロック結末のどんなそのような部分集合も「ブロック接尾語」と呼ばれます。
(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.
すなわち、当てにならずに、そして、承認か「再-トランスミッション」を条件として伝えられることになっていないブロック接尾語。 存在しているなら、1ブロックの葉の部分は赤い部分の端に続く八重奏のときに始まります。
(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
LTPプロトコル活動の糸はブロックを伝える目的のために2台の同輩エンジンの間で伝導しました。 セッションにおけるデータフローは単方向です: データ通信量は送付同輩から流れます。
Ramadas, et al. Experimental [Page 4] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[4ページ]RFC5326LTP--仕様2008年9月
receiving peer, while data-acknowledgment traffic flows from the receiving peer to the sending peer.
同輩を受けて、データ承認交通が受信から流れている間、送付同輩としてじっと見てください。
(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データ伝送活動のユニット。 それはセッションの間に1台の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).
以下によって特徴付けられたアプリケーションデータ(1ブロックの部分集合)の何らかの数の隣接の八重奏のレセプションの主張 最初の容認された八重奏のオフセット、および受けられた(オフセットのときに、始まります)隣接の八重奏の数。
(11) Scope
(11) 範囲
Scope identifies a subset of a block and comprises two numbers -- upper bound and lower bound.
範囲は、1ブロックの部分集合を特定して、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
*ではなく、セグメント、上限がブロック接頭語の終わりであるというレポートにおけるレセプションクレームが適用されますが、下界がレポートにおけるレセプションクレームが*をする(より小さい)の内部のブロック接頭語の終わりであるレポートに関しては、適用してください。 すなわち、どんなオフセットのときにもレポートの下界にもかかわらず、以下より等しいかすばらしいデータ、それ
Ramadas, et al. Experimental [Page 5] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[5ページ]RFC5326LTP--仕様2008年9月
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).
最後のデータ・セグメントは1ブロックのオリジナルの伝達の一部として伝わりました。 また、このデータ・セグメントは、セグメントの上限がブロック(八重奏における)の全長であることを示します。
(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).
セグメントはブロックの赤い部分の最後の八重奏を含む1ブロックのオリジナルの伝達の一部として伝わりました。 また、このデータ・セグメントは、セグメントの上限がブロックの赤い部分(八重奏における)の長さであることを示します。
(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.
何らかの実現に対応して発行されるレセプションレポートはチェックポイントの到着以外の出来事を定義しました。
Ramadas, et al. Experimental [Page 6] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[6ページ]RFC5326LTP--仕様2008年9月
(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はObject Identifier値をコード化することの抽象的なSyntax Notation One[ASN1]計画に倣われます。 SDNVとしてコード化されたデータ・フィールドでは、SDNVのそれぞれの八重奏の最も重要なビット(MSB)は、八重奏がSDNVの最後の八重奏であるかどうかを示すのに役立ちます。 1のMSBとの八重奏は、それがマルチ八重奏SDNVの1番目か中央八重奏のどちらかであることを示します。 0のMSBとの八重奏はSDNVの最後の八重奏です。 SDNVでコード化された値はSDNVのそれぞれの八重奏の7つの最下位ビットを連結することによって、見つけられます、最初の八重奏のときに始まって、最後の八重奏のときに終わって。
Ramadas, et al. Experimental [Page 7] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[7ページ]RFC5326LTP--仕様2008年9月
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}
- -
{100 1010 1} {0 011 1100} - -
= 10010101 00111100
= 10010101 00111100
0x1234 : 0001 0010 0011 0100
= 1 0010 0011 0100
is encoded as
0×1234: 0001 0010 0011 0100 = 1 0010 0011 0100はコード化されます。
{10 1 0010 0} {0 011 0100}
- -
{10 1 0010 0} {0 011 0100} - -
= 10100100 00110100
= 10100100 00110100
0x4234 : 0100 0010 0011 0100
=100 0010 0011 0100
is encoded as
0×4234: 0100 0010 0011 0100 =100 0010 0011 0100はコード化されます。
{1000000 1} {1 00 0010 0} {0 011 0100}
- - -
{1000000 1} {1 00 0010 0} {0 011 0100} - - -
= 10000001 10000100 00110100
= 10000001 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.
コード化されるべき値が作る中で最も重要な噛み付いている端(最下位ビットでは、終わらない)のゼロで水増しされるのを確実にするために注意しなければならない、それ、bitwiseする、コード化の前の7の長さのa倍数。
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
どんな理論上の限界もSDNV分野のサイズにない間、私たちは、7ビット毎の実際のデータがコード化されるためにSDNV計画のオーバーヘッドが1:7、すなわち、オーバーヘッドの1ビットであることに注意します。 その結果、a
Ramadas, et al. Experimental [Page 8] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[8ページ]RFC5326LTP--仕様2008年9月
7-octet value (a 56-bit quantity with no leading zeroes) would be
encoded in an 8-octet SDNV; an 8-octet value (a 64-bit quantity with
no leading zeroes) would be encoded in a 10-octet SDNV. In general,
an N-bit quantity with no leading zeroes would be encoded in a
ceil(N/7) octet SDNV, where ceil is the integer ceiling function.
Clearly, for fields that typically carry larger values such as RSA
public keys, the SDNV overhead could become unacceptable. Hence,
when adopting the SDNV scheme for other purposes related to this
document, such as any protocol extensions, we RECOMMEND that if the
typical data field value is expected to be larger than 8 octets, then
the data field should be specified as a {LENGTH, VALUE} tuple, with
the LENGTH parameter encoded as an SDNV followed by LENGTH octets
housing the VALUE of the data field.
7八重奏の値(主なゼロのない56ビットの量)は8八重奏のSDNVでコード化されるでしょう。 8八重奏の値(主なゼロのない64ビットの量)は10八重奏のSDNVでコード化されるでしょう。 一般に、主なゼロのないN-ビット量はceilでコード化された(N/7)八重奏SDNVでしょう。(そこでは、ceilは整数天井機能です)。 明確に、RSA公開鍵などの、より大きい値を通常運ぶ分野のために、SDNVオーバーヘッドは容認できなくなることができました。 したがって、SDNVを採用するときにはもう一方を計画してください。目的はどんなプロトコル拡大などのこのドキュメントにも関連して、私たちは典型的なデータが値をさばくなら8つの八重奏より大きいと予想されるRECOMMENDです、データ・フィールドのVALUEを収容するLENGTH八重奏でLENGTH、tupleであって、SDNVとしてLENGTHパラメタでコード化されたVALUEが続いたので指定されていて、データ・フィールドがそうするべきであるその時。
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表現がスケーラビリティを犠牲にしないで最も小さいセグメントサイズをもたらすと信じています。
3. Segment Structure
3. セグメント構造
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.
レポート確認応答セグメントは、送付者から受信機まで流れて、レポートセグメントのレセプションを承認します。 承認されていて、それはレポートの通し番号を運びます。
Ramadas, et al. Experimental [Page 9] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[9ページ]RFC5326LTP--仕様2008年9月
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 +-----------------------------------------------+
ビット0 1 2 3 4 5 6 7^ +-----+-----+-----+-----+-----+-----+-----+-----+ | | バージョン番号| セグメントタイプ旗| コントロール| +-----------------------+-----------------------+ バイト| | | | /セッションID\| \/ヘッダー+-----------------------+-----------------------+ | | ヘッダー拡大Cnt。 | トレーラ、拡大Cnt| 拡大| +-----------------------+-----------------------+ | | | | /ヘッダー拡大\| \/V+-----------------------------------------------+ | | | | | | | セグメント内容| / \ \ / | | | | | | ^ +-----------------------------------------------+ | | | トレーラ/トレーラ拡大\| \/V+-----------------------------------------------+
3.1. Segment Header
3.1. セグメントヘッダー
An LTP segment header comprises three data items: a single-octet control byte, the session ID, and the Extensions field.
LTPセグメントヘッダーは3つのデータ項目を含みます: ただ一つの八重奏コントロールバイト、セッションID、およびExtensions分野。
Control byte comprises the following:
コントロールバイトは以下を包括します:
Version number (4 bits): MUST be set to the binary value 0000 for
this version of the protocol.
バージョン番号(4ビット): 設定しなければなりません。プロトコルのこのバージョンのための2進の値0000。
Ramadas, et al. Experimental [Page 10] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[10ページ]RFC5326LTP--仕様2008年9月
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.
セッション創始者(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によって課された唯一の要件はセッションIDで唯一LTPエンジンによって開始されたあらゆるセッションを特定しなければならないということです。
The Extensions field is described in Section 3.1.4.
Extensions分野はセクション3.1.4で説明されます。
3.1.1. Segment Type Flags
3.1.1. セグメントタイプ旗
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ビットはセグメントの本質を示す旗です。 整然とする、(最上位ビット、1番目)、これらの旗は、CTRLと、EXCと、Flag1と、Flag0です。
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(コントロール)旗による0の値は、セグメントがデータ・セグメントであると認識します、1の値が、それがコントロールセグメントであると認識しますが。 0に設定されたEXC(例外)旗があるデータ・セグメントは赤い部分セグメントです。 1に用意ができているEXCがあるデータ・セグメントは葉の部分セグメントです。 コントロールセグメントのために、EXC旗を1に設定させるのは、セグメントがセッションキャンセル活動に関係するのを示します。 1に用意ができているFlag1とFlag0の両方があるどんなデータ・セグメント(赤い部分か葉の部分であることにかかわらず)もEOBを示します。 0に用意ができているFlag1とFlag0の両方があるどんなデータ・セグメント(赤い部分か葉の部分であることにかかわらず)も少しも追加議定書意味なしでデータを示します。 フラグビットが非ゼロに合わせているどんな赤い部分データ・セグメントもチェックポイントです。 1に用意ができているFlag1があるどんな赤い部分データ・セグメントも赤い部分の端を示します。
Ramadas, et al. Experimental [Page 11] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[11ページ]RFC5326LTP--仕様2008年9月
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
(旗1 = 1)セグメントが(旗0 = 1)セグメントがほかにブロックで最後のセグメントであるならチェックポイントセグメントがブロックの赤い部分で最後のセグメントであるということであるなら(EXC旗の=0)セグメントが赤い部分データだけを含んでいるなら(CTRL旗の=0)セグメントがデータ・セグメントであるなら、//セグメントは赤い部分の端が(旗0 = 1)セグメントがチェックポイントのほかのセグメントであるなら(旗0 = 1)セグメントがブロックのほかのセグメントで最後のセグメントであるなら(EXC旗の=0)セグメントであるなら(旗1 = 1)がコントロールセグメントであるなら葉の部分データだけを含んでいるということではありません; (旗0 = 0)セグメントが(旗1 = 0)セグメントが(旗0 = 1)であるならブロック送付者によるキャンセルに関するならセグメントのほかのセグメントがほかのセグメントがセッションキャンセル活動に関係させるレポートセグメントの承認であるというレポートであるならレポート活動に関係します; セグメントは(旗0 = 1)セグメントが受信機のほかのセグメントによるキャンセルがcanceの承認であるということであるなら送付者のほかのセグメントによるキャンセルがほかのセグメントがブロック受信機でキャンセルに関係させる送付者によるキャンセルの承認であるということです。受信機によるllation
Ramadas, et al. Experimental [Page 12] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[12ページ]RFC5326LTP--仕様2008年9月
3.1.2. Segment Type Codes
3.1.2. セグメントタイプコード
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、Flag1、およびFlag0の設定の組み合わせはセグメントタイプコードを構成します。(コードは詳細なセグメント自然の簡潔な表現として機能します)。
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
セグメントのCTRL EXC Flag1Flag0Codeネイチャー---- --- ------ ------ ---- --------------------------------------- チェックポイント、EORPまたはEOBではなく、0 0 0 0 0の赤いデータ、EORPかEOBではなく、0 0 0 1 1のRedデータ、Checkpoint、0 0 1 0 2のRedデータ、Checkpoint、EORP、NOT EOB0 0 1 1 3Redデータ、Checkpoint、EORP、EOB
0 1 0 0 4 Green data, NOT EOB
0 1 0 1 5 Green data, undefined
0 1 1 0 6 Green data, undefined
0 1 1 1 7 Green data, EOB
0 1 0 0 4のグリーンデータ、NOT EOB0 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 9Report-確認応答セグメント1 0 1 0 10Controlセグメントを報告します、未定義の1 0 1 1 11Controlセグメント、未定義です。
1 1 0 0 12 Cancel segment from block sender
1 1 0 1 13 Cancel-acknowledgment segment
to block sender
送付者を妨げるブロック送付者1 1 0 1 13キャンセル確認応答セグメントからの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 1 15キャンセル確認応答セグメント受信機からの1 1 1 0 14キャンセルセグメント
Ramadas, et al. Experimental [Page 13] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[13ページ]RFC5326LTP--仕様2008年9月
3.1.3. Segment Class Masks
3.1.3. セグメントクラス仮面
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
CTRL EXC旗1は0の簡略記憶記述に旗を揚げさせます。---- --- ------ ------ -------- --------------------------- 0 0--1、または--0 0 1--CPチェックポイント
0 0 1 - EORP End of red-part;
red-part size = offset + length
0 0 1--赤い部分のEORP End。 赤い成形品の寸法はオフセット+長さと等しいです。
0 - 1 1 EOB End of block;
block size = offset + length
ブロックの0--1 1EOB End。 ブロック・サイズはオフセット+長さと等しいです。
1 0 0 0 RS Report segment;
carries reception claims
1 0 0 0RS Reportセグメント。 レセプションクレームを運びます。
1 0 0 1 RA Report-acknowledgment segment
1 0 0 1RA Report-確認応答セグメント
1 1 0 0 CS Cancel segment from block sender
ブロック送付者からの1 1 0 0CSキャンセルセグメント
1 1 0 1 CAS Cancel-acknowledgment segment
to block sender
1 1 0 1妨げるCASキャンセル確認応答セグメント送付者
1 1 1 0 CR Cancel segment from block receiver
ブロック受信機からの1 1 1 0CRキャンセルセグメント
1 1 1 1 CAR Cancel-acknowledgment segment
to block receiver
妨げる1 1 1 1CARキャンセル確認応答セグメント受信機
1 1 - 0 Cx Cancel segment (generic)
1 1--0Cxキャンセルセグメント(一般的)です。
1 1 - 1 CAx Cancel-acknowledgment segment
(generic)
1 1--1CAxキャンセル確認応答セグメント(一般的)です。
3.1.4. Extensions Field
3.1.4. 拡大分野
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.
Extensions分野はゼロか、より機能的な拡大の包含を基本的なLTPセグメントに可能にします、それぞれ以下で説明されるタイプ長さの価値(TLV)の表現で。
Ramadas, et al. Experimental [Page 14] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[14ページ]RFC5326LTP--仕様2008年9月
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.
Extensions分野の最初の八重奏はセグメントにおける現在の拡大の数を示します: 高位4ビットはヘッダーの拡大TLVsの数を示します(すぐに続いて、拡張子が八重奏を数えます、そして、先行して、セグメントは満足しています)、下位の4ビットはトレーラの拡大TLVsの数を示しますが(すぐにセグメントの内容に従って)。 すなわち、各セグメントはトレーラにヘッダーの0〜15拡大TLVsと0〜15拡大からTLVsを持っているかもしれません。 どんな拡大TLVsが不在のとき、この拡大カウントでは、すべてのビット、ゼロに八重奏を設定しなければなりません。
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.
彼らがヘッダーかトレーラに起こるとき、以下のダイヤグラムは拡大TLVsを例証します。
+--------+----///-----///--+ |ext-tag | length | value | +--------+-------///-------+----------///-------+ |ext-tag | length | value | +--------+-----///-----///-+---------////-------+ |ext-tag | length | value | +--------+----------+----------+
+--------+----///-----///--+ |ext-タグ| 長さ| 値| +--------+-------///-------+----------///-------+ |ext-タグ| 長さ| 値| +--------+-----///-----///-+---------////-------+ |ext-タグ| 長さ| 値| +--------+----------+----------+
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 Extension Tag登録を維持します。 Unassigned範囲のコードポイント課題の詳細に関して下の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
拡大タグMeaning------------- ------- 0×00 LTPの認証の拡大の[LTPEXT]0x01LTPクッキー拡張子[LTPEXT]の0×02 0xAF Unassigned 0xB0-0xBF Reserved 0xC0-0xFFの兵士/実験的な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.
実現が拡大タグスペースの最後の4分の1が実験用のためのものであるのでこれらのタグのための衝突が可能であることを意識しているべきであることに注意してください。
Ramadas, et al. Experimental [Page 15] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[15ページ]RFC5326LTP--仕様2008年9月
3.2. Segment Content
3.2. セグメント内容
3.2.1. Data Segment (DS)
3.2.1. データ・セグメント(DS)
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]のガイドラインを使用するのは、RECOMMENDEDです。 送付者によって発行されたどんなその後のチェックポイントでも、先のチェックポイント通し番号を1つ増加することによって、通し番号値を見つけなければなりません。 しかしながら、チェックポイントセグメントが再送されるとき、通し番号はそれが元々伝えられた時と同じであるに違いありません。 チェックポイント通し番号はゼロであるはずがありません。
Ramadas, et al. Experimental [Page 16] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[16ページ]RFC5326LTP--仕様2008年9月
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.
セグメントで運ばれたクライアントサービスデータは元のクライアントサービスデータ・ブロックのバイトの部分集合のコピーです、示されたオフセットから。
3.2.2. Report Segment (RS)
3.2.2. レポートセグメント(RS)
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]のガイドラインを使用するのは、RECOMMENDEDです。 受信機によって発行されたどんなその後の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.
レポートセグメントの上限はセグメントのレセプションクレームが関係するブロック接頭語のサイズです。
Ramadas, et al. Experimental [Page 17] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[17ページ]RFC5326LTP--仕様2008年9月
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のデータ受信クレームからクライアントサービスデータの「再-トランスミッション」を求める暗示している要求を推論できます。*しかしながら、*を推論できるセグメントの上限より等しいか大きいどんなオフセットにおける、または、いずれものブロック・データのレセプションがセグメントのものが下ろされるほど相殺しなかったものは何も付きませんでした。
Ramadas, et al. Experimental [Page 18] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[18ページ]RFC5326LTP--仕様2008年9月
For example, if the scope of a report segment has lower bound 0 and upper bound 6000, and the report contains a single data reception claim with offset 0 and length 6000, then the report signifies successful reception of the first 6000 bytes of the block. If the total length of the block is 6000, then the report additionally signifies successful reception of the entire block.
例えば、レポートセグメントの範囲には下界0と上限6000があって、レポートがオフセット0と長さ6000があるただ一つのデータ受信クレームを含んでいるなら、レポートがブロックの最初の6000バイトのうまくいっているレセプションを意味します。 ブロックの全長が6000であるなら、レポートはさらに、全体のブロックのうまくいっているレセプションを意味します。
If on the other hand, the scope of a report segment has lower bound 1000 and upper bound 6000, and the report contains two data reception claims, one with offset 0 and length 2000 and the other with offset 3000 and length 500, then the report signifies successful reception only of bytes 1000-2999 and 4000-4499 of the block. From this we can infer that bytes 3000-3999 and 4500-5999 of the block need to be retransmitted, but we cannot infer anything about reception of the first 1000 bytes or of any subsequent data beginning at block offset 6000.
他方では、レポートセグメントの範囲には下界1000と上限6000があって、レポートが2つのデータ受信クレーム、オフセット3000があるオフセット0、長さ2000、およびもう片方がある1と長さ500を含んでいるなら、レポートがブロックのバイト1000-2999と4000-4499だけのうまくいっているレセプションを意味します。 これから、私たちが、ブロックのバイト3000-3999と4500-5999が、再送される必要がありますが、私たちが最初の1000バイトのレセプションに関して何も推論できないと推論できますか、またはどんな順次データでも、ブロックで始まるのは6000を相殺しました。
3.2.3. Report Acknowledgment Segment
3.2.3. レポート確認応答セグメント
The content of an RA is simply the report serial number of the RS in response to which the segment was generated.
RAの内容は単にRSに対応してセグメントが発生したレポート通し番号です。
Report serial number (SDNV)
レポート通し番号(SDNV)
This field returns the report serial number of the RS being
acknowledged.
承認されていて、この分野はRSのレポート通し番号を返します。
Ramadas, et al. Experimental [Page 19] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[19ページ]RFC5326LTP--仕様2008年9月
3.2.4. Session Management Segments
3.2.4. セッション管理セグメント
Cancel segments (Cx) carry a single byte reason-code with the following semantics:
キャンセルセグメント(Cx)は以下がある理由コード意味論を1バイト運びます:
Reason-Code Mnemonic Semantics
----------- -------- ---------------------------------------
00 USR_CNCLD Client service canceled session.
理由コードの簡略記憶意味論----------- -------- --------------------------------------- 00 USR_CNCLD Clientは取り消されたセッションを修理します。
01 UNREACH Unreachable client service.
01 UNREACH Unreachableクライアントサービス。
02 RLEXC Retransmission limit exceeded.
RLEXC Retransmission限界が超えていた02。
03 MISCOLORED Received either a red-part data segment
at block offset above any green-part
data segment offset or a green-part
data segment at block offset below any
red-part data segment offset.
03 どんな赤い部分データ・セグメントの下でも相殺されたブロックのMISCOLORED Receivedどんな葉の部分データ・セグメントオフセットを超えて相殺されたブロックの赤い部分データ・セグメントか葉の部分のどちらかデータ・セグメントは相殺されました。
04 SYS_CNCLD A system error condition caused
unexpected session termination.
04SYS_CNCLD Aシステムエラー条件は予期していなかったセッション終了を引き起こしました。
05 RXMTCYCEXC Exceeded the Retransmission-Cycles limit.
RXMTCYCEXC Exceeded Retransmission-サイクルズが制限する05。
06-FF Reserved
予約された06ff
The Cancel-acknowledgments (CAx) have no content.
キャンセル承認(CAx)には、内容が全くありません。
Note: The reason we use different cancel segment types for the originator and recipient is to allow a loopback mode to work without disturbing any replay protection mechanism in use.
以下に注意してください。 私たちが創始者と受取人に異なったキャンセルセグメントタイプを使用する理由はループバックモードが使用中のどんな反復操作による保護メカニズムも擾乱しないで働くのを許容することです。
3.3. Segment Trailer
3.3. セグメントトレーラ
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拡大TLVsの系列から成ります。
4. Requests from Client Service
4. クライアントサービスからの要求
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.
すべての場合では、要求パラメタの表現はローカルの実現問題です、パラメタ値の合法化とクライアントサービスの通知のように要求が無効であることがわかっている場合。
Ramadas, et al. Experimental [Page 20] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[20ページ]RFC5326LTP--仕様2008年9月
4.1. Transmission Request
4.1. 送信要求
In order to request transmission of a block of client service data, the client service MUST provide the following parameters to LTP:
1ブロックのクライアントサービスデータの伝達を要求するために、クライアントサービスは以下のパラメタを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)、第バイト、葉の部分データ・セグメントにおける、クライアントサービスデータの最初のバイトはブロックSHOULDの、そうです。 これが、赤い部分境界では、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
ブロックの赤い部分の長さがゼロ以上であるなら、EORP(赤い部分の端)セグメントとして適切なセグメントタイプフラグビット(セクション3.1.2)を設定することによって、赤い部分データを含む最後のデータ・セグメントをマークしなければなりません。 ゼロか赤い部分データを含むデータ・セグメントにさらに先行する、(アルゴリズムによると、選択されます。
Ramadas, et al. Experimental [Page 21] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[21ページ]RFC5326LTP--仕様2008年9月
a local implementation matter) MAY additionally be marked as a CP (Checkpoint), and serve as additional discretionary checkpoints (Section 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)に送り返されます。
4.2. Cancellation Request
4.2. 解約請求
In order to request cancellation of a session, either as the sender or as the receiver of the associated data block, the client service must provide the session ID identifying the session to be canceled.
送付者として、または、関連データブロックの受信機としてセッションのキャンセルを要求するために、クライアントサービスは取り消されるためにセッションを特定するIDをセッションに提供しなければなりません。
On reception of a valid cancellation request from a client service, LTP proceeds as follows.
クライアントサービスからの有効な解約請求のレセプションでは、LTPは以下の通り続きます。
First, the internal "Cancel Session" procedure (Section 6.19) is invoked.
まず最初に、内部の「キャンセルセッション」手順(セクション6.19)は呼び出されます。
Next, if the session is being canceled by the sender (i.e., the session originator part of the session ID supplied in the cancellation request is the local LTP engine ID):
次に、取り消されるのがセッションであるなら送付者であります(すなわち、IDが解約請求で供給したセッションのセッション創始者部分はローカルのLTPエンジンIDです):
- If none of the data segments previously queued for transmission
as part of this session have yet been de-queued and transmitted
-- i.e., if the destination engine cannot possibly be aware of
this session -- then the session is simply closed; the "Close
Session" procedure (Section 6.20) is invoked.
- すなわち、目的地エンジンがこのセッションを意識しているはずがないなら、以前にトランスミッションのためにこのセッションの一部として列に並ばせられたデータ・セグメントのいずれもまだデキューされて、伝えられていないなら、セッションは単に終えられます。 「厳密なセッション」手順(セクション6.20)は呼び出されます。
- Otherwise, a CS (cancel by block sender) segment with the
reason-code USR_CNCLD MUST be queued for transmission to the
destination LTP engine specified in the transmission request
that started this session.
- さもなければ、理由コードUSR_CNCLD MUSTが目的地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エンジンがaで走っているので、装置だけを受けてください)、セッションは単に終えられます。 「厳密なセッション」手順(セクション6.20)は呼び出されます。
- Otherwise, a CR (cancel by block receiver) segment with reason-
code USR_CNCLD MUST be queued for transmission to the block
sender.
- そうでなければ、理由コードUSR_CNCLD MUSTがブロック送付者への伝送のため列に並ばせられているCR(ブロック受信機で、取り消す)セグメント。
Ramadas, et al. Experimental [Page 22] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[22ページ]RFC5326LTP--仕様2008年9月
5. Requirements from the Operating Environment
5. 操作環境からの要件
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 MUSTが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、それぞれのUDPデータグラムの内容が整数のLTPセグメントと(b)がLTP認証[LTPEXT]拡大SHOULDであったなら終わりから端への経路がデータグラム内容不正の見込みが取るにたらないものか受信する結果でないなら使用されて、不正なLTPセグメントを処理しながらそうしなければならない(a)がわずかであるという(ソフトウェア開発のように)ことであるときに。 さらに、終わりから端への経路がデータグラム内容不正の見込みが取るにたらない(いくつかの私設のローカル・エリア・ネットワークのように)ものか受信の結果でないならデータ保全を確実にするのに使用されて、不正なLTPを処理すると区分されるLTP認証[LTPEXT]拡大SHOULDはわずかです(恐らくソフトウェア開発のように)。
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.
- それが、要求のときにタイムアウト間隔について計算するために、現在の距離(軽い秒の)をどんな同輩エンジンにも供給するのに必要です。
Ramadas, et al. Experimental [Page 23] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[23ページ]RFC5326LTP--仕様2008年9月
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.
操作のためのLTPエンジンは定期的に地方のデータ・リンク層と操作環境によってアップデートされた上記のパラメタがあるMIB(管理Information基地)を入手するはずです。 しかしながら、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は、受け取られたセグメントのデータ保全の照合を実行するために基本的なローカルのデータリンク層プロトコルを必要とします。 明確に、ローカルのデータリンク層プロトコルが、崩壊したセグメントが受けたいずれも検出して、静かにそれらを捨てるのに必要です。
6. Internal Procedures
6. 内部手続き
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エンジンがaで走っているので、装置だけを受けてください)、受信データセグメントは単に捨てられます。
- Otherwise, if the data segment contains data from the red-part
of the block, a CR with reason-code UNREACH MUST be enqueued for
transmission to the block sender. A CR with reason-code UNREACH
SHOULD be similarly enqueued for transmission to the data sender
even if the data segment contained data from the green-part of
the block; note however that (for example) in the case where the
block receiver knows that the sender of this green-part data is
functioning in a "beacon" (transmit-only) fashion, a CR need not
be sent. In either case, the received data segment is
discarded.
- そうでなければ、理由コードUNREACH MUSTがブロック送付者への伝送のため待ち行列に入れられているCRデータ・セグメントがブロックの赤い部分からのデータを含んでいるなら。 CR、データ・セグメントがブロックの葉の部分からのデータを含んだとしても、理由コードUNREACH SHOULDと共にデータへの伝送のため送付者であると同様に待ち行列に入れられてください。 (例えば) そんなにしかしながら中でブロック受信機が、この葉の部分データの送付者が「標識」で機能しているのを知っているケースに注意してください、(伝える、-単に、)、ファッション、CRを送る必要はありません。 どちらの場合ではも、受信データセグメントは捨てられます。
Ramadas, et al. Experimental [Page 24] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[24ページ]RFC5326LTP--仕様2008年9月
6.1. Start Transmission
6.1. 伝送を始めてください。
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エンジンへのセグメントのデキューするのと配送は始まります。
6.2. Start Checkpoint Timer
6.2. チェックポイントタイマを始動してください。
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)をやめたのが知られているなら、このタイマはすぐに吊されます、計算された予想された到着時間がまだ計算できない調整を必要とするかもしれないので。
6.3. Start RS Timer
6.3. RSタイマを始動してください。
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)をやめたのが知られているなら、このタイマはすぐに吊されます、計算された予想された到着時間がまだ計算できない調整を必要とするかもしれないので。
6.4. Stop Transmission
6.4. トランスミッションを止めてください。
This procedure is triggered by the arrival of a link state cue indicating the cessation of transmission to a specified remote LTP engine.
この手順は指定されたリモートLTPエンジンにトランスミッションの休止を示すリンク州の手がかりの到着で引き起こされます。
Response: the de-queuing and delivery to the underlying communication system of segments from traffic queues bound for the LTP engine specified in the link state cue ceases.
応答: リンク州の手がかりで指定されたLTPエンジンに向かっている交通待ち行列からのセグメントの基本的な通信系へのデキューするのと配送はやみます。
Ramadas, et al. Experimental [Page 25] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[25ページ]RFC5326LTP--仕様2008年9月
6.5. Suspend Timers
6.5. タイマを吊してください。
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.
名目上のリモートエンジンであるなら、トランスミッション時間が電流が、より調節されるという(すなわち、承認セグメントはトランスミッションのためにリモートエンジンのトランスミッションが吊していることの時間、提示されるかもしれません)ことであると認めてください、次に、これのためのカウントダウンタイマが、セグメントが吊していると認めて。
6.6. Resume Timers
6.6. タイマを再開してください。
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:
応答: リモートエンジンがあらゆる承認セグメントですが、戻ると予想されて、時間が調整される到着を予想しました。(カウントダウンタイマはそれにおいて吊されました)。 まず最初に、トランスミッション遅れ間隔は以下の通り計算されます:
Ramadas, et al. Experimental [Page 26] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[26ページ]RFC5326LTP--仕様2008年9月
- The nominal remote engine acknowledge transmission time is
computed as the sum of the transmission time of the original
segment (to which the acknowledging segment will respond) and
the one-way light time to the remote engine, plus N seconds of
AAL Section 6.5.
- 名目上のリモートエンジンは、トランスミッション時間がオリジナルのセグメント(承認セグメントが応じる)のトランスミッション時間、リモートエンジンへの一方通行の軽い時間、およびN秒のAALセクション6.5の合計として計算されると認めます。
- If the nominal remote engine acknowledge transmission time is
greater than the current time, i.e., the remote engine resumed
transmission prior to presentation of the acknowledging segment
for transmission, then the transmission delay interval is zero.
- 名目上のリモートエンジンが、トランスミッション時間が現在の時間より大きいと認めるなら、すなわち、リモートエンジンは承認セグメントのプレゼンテーションの前にトランスミッションのためにトランスミッションを再開しました、そして、トランスミッション遅れ間隔がゼロです。
- Otherwise, the transmission delay interval is computed as the
current time less the nominal remote engine acknowledge
transmission time.
- さもなければ、トランスミッション遅れ間隔による現在の時間としてそれほど計算されないで、名目上のリモートエンジンがトランスミッション時間を承認するということです。
The expected arrival time is increased by the computed transmission delay interval for each of the suspended countdown timers, and the timers are resumed.
予想された到着時間はそれぞれの吊したカウントダウンタイマのために計算されたトランスミッション遅れ間隔のそばで増加します、そして、タイマは再開されます。
6.7. Retransmit Checkpoint
6.7. チェックポイントを再送してください。
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)を呼び出します、そして、(概念的)のアプリケーションデータ待ち行列に理由コードRLEXCとCSを追加します、そして、トランスミッションセッション解約通知書(セクション7.5)にトランスミッションを要求したクライアントサービスを送り返します。
Otherwise, a new copy of the CP segment is appended to the (conceptual) application data queue for the destination LTP engine.
さもなければ、目的地LTPエンジンのための(概念的)のアプリケーションデータ待ち行列にCPセグメントの新しいコピーを追加します。
6.8. Retransmit RS
6.8. RSを再送してください。
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
応答: トランスミッションのためにどんな影響を受けるRSセグメントも列に並ばせてあるという回の数が地方のLTPエンジンのためにネットワークマネージメントで確立されたレポート「再-トランスミッション」限界を超えているなら、セグメントが1つの象徴であるセッションは中止されます: 「キャンセルセッション」手順(セクション6.19)は呼び出されて、CRはセグメントです。
Ramadas, et al. Experimental [Page 27] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[27ページ]RFC5326LTP--仕様2008年9月
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.
セッションを溯源したLTPエンジンへの伝送のため理由コードRLEXCを列に並ばせます、そして、このセッションのときに受け取られたそれぞれのデータ・セグメントで特定されたクライアントサービスにレセプションセッション解約通知書(セクション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エンジンへの伝送のため列に並ばせられます。
6.9. Signify Red-Part Reception
6.9. 赤い部分レセプションを意味してください。
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セグメント自体がEORPセグメントであるケースを含んでいます)、このセッションのときに伝えられるブロックの赤い部分のすべてのデータを受け取ったとき、CPセグメントの到着でこの手順を引き起こします。
Response: a red-part reception notice (Section 7.3) is sent to the specified client service.
応答: 赤い部分レセプション通知(セクション7.3)を指定されたクライアントサービスに送ります。
6.10. Signify Green-Part Segment Arrival
6.10. 葉の部分セグメント到着を意味してください。
This procedure is triggered by the arrival of a data segment whose content is a portion of the green-part of a block.
この手順は内容が1ブロックの葉の部分の一部であるデータ・セグメントの到着で引き起こされます。
Response: a green-part segment arrival notice (Section 7.2) is sent to the specified client service.
応答: 葉の部分セグメント着荷通知(セクション7.2)を指定されたクライアントサービスに送ります。
6.11. Send Reception Report
6.11. レセプションレポートを送ってください。
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) EORPがないのがそうした特定のブロックレセプションセッションに関して(b) 実現特有の状況を区分しますが(このCPを特定するチェックポイント通し番号は新しいです)、受け取られたCP(「非同期な」レセプション報告)のオリジナルのレセプションによって引き起こされます。
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)を呼び出します、そして、概念では、理由コードRLEXCがあるCRセグメントを発行して、セッションを溯源したLTPエンジンに向かっている社内業務交通の待ち行列に追加します、そして、このセッションのときに受け取られたそれぞれのデータ・セグメントで特定されたクライアントサービスにレセプションセッション解約通知書(セクション7.6)を送ります。 レセプション問題における1つの可能な限界がどんなただ一つのセッションのためにも発行できるレセプションレポートの最大数でしょう。
Ramadas, et al. Experimental [Page 28] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[28ページ]RFC5326LTP--仕様2008年9月
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.
- 上限、不要な「再-トランスミッション」を最小にするためにはレポートSHOULDでは、データが区分するチェックポイントの上限(オフセットと長さの合計)になってください。 以下に注意してください。 任意のチェックポイントが無くなりますが、その後のセグメントが受け取られているなら、無くなっているチェックポイントの「再-トランスミッション」が受け取られている時までには、受信機には、ブロックオフセットのときに、チェックポイントの上限を超えてセグメントがあるでしょう。 展開のために、同期レセプションレポートの上限は影響を受けるセッションのときに今までのところ受け取られているすべての赤い部分データ・セグメントの中の帯域幅経済が重要でないところの最大の上限値であるかもしれません。
- 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.
- チェックポイントがレポートセグメントに対応して発行されたなら、このレポートは「二次」のレセプションレポートです。 その場合、下側はバウンドしています。レポートSHOULDでは、引き金となるチェックポイントがそれ自体で不要な「再-トランスミッション」を最小にするためには応答であったレポートセグメントの下界になってください。 以下に注意してください。 展開のために、レポートの下界は代わりに帯域幅経済が重要でないところのゼロであるかもしれません。
- 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.
- チェックポイントがレポートセグメントに対応して発行されなかったなら、このレポートは「第一」のレセプションレポートです。 どんなセッションのためにも発行された最初の第一のレセプションレポートの下界はゼロであるに違いありません。 それぞれのその後の第一のレセプションの下界は、不要な「再-トランスミッション」を最小にするためにはセッションのために発行された先の第一のレセプションレポートの上限であるように同じセッションSHOULDのために発行されて、報告します。 以下に注意してください。 展開のために、あらゆる第一のレセプションレポートの下界は帯域幅経済が重要でないところのゼロであるかもしれません。
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
- 他のどんな第一のレセプションレポートもまだ発行されていないどんなセッションのためにも発行された最初の非同期なレセプションレポートの下界はゼロであるに違いありません。 それぞれのその後の非同期なレセプションの下界は、SHOULDが発行された先の第一のレセプションレポートの上限であると報告します。
Ramadas, et al. Experimental [Page 29] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[29ページ]RFC5326LTP--仕様2008年9月
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がレポートの範囲の中のすべてのデータ受信に関して報告するのに必要です、基本的な通信サービスで課されるどんなデータサイズ規制も考えて。 概念では、示されたセッションを溯源したLTPエンジンに向かっている社内業務交通の待ち行列にRSセグメントを追加します。 レポートの最初のRSセグメントの下界はレセプションレポートの下界であるに違いありません。 レポートの最後のRSセグメントの上限はレセプションレポートの上限であるに違いありません。
6.12. Signify Transmission Completion
6.12. トランスミッション完成を意味してください。
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)を受け取ったということである中で最も前半のもの引き起こされます。 EOBセグメントをデキューすること(トランスミッションのための)をブロックに示すリンク州の手がかりの到着で状態(a)は合図されます。 状態(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)は呼び出されます。
6.13. Retransmit Data
6.13. データを再送してください。
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
応答: RSセグメントは発行されて、概念にあるので、まず最初に、同じレポート通し番号があるRAセグメントは受信機に向かっている交通を社内業務の待ち行列に追加しました。RSセグメントは余分です--すなわち、示されたセッションが未知(例えば、RSセグメントをセッションを終了した後に受け取るか、または取り消す)かセグメントのRSものであるなら、通し番号を報告してください。
Ramadas, et al. Experimental [Page 30] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[30ページ]RFC5326LTP--仕様2008年9月
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セグメントを受け取られていて、処理したマッチ--そして、さらなる行動を全く取りません。 さもなければ、以下の手順は従われています。
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)を呼び出します、そして、このセッションのときに始まった送信要求で指定されたトランスミッション待ち行列に理由コードRLEXCとCSを追加します、そして、トランスミッションセッション解約通知書(セクション7.5)にトランスミッションを要求したクライアントサービスを送り返します。 トランスミッション問題における1つの可能な限界がどんなただ一つのセッションのためにも発行されるかもしれないretransmission 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セグメントとしてデータ・セグメントをマークしなければなりません。
6.14. Stop RS Timer
6.14. RSタイマを止めてください。
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)は呼び出されます。
Ramadas, et al. Experimental [Page 31] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[31ページ]RFC5326LTP--仕様2008年9月
6.15. Start Cancel Timer
6.15. キャンセルタイマを始動してください。
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)をやめたのが知られているなら、このタイマはすぐに吊されます、計算された予想された到着時間がまだ計算できない調整を必要とするかもしれないので。
6.16. Retransmit Cancellation Segment
6.16. キャンセルセグメントを再送してください。
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エンジンへの伝送のため列に並ばせられます。
6.17. Acknowledge Cancellation
6.17. キャンセルを承諾してください。
This procedure is triggered by the reception of a Cx segment.
この手順はCxセグメントのレセプションによって引き起こされます。
Response: in the case of a CS segment where there is no transmission queue-set bound for the sender (possibly because the receiver is a receive-only device), then no action is taken. Otherwise:
応答: そして、送付者に向かっているトランスミッション待ち行列セットが全くない(ことによると受信機が受信専用装置であるので)CSセグメントの場合では、行動を全く取りません。 そうでなければ:
- If the received segment is a CS segment, a CAS (cancel
acknowledgment to block sender) segment is issued and is, in
concept, appended to the queue of internal operations traffic
bound for the sender.
- 容認されたセグメントがCSセグメントであるなら、概念では、CAS(送付者を妨げるために承認を中止する)セグメントを発行して、送付者に向かっている社内業務交通の待ち行列に追加します。
- If the received segment is a CR segment, a CAR (cancel
acknowledgment to block receiver) segment is issued and is, in
concept, appended to the queue of internal operations traffic
bound for the receiver.
- 容認されたセグメントがCRセグメントであるなら、概念では、CAR(受信機を妨げるために承認を中止する)セグメントを発行して、受信機に向かっている社内業務交通の待ち行列に追加します。
Ramadas, et al. Experimental [Page 32] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[32ページ]RFC5326LTP--仕様2008年9月
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.
前の応じている承認CAx(承認を中止する)セグメントが失われたのでCxセグメントが再送されたのは、可能です、何かセグメントが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)は呼び出されます。
6.18. Stop Cancel Timer
6.18. キャンセルタイマを止めてください。
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)は呼び出されます。
6.19. Cancel Session
6.19. キャンセルセッション
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エンジンが送付者であるなら、セッションまで割り当てられたすべての残っているデータ再送バッファ領域はリリースできます。
6.20. Close Session
6.20. 厳密なセッション
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)は削除されます。 セッションの存在はもう認識されません。
6.21. Handle Miscolored Segment
6.21. Miscoloredセグメントを扱ってください。
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
この手順は(a) ブロックオフセットがブロックが相殺されたより高いオフセットのときに始まる以前に同じセッションのために受け取られたどんな葉の部分データ・セグメントの赤い部分データ・セグメントか(b) ブロックオフセットがブロックが相殺されたより低いどんな赤い部分データ・セグメントの葉の部分データ・セグメントのどちらかの到着でも引き起こされます。
Ramadas, et al. Experimental [Page 33] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[33ページ]RFC5326LTP--仕様2008年9月
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.
以前に、同じセッションのために受信しました。 上のチェックのどちらかに合っているセグメントの到着はブロック接尾語としてブロック接頭語としてのすべての赤い部分データとすべての葉の部分データを持つプロトコル要件の違反です。
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.
キャンセルSession手順(セクション6.19)は、呼び出されて理由コードMISCOLORED SHOULDがデータ送付者への伝送のため待ち行列に入れられている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)をクライアントサービスに送ります。
6.22. Handling System Error Conditions
6.22. 取り扱いシステムエラー条件
It is possible (especially for long-lived LTP sessions) that an unexpected operating system error condition may occur during the lifetime of an LTP session. An example is the case where the system faces severe memory crunch forcing LTP sessions into a scenario similar to that of TCP SACK [SACK] reneging. But unlike TCP SACK reception reports, which are advisory, LTP reception reports are binding, and reneging is NOT permitted on previously made reception claims.
予期していなかったオペレーティングシステムエラー条件がLTPセッションの生涯起こるのは、可能です(特に長命のLTPセッションのための)。 例はTCP SACK[SACK]が手を引くのについてシステムがそれと同様のシナリオにLTPセッションを力づくで押しながら厳しいメモリかみ砕くことに直面しているケースです。 しかし、レポートが縛っていて、手を引くことが受入れられないLTPレセプションは以前に、TCP SACKレセプションレポートと異なって、レセプションをクレームにしました。レポートは顧問です。
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.
そのようなどんな回復しがたいシステムエラー条件の下ではも、以下の応答は開始されることです: キャンセルSession手順(セクション6.19)は呼び出されます。 エラー条件を観測するなら、送付者、理由コードSYS_CNCLD SHOULDが受信機への伝送のため待ち行列に入れられているCSセグメント、およびトランスミッションセッションのときに、解約通知書(セクション7.5)をクライアントサービスに送ります。 他方では、同じ理由コードSYS_CNCLD SHOULDが送付者への伝送のため待ち行列に入れられている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セグメントを送る必要はありません。
Ramadas, et al. Experimental [Page 34] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[34ページ]RFC5326LTP--仕様2008年9月
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 Senderの「再-トランスミッション」サイクルは2回の関連する出来事を包括します: 送付者からのすべての傑出しているCPセグメントの送信、およびそれらのCPセグメントに対応して受信機から発行されたすべてのRSセグメントのレセプション。 同様の定義は、LTP Receiverで適用しますが、CPセグメントのレセプションと応答における、すべてのRSセグメントの送信に関連するでしょう。 再送されたCPとRSセグメントが彼らの元の「再-トランスミッション」-サイクルの一部のままで残っていることに注意してください。 また、ただ一つのCPセグメントで、レセプションレポートがデータがMTUサイズでリンクされたただ一つのRSセグメントをうまくはめ込まないなら、複数のRSセグメントを発生させるかもしれません。 レセプションレポートの一部であるすべてのRSセグメントがCPセグメントが属するのと同じ「再-トランスミッション」サイクルに属します。 厳しいチャンネルエラー条件があるとき、赤の部分送信がうまくいくと考えられる前に「再-トランスミッション」何サイクルも経過するかもしれません。 したがって、実現は、リソースかみ砕くことの状況からそれ自体を保護するために「再-トランスミッション」-サイクル限界を課すかもしれません。 LTP送付者が「再-トランスミッション」-サイクルに気付くなら、超えられていた存在を制限してください、それ。SHOULDはキャンセルSession手順(セクション6.19)に着手します、理由コードRXMTCYCEXCと共にCSセグメントを列に並ばせて、トランスミッションセッション解約通知書(セクション7.5)をクライアントサービスに送って。
7. Notices to Client Service
7. クライアントサービスへの通知
In all cases, the representation of notice parameters is a local implementation matter.
すべての場合では、通知パラメタの表現はローカルの実現問題です。
7.1. Session Start
7.1. セッション始め
The Session Start notice returns the session ID identifying a newly created session.
Session Start通知は新たに作成されたセッションを特定する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を運ぶ最初のデータ・セグメントの到着のときに提供します。
Ramadas, et al. Experimental [Page 35] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[35ページ]RFC5326LTP--仕様2008年9月
7.2. Green-Part Segment Arrival
7.2. 葉の部分セグメント到着
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。
7.3. Red-Part Reception
7.3. 赤い部分レセプション
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。
7.4. Transmission-Session Completion
7.4. トランスミッションセッション完成
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.
トランスミッションセッション完了通知は、示されたデータ・ブロックのすべてのバイトが送信されて、受信機がブロックの赤い部分を受け取ったことをクライアントサービスに知らせます。
Ramadas, et al. Experimental [Page 36] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[36ページ]RFC5326LTP--仕様2008年9月
7.5. Transmission-Session Cancellation
7.5. トランスミッションセッションキャンセル
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エンジンの受信機か誤りかリソース焼き入れ状態のため終えられたことをクライアントサービスに知らせます。 目的地クライアントサービス例がデータ・ブロックのどんな部分も受けたという保証が全くありません。
7.6. Reception-Session Cancellation
7.6. レセプションセッションキャンセル
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エンジンの送付者か誤りかリソース焼き入れ状態のため終えられたことをクライアントサービスに知らせます。 このセッションのためにどんなその後の引渡通告書も発行しないでしょう。
7.7. Initial-Transmission Completion
7.7. 初期のトランスミッション完成
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.
この通知は、1ブロック(赤い部分と葉の部分の両方)のすべてのセグメントが伝えられたことをクライアントサービスに知らせます。 この通知は、オリジナルのトランスミッションが完全であることを示すだけです。 どんな無くなっている赤い部分データ・セグメントの「再-トランスミッション」もまだ必要であるかもしれません。
Ramadas, et al. Experimental [Page 37] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[37ページ]RFC5326LTP--仕様2008年9月
8. State Transition Diagrams
8. 状態遷移ダイヤグラム
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
RL EXC Retransmissionが制限するTeのタイマの満期のRDSの通常の赤いデータ・セグメント(CP|EORP|EOBでない)のGDSの通常のグリーンデータ・セグメント(EOBでない)は完全に緑色でRP赤いパートGP葉の部分FGを超えていました。
Note that blocks represented in rectangles, as in
ブロックがコネとして中に長方形を表したことに注意してください。
+---------+
| FG_XMIT |
+---------+
+---------+ | 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.
状態へのポインタかプレースホルダのどちらかが状態遷移の系列のためのものですか?
Ramadas, et al. Experimental [Page 38] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[38ページ]RFC5326LTP--仕様2008年9月
8.1. Sender
LTP Sender State Transition Diagram
8.1. 送付者LTP送付者状態遷移ダイヤグラム
/\/\/\/\
| Cncld |
\/\/\/\/
+--------+ | +------+
Rcv CR; | V V V | Rcv RS;
Snd CAR | +-------------+ | Snd RA
+-------+ CLOSED +----+
+---------------------------->+------+------+
| | Blk. Trans. Req
| Zero RP +
| Xmit ________________________/ \ Non-Zero RP
| GDS; / \
| +---+ | +------------------+ | +------+
| | V V | /\/\ Rcv RS V V V |
| | +---------+ +<-| RX |<---+ +---------+ |
| +<-+ FG_XMIT | | \/\/ +---+ +--->+ Xmit RDS;
| +----+----+ | | RP_XMIT | |
| | | /\/\ +---+ +--->+ Xmit {RDS, CP};
+<--------+ +<-| CP |<---+ +-----+---+ Start CP Tmr
| Xmit \/\/ CP TE | \
| {GDS, EOB}; | |
| Xmit {RDS, CP, EORP}; | +-------+
| Start CP Tmr | |
| | |
| +------------------+ | +---+ | Xmit {RDS,
| | /\/\ Rcv RS V V V | | CP, EORP,
| +<-| RX |<---+ +---------+ | | EOB};
| | \/\/ +---+ | | | Start
| | | GP_XMIT +->+ | CP Tmr
| | /\/\ +---+ | Xmit |
| +<-| CP |<---+ +-----+---+ GDS; |
| \/\/ CP TE | |
| | |
| Xmit {GDS, EOB}; | +---------+
| | |
| +------------------+ | |
| | /\/\ Rcv RS V V V
| +<-| RX |<---+ +-------------+
| | \/\/ +---+ |
| | | WAIT_RP_ACK |
| | /\/\ +---+ |
| +<-| CP |<---+ +-----+-------+
| \/\/ CP TE | RP acknowledged fully;
| V
+----------------------------------------+
/\/\/\/\ | Cncld| \/\/\/\/ +--------+ | +------+ Rcv CR。 | V V V| Rcv RS。 Snd車| +-------------+ | Snd RA+-------+は+を閉じました。----+ +---------------------------->+------+------+ | | Blk。 移- Req| RPがありません+。| Xmit________________________/\非ゼロRP| GDS。 / \ | +---+ | +------------------+ | +------+ | | V V| /\/\Rcv RS V V V| | | +---------+ + <、-| RX| <、-、--+ +---------+ | | + <-+FG_XMIT| | \/\/ +---+ +--->+Xmit RDS。 | +----+----+ | | RP_XMIT| | | | | /\/\ +---+ +--->+はRDS、CPをXmitします。 + <。--------+ + <、-| CP| <、-、--+ +-----+---+ スタートCP Tmr| Xmit\/\/CP Te| \ | GDS、EOB。 | | | Xmit、RDS、CP、EORP。 | +-------+ | CP Tmrを始動してください。| | | | | | +------------------+ | +---+ | Xmit、| | |に対する/\/\Rcv RS V V| | + RDS、CP、EORP、<、-、| RX| <、-、--、+ +、-、-、-、-、-、-、-、--、+| | EOB、。 | | \/\/ +---+ | | | 始め| | | GP_XMIT+>+| CP Tmr| | /\/\ +---+ | Xmit| | + <、-| CP| <、-、--+ +-----+---+ GDS。 | | \/\/CP Te| | | | | | Xmit、GDS、EOB。 | +---------+ | | | | +------------------+ | | | | /\/\Rcv RS V V V| + <、-| RX| <、-、--+ +-------------+ | | \/\/ +---+ | | | | 待ち_RP_ACK| | | /\/\ +---+ | | + <、-| CP| <、-、--+ +-----+-------+ | \/\/CP Te| 完全に承認されたRP。 | +に対して----------------------------------------+
Ramadas, et al. Experimental [Page 39] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[39ページ]RFC5326LTP--仕様2008年9月
LTP Sender State Transition Diagram (contd.)
LTP送付者状態遷移ダイヤグラム(contd。)
/\/\ /\/\
|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 |
\/\/\/\/
/\/\ /\/\ |CP| |CX| \/\/ \/\/ | | | Snd Cs| | RL EXC。 | Cs Tmrを始動してください。 | | | | | /\/\ | +---+ | +------>| CX| V V| | \/\/ +---------+ | Cs Te| | Cs_は発信しました。| | EXCではなく、RL。 EXCではなく、V RL。 +-+--+--+-+ | Rxmt Cs、Rxmt CP| | | | スタート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
/\/\ | RX| \/\/ | Cncl CP Tmr(もしあれば)V Snd RA+---------+ +----+ | CHK_RPT| | | +-+--+----+ 範囲VのRP| | | \rcvdでない、完全である、+---------+ | Rxmt余分です。| | RP+--------------------->| RP_RXMT| | なくなったRS rcvd。 | | 範囲+で----+--+-+ | RDS。 | | rcvd完全に| | | V V Rxmtは持続します。| +----+ なくなったRDS| (著しいCP) | 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
LTP送付者が見せられた州のどれかにいる間、地方のクライアントサービスから非同期なキャンセル要求を受け取るかもしれません。 CXマーカーで始まる状態遷移の系列にそれが既になかったなら、内部手続きキャンセルSession(セクション6.19)は後をつけています、そして、LTP送付者は現状から理由コードUSR_CNCLDとのセッションキャンセルを開始するCXマーカーで始まる系列に移ります。 CXマーカー、適切な理由コードがあるCSセグメント、(USR_CNCLDかRLEXC依存、オンである、どのように、CX
Ramadas, et al. Experimental [Page 40] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[40ページ]RFC5326LTP--仕様2008年9月
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受信機と送付者へのトランスミッションが送付者からのキャンセルSent(CS_SENT)状態に入るので、列に並ばせられます。 内部手続きStartキャンセルTimer(セクション6.15)はCSセグメントの送信の始まりを示すリンク州の手がかりを受けるのに始動されます。 承認を受けると、受信機からのCASセグメント、LTP送付者はCLOSED状態に移ります('Cncld'ポインタを通して)。 CSタイマが期限が切れるなら、内部手続きRetransmit Cancellation Segment(セクション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マーカーをCLOSED状態にたどります。 しかしながら、「再-トランスミッション」限界が超えられていないなら、CSセグメントは「再-トランスミッション」のために列に並ばせられます、そして、LTP送付者はCS_SENT状態にいます。 CSタイマは内部手続きStartキャンセルTimer(セクション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セグメントを受けると、内部手続きAcknowledge Cancellation(セクション6.17)は呼び出されます: LTP送付者は、応答でCARセグメントを送って、CLOSED状態に戻ります。
The LTP sender stays in the CLOSED state until receiving a Block Transmission Request (Blk. Trans. Req) from the client service instance. Upon receiving the request, it moves to either the Fully Green Transmission State (FG_XMIT) if no portion of the block was requested to be transmitted as red or to the Red-Part Transmission State (RP_XMIT) state if a non-zero block-prefix was requested to be transmitted red.
LTP送付者はCLOSED状態にBlock Transmission Requestを受けるまでいます。(Blk。 移- Req) クライアントから、例を修理してください。 要求を受け取って、非ゼロブロック接頭語が伝えられた赤であるよう要求されたならブロックの一部によって全く赤かRed-部分Transmission州(RP_XMIT)状態に送られるよう要求されなかったなら、それはFullyグリーンTransmission州(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状態では、ブロックは複数の緑色のLTPデータ・セグメントとして区分されて、リンクMTUサイズを尊敬して、セグメントがリモートエンジンへの伝送のため列に並ばせられるということです。 そのようなセグメントがEOBとしてマークされて、トランスミッションのためにそれを列に並ばせた後にLTP送付者がCLOSED状態に返す最終。
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
リンクMTUサイズを尊敬して、RP_XMIT状態から、同様に、複数の赤いデータ・セグメントがトランスミッションのために列に並ばせられます。 送付者LTPは非同期なチェックポイントとして任意に赤いデータ・セグメントのいくつかをマークするかもしれません。 内部手続きStart Checkpoint Timer(セクション6.2)は、非同期なチェックポイントのトランスミッションを示すリンク州の手がかりを受けながら、生じられます。 ブロック送信要求が非ゼロ葉の部分を包括するなら、CPとEORPと、トランスミッション(グリーンPart Transmission(GP_XMIT)状態への移動)のためにそれを列に並ばせた後に、LTP送付者は最後の赤いデータ・セグメントをマークします。 しかしながら、ブロック送信要求が完全に赤かったなら
Ramadas, et al. Experimental [Page 41] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[41ページ]RFC5326LTP--仕様2008年9月
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.
CP、EORP、EOB、および直接赤い部分承認のためのWait(WAIT_RP_ACK)への送付者LTP移動が述べるように最後の赤いデータ・セグメントは著しいです。 上の状態遷移の両方では、内部手続きStart Checkpoint Timer(セクション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. LTP受信機(以前に、aに対応してCPセグメントを伝えるか、または加速している「再-トランスミッション」を非同期に呼びにやる)からRSを受け取るかもしれません。 LTP送付者は、次に、RXマーカー(ダイヤグラムの第二部)で始まる状態遷移の系列を実行するために動いて、必要なら、データを再送します、内部手続きRetransmit Data(セクション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セグメントがLTP受信機とLTP送付者への伝送のため列に並ばせられると認めるRAセグメントはCheck Report状態(CHK_RPT)に動きます。 RSセグメントがLTP受信機によって冗長に伝えられたなら(ことによると失せた最後に伝えられたRAセグメントかRSセグメントタイマのどちらかが早まって受信機で期限が切れたので)、LTP送付者は、それ以上何もをして、中断している状態に戻って戻ります。 同様に、RSセグメントの範囲の中のすべての赤いデータが受け取るように報告されるなら、やるべき仕事が全くありません、そして、LTP送付者は中断している状態に戻ります。 しかしながら、RSセグメントが範囲の中にデータの不完全なレセプションを示したなら、LTP送付者はRed-部分Retransmit状態(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):
2. 以前に設定されたCPタイマは期限が切れるかもしれません。 今、LTP送付者は、CPマーカー(ダイヤグラムの第二部)で始まる州の後をつけて、内部手続きRetransmit Checkpoint(セクション6.7)の後をつけます:
Ramadas, et al. Experimental [Page 42] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[42ページ]RFC5326LTP--仕様2008年9月
If the CP Retransmission Limit set by network management for
the session has been exceeded, the LTP sender proceeds towards
canceling the session (with reason-code RLEXC) as indicated by
the sequence of state transitions following the CX marker.
Otherwise (if the Retransmission Limit is not exceeded yet),
the CP segment is queued for retransmission and the LTP sender
returns to the interrupted state. The internal procedure Start
Checkpoint Timer (Section 6.2) is started again upon receiving
a link state cue indicating the beginning of transmission of
the segment.
セッションのためにネットワークマネージメントで用意ができているCP Retransmission Limitが超えられているなら、CXマーカーをたどっていて、状態遷移の系列によって示されるようにセッション(理由コードRLEXCと)を中止することに向かってLTP送付者は続きます。 さもなければ(Retransmission Limitがまだ超えられていないなら)、CPセグメントは送付者が中断している状態に返す「再-トランスミッション」とLTPのために列に並ばせられます。 内部手続きStart Checkpoint Timer(セクション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).
内部手続きClose Session(セクション6.20)に続いて、状態がCLOSEDに受信機LTPで受けて、その時戻ったとき赤い部分データが完全に承認されるまでそれに届いた後に、LTP送付者はWAIT_RP_ACK状態にいます。
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送付者がCLOSED状態でRSセグメントを受けているかもしれない間(セッション閉鎖の前の最後に伝えられたRAセグメントが失われたか、またはLTP受信機が早まってRSセグメントを再送したなら)CLOSED状態でRAセグメントを承認して、滞在を再送することに注意してください。 セッションが受信機によってCRセグメントを発行することによって中止されたなら、受信機はCRセグメントを再送するかもしれません(早まってかCARセグメントが承認し始めたのが損をしたので)。 この場合、LTP送付者は、承認しているCARセグメントを再送して、CLOSED状態にいます。
Ramadas, et al. Experimental [Page 43] RFC 5326 LTP - Specification September 2008
Ramadas、他 実験的な[43ページ]RFC5326LTP--仕様2008年9月
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. +--------------------------->+
/\/\/\/\ +----+ +----+ 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. +--------------------------->+
Ramadas, et al. Experimental [Page 44] RFC 5326 LTP - Specification September 2008
Ramadas, et al. Experimental [Page 44] RFC 5326 LTP - Specification September 2008
Receiver State Transition Diagram (contd.)
Receiver State Transition Diagram (contd.)
/\/\
| RX |
\/\/
| |
| | RL EXC; /\/\
RL NOT EXC; | +---------->| CX |
Rxmt RS, | \/\/
Start RS Tmr |
V
/\/\ | 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 |
\/\/\/\/
/\/\ | 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).
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).
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
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
Ramadas, et al. Experimental [Page 45] RFC 5326 LTP - Specification September 2008
Ramadas, et al. Experimental [Page 45] RFC 5326 LTP - Specification September 2008
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
- 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.
- 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.
Ramadas, et al. Experimental [Page 46] RFC 5326 LTP - Specification September 2008
Ramadas, et al. Experimental [Page 46] RFC 5326 LTP - Specification September 2008
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).
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).
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.
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.
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.
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.
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.
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.
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:
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:
Ramadas, et al. Experimental [Page 47] RFC 5326 LTP - Specification September 2008
Ramadas, et al. Experimental [Page 47] RFC 5326 LTP - Specification September 2008
- 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.
- 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.
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.
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.
9. Security Considerations
9. Security Considerations
9.1. Denial of Service Considerations
9.1. Denial of Service Considerations
Implementers SHOULD consider the likelihood of the following Denial of Service (DoS) attacks:
Implementers SHOULD consider the likelihood of the following Denial of Service (DoS) attacks:
- A fake Cx could be inserted, thus bringing down a session.
- A fake Cx could be inserted, thus bringing down a session.
- 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).
- 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).
- An attacker might also corrupt some bits, which is tantamount to
deleting that segment.
- 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.
- An attacker may flood an LTP engine with segments for the internal operations queue and prevent transmission of legitimate data segments.
Ramadas, et al. Experimental [Page 48] RFC 5326 LTP - Specification September 2008
Ramadas, et al. Experimental [Page 48] RFC 5326 LTP - Specification September 2008
- 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.
- 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.
If any of the above DoS attacks is likely, then one or more of the following anti-DoS mechanisms ought to be employed:
If any of the above DoS attacks is likely, then one or more of the following anti-DoS mechanisms ought to be employed:
- Session numbers SHOULD be partly random making it harder to
insert valid segments.
- 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.
- 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.
- Serial numbers (checkpoint serial numbers, report serial
numbers) MUST begin each session anew using random numbers
rather than from 0.
- Serial numbers (checkpoint serial numbers, report serial numbers) MUST begin each session anew using random numbers rather than from 0.
- The authentication header [LTPEXT].
- The authentication header [LTPEXT].
9.2. Replay Handling
9.2. Replay Handling
The following algorithm is given as an example of how an LTP implementation MAY handle replays.
The following algorithm is given as an example of how an LTP implementation MAY handle replays.
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. 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.
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. 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.
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. 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:
(a) when the inbound packet is a CP segment, the RS segment sent
in response gets stored as pre-cooked,
(a) when the inbound packet is a CP segment, the RS segment sent in response gets stored as pre-cooked,
Ramadas, et al. Experimental [Page 49] RFC 5326 LTP - Specification September 2008
Ramadas, et al. Experimental [Page 49] RFC 5326 LTP - Specification September 2008
(b) when the Incoming packet is an RS segment, the RA segment is
stored as pre-cooked, and
(b) when the Incoming packet is an RS segment, the RA segment is stored as pre-cooked, and
(c) when the incoming packet is a Cx segment, the CAx segment sent
in response gets stored pre-cooked.
(c) when the incoming packet is a Cx segment, the CAx segment sent in response gets stored pre-cooked.
4. Occasionally clean out the replay cache -- how frequently this
happens is an implementation issue.
4. Occasionally clean out the replay cache -- how frequently this happens is an implementation issue.
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.
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.
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.
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.
9.3. Implementation Considerations
9.3. Implementation Considerations
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.
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.
Implementations SHOULD check that SDNV values are within suitable
ranges where possible.
Implementations SHOULD check that SDNV values are within suitable ranges where possible.
Byte ranges
Byte ranges
Various report and other segments contain offset and length
fields. Implementations MUST ensure that these are consistent and
sane.
Various report and other segments contain offset and length fields. Implementations MUST ensure that these are consistent and sane.
Randomness
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).
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).
Ramadas, et al. Experimental [Page 50] RFC 5326 LTP - Specification September 2008
Ramadas, et al. Experimental [Page 50] RFC 5326 LTP - Specification September 2008
Implementers MUST ensure that they use sufficiently long random
values so that the birthday paradox doesn't cause a problem in
their environment.
Implementers MUST ensure that they use sufficiently long random values so that the birthday paradox doesn't cause a problem in their environment.
10. IANA Considerations
10. IANA Considerations
10.1. UDP Port Number for LTP
10.1. UDP Port Number for LTP
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.
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.
10.2. LTP Extension Tag Registry
10.2. LTP Extension Tag Registry
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.
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.
11. Acknowledgments
11. Acknowledgments
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.
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.
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.
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.
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.
Ramadas, et al. Experimental [Page 51] RFC 5326 LTP - Specification September 2008
Ramadas, et al. Experimental [Page 51] RFC 5326 LTP - Specification September 2008
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.
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.
12. References
12. References
12.1. Normative References
12.1. Normative References
[B97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[LTPMTV] Burleigh, S., Ramadas, M., and S. Farrell,"Licklider
Transmission Protocol - Motivation", RFC 5325, September
2008.
[LTPMTV] Burleigh, S., Ramadas, M., and S. Farrell,"Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.
[LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
Transmission Protocol - Security Extensions", RFC 5327,
September 2008.
[LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider Transmission Protocol - Security Extensions", RFC 5327, September 2008.
12.2. Informative References
12.2. Informative References
[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] 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.
[BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification",
RFC 5050, November 2007.
[BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[DTN] K. Fall, "A Delay-Tolerant Network Architecture for
Challenged Internets", In Proceedings of ACM SIGCOMM 2003,
Karlsruhe, Germany, Aug 2003.
[DTN] K. Fall, "A Delay-Tolerant Network Architecture for Challenged Internets", In Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, Aug 2003.
[ESC05] D. Eastlake, J. Schiller and S. Crockerr, "Randomness
Recommendations for Security", RFC 4086, June 2005.
[ESC05] D. Eastlake, J. Schiller and S. Crockerr, "Randomness Recommendations for Security", RFC 4086, June 2005.
[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, and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
Ramadas, et al. Experimental [Page 52] RFC 5326 LTP - Specification September 2008
Ramadas, et al. Experimental [Page 52] RFC 5326 LTP - Specification September 2008
Authors' Addresses
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, 3rd Main, 2nd Phase Peenya Industrial Area Bangalore 560097 India Telephone: +91 80 2364 2602 EMail: 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 Telephone: +1 (818) 393-3353 Fax: +1 (818) 354-1075 EMail: 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
Stephen Farrell Computer Science Department Trinity College Dublin Ireland Telephone: +353-1-896-1761 EMail: stephen.farrell@cs.tcd.ie
Ramadas, et al. Experimental [Page 53] RFC 5326 LTP - Specification September 2008
Ramadas, et al. Experimental [Page 53] RFC 5326 LTP - Specification September 2008
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
Copyright (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.
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.
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.
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.
Intellectual Property
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.
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.
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.
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.
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.
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.
Ramadas, et al. Experimental [Page 54]
Ramadas, et al. Experimental [Page 54]
一覧
スポンサーリンク
