[要約] RFC 7016は、AdobeのSecure Real-Time Media Flow Protocol（SRMF）に関する規格です。SRMFは、リアルタイムのメディアストリーミングを安全に転送するためのプロトコルであり、セキュリティとプライバシーの保護を目的としています。
Internet Engineering Task Force (IETF) M. Thornburgh
Request for Comments: 7016 Adobe
Category: Informational November 2013
ISSN: 2070-1721
Adobe's Secure Real-Time Media Flow Protocol
アドビのセキュアリアルタイムメディアフロープロトコル
Abstract
概要
This memo describes Adobe's Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features that make it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used.
このメモは、アドビのセキュアリアルタイムメディアフロープロトコル（RTMFP）について説明しています。これは、IPビデオを介して、リアルタイムのビデオ、オーディオ、データメッセージのパラレルフローとバルクデータを安全に転送するように設計されたエンドポイント間通信プロトコルです。 。 RTMFPには、ネットワークアドレストランスレータ（NAT）が使用されている場合でも、ピアツーピア（P2P）だけでなくクライアント/サーバー通信にも効果的な機能があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 Internet Engineering Steering Group（IESG）による公開が承認されています。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7016.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7016で入手できます。
IESG Note
IESG Note
This document represents technology developed outside the processes of the IETF and the IETF community has determined that it is useful to publish it as an RFC in its current form. It is a product of the IETF only in that it has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG), but the content of the document does not represent a consensus of the IETF.
このドキュメントは、IETFのプロセス外で開発されたテクノロジーを表しており、IETFコミュニティは、現在の形式でRFCとして公開することが有用であると判断しています。これは、IETFの製品であり、パブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されていますが、このドキュメントの内容はIETFの合意を表すものではありません。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントは、RFCとして公開するためにフォーマットしたり、英語以外の言語に翻訳したりする場合を除き、変更したり、その派生物を作成したりすることはできません。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Design Highlights of RTMFP .................................6
1.2. Terminology ................................................7
2. Syntax ..........................................................8
2.1. Common Elements ............................................8
2.1.1. Elementary Types and Constructs .....................8
2.1.2. Variable Length Unsigned Integer (VLU) .............10
2.1.3. Option .............................................10
2.1.4. Option List ........................................11
2.1.5. Internet Socket Address (Address) ..................12
2.2. Network Layer .............................................13
2.2.1. Encapsulation ......................................13
2.2.2. Multiplex ..........................................13
2.2.3. Encryption .........................................14
2.2.4. Packet .............................................15
2.3. Chunks ....................................................18
2.3.1. Packet Fragment Chunk ..............................20
2.3.2. Initiator Hello Chunk (IHello) .....................21
2.3.3. Forwarded Initiator Hello Chunk (FIHello) ..........22
2.3.4. Responder Hello Chunk (RHello) .....................23
2.3.5. Responder Redirect Chunk (Redirect) ................24
2.3.6. RHello Cookie Change Chunk .........................26
2.3.7. Initiator Initial Keying Chunk (IIKeying) ..........27
2.3.8. Responder Initial Keying Chunk (RIKeying) ..........29
2.3.9. Ping Chunk .........................................31
2.3.10. Ping Reply Chunk ..................................32
2.3.11. User Data Chunk ...................................33
2.3.11.1. Options for User Data ....................35
2.3.11.1.1. User's Per-Flow Metadata ......35
2.3.11.1.2. Return Flow Association .......36
2.3.12. Next User Data Chunk ..............................37
2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack) ....39
2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) .....41
2.3.15. Buffer Probe Chunk ................................43
2.3.16. Flow Exception Report Chunk .......................43
2.3.17. Session Close Request Chunk (Close) ...............44
2.3.18. Session Close Acknowledgement Chunk (Close Ack) ...44
3. Operation ......................................................45
3.1. Overview ..................................................45
3.2. Endpoint Identity .........................................46
3.3. Packet Multiplex ..........................................48
3.4. Packet Fragmentation ......................................48
3.5. Sessions ..................................................50
3.5.1. Startup ............................................53
3.5.1.1. Normal Handshake ..........................53
3.5.1.1.1. Initiator ......................54
3.5.1.1.2. Responder ......................55
3.5.1.2. Cookie Change .............................57
3.5.1.3. Glare .....................................59
3.5.1.4. Redirector ................................60
3.5.1.5. Forwarder .................................61
3.5.1.6. Redirector and Forwarder with NAT .........63
3.5.1.7. Load Distribution and Fault Tolerance .....66
3.5.2. Congestion Control .................................67
3.5.2.1. Time Critical Reverse Notification ........68
3.5.2.2. Retransmission Timeout ....................68
3.5.2.3. Burst Avoidance ...........................71
3.5.3. Address Mobility ...................................71
3.5.4. Ping ...............................................72
3.5.4.1. Keepalive .................................72
3.5.4.2. Address Mobility ..........................73
3.5.4.3. Path MTU Discovery ........................74
3.5.5. Close ..............................................74
3.6. Flows .....................................................75
3.6.1. Overview ...........................................75
3.6.1.1. Identity ..................................75
3.6.1.2. Messages and Sequencing ...................76
3.6.1.3. Lifetime ..................................77
3.6.2. Sender .............................................78
3.6.2.1. Startup ...................................80
3.6.2.2. Queuing Data ..............................80
3.6.2.3. Sending Data ..............................81
3.6.2.3.1. Startup Options ................83
3.6.2.3.2. Send Next Data .................83
3.6.2.4. Processing Acknowledgements ...............83
3.6.2.5. Negative Acknowledgement and Loss .........84
3.6.2.6. Timeout ...................................85
3.6.2.7. Abandoning Data ...........................86
3.6.2.7.1. Forward Sequence Number
Update .........................86
3.6.2.8. Examples ..................................87
3.6.2.9. Flow Control ..............................89
3.6.2.9.1. Buffer Probe ...................89
3.6.2.10. Exception ................................89
3.6.2.11. Close ....................................90
3.6.3. Receiver ...........................................90
3.6.3.1. Startup ...................................93
3.6.3.2. Receiving Data ............................94
3.6.3.3. Buffering and Delivering Data .............95
3.6.3.4. Acknowledging Data ........................97
3.6.3.4.1. Timing .........................98
3.6.3.4.2. Size and Truncation ............99
3.6.3.4.3. Constructing ...................99
3.6.3.4.4. Delayed Acknowledgement .......100
3.6.3.4.5. Obligatory Acknowledgement ....100
3.6.3.4.6. Opportunistic
Acknowledgement ...............100
3.6.3.4.7. Example .......................101
3.6.3.5. Flow Control .............................102
3.6.3.6. Receiving a Buffer Probe .................103
3.6.3.7. Rejecting a Flow .........................103
3.6.3.8. Close ....................................104
4. IANA Considerations ...........................................104
5. Security Considerations .......................................105
6. Acknowledgements ..............................................106
7. References ....................................................107
7.1. Normative References .....................................107
7.2. Informative References ...................................107
Appendix A. Example Congestion Control Algorithm .................108
A.1. Discussion ................................................108
A.2. Algorithm .................................................110
Adobe's Secure Real-Time Media Flow Protocol (RTMFP) is intended for use as a general purpose endpoint-to-endpoint data transport service in IP networks. It has features that make it well suited to the transport of real-time media (such as low-delay video, audio, and data) as well as bulk data, and for client-server as well as peer-to-peer (P2P) communication. These features include independent parallel message flows that may have different delivery priorities, variable message reliability (from TCP-like full reliability to UDP-like best effort), multi-point congestion control, and built-in security. Session multiplexing and facilities to support UDP hole-punching simplify Network Address Translator (NAT) traversal in peer-to-peer systems.
アドビのセキュアリアルタイムメディアフロープロトコル（RTMFP）は、IPネットワークでのエンドポイントからエンドポイントへの汎用データ転送サービスとして使用することを目的としています。リアルタイムメディア（低遅延のビデオ、オーディオ、データなど）やバルクデータの転送、およびクライアントサーバーやピアツーピア（P2P）に最適な機能を備えています。 ） コミュニケーション。これらの機能には、さまざまな配信優先順位、さまざまなメッセージ信頼性（TCPのような完全な信頼性からUDPのようなベストエフォートまで）、マルチポイントの輻輳制御、および組み込みのセキュリティがある独立した並列メッセージフローが含まれます。 UDPホールパンチングをサポートするセッションの多重化と機能により、ピアツーピアシステムでのネットワークアドレス変換（NAT）トラバーサルが簡素化されます。
RTMFP is implemented in Flash Player, Adobe Integrated Runtime (AIR), and Adobe Media Server (AMS, formerly Flash Media Server or FMS), all from Adobe Systems Incorporated, and is used as the foundation transport protocol for real-time video, audio, and data communication, both client-server and P2P, in those products. At the time of writing, the Adobe Flash Player runtime is installed on more than one billion end-user desktop computers.
RTMFPは、Flash Player、Adobe Integrated Runtime（AIR）、およびAdobe Media Server（AMS、以前のFlash Media ServerまたはFMS）に実装されており、すべてAdobe Systems Incorporatedから提供されており、リアルタイムビデオ、オーディオの基盤トランスポートプロトコルとして使用されています。 、およびこれらの製品におけるクライアントサーバーとP2Pの両方のデータ通信。執筆時点では、Adobe Flash Playerランタイムは10億台を超えるエンドユーザーのデスクトップコンピューターにインストールされています。
RTMFP was developed by Adobe Systems Incorporated and is not the product of an IETF activity.
RTMFPはAdobe Systems Incorporatedによって開発され、IETFアクティビティの製品ではありません。
This memo describes the syntax and operation of the Secure Real-Time Media Flow Protocol.
このメモは、Secure Real-Time Media Flow Protocolの構文と操作について説明しています。
This memo describes a general security framework that, when combined with an application-specific Cryptography Profile, can be used to establish a confidential and authenticated session between endpoints. The application-specific Cryptography Profile, not defined herein, would detail the specific cryptographic algorithms, data formats, and semantics to be used within this framework. Interoperation between applications of RTMFP requires common or compatible Cryptography Profiles.
このメモは、アプリケーション固有の暗号化プロファイルと組み合わせると、エンドポイント間に機密で認証されたセッションを確立するために使用できる一般的なセキュリティフレームワークについて説明します。ここで定義されていないアプリケーション固有の暗号化プロファイルは、このフレームワーク内で使用される特定の暗号化アルゴリズム、データ形式、およびセマンティクスを詳述します。 RTMFPのアプリケーション間の相互運用には、共通または互換性のある暗号化プロファイルが必要です。
Note to implementers: at the time of writing, the Cryptography Profile used by the above-mentioned Adobe products is not publicly described by Adobe. Implementers should investigate the availability of documentation of that Cryptography Profile prior to implementing RTMFP for the purpose of interoperation with the above-mentioned Adobe products.
実装者への注意：執筆の時点では、上記のアドビ製品で使用される暗号化プロファイルは、アドビによって公に説明されていません。実装者は、上記のアドビ製品との相互運用を目的としてRTMFPを実装する前に、その暗号化プロファイルのドキュメントの可用性を調査する必要があります。
Between any pair of communicating endpoints is a single, bidirectional, secured, congestion controlled session. Unidirectional flows convey messages from one end to the other within the session. An endpoint can have concurrent sessions with multiple other far endpoints.
通信するエンドポイントのペアの間には、単一の双方向の安全な輻輳制御セッションがあります。単方向フローは、セッション内でメッセージを一方の端から他方の端に伝達します。エンドポイントは、他の複数の遠端エンドポイントとの同時セッションを持つことができます。
Design highlights of RTMFP include the following:
RTMFPの設計の要点は次のとおりです。
o The security framework is an inherent part of the basic protocol. The application designer chooses the cryptographic formats and algorithms to suit the needs of the application, and may update them as the state of the security arts progresses.
o セキュリティフレームワークは、基本プロトコルの固有の部分です。アプリケーション設計者は、アプリケーションのニーズに合うように暗号化形式とアルゴリズムを選択し、セキュリティ技術の進歩に応じてそれらを更新します。
o Cryptographic Endpoint Discriminators can resist port scanning.
o 暗号化エンドポイント識別子は、ポートスキャンに抵抗できます。
o All header, control, and framing information, except for network addressing information and a session identifier, is encrypted according to the Cryptography Profile.
o ネットワークアドレッシング情報とセッション識別子を除くすべてのヘッダー、制御、およびフレーミング情報は、暗号化プロファイルに従って暗号化されます。
o There is a single session and associated congestion control state between a pair of endpoints.
o エンドポイントのペア間には、単一のセッションと関連する輻輳制御状態があります。
o Each session may have zero or more unidirectional message-oriented flows in each direction. All of a session's sending flows share the session's congestion control state.
o 各セッションには、各方向に1つ以上の単方向メッセージ指向フローがあります。セッションのすべての送信フローは、セッションの輻輳制御状態を共有します。
o Return Flow Association (Section 2.3.11.1.2) generalizes bidirectional communication to arbitrarily complex trees of flows.
o リターンフローアソシエーション（セクション2.3.11.1.2）は、双方向通信を一般化して、フローの複雑なツリーを任意に作成します。
o Messages in flows can be arbitrarily large and are fragmented for transmission.
o フロー内のメッセージは任意に大きくすることができ、送信用にフラグメント化されます。
o Messages of any size may be sent with full, partial, or no reliability (sender's choice). Messages may be delivered to the receiving user in original queuing order or network arrival order (receiver's choice).
o 任意のサイズのメッセージは、完全、部分的、または信頼性なしで送信できます（送信者の選択）。メッセージは、元のキューイング順またはネットワーク到着順（受信者の選択）で受信ユーザーに配信されます。
o Flows are named with arbitrary, user-defined metadata (Section 2.3.11.1.1) rather than port or stream numbers.
o フローには、ポート番号やストリーム番号ではなく、任意のユーザー定義のメタデータ（セクション2.3.11.1.1）が付けられます。
o The sequence numbers of each flow are independent of all other flows and are not permanently bound to a session-wide transmission ordering. This allows real-time priority decisions to be made at transmission or retransmission time.
o 各フローのシーケンス番号は他のすべてのフローから独立しており、セッション全体の送信順序に永続的にバインドされていません。これにより、送信時または再送信時にリアルタイムの優先度決定を行うことができます。
o Each flow has its own receive window and, therefore, independent flow control.
o 各フローには独自の受信ウィンドウがあるため、独立したフロー制御があります。
o Round trips are expensive and are minimized or eliminated when possible.
o 往復は高価であり、可能であれば最小限に抑えられるか、排除されます。
o After a session is established, flows begin by sending the flow's messages with no additional handshake (and associated round trips).
o セッションが確立されると、フローは、追加のハンドシェイク（および関連する往復）なしでフローのメッセージを送信することから始まります。
o Transmitting bytes on the network is much more expensive than moving bytes in a CPU or memory. Wasted bytes are minimized or eliminated when possible and practical, and variable length encodings are used, even at the expense of breaking 32-bit alignment and making the text diagrams in this specification look awkward.
o ネットワークでバイトを送信することは、CPUやメモリでバイトを移動するよりもはるかにコストがかかります。無駄なバイトは可能な限り実用的に最小化または排除され、可変長エンコーディングが使用されます。ただし、32ビットアライメントを壊し、この仕様のテキスト図を不自然に見せることになります。
o P2P lookup and peer introduction (including UDP hole-punching for NAT and firewall traversal) are supported directly by the session startup handshake.
o P2Pルックアップとピアの導入（NATのUDPホールパンチとファイアウォールトラバーサルを含む）は、セッションスタートアップハンドシェイクによって直接サポートされます。
o Session identifiers allow an endpoint to multiplex many sessions over a single local transport address while allowing sessions to survive changes in transport address (as may happen in mobile or wireless deployments).
o セッション識別子を使用すると、エンドポイントは単一のローカルトランスポートアドレスを介して多くのセッションを多重化でき、セッションはトランスポートアドレスの変更に耐えることができます（モバイルまたはワイヤレスの展開で発生する可能性があります）。
The syntax of the protocol is detailed in Section 2. The operation of the protocol is detailed in Section 3.
プロトコルの構文はセクション2で詳しく説明されています。プロトコルの操作はセクション3で詳しく説明されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Definitions of types and structures in this specification use traditional text diagrams paired with procedural descriptions using a C-like syntax. The C-like procedural descriptions SHALL be construed as definitive.
この仕様のタイプと構造の定義では、Cのような構文を使用した手続き型の説明と対になっている従来のテキスト図を使用します。 Cのような手続き型の記述は、決定的なものとして解釈されるべきです。
Structures are packed to take only as many bytes as explicitly indicated. There is no 32-bit alignment constraint, and fields are not padded for alignment unless explicitly indicated or described. Text diagrams may include a bit ruler across the top; this is a convenience for counting bits in individual fields and does not necessarily imply field alignment on a multiple of the ruler width.
構造体は、明示的に示されているバイト数だけを使用するようにパックされます。 32ビットのアライメント制約はなく、明示的に指定または説明されていない限り、フィールドはアライメントのためにパディングされません。テキスト図には上部にビット定規が含まれている場合があります。これは、個々のフィールドのビットをカウントするのに便利であり、ルーラー幅の倍数でのフィールドの整列を必ずしも意味しません。
Unless specified otherwise, reserved fields SHOULD be set to 0 by a sender and MUST be ignored by a receiver.
特に明記しない限り、予約済みフィールドは送信者によって0に設定されるべきで（SHOULD）、受信者によって無視されなければならない（MUST）。
The procedural syntax of this specification defines correct and error-free encoded inputs to a parser. The procedural syntax does not describe a fully featured parser, including error detection and handling. Implementations MUST include means to identify error circumstances, including truncations causing elementary or composed types to not fit inside containing structures, fields, or elements. Unless specified otherwise, an error circumstance SHALL abort the parsing and processing of an element and its enclosing elements, up to the containing packet.
この仕様の手続き型構文は、パーサーへの正しくエラーのないエンコードされた入力を定義します。手続き型構文は、エラーの検出と処理を含む、完全に機能するパーサーを記述していません。実装には、エラーの状況を特定する手段が含まれていなければなりません。これには、基本型または構成型が構造、フィールド、または要素の中に収まらない原因となる切り捨てが含まれます。特に明記されていない限り、エラー状況は、要素とその包含要素の解析と処理を、含まれるパケットまで中止するものとします（SHALL）。
This section lists types and structures that are used throughout this specification.
このセクションでは、この仕様全体で使用されるタイプと構造をリストします。
This section lists the elementary types and constructs out of which all of the following sections' definitions are built.
このセクションでは、以下のセクションの定義がすべて構築される基本タイプと構成をリストします。
uint8_t var;
uint8_t var;
An unsigned integer 8 bits (one byte) in length and byte aligned.
長さ8バイト（1バイト）の符号なし整数。バイト境界で整列。
uint16_t var;
uint16_t var;
An unsigned integer 16 bits in length, in network byte order ("big endian") and byte aligned.
ネットワークバイトオーダー（「ビッグエンディアン」）でバイトアラインされた、長さが16ビットの符号なし整数。
uint32_t var;
uint32_t var;
An unsigned integer 32 bits in length, in network byte order and byte aligned.
32バイト長の符号なし整数。ネットワークバイトオーダーで、バイト境界で整列されます。
uint128_t var;
uint128_t var;
An unsigned integer 128 bits in length, in network byte order and byte aligned.
128バイト長の符号なし整数。ネットワークバイトオーダーで、バイト境界で整列されます。
uintn_t var :bitsize;
uint_t var：bitesize;
An unsigned integer of any other size, potentially not byte aligned. Its size in bits is specified explicitly by bitsize.
その他のサイズの符号なし整数で、バイト境界整列されていない可能性があります。ビット単位のサイズは、ビットサイズによって明示的に指定されます。
bool_t var :1;
bool_t var：1;
A boolean flag having the value true (1 or set) or false (0 or clear) and being one bit in length.
true（1またはセット）またはfalse（0またはクリア）の値を持ち、長さが1ビットのブール値フラグ。
type var[num];
タイプvar [num];
A packed array of type with length num*sizeof(type)*8 bits.
長さがnum * sizeof（type）* 8ビットのタイプのパックされた配列。
struct name_t { ... } name :bitsize;
A packed structure. Its size in bits is specified by bitsize.
パック構造。ビット単位のサイズは、bitesizeで指定されます。
remainder();
残り();
The number of bytes from the current offset to the end of the enclosing structure.
現在のオフセットからそれを囲む構造の最後までのバイト数。
type var[remainder()];
タイプvar [remainder()];
A packed array of type, its size extending to the end of the enclosing structure.
タイプのパックされた配列で、そのサイズは囲んでいる構造体の最後まで拡張されます。
Note that a bitsize of "variable" indicates that the size of the structure is determined by the sizes of its interior components. A bitsize of "n*8" indicates that the size of the structure is a whole number of bytes and is byte aligned.
「変数」のビットサイズは、構造のサイズが内部コンポーネントのサイズによって決定されることを示していることに注意してください。 「n * 8」のビットサイズは、構造体のサイズがバイトの整数であり、バイト境界で整列されていることを示します。
A VLU encodes any finite non-negative integer into one or more bytes. For each encoded byte, if the high bit is set, the next byte is also part of the VLU. If the high bit is clear, this is the final byte of the VLU. The remaining bits encode the number, seven bits at a time, from most significant to least significant.
VLUは、非負の有限整数を1バイト以上にエンコードします。エンコードされたバイトごとに、上位ビットが設定されている場合、次のバイトもVLUの一部です。上位ビットがクリアされている場合、これはVLUの最後のバイトです。残りのビットは、一度に7ビットずつ、最上位から最下位までの数をエンコードします。
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+~+~+~+~+~+~+~+~+ +-+-+-+-+-+-+-+-+
|1| digit |...............|0| digit |
+~+~+~+~+~+~+~+~+ +-+-+-+-+-+-+-+-+
^ ^
+--------- zero or more --------+
struct vlu_t
{
value = 0;
do {
bool_t more :1;
uintn_t digit :7;
value = (value * 128) + digit;
} while(more);
} :variable*8;
+-------------/-+
| \ |
+-------------/-+
Figure 1: VLU Depiction in Following Diagrams
図1：次の図のVLUの説明
Unless stated otherwise in this specification, implementations SHOULD handle VLUs encoding unsigned integers at least 64 bits in length (that is, encoding a maximum value of at least 2^64 - 1).
この仕様で特に明記されていない限り、実装は、少なくとも64ビット長の符号なし整数をエンコードする（つまり、最大値を2 ^ 64-1にエンコードする）VLUを処理する必要があります（SHOULD）。
An Option is a Length-Type-Value triplet. Length and Type are encoded in VLU format. Length is the number of bytes of payload following the Length field. The payload comprises the Type and Value fields. Type identifies the kind of option this is. The syntax of the Value field is determined by the type of option.
オプションは、Length-Type-Valueトリプレットです。長さとタイプはVLU形式でエンコードされます。長さは、長さフィールドに続くペイロードのバイト数です。ペイロードは、タイプフィールドと値フィールドで構成されます。 Typeは、このオプションの種類を識別します。 「値」フィールドの構文は、オプションのタイプによって決まります。
An Option can have a length of zero, in which case it has no type and no value and is empty. An empty Option is called a "Marker".
Optionの長さは0にすることができます。その場合、タイプも値もなく、空です。空のオプションは「マーカー」と呼ばれます。
+-------------/-+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| length \ | type \ | value |
+-------------/-+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
^ ^
+-------- length bytes long (may be 0) ---------+
struct option_t
{
vlu_t length :variable*8; // "L"
if(length > 0)
{
struct {
vlu_t type :variable*8; // "T"
uint8_t value[remainder()]; // "V"
} payload :length*8;
}
} :variable*8;
+---/---/-------+
| L \ T \ V |
+---/---/-------+
Figure 2: Option Depiction in Following Diagrams
図2：次の図のオプションの説明
An Option List is a sequence of zero or more non-empty Options terminated by a Marker.
オプションリストは、マーカーで終了する0個以上の空でないオプションのシーケンスです。
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+-------------/-+
| L \ T \ V |...............| L \ T \ V | 0 \ |
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+-------------/-+
^ ^ Marker
+------- zero or more non-empty Options --------+ (empty Option)
struct optionList_t
{
do
{
option_t option :variable*8;
} while(option.length > 0);
} :variable*8;
When communicating an Internet socket address (a combination of a 32-bit IPv4 [RFC0791] or 128-bit IPv6 [RFC2460] address and a 16-bit port number) to another RTMFP, this encoding is used. This encoding additionally allows an address to be tagged with an origin type, which an RTMFP MAY use to modify the use or disposition of the address.
インターネットソケットアドレス（32ビットIPv4 [RFC0791]または128ビットIPv6 [RFC2460]アドレスと16ビットポート番号の組み合わせ）を別のRTMFPに通信する場合、このエンコーディングが使用されます。このエンコーディングはさらに、RTMFPがアドレスの使用または処理を変更するために使用できる発信元タイプでタグを付けることができるようにします。
1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-----/.../-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| | O | Internet | |
|P|0 0 0 0 0| R | address | port |
|6| rsv | I |32 or 128 bits | |
+-+-+-+-+-+-+-+-+-----/.../-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
struct address_t
{
bool_t inet6 :1; // "IP6"
uintn_t reserved :5 = 0; // "rsv"
uintn_t origin :2; // "ORI"
if(inet6)
uint128_t ipAddress;
else
uint32_t ipAddress;
uint16_t port;
} :variable*8;
inet6: If set, the Internet address is a 128-bit IPv6 address. If clear, the Internet address is a 32-bit IPv4 address.
inet6：設定されている場合、インターネットアドレスは128ビットのIPv6アドレスです。クリアされている場合、インターネットアドレスは32ビットのIPv4アドレスです。
origin: The origin tag of this address. Possible values are:
origin：この住所の起点タグ。可能な値は次のとおりです。
0: Unknown, unspecified, or "other"
0：不明、不特定、または「その他」
1: Address was reported by the origin as a local, directly attached interface address
1：アドレスは、発信元によってローカルの直接接続されたインターフェイスアドレスとして報告されました
2: Address was observed to be the source address from which a packet was received (a "reflexive transport address" in the terminology of [RFC5389])
2：アドレスは、パケットの受信元のソースアドレスであることが確認されました（[RFC5389]の用語では「再帰トランスポートアドレス」）。
3: Address is a relay, proxy, or introducer (a Redirector and/or Forwarder)
3：アドレスはリレー、プロキシ、またはイントロデューサ（リダイレクタおよび/またはフォワーダ）です
ipAddress: The Internet address, in network byte order.
ipAddress：ネットワークバイト順のインターネットアドレス。
port: The 16-bit port number, in network byte order.
port：16ビットのポート番号（ネットワークバイト順）。
RTMFP Multiplex packets are usually carried in UDP [RFC0768] datagrams so that they may transit commonly deployed NATs and firewalls, and so that RTMFP may be implemented on commonly deployed operating systems without special privileges or permissions.
RTMFPマルチプレックスパケットは通常、UDP [RFC0768]データグラムで運ばれるため、一般に展開されているNATとファイアウォールを通過でき、RTMFPは、特別な特権や権限なしで一般に展開されているオペレーティングシステムに実装できます。
RTMFP Multiplex packets MAY be carried by any suitable datagram transport or encapsulation where endpoints are addressed by an Internet socket address (that is, an IPv4 or IPv6 address and a 16-bit port number).
RTMFPマルチプレックスパケットは、エンドポイントがインターネットソケットアドレス（つまり、IPv4またはIPv6アドレスと16ビットのポート番号）でアドレス指定される、適切なデータグラムトランスポートまたはカプセル化によって伝送される場合があります。
The choice of port numbers is not mandated by this specification. Higher protocol layers or the application define the port numbers used.
ポート番号の選択は、この仕様では必須ではありません。上位のプロトコル層またはアプリケーションが、使用されるポート番号を定義します。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scrambled Session ID (SSID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| e first32[0] |
|- - - - - - n - - - - - - - - - - - - - - - - - - - - - - - -|
| c first32[1] |
+- - - - - - r - - - - - - - - - - - - - - - - - - - - - - - -+
| y |
| pted packet |
+---------------------------------------------------------------/
struct multiplex_t
{
uint32_t scrambledSessionID; // "SSID"
union {
uint32_t first32[2]; // see note
uint8_t encryptedPacket[remainder()];
} :(encapsulation.length - 4)*8;
// if encryptedPacket is less than 8 bytes long, treat it
// as if it were end-padded with 0s for the following:
sessionID = scrambledSessionID XOR first32[0] XOR first32[1];
} :encapsulation.length*8;
The 32-bit Scrambled Session ID is the 32-bit session ID modified by performing a bitwise exclusive-or with the bitwise exclusive-or of the first two 32-bit words of the encrypted packet.
32ビットのスクランブルセッションIDは、暗号化されたパケットの最初の2つの32ビットワードのビット単位の排他的論理和またはビット単位の排他的論理和を実行することによって変更された32ビットセッションIDです。
The session ID is a 32-bit value that the receiver has requested to be used by the sender when sending packets to this receiver (Sections 2.3.7 and 2.3.8). The session ID identifies the session to which this packet belongs and the decryption key to be used to decrypt the encrypted packet.
セッションIDは、この受信者にパケットを送信するときに送信者が使用するように受信者が要求した32ビット値です（セクション2.3.7および2.3.8）。セッションIDは、このパケットが属するセッションと、暗号化されたパケットを復号化するために使用される復号化キーを識別します。
Note: Session ID 0 (prior to scrambling) denotes the startup pseudo-session and implies the Default Session Key.
注：セッションID 0（スクランブリング前）は、スタートアップ疑似セッションを示し、デフォルトセッションキーを意味します。
Note: If the encrypted packet is less than 8 bytes long, then for the scrambling operation, perform the exclusive-or as though the encrypted packet were end-padded with enough 0-bytes to bring its length to 8.
注：暗号化されたパケットの長さが8バイト未満の場合は、スクランブル操作のために、exclusive-orを実行します。暗号化されたパケットが、その長さを8にするために十分な0バイトでパディングされているかのように。
RTMFP packets are encrypted according to a Cryptography Profile. This specification doesn't define a Cryptography Profile or mandate a particular choice of cryptography. The application defines the cryptographic syntax and algorithms.
RTMFPパケットは、暗号化プロファイルに従って暗号化されます。この仕様は、暗号化プロファイルを定義しておらず、暗号化の特定の選択を義務付けていません。アプリケーションは、暗号の構文とアルゴリズムを定義します。
Packet encryption is RECOMMENDED to be a block cipher operating in Cipher Block Chaining [CBC] or similar mode. Encrypted packets MUST be decipherable without inter-packet dependency, since packets may be lost, duplicated, or reordered in the network.
パケット暗号化は、Cipher Block Chaining [CBC]または同様のモードで動作するブロック暗号であることが推奨されます。暗号化されたパケットは、パケットがネットワーク内で失われたり、複製されたり、並べ替えられたりする可能性があるため、パケット間の依存関係なしに解読可能である必要があります。
The packet encryption layer is responsible for data integrity and authenticity of packets, for example by means of a checksum or cryptographic message authentication code. To mitigate replay attacks, data integrity SHOULD comprise duplicate packet detection, for example by means of a session-wide packet sequence number. The packet encryption layer SHALL discard a received packet that does not pass integrity or authenticity tests.
パケット暗号化層は、たとえばチェックサムまたは暗号メッセージ認証コードを使用して、データの整合性とパケットの信頼性を担います。リプレイ攻撃を軽減するために、データ整合性は、たとえばセッション全体のパケットシーケンス番号による重複パケット検出を含む必要があります。パケット暗号化層は、完全性または信頼性テストに合格しない受信パケットを破棄するものとします（SHALL）。
Note that the structures described below are of plain, unencrypted packets. Encrypted packets MUST be decrypted according to the Session Key associated with the Multiplex Session ID before being interpreted according to this specification.
以下で説明する構造は、暗号化されていない単純なパケットであることに注意してください。暗号化されたパケットは、この仕様に従って解釈される前に、マルチプレックスセッションIDに関連付けられたセッションキーに従って復号化する必要があります。
The Cryptography Profile defines a well-known Default Session Key that is used at session startup, during which per-session key(s) are negotiated by the two endpoints. A session ID of zero denotes use of the Default Session Key. The Default Session Key is also used with non-zero session IDs during the latter phases of session startup (Sections 2.3.6 and 2.3.8). See Security Considerations (Section 5) for more about the Default Session Key.
暗号化プロファイルは、セッション開始時に使用される既知のデフォルトセッションキーを定義します。このセッション中に、セッションごとのキーが2つのエンドポイントによってネゴシエートされます。ゼロのセッションIDは、デフォルトセッションキーの使用を示します。デフォルトセッションキーは、セッション起動の後のフェーズ（セクション2.3.6および2.3.8）でゼロ以外のセッションIDとともに使用されます。デフォルトセッションキーの詳細については、セキュリティに関する考慮事項（セクション5）を参照してください。
An (unencrypted, plain) RTMFP packet consists of a variable sized common header, zero or more chunks, and padding. Padding can be inserted by the encryption layer of the sender to meet cipher block size constraints and is ignored by the receiver. A sender's encryption layer MAY pad the end of a packet with bytes with value 0xff such that the resulting packet is a natural and appropriate size for the cipher. Alternatively, the Cryptography Profile MAY define its own framing and padding scheme, if needed, such that decrypted packets are compatible with the syntax defined in this section.
（暗号化されていない、プレーンな）RTMFPパケットは、可変サイズの共通ヘッダー、0個以上のチャンク、およびパディングで構成されます。パディングは、暗号化ブロックサイズの制約を満たすために送信者の暗号化層によって挿入でき、受信者は無視します。送信者の暗号化層は、結果のパケットが暗号にとって自然で適切なサイズになるように、値0xffのバイトでパケットの終わりを埋めてもよい（MAY）。あるいは、暗号化プロファイルは、必要に応じて、独自のフレーミングおよびパディング方式を定義してもよい（MAY）。これにより、復号されたパケットは、このセクションで定義された構文と互換性があります。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|T|T| r |T|T| M |
|C|C| s |S|S| O |
| |R| v | |E| D |
+-+-+-+-+-+-+-+-+
+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
| if(TS) timestamp | if(TSE) timestampEcho |
+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Chunk |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
:
:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Chunk |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| padding |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct packet_t
{
bool_t timeCritical :1; // "TC"
bool_t timeCriticalReverse :1; // "TCR"
uintn_t reserved :2; // "rsv"
bool_t timestampPresent :1; // "TS"
bool_t timestampEchoPresent :1; // "TSE"
uintn_t mode :2; // "MOD"
if(0 != mode)
{
if(timestampPresent)
uint16_t timestamp;
if(timestampEchoPresent)
uint16_t timestampEcho;
while(remainder() > 2)
{
uint8_t chunkType;
uint16_t chunkLength;
if(remainder() < chunkLength)
break;
uint8_t chunkPayload[chunkLength];
} // chunks
uint8_t padding[remainder()];
}
} :plainPacket.length*8;
timeCritical: Time Critical Forward Notification. If set, indicates that this packet contains real-time user data.
timeCritical：時間クリティカル転送通知。設定されている場合、このパケットにリアルタイムのユーザーデータが含まれていることを示します。
timeCriticalReverse: Time Critical Reverse Notification. If set, indicates that the sender is currently receiving packets on other sessions that have the timeCritical flag set.
timeCriticalReverse：タイムクリティカルなリバース通知。設定されている場合、送信者が現在timeCriticalフラグが設定されている他のセッションでパケットを受信していることを示します。
timestampPresent: If set, indicates that the timestamp field is present. If clear, there is no timestamp field.
timestampPresent：設定されている場合、タイムスタンプフィールドが存在することを示します。クリアされている場合、タイムスタンプフィールドはありません。
timestampEchoPresent: If set, indicates that the timestamp echo field is present. If clear, there is no timestamp echo field.
timestampEchoPresent：設定されている場合、タイムスタンプエコーフィールドが存在することを示します。クリアされている場合、タイムスタンプエコーフィールドはありません。
mode: The mode of this packet. See below for additional discussion of packet modes. Possible values are:
mode：このパケットのモード。パケットモードの詳細については、以下を参照してください。可能な値は次のとおりです。
0: Forbidden value
0：禁止値
1: Initiator Mark
1：イニシエーターマーク
2: Responder Mark
2：応答者マーク
3: Startup
3：スタートアップ
timestamp: If the timestampPresent flag is set, this field is present and contains the low 16 bits of the sender's 250 Hz clock (4 milliseconds per tick) at transmit time. The sender's clock MAY have its origin at any time in the past.
timestamp：timestampPresentフラグが設定されている場合、このフィールドが存在し、送信時の送信者の250 Hzクロック（ティックあたり4ミリ秒）の下位16ビットが含まれます。送信者の時計は、過去のいつでもその起源を持っているかもしれません。
timestampEcho: If the timestampEchoPresent flag is set, this field is present and contains the sender's estimate of what the timestamp field of a packet received from the other end would be at the time this packet was transmitted, using the method described in Section 3.5.2.2.
timestampEcho：timestampEchoPresentフラグが設定されている場合、このフィールドが存在し、セクション3.5.2.2で説明されている方法を使用して、このパケットが送信されたときに相手側から受信したパケットのタイムスタンプフィールドがどうなるかについての送信者の推定が含まれます。 。
chunks: Zero or more chunks follow the header. It is RECOMMENDED that a packet contain at least one chunk.
チャンク：0個以上のチャンクがヘッダーの後に続きます。パケットには少なくとも1つのチャンクが含まれていることが推奨されます。
padding: Zero or more bytes of padding follow the chunks. The following conditions indicate padding:
パディング：チャンクの後に0バイト以上のパディングが続きます。次の条件はパディングを示します。
* Fewer than three bytes (the size of a chunk header) remain in the packet.
* 3バイト未満（チャンクヘッダーのサイズ）がパケットに残ります。
* The chunkLength field of what would be the current chunk header indicates that the hypothetical chunk payload wouldn't fit in the remaining bytes of the packet.
* 現在のチャンクヘッダーのchunkLengthフィールドは、仮想チャンクペイロードがパケットの残りのバイトに収まらないことを示しています。
Packet mode 0 is not allowed. Packets marked with this mode are invalid and MUST be discarded.
パケットモード0は許可されていません。このモードでマークされたパケットは無効であり、破棄する必要があります。
The original initiator of a session MUST mark all non-startup packets it sends in that session with packet mode 1 ("Initiator Mark"). It SHOULD ignore any packet received in that session with packet mode 1.
セッションの元のイニシエーターは、そのセッションで送信するすべての非スタートアップパケットをパケットモード1（「イニシエーターマーク」）でマークする必要があります。パケットモード1のセッションで受信したパケットはすべて無視する必要があります（SHOULD）。
The original responder of a session MUST mark all non-startup packets it sends in that session with packet mode 2 ("Responder Mark"). It SHOULD ignore any packet received in that session with packet mode 2.
セッションの元のレスポンダは、そのセッションで送信するすべての非スタートアップパケットをパケットモード2（「レスポンダマーク」）でマークする必要があります。パケットモード2のセッションで受信したパケットはすべて無視する必要があります。
Packet mode 3 is for session startup. Session startup chunks are only allowed in packets with this mode.
パケットモード3はセッションの起動用です。セッション開始チャンクは、このモードのパケットでのみ許可されます。
Chunks that are not for session startup are only allowed in packets with modes 1 or 2.
セッションの起動用ではないチャンクは、モード1または2のパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunkType | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| chunkPayload (chunkLength bytes, may be zero) |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct chunk_t
{
uint8_t chunkType;
uint16_t chunkLength;
uint8_t chunkPayload[chunkLength];
} :variable*8;
chunkType: The chunk type code.
chunkType：チャンクタイプコード。
chunkLength: The size, in bytes, of the chunk payload.
chunkLength：チャンクペイロードのサイズ（バイト単位）。
chunkPayload: The type-specific payload of this chunk, chunkLength bytes in length (may be empty).
chunkPayload：このチャンクのタイプ固有のペイロード、chunkLengthバイトの長さ（空の場合があります）。
Defined chunk types are enumerated here in the order they might be encountered in the course of a typical session. The following chunk type codes are defined:
定義されたチャンクタイプは、一般的なセッション中に遭遇する可能性がある順序でここに列挙されています。次のチャンクタイプコードが定義されています。
0x7f: Packet Fragment (Section 2.3.1)
0x7f：パケットフラグメント（セクション2.3.1）
0x30: Initiator Hello (Section 2.3.2)
0x30：イニシエーターこんにちは（セクション2.3.2）
0x0f: Forwarded Initiator Hello (Section 2.3.3)
0x0f：Forwarded Initiator Hello（セクション2.3.3）
0x70: Responder Hello (Section 2.3.4)
0x70：応答側Hello（セクション2.3.4）
0x71: Responder Redirect (Section 2.3.5)
0x71：レスポンダリダイレクト（セクション2.3.5）
0x79: RHello Cookie Change (Section 2.3.6)
0x79：RHello Cookieの変更（セクション2.3.6）
0x38: Initiator Initial Keying (Section 2.3.7)
0x38：イニシエーターの初期キーイング（セクション2.3.7）
0x78: Responder Initial Keying (Section 2.3.8)
0x78：Responder Initial Keying（セクション2.3.8）
0x01: Ping (Section 2.3.9)
0x01：Ping（セクション2.3.9）
0x41: Ping Reply (Section 2.3.10)
0x41：Ping応答（セクション2.3.10）
0x10: User Data (Section 2.3.11)
0x10：ユーザーデータ（セクション2.3.11）
0x11: Next User Data (Section 2.3.12)
0x11：次のユーザーデータ（セクション2.3.12）
0x50: Data Acknowledgement Bitmap (Section 2.3.13)
0x50：データ確認ビットマップ（セクション2.3.13）
0x51: Data Acknowledgement Ranges (Section 2.3.14)
0x51：データ確認応答範囲（セクション2.3.14）
0x18: Buffer Probe (Section 2.3.15)
0x18：バッファプローブ（セクション2.3.15）
0x5e: Flow Exception Report (Section 2.3.16)
0x5e：フロー例外レポート（セクション2.3.16）
0x0c: Session Close Request (Section 2.3.17)
0x0c：セッション終了リクエスト（セクション2.3.17）
0x4c: Session Close Acknowledgement (Section 2.3.18)
0x4c：セッション終了の確認（セクション2.3.18）
0x00: Ignore/Padding
0x00：無視/パディング
0xff: Ignore/Padding
0xff：無視/パディング
A receiver MUST ignore a chunk having an unrecognized chunk type code. A receiver MUST ignore a chunk appearing in a packet having a mode inappropriate to that chunk type.
受信者は、認識されていないチャンクタイプコードを持つチャンクを無視する必要があります。受信者は、そのチャンクタイプに不適切なモードを持つパケットに現れるチャンクを無視しなければなりません（MUST）。
Unless specified otherwise, if a chunk has a syntax or processing error (for example, the chunk's payload field is not long enough to contain the specified syntax elements), the chunk SHALL be ignored as though it was not present in the packet, and parsing and processing SHALL commence with the next chunk in the packet, if any.
特に明記されていない限り、チャンクに構文エラーまたは処理エラーがある場合（たとえば、チャンクのペイロードフィールドが指定された構文要素を含めるのに十分な長さでない場合）、チャンクはパケットに存在しないかのように無視され、解析されます（SHALL）。そして、もしあれば、パケット内の次のチャンクから処理を開始する必要があります。
This chunk is used to divide a plain RTMFP packet (Section 2.2.4) that is unavoidably larger than the path MTU (such as session startup packets containing Responder Hello (Section 2.3.4) or Initiator Initial Keying (Section 2.3.7) chunks with large certificates) into segments that do not exceed the path MTU, and to allow the segments to be sent through the network at a moderated rate to avoid jamming interfaces, links, or paths.
このチャンクは、パスMTU（Responder Hello（セクション2.3.4）またはInitiator Initial Keying（セクション2.3.7）チャンクを含むセッション起動パケットなど）を避けられないサイズのプレーンなRTMFPパケット（セクション2.2.4）を分割するために使用されますパスのMTUを超えないセグメントに分割し、セグメントが適度な速度でネットワークを介して送信されるようにして、インターフェース、リンク、またはパスの妨害を回避します。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x7f | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-------------/-+-------------/-+
|M| reserved | packetID \ | fragmentNum \ |
+-+-+-+-+-+-+-+-+-------------/-+-------------/-+
+---------------------------------------------------------------+
| packetFragment |
+---------------------------------------------------------------/
struct fragmentChunkPayload_t
{
bool_t moreFragments :1; // M
uintn_t reserved :7;
vlu_t packetID :variable*8;
vlu_t fragmentNum :variable*8;
uint8_t packetFragment[remainder()];
} :chunkLength*8;
moreFragments: If set, the indicated packet comprises additional fragments. If clear, this fragment is the final fragment of the packet.
moreFragments：設定されている場合、示されたパケットは追加のフラグメントを含みます。クリアの場合、このフラグメントはパケットの最後のフラグメントです。
reserved: Reserved for future use.
reserved：将来使用するために予約されています。
packetID: VLU, the identifier of this segmented packet. All fragments of the same packet have the same packetID.
packetID：VLU、このセグメント化されたパケットの識別子。同じパケットのすべてのフラグメントは同じpacketIDを持っています。
fragmentNum: VLU, the index of this fragment of the indicated packet. The first fragment of the packet MUST be index 0. Fragments are numbered consecutively.
fragmentNum：VLU、指定されたパケットのこのフラグメントのインデックス。パケットの最初のフラグメントはインデックス0である必要があります。フラグメントは連続して番号が付けられます。
packetFragment: The bytes of the indicated segment of the indicated original plain RTMFP packet. A packetFragment MUST NOT be empty.
packetFragment：指定された元のプレーンRTMFPパケットの指定されたセグメントのバイト。 packetFragmentを空にすることはできません。
The use of this mechanism is detailed in Section 3.4.
このメカニズムの使用については、セクション3.4で詳しく説明します。
This chunk is sent by the initiator of a new session to begin the startup handshake. This chunk is only allowed in a packet with Session ID 0, encrypted with the Default Session Key, and having packet mode 3 (Startup).
このチャンクは、スタートアップハンドシェイクを開始するために、新しいセッションの開始者によって送信されます。このチャンクは、セッションID 0、デフォルトセッションキーで暗号化され、パケットモード3（スタートアップ）のパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x30 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+
| epdLength \ | endpointDiscriminator (epdLength bytes) |
+-------------/-+-----------------------------------------------/
+---------------------------------------------------------------+
| tag |
+---------------------------------------------------------------/
struct ihelloChunkPayload_t
{
vlu_t epdLength :variable*8;
uint8_t endpointDiscriminator[epdLength];
uint8_t tag[remainder()];
} :chunkLength*8;
epdLength: VLU, the length of the following endpointDiscriminator field in bytes.
epdLength：VLU、次のendpointDiscriminatorフィールドの長さ（バイト単位）。
endpointDiscriminator: The Endpoint Discriminator for the identity with which the initiator wants to communicate.
endpointDiscriminator：イニシエーターが通信するIDのエンドポイントディスクリミネーター。
tag: Initiator-provided data to be returned in a Responder Hello's tagEcho field. The tag/tagEcho is used to match Responder Hellos to the initiator's session startup state independent of the responder's address.
tag：イニシエーターが提供するデータで、レスポンダのHelloのtagEchoフィールドに返されます。 tag / tagEchoは、レスポンダーのアドレスに関係なく、レスポンダーのHelloをイニシエーターのセッション起動状態に一致させるために使用されます。
The use of IHello is detailed in Section 3.5.1.
IHelloの使用については、セクション3.5.1で詳しく説明しています。
This chunk is sent on behalf of an initiator by a Forwarder. It is only allowed in packets of an established session having packet mode 1 or 2. A receiver MAY treat this chunk as though it was an Initiator Hello received directly from replyAddress. Alternatively, if the receiver is selected by the Endpoint Discriminator, it MAY respond to replyAddress with an Implied Redirect (Section 2.3.5).
このチャンクは、フォワーダーによってイニシエーターに代わって送信されます。これは、パケットモード1または2の確立されたセッションのパケットでのみ許可されます。受信者は、このチャンクを、ReplyAddressから直接受信されたInitiator Helloであるかのように処理できます。あるいは、受信者がEndpoint Discriminatorによって選択された場合、暗黙のリダイレクト（セクション2.3.5）でreplyAddressに応答する場合があります。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0f | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+
| epdLength \ | endpointDiscriminator (epdLength bytes) |
+-------------/-+-----------------------------------------------/
+---------------------------------------------------------------+
| replyAddress |
+---------------------------------------------------------------/
+---------------------------------------------------------------+
| tag |
+---------------------------------------------------------------/
struct fihelloChunkPayload_t
{
vlu_t epdLength :variable*8;
uint8_t endpointDiscriminator[epdLength];
address_t replyAddress :variable*8;
uint8_t tag[remainder()];
} :chunkLength*8;
epdLength: VLU, the length of the following endpointDiscriminator field in bytes.
epdLength：VLU、次のendpointDiscriminatorフィールドの長さ（バイト単位）。
endpointDiscriminator: The Endpoint Discriminator for the identity with which the original initiator wants to communicate, copied from the original Initiator Hello.
endpointDiscriminator：元のイニシエーターHelloからコピーされた、元のイニシエーターが通信するIDのエンドポイントディスクリミネーター。
replyAddress: Address format (Section 2.1.5), the address that the forwarding node derived from the received Initiator Hello, to which the receiver should respond.
replyAddress：アドレス形式（セクション2.1.5）。受信側が応答する必要がある、受信したInitiator Helloから転送ノードが取得したアドレス。
tag: Copied from the original Initiator Hello.
タグ：元のイニシエーターこんにちはからコピー。
The use of FIHello is detailed in Section 3.5.1.5.
FIHelloの使用については、セクション3.5.1.5で詳しく説明しています。
This chunk is sent by a responder in response to an Initiator Hello or Forwarded Initiator Hello if the Endpoint Discriminator indicates the responder's identity. This chunk is only allowed in a packet with Session ID 0, encrypted with the Default Session Key, and having packet mode 3 (Startup).
このチャンクは、Endpoint DiscriminatorがレスポンダのIDを示している場合、Initiator HelloまたはForwarded Initiator Helloに応答してレスポンダによって送信されます。このチャンクは、セッションID 0、デフォルトセッションキーで暗号化され、パケットモード3（スタートアップ）のパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x70 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+
| tagLength \ | tagEcho (tagLength bytes) |
+-------------/-+-----------------------------------------------/
+-------------/-+-----------------------------------------------+
| cookieLength\ | cookie (cookieLength bytes) |
+-------------/-+-----------------------------------------------/
+---------------------------------------------------------------+
| responderCertificate |
+---------------------------------------------------------------/
struct rhelloChunkPayload_t
{
vlu_t tagLength :variable*8;
uint8_t tagEcho[tagLength];
vlu_t cookieLength :variable*8;
uint8_t cookie[cookieLength];
uint8_t responderCertificate[remainder()];
} :chunkLength*8;
tagLength: VLU, the length of the following tagEcho field in bytes.
tagLength：VLU、次のtagEchoフィールドの長さ（バイト単位）。
tagEcho: The tag from the Initiator Hello, unaltered.
tagEcho：イニシエーターこんにちは、変更されていないタグ。
cookieLength: VLU, the length of the following cookie field in bytes.
cookieLength：VLU、次のcookieフィールドの長さ（バイト単位）。
cookie: Responder-created state data to authenticate a future Initiator Initial Keying message (in order to prevent denial-of-service attacks).
cookie：将来のイニシエーター初期キーメッセージを認証するためにレスポンダーが作成した状態データ（サービス拒否攻撃を防ぐため）。
responderCertificate: The responder's cryptographic credentials.
responderCertificate：レスポンダーの暗号化資格。
Note: This specification doesn't mandate a specific choice of certificate format. The Cryptography Profile determines the syntax, algorithms, and interpretation of the responderCertificate.
注：この仕様では、証明書形式の特定の選択を義務付けていません。暗号化プロファイルは、responderCertificateの構文、アルゴリズム、および解釈を決定します。
The use of RHello is detailed in Section 3.5.1.
RHelloの使用については、セクション3.5.1で詳しく説明しています。
This chunk is sent in response to an Initiator Hello or Forwarded Initiator Hello to indicate that the requested endpoint can be reached at one or more of the indicated addresses. A receiver can add none, some, or all of the indicated addresses to the set of addresses to which it is sending Initiator Hello messages for the opening session associated with tagEcho. This chunk is only allowed in a packet with Session ID 0, encrypted with the Default Session Key, and having packet mode 3 (Startup).
このチャンクは、Initiator HelloまたはForwarded Initiator Helloに応答して送信され、指定されたアドレスの1つ以上で要求されたエンドポイントに到達できることを示します。レシーバーは、tagEchoに関連付けられた開始セッションのイニシエーターHelloメッセージを送信するアドレスのセットに、示されたアドレスの一部またはすべてを追加することができます。このチャンクは、セッションID 0、デフォルトセッションキーで暗号化され、パケットモード3（スタートアップ）のパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x71 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+
| tagLength \ | tagEcho (tagLength bytes) |
+-------------/-+-----------------------------------------------/
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| redirectDestination 1 |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
:
:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| redirectDestination N |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct responderRedirectChunkPayload_t
{
vlu_t tagLength :variable*8;
uint8_t tagEcho[tagLength];
addressCount = 0;
while(remainder() > 0)
{
address_t redirectDestination :variable*8;
addressCount++;
}
if(0 == addressCount)
redirectDestination = packetSourceAddress();
} :chunkLength*8;
tagLength: VLU, the length of the following tagEcho field in bytes.
tagLength：VLU、次のtagEchoフィールドの長さ（バイト単位）。
tagEcho: The tag from the Initiator Hello, unaltered.
tagEcho：イニシエーターこんにちは、変更されていないタグ。
redirectDestination: (Zero or more) Address format (Section 2.1.5) addresses to add to the opening set for the indicated session.
redirectDestination：（ゼロ以上）指定されたセッションの開始セットに追加するアドレス形式（セクション2.1.5）。
If this chunk lists zero redirectDestination addresses, then this is an Implied Redirect, and the indicated address is the address from which the packet containing this chunk was received.
このチャンクがゼロのredirectDestinationアドレスをリストしている場合、これは暗黙のリダイレクトであり、示されたアドレスは、このチャンクを含むパケットの受信元のアドレスです。
The use of Redirect is detailed in Sections 3.5.1.1.1, 3.5.1.1.2, and 3.5.1.4.
リダイレクトの使用については、セクション3.5.1.1.1、3.5.1.1.2、および3.5.1.4で詳しく説明しています。
This chunk SHOULD be sent by a responder to an initiator in response to an Initiator Initial Keying if that chunk's cookie appears to have been created by the responder but the cookie is incorrect (for example, it includes a hash of the initiator's address, but the initiator's address is different than the one that elicited the Responder Hello containing the original cookie).
このチャンクは、そのチャンクのCookieがレスポンダによって作成されたように見えても、Cookieが正しくない場合（たとえば、イニシエータのアドレスのハッシュが含まれているが、イニシエーターのアドレスは、元のCookieを含むレスポンダーHelloを引き出したアドレスとは異なります）。
This chunk is only allowed in a packet encrypted with the Default Session Key and having packet mode 3, and with the session ID indicated in the initiatorSessionID field of the Initiator Initial Keying to which this is a response.
このチャンクは、デフォルトセッションキーで暗号化され、パケットモード3で暗号化されたパケット、およびこれが応答であるイニシエーター初期キーのInitiatorSessionIDフィールドに示されたセッションIDでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x79 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+
| oldCookieLen\ | oldCookie (oldCookieLen bytes) |
+-------------/-+-----------------------------------------------/
+---------------------------------------------------------------+
| newCookie |
+---------------------------------------------------------------/
struct rhelloCookieChangeChunkPayload_t
{
vlu_t oldCookieLen :variable*8;
uint8_t oldCookie[oldCookieLen];
uint8_t newCookie[remainder()];
} :chunkLength*8;
oldCookieLen: VLU, the length of the following oldCookie field in bytes.
oldCookieLen：VLU、次のoldCookieフィールドの長さ（バイト単位）。
oldCookie: The cookie that was sent in a previous Responder Hello and Initiator Initial Keying.
oldCookie：以前のレスポンダーのHelloおよびイニシエーターの初期キーで送信されたCookie。
newCookie: The new cookie that the responder would like sent (and signed) in a replacement Initiator Initial Keying. The old and new cookies need not have the same lengths.
newCookie：レスポンダが代わりのイニシエーター初期キーで送信（および署名）したい新しいCookie。新旧のクッキーは同じ長さである必要はありません。
On receipt of this chunk, the initiator SHOULD compute, sign, and send a new Initiator Initial Keying having newCookie in place of oldCookie. The use of this chunk is detailed in Section 3.5.1.2.
このチャンクを受け取ると、イニシエーターはoldCookieの代わりにnewCookieを持つ新しいイニシエーター初期キーを計算、署名、および送信する必要があります（SHOULD）。このチャンクの使用については、セクション3.5.1.2で詳しく説明しています。
This chunk is sent by an initiator to establish a session with a responder. The initiator MUST have obtained a valid cookie to use with the responder, typically by receiving a Responder Hello from it. This chunk is only allowed in a packet with Session ID 0, encrypted with the Default Session Key, and having packet mode 3 (Startup).
このチャンクは、レスポンダとのセッションを確立するためにイニシエータによって送信されます。イニシエータは、通常、レスポンダHelloを受信して、レスポンダで使用する有効なCookieを取得している必要があります。このチャンクは、セッションID 0、デフォルトセッションキーで暗号化され、パケットモード3（スタートアップ）のパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x38 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| initiatorSessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+
| cookieLength\ | cookieEcho |
+-------------/-+-----------------------------------------------/
+-------------/-+-----------------------------------------------+
| certLength \ | initiatorCertificate |
+-------------/-+-----------------------------------------------/
+-------------/-+-----------------------------------------------+
| skicLength \ | sessionKeyInitiatorComponent |
+-------------/-+-----------------------------------------------/
+---------------------------------------------------------------+
| signature |
+---------------------------------------------------------------/
struct iikeyingChunkPayload_t
{
struct
{
uint32_t initiatorSessionID;
vlu_t cookieLength :variable*8;
uint8_t cookieEcho[cookieLength];
vlu_t certLength :variable*8;
uint8_t initiatorCertificate[certLength];
vlu_t skicLength :variable*8;
uint8_t sessionKeyInitiatorComponent[skicLength];
} initiatorSignedParameters :variable*8;
uint8_t signature[remainder()];
} :chunkLength*8;
initiatorSessionID: The session ID to be used by the responder when sending packets to the initiator.
initiatorSessionID：パケットをイニシエーターに送信するときにレスポンダーが使用するセッションID。
cookieLength: VLU, the length of the following cookieEcho field in bytes.
cookieLength：VLU、次のcookieEchoフィールドの長さ（バイト単位）。
cookieEcho: The cookie from the Responder Hello, unaltered.
cookieEcho：レスポンダHelloからのcookieで、変更されません。
certLength: VLU, the length of the following initiatorCertificate field in bytes.
certLength：VLU、次の発信者Certificateフィールドの長さ（バイト単位）。
initiatorCertificate: The initiator's identity credentials.
initiatorCertificate：イニシエーターのID資格情報。
skicLength: VLU, the length of the following sessionKeyInitiatorComponent field in bytes.
skicLength：VLU、次のsessionKeyInitiatorComponentフィールドの長さ（バイト単位）。
sessionKeyInitiatorComponent: The initiator's portion of the session key negotiation according to the Cryptography Profile.
sessionKeyInitiatorComponent：暗号化プロファイルによるセッションキーネゴシエーションの開始者の部分。
initiatorSignedParameters: The payload portion of this chunk up to the signature field.
initiatorSignedParameters：このチャンクのペイロード部分から署名フィールドまで。
signature: The initiator's digital signature of the initiatorSignedParameters according to the Cryptography Profile.
signature：暗号化プロファイルに従った、initiatorSignedParametersのイニシエーターのデジタル署名。
Note: This specification doesn't mandate a specific choice of cryptography. The Cryptography Profile determines the syntax, algorithms, and interpretation of the initiatorCertificate, responderCertificate, sessionKeyInitiatorComponent, sessionKeyResponderComponent, and signature, and how the sessionKeyInitiatorComponent and sessionKeyResponderComponent are combined to derive the session keys.
注：この仕様は、暗号化の特定の選択を義務付けるものではありません。暗号化プロファイルは、initiatorCertificate、responderCertificate、sessionKeyInitiatorComponent、sessionKeyResponderComponent、および署名の構文、アルゴリズム、解釈、およびsessionKeyInitiatorComponentとsessionKeyResponderComponentを組み合わせてセッションキーを取得する方法を決定します。
The use of IIKeying is detailed in Section 3.5.1.
IIKeyingの使用については、セクション3.5.1で詳しく説明しています。
This chunk is sent by a responder in response to an Initiator Initial Keying as the final phase of session startup. This chunk is only allowed in a packet encrypted with the Default Session Key, having packet mode 3 (Startup), and sent to the initiator with the session ID specified by the initiatorSessionID field from the Initiator Initial Keying.
このチャンクは、セッション開始の最終フェーズとして、イニシエーター初期キーに応答してレスポンダによって送信されます。このチャンクは、デフォルトのセッションキーで暗号化され、パケットモード3（スタートアップ）のパケットでのみ許可され、イニシエーター初期キーからの発信者セッションIDフィールドで指定されたセッションIDで発信者に送信されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x78 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| responderSessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-----------------------------------------------+
| skrcLength \ | sessionKeyResponderComponent |
+-------------/-+-----------------------------------------------/
+---------------------------------------------------------------+
| signature |
+---------------------------------------------------------------/
struct rikeyingChunkPayload_t
{
struct
{
uint32_t responderSessionID;
vlu_t skrcLength :variable*8;
uint8_t sessionKeyResponderComponent[skrcLength];
} responderSignedParametersPortion :variable*8;
uint8_t signature[remainder()];
} :chunkLength*8;
struct
{
responderSignedParametersPortion;
sessionKeyInitiatorComponent;
} responderSignedParameters;
responderSessionID: The session ID to be used by the initiator when sending packets to the responder.
responderSessionID：応答側にパケットを送信するときに開始側が使用するセッションID。
skrcLength: VLU, the length of the following sessionKeyResponderComponent field in bytes.
skrcLength：VLU、後続のsessionKeyResponderComponentフィールドの長さ（バイト単位）。
sessionKeyResponderComponent: The responder's portion of the session key negotiation according to the Cryptography Profile.
sessionKeyResponderComponent：暗号化プロファイルによるセッションキーネゴシエーションのレスポンダの部分。
responderSignedParametersPortion: The payload portion of this chunk up to the signature field.
responderSignedParametersPortion：このチャンクのペイロード部分から署名フィールドまで。
signature: The responder's digital signature of the responderSignedParameters (see below) according to the Cryptography Profile.
署名：暗号化プロファイルに基づくレスポンダーのレスポンダーのデジタル署名（以下を参照）。
responderSignedParameters: The concatenation of the responderSignedParametersPortion (the payload portion of this chunk up to the signature field) and the sessionKeyInitiatorComponent from the Initiator Initial Keying to which this chunk is a response.
responderSignedParameters：responderSignedParametersPortion（このチャンクのペイロード部分から署名フィールドまで）と、このチャンクが応答するInitiator Initial KeyingからのsessionKeyInitiatorComponentの連結。
Note: This specification doesn't mandate a specific choice of cryptography. The Cryptography Profile determines the syntax, algorithms, and interpretation of the initiatorCertificate, responderCertificate, sessionKeyInitiatorComponent, sessionKeyResponderComponent, and signature, and how the sessionKeyInitiatorComponent and sessionKeyResponderComponent are combined to derive the session keys.
注：この仕様は、暗号化の特定の選択を義務付けるものではありません。暗号化プロファイルは、initiatorCertificate、responderCertificate、sessionKeyInitiatorComponent、sessionKeyResponderComponent、および署名の構文、アルゴリズム、解釈、およびsessionKeyInitiatorComponentとsessionKeyResponderComponentを組み合わせてセッションキーを取得する方法を決定します。
Once the responder has computed the sessionKeyResponderComponent, it has all of the information and state necessary for an established session with the initiator. Once the responder has sent this chunk to the initiator, the session is established and ready to carry flows of user data.
レスポンダがsessionKeyResponderComponentを計算すると、イニシエータとの確立されたセッションに必要なすべての情報と状態が得られます。レスポンダがこのチャンクをイニシエータに送信すると、セッションが確立され、ユーザーデータのフローを伝送する準備が整います。
Once the initiator receives, verifies, and processes this chunk, it has all of the information and state necessary for an established session with the responder. The session is established and ready to carry flows of user data.
イニシエーターは、このチャンクを受信、検証、および処理すると、レスポンダーとの確立されたセッションに必要なすべての情報と状態を取得します。セッションが確立され、ユーザーデータのフローを伝送する準備が整います。
The use of RIKeying is detailed in Section 3.5.1.
RIKeyingの使用については、セクション3.5.1で詳しく説明しています。
This chunk is sent in order to elicit a Ping Reply from the receiver. It is only allowed in a packet belonging to an established session and having packet mode 1 or 2.
このチャンクは、受信側からPing応答を引き出すために送信されます。確立されたセッションに属し、パケットモードが1または2のパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| message |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct pingChunkPayload_t
{
uint8_t message[chunkLength];
} :chunkLength*8;
message: The (potentially empty) message that is expected to be returned by the other end of the session in a Ping Reply.
メッセージ：セッションのもう一方の端からPing応答で返されると予想される（潜在的に空の）メッセージ。
The receiver of this chunk SHOULD reply as immediately as is practical with a Ping Reply.
このチャンクの受信者は、Ping応答を使用してできるだけ早く応答する必要があります（SHOULD）。
Ping and the expected Ping Reply are typically used for session keepalive, endpoint address change verification, and path MTU discovery. See Section 3.5.4 for details.
Pingと予想されるPing応答は、通常、セッションキープアライブ、エンドポイントアドレス変更の検証、およびパスMTUディスカバリに使用されます。詳細については、セクション3.5.4を参照してください。
This chunk is sent in response to a Ping chunk. It is only allowed in a packet belonging to an established session and having packet mode 1 or 2.
このチャンクは、Pingチャンクへの応答として送信されます。確立されたセッションに属し、パケットモードが1または2のパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x41 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| messageEcho |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct pingReplyChunkPayload_t
{
uint8_t messageEcho[chunkLength];
} :chunkLength*8;
messageEcho: The message from the Ping to which this is a response, unaltered.
messageEcho：これが応答であるPingからのメッセージ。変更されません。
This chunk is the basic unit of transmission for the user messages of a flow. A user message comprises one or more fragments. Each fragment is carried in its own chunk and has a unique sequence number in its flow. It is only allowed in a packet belonging to an established session and having packet mode 1 or 2.
このチャンクは、フローのユーザーメッセージの送信の基本単位です。ユーザーメッセージは、1つ以上のフラグメントで構成されます。各フラグメントは独自のチャンクで運ばれ、フロー内で一意のシーケンス番号を持ちます。確立されたセッションに属し、パケットモードが1または2のパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|O|r| F | r |A|F|
|P|s| R | s |B|I|
|T|v| A | v |N|N|
+-+-+-+-+-+-+-+-+
+-------------/-+-------------/-+-------------/-+
| flowID \ | seq# \ | fsnOffset \ |
+-------------/-+-------------/-+-------------/-+
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+-------------/-+
| L \ T \ V |... options ...| L \ T \ V | 0 \ |
\~~~/~~~/~~~~~~~+ [if(OPT)] +~~~/~~~/~~~~~~~+-------------/-/
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| userData |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct userDataChunkPayload_t
{
bool_t optionsPresent :1; // "OPT"
uintn_t reserved1 :1; // "rsv"
uintn_t fragmentControl :2; // "FRA"
// 0=whole, 1=begin, 2=end, 3=middle
uintn_t reserved2 :2; // "rsv"
bool_t abandon :1; // "ABN"
bool_t final :1; // "FIN"
vlu_t flowID :variable*8;
vlu_t sequenceNumber :variable*8; // "seq#"
vlu_t fsnOffset :variable*8;
forwardSequenceNumber = sequenceNumber - fsnOffset;
if(optionsPresent)
optionList_t options :variable*8;
uint8_t userData[remainder()];
} :chunkLength*8;
optionsPresent: If set, indicates the presence of an option list before the user data. If clear, there is no option list in this chunk.
optionsPresent：設定されている場合、ユーザーデータの前にオプションリストが存在することを示します。クリアされている場合、このチャンクにはオプションリストはありません。
fragmentControl: Indicates how this fragment is assembled, potentially with others, into a complete user message. Possible values:
fragmentControl：このフラグメントが、他のユーザーと一緒に、完全なユーザーメッセージにアセンブルされる方法を示します。可能な値：
0: This fragment is a complete message.
0：このフラグメントは完全なメッセージです。
1: This fragment is the first of a multi-fragment message.
1：このフラグメントは、マルチフラグメントメッセージの最初のものです。
2: This fragment is the last of a multi-fragment message.
2：このフラグメントは、マルチフラグメントメッセージの最後です。
3: This fragment is in the middle of a multi-fragment message.
3：このフラグメントは、マルチフラグメントメッセージの途中にあります。
A single-fragment user message has a fragment control of "0-whole". When a message has more than one fragment, the first fragment has a fragment control of "1-begin", then zero or more "3-middle" fragments, and finally a "2-end" fragment. The sequence numbers of a multi-fragment message MUST be contiguous.
単一フラグメントのユーザーメッセージには、「0全体」のフラグメントコントロールがあります。メッセージに複数のフラグメントがある場合、最初のフラグメントには「1-begin」、次に0個以上の「3-middle」フラグメント、最後に「2-end」フラグメントのフラグメントコントロールがあります。マルチフラグメントメッセージのシーケンス番号は連続している必要があります。
abandon: If set, this sequence number has been abandoned by the sender. The userData, if any, MUST be ignored.
abandon：設定されている場合、このシーケンス番号は送信者によって破棄されています。 userData（ある場合）は無視する必要があります。
final: If set, this is the last sequence number of the flow.
final：設定されている場合、これはフローの最後のシーケンス番号です。
flowID: VLU, the flow identifier.
flowID：VLU、フロー識別子。
sequenceNumber: VLU, the sequence number of this fragment. Fragments are assigned contiguous increasing sequence numbers in a flow. The first sequence number of a flow SHOULD be 1. The first sequence number of a flow MUST be greater than zero. Sequence numbers are unbounded and do not wrap.
sequenceNumber：VLU、このフラグメントのシーケンス番号。フラグメントには、フロー内で連続する増加するシーケンス番号が割り当てられます。フローの最初のシーケンス番号は1である必要があります（SHOULD）。フローの最初のシーケンス番号はゼロより大きい必要があります。シーケンス番号には制限がなく、折り返されません。
fsnOffset: VLU, the difference between the sequence number and the Forward Sequence Number. This field MUST NOT be zero if the abandon flag is not set. This field MUST NOT be greater than sequenceNumber.
fsnOffset：VLU、シーケンス番号と転送シーケンス番号の違い。放棄フラグが設定されていない場合、このフィールドはゼロであってはなりません。このフィールドは、sequenceNumberより大きくてはいけません。
forwardSequenceNumber: The flow sender will not send (or resend) any fragment with a sequence number less than or equal to the Forward Sequence Number.
forwardSequenceNumber：フロー送信側は、転送シーケンス番号以下のシーケンス番号を持つフラグメントを送信（または再送信）しません。
options: If the optionsPresent flag is set, a list of zero or more Options terminated by a Marker is present. See Section 2.3.11.1 for defined options.
options：optionsPresentフラグが設定されている場合、マーカーで終了する0個以上のオプションのリストが存在します。定義されているオプションについては、セクション2.3.11.1を参照してください。
userData: The actual user data for this fragment.
userData：このフラグメントの実際のユーザーデータ。
The use of User Data is detailed in Section 3.6.2.
ユーザーデータの使用については、セクション3.6.2で詳しく説明しています。
This section lists options that may appear in User Data option lists. A conforming implementation MUST support the options in this section.
このセクションでは、ユーザーデータオプションリストに表示されるオプションを示します。準拠する実装は、このセクションのオプションをサポートする必要があります。
A flow receiver MUST reject a flow containing a flow option that is not understood if the option type is less than 8192 (0x2000). A flow receiver MUST ignore any flow option that is not understood if the option type is 8192 or greater.
フローレシーバーは、オプションタイプが8192（0x2000）未満の場合に理解されないフローオプションを含むフローを拒否する必要があります。フローレシーバーは、オプションタイプが8192以上の場合、理解できないフローオプションを無視する必要があります。
The following option type codes are defined for User Data:
次のオプションタイプコードは、ユーザーデータに対して定義されています。
0x00: User's Per-Flow Metadata (Section 2.3.11.1.1)
0x00：ユーザーのフローごとのメタデータ（セクション2.3.11.1.1）
0x0a: Return Flow Association (Section 2.3.11.1.2)
0x0a：Return Flow Association（セクション2.3.11.1.2）
This option conveys the user's per-flow metadata for the flow to which it's attached.
このオプションは、アタッチされているフローのフローごとのユーザーのメタデータを伝えます。
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| length \ | 0x00 \ | userMetadata |
+-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct userMetadataOptionValue_t
{
uint8_t userMetadata[remainder()];
} :remainder()*8;
The user associates application-defined metadata with each flow. The metadata does not change over the life of the flow. Every flow MUST have metadata. A flow sender MUST send this option with the first User Data chunk for this flow in each packet until an acknowledgement for this flow is received. A flow sender SHOULD NOT send this option more than once for each flow in any one packet. A flow sender SHOULD NOT send this option for a flow once the flow has been acknowledged.
ユーザーは、アプリケーション定義のメタデータを各フローに関連付けます。メタデータはフローの存続期間を通じて変更されません。すべてのフローにはメタデータが必要です。フローの送信者は、このフローの確認応答が受信されるまで、各パケットでこのフローの最初のユーザーデータチャンクとともにこのオプションを送信する必要があります。フローセンダーは、1つのパケットの各フローに対してこのオプションを複数回送信してはなりません（SHOULD NOT）。フローが確認されると、フロー送信者はフローに対してこのオプションを送信してはなりません（SHOULD NOT）。
This specification doesn't mandate the encoding, syntax, or interpretation of the user's per-flow metadata; this is determined by the application.
この仕様は、ユーザーのフローごとのメタデータのエンコード、構文、または解釈を義務付けていません。これはアプリケーションによって決定されます。
The userMetadata SHOULD NOT exceed 512 bytes. The userMetadata MAY be 0 bytes in length.
userMetadataは512バイトを超えてはなりません（SHOULD NOT）。 userMetadataの長さは0バイトである場合があります。
A new flow can be considered to be in return (or response) to a flow sent by the other endpoint. This option encodes the receive flow identifier to which this new sending flow is a response.
新しいフローは、他のエンドポイントによって送信されたフローの見返り（または応答）であると見なすことができます。このオプションは、この新しい送信フローが応答である受信フロー識別子をエンコードします。
+-------------/-+-------------/-+-------------/-+
| length \ | 0x0a \ | flowID \ |
+-------------/-+-------------/-+-------------/-+
struct returnFlowAssociationOptionValue_t
{
vlu_t flowID :variable*8;
} :variable*8;
Consider endpoints A and B. Endpoint A begins a flow with identifier 5 to endpoint B. A is the flow sender for A's flowID=5, and B is the flow receiver for A's flowID=5. B begins a return flow with identifier 7 to A in response to A's flowID=5. B is the flow sender for B's flowID=7, and A is the flow receiver for B's flowID=7. B sends this option with flowID set to 5 to indicate that B's flowID=7 is in response to and associated with A's flowID=5.
エンドポイントAとBを考えます。エンドポイントAは、エンドポイントBへの識別子5でフローを開始します。AはAのflowID = 5のフローセンダーであり、BはAのflowID = 5のフローレシーバーです。 Bは、AのflowID = 5に応答して、識別子7からAへの戻りフローを開始します。 BはBのflowID = 7のフローセンダーであり、AはBのflowID = 7のフローレシーバーです。 Bは、flowIDを5に設定してこのオプションを送信し、BのflowID = 7がAのflowID = 5に応答して関連付けられていることを示します。
If there is a return association, the flow sender MUST send this option with the first User Data chunk for this flow in each packet until an acknowledgement for this flow is received. A flow sender SHOULD NOT send this option more than once for each flow in any one packet. A flow sender SHOULD NOT send this option for a flow once the flow has been acknowledged.
リターンアソシエーションがある場合、フロー送信者は、このフローの確認応答が受信されるまで、各パケットでこのフローの最初のユーザーデータチャンクとともにこのオプションを送信する必要があります。フローセンダーは、1つのパケットの各フローに対してこのオプションを複数回送信してはなりません（SHOULD NOT）。フローが確認されると、フロー送信者はフローに対してこのオプションを送信してはなりません（SHOULD NOT）。
A flow MUST NOT indicate more than one return association.
フローは、複数のリターンアソシエーションを示してはなりません。
A flow MUST indicate its return association, if any, upon its first transmission of a User Data chunk. A return association can't be added to a sending flow after it begins.
フローは、ユーザーデータチャンクの最初の送信時に、もしあれば、その関連付けを示す必要があります。リターンアソシエーションは、開始後に送信フローに追加することはできません。
A flow receiver MUST reject a new receiving flow having a return flow association that does not indicate an F_OPEN sending flow.
フローレシーバーは、F_OPEN送信フローを示さないリターンフローアソシエーションを持つ新しい受信フローを拒否する必要があります。
This chunk is equivalent to the User Data chunk for purposes of sending the user messages of a flow. When used, it MUST follow a User Data chunk or another Next User Data chunk in the same packet.
このチャンクは、フローのユーザーメッセージを送信するためのユーザーデータチャンクに相当します。使用する場合、同じパケット内のユーザーデータチャンクまたは別の次のユーザーデータチャンクを追跡する必要があります。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x11 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|O|r| F | r |A|F|
|P|s| R | s |B|I|
|T|v| A | v |N|N|
+-+-+-+-+-+-+-+-+
+~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+-------------/-+
| L \ T \ V |... options ...| L \ T \ V | 0 \ |
\~~~/~~~/~~~~~~~+ [if(OPT)] +~~~/~~~/~~~~~~~+-------------/-/
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| userData |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct nextUserDataChunkPayload_t
{
bool_t optionsPresent :1; // "OPT"
uintn_t reserved1 :1; // "rsv"
uintn_t fragmentControl :2; // "FRA"
// 0=whole, 1=begin, 2=end, 3=middle
uintn_t reserved2 :2; // "rsv"
bool_t abandon :1; // "ABN"
bool_t final :1; // "FIN"
if(optionsPresent)
optionList_t options :variable*8;
uint8_t userData[remainder()];
} :chunkLength*8;
This chunk is considered to be for the same flowID as the most recently preceding User Data or Next User Data chunk in the same packet, having the same Forward Sequence Number, and having the next sequence number. The optionsPresent, fragmentControl, abandon, and final flags, and the options (if present), have the same interpretation as for the User Data chunk.
このチャンクは、同じパケット内の直前のユーザーデータチャンクまたは次のユーザーデータチャンクと同じflowIDで、同じ順方向シーケンス番号を持ち、次のシーケンス番号を持つものと見なされます。 optionsPresent、fragmentControl、abandon、finalフラグ、およびオプション（存在する場合）の解釈は、ユーザーデータチャンクの場合と同じです。
...
----------+------------------------------------
10 00 07 | User Data chunk, length=7
00 | OPT=0, FRA=0 "whole", ABN=0, FIN=0
02 05 03 | flowID=2, seq#=5, fsn=(5-3)=2
00 01 02 | data 3 bytes: 00, 01, 02
----------+------------------------------------
11 00 04 | Next User Data chunk,length=4
00 | OPT=0, FRA=0 "whole", ABN=0, FIN=0
| flowID=2, seq#=6, fsn=2
03 04 05 | data 3 bytes: 03, 04, 05
----------+------------------------------------
11 00 04 | Next User Data chunk, length=4
00 | OPT=0, FRA=0 "whole", ABN=0, FIN=0
| flowID=2, seq#=7, fsn=2
06 07 08 | data 3 bytes: 06, 07, 08
----------+------------------------------------
Figure 3: Sequential Messages in One Packet Using Next User Data
図3：次のユーザーデータを使用した1つのパケット内の順次メッセージ
The use of Next User Data is detailed in Section 3.6.2.3.2.
次のユーザーデータの使用については、セクション3.6.2.3.2で詳しく説明しています。
This chunk is sent by the flow receiver to indicate to the flow sender the User Data fragment sequence numbers that have been received for one flow. It is only allowed in a packet belonging to an established session and having packet mode 1 or 2.
このチャンクは、フローレシーバーによって送信され、1つのフローで受信されたユーザーデータフラグメントシーケンス番号をフローセンダーに示します。確立されたセッションに属し、パケットモードが1または2のパケットでのみ許可されます。
The flow receiver can choose to acknowledge User Data with this chunk or with a Range Ack. It SHOULD choose whichever format has the most compact encoding of the sequence numbers received.
フローレシーバーは、このチャンクまたはRange Ackでユーザーデータを確認することを選択できます。受信したシーケンス番号の最もコンパクトなエンコーディングを持つフォーマットを選択する必要があります。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x50 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-------------/-+-------------/-+
| flowID \ | bufAvail \ | cumAck \ |
+-------------/-+-------------/-+-------------/-+
+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|
|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|
|9|8|7|6|5|4|3|2|1|1|1|1|1|1|1|1|2|2|2|2|2|2|1|1| ....
| | | | | | | | |7|6|5|4|3|2|1|0|5|4|3|2|1|0|9|8|
+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
struct dataAckBitmapChunkPayload_t
{
vlu_t flowID :variable*8;
vlu_t bufferBlocksAvailable :variable*8; // "bufAvail"
vlu_t cumulativeAck :variable*8; // "cumAck"
bufferBytesAvailable = bufferBlocksAvailable * 1024;
acknowledge(0 through cumulativeAck);
ackCursor = cumulativeAck + 1;
while(remainder() > 0)
{
for(bitPosition = 8; bitPosition > 0; bitPosition--)
{
bool_t bit :1;
if(bit)
acknowledge(ackCursor + bitPosition);
}
ackCursor += 8;
}
} :chunkLength*8;
flowID: VLU, the flow identifier.
flowID：VLU、フロー識別子。
bufferBlocksAvailable: VLU, the number of 1024-byte blocks of User Data that the receiver is currently able to accept. Section 3.6.3.5 describes how to calculate this value.
bufferBlocksAvailable：VLU、受信者が現在受け入れることができるユーザーデータの1024バイトブロックの数。セクション3.6.3.5では、この値の計算方法について説明します。
cumulativeAck: VLU, the acknowledgement of every fragment sequence number in this flow that is less than or equal to this value. This MUST NOT be less than the highest Forward Sequence Number received in this flow.
incrementalAck：VLU、この値以下のこのフロー内のすべてのフラグメントシーケンス番号の確認。これは、このフローで受信した最高の転送シーケンス番号よりも小さくてはなりません。
bit field: A sequence of zero or more bytes representing a bit field of received fragment sequence numbers after the cumulative acknowledgement, least significant bit first. A set bit indicates receipt of a sequence number. A clear bit indicates that sequence number was not received. The least significant bit of the first byte is the second sequence number following the cumulative acknowledgement, the next bit is the third sequence number following, and so on.
ビットフィールド：累積確認応答後の受信フラグメントシーケンス番号のビットフィールドを表す0バイト以上のシーケンス。最下位ビットが最初。セットビットはシーケンス番号の受信を示します。クリアビットは、シーケンス番号が受信されなかったことを示します。最初のバイトの最下位ビットは、累積確認応答に続く2番目のシーケンス番号、次のビットは、それに続く3番目のシーケンス番号です。
Figure 4 shows an example Bitmap Ack indicating acknowledgement of fragment sequence numbers 0 through 16, 18, 21 through 24, 27, and 28.
図4は、フラグメントシーケンス番号0〜16、18、21〜24、27、28の確認応答を示すビットマップAckの例を示しています。
50 00 05 | Bitmap Ack, length=5 bytes
05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16
79 06 | 01111001 00000110 = 18, 21, 22, 23, 24, 27, 28
Figure 4: Example Bitmap Ack
図4：ビットマップ確認の例
This chunk is sent by the flow receiver to indicate to the flow sender the User Data fragment sequence numbers that have been received for one flow. It is only allowed in a packet belonging to an established session and having packet mode 1 or 2.
このチャンクは、フローレシーバーによって送信され、1つのフローで受信されたユーザーデータフラグメントシーケンス番号をフローセンダーに示します。確立されたセッションに属し、パケットモードが1または2のパケットでのみ許可されます。
The flow receiver can choose to acknowledge User Data with this chunk or with a Bitmap Ack. It SHOULD choose whichever format has the most compact encoding of the sequence numbers received.
フローレシーバーは、このチャンクまたはビットマップACKでユーザーデータを確認することを選択できます。受信したシーケンス番号の最もコンパクトなエンコーディングを持つフォーマットを選択する必要があります。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x51 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-------------/-+-------------/-+
| flowID \ | bufAvail \ | cumAck \ |
+-------------/-+-------------/-+-------------/-+
+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~/~+
| #holes-1 \ | #recv-1 \ |
+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~/~+
:
:
+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~/~+
| #holes-1 \ | #recv-1 \ |
+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~/~+
struct dataAckRangesChunkPayload_t
{
vlu_t flowID :variable*8;
vlu_t bufferBlocksAvailable :variable*8; // "bufAvail"
vlu_t cumulativeAck :variable*8; // "cumAck"
bufferBytesAvailable = bufferBlocksAvailable * 1024;
acknowledge(0 through cumulativeAck);
ackCursor = cumulativeAck;
while(remainder() > 0)
{
vlu_t holesMinusOne :variable*8; // "#holes-1"
vlu_t receivedMinusOne :variable*8; // "#recv-1"
ackCursor++;
rangeFrom = ackCursor + holesMinusOne + 1;
rangeTo = rangeFrom + receivedMinusOne;
acknowledge(rangeFrom through rangeTo);
ackCursor = rangeTo;
}
} :chunkLength*8;
flowID: VLU, the flow identifier.
flowID：VLU、フロー識別子。
bufferBlocksAvailable: VLU, the number of 1024-byte blocks of User Data that the receiver is currently able to accept. Section 3.6.3.5 describes how to calculate this value.
bufferBlocksAvailable：VLU、受信者が現在受け入れることができるユーザーデータの1024バイトブロックの数。セクション3.6.3.5では、この値の計算方法について説明します。
cumulativeAck: VLU, the acknowledgement of every fragment sequence number in this flow that is less than or equal to this value. This MUST NOT be less than the highest Forward Sequence Number received in this flow.
incrementalAck：VLU、この値以下のこのフロー内のすべてのフラグメントシーケンス番号の確認。これは、このフローで受信した最高の転送シーケンス番号よりも小さくてはなりません。
holesMinusOne / receivedMinusOne: Zero or more acknowledgement ranges, run-length encoded. Runs are encoded as zero or more pairs of VLUs indicating the number (minus one) of missing sequence numbers followed by the number (minus one) of received sequence numbers, starting at the cumulative acknowledgement. NOTE: If a parser syntax error is encountered here (that is, if the chunk is truncated such that not enough bytes remain to completely encode both VLUs of the acknowledgement range), then treat and process this chunk as though it was properly formed up to the last completely encoded range.
holesMinusOne / receivedMinusOne：ゼロ以上の確認応答範囲、ランレングスエンコード。実行は、欠落したシーケンス番号の数（マイナス1）に続いて、受信したシーケンス番号の数（マイナス1）を示すVLUのゼロ以上のペアとしてエンコードされ、累積確認から始まります。注：パーサー構文エラーがここで発生した場合（つまり、確認応答範囲の両方のVLUを完全にエンコードするのに十分なバイトが残っていないようにチャンクが切り捨てられた場合）、このチャンクが正しく形成されたかのように扱い、処理最後の完全にエンコードされた範囲。
Figure 5 shows an example Range Ack indicating acknowledgement of fragment sequence numbers 0 through 16, 18, 21, 22, 23, and 24.
図5は、フラグメントシーケンス番号0〜16、18、21、22、23、および24の確認応答を示すRange Ackの例を示しています。
51 00 07 | Range Ack, length=7
05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16
00 00 | holes=1, received=1 -- missing 17, received 18
01 03 | holes=2, received=4 -- missing 19..20, received 21..24
Figure 5: Example Range Ack
図5：範囲確認の例
Figure 6 shows an example Range Ack indicating acknowledgement of fragment sequence numbers 0 through 16 and 18, with a truncated last range. Note that the truncation and parse error does not abort the entire chunk in this case.
図6は、最後の範囲が切り捨てられたフラグメントシーケンス番号0〜16および18の確認応答を示す範囲ACKの例を示しています。この場合、切り捨てと解析のエラーはチャンク全体を中止しないことに注意してください。
51 00 07 | Range Ack, length=9
05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16
00 00 | holes=1, received=1 -- missing 17, received 18
01 83 | holes=2, received=VLU parse error, ignore this range
Figure 6: Example Truncated Range Ack
図6：切り捨てられた範囲の確認の例
This chunk is sent by the flow sender in order to request the current available receive buffer (in the form of a Data Acknowledgement) for a flow. It is only allowed in a packet belonging to an established session and having packet mode 1 or 2.
このチャンクは、フローの現在利用可能な受信バッファー（データ確認応答の形式）を要求するために、フローセンダーによって送信されます。確立されたセッションに属し、パケットモードが1または2のパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x18 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+
| flowID \ |
+-------------/-+
struct bufferProbeChunkPayload_t
{
vlu_t flowID :variable*8;
} :chunkLength*8;
flowID: VLU, the flow identifier.
flowID：VLU、フロー識別子。
The receiver of this chunk SHOULD reply as immediately as is practical with a Data Acknowledgement.
このチャンクの受信者は、データ確認応答を使用して、できるだけ早く応答する必要があります（SHOULD）。
This chunk is sent by the flow receiver to indicate that it is not (or is no longer) interested in the flow and would like the flow sender to close the flow. This chunk SHOULD precede every Data Acknowledgement chunk for the same flow in this condition.
このチャンクは、フローレシーバーによって送信されます。これは、フローに関心がなく（またはもはや関心がない）、フローセンダーにフローを閉じてもらいたいことを示します。このチャンクは、この状態の同じフローのすべてのデータ確認チャンクに先行する必要があります（SHOULD）。
This chunk is only allowed in a packet belonging to an established session and having packet mode 1 or 2.
このチャンクは、確立されたセッションに属し、パケットモード1または2を持つパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x5e | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-------------/-+
| flowID \ | exception \ |
+-------------/-+-------------/-+
struct flowExceptionReportChunkPayload_t
{
vlu_t flowID :variable*8;
vlu_t exception :variable*8;
} :chunkLength*8;
flowID: VLU, the flow identifier.
flowID：VLU、フロー識別子。
exception: VLU, the application-defined exception code being reported.
例外：VLU、報告されているアプリケーション定義の例外コード。
A receiving RTMFP might reject a flow automatically, for example if it is missing metadata, or if an invalid return association is specified. In circumstances where an RTMFP rejects a flow automatically, the exception code MUST be 0. The application can specify any exception code, including 0, when rejecting a flow. All non-zero exception codes are reserved for the application.
メタデータが欠落している場合や、無効な戻り関連付けが指定されている場合など、受信RTMFPはフローを自動的に拒否する場合があります。 RTMFPがフローを自動的に拒否する状況では、例外コードは0である必要があります。アプリケーションは、フローを拒否するときに、0を含む任意の例外コードを指定できます。ゼロ以外のすべての例外コードは、アプリケーション用に予約されています。
This chunk is sent to cleanly terminate a session. It is only allowed in a packet belonging to an established or closing session and having packet mode 1 or 2.
このチャンクは、セッションを完全に終了するために送信されます。これは、確立済みまたはクローズセッションに属し、パケットモード1または2を持つパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This chunk has no payload.
このチャンクにはペイロードがありません。
The use of Close is detailed in Section 3.5.5.
The use of Close is detailed in Section 3.5.5.
This chunk is sent in response to a Session Close Request to indicate that the sender has terminated the session. It is only allowed in a packet belonging to an established or closing session and having packet mode 1 or 2.
このチャンクは、送信者がセッションを終了したことを示すために、Session Close Requestへの応答として送信されます。これは、確立済みまたはクローズセッションに属し、パケットモード1または2を持つパケットでのみ許可されます。
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x4c | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This chunk has no payload.
このチャンクにはペイロードがありません。
The use of Close Ack is detailed in Section 3.5.5.
Close Ackの使用については、セクション3.5.5で詳しく説明しています。
+--------+ +--------+
| Peer A | S E S S I O N | Peer B |
| /=============================\ |
| || Flows || |
| ||---------------------------->|| |
| ||---------------------------->|| |
| ||<----------------------------|| |
| ||<----------------------------|| |
| ||<----------------------------|| |
| \=============================/ |
| | | |
| | +--------+
| |
| | +--------+
| | S E S S I O N | Peer C |
| /=============================\ |
| || Flows || |
| ||---------------------------->|| |
| ||<----------------------------|| |
| ||<----------------------------|| |
| \=============================/ |
| | | |
+--------+ +--------+
Figure 7: Sessions between Pairs of Communicating Endpoints
図7：通信するエンドポイントのペア間のセッション
Between any pair of communicating endpoints is a single, bidirectional, secured, congestion controlled session. Unidirectional flows convey messages from one end to the other within the session.
通信するエンドポイントのペアの間には、単一の双方向の安全な輻輳制御セッションがあります。単方向フローは、セッション内でメッセージを一方の端から他方の端に伝達します。
An endpoint initiates a session to a far end when communication is desired. An initiator begins with one or more candidate destination socket addresses, and it may learn and try more candidate addresses during startup handshaking. Eventually, a first suitable response is received, and that endpoint is selected. Startup proceeds to the selected endpoint. In the case of session startup glare, one endpoint is the prevailing initiator and the other assumes the role of responder. Encryption keys and session identifiers are negotiated between the endpoints, and the session is established.
通信が必要な場合、エンドポイントは遠端へのセッションを開始します。イニシエーターは、1つまたは複数の候補宛先ソケットアドレスで始まり、スタートアップハンドシェイク中に、より多くの候補アドレスを学習して試行する場合があります。最終的に、最初の適切な応答が受信され、そのエンドポイントが選択されます。起動は選択したエンドポイントに進みます。セッションの開始グレアの場合、1つのエンドポイントが優勢なイニシエーターであり、もう1つのエンドポイントはレスポンダーの役割を担います。暗号化キーとセッション識別子がエンドポイント間でネゴシエートされ、セッションが確立されます。
Each endpoint may begin sending message flows to the other end. For each flow, the far end may accept it and deliver its messages to the user, or it may reject the flow and transmit an exception to the sender. The flow receiver may close and reject a flow at a later time, after first accepting it. The flow receiver acknowledges all data sent to it, regardless of whether the flow was accepted. Acknowledgements drive a congestion control mechanism.
Each endpoint may begin sending message flows to the other end. For each flow, the far end may accept it and deliver its messages to the user, or it may reject the flow and transmit an exception to the sender. The flow receiver may close and reject a flow at a later time, after first accepting it. The flow receiver acknowledges all data sent to it, regardless of whether the flow was accepted. Acknowledgements drive a congestion control mechanism.
An endpoint may have concurrent sessions with other far endpoints. The multiple sessions are distinguished by a session identifier rather than by socket address. This allows an endpoint's address to change mid-session without having to tear down and re-establish a session. The existing cryptographic state for a session can be used to verify a change of address while protecting against session hijacking or denial of service.
エンドポイントには、他の遠いエンドポイントとの同時セッションがある場合があります。複数のセッションは、ソケットアドレスではなくセッション識別子によって区別されます。これにより、セッションを破棄して再確立する必要なしに、エンドポイントのアドレスをセッションの途中で変更できます。セッションの既存の暗号化状態を使用して、セッションのハイジャックまたはサービス拒否から保護しながら、アドレスの変更を確認できます。
A sender may indicate to a receiver that some user messages are of a time critical or real-time nature. A receiver may indicate to senders on concurrent sessions that it is receiving time critical messages from another endpoint. The other senders SHOULD modify their congestion control parameters to yield capacity to the session carrying time critical messages.
送信者は、一部のユーザーメッセージがタイムクリティカルまたはリアルタイムの性質であることを受信者に示す場合があります。受信者は、別のエンドポイントからタイムクリティカルなメッセージを受信していることを同時セッションの送信者に示す場合があります。他の送信者は、輻輳制御パラメータを変更して、タイムクリティカルなメッセージを運ぶセッションに容量を与える必要があります（SHOULD）。
A sender may close a flow. The flow is completed when the receiver has no outstanding gaps before the final fragment of the flow. The sender and receiver reserve a completed flow's identifier for a time to allow in-flight messages to drain from the network.
送信者はフローを閉じます。フローの最後のフラグメントの前にレシーバーに未処理のギャップがない場合、フローは完了します。送信者と受信者は、完了したフローの識別子を一定時間予約して、処理中のメッセージをネットワークから排出できるようにします。
Eventually, neither end will have any flows open to the other. The session will be idle and quiescent. Either end may reliably close the session to recover its resources.
最終的に、どちらの端も、もう一方に開かれたフローを持ちません。セッションはアイドル状態で静止します。どちらの側も、確実にセッションを閉じてリソースを回復します。
In certain circumstances, an endpoint may be ceasing operation and not have time to wait for acknowledgement of a reliable session close. In this case, the halting endpoint may send an abrupt session close to advise the far end that it is halting immediately.
特定の状況では、エンドポイントが操作を停止していて、信頼できるセッションの終了の確認を待つ時間がない場合があります。この場合、停止しているエンドポイントは突然セッションを送信して、遠端にすぐに停止していることを通知します。
Each RTMFP endpoint has an identity. The identity is encoded in a certificate. This specification doesn't mandate any particular certificate format, cryptographic algorithms, or cryptographic properties for certificates.
Each RTMFP endpoint has an identity. The identity is encoded in a certificate. This specification doesn't mandate any particular certificate format, cryptographic algorithms, or cryptographic properties for certificates.
An endpoint is named by an Endpoint Discriminator. This specification doesn't mandate any particular format for Endpoint Discriminators.
エンドポイントは、Endpoint Discriminatorによって命名されます。この仕様では、Endpoint Discriminatorsの特定の形式を義務付けていません。
An Endpoint Discriminator MAY select more than one identity and MAY match more than one distinct certificate.
Endpoint Discriminatorは、複数のIDを選択する場合があり、複数の異なる証明書と一致する場合があります。
Multiple distinct Endpoint Discriminators MAY match one certificate.
複数の異なるエンドポイント識別子が1つの証明書と一致する場合があります。
It is RECOMMENDED that multiple endpoints not have the same identity. Entities with the same identity are indistinguishable during session startup; this situation could be undesirable in some applications.
複数のエンドポイントが同じIDを持たないことをお勧めします。同じIDを持つエンティティは、セッションの起動時に区別できません。この状況は、一部のアプリケーションでは望ましくない場合があります。
An endpoint MAY have more than one address.
An endpoint MAY have more than one address.
The Cryptography Profile implements the following functions for identities, certificates, and Endpoint Discriminators, whose operation MUST be deterministic:
暗号化プロファイルは、操作が確定的でなければならないID、証明書、およびエンドポイントディスクリミネーター用の次の関数を実装します。
o Test whether a given certificate is authentic. Authenticity can comprise verifying an issuer signature chain in a public key infrastructure.
o Test whether a given certificate is authentic. Authenticity can comprise verifying an issuer signature chain in a public key infrastructure.
o Test whether a given Endpoint Discriminator selects a given certificate.
o 特定のEndpoint Discriminatorが特定の証明書を選択するかどうかをテストします。
o Test whether a given Endpoint Discriminator selects the local endpoint.
o 指定されたEndpoint Discriminatorがローカルエンドポイントを選択するかどうかをテストします。
o Generate a Canonical Endpoint Discriminator for a given certificate. Canonical Endpoint Discriminators for distinct identities SHOULD be distinct. If two distinct identities have the same Canonical Endpoint Discriminator, an initiator might abort a new opening session to the second identity (Section 3.5.1.1.1); this behavior might not be desirable.
o 指定された証明書のCanonical Endpoint Discriminatorを生成します。個別のアイデンティティの正規のエンドポイント弁別子は個別である必要があります。 2つの異なるIDが同じCanonical Endpoint Discriminatorを持つ場合、イニシエーターは2番目のIDへの新しいオープニングセッションを中止する場合があります（セクション3.5.1.1.1）。この動作は望ましくない場合があります。
o Given a certificate, a message, and a digital signature over the message, test whether the signature is valid and generated by the owner of the certificate.
o 証明書、メッセージ、およびメッセージに対するデジタル署名を指定して、署名が有効であり、証明書の所有者によって生成されたかどうかをテストします。
o Generate a digital signature for a given message corresponding to the near identity.
o 近いアイデンティティに対応する特定のメッセージのデジタル署名を生成します。
o Given the near identity and a far certificate, determine which one shall prevail as Initiator and which shall assume the Responder role in the case of startup glare. The far end MUST arrive at the same conclusion. A comparison function can comprise performing a lexicographic ordering of the binary certificates, declaring the far identity the prevailing endpoint if the far certificate is ordered before the near certificate, and otherwise declaring the near identity to be the prevailing endpoint.
o 近い身元と遠い証明書を考慮して、どれがイニシエーターとして勝ち、どれが起動時のまぶしさの場合にレスポンダーの役割を担うかを決定します。遠端も同じ結論に達しなければなりません。比較機能は、バイナリ証明書の辞書式順序の実行、遠い証明書が近い証明書の前に並べられている場合は、遠いIDを優勢なエンドポイントとして宣言し、そうでない場合は、近しいアイデンティティを優勢なエンドポイントとして宣言することを含みます。
o Given a first certificate and a second certificate, test whether a new incoming session from the second shall override an existing session with the first. It is RECOMMENDED that the test comprise testing whether the certificates are bitwise identical.
o 最初の証明書と2番目の証明書が与えられたら、2番目からの新しい着信セッションが1番目の既存のセッションをオーバーライドするかどうかをテストします。テストは、証明書がビットごとに同一であるかどうかをテストすることからなることをお勧めします。
All other semantics for certificates and Endpoint Discriminators are determined by the Cryptography Profile and the application.
証明書およびエンドポイント識別子のその他すべてのセマンティクスは、暗号化プロファイルとアプリケーションによって決定されます。
An RTMFP typically has one or more interfaces through which it communicates with other RTMFP endpoints. RTMFP can communicate with multiple distinct other RTMFP endpoints through each local interface. Session multiplexing over a shared interface can facilitate peer-to-peer communications through a NAT, by enabling third-party endpoints such as Forwarders (Section 3.5.1.5) and Redirectors (Section 3.5.1.4) to observe the translated public address and inform peers of the translation.
RTMFPには通常、他のRTMFPエンドポイントと通信するための1つ以上のインターフェースがあります。 RTMFPは、各ローカルインターフェイスを介して、他の複数のRTMFPエンドポイントと通信できます。共有インターフェースを介したセッションの多重化により、フォワーダー（セクション3.5.1.5）やリダイレクター（セクション3.5.1.4）などのサードパーティエンドポイントが変換されたパブリックアドレスを監視し、ピアに通知することで、NATを介したピアツーピア通信が容易になります。翻訳の。
An interface is typically a UDP socket (Section 2.2.1) but MAY be any suitable datagram transport service where endpoints can be addressed by IPv4 or IPv6 socket addresses.
インターフェースは通常UDPソケット（セクション2.2.1）ですが、エンドポイントがIPv4またはIPv6ソケットアドレスでアドレス指定できる任意の適切なデータグラムトランスポートサービスである場合があります。
RTMFP uses a session ID to multiplex and demultiplex communications with distinct endpoints (Section 2.2.2), in addition to the endpoint socket address. This allows an RTMFP to detect a far-end address change (as might happen, for example, in mobile and wireless scenarios) and allows communication sessions to survive address changes. This also allows an RTMFP to act as a Forwarder or Redirector for an endpoint with which it has an active session, by distinguishing startup packets from those of the active session.
RTMFP uses a session ID to multiplex and demultiplex communications with distinct endpoints (Section 2.2.2), in addition to the endpoint socket address. This allows an RTMFP to detect a far-end address change (as might happen, for example, in mobile and wireless scenarios) and allows communication sessions to survive address changes. This also allows an RTMFP to act as a Forwarder or Redirector for an endpoint with which it has an active session, by distinguishing startup packets from those of the active session.
On receiving a packet, an RTMFP decodes the session ID to look up the corresponding session information context and decryption key. Session ID 0 is reserved for session startup and MUST NOT be used for an active session. A packet for Session ID 0 uses the Default Session Key as defined by the Cryptography Profile.
パケットを受信すると、RTMFPはセッションIDをデコードして、対応するセッション情報コンテキストと復号化キーを検索します。セッションID 0はセッションの起動用に予約されており、アクティブなセッションで使用してはなりません。セッションID 0のパケットは、暗号化プロファイルで定義されているデフォルトセッションキーを使用します。
When an RTMFP packet (Section 2.2.4) is unavoidably larger than the path MTU (such as a startup packet containing an RHello (Section 2.3.4) or IIKeying (Section 2.3.7) chunk with a large certificate), it can be fragmented into segments that do not exceed the path MTU by using the Packet Fragment chunk (Section 2.3.1).
RTMFPパケット（セクション2.2.4）がパスMTU（RHello（セクション2.3.4）またはIIKeying（セクション2.3.7）チャンクと大きな証明書を含むスタートアップパケット）よりも不可避的に大きい場合、パケットフラグメントチャンクを使用して、パスMTUを超えないセグメントにフラグメント化されます（セクション2.3.1）。
The packet fragmentation mechanism SHOULD be used only to segment unavoidably large packets. Accordingly, this mechanism SHOULD be employed only during session startup with Session ID 0. This mechanism MUST NOT be used instead of the natural fragmentation mechanism of the User Data (Section 2.3.11) and Next User Data (Section 2.3.12) chunks for dividing the messages of the user's data flows into segments that do not exceed the path MTU.
パケット断片化メカニズムは、避けられないほど大きなパケットをセグメント化するためにのみ使用されるべきです（SHOULD）。したがって、このメカニズムは、セッションID 0のセッション起動時にのみ使用する必要があります。このメカニズムは、ユーザーデータ（セクション2.3.11）および次のユーザーデータ（セクション2.3.12）チャンクの自然な断片化メカニズムの代わりに使用してはなりません（MUST NOT）。ユーザーのデータフローのメッセージを、パスMTUを超えないセグメントに分割します。
A fragmented plain RTMFP packet is reassembled by concatenating the packetFragment fields of the fragments for the packet in contiguous ascending order, starting from index 0 through and including the final fragment.
フラグメント化されたプレーンなRTMFPパケットは、パケットのフラグメントのpacketFragmentフィールドを、インデックス0から始まり、最後のフラグメントを含む連続した昇順で連結することによって再構成されます。
When reassembling packets for Session ID 0, a receiver SHOULD identify the packets by the socket address from which the packet containing the fragment was received, as well as the indicated packetID.
When reassembling packets for Session ID 0, a receiver SHOULD identify the packets by the socket address from which the packet containing the fragment was received, as well as the indicated packetID.
A receiver SHOULD allow up to 60 seconds to completely receive a fragmented packet for which progress is being made. A packet is progressing if at least one new fragment for it was received in the last second.
A receiver SHOULD allow up to 60 seconds to completely receive a fragmented packet for which progress is being made. A packet is progressing if at least one new fragment for it was received in the last second.
A receiver MUST discard a Packet Fragment chunk having an empty packetFragment field.
レシーバーは、packetFragmentフィールドが空のパケットフラグメントチャンクを破棄する必要があります。
The mode of each packet containing Packet Fragments for the same fragmented packet MUST match the mode of the fragmented packet. A receiver MUST discard any new Packet Fragment chunk received in a packet with a mode different from the mode of the packet containing the first received fragment. A receiver MUST discard any reassembled packet with a mode different than the packets containing its fragments.
同じフラグメント化されたパケットのパケットフラグメントを含む各パケットのモードは、フラグメント化されたパケットのモードと一致する必要があります。レシーバーは、最初に受信したフラグメントを含むパケットのモードとは異なるモードのパケットで受信した新しいパケットフラグメントチャンクを破棄しなければなりません（MUST）。受信者は、フラグメントを含むパケットとは異なるモードで再構成されたパケットを破棄しなければなりません（MUST）。
In order to avoid jamming the network, the sender MUST rate limit packet transmission. In the absence of specific path capacity information (for instance, during session startup), a sender SHOULD NOT send more than 4380 bytes nor more than four packets per distinct endpoint every 200 ms.
ネットワークの妨害を回避するために、送信者はパケット送信をレート制限しなければなりません（MUST）。特定のパスキャパシティ情報がない場合（たとえば、セッションの起動時）、送信者は、200ミリ秒ごとに異なるエンドポイントごとに4380バイトを超えるパケットも4つを超えるパケットも送信してはなりません（SHOULD NOT）。
To avoid resource exhaustion, a receiver SHOULD limit the number of concurrent packet reassembly buffers and the size of each buffer. Limits can depend, for example, on the expected size of reassembled packets, on the rate at which fragmented packets are expected to be received, on the expected degree of interleaving, and on the expected function of the receiver. Limits can depend on the available resources of the receiver. There can be different limits for packets with Session ID 0 and packets for established sessions. For example, a busy server might need to allow for several hundred concurrent packet reassembly buffers to accommodate hundreds of connection requests per second with potentially interleaved fragments, but a client device with constrained resources could allow just a few reassembly buffers. In the absence of specific information regarding the expected size of reassembled packets, a receiver should set the limit for each packet reassembly buffer to 65536 bytes.
リソースの枯渇を回避するために、受信者は、同時パケット再構成バッファーの数と各バッファーのサイズを制限する必要があります（SHOULD）。制限は、たとえば、再構成されたパケットの予想されるサイズ、断片化されたパケットが受信されると予想されるレート、予想されるインターリーブの程度、および受信機の予想される機能に依存します。制限は、レシーバーの使用可能なリソースによって異なります。セッションID 0のパケットと確立されたセッションのパケットには、異なる制限がある場合があります。たとえば、ビジー状態のサーバーでは、インターリーブされる可能性のあるフラグメントで1秒あたり数百の接続要求に対応するために、数百の同時パケット再構成バッファーを許可する必要があるかもしれませんが、リソースが制限されているクライアントデバイスでは、再構成バッファーが少数しか許可されない場合があります。再構成されたパケットの予想サイズに関する特定の情報がない場合、受信者は各パケット再構成バッファの制限を65536バイトに設定する必要があります。
A session is the protocol relationship between a pair of communicating endpoints, comprising the shared and endpoint-specific information context necessary to carry out the communication. The session context at each end includes at least:
セッションは、通信するエンドポイントのペア間のプロトコル関係であり、通信を実行するために必要な共有されたエンドポイント固有の情報コンテキストを含みます。両端のセッションコンテキストには、少なくとも次のものが含まれます。
o TS_RX: the last timestamp received from the far end;
o TS_RX：遠端から受信した最後のタイムスタンプ。
o TS_RX_TIME: the time at which TS_RX was first observed to be different than its previous value;
o TS_RX_TIME：TS_RXが最初に以前の値と異なることが観測された時刻。
o TS_ECHO_TX: the last timestamp echo sent to the far end;
o TS_ECHO_TX：遠端に送信された最後のタイムスタンプエコー。
o MRTO: the measured retransmission timeout;
o MRTO：測定された再送信タイムアウト。
o ERTO: the effective retransmission timeout;
o ERTO：有効な再送信タイムアウト。
o Cryptographic keys for encrypting and decrypting packets, and for verifying the validity of packets, according to the Cryptography Profile;
o 暗号化プロファイルに従って、パケットの暗号化と復号化、およびパケットの有効性を検証するための暗号化キー。
o Cryptographic near and far nonces according to the Cryptography Profile, where the near nonce is the far end's far nonce, and vice versa;
o Cryptography Profileに準拠した暗号の近距離および遠距離ノンス。ここで近距離ノンスは遠端の遠距離ノンスであり、逆も同様です。
o The certificate of the far end;
o 遠端の証明書。
o The receive session identifier, used by the far end when sending packets to this end;
o パケットをこの端に送信するときに遠端で使用される受信セッション識別子。
o The send session identifier to use when sending packets to the far end;
o 遠端にパケットを送信するときに使用する送信セッション識別子。
o DESTADDR: the destination socket address to use when sending packets to the far end;
o DESTADDR：パケットを遠端に送信するときに使用する宛先ソケットアドレス。
o The set of all sending flow contexts (Section 3.6.2);
o すべての送信フローコンテキストのセット（セクション3.6.2）。
o The set of all receiving flow contexts (Section 3.6.3);
o すべての受信フローコンテキストのセット（セクション3.6.3）。
o The transmission budget, which controls the rate at which data is sent into the network (for example, a congestion window);
o データがネットワークに送信される速度を制御する送信バジェット（たとえば、輻輳ウィンドウ）。
o S_OUTSTANDING_BYTES: the total amount of user message data outstanding, or in flight, in the network -- that is, the sum of the F_OUTSTANDING_BYTES of each sending flow in the session;
o S_OUTSTANDING_BYTES：ネットワークで未処理の、または処理中のユーザーメッセージデータの合計量。つまり、セッションの各送信フローのF_OUTSTANDING_BYTESの合計。
o RX_DATA_PACKETS: a count of the number of received packets containing at least one User Data chunk since the last acknowledgement was sent, initially 0;
o RX_DATA_PACKETS：最後の確認応答が送信されてから少なくとも1つのユーザーデータチャンクを含む受信パケット数のカウント、最初は0。
o ACK_NOW: a boolean flag indicating whether an acknowledgement should be sent immediately, initially false;
o ACK_NOW：肯定応答をすぐに送信するかどうかを示すブールフラグ。最初はfalse。
o DELACK_ALARM: an alarm to trigger an acknowledgement after a delay, initially unset;
o DELACK_ALARM：遅延後に確認応答をトリガーするアラーム。最初は設定されていません。
o The state, at any time being one of the following values: the opening states S_IHELLO_SENT and S_KEYING_SENT, the open state S_OPEN, the closing states S_NEARCLOSE and S_FARCLOSE_LINGER, and the closed states S_CLOSED and S_OPEN_FAILED; and
o いつでも次のいずれかの値である状態：開始状態S_IHELLO_SENTおよびS_KEYING_SENT、オープン状態S_OPEN、終了状態S_NEARCLOSEおよびS_FARCLOSE_LINGER、およびクローズ状態S_CLOSEDおよびS_OPEN_FAILED。そして
o The role -- either Initiator or Responder -- of this end of the session.
o セッションのこの終わりの役割（開始者または応答者）。
Note: The following diagram is only a summary of state transitions and their causing events, and is not a complete operational specification.
注：以下の図は、状態遷移とその原因となるイベントの要約にすぎず、完全な運用仕様ではありません。
rcv IIKeying Glare
far prevails +-------------+ ultimate open timeout
+--------------|S_IHELLO_SENT|-------------+
| +-------------+ |
| |rcv RHello |
| | v
| v +-------------+
|<-----------(duplicate session?) |S_OPEN_FAILED|
| yes |no +-------------+
| | ^
| rcv IIKeying Glare v |
| far prevails +-------------+ |
|<-------------|S_KEYING_SENT|-------------+
| +-------------+ ultimate open timeout
| |rcv RIKeying
| |
| rcv v
| +-+ IIKeying +--------+ rcv Close Request
| |X|---------->| S_OPEN |--------------------+
| +-+ +--------+ |
| | |ABRUPT CLOSE |
| ORDERLY CLOSE| |or rcv Close Ack |
| | |or rcv IIKeying |
| | | session override |
| | +-------+ |
| v | v
| +-----------+ | +-----------------+
| |S_NEARCLOSE| | |S_FARCLOSE_LINGER|
| +-----------+ | +-----------------+
| rcv Close Ack| | |rcv Close Ack
| or 90 seconds| v |or 19 seconds
| | +--------+ |
| +------>|S_CLOSED|<---------+
+-------------------------->| |
+--------+
Figure 8: Session State Diagram
図8：セッション状態図
RTMFP sessions are established with a 4-way handshake in two round trips. The initiator begins by sending an IHello to one or more candidate addresses for the desired destination endpoint. A responder statelessly sends an RHello in response. The first correct RHello received at the initiator is selected; all others are ignored. The initiator computes its half of the session keying and sends an IIKeying. The responder receives the IIKeying and, if it is acceptable, computes its half of the session keying, at which point it can also compute the shared session keying and session nonces. The responder creates a new S_OPEN session with the initiator and sends an RIKeying. The initiator receives the RIKeying and, if it is acceptable, computes the shared session keying and session nonces. The initiator's session is now S_OPEN.
RTMFPセッションは、2往復の4ウェイハンドシェイクで確立されます。イニシエーターは、目的の宛先エンドポイントの1つ以上の候補アドレスにIHelloを送信することから始めます。レスポンダは、応答としてRHelloをステートレスに送信します。イニシエーターで受信された最初の正しいRHelloが選択されます。他のすべては無視されます。イニシエーターはセッションキーイングの半分を計算し、IIKeyingを送信します。レスポンダはIIKeyingを受信し、許容できる場合はセッションキーイングの半分を計算します。その時点で、共有セッションキーイングとセッションナンスも計算できます。レスポンダは、イニシエータとの新しいS_OPENセッションを作成し、RIKeyingを送信します。イニシエーターはRIKeyingを受信し、受け入れ可能な場合は、共有セッションキーイングとセッションナンスを計算します。イニシエーターのセッションはS_OPENです。
. Initiator Responder .
| IHello |
|(EPD,Tag) |
S_IHELLO_SENT |(SID=0) |
|------------------------------->|
| |
| RHello |
| (Tag,Cookie,RCert)|
| (SID=0)|
|<-------------------------------|
S_KEYING_SENT | |
| IIKeying |
|(ISID,Cookie,ICert,SKIC,ISig) |
|(SID=0) |
|------------------------------->|
| |
| RIKeying |
| (RSID,SKRC,RSig)|
| (SID=ISID,Key=Default)| S_OPEN
|<-------------------------------|
S_OPEN | |
| S E S S I O N |
|<-------------------(SID=ISID)--|
|--(SID=RSID)------------------->|
Figure 9: Normal Handshake
図9：通常のハンドシェイク
In the following sections, the handshake is detailed from the perspectives of the initiator and responder.
次のセクションでは、イニシエーターとレスポンダーの観点から、ハンドシェイクについて詳しく説明します。
The initiator determines that a session is needed for an Endpoint Discriminator. The initiator creates state for a new opening session and begins with a candidate endpoint address set containing at least one address. The new session is placed in the S_IHELLO_SENT state.
イニシエーターは、エンドポイント識別子にセッションが必要であると判断します。イニシエーターは、新しいオープニングセッションの状態を作成し、少なくとも1つのアドレスを含む候補エンドポイントアドレスセットで開始します。新しいセッションはS_IHELLO_SENT状態になります。
If the session does not move to the S_OPEN state before an ultimate open timeout, the session has failed and moves to the S_OPEN_FAILED state. The RECOMMENDED ultimate open timeout is 95 seconds.
最終的なオープンタイムアウトの前にセッションがS_OPEN状態に移行しない場合、セッションは失敗してS_OPEN_FAILED状態に移行します。推奨される最終的なオープンタイムアウトは95秒です。
The initiator chooses a new, unique tag not used by any currently opening session. It is RECOMMENDED that the tag be cryptographically pseudorandom and be at least 8 bytes in length, so that it is hard to guess. The initiator constructs an IHello chunk (Section 2.3.2) with the Endpoint Discriminator and the tag.
開始者は、現在開いているセッションで使用されていない新しい一意のタグを選択します。タグは暗号的に疑似ランダムであり、長さが少なくとも8バイトであることをお勧めします。そのため、推測するのは困難です。イニシエーターは、Endpoint Discriminatorとタグを使用してIHelloチャンク（セクション2.3.2）を構築します。
While the initiator is in the S_IHELLO_SENT state, it sends the IHello to each candidate endpoint address in the set, on a backoff schedule. The backoff SHOULD NOT be less than multiplicative, with not less than 1.5 seconds added to the interval between each attempt. The backoff SHOULD be scheduled separately for each candidate address, since new candidates can be added over time.
イニシエーターがS_IHELLO_SENT状態にある間、イニシエーターはバックオフスケジュールに従って、セット内の各候補エンドポイントアドレスにIHelloを送信します。バックオフは、各試行間の間隔に1.5秒以上の時間を追加して、乗法より小さくすべきではありません（SHOULD NOT）。時間の経過とともに新しい候補者を追加できるため、バックオフは候補者のアドレスごとに個別にスケジュールする必要があります。
If the initiator receives a Redirect chunk (Section 2.3.5) with a tag echo matching this session, AND this session is in the S_IHELLO_SENT state, then for each redirect destination indicated in the Redirect: if the candidate endpoint address set contains fewer than REDIRECT_THRESHOLD addresses, add the indicated redirect destination to the candidate endpoint address set. REDIRECT_THRESHOLD SHOULD NOT be more than 24.
イニシエーターがこのセッションに一致するタグエコーを含むリダイレクトチャンク（セクション2.3.5）を受信し、このセッションがS_IHELLO_SENT状態にある場合、リダイレクトに示されている各リダイレクト先について：候補エンドポイントアドレスセットに含まれるREDIRECT_THRESHOLD未満の場合アドレス、候補のエンドポイントアドレスセットに示されたリダイレクト宛先を追加します。 REDIRECT_THRESHOLDは24以下にする必要があります。
If the initiator receives an RHello chunk (Section 2.3.4) with a tag echo matching this session, AND this session is in the S_IHELLO_SENT state, AND the responder certificate matches the desired Endpoint Discriminator, AND the certificate is authentic according to the Cryptography Profile, then:
イニシエーターがこのセッションと一致するタグエコーを含むRHelloチャンク（セクション2.3.4）を受信し、かつこのセッションがS_IHELLO_SENT状態であり、レスポンダ証明書が目的のエンドポイントディスクリミネーターと一致し、かつ証明書が暗号プロファイルに従って認証されている場合、次に：
1. If the Canonical Endpoint Discriminator for the responder certificate matches the Canonical Endpoint Discriminator of another existing session in the S_KEYING_SENT or S_OPEN states, AND the certificate of the other opening session matches the desired Endpoint Discriminator, then this session is a duplicate and SHOULD be aborted in favor of the other existing session; otherwise,
1. レスポンダ証明書のCanonical Endpoint DiscriminatorがS_KEYING_SENTまたはS_OPEN状態の別の既存セッションのCanonical Endpoint Discriminatorと一致し、他の開始セッションの証明書が目的のEndpoint Discriminatorと一致する場合、このセッションは重複しているため、他の既存のセッションを支持する;さもないと、
2. Move to the S_KEYING_SENT state. Set DESTADDR, the far-end address for the session, to the address from which this RHello was received. The initiator chooses a new, unique receive session ID, not used by any other session, for the responder to use when sending packets to the initiator. It computes a Session Key Initiator Component appropriate to the responder's certificate according to the Cryptography Profile. Using this data and the cookie from the RHello, the initiator constructs and signs an IIKeying chunk (Section 2.3.7).
2. S_KEYING_SENT状態に移行します。セッションの遠端アドレスであるDESTADDRを、このRHelloの受信元のアドレスに設定します。イニシエーターは、パケットをイニシエーターに送信するときにレスポンダーが使用する、他のセッションでは使用されていない新しい一意の受信セッションIDを選択します。暗号化プロファイルに従って、レスポンダの証明書に適切なセッションキーイニシエータコンポーネントを計算します。このデータとRHelloからのCookieを使用して、イニシエーターはIIKeyingチャンクを構築して署名します（セクション2.3.7）。
While the initiator is in the S_KEYING_SENT state, it sends the IIKeying to DESTADDR on a backoff schedule. The backoff SHOULD NOT be less than multiplicative, with not less than 1.5 seconds added to the interval between each attempt.
イニシエーターがS_KEYING_SENT状態にある間、イニシエーターはIIKeyingをバックオフスケジュールでDESTADDRに送信します。バックオフは、各試行間の間隔に1.5秒以上の時間を追加して、乗法より小さくすべきではありません（SHOULD NOT）。
If the initiator receives an RIKeying chunk (Section 2.3.8) in a packet with this session's receive session identifier, AND this session is in the S_KEYING_SENT state, AND the signature in the chunk is authentic according to the far end's certificate (from the RHello), AND the Session Key Responder Component successfully combines with the Session Key Initiator Component and the near and far certificates to form the shared session keys and nonces according to the Cryptography Profile, then the session has opened successfully. The session moves to the S_OPEN state. The send session identifier is set from the RIKeying. Packet encryption, decryption, and verification now use the newly computed shared session keys, and the session nonces are available for application-layer cryptographic challenges.
イニシエーターがこのセッションの受信セッション識別子を持つパケットでRIKeyingチャンク（セクション2.3.8）を受信し、かつこのセッションがS_KEYING_SENT状態であり、かつチャンク内の署名が遠端の証明書（RHelloから）に従って認証されている場合）、およびセッションキーレスポンダーコンポーネントがセッションキーイニシエーターコンポーネントおよびニア証明書とファー証明書と正常に結合し、暗号化プロファイルに従って共有セッションキーとナンスを形成すると、セッションが正常に開きます。セッションはS_OPEN状態に移行します。送信セッション識別子はRIKeyingから設定されます。パケットの暗号化、復号化、および検証で、新しく計算された共有セッションキーが使用されるようになり、セッションナンスをアプリケーション層の暗号化の課題に使用できるようになりました。
On receipt of an IHello chunk (Section 2.3.2) with an Endpoint Discriminator that selects its identity, an endpoint SHOULD construct an RHello chunk (Section 2.3.4) and send it to the address from which the IHello was received. To avoid a potential resource exhaustion denial of service, the endpoint SHOULD NOT create any persistent state associated with the IHello. The endpoint MUST generate the cookie for the RHello in such a way that it can be recognized as authentic and valid when echoed in an IIKeying. The endpoint SHOULD use the address from which the IHello was received as part of the cookie generation formula. Cookies SHOULD be valid only for a limited time; that lifetime SHOULD NOT be less than 95 seconds (the recommended ultimate session open timeout).
エンドポイントは、IDを選択するエンドポイントディスクリミネーターでIHelloチャンク（セクション2.3.2）を受信すると、RHelloチャンク（セクション2.3.4）を構築し、IHelloの受信元アドレスに送信する必要があります（SHOULD）。潜在的なリソース枯渇サービス拒否を回避するために、エンドポイントはIHelloに関連付けられた永続的な状態を作成してはなりません（SHOULD NOT）。エンドポイントは、IIKeyingでエコーされたときに本物であり、有効であると認識できるような方法で、RHelloのCookieを生成する必要があります。エンドポイントは、IHelloが受信されたアドレスをCookie生成式の一部として使用する必要があります（SHOULD）。クッキーは一定期間のみ有効である必要があります。その存続期間は95秒未満にする必要があります（推奨される最終的なセッションオープンタイムアウト）。
On receipt of an FIHello chunk (Section 2.3.3) from a Forwarder (Section 3.5.1.5) where the Endpoint Discriminator selects its identity, an endpoint SHOULD do one of the following:
エンドポイント弁別子がアイデンティティを選択するフォワーダー（セクション3.5.1.5）からFIHelloチャンク（セクション2.3.3）を受信すると、エンドポイントは次のいずれかを実行する必要があります（SHOULD）。
1. Compute, construct, and send an RHello as though the FIHello was an IHello received from the indicated reply address; or
1. FIHelloが指定された応答アドレスから受信したIHelloであるかのように、RHelloを計算、構築、送信します。または
2. Construct and send an Implied Redirect (Section 2.3.5) to the FIHello's reply address; or
2. 暗黙のリダイレクト（セクション2.3.5）を作成し、FIHelloの返信アドレスに送信します。または
3. Ignore this FIHello.
3. このFIHelloは無視してください。
On receipt of an IIKeying chunk (Section 2.3.7), if the cookie is not authentic or if it has expired, ignore this IIKeying; otherwise,
IIKeyingチャンクを受信すると（セクション2.3.7）、Cookieが本物ではない場合、または有効期限が切れている場合は、このIIKeyingを無視します。さもないと、
On receipt of an IIKeying chunk, if the cookie appears authentic but does not match the address from which the IIKeying's packet was received, perform the special processing at Cookie Change (Section 3.5.1.2); otherwise,
IIKeyingチャンクの受信時に、Cookieが本物であるように見えても、IIKeyingのパケットの受信元のアドレスと一致しない場合は、Cookieの変更（セクション3.5.1.2）で特別な処理を実行します。さもないと、
On receipt of an IIKeying with an authentic and valid cookie, if the certificate is authentic according to the Cryptography Profile, AND the signature in the chunk is authentic according to the far end's certificate and the Cryptography Profile, AND the Session Key Initiator Component is acceptable, then:
真正で有効なCookieを含むIIKeyingを受信したとき、証明書が暗号化プロファイルに従って真正であり、チャンク内の署名が遠端の証明書および暗号化プロファイルに従って真正であり、セッションキーイニシエーターコンポーネントが受け入れ可能である場合、次に：
1. If the address from which this IIKeying was received corresponds to an opening session in the S_IHELLO_SENT or S_KEYING_SENT state, perform the special processing at Glare (Section 3.5.1.3); otherwise,
1. このIIKeyingの受信元のアドレスがS_IHELLO_SENTまたはS_KEYING_SENT状態のオープニングセッションに対応している場合は、Glareで特別な処理を実行します（セクション3.5.1.3）。さもないと、
2. If the address from which this IIKeying was received corresponds to a session in the S_OPEN state, then:
2. このIIKeyingの受信元のアドレスがS_OPEN状態のセッションに対応する場合：
1. If the receiver was the Responder for the S_OPEN session and the session identifier, certificate, and Session Key Initiator Component are identical to those of the S_OPEN session, this IIKeying is a retransmission, so resend the S_OPEN session's RIKeying using the Default Session Key as specified below; otherwise,
1. レシーバーがS_OPENセッションのレスポンダーであり、セッションID、証明書、およびセッションキーイニシエーターコンポーネントがS_OPENセッションのものと同一である場合、このIIKeyingは再送信であるため、指定されたデフォルトのセッションキーを使用してS_OPENセッションのRIKeyingを再送信します。未満;さもないと、
2. If the certificate from this IIKeying does not override the certificate of the S_OPEN session, ignore this IIKeying; otherwise,
2. このIIKeyingからの証明書がS_OPENセッションの証明書を上書きしない場合は、このIIKeyingを無視してください。さもないと、
3. The certificate from this IIKeying overrides the certificate of the S_OPEN session; this is a new opening session from the same identity, and the existing S_OPEN session is stale. Move the existing S_OPEN session to S_CLOSED and abort all of its flows (signaling exceptions to the user), then continue processing this IIKeying.
3. このIIKeyingからの証明書は、S_OPENセッションの証明書をオーバーライドします。これは同じIDからの新しいオープニングセッションであり、既存のS_OPENセッションは古くなっています。既存のS_OPENセッションをS_CLOSEDに移動し、そのフローをすべて中止し（ユーザーに例外を通知）、このIIKeyingの処理を続行します。
Otherwise,
さもないと、
3. Compute a Session Key Responder Component and choose a new, unique receive session ID not used by any other session for the initiator to use when sending packets to the responder. Using this data, construct and, with the Session Key Initiator Component, sign an RIKeying chunk (Section 2.3.8). Using the Session Key Initiator and Responder Components and the near and far certificates, the responder combines and computes the shared session keys and nonces according to the Cryptography Profile. The responder creates a new session in the S_OPEN state, with the far-endpoint address DESTADDR taken from the source address of the packet containing the IIKeying and the send session identifier taken from the IIKeying. The responder sends the RIKeying to the initiator using the Default Session Key and the requested send session identifier. Packet encryption, decryption, and verification of all future packets for this session use the newly computed keys, and the session nonces are available for application-layer cryptographic challenges.
3. セッションキーレスポンダコンポーネントを計算し、イニシエータがパケットをレスポンダに送信するときに使用する、他のセッションで使用されていない新しい一意の受信セッションIDを選択します。このデータを使用して、セッションキーイニシエーターコンポーネントを作成し、RIKeyingチャンクに署名します（セクション2.3.8）。セッションキーイニシエーターとレスポンダーコンポーネント、およびニア証明書とファー証明書を使用して、レスポンダーは暗号化プロファイルに従って共有セッションキーとナンスを組み合わせて計算します。レスポンダは、IIKeyingを含むパケットのソースアドレスから取得された遠端点アドレスDESTADDRと、IIKeyingから取得された送信セッション識別子を使用して、S_OPEN状態で新しいセッションを作成します。レスポンダは、デフォルトセッションキーと要求された送信セッション識別子を使用して、RIKeyingをイニシエータに送信します。パケットの暗号化、復号化、およびこのセッションの今後のすべてのパケットの検証では、新しく計算された鍵が使用され、セッションナンスはアプリケーション層の暗号化の課題に使用できます。
In some circumstances, the responder may generate an RHello cookie for an initiator's address that isn't the address the initiator would use when sending packets directly to the responder. This can happen, for example, when the initiator has multiple local addresses and uses one address to reach a Forwarder (Section 3.5.1.5) but another to reach the responder.
状況によっては、レスポンダがイニシエータがパケットを直接レスポンダに送信するときに使用するアドレスではないアドレスのイニシエータのRHello Cookieを生成する場合があります。これは、たとえば、イニシエーターに複数のローカルアドレスがあり、1つのアドレスを使用してフォワーダー（セクション3.5.1.5）に到達し、別のアドレスを使用してレスポンダーに到達する場合に発生する可能性があります。
Consider the following example:
次の例について考えてみます。
Initiator Forwarder Responder
| IHello | |
|(Src=Ix) | |
|------------------------------->| |
| | FIHello |
| |(RA=Ix) |
| |-------------------------------->|
| |
| RHello |
| (Cookie:Ix)|
|<-----------------------------------------------------------------|
| |
| IIKeying |
|(Cookie:Ix,Src=Iy) |
|----------------------------------------------------------------->|
| |
| RHello Cookie Change |
| (Cookie:Ix,Cookie:Iy)|
|<-----------------------------------------------------------------|
| |
| IIKeying |
|(Cookie:Iy) |
|----------------------------------------------------------------->|
| |
| RIKeying |
|<-----------------------------------------------------------------|
| |
|<======================== S E S S I O N =========================>|
Figure 10: Handshake with Cookie Change
図10：Cookieの変更を伴うハンドシェイク
The initiator has two network interfaces: a first preferred interface with address Ix = 192.0.2.100:50000, and a second with address Iy = 198.51.100.101:50001. The responder has one interface with address Ry = 198.51.100.200:51000, on the same network as the initiator's second interface. The initiator uses its first interface to reach a Forwarder. The Forwarder observes the initiator's address of Ix and sends a Forwarded IHello (Section 2.3.3) to the responder. The responder treats this as if it were an IHello from Ix, calculates a corresponding cookie, and sends an RHello to Ix. The initiator receives this RHello from Ry and selects that address as the destination for the session. It then sends an IIKeying, copying the cookie from the RHello. However, since the source of the RHello is Ry, on a network to which the initiator is directly connected, the initiator uses its second interface Iy to send the IIKeying. The responder, on receiving the IIKeying, will compare the cookie to the expected value based on the source address of the packet, and since the IIKeying source doesn't match the IHello source used to generate the cookie, the responder will reject the IIKeying.
イニシエーターには2つのネットワークインターフェイスがあります。アドレスがIx = 192.0.2.100:50000の最初の優先インターフェイスと、アドレスがIy = 198.51.100.101:50001の2番目のインターフェイスです。レスポンダには、イニシエータの2番目のインターフェースと同じネットワーク上に、アドレスRy = 198.51.100.200:51000のインターフェースが1つあります。イニシエーターは、最初のインターフェースを使用してフォワーダーに到達します。 Forwarderは、Ixのイニシエーターのアドレスを監視し、Forwarded IHello（セクション2.3.3）をレスポンダに送信します。レスポンダは、これをIxからのIHelloであるかのように扱い、対応するCookieを計算して、RHelloをIxに送信します。イニシエーターはRyからこのRHelloを受信し、そのアドレスをセッションの宛先として選択します。次にIIKeyingを送信し、RHelloからCookieをコピーします。ただし、RHelloのソースはRyであるため、イニシエーターが直接接続されているネットワークでは、イニシエーターは2番目のインターフェースIyを使用してIIKeyingを送信します。 IIKeyingを受信すると、レスポンダはパケットのソースアドレスに基づいてCookieを期待値と比較します。IIKeyingソースがCookieの生成に使用されたIHelloソースと一致しないため、レスポンダはIIKeyingを拒否します。
If the responder determines that it generated the cookie in the IIKeying but the cookie doesn't match the sender's address (for example, if the cookie is in two parts, with a first part generated independently of the initiator's address and a second part dependent on the address), the responder SHOULD generate a new cookie based on the address from which the IIKeying was received and send an RHello Cookie Change chunk (Section 2.3.6) to the source of the IIKeying, using the session ID from the IIKeying and the Default Session Key.
IIKeyingでCookieを生成したと応答側が判断したが、Cookieが送信者のアドレスと一致しない場合（たとえば、Cookieが2つの部分にあり、最初の部分は開始者のアドレスとは無関係に生成され、2番目の部分は依存している場合）アドレス）、レスポンダーは、IIKeyingを受信したアドレスに基づいて新しいCookieを生成し、IIKeyingのセッションIDを使用して、RHello Cookie Changeチャンク（セクション2.3.6）をIIKeyingのソースに送信する必要があります（SHOULD）。デフォルトのセッションキー。
If the initiator receives an RHello Cookie Change chunk for a session in the S_KEYING_SENT state, AND the old cookie matches the one originally sent to the responder, then the initiator adopts the new cookie, constructs and signs a new IIKeying chunk, and sends the new IIKeying to the responder. The initiator SHOULD NOT change the cookie for a session more than once.
イニシエーターがS_KEYING_SENT状態のセッションのRHello Cookie Changeチャンクを受信し、古いCookieが最初にレスポンダーに送信されたものと一致する場合、イニシエーターは新しいCookieを採用し、新しいIIKeyingチャンクを作成して署名し、新しいIIレスポンダへのキーイング。イニシエーターは、セッションのCookieを複数回変更してはなりません（SHOULD NOT）。
Glare occurs when two endpoints attempt to initiate sessions to each other concurrently. Glare is detected by receipt of a valid and authentic IIKeying from an endpoint address that is a destination for an opening session. Only one session is allowed between a pair of endpoints.
グレアは、2つのエンドポイントが相互に同時にセッションを開始しようとしたときに発生します。グレアは、オープニングセッションの宛先であるエンドポイントアドレスからの有効で信頼できるIIKeyingの受信によって検出されます。エンドポイントのペア間で許可されるセッションは1つだけです。
Glare is resolved by comparing the certificate in the received IIKeying with the near end's certificate. The Cryptography Profile defines a certificate comparison function to determine the prevailing endpoint when there is glare.
グレアは、受信したIIKeyingの証明書を近端の証明書と比較することで解決されます。暗号化プロファイルは、グレアが存在する場合の一般的なエンドポイントを決定するための証明書比較関数を定義します。
If the near end prevails, discard and ignore the received IIKeying. The far end will abort its opening session on receipt of IIKeying from the near end.
近端が優勢な場合は、受け取ったIIKeyingを破棄して無視します。遠端は、近端からIIKeyingを受信すると、オープニングセッションを中止します。
Otherwise, the far end prevails:
それ以外の場合、遠端が優先されます。
1. If the certificate in the IIKeying overrides the certificate associated with the near opening session according to the Cryptography Profile, then abort and destroy the near opening session. Then,
1. IIKeyingの証明書が、暗号化プロファイルに従って、ほぼ開始しているセッションに関連付けられている証明書をオーバーライドする場合は、中断し、ほぼ開始しているセッションを破棄します。そして、
2. Continue with normal Responder IIKeying processing (Section 3.5.1.1.2).
2. 通常のResponder IIKeying処理を続行します（セクション3.5.1.1.2）。
+-----------+ +------------+ +-----------+
| Initiator |---------->| Redirector | | Responder |
| |<----------| | | |
| | +------------+ | |
| |<=================================>| |
+-----------+ +-----------+
Figure 11: Redirector
図11：リダイレクター
A Redirector acts like a name server for Endpoint Discriminators. An initiator MAY use a Redirector to discover additional candidate endpoint addresses for a desired endpoint.
リダイレクタは、Endpoint Discriminatorsのネームサーバーのように機能します。イニシエーターは、リダイレクターを使用して、目的のエンドポイントの追加候補エンドポイントアドレスを検出できます（MAY）。
On receipt of an IHello chunk with an Endpoint Discriminator that does not select the Redirector's identity, the Redirector constructs and sends back to the initiator a Responder Redirect chunk (Section 2.3.5) containing one or more additional candidate addresses for the indicated endpoint.
リダイレクターのIDを選択しないエンドポイント識別子を持つIHelloチャンクを受信すると、リダイレクターは指定されたエンドポイントの1つ以上の追加候補アドレスを含むレスポンダーリダイレクトチャンク（セクション2.3.5）を作成してイニシエーターに送り返します。
Initiator Redirector Responder
| IHello | |
|------------------------------->| |
| | |
| Redirect | |
|<-------------------------------| |
| |
| IHello |
|----------------------------------------------------------------->|
| |
| RHello |
|<-----------------------------------------------------------------|
| |
| IIKeying |
|----------------------------------------------------------------->|
| |
| RIKeying |
|<-----------------------------------------------------------------|
| |
|<======================== S E S S I O N =========================>|
Figure 12: Handshake Using a Redirector
図12：リダイレクターを使用したハンドシェイク
Deployment Design Note: Redirectors SHOULD NOT initiate new sessions to endpoints that might use the Redirector's address as a candidate for another endpoint, since the far end might interpret the Redirector's IIKeying as glare for the far end's initiation to the other endpoint.
配備設計上の注意：リダイレクターは、リダイレクターのアドレスを別のエンドポイントの候補として使用する可能性のあるエンドポイントへの新しいセッションを開始しないでください。これは、遠端がリダイレクターのIIKeyingを、遠端が他のエンドポイントへの開始のまぶしさとして解釈する可能性があるためです。
+-----------+ +-----------+ +---+ +-----------+
| Initiator |---->| Forwarder |<===>| N |<===>| Responder |
| | +-----------+ | A | | |
| |<=====================>| T |<===>| |
+-----------+ +---+ +-----------+
Figure 13: Forwarder
図13：フォワーダー
A responder might be behind a NAT or firewall that doesn't allow inbound packets to reach the endpoint until it first sends an outbound packet for a particular far-endpoint address.
レスポンダは、NATまたはファイアウォールの背後にある可能性があり、特定の遠端点アドレスのアウトバウンドパケットを最初に送信するまで、インバウンドパケットがエンドポイントに到達することを許可しません。
A Forwarder's endpoint address MAY be a candidate address for another endpoint. A responder MAY use a Forwarder to receive FIHello chunks sent on behalf of an initiator.
フォワーダーのエンドポイントアドレスは、別のエンドポイントの候補アドレスになる場合があります。レスポンダは、イニシエータに代わって送信されたFIHelloチャンクを受信するためにフォワーダを使用できます（MAY）。
On receipt of an IHello chunk with an Endpoint Discriminator that does not select the Forwarder's identity, if the Forwarder has an S_OPEN session with an endpoint whose certificate matches the desired Endpoint Discriminator, the Forwarder constructs and sends an FIHello chunk (Section 2.3.3) to the selected endpoint over the S_OPEN session, using the tag and Endpoint Discriminator from the IHello chunk and the source address of the packet containing the IHello for the corresponding fields of the FIHello.
フォワーダーのIDを選択しないEndpoint Discriminatorを含むIHelloチャンクを受信すると、フォワーダーが、証明書が目的のEndpoint Discriminatorと一致するエンドポイントとのS_OPENセッションを持っている場合、FIHelloチャンクを構築して送信します（セクション2.3.3）。 IHelloチャンクのタグとEndpoint Discriminator、およびFIHelloの対応するフィールドのIHelloを含むパケットの送信元アドレスを使用して、S_OPENセッションを介して選択したエンドポイントに送信します。
On receipt of an FIHello chunk, a responder might send an RHello or Implied Redirect to the original source of the IHello (Section 3.5.1.1.2), potentially allowing future packets to flow directly between the initiator and responder through the NAT or firewall.
FIHelloチャンクを受信すると、レスポンダーはRHelloまたは暗黙のリダイレクトをIHelloの元のソース（セクション3.5.1.1.2）に送信し、将来のパケットがイニシエーターとレスポンダーの間でNATまたはファイアウォールを介して直接流れるようにする可能性があります。
Initiator Forwarder NAT Responder
| IHello | | |
|------------------------------->| | |
| | FIHello | |
| |--------------->|--------------->|
| | |
| | RHello |
| :<---------------|
|<------------------------------------------------: |
| : |
| IIKeying : |
|-------------------------------------------------:--------------->|
| : |
| : RIKeying |
| :<---------------|
|<------------------------------------------------: |
| : |
|<======================== S E S S I O N ========>:<==============>|
Figure 14: Forwarder Handshake where Responder Sends an RHello
図14：レスポンダがRHelloを送信するフォワーダハンドシェイク
Initiator Forwarder NAT Responder
| IHello | | |
|------------------------------->| | |
| | FIHello | |
| |--------------->|--------------->|
| | |
| | Redirect |
| | (Implied,RD={})|
| :<---------------|
|<------------------------------------------------: |
| : |
| IHello : |
|------------------------------------------------>:--------------->|
| : |
| : RHello |
| :<---------------|
|<------------------------------------------------: |
| : |
| IIKeying : |
|------------------------------------------------>:--------------->|
| : |
| : RIKeying |
| :<---------------|
|<------------------------------------------------: |
| : |
|<======================== S E S S I O N ========>:<==============>|
Figure 15: Forwarder Handshake where Responder Sends an Implied Redirect
図15：レスポンダが暗黙のリダイレクトを送信するフォワーダハンドシェイク
+---+ +---+ +---+ +---+ +---+
| I | | N | | I | | N | | R |
| n |------>| A |------>| n | | A | | e |
| i | | T | | t |<====>| T |<====>| s |
| t |<------| |<------| r | | | | p |
| i | | | | o | | | | o |
| a | | | +---+ | | | n |
| t | | | | | | d |
| o |<=====>| |<================>| |<====>| e |
| r | | | | | | r |
+---+ +---+ +---+ +---+
Figure 16: Introduction Service for Initiator and Responder behind NATs
図16：NATの背後にあるイニシエーターとレスポンダーの紹介サービス
An initiator and responder might each be behind distinct NATs or firewalls that don't allow inbound packets to reach the respective endpoints until each first sends an outbound packet for a particular far-endpoint address.
イニシエーターとレスポンダーはそれぞれ、個別のNATまたはファイアウォールの背後にある可能性があり、それぞれが特定の遠端点アドレスのアウトバウンドパケットを最初に送信するまで、インバウンドパケットがそれぞれのエンドポイントに到達することを許可しません。
An introduction service comprising Redirector and Forwarder functions may facilitate direct communication between endpoints each behind a NAT.
リダイレクターとフォワーダーの機能を備えた導入サービスは、NATの背後にあるエンドポイント間の直接通信を容易にします。
The responder is registered with the introduction service via an S_OPEN session to it. The service observes and records the responder's public NAT address as the DESTADDR of the S_OPEN session. The service MAY record other addresses for the responder, for example addresses that the responder self-reports as being directly attached.
レスポンダは、S_OPENセッションを介して紹介サービスに登録されます。サービスは、レスポンダーのパブリックNATアドレスを監視して、S_OPENセッションのDESTADDRとして記録します。サービスはレスポンダの他のアドレス、たとえばレスポンダが直接接続されていると自己報告するアドレスなどを記録してもよい（MAY）。
The initiator begins with an address of the introduction service as an initial candidate. The Redirector portion of the service sends to the initiator a Responder Redirect containing at least the responder's public NAT address as previously recorded. The Forwarder portion of the service sends to the responder a Forwarded IHello containing the initiator's public NAT address as observed to be the source of the IHello.
イニシエーターは、最初の候補として紹介サービスのアドレスから始まります。サービスのリダイレクター部分は、少なくとも記録済みのレスポンダーのパブリックNATアドレスを含むレスポンダーリダイレクトをイニシエーターに送信します。サービスのForwarder部分は、IHelloのソースであることが確認されたイニシエーターのパブリックNATアドレスを含むForwarded IHelloをレスポンダーに送信します。
The responder sends an RHello to the initiator's public NAT address in response to the FIHello. This will allow inbound packets to the responder through its NAT from the initiator's public NAT address.
レスポンダは、FIHelloに応答してRHelloをイニシエータのパブリックNATアドレスに送信します。これにより、イニシエーターのパブリックNATアドレスからNATを介してレスポンダーへのインバウンドパケットが許可されます。
The initiator sends an IHello to the responder's public NAT address in response to the Responder Redirect. This will allow inbound packets to the initiator through its NAT from the responder's public NAT address.
イニシエーターは、レスポンダーリダイレクトへの応答として、IHelloをレスポンダーのパブリックNATアドレスに送信します。これにより、レスポンダーのパブリックNATアドレスからNATを介してイニシエーターへのインバウンドパケットが許可されます。
With transit paths created in both NATs, normal session startup can proceed.
両方のNATで作成されたトランジットパスを使用すると、通常のセッションの起動を続行できます。
Initiator NAT-I Redirector+Forwarder NAT-R Responder
| | | | |
| IHello | | | |
|(Dst=Intro) | | | |
|-------------->| | | |
| |--------------->| | |
| | | FIHello | |
| | |(RA=NAT-I-Pub) | |
| | |--------------->|--------------->|
| | Redirect | | |
| | (RD={NAT-R-Pub,| | |
| | ...})| | |
|<--------------|<---------------| | |
| | | RHello |
| | | (Dst=NAT-I-Pub)|
| | :<---------------|
| | (*) <--------------------------: |
| IHello | : |
|(Dst=NAT-R-Pub)| : |
|-------------->: : |
| :-------------------------------->:--------------->|
| : : |
| : : RHello |
| : :<---------------|
|<--------------:<--------------------------------: |
| : : |
| IIKeying : : |
|-------------->: : |
| :-------------------------------->:--------------->|
| : : |
| : : RIKeying |
| : :<---------------|
|<--------------:<--------------------------------: |
| : : |
|<=============>:<======== S E S S I O N ========>:<==============>|
Figure 17: Handshake with Redirector and Forwarder
図17：リダイレクターとフォワーダーを使用したハンドシェイク
At the point in Figure 17 marked (*), the responder's RHello from the FIHello might arrive at the initiator's NAT before or after the initiator's IHello is sent outbound to the responder's public NAT address. If it arrives before, it may be dropped by the NAT. If it arrives after, it will transit the NAT and trigger keying without waiting for another round-trip time. The timing of this race depends, among other factors, on the relative distances of the initiator and responder from each other and from the introduction service.
図17の（*）でマークされた時点で、FIHelloからのレスポンダーのRHelloは、イニシエーターのIHelloがレスポンダーのパブリックNATアドレスに送信される前または後に、イニシエーターのNATに到着する場合があります。以前に到着した場合、NATによってドロップされる可能性があります。それが後に到着した場合、NATを通過し、次の往復時間を待たずにキーイングをトリガーします。このレースのタイミングは、他の要因の中でも、イニシエーターとレスポンダーの互いからの、および紹介サービスからの相対的な距離に依存します。
+---+ IHello/RHello +-------------+
| I |<------------------->| Responder 1 |
| n | +-------------+
| i | SESSION +-------------+
| t |<=========>| Responder 2 |
| i | +-------------+
| a | IHello... +----------------+
| t |-------------------------> X | Dead Responder |
| o | +----------------+
| r | IHello/RHello +-------------+
| |<---------------->| Responder N |
+---+ +-------------+
Figure 18: Parallel Open to Multiple Endpoints
図18：複数のエンドポイントへの並列オープン
As specified in Section 3.2, more than one endpoint is allowed to be selected by one Endpoint Discriminator. This will typically be the case for a set of servers, any of which could accommodate a connecting client.
セクション3.2で指定されているように、1つのエンドポイント識別子によって複数のエンドポイントを選択できます。これは通常、サーバーのセットに当てはまります。サーバーのいずれも接続するクライアントに対応できます。
As specified in Section 3.5.1.1.1, an initiator is allowed to use multiple candidate endpoint addresses when starting a session, and the sender of the first acceptable RHello chunk to be received is selected to complete the session, with later responses ignored. An initiator can start with the multiple candidate endpoint addresses, or it may learn them during startup from one or more Redirectors (Section 3.5.1.4).
セクション3.5.1.1.1で指定されているように、イニシエーターはセッションの開始時に複数の候補エンドポイントアドレスを使用でき、受信する最初の受け入れ可能なRHelloチャンクの送信者がセッションを完了するために選択され、その後の応答は無視されます。イニシエーターは複数の候補エンドポイントアドレスで開始できます。または、1つ以上のリダイレクターから起動時にそれらを学習する場合があります（セクション3.5.1.4）。
Parallel open to multiple endpoints for the same Endpoint Discriminator, combined with selection by earliest RHello, can be used for load distribution and fault tolerance. The cost at each endpoint that is not selected is limited to receiving and processing an IHello, and generating and sending an RHello.
同じEndpoint Discriminatorの複数のエンドポイントに並行してオープンし、最初のRHelloによる選択と組み合わせて、負荷分散とフォールトトレランスに使用できます。選択されていない各エンドポイントのコストは、IHelloの受信と処理、およびRHelloの生成と送信に限定されます。
In one circumstance, multiple servers of similar processing and networking capacity may be located in near proximity to each other, such as in a data center. In this circumstance, a less heavily loaded server can respond to an IHello more quickly than more heavily loaded servers and will tend to be selected by a client.
ある状況では、同様の処理能力とネットワーキング能力を備えた複数のサーバーが、データセンター内など、互いに近接して配置されている場合があります。この状況では、負荷が少ないサーバーは、負荷が高いサーバーよりもIHelloに迅速に応答でき、クライアントによって選択される傾向があります。
In another circumstance, multiple servers may be located in different physical locations, such as different data centers. In this circumstance, a server that is located nearer (in terms of network distance) to the client can respond earlier than more distant servers and will tend to be selected by the client.
別の状況では、複数のサーバーが異なるデータセンターなどの異なる物理的な場所に配置されている場合があります。この状況では、クライアントに近い（ネットワーク距離の点で）サーバーは、遠いサーバーよりも早く応答でき、クライアントによって選択される傾向があります。
Multiple servers, in proximity or distant from one another, can form a redundant pool of servers. A client can perform a parallel open to the multiple servers. In normal operation, the multiple servers will all respond, and the client will select one of them as described above. If one of the multiple servers fails, other servers in the pool can still respond to the client, allowing the client to succeed to an S_OPEN session with one of them.
複数のサーバーが互いに近接または離れている場合は、サーバーの冗長プールを形成できます。クライアントは、複数のサーバーに対して並列オープンを実行できます。通常の操作では、複数のサーバーがすべて応答し、クライアントは上記のようにそれらの1つを選択します。複数のサーバーの1つに障害が発生した場合でも、プール内の他のサーバーはクライアントに応答できるため、クライアントはそのうちの1つとのS_OPENセッションに成功できます。
An RTMFP MUST implement congestion control and avoidance algorithms that are "TCP compatible", in accordance with Internet best current practice [RFC2914]. The algorithms SHOULD NOT be more aggressive in sending data than those described in "TCP Congestion Control" [RFC5681] and MUST NOT be more aggressive in sending data than the "slow start algorithm" described in Section 3.1 of RFC 5681.
RTMFPは、インターネットのベストプラクティス[RFC2914]に従って、「TCP互換」である輻輳制御および回避アルゴリズムを実装する必要があります。アルゴリズムは、「TCP輻輳制御」[RFC5681]で説明されているものよりもデータを送信する際に積極的にすべきではなく、RFC 5681のセクション3.1で説明されている「スロースタートアルゴリズム」よりも積極的にデータを送信してはなりません。
An endpoint maintains a transmission budget in the session information context of each S_OPEN session (Section 3.5), controlling the rate at which the endpoint sends data into the network.
エンドポイントは、各S_OPENセッション（セクション3.5）のセッション情報コンテキストで伝送バジェットを維持し、エンドポイントがネットワークにデータを送信するレートを制御します。
For window-based congestion control and avoidance algorithms, the transmission budget is the congestion window, which is the amount of user data that is allowed to be outstanding, or in flight, in the network. Transmission is allowed when S_OUTSTANDING_BYTES (Section 3.5) is less than the congestion window (Section 3.6.2.3). See Appendix A for an experimental window-based congestion control algorithm for real-time and bulk data.
ウィンドウベースの輻輳制御および回避アルゴリズムの場合、送信バジェットは輻輳ウィンドウです。これは、ネットワーク内で未処理または処理中のユーザーデータの量です。 S_OUTSTANDING_BYTES（セクション3.5）が輻輳ウィンドウ（セクション3.6.2.3）より小さい場合、送信は許可されます。リアルタイムデータとバルクデータの実験的なウィンドウベースの輻輳制御アルゴリズムについては、付録Aを参照してください。
An endpoint avoids sending large bursts of data or packets into the network (Section 3.5.2.3).
エンドポイントは、データまたはパケットの大きなバーストをネットワークに送信することを回避します（セクション3.5.2.3）。
A sending endpoint increases and decreases its transmission budget in response to acknowledgements (Section 3.6.2.4) and loss according to the congestion control and avoidance algorithms. Loss is detected by negative acknowledgement (Section 3.6.2.5) and timeout (Section 3.6.2.6).
送信側エンドポイントは、輻輳制御および回避アルゴリズムに従って、確認応答（セクション3.6.2.4）および損失に応じて、送信バジェットを増減します。損失は、否定応答（セクション3.6.2.5）およびタイムアウト（セクション3.6.2.6）によって検出されます。
Timeout is determined by the Effective Retransmission Timeout (ERTO) (Section 3.5.2.2). The ERTO is measured using the Timestamp and Timestamp Echo packet header fields (Section 2.2.4).
タイムアウトは、有効な再送信タイムアウト（ERTO）によって決定されます（セクション3.5.2.2）。 ERTOは、タイムスタンプおよびタイムスタンプエコーパケットヘッダーフィールドを使用して測定されます（セクション2.2.4）。
A receiving endpoint acknowledges all received data (Section 3.6.3.4) to enable the sender to measure receipt of data, or lack thereof.
受信側エンドポイントは、受信したすべてのデータを確認し（3.6.3.4項）、送信側がデータの受信または欠落を測定できるようにします。
A receiving endpoint may be receiving time critical (or real-time) data from a first sender while receiving data from other senders. The receiving endpoint can signal its other senders (Section 2.2.4)
受信側エンドポイントは、他の送信側からデータを受信しながら、最初の送信側からタイムクリティカル（またはリアルタイム）のデータを受信している可能性があります。受信エンドポイントは他の送信者に信号を送ることができます（セクション2.2.4）
to cause them to decrease the aggressiveness of their congestion control and avoidance algorithms, in order to yield network capacity to the time critical data (Section 3.5.2.1).
タイムクリティカルなデータにネットワーク容量をもたらすために、輻輳制御および回避アルゴリズムの積極性を低下させる（セクション3.5.2.1）。
A sender can increase its transmission budget at a rate compatible with (but not exceeding) the "slow start algorithm" specified in RFC 5681 (with which the transmission rate is doubled every round trip when beginning or restarting transmission, until loss is detected). However, a sender MUST behave as though the slow start threshold SSTHRESH is clamped to 0 (disabling the slow start algorithm's exponential increase behavior) on a session where a Time Critical Reverse Notification (Section 2.2.4) indication has been received from the far end within the last 800 milliseconds, unless the sender is itself currently sending time critical data to the far end.
送信者は、RFC 5681で指定された「スロースタートアルゴリズム」と互換性のある（ただし超過しない）レートで送信バジェットを増やすことができます（これにより、損失が検出されるまで、送信を開始または再開すると、ラウンドトリップごとに送信レートが2倍になります）。ただし、送信者は、タイムクリティカルなリバース通知（セクション2.2.4）の指示が遠端から受信されたセッションで、スロースタートしきい値SSTHRESHが0にクランプされている（スロースタートアルゴリズムの指数増加動作を無効にする）ように動作する必要があります。送信者自身が現在タイムクリティカルなデータを遠端に送信していない限り、過去800ミリ秒以内。
During each round trip, a sender SHOULD NOT increase the transmission budget by more than 0.5% or by 384 bytes per round trip (whichever is greater) on a session where a Time Critical Reverse Notification indication has been received from the far end within the last 800 milliseconds, unless the sender is itself currently sending time critical data to the far end.
各ラウンドトリップの間、送信者は、最後の時間内に遠端からタイムクリティカルなリバース通知の指示が受信されたセッションで、0.5％以上、またはラウンドトリップごとに384バイト（どちらか大きい方）だけ、送信バジェットを増加してはなりません（SHOULD NOT）。 800ミリ秒。ただし、送信者自身が現在タイムクリティカルなデータを遠端に送信している場合を除きます。
RTMFP uses the ERTO to detect when a user data fragment has been lost in the network. The ERTO is typically calculated in a manner similar to that specified in "Requirements for Internet Hosts - Communication Layers" [RFC1122] and is a function of round-trip time measurements and persistent timeout behavior.
RTMFPはERTOを使用して、ユーザーデータフラグメントがネットワークで失われたことを検出します。 ERTOは通常、「インターネットホストの要件-通信層」[RFC1122]で指定された方法と同様の方法で計算され、往復時間測定と永続的なタイムアウト動作の関数です。
The ERTO SHOULD be at least 250 milliseconds and SHOULD allow for the receiver to delay sending an acknowledgement for up to 200 milliseconds (Section 3.6.3.4.4). The ERTO MUST NOT be less than the round-trip time.
ERTOは少なくとも250ミリ秒である必要があり（SHOULD）、受信者が最大200ミリ秒（セクション3.6.3.4.4）の確認応答の送信を遅延できるようにする必要があります。 ERTOは往復時間より短くしてはなりません。
To facilitate round-trip time measurement, an endpoint MUST implement the Timestamp Echo facility:
ラウンドトリップ時間測定を容易にするために、エンドポイントはタイムスタンプエコー機能を実装する必要があります。
o On a session entering the S_OPEN state, initialize TS_RX_TIME to negative infinity, and initialize TS_RX and TS_ECHO_TX to have no value.
o S_OPEN状態に入るセッションで、TS_RX_TIMEを負の無限大に初期化し、TS_RXおよびTS_ECHO_TXを初期化して値をなくします。
o On receipt of a packet in an S_OPEN session with the timestampPresent (Section 2.2.4) flag set, if the timestamp field in the packet is different than TS_RX, set TS_RX to the value of the timestamp field in the packet, and set TS_RX_TIME to the current time.
o timestampPresent（セクション2.2.4）フラグが設定されたS_OPENセッションでパケットを受信したときに、パケットのタイムスタンプフィールドがTS_RXと異なる場合は、TS_RXをパケットのタイムスタンプフィールドの値に設定し、TS_RX_TIMEを現在の時刻。
o When sending a packet to the far end in an S_OPEN session:
o S_OPENセッションで遠端にパケットを送信する場合：
1. Calculate TS_RX_ELAPSED = current time - TS_RX_TIME. If TS_RX_ELAPSED is more than 128 seconds, then set TS_RX and TS_ECHO_TX to have no value, and do not include a timestamp echo; otherwise,
1. TS_RX_ELAPSED =現在の時刻-TS_RX_TIMEを計算します。 TS_RX_ELAPSEDが128秒を超える場合は、TS_RXおよびTS_ECHO_TXを値なしに設定し、タイムスタンプエコーを含めないでください。さもないと、
2. Calculate TS_RX_ELAPSED_TICKS to be the number of whole 4-millisecond periods in TS_RX_ELAPSED; then
2. TS_RX_ELAPSED_TICKSを計算して、TS_RX_ELAPSEDの4ミリ秒の期間全体の数になります。その後
3. Calculate TS_ECHO = (TS_RX + TS_RX_ELAPSED_TICKS) MODULO 65536; then
3. TS_ECHO =（TS_RX + TS_RX_ELAPSED_TICKS）MODULO 65536を計算します。その後
4. If TS_ECHO is not equal to TS_ECHO_TX, then set TS_ECHO_TX to TS_ECHO, set the timestampEchoPresent flag, and set the timestampEcho field to TS_ECHO_TX.
4. TS_ECHOがTS_ECHO_TXと等しくない場合は、TS_ECHO_TXをTS_ECHOに設定し、timestampEchoPresentフラグを設定し、timestampEchoフィールドをTS_ECHO_TXに設定します。
The remainder of this section describes an OPTIONAL method for calculating the ERTO. Real-time applications and P2P mesh applications often require knowing the round-trip time and RTT variance. This section additionally describes a method for measuring the round-trip time and RTT variance, and calculating a smoothed round-trip time.
このセクションの残りの部分では、ERTOを計算するためのオプションの方法について説明します。リアルタイムアプリケーションとP2Pメッシュアプリケーションでは、多くの場合、往復時間とRTT変動を知る必要があります。このセクションでは、往復時間とRTTの分散を測定し、平滑化された往復時間を計算する方法についても説明します。
Let the session information context contain additional variables:
セッション情報コンテキストに追加の変数を含めます。
o TS_TX: the last timestamp sent to the far end, initialized to have no value;
o TS_TX：値を持たないように初期化された、遠端に送信された最後のタイムスタンプ。
o TS_ECHO_RX: the last timestamp echo received from the far end, initialized to have no value;
o TS_ECHO_RX：値を持たないように初期化された、遠端から受信した最後のタイムスタンプエコー。
o SRTT: the smoothed round-trip time, initialized to have no value;
o SRTT：平滑化された往復時間。値を持たないように初期化されます。
o RTTVAR: the round-trip time variance, initialized to 0.
o RTTVAR：往復の時間変動。0に初期化されます。
Initialize MRTO to 250 milliseconds.
MRTOを250ミリ秒に初期化します。
Initialize ERTO to 3 seconds.
ERTOを3秒に初期化します。
On sending a packet to the far end of an S_OPEN session, if the current send timestamp is not equal to TS_TX, then set TS_TX to the current send timestamp, set the timestampPresent flag in the packet header, and set the timestamp field to TS_TX.
S_OPENセッションの遠端にパケットを送信するときに、現在の送信タイムスタンプがTS_TXと等しくない場合、TS_TXを現在の送信タイムスタンプに設定し、パケットヘッダーのtimestampPresentフラグを設定し、タイムスタンプフィールドをTS_TXに設定します。
On receipt of a packet from the far end of an S_OPEN session, if the timestampEchoPresent flag is set in the packet header, AND the timestampEcho field is not equal to TS_ECHO_RX, then:
S_OPENセッションの遠端からのパケットの受信時に、timestampEchoPresentフラグがパケットヘッダーに設定されていて、timestampEchoフィールドがTS_ECHO_RXと等しくない場合、次のようになります。
1. Set TS_ECHO_RX to timestampEcho;
1. TS_ECHO_RXをtimestampEchoに設定します。
2. Calculate RTT_TICKS = (current send timestamp - timestampEcho) MODULO 65536;
2. RTT_TICKS =（現在の送信タイムスタンプ-timestampEcho）MODULO 65536を計算します。
3. If RTT_TICKS is greater than 32767, the measurement is invalid, so discard this measurement; otherwise,
3. RTT_TICKSが32767より大きい場合、測定は無効であるため、この測定を破棄します。さもないと、
4. Calculate RTT = RTT_TICKS * 4 milliseconds;
4. RTT = RTT_TICKS * 4ミリ秒を計算します。
5. If SRTT has a value, then calculate new values of RTTVAR and SRTT:
5. SRTTに値がある場合、RTTVARとSRTTの新しい値を計算します。
1. RTT_DELTA = | SRTT - RTT |;
1. RTT_DELTA = | SRTT-RTT |;
2. RTTVAR = ((3 * RTTVAR) + RTT_DELTA) / 4;
2. RTTVAR =（（3 * RTTVAR）+ RTT_DELTA）/ 4;
3. SRTT = ((7 * SRTT) + RTT) / 8.
3. SRTT =（（7 * SRTT）+ RTT）/ 8。
6. If SRTT has no value, then set SRTT = RTT and RTTVAR = RTT / 2;
6. SRTTに値がない場合は、SRTT = RTTおよびRTTVAR = RTT / 2に設定します。
7. Set MRTO = SRTT + 4 * RTTVAR + 200 milliseconds;
7. MRTO = SRTT + 4 * RTTVAR + 200ミリ秒に設定します。
8. Set ERTO to MRTO or 250 milliseconds, whichever is greater.
8. ERTOをMRTOまたは250ミリ秒のいずれか大きい方に設定します。
A retransmission timeout occurs when the most recently transmitted user data fragment has remained outstanding in the network for ERTO. When this timeout occurs, increase ERTO on an exponential backoff with an ultimate backoff cap of 10 seconds:
再送信タイムアウトは、最後に送信されたユーザーデータフラグメントがERTOのネットワークで未処理のままである場合に発生します。このタイムアウトが発生した場合、最終的なバックオフキャップが10秒の指数バックオフでERTOを増やします。
1. Calculate ERTO_BACKOFF = ERTO * 1.4142;
1. ERTO_BACKOFF = ERTO * 1.4142を計算します。
2. Calculate ERTO_CAPPED to be ERTO_BACKOFF or 10 seconds, whichever is less;
2. ERTO_CAPPEDを計算して、ERTO_BACKOFFまたは10秒のいずれか短い方にしてください。
3. Set ERTO to ERTO_CAPPED or MRTO, whichever is greater.
3. ERTOをERTO_CAPPEDまたはMRTOのいずれか大きい方に設定します。
An application's sending patterns may cause the transmission budget to grow to a large value, but at times its sending patterns will result in a comparatively small amount of data outstanding in the network. In this circumstance, especially with a window-based congestion avoidance algorithm, if the application then has a large amount of new data to send (for example, a new bulk data transfer), it could send data into the network all at once to fill the window. This kind of transmission burst is undesirable, however, because it can jam interfaces, links, and buffers.
アプリケーションの送信パターンにより、送信バジェットが大きな値になることがありますが、その送信パターンにより、ネットワークで未処理のデータ量が比較的少なくなる場合があります。この状況では、特にウィンドウベースの輻輳回避アルゴリズムでは、アプリケーションが大量の新しいデータを送信する場合（たとえば、新しいバルクデータ転送）、データを一度にネットワークに送信してデータをいっぱいにすることができます。窓。ただし、この種類の送信バーストは、インターフェイス、リンク、およびバッファを妨害する可能性があるため、望ましくありません。
Accordingly, in any session, an endpoint SHOULD NOT send more than six packets containing user data between receiving any acknowledgements or retransmission timeouts.
したがって、どのセッションでも、エンドポイントは、確認応答または再送信タイムアウトを受信する間に、ユーザーデータを含む6つ以上のパケットを送信してはなりません（SHOULD NOT）。
The following describes an OPTIONAL method to avoid bursting large numbers of packets into the network:
以下に、ネットワークへの大量のパケットのバーストを回避するためのオプションの方法について説明します。
Let the session information context contain an additional variable DATA_PACKET_COUNT, initialized to 0.
セッション情報コンテキストに、0に初期化された追加の変数DATA_PACKET_COUNTが含まれるようにします。
Transmission of a user data fragment on this session is not allowed if DATA_PACKET_COUNT is greater than or equal to 6, regardless of any other allowance of the congestion control algorithm.
DATA_PACKET_COUNTが6以上の場合、輻輳制御アルゴリズムの他の許可に関係なく、このセッションでのユーザーデータフラグメントの送信は許可されません。
On transmission of a packet containing at least one User Data chunk (Section 2.3.11), set DATA_PACKET_COUNT = DATA_PACKET_COUNT + 1.
少なくとも1つのユーザーデータチャンク（2.3.11節）を含むパケットの送信時に、DATA_PACKET_COUNT = DATA_PACKET_COUNT + 1を設定します。
On receipt of an acknowledgement chunk (Sections 2.3.13 and 2.3.14), set DATA_PACKET_COUNT to 0.
確認応答チャンクを受信したら（セクション2.3.13および2.3.14）、DATA_PACKET_COUNTを0に設定します。
On a retransmission timeout, set DATA_PACKET_COUNT to 0.
再送信タイムアウト時に、DATA_PACKET_COUNTを0に設定します。
Sessions are demultiplexed with a 32-bit session ID, rather than by endpoint address. This allows an endpoint's address to change during an S_OPEN session. This can happen, for example, when switching from a wireless to a wired network, or when moving from one wireless base station to another, or when a NAT restarts.
セッションは、エンドポイントアドレスではなく、32ビットセッションIDで逆多重化されます。これにより、S_OPENセッション中にエンドポイントのアドレスを変更できます。これは、たとえば、ワイヤレスネットワークから有線ネットワークに切り替えるとき、1つのワイヤレスベースステーションから別のベースステーションに移動するとき、またはNATが再起動するときに発生する可能性があります。
If the near end receives a valid packet for an S_OPEN session from a source address that doesn't match DESTADDR, the far end might have changed addresses. The near end SHOULD verify that the far end is definitively at the new address before changing DESTADDR. A suggested verification method is described in Section 3.5.4.2.
近端がDESTADDRと一致しない送信元アドレスからS_OPENセッションの有効なパケットを受信した場合、遠端がアドレスを変更している可能性があります。 DESTADDRを変更する前に、近端は遠端が確実に新しいアドレスにあることを確認する必要があります。推奨される検証方法は、セクション3.5.4.2で説明されています。
If an endpoint receives a Ping chunk (Section 2.3.9) in a session in the S_OPEN state, it SHOULD construct and send a Ping Reply chunk (Section 2.3.10) in response if possible, copying the message unaltered. The Ping Reply SHOULD be sent as quickly as possible following receipt of a Ping. The semantics of a Ping's message is reserved for the sender; a receiver SHOULD NOT interpret the Ping's message.
エンドポイントがS_OPEN状態のセッションでPingチャンク（セクション2.3.9）を受信した場合、可能であれば応答としてPing応答チャンク（セクション2.3.10）を構築して送信し、メッセージを変更せずにコピーする必要があります。 Ping応答は、Pingの受信後、可能な限り迅速に送信する必要があります（SHOULD）。 Pingのメッセージのセマンティクスは送信者用に予約されています。受信者はPingのメッセージを解釈すべきではありません（SHOULD NOT）。
Endpoints can use the mechanism of the Ping chunk and the expected Ping Reply for any purpose. This specification doesn't mandate any specific constraints on the format or semantics of a Ping message. A Ping Reply MUST be sent only as a response to a Ping.
エンドポイントは、任意の目的でPingチャンクのメカニズムと予想されるPing応答を使用できます。この仕様では、Pingメッセージの形式やセマンティクスに特定の制約を課していません。 Ping応答は、Pingへの応答としてのみ送信する必要があります。
Receipt of a Ping Reply implies live bidirectional connectivity. This specification doesn't mandate any other semantics for a Ping Reply.
Ping応答の受信は、ライブの双方向接続を意味します。この仕様では、Ping応答のその他のセマンティクスは必須ではありません。
An endpoint can use a Ping to test for live bidirectional connectivity, to test that the far end of a session is still in the S_OPEN state, to keep NAT translations alive, and to keep firewall holes open.
エンドポイントはPingを使用して、ライブの双方向接続をテストし、セッションの遠端がまだS_OPEN状態であることをテストし、NAT変換を維持し、ファイアウォールホールを開いたままにします。
An endpoint can use a Ping to hasten detection of a near-end address change by the far end.
エンドポイントはPingを使用して、遠端による近端アドレス変更の検出を速めることができます。
An endpoint may declare a session to be defunct and dead after a persistent failure by the far end to return Ping Replies in response to Pings.
エンドポイントは、Pingに応答してPing応答を返すために、遠端で永続的な障害が発生した後、セッションが非アクティブであると宣言する場合があります。
If used for these purposes, a Keepalive Ping SHOULD have an empty message.
これらの目的で使用する場合、キープアライブpingには空のメッセージが必要です（SHOULD）。
A Keepalive Ping SHOULD NOT be sent more often than once per ERTO. If a corresponding Ping Reply is not received within ERTO of sending the Ping, ERTO SHOULD be increased according to Section 3.5.2 ("Congestion Control").
キープアライブpingは、ERTOごとに複数回送信するべきではありません。対応するPing応答がpingを送信したERTO内で受信されない場合、ERTOはセクション3.5.2（「輻輳制御」）に従って増加する必要があります。
This section describes an OPTIONAL but suggested method for processing and verifying a far-end address change.
このセクションでは、オプションですが、遠端アドレスの変更を処理および確認するための推奨方法について説明します。
Let the session context contain additional variables MOB_TX_TS, MOB_RX_TS, and MOB_SECRET. MOB_TX_TS and MOB_RX_TS have initial values of negative infinity. MOB_SECRET should be a cryptographically pseudorandom value not less than 128 bits in length and known only to this end.
セッションコンテキストに追加の変数MOB_TX_TS、MOB_RX_TS、およびMOB_SECRETを含めます。 MOB_TX_TSおよびMOB_RX_TSの初期値は負の無限大です。 MOB_SECRETは、128ビット以上の長さの暗号化された疑似ランダム値であり、この目的でのみ知られている必要があります。
On receipt of a packet for an S_OPEN session, after processing all chunks in the packet: if the session is still in the S_OPEN state, AND the source address of the packet does not match DESTADDR, AND MOB_TX_TS is at least one second in the past, then:
S_OPENセッションのパケットを受信したとき、パケット内のすべてのチャンクを処理した後：セッションがまだS_OPEN状態であり、かつパケットの送信元アドレスがDESTADDRと一致せず、MOB_TX_TSが過去1秒以上である場合、次に：
1. Set MOB_TX_TS to the current time;
1. MOB_TX_TSを現在の時刻に設定します。
2. Construct a Ping message comprising the following: a marking to indicate (to this end when returned in a Ping Reply) that it is a mobility check (for example, the first byte being ASCII 'M' for "Mobility"), a timestamp set to MOB_TX_TS, and a cryptographic hash over the following: the preceding items, the address from which the packet was received, and MOB_SECRET; and
2. 次を含むPingメッセージを作成します：（Ping応答で返されたときにこの目的のために）モビリティチェックであることを示すマーキング（たとえば、最初のバイトは「モビリティ」のASCII 'M'です）、タイムスタンプセットMOB_TX_TS、および次の暗号化ハッシュ：前の項目、パケットの受信元のアドレス、およびMOB_SECRET。そして
3. Send this Ping to the address from which the packet was received, instead of DESTADDR.
3. このPingを、DESTADDRではなく、パケットの受信元のアドレスに送信します。
On receipt of a Ping Reply in an S_OPEN session, if the Ping Reply's message satisfies all of these conditions:
S_OPENセッションでPing返信を受信したとき、Ping返信のメッセージが次のすべての条件を満たす場合：
o it has this end's expected marking to indicate that it is a mobility check, and
o これは、モビリティチェックであることを示すために、この端の予想されるマーキングを持っています。
o the timestamp in the message is not more than 120 seconds in the past, and
o メッセージのタイムスタンプが過去120秒以下であり、かつ
o the timestamp in the message is greater than MOB_RX_TS, and
o メッセージのタイムスタンプがMOB_RX_TSより大きい、および
o the cryptographic hash matches the expected value according to the contents of the message plus the source address of the packet containing this Ping Reply and MOB_SECRET,
o 暗号化ハッシュは、メッセージの内容と、このPing応答およびMOB_SECRETを含むパケットの送信元アドレスに従って、期待値と一致します。
then:
次に：
1. Set MOB_RX_TS to the timestamp in the message; and
1. MOB_RX_TSをメッセージのタイムスタンプに設定します。そして
2. Set DESTADDR to the source address of the packet containing this Ping Reply.
2. DESTADDRを、このPing応答を含むパケットの送信元アドレスに設定します。
"Packetization Layer Path MTU Discovery" [RFC4821] describes a method for measuring the path MTU between communicating endpoints.
「Packetization Layer Path MTU Discovery」[RFC4821]では、通信するエンドポイント間のパスMTUを測定する方法について説明しています。
An RTMFP SHOULD perform path MTU discovery.
RTMFPは、パスMTU検出を実行する必要があります（SHOULD）。
The method described in RFC 4821 can be adapted for use in RTMFP by sending a probe packet comprising one of the Padding chunk types (type 0x00 or 0xff) and a Ping. The Ping chunk SHOULD come after the Padding chunk, to guard against a false positive response in case the probe packet is truncated.
RFC 4821で説明されている方法は、パッディングチャンクタイプ（タイプ0x00または0xff）の1つとPingを含むプローブパケットを送信することにより、RTMFPでの使用に適合させることができます。 Pingチャンクは、プローブパケットが切り捨てられた場合の誤検知から保護するために、Paddingチャンクの後に来る必要があります（SHOULD）。
An endpoint may close a session at any time. Typically, an endpoint will close a session when there have been no open flows in either direction for a time. In another circumstance, an endpoint may be ceasing operation and will close all of its sessions even if they have open flows.
エンドポイントはいつでもセッションを閉じることができます。通常、エンドポイントは、どちらかの方向に開いているフローがしばらくなかった場合にセッションを閉じます。別の状況では、エンドポイントが操作を停止している可能性があり、フローが開いていても、すべてのセッションを閉じます。
To close an S_OPEN session in a reliable and orderly fashion, an endpoint moves the session to the S_NEARCLOSE state.
S_OPENセッションを信頼性の高い規則的な方法で閉じるために、エンドポイントはセッションをS_NEARCLOSE状態に移行します。
On a session transitioning from S_OPEN to S_NEARCLOSE and every 5 seconds thereafter while still in the S_NEARCLOSE state, send a Session Close Request chunk (Section 2.3.17).
S_OPENからS_NEARCLOSEに移行するセッションで、その後S_NEARCLOSE状態のまま5秒ごとに、Session Close Requestチャンクを送信します（セクション2.3.17）。
A session that has been in the S_NEARCLOSE state for at least 90 seconds (allowing time to retransmit the Session Close Request multiple times) SHOULD move to the S_CLOSED state.
少なくとも90秒間S_NEARCLOSE状態にあったセッション（セッションクローズリクエストを複数回再送信できる時間を許容）は、S_CLOSED状態に移行する必要があります（SHOULD）。
On a session transitioning from S_OPEN to the S_NEARCLOSE, S_FARCLOSE_LINGER or S_CLOSED state, immediately abort and terminate all open or closing flows. Flows only exist in S_OPEN sessions.
S_OPENからS_NEARCLOSE、S_FARCLOSE_LINGERまたはS_CLOSED状態に移行するセッションでは、すべてのオープンまたはクローズフローをただちに中止して終了します。フローはS_OPENセッションにのみ存在します。
To close an S_OPEN session abruptly, send a Session Close Acknowledgement chunk (Section 2.3.18), then move to the S_CLOSED state.
S_OPENセッションを突然閉じるには、Session Close Acknowledgementチャンクを送信し（セクション2.3.18）、S_CLOSED状態に移行します。
On receipt of a Session Close Request chunk for a session in the S_OPEN, S_NEARCLOSE, or S_FARCLOSE_LINGER states, send a Session Close Acknowledgement chunk; then, if the session is in the S_OPEN state, move to the S_FARCLOSE_LINGER state.
S_OPEN、S_NEARCLOSE、またはS_FARCLOSE_LINGER状態のセッションのSession Close Requestチャンクを受信すると、Session Close Acknowledgementチャンクを送信します。次に、セッションがS_OPEN状態の場合は、S_FARCLOSE_LINGER状態に移行します。
A session that has been in the S_FARCLOSE_LINGER state for at least 19 seconds (allowing time to answer 3 retransmissions of a Session Close Request) SHOULD move to the S_CLOSED state.
少なくとも19秒間S_FARCLOSE_LINGER状態にあるセッション（セッションクローズリクエストの3回の再送信に応答する時間がある）は、S_CLOSED状態に移行する必要があります（SHOULD）。
On receipt of a Session Close Acknowledgement chunk for a session in the S_OPEN, S_NEARCLOSE, or S_FARCLOSE_LINGER states, move to the S_CLOSED state.
S_OPEN、S_NEARCLOSE、またはS_FARCLOSE_LINGER状態のセッションのSession Close Acknowledgementチャンクを受信すると、S_CLOSED状態に移行します。
A flow is a unidirectional communication channel in a session for transporting a correlated series of user messages from a sender to a receiver. Each end of a session may have zero or more sending flows to the other end. Each sending flow at one end has a corresponding receiving flow at the other end.
フローは、相関関係のある一連のユーザーメッセージを送信者から受信者に転送するためのセッション内の一方向通信チャネルです。セッションの両端には、もう一方の端への送信フローがゼロ以上ある場合があります。一端の各送信フローには、他端に対応する受信フローがあります。
Flows are multiplexed in a session by a flow identifier. Each end of a session chooses its sending flow identifiers independently of the other end. The choice of similar flow identifiers by both ends does not imply an association. A sender MAY choose any identifier for any flow; therefore, a flow receiver MUST NOT ascribe any semantic meaning, role, or name to a flow based only on its identifier. There are no "well known" or reserved flow identifiers.
フローは、セッション内でフロー識別子によって多重化されます。セッションの両端は、他端とは無関係に送信フロー識別子を選択します。両端で同様のフロー識別子を選択しても、関連付けを意味するわけではありません。送信者は、任意のフローの任意の識別子を選択できます。したがって、フローレシーバーは、識別子のみに基づいてフローに意味的な意味、役割、または名前を割り当ててはなりません（MUST NOT）。 「既知の」または予約済みのフロー識別子はありません。
Bidirectional flow association is indicated at flow startup with the Return Flow Association option (Section 2.3.11.1.2). An endpoint can indicate that a new sending flow is in return (or response) to a receiving flow from the other end. A sending flow MUST NOT indicate more than one return association. A receiving flow can be specified as the return association for any number of sending flows. The return flow association, if any, is fixed for the lifetime of the sending flow. Note: Closure of one flow in an association does not automatically close other flows in the association, except as specified in Section 3.6.3.1.
双方向のフローの関連付けは、フローの開始時にReturn Flow Associationオプション（セクション2.3.11.1.2）で示されます。エンドポイントは、新しい送信フローが相手側からの受信フローの見返り（または応答）であることを示すことができます。送信フローは、複数のリターンアソシエーションを示してはなりません。受信フローは、任意の数の送信フローのリターンアソシエーションとして指定できます。リターンフローの関連付けがある場合は、送信フローのライフタイムの間固定されます。注：セクション3.6.3.1で指定されている場合を除き、アソシエーション内の1つのフローを閉じても、アソシエーション内の他のフローは自動的に閉じません。
Flows are named with arbitrary user metadata. This specification doesn't mandate any particular encoding, syntax, or semantics for the user metadata, except for the encoded size (Section 2.3.11.1.1); the user metadata is entirely reserved for the application. The user metadata is fixed for the lifetime of the flow.
フローには、任意のユーザーメタデータを使用して名前が付けられます。この仕様では、エンコードされたサイズ（セクション2.3.11.1.1）を除いて、ユーザーメタデータの特定のエンコード、構文、またはセマンティクスを義務付けていません。ユーザーメタデータは完全にアプリケーション用に予約されています。ユーザーメタデータは、フローの存続期間中固定されています。
Flows provide message-oriented framing. Large messages are fragmented for transport in the network. Receivers reassemble fragmented messages and only present complete messages to the user.
フローはメッセージ指向のフレーミングを提供します。大きなメッセージは、ネットワークでの転送のために断片化されます。受信者は断片化されたメッセージを再構成し、完全なメッセージのみをユーザーに提示します。
A sender queues messages on a sending flow one after another. A receiver can recover the original queuing order of the messages, even when they are reordered in transit by the network or as a result of loss and retransmission, by means of the messages' fragment sequence numbers. Flows are the basic units of message sequencing; each flow is sequenced independently of all other flows; inter-flow message arrival and delivery sequencing are not guaranteed.
送信者は、送信フローのメッセージを次々にキューに入れます。受信者は、メッセージのフラグメントシーケンス番号を使用して、ネットワークで転送中に再順序付けされた場合や、損失と再送信の結果として、メッセージの元のキューイング順序を回復できます。フローはメッセージシーケンスの基本単位です。各フローは、他のすべてのフローとは無関係に順序付けられます。フロー間メッセージの到着と配信の順序付けは保証されません。
Independent flow sequencing allows a sender to prioritize the transmission or retransmission of the messages of one flow over those of other flows in a session, allocating capacity from the transmission budget according to priority. RTMFP is designed for flows to be the basic unit of prioritization. In any flow, fragment sequence numbers are unique and monotonically increasing; that is, the fragment sequence numbers for any message MUST be greater than the fragment sequence numbers of all messages previously queued in that flow. Receipt of fragments out of sequence number order within a flow creates discontiguous gaps at the receiver, causing it to send an acknowledgement for every packet and also causing the size of the encoded acknowledgements to grow. Therefore, for any flow, the sender SHOULD send lower sequence numbers first.
独立したフローシーケンスにより、送信者はセッション内の他のフローのメッセージよりも1つのフローのメッセージの送信または再送信を優先し、優先度に従って送信バジェットから容量を割り当てることができます。 RTMFPは、フローが優先順位付けの基本単位になるように設計されています。どのフローでも、フラグメントのシーケンス番号は一意で単調に増加します。つまり、メッセージのフラグメントシーケンス番号は、そのフローで以前にキューに入れられたすべてのメッセージのフラグメントシーケンス番号よりも大きい必要があります。フロー内のシーケンス番号順以外のフラグメントを受信すると、レシーバーに不連続なギャップが生じ、パケットごとに確認応答が送信され、エンコードされた確認応答のサイズも大きくなります。したがって、どのフローでも、送信者は最初に小さいシーケンス番号を送信する必要があります（SHOULD）。
A sender can abandon a queued message at any time, even if some fragments of that message have been received by the other end. A receiver MUST be able to detect a gap in the flow when a message is abandoned; therefore, each message SHOULD take at least one sequence number from the sequence space even if no fragments for that message are ever sent. The sender will transmit the fragments of all messages not abandoned, and retransmit any lost fragments of all messages not abandoned, until all the fragments of all messages not abandoned are acknowledged by the receiver. A sender indicates a Forward Sequence Number (FSN) to instruct the receiver that sequence numbers less than or equal to the FSN will not be transmitted or retransmitted. This allows the receiver to move forward over gaps and continue sequenced delivery of completely received messages to the user. Any incomplete messages missing fragments with sequence numbers less than or equal to the FSN were abandoned by the sender and will never be completed. A gap indication MUST be communicated to the receiving user.
送信者は、キューに入れられたメッセージの一部が相手側で受信されていても、いつでもキューに入れられたメッセージを破棄できます。受信者は、メッセージが破棄されたときにフローのギャップを検出できなければなりません（MUST）。したがって、そのメッセージのフラグメントが送信されない場合でも、各メッセージはシーケンススペースから少なくとも1つのシーケンス番号を取得する必要があります（SHOULD）。放棄されていないすべてのメッセージのフラグメントが受信者によって確認されるまで、送信者は放棄されていないすべてのメッセージのフラグメントを送信し、放棄されていないすべてのメッセージの失われたフラグメントを再送信します。送信者は、FSN以下のシーケンス番号が送信または再送信されないことを受信者に指示するために、転送シーケンス番号（FSN）を示します。これにより、受信者はギャップを越えて前進し、完全に受信されたメッセージをユーザーに順次配信し続けることができます。 FSN以下のシーケンス番号を持つフラグメントが欠落している不完全なメッセージは、送信者によって破棄され、決して完了しません。ギャップ表示は、受信ユーザーに通知されなければなりません。
A sender begins a flow by sending user message fragments to the other end, and including the user metadata and, if any, the return flow association. The sender continues to include the user metadata and return flow association until the flow is acknowledged by the far end, at which point the sender knows that the receiver has received the user metadata and, if any, the return flow association. After that point, the flow identifier alone is sufficient.
送信者は、ユーザーメッセージフラグメントを相手側に送信し、ユーザーメタデータと、もしあればリターンフローの関連付けを含めて、フローを開始します。送信側は、フローが遠端で確認されるまで、ユーザーメタデータと戻りフローの関連付けを続けます。その時点で、送信側は、受信者がユーザーメタデータと、もしあれば戻りフローの関連付けを受信したことを認識します。その後は、フロー識別子だけで十分です。
Flow receivers SHOULD acknowledge all sequence numbers received for any flow, whether the flow is accepted or rejected. Flow receivers MUST NOT acknowledge sequence numbers higher than the FSN that were not received. Acknowledgements drive the congestion control and avoidance algorithms and therefore must be accurate.
フローレシーバーは、フローが受け入れられるか拒否されるかにかかわらず、任意のフローに対して受信されたすべてのシーケンス番号を確認する必要があります。フローレシーバーは、受信されなかったFSNよりも大きいシーケンス番号を確認してはなりません（MUST NOT）。承認は、輻輳制御および回避アルゴリズムを推進するため、正確でなければなりません。
An endpoint can reject a receiving flow at any time in the flow's lifetime. To reject the flow, the receiving endpoint sends a Flow Exception Report chunk (Section 2.3.16) immediately preceding every acknowledgement chunk for the rejected receiving flow.
エンドポイントは、フローの存続期間中いつでも受信フローを拒否できます。フローを拒否するために、受信エンドポイントは、拒否された受信フローのすべての確認応答チャンクの直前にフロー例外レポートチャンク（2.3.16節）を送信します。
An endpoint may eventually conclude and close a sending flow. The last sequence number of the flow is marked with the Final flag. The sending flow is complete when all sequence numbers of the flow, including the final sequence number, have been cumulatively acknowledged by the receiver. The receiving flow is complete when every sequence number from the FSN to the final sequence number has been received. The sending flow and corresponding receiving flow at the respective ends hold the flow identifier of a completed flow in reserve for a time to allow delayed or duplicated fragments and acknowledgements to drain from the network without erroneously initiating a new receiving flow or erroneously acknowledging a new sending flow.
エンドポイントは最終的に送信フローを完了して閉じる場合があります。フローの最後のシーケンス番号は、Finalフラグでマークされます。最終シーケンス番号を含むフローのすべてのシーケンス番号が受信者によって累積的に確認されると、送信フローは完了です。 FSNから最終シーケンス番号までのすべてのシーケンス番号が受信されると、受信フローが完了します。それぞれの端での送信フローと対応する受信フローは、新しい受信フローを誤って開始したり、新しい送信を誤って確認したりせずに、遅延または複製されたフラグメントと確認応答をネットワークから排出できるように、完了したフローのフロー識別子を一定時間確保します。フロー。
If a flow sender receives a Flow Exception indication from the other end, the flow sender SHOULD close the flow and abandon all of the undelivered queued messages. The flow sender SHOULD indicate an exception to the user.
フローセンダーがもう一方の端からフロー例外の指示を受信した場合、フローセンダーはフローを閉じて、配信されなかったすべてのキューに入れられたメッセージを破棄する必要があります。フロー送信者は、ユーザーに例外を示す必要があります（SHOULD）。
Each sending flow comprises the flow-specific information context necessary to transfer that flow's messages to the other end. Each sending flow context includes at least:
各送信フローは、そのフローのメッセージを相手側に転送するために必要なフロー固有の情報コンテキストで構成されます。各送信フローコンテキストには、少なくとも次のものが含まれます。
o F_FLOW_ID: this flow's identifier;
o F_FLOW_ID：このフローの識別子。
o STARTUP_OPTIONS: the set of options to send to the receiver until this flow is acknowledged, including the User's Per-Flow Metadata and, if set, the Return Flow Association;
o STARTUP_OPTIONS：このフローが確認されるまで受信者に送信するオプションのセット。ユーザーのフローごとのメタデータと、設定されている場合はリターンフローの関連付けを含みます。
o SEND_QUEUE: the unacknowledged message fragments queued in this flow, initially empty; each message fragment entry comprising the following:
o SEND_QUEUE：このフローでキューに入れられた未確認のメッセージフラグメント。最初は空です。以下を含む各メッセージフラグメントエントリ：
* SEQUENCE_NUMBER: the sequence number of this fragment;
* SEQUENCE_NUMBER：このフラグメントのシーケンス番号。
* DATA: this fragment's user data;
* DATA：このフラグメントのユーザーデータ。
* FRA: the fragment control value for this message fragment, having one of the values enumerated for that purpose in Section 2.3.11 ("User Data Chunk");
* FRA：このメッセージフラグメントのフラグメント制御値。セクション2.3.11（「ユーザーデータチャンク」）でその目的のために列挙された値の1つを持ちます。
* ABANDONED: a boolean flag indicating whether this fragment has been abandoned;
* ABANDONED：このフラグメントが破棄されたかどうかを示すブールフラグ。
* SENT_ABANDONED: a boolean flag indicating whether this fragment was abandoned when sent;
* SENT_ABANDONED：このフラグメントが送信時に破棄されたかどうかを示すブールフラグ。
* EVER_SENT: a boolean flag indicating whether this fragment has been sent at least once, initially false;
* EVER_SENT：このフラグメントが少なくとも1回送信されたかどうかを示すブールフラグ。最初はfalse。
* NAK_COUNT: a count of the number of negative acknowledgements detected for this fragment, initially 0;
* NAK_COUNT：このフラグメントに対して検出された否定応答の数のカウント。最初は0。
* IN_FLIGHT: a boolean flag indicating whether this fragment is currently outstanding, or in flight, in the network, initially false;
* IN_FLIGHT：このフラグメントがネットワークで現在未解決であるか、処理中かを示すブールフラグ。最初はfalse。
* TRANSMIT_SIZE: the size, in bytes, of the encoded User Data chunk (including the chunk header) for this fragment when it was transmitted into the network.
* TRANSMIT_SIZE：このフラグメントがネットワークに送信されたときの、このフラグメントのエンコードされたユーザーデータチャンク（チャンクヘッダーを含む）のサイズ（バイト単位）。
o F_OUTSTANDING_BYTES: the sum of the TRANSMIT_SIZE of each entry in SEND_QUEUE where entry.IN_FLIGHT is true;
o F_OUTSTANDING_BYTES：SEND_QUEUEの各エントリのTRANSMIT_SIZEの合計。ここで、entry.IN_FLIGHTはtrueです。
o RX_BUFFER_SIZE: the most recent available buffer advertisement from the other end (Sections 2.3.13 and 2.3.14), initially 65536 bytes;
o RX_BUFFER_SIZE：もう一方の端からの利用可能な最新のバッファー通知（セクション2.3.13および2.3.14）、最初は65536バイト。
o NEXT_SN: the next sequence number to assign to a message fragment, initially 1;
o NEXT_SN：メッセージフラグメントに割り当てる次のシーケンス番号。最初は1。
o F_FINAL_SN: the sequence number assigned to the final message fragment of the flow, initially having no value;
o F_FINAL_SN：フローの最後のメッセージフラグメントに割り当てられたシーケンス番号。最初は値がありません。
o EXCEPTION: a boolean flag indicating whether an exception has been reported by the receiver, initially false;
o EXCEPTION：レシーバーによって例外が報告されたかどうかを示すブールフラグ。最初はfalse。
o The state, at any time being one of the following values: the open state F_OPEN; the closing states F_CLOSING and F_COMPLETE_LINGER; and the closed state F_CLOSED.
o 常に次のいずれかの値の状態。オープン状態F_OPEN;終了状態F_CLOSINGおよびF_COMPLETE_LINGER;閉じた状態F_CLOSED。
Note: The following diagram is only a summary of state transitions and their causing events, and is not a complete operational specification.
注：以下の図は、状態遷移とその原因となるイベントの要約にすぎず、完全な運用仕様ではありません。
+--------+
| F_OPEN |
+--------+
|CLOSE or
|rcv Flow Exception
|
v
+---------+
|F_CLOSING|
+---------+
|rcv Data Ack
| 0..F_FINAL_SN
v
+-----------------+
|F_COMPLETE_LINGER|
+-----------------+
| 130 seconds
v
+--------+
|F_CLOSED|
+--------+
Figure 19: Sending Flow State Diagram
図19：フロー状態図の送信
The application opens a new sending flow to the other end in an S_OPEN session. The implementation chooses a new flow ID that is not assigned to any other sending flow in that session in the F_OPEN, F_CLOSING, or F_COMPLETE_LINGER states. The flow starts in the F_OPEN state. The STARTUP_OPTIONS for the new flow is set with the User's Per-Flow Metadata (Section 2.3.11.1.1). If this flow is in return (or response) to a receiving flow from the other end, that flow's ID is encoded in a Return Flow Association (Section 2.3.11.1.2) option and added to STARTUP_OPTIONS. A new sending flow SHOULD NOT be opened in response to a receiving flow from the other end that is not in the RF_OPEN state when the sending flow is opened.
アプリケーションは、S_OPENセッションで、もう一方の端への新しい送信フローを開きます。実装は、F_OPEN、F_CLOSING、またはF_COMPLETE_LINGER状態で、そのセッションの他の送信フローに割り当てられていない新しいフローIDを選択します。フローはF_OPEN状態で開始されます。新しいフローのSTARTUP_OPTIONSは、ユーザーのフローごとのメタデータで設定されます（セクション2.3.11.1.1）。このフローが相手側からの受信フローへの返信（または応答）である場合、そのフローのIDはReturn Flow Association（セクション2.3.11.1.2）オプションでエンコードされ、STARTUP_OPTIONSに追加されます。送信フローが開かれるときにRF_OPEN状態にない他端からの受信フローに応答して、新しい送信フローを開く必要があります（SHOULD NOT）。
At this point, the flow exists in the sender but not in the receiver. The flow begins when user data fragments are transmitted to the receiver. A sender can begin a flow in the absence of immediate user data by sending a Forward Sequence Number Update (Section 3.6.2.7.1), by queuing and transmitting a user data fragment that is already abandoned.
この時点で、フローは送信側に存在しますが、受信側には存在しません。フローは、ユーザーデータフラグメントが受信者に送信されたときに始まります。送信者は、すでに破棄されているユーザーデータフラグメントをキューに入れて送信することにより、転送シーケンス番号更新（3.6.2.7.1項）を送信することにより、即時のユーザーデータがない場合にフローを開始できます。
The application queues messages in an F_OPEN sending flow for transmission to the far end. The implementation divides each message into one or more fragments for transmission in User Data chunks (Section 2.3.11). Each fragment MUST be small enough so that, if assembled into a packet (Section 2.2.4) with a maximum-size common header, User Data chunk header, and, if not empty, this flow's STARTUP_OPTIONS, the packet will not exceed the path MTU (Section 3.5.4.3).
アプリケーションは、F_OPEN送信フローのメッセージをキューに入れ、遠端に送信します。実装では、ユーザーメッセージチャンクで送信するために、各メッセージを1つ以上のフラグメントに分割します（セクション2.3.11）。各フラグメントは、最大サイズの共通ヘッダー、ユーザーデータチャンクヘッダーを使用してパケット（セクション2.2.4）に組み立てられ、空でない場合、このフローのSTARTUP_OPTIONS、パケットがパスを超えないように、十分に小さい必要があります。 MTU（セクション3.5.4.3）。
For each fragment, create a fragment entry and set fragmentEntry.SEQUENCE_NUMBER to flow.NEXT_SN, and increment flow.NEXT_SN by one. Set fragmentEntry.FRA according to the encoding in User Data chunks:
フラグメントごとに、フラグメントエントリを作成し、fragmentEntry.SEQUENCE_NUMBERをflow.NEXT_SNに設定し、flow.NEXT_SNを1増やします。ユーザーデータチャンクのエンコーディングに従って、fragmentEntry.FRAを設定します。
0: This fragment is a complete message.
0：このフラグメントは完全なメッセージです。
1: This fragment is the first of a multi-fragment message.
1：このフラグメントは、マルチフラグメントメッセージの最初のものです。
2: This fragment is the last of a multi-fragment message.
2：このフラグメントは、マルチフラグメントメッセージの最後です。
3: This fragment is in the middle of a multi-fragment message.
3：このフラグメントは、マルチフラグメントメッセージの途中にあります。
Append fragmentEntry to flow.SEND_QUEUE.
fragmentEntryをflow.SEND_QUEUEに追加します。
A sending flow is ready to transmit if the SEND_QUEUE contains at least one entry that is eligible to send, and if either RX_BUFFER_SIZE is greater than F_OUTSTANDING_BYTES or EXCEPTION is set to true.
SEND_QUEUEに送信に適格なエントリが少なくとも1つ含まれ、RX_BUFFER_SIZEがF_OUTSTANDING_BYTESより大きいか、EXCEPTIONがtrueに設定されている場合、送信フローは送信の準備ができています。
A SEND_QUEUE entry is eligible to send if it is not IN_FLIGHT, AND at least one of the following conditions holds:
SEND_QUEUEエントリは、IN_FLIGHTでなく、次の条件の少なくとも1つが満たされた場合に送信できます。
o The entry is not ABANDONED; or
o エントリは放棄されていません。または
o The entry is the first one in the SEND_QUEUE; or
o エントリはSEND_QUEUEの最初のエントリです。または
o The entry's SEQUENCE_NUMBER is equal to flow.F_FINAL_SN.
o エントリのSEQUENCE_NUMBERは、flow.F_FINAL_SNと同じです。
If the session's transmission budget allows, a flow that is ready to transmit is selected for transmission according to the implementation's prioritization scheme. The manner of flow prioritization is not mandated by this specification.
セッションの送信バジェットが許可する場合、実装の優先順位付けスキームに従って、送信準備ができているフローが送信用に選択されます。フローの優先順位付けの方法は、この仕様では必須ではありません。
Trim abandoned messages from the front of the queue, and find the Forward Sequence Number (FSN):
キューの前から破棄されたメッセージをトリミングし、転送シーケンス番号（FSN）を見つけます。
1. While the SEND_QUEUE contains at least two entries, AND the first entry is not IN_FLIGHT, AND the first entry is ABANDONED, remove and discard the first entry from the SEND_QUEUE;
1. SEND_QUEUEに少なくとも2つのエントリが含まれ、かつ最初のエントリがIN_FLIGHTではなく、かつ最初のエントリがABANDONEDである場合、SEND_QUEUEから最初のエントリを削除して破棄します。
2. If the first entry in the SEND_QUEUE is not abandoned, set FSN to entry.SEQUENCE_NUMBER - 1; otherwise,
2. SEND_QUEUEの最初のエントリが破棄されない場合は、FSNをentry.SEQUENCE_NUMBER-1に設定します。さもないと、
3. If the first entry in the SEND_QUEUE is IN_FLIGHT, AND entry.SENT_ABANDONED is false, set FSN to entry.SEQUENCE_NUMBER - 1; otherwise,
3. SEND_QUEUEの最初のエントリがIN_FLIGHTであり、かつentry.SENT_ABANDONEDがfalseの場合、FSNをentry.SEQUENCE_NUMBER-1に設定します。さもないと、
4. The first entry in the SEND_QUEUE is abandoned and either is not IN_FLIGHT or was already abandoned when sent; set FSN to entry.SEQUENCE_NUMBER.
4. SEND_QUEUEの最初のエントリは破棄され、IN_FLIGHTではないか、送信時に既に破棄されています。 FSNをentry.SEQUENCE_NUMBERに設定します。
The FSN MUST NOT be greater than any sequence number currently outstanding. The FSN MUST NOT be equal to any sequence number currently outstanding that was not abandoned when sent.
FSNは、現在未解決のシーケンス番号より大きくてはなりません（MUST NOT）。 FSNは、送信時に破棄されなかった、現在未解決のシーケンス番号と同じであってはなりません（MUST NOT）。
Assemble user data chunks for this flow into a packet to send to the receiver. While enough space remains in the packet and the flow is ready to transmit:
このフローのユーザーデータチャンクをパケットにまとめて、レシーバーに送信します。パケットに十分なスペースが残っており、フローを送信する準備ができている間：
1. Starting at the head of the SEND_QUEUE, find the first eligible fragment entry;
1. SEND_QUEUEの先頭から始めて、最初の適格なフラグメントエントリを見つけます。
2. Encode the entry into a User Data chunk (Section 2.3.11) or, if possible (Section 3.6.2.3.2), a Next User Data chunk (Section 2.3.12);
2. エントリをユーザーデータチャンク（セクション2.3.11）、または可能であれば（セクション3.6.2.3.2）、次のユーザーデータチャンク（セクション2.3.12）にエンコードします。
3. If present, set chunk.flowID to flow.F_FLOW_ID;
3. 存在する場合は、chunk.flowIDをflow.F_FLOW_IDに設定します。
4. If present, set chunk.sequenceNumber to entry.SEQUENCE_NUMBER;
4. 存在する場合は、chunk.sequenceNumberをentry.SEQUENCE_NUMBERに設定します。
5. If present, set chunk.fsnOffset to entry.SEQUENCE_NUMBER - FSN;
5. 存在する場合は、chunk.fsnOffsetをentry.SEQUENCE_NUMBER-FSNに設定します。
6. Set chunk.fragmentControl to entry.FRA;
6. chunk.fragmentControlをentry.FRAに設定します。
7. Set chunk.abandon to entry.ABANDONED;
7. chunk.abandonをentry.ABANDONEDに設定します。
8. If entry.SEQUENCE_NUMBER equals flow.F_FINAL_SN, set chunk.final to true; else set chunk.final to false;
8. entry.SEQUENCE_NUMBERがflow.F_FINAL_SNと等しい場合、chunk.finalをtrueに設定します。それ以外の場合は、chunk.finalをfalseに設定します。
9. If any options are being sent with this chunk, set chunk.optionsPresent to true, assemble the options into the chunk, and assemble a Marker to terminate the option list;
9. このチャンクでオプションが送信されている場合は、chunk.optionsPresentをtrueに設定し、オプションをチャンクにアセンブルし、マーカーをアセンブルしてオプションリストを終了します。
10. If entry.ABANDONED is true, set chunk.userData to empty; otherwise, set chunk.userData to entry.DATA;
10. entry.ABANDONEDがtrueの場合、chunk.userDataを空に設定します。それ以外の場合は、chunk.userDataをentry.DATAに設定します。
11. If adding the assembled chunk to the packet would cause the packet to exceed the path MTU, do not assemble this chunk into the packet; enough space no longer remains in the packet; stop. Otherwise, continue:
11. 組み立てられたチャンクをパケットに追加すると、パケットがパスMTUを超える場合は、このチャンクをパケットに組み立てないでください。パケットに十分なスペースが残っていない。やめる。それ以外の場合は続行します。
12. Set entry.IN_FLIGHT to true;
12. entry.IN_FLIGHTをtrueに設定します。
13. Set entry.EVER_SENT to true;
13. entry.EVER_SENTをtrueに設定します。
14. Set entry.NAK_COUNT to 0;
14. entry.NAK_COUNTを0に設定します。
15. Set entry.SENT_ABANDONED to entry.ABANDONED;
15. entry.SENT_ABANDONEDをentry.ABANDONEDに設定します。
16. Set entry.TRANSMIT_SIZE to the size of the assembled chunk, including the chunk header;
16. entry.TRANSMIT_SIZEを、組み立てられたチャンクのサイズ（チャンクヘッダーを含む）に設定します。
17. Assemble this chunk into the packet; and
17. このチャンクをパケットに組み立てます。そして
18. If this flow or entry is considered Time Critical (real-time), set the timeCritical flag in the packet header (Section 2.2.4).
18. このフローまたはエントリがTime Critical（リアルタイム）と見なされる場合は、パケットヘッダーでtimeCriticalフラグを設定します（セクション2.2.4）。
Complete any other appropriate packet processing, and transmit the packet to the far end.
他の適切なパケット処理を完了し、パケットを遠端に送信します。
If STARTUP_OPTIONS is not empty, then when assembling the FIRST User Data chunk for this flow into a packet, add the encoded STARTUP_OPTIONS to that chunk's option list.
STARTUP_OPTIONSが空でない場合、このフローの最初のユーザーデータチャンクをパケットにアセンブルするときに、エンコードされたSTARTUP_OPTIONSをそのチャンクのオプションリストに追加します。
The Next User Data chunk (Section 2.3.12) is a compact encoding for a user message fragment when multiple contiguous fragments are assembled into one packet. Using this chunk where possible can conserve space in a packet, potentially reducing transmission overhead or allowing additional information to be sent in a packet.
次のユーザーデータチャンク（セクション2.3.12）は、複数の連続するフラグメントが1つのパケットにまとめられる場合のユーザーメッセージフラグメントのコンパクトなエンコーディングです。このチャンクを可能な限り使用すると、パケットのスペースを節約でき、送信オーバーヘッドを削減したり、パケットで追加情報を送信したりできるようになります。
If, after assembling a user message fragment of a flow into a packet (Section 3.6.2.3), the next eligible fragment to be selected for assembly into that packet belongs to the same flow, AND its sequence number is one greater than that of the fragment just assembled, it is RECOMMENDED that an implementation encode a Next User Data chunk instead of a User Data chunk.
フローのユーザーメッセージフラグメントをパケットにアセンブルした後（セクション3.6.2.3）、そのパケットにアセンブルするために選択される次の適格なフラグメントが同じフローに属し、そのシーケンス番号がフラグメントがアセンブルされたばかりの場合、実装はユーザーデータチャンクではなく次のユーザーデータチャンクをエンコードすることをお勧めします。
The FIRST fragment of a flow assembled into a packet MUST be encoded as a User Data chunk.
パケットに組み立てられたフローの最初のフラグメントは、ユーザーデータチャンクとしてエンコードする必要があります。
A Data Acknowledgement Bitmap chunk (Section 2.3.13) or a Data Acknowledgement Ranges chunk (Section 2.3.14) encodes the acknowledgement of receipt of one or more sequence numbers of a flow, as well as the receiver's current receive window advertisement.
データ確認応答ビットマップチャンク（セクション2.3.13）またはデータ確認応答範囲チャンク（セクション2.3.14）は、フローの1つ以上のシーケンス番号の受信確認と受信者の現在の受信ウィンドウアドバタイズをエンコードします。
On receipt of an acknowledgement chunk for a sending flow:
送信フローの確認応答チャンクを受信すると、次のようになります。
1. Set PRE_ACK_OUTSTANDING_BYTES to flow.F_OUTSTANDING_BYTES;
1. PRE_ACK_OUTSTANDING_BYTESをflow.F_OUTSTANDING_BYTES;に設定します。
2. Set flow.STARTUP_OPTIONS to empty;
2. flow.STARTUP_OPTIONSを空に設定します。
3. Set flow.RX_BUFFER_SIZE to chunk.bufferBytesAvailable;
3. flow.RX_BUFFER_SIZEをchunk.bufferBytesAvailableに設定します。
4. For each sequence number encoded in the acknowledgement, if there is an entry in flow.SEND_QUEUE with that sequence number and its IN_FLIGHT is true, then remove the entry from flow.SEND_QUEUE; and
4. 確認にエンコードされたシーケンス番号ごとに、flow.SEND_QUEUEにそのシーケンス番号のエントリがあり、そのIN_FLIGHTがtrueの場合、フローからエントリを削除します。SEND_QUEUE;そして
5. Notify the congestion control and avoidance algorithms that PRE_ACK_OUTSTANDING_BYTES - flow.F_OUTSTANDING_BYTES were acknowledged. Note that negative acknowledgements (Section 3.6.2.5) affect "TCP friendly" congestion control.
5. 輻輳制御および回避アルゴリズムにPRE_ACK_OUTSTANDING_BYTES-flow.F_OUTSTANDING_BYTESが確認されたことを通知します。否定応答（セクション3.6.2.5）は、「TCP対応」の輻輳制御に影響を与えることに注意してください。
A negative acknowledgement is inferred for an outstanding fragment if an acknowledgement is received for any other fragments sent after it in the same session.
同じセッションでその後に送信された他のフラグメントの確認応答を受信した場合、未解決のフラグメントに対して否定応答が推測されます。
An implementation SHOULD consider a fragment to be lost once that fragment receives three negative acknowledgements. A lost fragment is no longer outstanding in the network.
実装は、フラグメントが3つの否定応答を受信すると、フラグメントが失われたと見なす必要があります（SHOULD）。失われたフラグメントは、ネットワークで未処理ではなくなります。
The following describes an OPTIONAL method for detecting negative acknowledgements.
以下では、否定応答を検出するためのオプションの方法について説明します。
Let the session track the order in which fragments are transmitted across all its sending flows by way of a monotonically increasing Transmission Sequence Number (TSN) recorded with each fragment queue entry each time that fragment is transmitted.
そのフラグメントが送信されるたびに各フラグメントキューエントリに記録された単調に増加する送信シーケンス番号（TSN）によって、すべての送信フローでフラグメントが送信される順序をセッションに追跡させます。
Let the session information context contain additional variables:
セッション情報コンテキストに追加の変数を含めます。
o NEXT_TSN: the next TSN to record with a fragment's queue entry when it is transmitted, initially 1;
o NEXT_TSN：フラグメントの送信時にフラグメントのキューエントリで記録する次のTSN。最初は1。
o MAX_TSN_ACK: the highest acknowledged TSN, initially 0.
o MAX_TSN_ACK：承認された最高のTSN、最初は0。
Let each fragment queue entry contain an additional variable TSN, initially 0, to track its transmission order.
各フラグメントキューエントリに追加の変数TSN（最初は0）を含めて、その送信順序を追跡します。
On transmission of a message fragment into the network, set its entry.TSN to session.NEXT_TSN, and increment session.NEXT_TSN.
ネットワークへのメッセージフラグメントの送信時に、そのentry.TSNをsession.NEXT_TSNに設定し、session.NEXT_TSNを増分します。
On acknowledgement of an outstanding fragment, if its entry.TSN is greater than session.MAX_TSN_ACK, set session.MAX_TSN_ACK to entry.TSN.
未解決のフラグメントの確認時に、そのentry.TSNがsession.MAX_TSN_ACKより大きい場合は、session.MAX_TSN_ACKをentry.TSNに設定します。
After processing all acknowledgements in a packet containing at least one acknowledgement, then for each sending flow in that session, for each entry in that flow's SEND_QUEUE, if entry.IN_FLIGHT is true and entry.TSN is less than session.MAX_TSN_ACK, increment entry.NAK_COUNT and notify the congestion control and avoidance algorithms that a negative acknowledgement was detected in this packet.
少なくとも1つの確認応答を含むパケット内のすべての確認応答を処理した後、そのセッションの送信フローごとに、そのフローのSEND_QUEUEの各エントリについて、entry.IN_FLIGHTがtrueであり、entry.TSNがsession.MAX_TSN_ACKより小さい場合、エントリを増分します。 NAK_COUNTし、このパケットで否定応答が検出されたことを輻輳制御および回避アルゴリズムに通知します。
For each sending flow in that session, for each entry in that flow's SEND_QUEUE, if entry.IN_FLIGHT is true and entry.NAK_COUNT is at least 3, that fragment was lost in the network and is no longer considered to be in flight. Set entry.IN_FLIGHT to false. Notify the congestion control and avoidance algorithms of the loss.
そのセッションの各送信フローについて、そのフローのSEND_QUEUEの各エントリについて、entry.IN_FLIGHTがtrueであり、entry.NAK_COUNTが3以上の場合、そのフラグメントはネットワークで失われ、処理中ではないと見なされます。 entry.IN_FLIGHTをfalseに設定します。輻輳制御および回避アルゴリズムに損失を通知します。
A fragment is considered lost and no longer in flight in the network if it has remained outstanding for at least ERTO.
フラグメントが少なくともERTOの間未解決のままである場合、フラグメントは失われたと見なされ、ネットワーク内で飛行中ではなくなります。
The following describes an OPTIONAL method to manage transmission timeouts. This method REQUIRES that either burst avoidance (Section 3.5.2.3) is implemented or the implementation's congestion control and avoidance algorithms will eventually stop sending new fragments into the network if acknowledgements are persistently not received.
次に、送信タイムアウトを管理するためのオプションの方法について説明します。この方法では、バースト回避（セクション3.5.2.3）が実装されているか、実装の輻輳制御および回避アルゴリズムが、確認応答が持続的に受信されない場合、最終的にネットワークへの新しいフラグメントの送信を停止する必要があります。
Let the session information context contain an alarm TIMEOUT_ALARM, initially unset.
セッション情報コンテキストに、最初は設定されていないアラームTIMEOUT_ALARMを含めます。
On sending a packet containing at least one User Data chunk, set or reset TIMEOUT_ALARM to fire in ERTO.
少なくとも1つのユーザーデータチャンクを含むパケットを送信するときに、ERTOで起動するようにTIMEOUT_ALARMを設定またはリセットします。
On receiving a packet containing at least one acknowledgement, reset TIMEOUT_ALARM (if already set) to fire in ERTO.
少なくとも1つの確認応答を含むパケットを受信したら、TIMEOUT_ALARM（すでに設定されている場合）をリセットして、ERTOで起動します。
When TIMEOUT_ALARM fires:
TIMEOUT_ALARMが発生したとき：
1. Set WAS_LOSS = false;
1. WAS_LOSS = falseを設定します。
2. For each sending flow in the session, and for each entry in that flow's SEND_QUEUE:
2. セッションの各送信フロー、およびそのフローのSEND_QUEUEの各エントリについて：
1. If entry.IN_FLIGHT is true, set WAS_LOSS = true; and
1. entry.IN_FLIGHTがtrueの場合、WAS_LOSS = trueを設定します。そして
2. Set entry.IN_FLIGHT to false.
2. entry.IN_FLIGHTをfalseに設定します。
3. If WAS_LOSS is true, perform ERTO backoff (Section 3.5.2.2); and
3. WAS_LOSSがtrueの場合、ERTOバックオフ（セクション3.5.2.2）を実行します。そして
4. Notify the congestion control and avoidance algorithms of the timeout and, if WAS_LOSS is true, that there was loss.
4. タイムアウトの輻輳制御および回避アルゴリズムに通知し、WAS_LOSSがtrueの場合は、損失があったことを通知します。
The application can abandon queued messages at any time and for any reason. Example reasons include (but are not limited to) the following: one or more fragments of a message have remained in the SEND_QUEUE for longer than a specified message lifetime; a fragment has been retransmitted more than a specified retransmission limit; a prior message on which this message depends (such as a key frame in a prediction chain) was abandoned and not delivered.
アプリケーションは、キューに入れられたメッセージをいつでも理由を問わず破棄できます。理由の例には、以下が含まれます（これらに限定されません）。メッセージの1つ以上のフラグメントが、指定されたメッセージの存続期間よりも長くSEND_QUEUEに残っている。フラグメントが指定された再送信制限を超えて再送信されました。このメッセージが依存する以前のメッセージ（予測チェーンのキーフレームなど）は破棄され、配信されませんでした。
To abandon a message fragment, set its SEND_QUEUE entry's ABANDON flag to true. When abandoning a message fragment, abandon all fragments of the message to which it belongs.
メッセージフラグメントを破棄するには、SEND_QUEUEエントリのABANDONフラグをtrueに設定します。メッセージフラグメントを破棄する場合は、それが属するメッセージのすべてのフラグメントを破棄します。
An abandoned fragment MUST NOT be un-abandoned.
破棄されたフラグメントは、放棄されてはいけません。
Abandoned data may leave gaps in the sequence number space of a flow. Gaps may cause the receiver to hold completely received messages for ordered delivery to allow for retransmission of the missing fragments. User Data chunks (Section 2.3.11) encode a Forward Sequence Number (FSN) to instruct the receiver that fragments with sequence numbers less than or equal to the FSN will not be transmitted or retransmitted.
破棄されたデータは、フローのシーケンス番号スペースにギャップを残す可能性があります。欠落があると、欠落しているフラグメントの再送信を可能にするために、受信者が完全に受信したメッセージを順序付けられた配信用に保持することがあります。ユーザーデータチャンク（セクション2.3.11）は、FSN以下のシーケンス番号を持つフラグメントが送信または再送信されないことを受信者に指示するために、転送シーケンス番号（FSN）をエンコードします。
When the receiver has gaps in the received sequence number space and no non-abandoned message fragments remain in the SEND_QUEUE, the sender SHOULD transmit a Forward Sequence Number Update (FSN Update) comprising a User Data chunk marked abandoned, whose sequence number is the FSN and whose fsnOffset is 0. An FSN Update allows the receiver to skip gaps that will not be repaired and deliver received messages to the user. An FSN Update may be thought of as a transmission or retransmission of abandoned sequence numbers without actually sending the data.
受信者が受信したシーケンス番号スペースにギャップがあり、SEND_QUEUEに放棄されていないメッセージフラグメントが残っていない場合、送信者は、破棄されたとマークされたユーザーデータチャンクを含む転送シーケンス番号更新（FSN更新）を送信する必要があります（FSN更新） fsnOffsetが0のFSN更新を使用すると、受信者は修復されないギャップをスキップして、受信したメッセージをユーザーに配信できます。 FSN更新は、実際にデータを送信せずに、破棄されたシーケンス番号の送信または再送信と考えることができます。
The method described in Section 3.6.2.3 ("Sending Data") generates FSN Updates when appropriate.
セクション3.6.2.3（「データの送信」）で説明されている方法は、必要に応じてFSN更新を生成します。
Sender
| :
1 |<--- Ack ID=2, seq:0-16
2 |---> Data ID=2, seq#=25, fsnOff=9 (fsn=16)
3 |---> Data ID=2, seq#=26, fsnOff=10 (fsn=16)
4 |<--- Ack ID=2, seq:0-18
5 |---> Data ID=2, seq#=27, fsnOff=9 (fsn=18)
6 |---> Data ID=2, seq#=28, fsnOff=10 (fsn=18)
| :
There are 9 sequence numbers in flight with delayed acknowledgements.
進行中の9つのシーケンス番号があり、確認応答が遅れています。
Figure 20: Normal Flow with No Loss
図20：損失のない通常のフロー
Sender
| :
1 |<--- Ack ID=3, seq:0-30
2 |---> Data ID=3, seq#=45, fsnOff=15 (fsn=30)
3 |<--- Ack ID=3, seq:0-30, 32 (nack 31:1)
4 |---> Data ID=3, seq#=46, fsnOff=16 (fsn=30)
5 |<--- Ack ID=3, seq:0-30, 32, 34 (nack 31:2, 33:1)
6 |<--- Ack ID=3, seq:0-30, 32, 34-35 (nack 31:3=lost, 33:2)
7 |---> Data ID=3, seq#=47, fsnOff=15 (fsn=32, abandon 31)
8 |<--- Ack ID=3, seq:0-30, 32, 34-36 (nack 33:3=lost)
9 |---> Data ID=3, seq#=33, fsnOff=1 (fsn=32, retransmit 33)
10 |<--- Ack ID=3, seq:0-30, 32, 34-37
11 |---> Data ID=3, seq#=48, fsnOff=16 (fsn=32)
| :
| (continues through seq#=59)
| :
12 |---> Data ID=3, seq#=60, fsnOff=28(fsn=32)
13 |<--- Ack ID=3, seq:0-30, 34-46
14 |---> Data ID=3, seq#=61, fsnOff=29 (fsn=32)
15 |<--- Ack ID=3, seq:0-32, 34-47
16 |---> Data ID=3, seq#=62, fsnOff=30 (fsn=32)
17 |<--- Ack ID=3, seq:0-47
18 |---> Data ID=3, seq#=63, fsnOff=16 (fsn=47)
19 |<--- Ack ID=3, seq:0-49
20 |---> Data ID=3, seq#=64, fsnOff=15 (fsn=49)
| :
21 |<--- Ack ID=3, seq:0-59
22 |<--- Ack ID=3, seq:0-59, 61 (nack 60:1)
23 |<--- Ack ID=3, seq:0-59, 61-62 (nack 60:2)
24 |<--- Ack ID=3, seq:0-59, 61-63 (nack 60:3=lost)
25 |---> Data ID=3, ABN=1, seq#=60, fsnOff=0 (fsn=60, abandon 60)
26 |<--- Ack ID=3, seq:0-59, 61-64
| :
27 |<--- Ack ID=3, seq:0-64
Flow with sequence numbers 31, 33, and 60 lost in transit, and a pause at 64. 33 is retransmitted; 31 and 60 are abandoned. Note that line 25 is a Forward Sequence Number Update (Section 3.6.2.7.1).
シーケンス番号31、33、および60のフローは転送中に失われ、64で一時停止されます。33が再送信されます。 31と60は放棄されました。 25行目はForward Sequence Number Update（セクション3.6.2.7.1）であることに注意してください。
Figure 21: Flow with Loss
図21：損失のあるフロー
The flow receiver advertises the amount of new data it's willing to accept from the flow sender with the bufferBytesAvailable derived field of an acknowledgement (Sections 2.3.13 and 2.3.14).
フローレシーバーは、確認応答のbufferBytesAvailable派生フィールドを使用して、フローセンダーから受け入れることができる新しいデータの量を通知します（セクション2.3.13および2.3.14）。
The flow sender MUST NOT send new data into the network if flow.F_OUTSTANDING_BYTES is greater than or equal to the most recently received buffer advertisement, unless flow.EXCEPTION is true (Section 3.6.2.3).
flow.EXCEPTIONがtrueでない限り、flow.F_OUTSTANDING_BYTESが最後に受信したバッファアドバタイズメント以上の場合、フロー送信者はネットワークに新しいデータを送信してはなりません（セクション3.6.2.3）。
The flow sender is suspended if the most recently received buffer advertisement is zero and the flow hasn't been rejected by the receiver -- that is, while RX_BUFFER_SIZE is zero AND EXCEPTION is false. To guard against potentially lost acknowledgements that might reopen the receive window, a suspended flow sender SHOULD send a packet comprising a Buffer Probe chunk (Section 2.3.15) for this flow from time to time.
最後に受信したバッファアドバタイズメントがゼロであり、フローがレシーバーによって拒否されていない場合、つまり、RX_BUFFER_SIZEがゼロであり、かつEXCEPTIONがfalseの場合、フローセンダーは中断されます。受信ウィンドウを再び開く可能性のある、失われた可能性のある確認応答を防ぐために、一時停止されたフロー送信者は、このフローのバッファプローブチャンク（セクション2.3.15）から構成されるパケットを時々送信する必要があります（SHOULD）。
If the receive window advertisement transitions from non-zero to zero, the flow sender MAY send a Buffer Probe immediately and SHOULD send a probe within one second.
受信ウィンドウアドバタイズメントがゼロ以外からゼロに移行する場合、フロー送信側はすぐにバッファプローブを送信でき、1秒以内にプローブを送信する必要があります。
The initial period between Buffer Probes SHOULD be at least one second or ERTO, whichever is greater. The period between probes SHOULD increase over time, but the period between probes SHOULD NOT be more than one minute or ERTO, whichever is greater.
バッファープローブ間の初期期間は、少なくとも1秒またはERTOのいずれか大きい方である必要があります。プローブ間の期間は時間の経過とともに増加する必要がありますが、プローブ間の期間は1分またはERTOのいずれか長い方でなければなりません。
The flow sender SHOULD stop sending Buffer Probes if it is no longer suspended.
フローセンダーは、中断されなくなった場合、バッファープローブの送信を停止する必要があります（SHOULD）。
The flow receiver can reject the flow at any time and for any reason. The flow receiver sends a Flow Exception Report (Section 2.3.16) when it has rejected a flow.
フローレシーバーは、いつでもどのような理由でもフローを拒否できます。フロー受信者は、フローを拒否すると、フロー例外レポート（2.3.16項）を送信します。
On receiving a Flow Exception Report for a sending flow:
送信フローのフロー例外レポートを受信すると：
1. If the flow is F_OPEN, close the flow (Section 3.6.2.11) and notify the user that the far end reported an exception with the encoded exception code;
1. フローがF_OPENの場合、フローを閉じ（3.6.2.11項）、遠端がエンコードされた例外コードで例外を報告したことをユーザーに通知します。
2. Set the EXCEPTION flag to true; and
2. EXCEPTIONフラグをtrueに設定します。そして
3. For each entry in SEND_QUEUE, set entry.ABANDONED = true.
3. SEND_QUEUEの各エントリに対して、entry.ABANDONED = trueを設定します。
A sending flow is closed by the user or as a result of an exception. To close an F_OPEN flow:
送信フローは、ユーザーによって、または例外の結果として閉じられました。 F_OPENフローを閉じるには：
1. Move to the F_CLOSING state;
1. F_CLOSING状態に移行します。
2. If the SEND_QUEUE is not empty, AND the tail entry of the SEND_QUEUE has a sequence number of NEXT_SN - 1, AND the tail entry.EVER_SENT is false, set F_FINAL_SN to entry.SEQUENCE_NUMBER; else
2. SEND_QUEUEが空ではなく、かつSEND_QUEUEのテールエントリのシーケンス番号がNEXT_SN-1であり、テールエントリである場合。EVER_SENTがfalseの場合、F_FINAL_SNをentry.SEQUENCE_NUMBERに設定します。そうしないと
3. The SEND_QUEUE is empty, OR the tail entry does not have a sequence number of NEXT_SN - 1, OR the tail entry.EVER_SENT is true: enqueue a new SEND_QUEUE entry with entry.SEQUENCE_NUMBER = flow.NEXT_SN, entry.FRA = 0, and entry.ABANDONED = true, and set flow.F_FINAL_SN to entry.SEQUENCE_NUMBER.
3. SEND_QUEUEが空であるか、末尾のエントリにNEXT_SN-1のシーケンス番号がないか、末尾のエントリがあります。EVER_SENTがtrueの場合：新しいSEND_QUEUEエントリをentry.SEQUENCE_NUMBER = flow.NEXT_SN、entry.FRA = 0、およびentry.ABANDONED = true、flow.F_FINAL_SNをentry.SEQUENCE_NUMBERに設定します。
An F_CLOSING sending flow is complete when its SEND_QUEUE transitions to empty, indicating that all sequence numbers, including the FINAL_SN, have been acknowledged by the other end.
SEND_QUEUEが空に遷移すると、F_CLOSING送信フローが完了します。これは、FINAL_SNを含むすべてのシーケンス番号が相手側によって確認されたことを示します。
When an F_CLOSING sending flow becomes complete, move to the F_COMPLETE_LINGER state.
F_CLOSING送信フローが完了すると、F_COMPLETE_LINGER状態に移行します。
A sending flow MUST remain in the F_COMPLETE_LINGER state for at least 130 seconds. After at least 130 seconds, move to the F_CLOSED state. The sending flow is now closed, its resources can be reclaimed, and its F_FLOW_ID MAY be used for a new sending flow.
送信フローは、少なくとも130秒間F_COMPLETE_LINGER状態に留まる必要があります。 130秒以上経過したら、F_CLOSED状態に移行します。これで送信フローが閉じられ、そのリソースを再利用でき、そのF_FLOW_IDを新しい送信フローに使用できます（MAY）。
Each receiving flow comprises the flow-specific information context necessary to receive that flow's messages from the sending end and deliver completed messages to the user. Each receiving flow context includes at least:
各受信フローは、送信側からそのフローのメッセージを受信し、完了したメッセージをユーザーに配信するために必要なフロー固有の情報コンテキストを含みます。各受信フローコンテキストには、少なくとも次のものが含まれます。
o RF_FLOW_ID: this flow's identifier;
o RF_FLOW_ID：このフローの識別子。
o SEQUENCE_SET: the set of all fragment sequence numbers seen in this receiving flow, whether received or abandoned, initially empty;
o SEQUENCE_SET：この受信フローで見られるすべてのフラグメントシーケンス番号のセット。受信されたか破棄されたかに関係なく、最初は空です。
o RF_FINAL_SN: the final fragment sequence number of the flow, initially having no value;
o RF_FINAL_SN：フローの最終フラグメントシーケンス番号。最初は値がありません。
o RECV_BUFFER: the message fragments waiting to be delivered to the user, sorted by sequence number in ascending order, initially empty; each message fragment entry comprising the following:
o RECV_BUFFER：ユーザーに配信されるのを待っているメッセージフラグメント。昇順のシーケンス番号でソートされ、最初は空です。以下を含む各メッセージフラグメントエントリ：
* SEQUENCE_NUMBER: the sequence number of this fragment;
* SEQUENCE_NUMBER：このフラグメントのシーケンス番号。
* DATA: this fragment's user data; and
* DATA：このフラグメントのユーザーデータ。そして
* FRA: the fragment control value for this message fragment, having one of the values enumerated for that purpose in Section 2.3.11 ("User Data Chunk").
* FRA：このメッセージフラグメントのフラグメントコントロール値。2.3.11節で目的のために列挙された値の1つ（「ユーザーデータチャンク」）を持ちます。
o BUFFERED_SIZE: the sum of the lengths of each fragment in RECV_BUFFER plus any additional storage overhead for the fragments incurred by the implementation, in bytes;
o BUFFERED_SIZE：RECV_BUFFERの各フラグメントの長さの合計と、実装によって発生したフラグメントの追加のストレージオーバーヘッド（バイト単位）。
o BUFFER_CAPACITY: the desired maximum size for the receive buffer, in bytes;
o BUFFER_CAPACITY：受信バッファーの望ましい最大サイズ（バイト単位）。
o PREV_RWND: the most recent receive window advertisement sent in an acknowledgement, in 1024-byte blocks, initially having no value;
o PREV_RWND：確認応答で送信された最新の受信ウィンドウアドバタイズメント（1024バイトブロック単位）。最初は値がありません。
o SHOULD_ACK: whether or not an acknowledgement should be sent for this flow, initially false;
o SHOULD_ACK：このフローに対して確認応答を送信するかどうか。最初はfalse。
o EXCEPTION_CODE: the exception code to report to the sender when the flow has been rejected, initially 0;
o EXCEPTION_CODE：フローが拒否されたときに送信者に報告する例外コード。最初は0。
o The state, at any time being one of the following values: the open state RF_OPEN; the closing states RF_REJECTED and RF_COMPLETE_LINGER; and the closed state RF_CLOSED.
o いつでも次のいずれかの値の状態。オープン状態RF_OPEN;終了状態RF_REJECTEDおよびRF_COMPLETE_LINGER;閉じた状態RF_CLOSED。
Note: The following diagram is only a summary of state transitions and their causing events, and is not a complete operational specification.
注：以下の図は、状態遷移とその原因となるイベントの要約にすぎず、完全な運用仕様ではありません。
+-+
|X|
+-+
|rcv User Data for
| no existing flow
v
+---------+
| RF_OPEN |
+---------+
rcv all sequence numbers| |user reject,
0..RF_FINAL_SN | |rcv bad option,
| |no metadata at open,
| |association specified
| | but not F_OPEN at open
+---+ |
| v
| +-----------+
| |RF_REJECTED|
| +-----------+
| |rcv all sequence numbers
| | 0..RF_FINAL_SN
v v
+------------------+
|RF_COMPLETE_LINGER|
+------------------+
| 120 seconds
v
+---------+
|RF_CLOSED|
+---------+
Figure 22: Receiving Flow State Diagram
図22：受信フローの状態図
A new receiving flow starts on receipt of a User Data chunk (Section 2.3.11) encoding a flow ID not belonging to any other receiving flow in the same session in the RF_OPEN, RF_REJECTED, or RF_COMPLETE_LINGER states.
新しい受信フローは、RF_OPEN、RF_REJECTED、またはRF_COMPLETE_LINGER状態の同じセッションで他の受信フローに属さないフローIDをエンコードするユーザーデータチャンク（セクション2.3.11）を受信すると開始します。
On receipt of such a User Data chunk:
このようなユーザーデータチャンクを受信すると：
1. Set temporary variables METADATA, ASSOCIATED_FLOWID, and ASSOCIATION to each have no value;
1. 一時変数METADATA、ASSOCIATED_FLOWID、およびASSOCIATIONをそれぞれに値がないように設定します。
2. Create a new receiving flow context in this session, setting its RF_FLOW_ID to the flow ID encoded in the opening User Data chunk, and set to the RF_OPEN state;
2. このセッションで新しい受信フローコンテキストを作成し、そのRF_FLOW_IDを、開始ユーザーデータチャンクでエンコードされたフローIDに設定し、RF_OPEN状態に設定します。
3. If the opening User Data chunk encodes a User's Per-Flow Metadata option (Section 2.3.11.1.1), set METADATA to option.userMetadata;
3. 最初のユーザーデータチャンクがユーザーのフローごとのメタデータオプションをエンコードする場合（セクション2.3.11.1.1）、METADATAをoption.userMetadataに設定します。
4. If the opening User Data chunk encodes a Return Flow Association option (Section 2.3.11.1.2), set ASSOCIATED_FLOWID to option.flowID;
4. 最初のユーザーデータチャンクがReturn Flow Associationオプションをエンコードする場合（セクション2.3.11.1.2）、ASSOCIATED_FLOWIDをoption.flowIDに設定します。
5. If METADATA has no value, the receiver MUST reject the flow (Section 3.6.3.7), moving it to the RF_REJECTED state;
5. METADATAに値がない場合、受信者はフローを拒否し（3.6.3.7節）、RF_REJECTED状態に移行する必要があります。
6. If ASSOCIATED_FLOWID has a value, then if there is no sending flow in the same session with a flow ID of ASSOCIATED_FLOWID, the receiver MUST reject the flow, moving it to the RF_REJECTED state; otherwise, set ASSOCIATION to the indicated sending flow;
6. ASSOCIATED_FLOWIDに値がある場合、同じセッションにフローIDがASSOCIATED_FLOWIDの送信フローがない場合、受信者はフローを拒否して、RF_REJECTED状態に移行する必要があります。それ以外の場合は、ASSOCIATIONを指定された送信フローに設定します。
7. If ASSOCIATION indicates a sending flow, AND that sending flow's state is not F_OPEN, the receiver MUST reject this receiving flow, moving it to the RF_REJECTED state;
7. ASSOCIATIONが送信フローを示し、その送信フローの状態がF_OPENではない場合、受信者はこの受信フローを拒否して、RF_REJECTED状態に移行する必要があります。
8. If the opening User Data chunk encodes any unrecognized option with a type code less than 8192 (Section 2.3.11.1), the receiver MUST reject the flow, moving it to the RF_REJECTED state;
8. オープニングのユーザーデータチャンクが8192（セクション2.3.11.1）未満のタイプコードで認識されないオプションをエンコードする場合、受信者はフローを拒否し、RF_REJECTED状態に移行する必要があります。
9. If this new receiving flow is still RF_OPEN, then notify the user that a new receiving flow has opened, including the METADATA and, if present, the ASSOCIATION, and set flow.BUFFER_CAPACITY according to the user;
9. この新しい受信フローがまだRF_OPENである場合は、METADATAおよび存在する場合はASSOCIATIONを含む新しい受信フローが開いたことをユーザーに通知し、ユーザーに応じてflow.BUFFER_CAPACITYを設定します。
10. Perform the normal data processing (Section 3.6.3.2) for the opening User Data chunk; and
10. 最初のユーザーデータチャンクに対して通常のデータ処理（3.6.3.2項）を実行します。そして
11. Set this session's ACK_NOW to true.
11. このセッションのACK_NOWをtrueに設定します。
A User Data chunk (Section 2.3.11) or a Next User Data chunk (Section 2.3.12) encodes one fragment of a user data message of a flow, as well as the flow's Forward Sequence Number and potentially optional parameters (Section 2.3.11.1).
ユーザーデータチャンク（セクション2.3.11）または次のユーザーデータチャンク（セクション2.3.12）は、フローのユーザーデータメッセージの1つのフラグメント、およびフローの転送シーケンス番号とオプションのパラメーター（セクション2.3。 11.1）。
On receipt of a User Data or Next User Data chunk:
ユーザーデータまたは次のユーザーデータのチャンクの受信時：
1. If chunk.flowID doesn't indicate an existing receiving flow in the same session in the RF_OPEN, RF_REJECTED, or RF_COMPLETE_LINGER state, perform the steps of Section 3.6.3.1 ("Startup") to start a new receiving flow;
1. chunk.flowIDが、RF_OPEN、RF_REJECTED、またはRF_COMPLETE_LINGER状態の同じセッションの既存の受信フローを示していない場合は、セクション3.6.3.1（「起動」）の手順を実行して、新しい受信フローを開始します。
2. Retrieve the receiving flow context for the flow indicated by chunk.flowID;
2. chunk.flowIDで示されるフローの受信フローコンテキストを取得します。
3. Set flow.SHOULD_ACK to true;
3. flow.SHOULD_ACKをtrueに設定します。
4. If the flow is RF_OPEN, AND the chunk encodes any unrecognized option with a type code less than 8192 (Section 2.3.11.1), the flow MUST be rejected: notify the user of an exception, and reject the flow (Section 3.6.3.7), moving it to the RF_REJECTED state;
4. フローがRF_OPENであり、チャンクが8192未満のタイプコードで認識されないオプションをエンコードしている場合（セクション2.3.11.1）、フローを拒否する必要があります。ユーザーに例外を通知し、フローを拒否します（セクション3.6.3.7）。 、それをRF_REJECTED状態に移動します。
5. If the flow is not in the RF_OPEN state, set session.ACK_NOW to true;
5. フローがRF_OPEN状態でない場合は、session.ACK_NOWをtrueに設定します。
6. If flow.PREV_RWND has a value and that value is less than 2 blocks, set session.ACK_NOW to true;
6. flow.PREV_RWNDに値があり、その値が2ブロック未満の場合は、session.ACK_NOWをtrueに設定します。
7. If chunk.abandon is true, set session.ACK_NOW to true;
7. chunk.abandonがtrueの場合、session.ACK_NOWをtrueに設定します。
8. If flow.SEQUENCE_SET has any gaps (that is, if it doesn't contain every sequence number from 0 through and including the highest sequence number in the set), set session.ACK_NOW to true;
8. flow.SEQUENCE_SETにギャップがある場合（つまり、0からセット内の最大のシーケンス番号を含むすべてのシーケンス番号が含まれていない場合）、session.ACK_NOWをtrueに設定します。
9. If flow.SEQUENCE_SET contains chunk.sequenceNumber, then this chunk is a duplicate: set session.ACK_NOW to true;
9. flow.SEQUENCE_SETにchunk.sequenceNumberが含まれている場合、このチャンクは重複しています。session.ACK_NOWをtrueに設定します。
10. If flow.SEQUENCE_SET doesn't contain chunk.sequenceNumber, AND chunk.final is true, AND flow.RF_FINAL_SN has no value, then set flow.RF_FINAL_SN to chunk.sequenceNumber, and set session.ACK_NOW to true;
10. flow.SEQUENCE_SETにchunk.sequenceNumberが含まれておらず、かつchunk.finalがtrueであり、かつ、flow.RF_FINAL_SNに値がない場合、flow.RF_FINAL_SNをchunk.sequenceNumberに設定し、session.ACK_NOWをtrueに設定します。
11. If the flow is in the RF_OPEN state, AND flow.SEQUENCE_SET doesn't contain chunk.sequenceNumber, AND chunk.abandon is false, then create a new RECV_BUFFER entry for this chunk's data and set entry.SEQUENCE_NUMBER to chunk.sequenceNumber, entry.DATA to chunk.userData, and entry.FRA to chunk.fragmentControl, and insert this new entry into flow.RECV_BUFFER;
11. フローがRF_OPEN状態であり、かつflow.SEQUENCE_SETにchunk.sequenceNumberが含まれておらず、かつchunk.abandonがfalseの場合、このチャンクのデータ用に新しいRECV_BUFFERエントリを作成し、entry.SEQUENCE_NUMBERをchunk.sequenceNumberエントリに設定します。 DATAをchunk.userDataに、entry.FRAをchunk.fragmentControlに、この新しいエントリをflow.RECV_BUFFERに挿入します。
12. Add to flow.SEQUENCE_SET the range of sequence numbers from 0 through and including the chunk.forwardSequenceNumber derived field;
12. flow.SEQUENCE_SETにシーケンス番号の範囲を0からchunk.forwardSequenceNumber派生フィールドを含めて追加します。
13. Add chunk.sequenceNumber to flow.SEQUENCE_SET;
13. chunk.sequenceNumberをflow.SEQUENCE_SETに追加します。
14. If flow.SEQUENCE_SET now has any gaps, set session.ACK_NOW to true;
14. flow.SEQUENCE_SETにギャップがある場合は、session.ACK_NOWをtrueに設定します。
15. If session.ACK_NOW is false and session.DELACK_ALARM is not set, set session.DELACK_ALARM to fire in 200 milliseconds; and
15. session.ACK_NOWがfalseで、session.DELACK_ALARMが設定されていない場合は、session.DELACK_ALARMを200ミリ秒で起動するように設定します。そして
16. Attempt delivery of completed messages in this flow's RECV_BUFFER to the user (Section 3.6.3.3).
16. このフローのRECV_BUFFERで完了したメッセージのユーザーへの配信を試みます（セクション3.6.3.3）。
After processing all chunks in a packet containing at least one User Data chunk, increment session.RX_DATA_PACKETS by one. If session.RX_DATA_PACKETS is at least two, set session.ACK_NOW to true.
少なくとも1つのユーザーデータチャンクを含むパケットのすべてのチャンクを処理した後、session.RX_DATA_PACKETSを1増やします。 session.RX_DATA_PACKETSが2つ以上の場合は、session.ACK_NOWをtrueに設定します。
A receiving flow that is not in the RF_CLOSED state is ready to send an acknowledgement if its SHOULD_ACK flag is set. Acknowledgements for receiving flows that are ready are sent either opportunistically by piggybacking on a packet that's already sending user data or an acknowledgement (Section 3.6.3.4.6), or when the session's ACK_NOW flag is set (Section 3.6.3.4.5).
RF_CLOSED状態でない受信フローは、SHOULD_ACKフラグが設定されている場合、確認応答を送信する準備ができています。準備ができているフローを受信するための確認応答は、すでにユーザーデータまたは確認応答を送信しているパケットに便乗的に送信するか（セクション3.6.3.4.6）、またはセッションのACK_NOWフラグが設定されている場合（セクション3.6.3.4.5）に送信されます。
A receiving flow's information context contains a RECV_BUFFER for reordering, reassembling, and holding the user data messages of the flow. Only complete messages are delivered to the user; an implementation MUST NOT deliver partially received messages, except by special arrangement with the user.
受信フローの情報コンテキストには、フローのユーザーデータメッセージを並べ替え、再構成、および保持するためのRECV_BUFFERが含まれています。完全なメッセージのみがユーザーに配信されます。実装は、ユーザーとの特別な取り決めによる場合を除いて、部分的に受信したメッセージを配信してはなりません（MUST NOT）。
Let the Cumulative Acknowledgement Sequence Number (CSN) be the highest number in the contiguous range of numbers in SEQUENCE_SET starting with 0. For example, if SEQUENCE_SET contains {0, 1, 2, 3, 5, 6}, the contiguous range starting with 0 is 0..3, so the CSN is 3.
累積確認応答シーケンス番号（CSN）を、0から始まるSEQUENCE_SETの連続する番号範囲の最大番号とします。たとえば、SEQUENCE_SETに{0、1、2、3、5、6}が含まれている場合、連続する範囲は0は0..3なので、CSNは3です。
A message is complete if all of its fragments are present in the RECV_BUFFER. The fragments of one message have contiguous sequence numbers. A message can be either a single fragment, whose fragment control value is 0-whole, or two or more fragments where the first's fragment control value is 1-begin, followed by zero or more fragments with control value 3-middle, and terminated by a last fragment with control value 2-end.
すべてのフラグメントがRECV_BUFFERに存在する場合、メッセージは完了です。 1つのメッセージのフラグメントには、連続したシーケンス番号があります。メッセージは、フラグメント制御値が0全体である単一のフラグメント、または最初のフラグメント制御値が1で始まる2つ以上のフラグメントで、その後に制御値が3の中間にある0個以上のフラグメントが続き、制御値2の最後のフラグメント。
An incomplete message segment is a contiguous sequence of one or more fragments that do not form a complete message -- that is, a 1-begin followed by zero or more 3-middle fragments but with no 2-end, or zero or more 3-middle fragments followed by a 2-end but with no 1-begin, or one or more 3-middle fragments with neither a 1-begin nor a 2-end.
不完全なメッセージセグメントは、完全なメッセージを形成しない1つ以上のフラグメントの連続したシーケンスです。つまり、1始まりの後に0個以上の3つの中間フラグメントが続きますが、2終わりがないか、0個以上の3です。 -中間フラグメントの後に2端が続くが1開始がないか、1つ以上の3中間フラグメントが1開始でも2端でもない。
Incomplete message segments can either be in progress or abandoned. An incomplete segment is abandoned in the following cases:
不完全なメッセージセグメントは、進行中または破棄されます。次の場合、不完全なセグメントは破棄されます。
o The sequence number of the segment's first fragment is less than or equal to the CSN, AND that fragment's control value is not 1-begin; or
o セグメントの最初のフラグメントのシーケンス番号がCSN以下であり、かつそのフラグメントの制御値が1から始まっていない。または
o The sequence number of the segment's last fragment is less than the CSN.
o セグメントの最後のフラグメントのシーケンス番号がCSN未満です。
Abandoned message segments will never be completed, so they SHOULD be removed from the RECV_BUFFER to make room in the advertised receive window and the receiver's memory for messages that can be completed.
破棄されたメッセージセグメントは決して完了しないため、それらをRECV_BUFFERから削除して、アドバタイズされた受信ウィンドウと受信者のメモリに、完了可能なメッセージ用のスペースを確保する必要があります。
The user can suspend delivery of a flow's messages. A suspended receiving flow holds completed messages in its RECV_BUFFER until the user resumes delivery. A suspended flow can cause the receive window advertisement to go to zero even when the BUFFER_CAPACITY is non-zero; this is described in detail in Section 3.6.3.5 ("Flow Control").
ユーザーはフローのメッセージの配信を一時停止できます。中断された受信フローは、ユーザーが配信を再開するまで、完了したメッセージをRECV_BUFFERに保持します。中断されたフローにより、BUFFER_CAPACITYがゼロ以外の場合でも、受信ウィンドウアドバタイズがゼロになる可能性があります。これについては、3.6.3.5（「フロー制御」）で詳しく説明します。
When the receiving flow is not suspended, the original queuing order of the messages is recovered by delivering, in ascending sequence number order, complete messages in the RECV_BUFFER whose sequence numbers are less than or equal to the CSN.
受信フローが中断されない場合、メッセージの元のキューイング順序は、シーケンス番号の昇順で、シーケンス番号がCSN以下の完全なメッセージをRECV_BUFFERに配信することによって回復されます。
The following describes a method for discarding abandoned message segments and delivering complete messages in original queuing order when the receiving flow is not suspended.
次に、受信フローが中断されていない場合に、破棄されたメッセージセグメントを破棄し、完全なメッセージを元のキューイング順に配信する方法について説明します。
While the first fragment entry in the RECV_BUFFER has a sequence number less than or equal to the CSN and delivery is still possible:
RECV_BUFFERの最初のフラグメントエントリのシーケンス番号はCSN以下であり、配信は引き続き可能です。
1. If entry.FRA is 0-whole, deliver entry.DATA to the user, and remove this entry from RECV_BUFFER; otherwise,
1. entry.FRAが0全体の場合、entry.DATAをユーザーに配信し、このエントリーをRECV_BUFFERから削除します。さもないと、
2. If entry.FRA is 2-end or 3-middle, this entry belongs to an abandoned segment, so remove and discard this entry from RECV_BUFFER; otherwise,
2. entry.FRAが2エンドまたは3ミドルの場合、このエントリーは破棄されたセグメントに属しているため、このエントリーをRECV_BUFFERから削除して破棄します。さもないと、
3. Entry.FRA is 1-begin. Let LAST_ENTRY be the last RECV_BUFFER entry that is part of this message segment (LAST_ENTRY can be entry if the segment has only one fragment so far). Then:
3. Entry.FRAは1から始まります。 LAST_ENTRYを、このメッセージセグメントの一部である最後のRECV_BUFFERエントリにします（これまでにセグメントにフラグメントが1つしかない場合は、LAST_ENTRYをエントリにすることができます）。次に：
1. If LAST_ENTRY.FRA is 2-end, this segment is a complete message, so concatenate the DATA fields of each fragment entry of this segment in ascending sequence number order and deliver the complete message to the user, then remove the entries for this complete message from RECV_BUFFER; otherwise,
1. LAST_ENTRY.FRAが2エンドの場合、このセグメントは完全なメッセージであるため、このセグメントの各フラグメントエントリのDATAフィールドを昇順のシーケンス番号で連結し、完全なメッセージをユーザーに配信してから、この完全なメッセージのエントリを削除します。 RECV_BUFFERから。さもないと、
2. If LAST_ENTRY.SEQUENCE_NUMBER is less than CSN, this segment is incomplete and abandoned, so remove and discard the entries for this segment from RECV_BUFFER; otherwise,
2. LAST_ENTRY.SEQUENCE_NUMBERがCSNより小さい場合、このセグメントは不完全であり、破棄されるため、このセグメントのエントリをRECV_BUFFERから削除して破棄します。さもないと、
3. LAST_ENTRY.SEQUENCE_NUMBER is equal to CSN and LAST_ENTRY.FRA is not 2-end: this segment is incomplete but still in progress. Ordered delivery is no longer possible until at least one more fragment is received. Stop.
3. LAST_ENTRY.SEQUENCE_NUMBERはCSNと等しく、LAST_ENTRY.FRAは2エンドではありません。このセグメントは不完全ですが、まだ進行中です。少なくとももう1つのフラグメントが受信されるまで、注文した配送はできなくなります。やめる。
If flow.RF_FINAL_SN has a value and is equal to the CSN, AND RECV_BUFFER is empty, all complete messages have been delivered to the user, so notify the user that the flow is complete.
flow.RF_FINAL_SNに値があり、CSNと等しく、かつRECV_BUFFERが空の場合、すべての完全なメッセージがユーザーに配信されているため、フローが完了したことをユーザーに通知します。
A flow receiver SHOULD acknowledge all user data fragment sequence numbers seen in that flow. Acknowledgements drive the sender's congestion control and avoidance algorithms, clear data from the sender's buffers, and in some sender implementations clock new data into the network; therefore, the acknowledgements must be accurate and timely.
フロー受信者は、そのフローで見られるすべてのユーザーデータフラグメントシーケンス番号を確認する必要があります。承認は、送信者の輻輳制御および回避アルゴリズムを駆動し、送信者のバッファからデータをクリアし、一部の送信者の実装では、新しいデータをネットワークに送り込みます。したがって、確認は正確かつタイムリーでなければなりません。
For reasons similar to those discussed in Section 4.2.3.2 of RFC 1122 [RFC1122], it is advantageous to delay sending acknowledgements for a short time, so that multiple data fragments can be acknowledged in a single transmission. However, it is also advantageous for a sender to receive timely notification about the receiver's disposition of the flow, particularly in unusual or exceptional circumstances, so that the circumstances can be addressed if possible.
RFC 1122 [RFC1122]のセクション4.2.3.2で説明されている理由と同様の理由により、複数のデータフラグメントを1回の送信で確認できるように、確認応答の送信を短時間遅らせると有利です。ただし、特に異常または例外的な状況で、フローの受信者の処理に関するタイムリーな通知を送信者が受信することも有利であり、可能であればその状況に対処できます。
Therefore, a flow receiver SHOULD send an acknowledgement for a flow as soon as is practical in any of the following circumstances:
したがって、フローレシーバーは、以下の状況のいずれかで実用的であるとすぐにフローの確認応答を送信する必要があります（SHOULD）。
o On receipt of a User Data chunk that starts a new flow;
o 新しいフローを開始するユーザーデータチャンクの受信時。
o On receipt of a User Data or Next User Data chunk if the flow is not in the RF_OPEN state;
o フローがRF_OPEN状態でない場合、ユーザーデータまたは次のユーザーデータのチャンクを受信したとき。
o On receipt of a User Data chunk where, before processing the chunk, the SEQUENCE_SET of the indicated flow does not contain every sequence number between 0 and the highest sequence number in the set (that is, if there was a sequence number gap before processing the chunk);
o ユーザーデータチャンクを受信すると、チャンクを処理する前に、示されたフローのSEQUENCE_SETに0からセット内の最大シーケンス番号までのすべてのシーケンス番号が含まれていない（つまり、シーケンスを処理する前にシーケンス番号のギャップがあった場合）チャンク）;
o On receipt of a User Data chunk where, after processing the chunk, the flow's SEQUENCE_SET does not contain every sequence number between 0 and the highest sequence number in the set (that is, if this chunk causes a sequence number gap);
o ユーザーデータチャンクを受信すると、チャンクの処理後、フローのSEQUENCE_SETに0とセット内の最大のシーケンス番号の間のシーケンス番号が含まれていません（つまり、このチャンクによってシーケンス番号にギャップが生じた場合）。
o On receipt of a Buffer Probe for the flow;
o フローのバッファープローブの受信時。
o On receipt of a User Data chunk if the last acknowledgement sent for the flow indicated fewer than two bufferBlocksAvailable;
o フローに対して送信された最後の確認応答が2つ未満のbufferBlocksAvailableを示した場合のユーザーデータチャンクの受信時。
o On receipt of a User Data or Next User Data chunk for the flow if, after processing the chunk, the flow's BUFFER_CAPACITY is not at least 1024 bytes greater than BUFFERED_SIZE;
o フローのユーザーデータまたは次のユーザーデータのチャンクを受信したときに、チャンクを処理した後、フローのBUFFER_CAPACITYが少なくとも1024バイトがBUFFERED_SIZEより大きくない場合。
o On receipt of a User Data or Next User Data chunk for any sequence number that was already seen (that is, on receipt of a duplicate);
o すでに表示されているシーケンス番号のユーザーデータまたは次のユーザーデータのチャンクを受信したとき（つまり、重複を受信したとき）。
o On the first receipt of the final sequence number of the flow;
o フローの最終シーケンス番号の最初の受信時。
o On receipt of two packets in the session that contain user data for any flows since an acknowledgement was last sent, the new acknowledgements being for the flows having any User Data chunks in the received packets (that is, for every second packet containing user data);
o 確認応答が最後に送信されてからフローのユーザーデータを含む2つのパケットをセッションで受信すると、新しい確認応答は、受信したパケットにユーザーデータチャンクを含むフロー（つまり、ユーザーデータを含む2番目のパケットごと）に対するものです。 ;
o After receipt of a User Data chunk for the flow, if an acknowledgement for any other flow is being sent (that is, consolidate acknowledgements);
o フローのユーザーデータチャンクを受信した後、他のフローの確認応答が送信されている（つまり、確認応答を統合する）場合。
o After receipt of a User Data chunk for the flow, if any user data for a sending flow is being sent in a packet and if there is space available in the same packet (that is, attempt to piggyback an acknowledgement with user data if possible);
o フローのユーザーデータチャンクを受信した後、送信フローのユーザーデータがパケットで送信されており、同じパケットに使用可能なスペースがある場合（つまり、可能であればユーザーデータで確認応答をピギーバックしようとします） ;
o No longer than 200 milliseconds after receipt of a User Data chunk for the flow.
o フローのユーザーデータチャンクを受信してから200ミリ秒以内。
Including an encoded acknowledgement in a packet might cause the packet to exceed the path MTU. In that case:
エンコードされた確認応答をパケットに含めると、パケットがパスMTUを超える可能性があります。その場合：
o If the packet is being sent primarily to send an acknowledgement, AND this is the first acknowledgement in the packet, truncate the acknowledgement so that the packet does not exceed the path MTU; otherwise,
o パケットが主に確認応答を送信するために送信されており、これがパケット内の最初の確認応答である場合、パケットがパスMTUを超えないように確認応答を切り捨てます。さもないと、
o The acknowledgement is being piggybacked in a packet with user data or with an acknowledgement for another flow: do not include this acknowledgement in the packet, and send it later.
o 確認応答は、ユーザーデータまたは別のフローの確認応答を持つパケットで便乗されています。この確認応答をパケットに含めず、後で送信してください。
The Data Acknowledgement Bitmap chunk (Section 2.3.13) and Data Acknowledgement Ranges chunk (Section 2.3.14) encode a receiving flow's SEQUENCE_SET and its receive window advertisement. The two chunks are semantically equivalent; implementations SHOULD send whichever provides the most compact encoding of the SEQUENCE_SET.
データ受信確認ビットマップチャンク（セクション2.3.13）およびデータ受信確認範囲チャンク（セクション2.3.14）は、受信フローのSEQUENCE_SETとその受信ウィンドウアドバタイズをエンコードします。 2つのチャンクは、意味的に同等です。実装は、SEQUENCE_SETの最もコンパクトなエンコーディングを提供する方を送信する必要があります（SHOULD）。
When assembling an acknowledgement for a receiving flow:
受信フローの確認を組み立てるとき：
1. If the flow's state is RF_REJECTED, first assemble a Flow Exception Report chunk (Section 2.3.16) for flow.flowID;
1. フローの状態がRF_REJECTEDの場合、最初にflow.flowIDのフロー例外レポートチャンク（セクション2.3.16）をアセンブルします。
2. Choose the acknowledgement chunk type that most compactly encodes flow.SEQUENCE_SET;
2. flow.SEQUENCE_SET;を最もコンパクトにエンコードする確認応答チャンクタイプを選択します。
3. Use the method described in Section 3.6.3.5 ("Flow Control") to determine the value for the acknowledgement chunk's bufferBlocksAvailable field.
3. セクション3.6.3.5（「フロー制御」）で説明されている方法を使用して、確認応答チャンクのbufferBlocksAvailableフィールドの値を決定します。
As discussed in Section 3.6.3.4.1 ("Timing"), a flow receiver can delay sending an acknowledgement for up to 200 milliseconds after receiving user data. The method described in Section 3.6.3.2 ("Receiving Data") sets the session's DELACK_ALARM.
セクション3.6.3.4.1（「タイミング」）で説明したように、フローレシーバーは、ユーザーデータの受信後、確認応答の送信を最大200ミリ秒遅らせることができます。セクション3.6.3.2（「データの受信」）で説明されているメソッドは、セッションのDELACK_ALARMを設定します。
When DELACK_ALARM fires, set ACK_NOW to true.
DELACK_ALARMが発生したら、ACK_NOWをtrueに設定します。
One or more acknowledgements should be sent as soon as is practical when the session's ACK_NOW flag is set. While the ACK_NOW flag is set:
セッションのACK_NOWフラグが設定されている場合は、できるだけ早く1つ以上の確認応答を送信する必要があります。 ACK_NOWフラグが設定されている間：
1. Choose a receiving flow that is ready to send an acknowledgement;
1. 確認応答を送信する準備ができている受信フローを選択します。
2. If there is no such flow, there is no work to do, set ACK_NOW to false, set RX_DATA_PACKETS to 0, clear the DELACK_ALARM, and stop; otherwise,
2. そのようなフローがない場合、実行する作業はありません。ACK_NOWをfalseに設定し、RX_DATA_PACKETSを0に設定し、DELACK_ALARMをクリアして停止します。さもないと、
3. Start a new packet;
3. 新しいパケットを開始します。
4. Assemble an acknowledgement for the flow and include it in the packet, truncating it if necessary so that the packet doesn't exceed the path MTU;
4. フローの確認応答を組み立ててパケットに含め、パケットがパスMTUを超えないように、必要に応じてそれを切り捨てます。
5. Set flow.SHOULD_ACK to false;
5. flow.SHOULD_ACKをfalseに設定します。
6. Set flow.PREV_RWND to the bufferBlocksAvailable field of the included acknowledgement chunk;
6. 含まれる確認応答チャンクのbufferBlocksAvailableフィールドにflow.PREV_RWNDを設定します。
7. Attempt to piggyback acknowledgements for any other flows that are ready to send an acknowledgement into the packet, as described below; and
7. 以下で説明するように、確認応答をパケットに送信する準備ができている他のフローの確認応答を便乗させようとします。そして
8. Send the packet.
8. パケットを送信します。
When sending a packet with user data or an acknowledgement, any other receiving flows that are ready to send an acknowledgement should include their acknowledgements in the packet if possible.
ユーザーデータまたは確認応答を含むパケットを送信する場合、確認応答を送信する準備ができている他の受信フローは、可能であれば、それらの確認応答をパケットに含める必要があります。
To piggyback acknowledgements in a packet that is already being sent, where the packet contains user data or an acknowledgement, while there is at least one receiving flow that is ready to send an acknowledgement:
既に送信されているパケットに確認応答を便乗させるには、確認応答を送信する準備ができている受信フローが少なくとも1つある間に、パケットにユーザーデータまたは確認応答が含まれている必要があります。
1. Assemble an acknowledgement for the flow;
1. フローの確認を組み立てます。
2. If the acknowledgement cannot be included in the packet without exceeding the path MTU, the packet is full; stop. Otherwise,
2. パスMTUを超えずに確認応答をパケットに含めることができない場合、パケットはいっぱいです。やめる。さもないと、
3. Include the acknowledgement in the packet;
3. 確認応答をパケットに含めます。
4. Set flow.SHOULD_ACK to false;
4. flow.SHOULD_ACKをfalseに設定します。
5. Set flow.PREV_RWND to the bufferBlocksAvailable field of the included acknowledgement chunk; and
5. 含まれる確認応答チャンクのbufferBlocksAvailableフィールドにflow.PREV_RWNDを設定します。そして
6. If there are no longer any receiving flows in the session that are ready to send an acknowledgement, set session.ACK_NOW to false, set session.RX_DATA_PACKETS to 0, and clear session.DELACK_ALARM.
6. セッション内に確認応答を送信する準備ができている受信フローがなくなった場合は、session.ACK_NOWをfalseに設定し、session.RX_DATA_PACKETSを0に設定し、session.DELACK_ALARMをクリアします。
Figure 23 shows an example flow with sequence numbers 31 and 33 lost in transit; 31 is abandoned, and 33 is retransmitted.
図23は、シーケンス番号31および33が転送中に失われたフローの例を示しています。 31は破棄され、33は再送信されます。
Receiver
1 |<--- Data ID=3, seq#=29, fsnOff=11 (fsn=18)
2 |<--- Data ID=3, seq#=30, fsnOff=12 (fsn=18)
3 |---> Ack ID=3, seq:0-30
4 |<--- Data ID=3, seq#=32, fsnOff=12 (fsn=20)
5 |---> Ack ID=3, seq:0-30, 32
6 |<--- Data ID=3, seq#=34, fsnOff=12 (fsn=22)
7 |---> Ack ID=3, seq:0-30, 32, 34
| :
8 |<--- Data ID=3, seq#=46, fsnOff=16 (fsn=30)
9 |---> Ack ID=3, seq:0-30, 32, 34-46
10 |<--- Data ID=3, seq#=47, fsnOff=15 (fsn=32)
11 |---> Ack ID=3, seq:0-32, 34-47
12 |<--- Data ID=3, seq#=33, fsnOff=1 (fsn=32)
13 |---> Ack ID=3, seq#=0-47
14 |<--- Data ID=3, seq#=48, fsnOff=16 (fsn=32)
15 |<--- Data ID=3, seq#=49, fsnOff=17 (fsn=32)
16 |---> Ack ID=3, seq#=0-49
| :
Figure 23: Flow Example with Loss
図23：損失のあるフローの例
The flow receiver maintains a buffer for reassembling and reordering messages for delivery to the user (Section 3.6.3.3). The implementation and the user may wish to limit the amount of resources (including buffer memory) that a flow is allowed to use.
フローレシーバーは、ユーザーに配信するためにメッセージを再構成して並べ替えるためのバッファーを維持します（セクション3.6.3.3）。実装とユーザーは、フローが使用できるリソース（バッファメモリを含む）の量を制限したい場合があります。
RTMFP provides a means for each receiving flow to govern the amount of data sent by the sender, by way of the bufferBytesAvailable derived field of acknowledgement chunks (Sections 2.3.13 and 2.3.14). This derived field indicates the amount of data that the sender is allowed to have outstanding in the network, until instructed otherwise. This amount is also called the receive window.
RTMFPは、受信フローごとに、確認応答チャンクのbufferBytesAvailable派生フィールドを介して、送信者が送信するデータの量を管理する手段を提供します（セクション2.3.13および2.3.14）。この派生フィールドは、特に指示がない限り、送信者がネットワーク内で未処理のままにできるデータの量を示します。この量は、受信ウィンドウとも呼ばれます。
The flow receiver can suspend the sender by advertising a closed (zero length) receive window.
フローレシーバーは、閉じた（長さがゼロの）受信ウィンドウをアドバタイズすることにより、送信者を一時停止できます。
The user can suspend delivery of messages from the receiving flow (Section 3.6.3.3). This can cause the receive buffer to fill.
ユーザーは、受信フローからのメッセージの配信を一時停止できます（セクション3.6.3.3）。これにより、受信バッファーがいっぱいになる可能性があります。
In order for progress to be made on completing a fragmented message or repairing a gap for sequenced delivery in a flow, the flow receiver MUST advertise at least one buffer block in an acknowledgement if it is not suspended, even if the amount of data in the buffer exceeds the buffer capacity, unless the buffer capacity is 0. Otherwise, deadlock can occur, as the receive buffer will stay full and won't drain because of a gap or incomplete message, and the gap or incomplete message can't be repaired or completed because the sender is suspended.
断片化されたメッセージの完了、またはフロー内のシーケンス配信のギャップの修復で進行するために、フローのデータ量が中断されていても、フロー受信者は確認応答で少なくとも1つのバッファブロックを通知する必要があります。バッファー容量が0でない限り、バッファーはバッファー容量を超えます。そうしないと、ギャップまたは不完全なメッセージのために受信バッファーがいっぱいのままドレインされず、ギャップまたは不完全なメッセージを修復できないため、デッドロックが発生する可能性があります。または送信者が一時停止されているため完了しました。
The receive window is advertised in units of 1024-byte blocks. For example, advertisements for 1 byte, 1023 bytes, and 1024 bytes each require one block. An advertisement for 1025 bytes requires two blocks.
受信ウィンドウは、1024バイトブロック単位でアドバタイズされます。たとえば、1バイト、1023バイト、および1024バイトのアドバタイズには、それぞれ1つのブロックが必要です。 1025バイトのアドバタイズには2つのブロックが必要です。
The following describes the RECOMMENDED method of calculating the bufferBlocksAvailable field of an acknowledgement chunk for a receiving flow:
次に、受信フローの確認応答チャンクのbufferBlocksAvailableフィールドを計算するRECOMMENDEDメソッドについて説明します。
1. If BUFFERED_SIZE is greater than or equal to BUFFER_CAPACITY, set ADVERTISE_BYTES to 0;
1. BUFFERED_SIZEがBUFFER_CAPACITY以上の場合は、ADVERTISE_BYTESを0に設定します。
2. If BUFFERED_SIZE is less than BUFFER_CAPACITY, set ADVERTISE_BYTES to BUFFER_CAPACITY - BUFFERED_SIZE;
2. BUFFERED_SIZEがBUFFER_CAPACITYより小さい場合は、ADVERTISE_BYTESをBUFFER_CAPACITY-BUFFERED_SIZEに設定します。
3. Set ADVERTISE_BLOCKS to CEIL(ADVERTISE_BYTES / 1024);
3. ADVERTISE_BLOCKSをCEIL（ADVERTISE_BYTES / 1024）に設定します。
4. If ADVERTISE_BLOCKS is 0, AND BUFFER_CAPACITY is greater than 0, AND delivery to the user is not suspended, set ADVERTISE_BLOCKS to 1; and
4. ADVERTISE_BLOCKSが0で、かつBUFFER_CAPACITYが0より大きく、ユーザーへの配信が一時停止されていない場合は、ADVERTISE_BLOCKSを1に設定します。そして
5. Set the acknowledgement's bufferBlocksAvailable field to ADVERTISE_BLOCKS.
5. 確認応答のbufferBlocksAvailableフィールドをADVERTISE_BLOCKSに設定します。
A Buffer Probe chunk (Section 2.3.15) is sent by the flow sender (Section 3.6.2.9.1) to request the current receive window advertisement (in the form of an acknowledgement) from the flow receiver.
バッファープローブチャンク（セクション2.3.15）がフローセンダー（セクション3.6.2.9.1）によって送信され、フローレシーバーに現在の受信ウィンドウアドバタイズメント（確認応答の形式）を要求します。
On receipt of a Buffer Probe chunk:
バッファープローブチャンクの受信時：
1. If chunk.flowID doesn't belong to a receiving flow in the same session in the RF_OPEN, RF_REJECTED, or RF_COMPLETE_LINGER state, ignore this Buffer Probe; otherwise,
1. chunk.flowIDがRF_OPEN、RF_REJECTED、またはRF_COMPLETE_LINGER状態の同じセッションの受信フローに属していない場合は、このバッファープローブを無視してください。さもないと、
2. Retrieve the receiving flow context for the flow indicated by chunk.flowID; then
2. chunk.flowIDで示されるフローの受信フローコンテキストを取得します。その後
3. Set flow.SHOULD_ACK to true; and
3. flow.SHOULD_ACKをtrueに設定します。そして
4. Set session.ACK_NOW to true.
4. session.ACK_NOWをtrueに設定します。
A receiver can reject an RF_OPEN flow at any time and for any reason. To reject a receiving flow in the RF_OPEN state:
レシーバーは、いつでも、どのような理由でも、RF_OPENフローを拒否できます。 RF_OPEN状態の受信フローを拒否するには：
1. Move to the RF_REJECTED state;
1. RF_REJECTED状態に移行します。
2. Discard all entries in flow.RECV_BUFFER, as they are no longer relevant;
2. 関係がなくなったため、flow.RECV_BUFFERのすべてのエントリを破棄します。
3. If the user rejected the flow, set flow.EXCEPTION_CODE to the exception code indicated by the user; otherwise, the flow was rejected automatically by the implementation, so the exception code is 0;
3. ユーザーがフローを拒否した場合は、flow.EXCEPTION_CODEをユーザーが指定した例外コードに設定します。それ以外の場合、フローは実装によって自動的に拒否されたため、例外コードは0です。
4. Set flow.SHOULD_ACK to true; and
4. flow.SHOULD_ACKをtrueに設定します。そして
5. Set session.ACK_NOW to true.
5. session.ACK_NOWをtrueに設定します。
The receiver indicates that it has rejected a flow by sending a Flow Exception Report chunk (Section 2.3.16) with every acknowledgement (Section 3.6.3.4.3) for a flow in the RF_REJECTED state.
レシーバーは、RF_REJECTED状態のフローのすべての確認応答（セクション3.6.3.4.3）とともにフロー例外レポートチャンク（セクション2.3.16）を送信することにより、フローを拒否したことを示します。
A receiving flow is complete when every sequence number from 0 through and including the final sequence number has been received -- that is, when flow.RF_FINAL_SN has a value and flow.SEQUENCE_SET contains every sequence number from 0 through flow.RF_FINAL_SN, inclusive.
受信フローは、0から最終シーケンス番号までのすべてのシーケンス番号が受信されると完了します。つまり、flow.RF_FINAL_SNに値があり、flow.SEQUENCE_SETには、0からflow.RF_FINAL_SNまでのすべてのシーケンス番号が含まれます。
When an RF_OPEN or RF_REJECTED receiving flow becomes complete, move to the RF_COMPLETE_LINGER state, set flow.SHOULD_ACK to true, and set session.ACK_NOW to true.
RF_OPENまたはRF_REJECTED受信フローが完了したら、RF_COMPLETE_LINGER状態に移行し、flow.SHOULD_ACKをtrueに設定し、session.ACK_NOWをtrueに設定します。
A receiving flow SHOULD remain in the RF_COMPLETE_LINGER state for 120 seconds. After 120 seconds, move to the RF_CLOSED state. The receiving flow is now closed, and its resources can be reclaimed once all complete messages in flow.RECV_BUFFER have been delivered to the user (Section 3.6.3.3). The same flow ID might be used for a new flow by the sender after this point.
受信フローは、120秒間RF_COMPLETE_LINGER状態を維持する必要があります（SHOULD）。 120秒後、RF_CLOSED状態に移行します。これで受信フローが閉じられ、flow.RECV_BUFFER内のすべての完全なメッセージがユーザーに配信されると、そのリソースを再利用できます（セクション3.6.3.3）。この後、送信者は新しいフローに同じフローIDを使用できます。
Discussion: The flow sender detects that the flow is complete on receiving an acknowledgement of all fragment sequence numbers of the flow. This can't happen until after the receiver has detected that the flow is complete and acknowledged all of the sequence numbers. The receiver's RF_COMPLETE_LINGER period is two minutes (one Maximum Segment Lifetime (MSL)); this period allows any in-flight packets to drain from the network without being misidentified and gives the sender an opportunity to retransmit any sequence numbers if the completing acknowledgement is lost. The sender's F_COMPLETE_LINGER period is at least two minutes plus 10 seconds and doesn't begin until the completing acknowledgement is received; therefore, the same flow identifier won't be reused by the flow sender for a new sending flow for at least 10 seconds after the flow receiver has closed the receiving flow context. This ensures correct operation independent of network delay, even when the sender's clock runs up to 8 percent faster than the receiver's.
ディスカッション：フロー送信者は、フローのすべてのフラグメントシーケンス番号の確認応答を受信すると、フローが完了したことを検出します。これは、受信者がフローが完了したことを検出し、すべてのシーケンス番号を確認するまで発生しません。レシーバーのRF_COMPLETE_LINGER期間は2分（1つの最大セグメントライフタイム（MSL））です。この期間により、送信中のパケットが誤認されることなくネットワークから排出され、完全な確認応答が失われた場合に送信者がシーケンス番号を再送信する機会が与えられます。送信者のF_COMPLETE_LINGER期間は少なくとも2分+ 10秒であり、完了確認が受信されるまで開始されません。したがって、フローレシーバーが受信フローコンテキストを閉じてから少なくとも10秒間は、同じフロー識別子が新しい送信フローのためにフローセンダーによって再利用されません。これにより、送信側のクロックが受信側のクロックよりも最大8％高速で実行されている場合でも、ネットワーク遅延に関係なく正しい動作が保証されます。
This memo specifies chunk type code values (Section 2.3) and User Data option type code values (Section 2.3.11.1). These type code values are assigned and maintained by Adobe. Therefore, this memo has no IANA actions.
このメモは、チャンクタイプコード値（セクション2.3）およびユーザーデータオプションタイプコード値（セクション2.3.11.1）を指定します。これらのタイプコード値は、アドビによって割り当てられ、維持されます。したがって、このメモにはIANAアクションはありません。
This memo specifies a general framework that can be used to establish a confidential and authenticated session between endpoints. A Cryptography Profile, not specified herein, defines the cryptographic algorithms, data formats, and semantics as used within this framework. Designing a Cryptography Profile to ensure that communications are protected to the degree required by the application-specific threat model is outside the scope of this specification.
このメモは、エンドポイント間で機密で認証されたセッションを確立するために使用できる一般的なフレームワークを指定します。ここで指定されていない暗号化プロファイルは、このフレームワーク内で使用される暗号アルゴリズム、データ形式、およびセマンティクスを定義します。暗号化プロファイルを設計して、アプリケーション固有の脅威モデルに必要な程度まで通信が保護されるようにすることは、この仕様の範囲外です。
A block cipher in CBC mode is RECOMMENDED for packet encryption (Section 2.2.3). An attacker can predict the values of some fields from one plain RTMFP packet to the next or predict that some fields may be the same from one packet to the next. This SHOULD be considered in choosing and implementing a packet encryption cipher and mode.
CBCモードのブロック暗号は、パケット暗号化に推奨されます（セクション2.2.3）。攻撃者は、あるRTMFPパケットから次のパケットまでの一部のフィールドの値を予測したり、一部のフィールドがパケット間で同じである可能性があることを予測したりできます。これは、パケット暗号化の暗号とモードを選択して実装する際に考慮すべきです。
The well-known Default Session Key of a Cryptography Profile serves multiple purposes, including the scrambling of session startup packets to protect interior fields from undesirable modification by middleboxes such as NATs, increasing the effort required for casual passive observation of startup packets, and allowing different applications of RTMFP using different Default Session Keys to (intentionally or not) share network transport addresses without interference. The Default Session Key, being well known, MUST NOT be construed to contribute to the security of session startup; session startup is essentially in the clear.
暗号化プロファイルのよく知られたデフォルトセッションキーは、NATなどのミドルボックスによる望ましくない変更から内部フィールドを保護するためのセッションスタートアップパケットのスクランブル、スタートアップパケットのカジュアルなパッシブ監視に必要な労力の増加、さまざまなさまざまなデフォルトセッションキーを使用したRTMFPのアプリケーションは、干渉なしに（意図的に、または意図せずに）ネットワーク転送アドレスを共有します。よく知られているデフォルトセッションキーは、セッション起動のセキュリティに寄与すると解釈してはなりません。セッションの起動は、本質的には明確です。
Section 3.5.4.2 describes an OPTIONAL method for processing a change of network address of a communicating peer. Securely processing address mobility using that method, or any substantially similar method, REQUIRES at least that the packet encryption function of the Cryptography Profile (Section 2.2.3) employs a cryptographic verification mechanism comprising secret information known only to the two endpoints. Without this constraint, that method, or any substantially similar method, becomes "session hijacking support".
セクション3.5.4.2では、通信するピアのネットワークアドレスの変更を処理するためのOPTIONALメソッドについて説明します。その方法または実質的に同様の方法を使用してアドレスモビリティを安全に処理するには、少なくとも暗号化プロファイル（セクション2.2.3）のパケット暗号化機能が、2つのエンドポイントだけが知っている秘密情報を含む暗号化検証メカニズムを使用する必要があります。この制約がない場合、そのメソッドまたは実質的に同様のメソッドが「セッションハイジャックサポート」になります。
Flows and packet fragmentation imply semantics that could cause unbounded resource utilization in receivers, causing a denial of service. Implementations SHOULD guard against unbounded or excessive resource use and abort sessions that appear abusive.
フローとパケットの断片化は、受信側で無制限のリソース使用率を引き起こし、サービス拒否を引き起こす可能性があるセマンティクスを意味します。実装は、無制限または過剰なリソースの使用を防ぎ、乱用と思われるセッションを中止する必要があります。
A rogue but popular Redirector (Section 3.5.1.4) could direct session initiators to flood a victim address or network with Initiator Hello packets, potentially causing a denial of service.
悪意のある人気のあるリダイレクター（セクション3.5.1.4）は、セッション開始者に被害者のアドレスまたはネットワークにイニシエーターHelloパケットをフラッディングするように指示し、サービス拒否を引き起こす可能性があります。
An attacker that can passively observe an IHello and that possesses a certificate matching the Endpoint Discriminator (without having to know the private key, if any, associated with it) can deny the initiator access to the desired responder by sending an RHello before the desired responder does, since only the first received RHello is selected by the initiator. The attacker needn't forge the desired responder's source address, since the RHello is selected based on the tag echo and not the packet's source address. This can simplify the attack in some network or host configurations.
IHelloを受動的に監視でき、エンドポイントディスクリミネーターと一致する証明書を持っている攻撃者（それに関連付けられている秘密キーがあればそれを知らなくても）は、目的のレスポンダーの前にRHelloを送信することにより、目的のレスポンダーへのイニシエーターアクセスを拒否できます。最初に受信したRHelloのみがイニシエーターによって選択されるためです。 RHelloはパケットの送信元アドレスではなくタグエコーに基づいて選択されるため、攻撃者は目的のレスポンダの送信元アドレスを偽造する必要はありません。これにより、一部のネットワークまたはホスト構成での攻撃を簡略化できます。
An attacker that can passively observe and record the packets of an established session can use traffic analysis techniques to infer the start and completion of flows without decrypting the packets. The User Data fragments of flows have unique sequence numbers, so flows are immune to replay while they are open. However, once a flow has completed and the linger period has concluded, the attacker could replay the recorded packets, opening a new flow in the receiver and duplicating the flow's data; this replay might have undesirable effects on the receiver's application. The attacker could also infer that a new flow has begun reusing the recorded flow's identifier and replay the final sequence number or any of the other fragments in the flow, potentially denying or interfering with legitimate traffic to the receiver. Therefore, the data integrity aspect of packet encryption SHOULD comprise anti-replay measures.
確立されたセッションのパケットを受動的に監視および記録できる攻撃者は、トラフィック分析手法を使用して、パケットを復号化せずにフローの開始と完了を推測できます。フローのユーザーデータフラグメントには固有のシーケンス番号があるため、フローが開いている間、フローは再生の影響を受けません。ただし、フローが完了してリンガー期間が終了すると、攻撃者は記録されたパケットを再生し、レシーバーで新しいフローを開いてフローのデータを複製する可能性があります。このリプレイは、レシーバーのアプリケーションに望ましくない影響を与える可能性があります。攻撃者はまた、新しいフローが記録されたフローの識別子を再利用し始め、フロー内の最終シーケンス番号またはその他のフラグメントを再生し、受信者への正当なトラフィックを拒否または干渉する可能性があると推測することもできます。したがって、パケット暗号化のデータ整合性の側面は、アンチリプレイ対策を含む必要があります。
Special thanks go to Matthew Kaufman for his contributions to the creation and design of RTMFP.
RTMFPの作成と設計に貢献してくれたMatthew Kaufmanに特に感謝します。
Thanks to Jari Arkko, Ben Campbell, Wesley Eddy, Stephen Farrell, Philipp Hancke, Bela Lubkin, Hilarie Orman, Richard Scheffenegger, and Martin Stiemerling for their detailed reviews of this memo.
このメモの詳細なレビューを提供してくれたJari Arkko、Ben Campbell、Wesley Eddy、Stephen Farrell、Philipp Hancke、Bela Lubkin、Hilarie Orman、Richard Scheffenegger、Martin Stiemerlingに感謝します。
[CBC] Dworkin, M., "Recommendation for Block Cipher Modes of Operation", NIST Special Publication 800-38A, December 2001, <http://csrc.nist.gov/publications/ nistpubs/800-38a/sp800-38a.pdf>.
[CBC] Dworkin、M。、「Block Cipher Modes of Operation」、NIST Special Publication 800-38A、December 2001、<http://csrc.nist.gov/publications/ nistpubs / 800-38a / sp800-38a .pdf>。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、2009年9月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[ScalableTCP] Kelly, T., "Scalable TCP: Improving Performance in Highspeed Wide Area Networks", December 2002, <http://datatag.web.cern.ch/datatag/papers/ pfldnet2003-ctk.pdf>.
[ScalableTCP] Kelly、T。、「Scalable TCP：Improving Performance in Highspeed Wide Area Networks」、2002年12月、<http://datatag.web.cern.ch/datatag/papers/pfldnet2003-ctk.pdf>。
As mandated in Section 3.5.2, an RTMFP is required to use TCP-compatible congestion control, but flexibility in exact implementation is allowed, within certain limits. This section describes an experimental window-based congestion control algorithm that is appropriate for real-time and bulk data transport in RTMFP. The algorithm includes slow start and congestion avoidance phases, including modified increase and decrease parameters. These parameters are further adjusted according to whether real-time data is being sent and whether Time Critical Reverse Notifications are received.
セクション3.5.2で規定されているように、RTMFPはTCP互換の輻輳制御を使用する必要がありますが、特定の制限内で正確な実装の柔軟性が許可されます。このセクションでは、RTMFPのリアルタイムおよびバルクデータ転送に適した実験的なウィンドウベースの輻輳制御アルゴリズムについて説明します。アルゴリズムには、変更された増加および減少パラメーターを含む、スロースタートおよび輻輳回避フェーズが含まれます。これらのパラメータは、リアルタイムデータが送信されているかどうか、およびタイムクリティカルリバース通知が受信されているかどうかに応じてさらに調整されます。
RFC 5681 defines the standard window-based congestion control algorithms for TCP. These algorithms are appropriate for delay-insensitive bulk data transport but have undesirable behaviors for delay- and loss-sensitive applications. Among the undesirable behaviors are the cutting of the congestion window in half during a loss event, and the rapidity of the slow start algorithm's exponential growth. Cutting the congestion window in half requires a large channel headroom to support a real-time application and can cause a large amount of jitter from sender-side buffering. Doubling the congestion window during the slow start phase can lead to the congestion window temporarily growing to twice the size it should be, causing a period of excessive loss in the path.
RFC 5681は、TCPの標準的なウィンドウベースの輻輳制御アルゴリズムを定義しています。これらのアルゴリズムは、遅延の影響を受けにくいバルクデータ転送に適していますが、遅延や損失の影響を受けやすいアプリケーションでは望ましくない動作をします。望ましくない動作の中には、損失イベント中に輻輳ウィンドウを半分に切断することと、スロースタートアルゴリズムの急激な成長の速さがあります。輻輳ウィンドウを半分にカットするには、リアルタイムアプリケーションをサポートするために大きなチャネルヘッドルームが必要であり、送信側のバッファリングから大量のジッターを引き起こす可能性があります。スロースタートフェーズ中に輻輳ウィンドウを2倍にすると、輻輳ウィンドウが一時的に本来のサイズの2倍になり、パスで過度の損失が発生する可能性があります。
We found that a number of deployed TCP implementations use the method of equation (3) from Section 3.1 of RFC 5681; this method, when combined with the recommended behavior of acknowledging every other packet, causes the congestion window to grow at approximately half the rate that the recommended method specifies. In order to compete fairly with these deployed TCPs, we choose 768 bytes per round trip as the increment during the normal congestion avoidance phase; this is approximately half of the typical maximum segment size of 1500 bytes and is also easily subdivided.
デプロイされたTCP実装の多くが、RFC 5681のセクション3.1の式（3）の方法を使用していることがわかりました。この方法を1つおきのパケットの確認応答の推奨される動作と組み合わせると、推奨される方法で指定されている速度の約半分で輻輳ウィンドウが拡大します。これらの展開されたTCPと公平に競争するために、通常の輻輳回避フェーズ中の増分として、ラウンドトリップあたり768バイトを選択します。これは、1500バイトの一般的な最大セグメントサイズの約半分であり、簡単に再分割することもできます。
The sender may be sending real-time data to the far end. When sending real-time data, a smoother response to congestion is desired while still competing with reasonable fairness to other flows in the Internet. In order to scale the sending rate quickly, the slow start algorithm is desired, but slow start's normal rate of increase can cause excessive loss in the last round trip. Accordingly, slow start's exponential increase rate is adjusted to double approximately every 3 round trips instead of every round trip. The multiplicative decrease cuts the congestion window by one eighth on loss to maintain a smoother sending rate. The additive increase is done at half the normal rate (incrementing at 384 bytes per round trip), to both compensate for the less aggressive loss response and probe the path capacity more gently.
送信者は、リアルタイムデータを遠端に送信している可能性があります。リアルタイムデータを送信するときは、インターネット内の他のフローとの妥当な公平性を保ちながら、輻輳に対するスムーズな応答が望まれます。送信レートをすばやくスケーリングするには、スロースタートアルゴリズムが望ましいですが、スロースタートの通常の増加率は、最後の往復で過度の損失を引き起こす可能性があります。したがって、スロースタートの指数関数的増加率は、往復ごとではなく、約3往復ごとに2倍になるように調整されます。乗法的減少により、損失時に輻輳ウィンドウが1/8に削減され、よりスムーズな送信速度が維持されます。加法的な増加は通常の半分の速度で行われ（往復あたり384バイトで増加）、あまり積極的ではない損失応答を補償し、パス容量をより穏やかに調べます。
The far end may report that it is receiving real-time data from other peers, or the sender may be sending real-time data to other far ends. In these circumstances (if not sending real-time data to this far end), it is desirable to respond differently than the standard TCP algorithms specify, to both yield capacity to the real-time flows and avoid excessive losses while probing the path capacity. Slow start's exponential increase is disabled, and the additive increase is done at half the normal rate (incrementing at 384 bytes per round trip). Multiplicative decrease is left at the normal rate (cutting by half) to yield to other flows.
遠端は、他のピアからリアルタイムデータを受信していることを報告するか、送信者が他の遠端にリアルタイムデータを送信している可能性があります。これらの状況（リアルタイムデータをこの遠端に送信しない場合）では、標準TCPアルゴリズムが指定するのとは異なる方法で応答して、リアルタイムフローに容量を提供し、パス容量のプローブ中に過度の損失を回避することが望まれます。スロースタートの指数関数的な増加は無効になり、追加の増加は通常のレートの半分で行われます（ラウンドトリップあたり384バイトで増加します）。乗法的減少は、通常のレート（半分に削減）のままにして、他のフローに譲ります。
Since real-time messages may be small, and sent regularly, it is advantageous to spread congestion window increases out across the round-trip time instead of doing them all at once. We divide the round trip into 16 segments with an additive increase of a useful size (48 bytes) per segment.
リアルタイムメッセージは小さく、定期的に送信される可能性があるため、輻輳ウィンドウの増加をすべて一度に行うのではなく、往復時間全体に広げることが有利です。ラウンドトリップを16セグメントに分割し、セグメントごとに有効サイズ（48バイト）をさらに増やします。
Scalable TCP [ScalableTCP] describes experimental methods of modifying the additive increase and multiplicative decrease of the congestion window in large delay-bandwidth scenarios. The congestion window is increased by 1% each round trip and decreased by one eighth on loss in the congestion avoidance phase in certain circumstances (specifically, when a 1% increase is larger than the normal additive-increase amount). Those methods are adapted here. The scalable increase amount is 48 bytes for every 4800 bytes acknowledged, to spread the increase out over the round trip. The congestion window is decreased by one eighth on loss when it is at least 67200 bytes per round trip, which is seven eighths of 76800 (the point at which 1% is greater than 768 bytes per round trip). When sending real-time data to the far end, the scalable increase is 1% or 384 bytes per round trip, whichever is greater. Otherwise, when notified that the far end is receiving real-time data from other peers, the scaled increase is adjusted to 0.5% or 384 bytes per round trip, whichever is greater.
スケーラブルTCP [ScalableTCP]は、大きな遅延帯域幅のシナリオでの輻輳ウィンドウの追加の増加と乗法の減少を変更する実験的な方法を説明しています。輻輳ウィンドウは、ラウンドトリップごとに1％ずつ増加し、特定の状況（特に、1％の増加が通常の加算増加量よりも大きい場合）での輻輳回避フェーズでの損失時に1/8ずつ減少します。これらのメソッドはここで適応されます。スケーラブルな増加量は、確認応答の4800バイトごとに48バイトであり、増加を往復に分散します。輻輳ウィンドウは、ラウンドトリップあたり少なくとも67200バイト、つまり76800の7分の8（1ポイントがラウンドトリップあたり768バイトを超えるポイント）である場合、損失時に1/8ずつ減少します。リアルタイムデータを遠端に送信する場合、スケーラブルな増加は1％または往復あたり384バイトのいずれか大きい方です。それ以外の場合、遠端が他のピアからリアルタイムデータを受信していることが通知されると、スケーリングされた増加は、0.5％またはラウンドトリップあたり384バイトのいずれか大きい方に調整されます。
Let SMSS denote the Sender Maximum Segment Size [RFC5681], for example 1460 bytes. Let CWND_INIT denote the Initial Congestion Window (IW) according to Section 3.1 of RFC 5681, for example 4380 bytes. Let CWND_TIMEDOUT denote the congestion window after a timeout indicating lost data, being 1*SMSS (for example, 1460 bytes).
SMSSが1460バイトなどの送信者最大セグメントサイズ[RFC5681]を示すようにします。 CWND_INITが、RFC 5681のセクション3.1に従って、初期輻輳ウィンドウ（IW）を示すとします（例：4380バイト）。 CWND_TIMEDOUTが、失われたデータを示すタイムアウト後の輻輳ウィンドウを1 * SMSS（たとえば、1460バイト）であると示します。
Let the session information context contain additional variables:
セッション情報コンテキストに追加の変数を含めます。
o CWND: the congestion window, initialized to CWND_INIT;
o CWND：CWND_INITに初期化された輻輳ウィンドウ。
o SSTHRESH: the slow start threshold, initialized to positive infinity;
o SSTHRESH：スロースタートしきい値。正の無限大に初期化されます。
o ACKED_BYTES_ACCUMULATOR: a count of acknowledged bytes, initialized to 0;
o ACKED_BYTES_ACCUMULATOR：0に初期化された確認済みバイトのカウント。
o ACKED_BYTES_THIS_PACKET: a count of acknowledged bytes observed in the current packet;
o ACKED_BYTES_THIS_PACKET：現在のパケットで確認された確認済みバイトの数。
o PRE_ACK_OUTSTANDING: the number of bytes outstanding in the network before processing any acknowledgements in the current packet;
o PRE_ACK_OUTSTANDING：現在のパケットの確認応答を処理する前の、ネットワークで未処理のバイト数。
o ANY_LOSS: an indication of whether any loss has been detected in the current packet;
o ANY_LOSS：現在のパケットで損失が検出されたかどうかを示します。
o ANY_NAKS: an indication of whether any negative acknowledgements have been detected in the current packet;
o ANY_NAKS：現在のパケットで否定応答が検出されたかどうかを示します。
o ANY_ACKS: an indication of whether any acknowledgement chunks have been received in the current packet.
o ANY_ACKS：確認応答チャンクが現在のパケットで受信されたかどうかを示します。
Let FASTGROW_ALLOWED indicate whether the congestion window is allowed to grow at the normal rate versus a slower rate, being false if a Time Critical Reverse Notification has been received on this session within the last 800 milliseconds (Sections 2.2.4 and 3.5.2.1) or if a Time Critical Forward Notification has been sent on ANY session in the last 800 milliseconds, and otherwise being true.
FASTGROW_ALLOWEDに、輻輳ウィンドウが通常の速度よりも遅い速度で拡大できるかどうかを示し、このセッションで過去800ミリ秒以内にタイムクリティカルリバース通知が受信された場合（セクション2.2.4および3.5.2.1）またはfalse Time Critical Forward Notificationが過去800ミリ秒の間に任意のセッションで送信された場合、それ以外の場合はtrue。
Let TC_SENT indicate whether a Time Critical Forward Notification has been sent on this session within the last 800 milliseconds.
TC_SENTに、このセッションで過去800ミリ秒以内にタイムクリティカル転送通知が送信されたかどうかを示します。
Implement the method described in Section 3.6.2.6 to manage transmission timeouts, including setting the TIMEOUT_ALARM.
TIMEOUT_ALARMの設定など、送信タイムアウトを管理するために、3.6.2.6で説明されているメソッドを実装します。
On being notified that the TIMEOUT_ALARM has fired, perform the function shown in Figure 24:
TIMEOUT_ALARMが発生したことが通知されたら、図24に示す機能を実行します。
on TimeoutNotification(WAS_LOSS): set SSTHRESH to MAX(SSTHRESH, CWND * 3/4). set ACKED_BYTES_ACCUMULATOR to 0. if WAS_LOSS is true: set CWND to CWND_TIMEDOUT. else: set CWND to CWND_INIT.
on TimeoutNotification（WAS_LOSS）：SSTHRESHをMAX（SSTHRESH、CWND * 3/4）に設定します。 ACKED_BYTES_ACCUMULATORを0に設定します。WAS_LOSSがtrueの場合：CWNDをCWND_TIMEDOUTに設定します。それ以外の場合：CWNDをCWND_INITに設定します。
Figure 24: Pseudocode for Handling a Timeout Notification
図24：タイムアウト通知を処理するための疑似コード
Before processing each received packet in this session:
このセッションで受信した各パケットを処理する前に：
1. Set ANY_LOSS to false;
1. ANY_LOSSをfalseに設定します。
2. Set ANY_NAKS to false;
2. ANY_NAKSをfalseに設定します。
3. Set ACKED_BYTES_THIS_PACKET to 0; and
3. ACKED_BYTES_THIS_PACKETを0に設定します。そして
4. Set PRE_ACK_OUTSTANDING to S_OUTSTANDING_BYTES.
4. PRE_ACK_OUTSTANDINGをS_OUTSTANDING_BYTESに設定します。
On notification of loss (Section 3.6.2.5), set ANY_LOSS to true.
損失の通知（セクション3.6.2.5）で、ANY_LOSSをtrueに設定します。
On notification of negative acknowledgement (Section 3.6.2.5), set ANY_NAKS to true.
否定応答の通知（セクション3.6.2.5）で、ANY_NAKSをtrueに設定します。
On notification of acknowledgement of data (Section 3.6.2.4), set ANY_ACKS to true, and add the count of acknowledged bytes to ACKED_BYTES_THIS_PACKET.
データの確認の通知（セクション3.6.2.4）で、ANY_ACKSをtrueに設定し、確認済みバイトの数をACKED_BYTES_THIS_PACKETに追加します。
After processing all chunks in each received packet for this session, perform the function shown in Figure 25:
このセッションで受信した各パケットのすべてのチャンクを処理した後、図25に示す機能を実行します。
if ANY_LOSS is true: if (TC_SENT is true) OR (PRE_ACK_OUTSTANDING > 67200 AND \ FASTGROW_ALLOWED is true): set SSTHRESH to MAX(PRE_ACK_OUTSTANDING * 7/8, CWND_INIT). else: set SSTHRESH to MAX(PRE_ACK_OUTSTANDING * 1/2, CWND_INIT). set CWND to SSTHRESH. set ACKED_BYTES_ACCUMULATOR to 0. else if (ANY_ACKS is true) AND (ANY_NAKS is false) AND \ (PRE_ACK_OUTSTANDING >= CWND): set var INCREASE to 0. var AITHRESH. if FASTGROW_ALLOWED is true: if CWND < SSTHRESH: set INCREASE to ACKED_BYTES_THIS_PACKET. else: add ACKED_BYTES_THIS_PACKET to ACKED_BYTES_ACCUMULATOR. set AITHRESH to MIN(MAX(CWND / 16, 64), 4800). while ACKED_BYTES_ACCUMULATOR >= AITHRESH: subtract AITHRESH from ACKED_BYTES_ACCUMULATOR. add 48 to INCREASE. else FASTGROW_ALLOWED is false: if CWND < SSTHRESH AND TC_SENT is true: set INCREASE to CEIL(ACKED_BYTES_THIS_PACKET / 4). else: var AITHRESH_CAP. if TC_SENT is true: set AITHRESH_CAP to 2400. else: set AITHRESH_CAP to 4800. add ACKED_BYTES_THIS_PACKET to ACKED_BYTES_ACCUMULATOR. set AITHRESH to MIN(MAX(CWND / 16, 64), AITHRESH_CAP). while ACKED_BYTES_ACCUMULATOR >= AITHRESH: subtract AITHRESH from ACKED_BYTES_ACCUMULATOR. add 24 to INCREASE. set CWND to MAX(CWND + MIN(INCREASE, SMSS), CWND_INIT).
ANY_LOSSがtrueの場合：（TC_SENTがtrue）または（PRE_ACK_OUTSTANDING> 67200 AND \ FASTGROW_ALLOWEDがtrueの場合）：SSTHRESHをMAX（PRE_ACK_OUTSTANDING * 7/8、CWND_INIT）に設定します。それ以外の場合：SSTHRESHをMAX（PRE_ACK_OUTSTANDING * 1/2、CWND_INIT）に設定します。 CWNDをSSTHRESHに設定します。 ACKED_BYTES_ACCUMULATORを0に設定します。それ以外の場合（ANY_ACKSがtrue）AND（ANY_NAKSがfalse）AND \（PRE_ACK_OUTSTANDING> = CWND）：var INCREASEを0に設定します。varAITHRESH。 FASTGROW_ALLOWEDがtrueの場合：CWND <SSTHRESHの場合：INCREASEをACKED_BYTES_THIS_PACKETに設定します。それ以外の場合：ACKED_BYTES_THIS_PACKETをACKED_BYTES_ACCUMULATORに追加します。 AITHRESHをMIN（MAX（CWND / 16、64）、4800）に設定します。 ACKED_BYTES_ACCUMULATOR> = AITHRESHの場合：ACKED_BYTES_ACCUMULATORからAITHRESHを減算します。 INCREASEに48を加算します。それ以外の場合、FASTGROW_ALLOWEDはfalseです。CWND<SSTHRESH AND TC_SENTがtrueの場合：INCREASEをCEIL（ACKED_BYTES_THIS_PACKET / 4）に設定します。それ以外の場合：var AITHRESH_CAP。 TC_SENTが真の場合：AITHRESH_CAPを2400に設定します。それ以外の場合：AITHRESH_CAPを4800に設定します。ACKED_BYTES_THIS_PACKETをACKED_BYTES_ACCUMULATORに追加します。 AITHRESHをMIN（MAX（CWND / 16、64）、AITHRESH_CAP）に設定します。 ACKED_BYTES_ACCUMULATOR> = AITHRESHの場合：ACKED_BYTES_ACCUMULATORからAITHRESHを減算します。 INCREASEに24を加算します。 CWNDをMAX（CWND + MIN（INCREASE、SMSS）、CWND_INIT）に設定します。
Figure 25: Pseudocode for Congestion Window Adjustment after Processing a Packet
図25：パケット処理後の輻輳ウィンドウ調整の疑似コード
Author's Address
著者のアドレス
Michael C. Thornburgh Adobe Systems Incorporated 345 Park Avenue San Jose, CA 95110-2704 US
Michael C. Thornburgh Adobe Systems Incorporated 345 Park Avenue San Jose、CA 95110-2704 US
Phone: +1 408 536 6000
EMail: mthornbu@adobe.com
URI: http://www.adobe.com/