[要約] RFC 6824は、複数のアドレスを使用したマルチパス操作のためのTCP拡張に関するものです。このRFCの目的は、複数のネットワークパスを同時に使用してTCP接続のパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) A. Ford
Request for Comments: 6824 Cisco
Category: Experimental C. Raiciu
ISSN: 2070-1721 U. Politechnica of Bucharest
M. Handley
U. College London
O. Bonaventure
U. catholique de Louvain
January 2013
TCP Extensions for Multipath Operation with Multiple Addresses
複数のアドレスを持つマルチパス操作のためのTCP拡張
Abstract
概要
TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.
TCP / IP通信は現在、接続ごとに1つのパスに制限されていますが、ピア間に複数のパスが存在することがよくあります。 TCP / IPセッションでこれらの複数のパスを同時に使用すると、ネットワーク内のリソースの使用率が向上し、スループットの向上とネットワーク障害に対する回復力の向上により、ユーザーエクスペリエンスが向上します。
Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.
マルチパスTCPは、ピア間の複数のパスを同時に使用する機能を提供します。このドキュメントでは、マルチパス操作をサポートするための、従来のTCPに対する一連の拡張機能について説明します。プロトコルは、TCPと同じタイプのサービスをアプリケーションに提供します（つまり、信頼性の高いバイトストリーム）。また、互いに素である可能性のあるパス全体で複数のTCPフローを確立して使用するために必要なコンポーネントを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and 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）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6824.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6824で入手できます。
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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Design Assumptions .........................................4
1.2. Multipath TCP in the Networking Stack ......................5
1.3. Terminology ................................................6
1.4. MPTCP Concept ..............................................7
1.5. Requirements Language ......................................8
2. Operation Overview ..............................................8
2.1. Initiating an MPTCP Connection .............................9
2.2. Associating a New Subflow with an Existing MPTCP
Connection .................................................9
2.3. Informing the Other Host about Another Potential Address ..10
2.4. Data Transfer Using MPTCP .................................11
2.5. Requesting a Change in a Path's Priority ..................11
2.6. Closing an MPTCP Connection ...............................12
2.7. Notable Features ..........................................12
3. MPTCP Protocol .................................................12
3.1. Connection Initiation .....................................14
3.2. Starting a New Subflow ....................................18
3.3. General MPTCP Operation ...................................23
3.3.1. Data Sequence Mapping ..............................25
3.3.2. Data Acknowledgments ...............................28
3.3.3. Closing a Connection ...............................29
3.3.4. Receiver Considerations ............................30
3.3.5. Sender Considerations ..............................31
3.3.6. Reliability and Retransmissions ....................32
3.3.7. Congestion Control Considerations ..................33
3.3.8. Subflow Policy .....................................34
3.4. Address Knowledge Exchange (Path Management) ..............35
3.4.1. Address Advertisement ..............................36
3.4.2. Remove Address .....................................39
3.5. Fast Close ................................................40
3.6. Fallback ..................................................41
3.7. Error Handling ............................................45
3.8. Heuristics ................................................45
3.8.1. Port Usage .........................................46
3.8.2. Delayed Subflow Start ..............................46
3.8.3. Failure Handling ...................................47
4. Semantic Issues ................................................48
5. Security Considerations ........................................49
6. Interactions with Middleboxes ..................................51
7. Acknowledgments ................................................55
8. IANA Considerations ............................................55
9. References .....................................................57
9.1. Normative References ......................................57
9.2. Informative References ....................................57
Appendix A. Notes on Use of TCP Options ...........................59
Appendix B. Control Blocks ........................................60
B.1. MPTCP Control Block .......................................60
B.1.1. Authentication and Metadata ........................60
B.1.2. Sending Side .......................................61
B.1.3. Receiving Side .....................................61
B.2. TCP Control Blocks ........................................62
B.2.1. Sending Side .......................................62
B.2.2. Receiving Side .....................................62
Appendix C. Finite State Machine ..................................63
Multipath TCP (MPTCP) is a set of extensions to regular TCP [1] to provide a Multipath TCP [2] service, which enables a transport connection to operate across multiple paths simultaneously. This document presents the protocol changes required to add multipath capability to TCP; specifically, those for signaling and setting up multiple paths ("subflows"), managing these subflows, reassembly of data, and termination of sessions. This is not the only information required to create a Multipath TCP implementation, however. This document is complemented by three others:
マルチパスTCP（MPTCP）は、通常のTCP [1]の拡張セットであり、マルチパスTCP [2]サービスを提供します。これにより、トランスポート接続が複数のパスにわたって同時に動作できるようになります。このドキュメントでは、TCPにマルチパス機能を追加するために必要なプロトコルの変更について説明します。具体的には、複数のパス（「サブフロー」）のシグナリングとセットアップ、これらのサブフローの管理、データの再構成、およびセッションの終了のためのものです。ただし、マルチパスTCP実装を作成するために必要な情報はこれだけではありません。このドキュメントは、他の3つによって補足されます。
o Architecture [2], which explains the motivations behind Multipath TCP, contains a discussion of high-level design decisions on which this design is based, and an explanation of a functional separation through which an extensible MPTCP implementation can be developed.
o マルチパスTCPの背後にある動機を説明するアーキテクチャ[2]には、この設計の基礎となる高レベルの設計決定に関する説明と、拡張可能なMPTCP実装を開発するための機能的な分離についての説明が含まれています。
o Congestion control [5] presents a safe congestion control algorithm for coupling the behavior of the multiple paths in order to "do no harm" to other network users.
o 輻輳制御[5]は、他のネットワークユーザーに「害を与えない」ために複数のパスの動作を結合するための安全な輻輳制御アルゴリズムを提供します。
o Application considerations [6] discusses what impact MPTCP will have on applications, what applications will want to do with MPTCP, and as a consequence of these factors, what API extensions an MPTCP implementation should present.
o アプリケーションの考慮事項[6]では、MPTCPがアプリケーションに与える影響、アプリケーションがMPTCPで何をしたいか、そしてこれらの要因の結果として、MPTCP実装がどのAPI拡張を提供する必要があるかについて説明します。
In order to limit the potentially huge design space, the working group imposed two key constraints on the Multipath TCP design presented in this document:
潜在的に巨大な設計スペースを制限するために、ワーキンググループは、このドキュメントで提示されているマルチパスTCP設計に2つの主要な制約を課しました。
o It must be backwards-compatible with current, regular TCP, to increase its chances of deployment.
o 展開の可能性を高めるには、現在の通常のTCPとの下位互換性が必要です。
o It can be assumed that one or both hosts are multihomed and multiaddressed.
o 一方または両方のホストがマルチホーム化され、マルチアドレス指定されていると想定できます。
To simplify the design, we assume that the presence of multiple addresses at a host is sufficient to indicate the existence of multiple paths. These paths need not be entirely disjoint: they may share one or many routers between them. Even in such a situation, making use of multiple paths is beneficial, improving resource utilization and resilience to a subset of node failures. The congestion control algorithms defined in [5] ensure this does not act detrimentally. Furthermore, there may be some scenarios where different TCP ports on a single host can provide disjoint paths (such as through certain Equal-Cost Multipath (ECMP) implementations [7]), and so the MPTCP design also supports the use of ports in path identifiers.
設計を単純化するために、ホストに複数のアドレスが存在することで、複数のパスの存在を示すのに十分であると想定します。これらのパスは完全にばらばらである必要はありません。パス間で1つまたは複数のルーターを共有する場合があります。このような状況でも、複数のパスを使用することは有益であり、リソースの使用率とノード障害のサブセットに対する回復力が向上します。 [5]で定義されている輻輳制御アルゴリズムは、これが有害な動作をしないことを保証します。さらに、単一のホスト上の異なるTCPポートがばらばらのパスを提供できる（特定の等コストマルチパス（ECMP）実装[7]など）場合があるため、MPTCP設計はパス内のポートの使用もサポートします。識別子。
There are three aspects to the backwards-compatibility listed above (discussed in more detail in [2]):
上記の下位互換性には3つの側面があります（[2]で詳細に説明）。
External Constraints: The protocol must function through the vast majority of existing middleboxes such as NATs, firewalls, and proxies, and as such must resemble existing TCP as far as possible on the wire. Furthermore, the protocol must not assume the segments it sends on the wire arrive unmodified at the destination: they may be split or coalesced; TCP options may be removed or duplicated.
外部制約：プロトコルは、NAT、ファイアウォール、プロキシなどの既存のミドルボックスの大部分で機能する必要があり、回線上で可能な限り既存のTCPに類似している必要があります。さらに、プロトコルは、回線上で送信するセグメントが変更されずに宛先に到着することを前提としてはなりません。これらのセグメントは分割または合体される場合があります。 TCPオプションは削除または複製される場合があります。
Application Constraints: The protocol must be usable with no change to existing applications that use the common TCP API (although it is reasonable that not all features would be available to such legacy applications). Furthermore, the protocol must provide the same service model as regular TCP to the application.
アプリケーションの制約：プロトコルは、共通のTCP APIを使用する既存のアプリケーションに変更を加えずに使用できる必要があります（そのようなレガシーアプリケーションですべての機能が使用できるわけではないのは当然です）。さらに、プロトコルは、通常のTCPと同じサービスモデルをアプリケーションに提供する必要があります。
Fallback: The protocol should be able to fall back to standard TCP with no interference from the user, to be able to communicate with legacy hosts.
フォールバック：プロトコルは、レガシーホストと通信できるように、ユーザーからの干渉なしに標準TCPにフォールバックできる必要があります。
The complementary application considerations document [6] discusses the necessary features of an API to provide backwards-compatibility, as well as API extensions to convey the behavior of MPTCP at a level of control and information equivalent to that available with regular, single-path TCP.
補足的なアプリケーションの考慮事項に関するドキュメント[6]では、後方互換性を提供するために必要なAPIの機能と、通常の単一パスTCPで利用可能なものと同等の制御および情報レベルでMPTCPの動作を伝えるためのAPI拡張について説明します。
Further discussion of the design constraints and associated design decisions are given in the MPTCP Architecture document [2] and in [8].
設計の制約と関連する設計の決定の詳細については、MPTCPアーキテクチャドキュメント[2]と[8]に記載されています。
MPTCP operates at the transport layer and aims to be transparent to both higher and lower layers. It is a set of additional features on top of standard TCP; Figure 1 illustrates this layering. MPTCP is designed to be usable by legacy applications with no changes; detailed discussion of its interactions with applications is given in [6].
MPTCPはトランスポート層で動作し、上位層と下位層の両方に対して透過的であることを目的としています。これは、標準TCPに追加された一連の追加機能です。図1は、この階層化を示しています。 MPTCPは、変更なしでレガシーアプリケーションで使用できるように設計されています。アプリケーションとの相互作用の詳細については、[6]を参照してください。
+-------------------------------+
| Application |
+---------------+ +-------------------------------+
| Application | | MPTCP |
+---------------+ + - - - - - - - + - - - - - - - +
| TCP | | Subflow (TCP) | Subflow (TCP) |
+---------------+ +-------------------------------+
| IP | | IP | IP |
+---------------+ +-------------------------------+
Figure 1: Comparison of Standard TCP and MPTCP Protocol Stacks
図1：標準TCPとMPTCPプロトコルスタックの比較
This document makes use of a number of terms that are either MPTCP-specific or have defined meaning in the context of MPTCP, as follows:
このドキュメントでは、MPTCP固有の用語、またはMPTCPのコンテキストで意味が定義されている次のようないくつかの用語を使用しています。
Path: A sequence of links between a sender and a receiver, defined in this context by a 4-tuple of source and destination address/ port pairs.
パス：送信元と受信先の間の一連のリンク。このコンテキストでは、送信元と宛先のアドレス/ポートのペアの4タプルによって定義されます。
Subflow: A flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection. A subflow is started and terminated similar to a regular TCP connection.
サブフロー：個々のパス上で動作するTCPセグメントのフロー。これは、より大きなMPTCP接続の一部を形成します。サブフローは、通常のTCP接続と同様に開始および終了します。
(MPTCP) Connection: A set of one or more subflows, over which an application can communicate between two hosts. There is a one-to-one mapping between a connection and an application socket.
（MPTCP）接続：アプリケーションが2つのホスト間で通信できる1つ以上のサブフローのセット。接続とアプリケーションソケットの間には1対1のマッピングがあります。
Data-level: The payload data is nominally transferred over a connection, which in turn is transported over subflows. Thus, the term "data-level" is synonymous with "connection level", in contrast to "subflow-level", which refers to properties of an individual subflow.
データ・レベル：ペイロード・データは、名目上、接続を介して転送され、次に接続がサブフローを介して転送されます。したがって、「データレベル」という用語は、個々のサブフローのプロパティを指す「サブフローレベル」とは対照的に、「接続レベル」と同義です。
Token: A locally unique identifier given to a multipath connection by a host. May also be referred to as a "Connection ID".
トークン：ホストによってマルチパス接続に与えられたローカルで一意の識別子。 「接続ID」とも呼ばれます。
Host: An end host operating an MPTCP implementation, and either initiating or accepting an MPTCP connection.
ホスト：MPTCP実装を操作し、MPTCP接続を開始または受け入れるエンドホスト。
In addition to these terms, note that MPTCP's interpretation of, and effect on, regular single-path TCP semantics are discussed in Section 4.
これらの用語に加えて、通常の単一パスTCPセマンティクスのMPTCPの解釈とその影響については、セクション4で説明します。
This section provides a high-level summary of normal operation of MPTCP, and is illustrated by the scenario shown in Figure 2. A detailed description of operation is given in Section 3.
このセクションでは、MPTCPの通常の操作の概要を示し、図2に示すシナリオで説明します。操作の詳細な説明は、セクション3にあります。
o To a non-MPTCP-aware application, MPTCP will behave the same as normal TCP. Extended APIs could provide additional control to MPTCP-aware applications [6]. An application begins by opening a TCP socket in the normal way. MPTCP signaling and operation are handled by the MPTCP implementation.
o MPTCP非対応のアプリケーションでは、MPTCPは通常のTCPと同じように動作します。拡張APIは、MPTCP対応アプリケーションに追加の制御を提供できます[6]。アプリケーションは、通常の方法でTCPソケットを開くことから始まります。 MPTCPシグナリングと操作は、MPTCP実装によって処理されます。
o An MPTCP connection begins similarly to a regular TCP connection. This is illustrated in Figure 2 where an MPTCP connection is established between addresses A1 and B1 on Hosts A and B, respectively.
o MPTCP接続は、通常のTCP接続と同様に始まります。これを図2に示します。ここでは、ホストAとBのアドレスA1とB1の間にMPTCP接続がそれぞれ確立されています。
o If extra paths are available, additional TCP sessions (termed MPTCP "subflows") are created on these paths, and are combined with the existing session, which continues to appear as a single connection to the applications at both ends. The creation of the additional TCP session is illustrated between Address A2 on Host A and Address B1 on Host B.
o 追加のパスが利用可能な場合、追加のTCPセッション（MPTCP "サブフロー"と呼ばれます）がこれらのパス上に作成され、既存のセッションと結合され、両端のアプリケーションへの単一の接続として引き続き表示されます。追加のTCPセッションの作成は、ホストAのアドレスA2とホストBのアドレスB1の間で示されています。
o MPTCP identifies multiple paths by the presence of multiple addresses at hosts. Combinations of these multiple addresses equate to the additional paths. In the example, other potential paths that could be set up are A1<->B2 and A2<->B2. Although this additional session is shown as being initiated from A2, it could equally have been initiated from B1.
o MPTCPは、ホストに複数のアドレスが存在することにより、複数のパスを識別します。これらの複数のアドレスの組み合わせは、追加のパスと同じです。この例では、設定できる他の潜在的なパスはA1 <-> B2とA2 <-> B2です。この追加のセッションはA2から開始されたものとして示されていますが、B1から同様に開始された可能性もあります。
o The discovery and setup of additional subflows will be achieved through a path management method; this document describes a mechanism by which a host can initiate new subflows by using its own additional addresses, or by signaling its available addresses to the other host.
o 追加のサブフローの検出とセットアップは、パス管理方法によって実現されます。このドキュメントでは、ホストが独自の追加アドレスを使用するか、使用可能なアドレスを他のホストにシグナリングすることにより、ホストが新しいサブフローを開始できるメカニズムについて説明します。
o MPTCP adds connection-level sequence numbers to allow the reassembly of segments arriving on multiple subflows with differing network delays.
o MPTCPは、接続レベルのシーケンス番号を追加して、ネットワーク遅延が異なる複数のサブフローに到着するセグメントを再構成できるようにします。
o Subflows are terminated as regular TCP connections, with a four-way FIN handshake. The MPTCP connection is terminated by a connection-level FIN.
o サブフローは、4方向FINハンドシェイクにより、通常のTCP接続として終了します。 MPTCP接続は、接続レベルのFINによって終了します。
Host A Host B
------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ----------
| | | |
| (initial connection setup) | |
|----------------------------------->| |
|<-----------------------------------| |
| | | |
| (additional subflow setup) |
| |--------------------->| |
| |<---------------------| |
| | | |
| | | |
Figure 2: Example MPTCP Usage Scenario
図2：MPTCP使用シナリオの例
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [3]で説明されているように解釈されます。
This section presents a single description of common MPTCP operation, with reference to the protocol operation. This is a high-level overview of the key functions; the full specification follows in Section 3. Extensibility and negotiated features are not discussed here. Considerable reference is made to symbolic names of MPTCP options throughout this section -- these are subtypes of the IANA-assigned MPTCP option (see Section 8), and their formats are defined in the detailed protocol specification that follows in Section 3.
このセクションでは、プロトコル操作を参照しながら、一般的なMPTCP操作について1つ説明します。これは、主要な機能の概要です。仕様全体はセクション3で説明します。拡張性と交渉された機能については、ここでは説明しません。このセクション全体で、MPTCPオプションのシンボリック名がかなり参照されています。これらは、IANAによって割り当てられたMPTCPオプション（セクション8を参照）のサブタイプであり、そのフォーマットは、セクション3に続く詳細なプロトコル仕様で定義されています。
A Multipath TCP connection provides a bidirectional bytestream between two hosts communicating like normal TCP and, thus, does not require any change to the applications. However, Multipath TCP enables the hosts to use different paths with different IP addresses to exchange packets belonging to the MPTCP connection. A Multipath TCP connection appears like a normal TCP connection to an application. However, to the network layer, each MPTCP subflow looks like a regular TCP flow whose segments carry a new TCP option type. Multipath TCP manages the creation, removal, and utilization of these subflows to send data. The number of subflows that are managed within a Multipath TCP connection is not fixed and it can fluctuate during the lifetime of the Multipath TCP connection.
マルチパスTCP接続は、通常のTCPのように通信する2つのホスト間に双方向バイトストリームを提供するため、アプリケーションを変更する必要はありません。ただし、マルチパスTCPを使用すると、ホストは異なるIPアドレスの異なるパスを使用して、MPTCP接続に属するパケットを交換できます。マルチパスTCP接続は、アプリケーションへの通常のTCP接続のように見えます。ただし、ネットワーク層では、各MPTCPサブフローは通常のTCPフローのように見え、そのセグメントには新しいTCPオプションタイプが含まれます。マルチパスTCPは、これらのサブフローの作成、削除、および使用を管理して、データを送信します。マルチパスTCP接続内で管理されるサブフローの数は固定されておらず、マルチパスTCP接続の存続期間中に変動する可能性があります。
All MPTCP operations are signaled with a TCP option -- a single numerical type for MPTCP, with "sub-types" for each MPTCP message. What follows is a summary of the purpose and rationale of these messages.
すべてのMPTCP操作は、TCPオプション（MPTCPの単一の数値タイプ、各MPTCPメッセージの「サブタイプ」）で通知されます。以下は、これらのメッセージの目的と根拠の要約です。
This is the same signaling as for initiating a normal TCP connection, but the SYN, SYN/ACK, and ACK packets also carry the MP_CAPABLE option. This is variable length and serves multiple purposes. Firstly, it verifies whether the remote host supports Multipath TCP; secondly, this option allows the hosts to exchange some information to authenticate the establishment of additional subflows. Further details are given in Section 3.1.
これは、通常のTCP接続を開始する場合と同じシグナリングですが、SYN、SYN / ACK、およびACKパケットにもMP_CAPABLEオプションが含まれています。これは可変長であり、複数の目的に役立ちます。まず、リモートホストがマルチパスTCPをサポートしているかどうかを確認します。次に、このオプションにより、ホストはいくつかの情報を交換して、追加のサブフローの確立を認証できます。詳細については、セクション3.1を参照してください。
Host A Host B
------ ------
MP_CAPABLE ->
[A's key, flags]
<- MP_CAPABLE
[B's key, flags]
ACK + MP_CAPABLE ->
[A's key, B's key, flags]
The exchange of keys in the MP_CAPABLE handshake provides material that can be used to authenticate the endpoints when new subflows will be set up. Additional subflows begin in the same way as initiating a normal TCP connection, but the SYN, SYN/ACK, and ACK packets also carry the MP_JOIN option.
MP_CAPABLEハンドシェイクでの鍵の交換により、新しいサブフローがセットアップされるときにエンドポイントを認証するために使用できる資料が提供されます。追加のサブフローは、通常のTCP接続の開始と同じ方法で始まりますが、SYN、SYN / ACK、およびACKパケットもMP_JOINオプションを伝送します。
Host A initiates a new subflow between one of its addresses and one of Host B's addresses. The token -- generated from the key -- is used to identify which MPTCP connection it is joining, and the HMAC is used for authentication. The Hash-based Message Authentication Code (HMAC) uses the keys exchanged in the MP_CAPABLE handshake, and the random numbers (nonces) exchanged in these MP_JOIN options. MP_JOIN also contains flags and an Address ID that can be used to refer to the source address without the sender needing to know if it has been changed by a NAT. Further details are in Section 3.2.
ホストAは、そのアドレスの1つとホストBのアドレスの1つとの間に新しいサブフローを開始します。トークン（キーから生成されます）を使用して、加入しているMPTCP接続を識別し、HMACを認証に使用します。ハッシュベースのメッセージ認証コード（HMAC）は、MP_CAPABLEハンドシェイクで交換されるキーと、これらのMP_JOINオプションで交換される乱数（ノンス）を使用します。 MP_JOINには、送信元がNATによって変更されたかどうかを知る必要なく送信元アドレスを参照するために使用できるフラグとアドレスIDも含まれています。詳細はセクション3.2を参照してください。
Host A Host B
------ ------
MP_JOIN ->
[B's token, A's nonce,
A's Address ID, flags]
<- MP_JOIN
[B's HMAC, B's nonce,
B's Address ID, flags]
ACK + MP_JOIN ->
[A's HMAC]
<- ACK
<-ACK
The set of IP addresses associated to a multihomed host may change during the lifetime of an MPTCP connection. MPTCP supports the addition and removal of addresses on a host both implicitly and explicitly. If Host A has established a subflow starting at address IP#-A1 and wants to open a second subflow starting at address IP#-A2, it simply initiates the establishment of the subflow as explained above. The remote host will then be implicitly informed about the new address.
マルチホームホストに関連付けられたIPアドレスのセットは、MPTCP接続の存続期間中に変更される可能性があります。 MPTCPは、ホスト上でのアドレスの追加と削除を暗黙的および明示的にサポートしています。ホストAがアドレスIP＃-A1で開始するサブフローを確立し、アドレスIP＃-A2で開始する2番目のサブフローを開きたい場合、ホストAは上記のようにサブフローの確立を開始するだけです。その後、リモートホストに新しいアドレスが暗黙的に通知されます。
In some circumstances, a host may want to advertise to the remote host the availability of an address without establishing a new subflow, for example, when a NAT prevents setup in one direction. In the example below, Host A informs Host B about its alternative IP address (IP#-A2). Host B may later send an MP_JOIN to this new address. Due to the presence of middleboxes that may translate IP addresses, this option uses an address identifier to unambiguously identify an address on a host. Further details are in Section 3.4.1.
状況によっては、ホストがリモートホストに、新しいサブフローを確立せずにアドレスの可用性をアドバタイズする場合があります。次の例では、ホストAがホストBに代替IPアドレス（IP＃-A2）を通知しています。ホストBは後でこの新しいアドレスにMP_JOINを送信できます。 IPアドレスを変換する可能性のあるミドルボックスが存在するため、このオプションはアドレス識別子を使用してホスト上のアドレスを明確に識別します。詳細はセクション3.4.1にあります。
Host A Host B
------ ------
ADD_ADDR ->
[IP#-A2,
IP#-A2's Address ID]
There is a corresponding signal for address removal, making use of the Address ID that is signaled in the add address handshake. Further details in Section 3.4.2.
追加アドレスハンドシェイクで通知されるアドレスIDを利用して、アドレス削除に対応する信号があります。詳細はセクション3.4.2をご覧ください。
Host A Host B
------ ------
REMOVE_ADDR ->
[IP#-A2's Address ID]
To ensure reliable, in-order delivery of data over subflows that may appear and disappear at any time, MPTCP uses a 64-bit data sequence number (DSN) to number all data sent over the MPTCP connection. Each subflow has its own 32-bit sequence number space and an MPTCP option maps the subflow sequence space to the data sequence space. In this way, data can be retransmitted on different subflows (mapped to the same DSN) in the event of failure.
MPTCPは、いつでも現れたり消えたりする可能性があるサブフローを介して、信頼性の高い順序どおりのデータ配信を保証するために、64ビットのデータシーケンス番号（DSN）を使用して、MPTCP接続で送信されるすべてのデータに番号を付けます。各サブフローには独自の32ビットシーケンス番号スペースがあり、MPTCPオプションはサブフローシーケンススペースをデータシーケンススペースにマップします。このようにして、障害が発生した場合に、データを（同じDSNにマップされた）異なるサブフローで再送信できます。
The "Data Sequence Signal" carries the "Data Sequence Mapping". The data sequence mapping consists of the subflow sequence number, data sequence number, and length for which this mapping is valid. This option can also carry a connection-level acknowledgment (the "Data ACK") for the received DSN.
「データシーケンス信号」には「データシーケンスマッピング」が含まれています。データシーケンスマッピングは、このマッピングが有効なサブフローシーケンス番号、データシーケンス番号、および長さで構成されます。このオプションは、受信したDSNの接続レベルの確認応答（「データACK」）を運ぶこともできます。
With MPTCP, all subflows share the same receive buffer and advertise the same receive window. There are two levels of acknowledgment in MPTCP. Regular TCP acknowledgments are used on each subflow to acknowledge the reception of the segments sent over the subflow independently of their DSN. In addition, there are connection-level acknowledgments for the data sequence space. These acknowledgments track the advancement of the bytestream and slide the receiving window.
MPTCPでは、すべてのサブフローが同じ受信バッファを共有し、同じ受信ウィンドウをアドバタイズします。 MPTCPには2つのレベルの確認応答があります。各サブフローで通常のTCP確認応答が使用され、DSNとは無関係にサブフローを介して送信されたセグメントの受信を確認します。さらに、データシーケンススペースに対する接続レベルの確認応答があります。これらの確認応答は、バイトストリームの進歩を追跡し、受信ウィンドウをスライドさせます。
Further details are in Section 3.3.
詳細はセクション3.3にあります。
Host A Host B
------ ------
DATA_SEQUENCE_SIGNAL ->
[Data Sequence Mapping]
[Data ACK]
[Checksum]
Hosts can indicate at initial subflow setup whether they wish the subflow to be used as a regular or backup path -- a backup path only being used if there are no regular paths available. During a connection, Host A can request a change in the priority of a subflow through the MP_PRIO signal to Host B. Further details are in Section 3.3.8.
ホストは、サブフローの初期設定時に、サブフローを通常のパスとして使用するか、バックアップパスとして使用するかを指定できます。バックアップパスは、使用可能な通常のパスがない場合にのみ使用されます。接続中に、ホストAはMP_PRIO信号を介してホストBへのサブフローの優先度の変更を要求できます。詳細はセクション3.3.8を参照してください。
Host A Host B
------ ------
MP_PRIO ->
When Host A wants to inform Host B that it has no more data to send, it signals this "Data FIN" as part of the Data Sequence Signal (see above). It has the same semantics and behavior as a regular TCP FIN, but at the connection level. Once all the data on the MPTCP connection has been successfully received, then this message is acknowledged at the connection level with a DATA_ACK. Further details are in Section 3.3.3.
ホストAが送信するデータがないことをホストBに通知する場合、ホストAはこの「データFIN」をデータシーケンス信号の一部として信号で通知します（上記を参照）。通常のTCP FINと同じセマンティクスと動作を持っていますが、接続レベルです。 MPTCP接続のすべてのデータが正常に受信されると、このメッセージはDATA_ACKで接続レベルで確認されます。詳細はセクション3.3.3にあります。
Host A Host B
------ ------
DATA_SEQUENCE_SIGNAL ->
[Data FIN]
<- (MPTCP DATA_ACK)
<-（MPTCP DATA_ACK）
It is worth highlighting that MPTCP's signaling has been designed with several key requirements in mind:
MPTCPのシグナリングがいくつかの重要な要件を念頭に置いて設計されていることを強調する価値があります。
o To cope with NATs on the path, addresses are referred to by Address IDs, in case the IP packet's source address gets changed by a NAT. Setting up a new TCP flow is not possible if the passive opener is behind a NAT; to allow subflows to be created when either end is behind a NAT, MPTCP uses the ADD_ADDR message.
o パス上のNATに対処するために、IPパケットの送信元アドレスがNATによって変更された場合に備えて、アドレスはアドレスIDによって参照されます。パッシブオープナーがNATの背後にある場合、新しいTCPフローを設定することはできません。どちらかの端がNATの背後にあるときにサブフローを作成できるようにするために、MPTCPはADD_ADDRメッセージを使用します。
o MPTCP falls back to ordinary TCP if MPTCP operation is not possible, for example, if one host is not MPTCP capable or if a middlebox alters the payload.
o たとえば、1つのホストがMPTCPに対応していない場合や、ミドルボックスがペイロードを変更した場合など、MPTCP操作が不可能な場合、MPTCPは通常のTCPにフォールバックします。
o To meet the threats identified in [9], the following steps are taken: keys are sent in the clear in the MP_CAPABLE messages; MP_JOIN messages are secured with HMAC-SHA1 ([10], [4]) using those keys; and standard TCP validity checks are made on the other messages (ensuring sequence numbers are in-window).
o [9]で特定された脅威に対処するために、次の手順が実行されます。キーは、MP_CAPABLEメッセージで平文で送信されます。 MP_JOINメッセージは、これらのキーを使用してHMAC-SHA1（[10]、[4]）で保護されます。また、標準のTCP妥当性検査が他のメッセージに対して行われます（シーケンス番号がウィンドウ内にあることを確認します）。
This section describes the operation of the MPTCP protocol, and is subdivided into sections for each key part of the protocol operation.
このセクションでは、MPTCPプロトコルの操作について説明し、プロトコル操作の主要な部分ごとにセクションに分かれています。
All MPTCP operations are signaled using optional TCP header fields. A single TCP option number ("Kind") has been assigned by IANA for MPTCP (see Section 8), and then individual messages will be determined by a "subtype", the values of which are also stored in an IANA registry (and are also listed in Section 8).
すべてのMPTCP操作は、オプションのTCPヘッダーフィールドを使用して通知されます。単一のTCPオプション番号（「種類」）がITCPによってMPTCPに割り当てられ（セクション8を参照）、個々のメッセージは「サブタイプ」によって決定され、その値はIANAレジストリにも格納されます（およびセクション8にも記載されています。
Throughout this document, when reference is made to an MPTCP option by symbolic name, such as "MP_CAPABLE", this refers to a TCP option with the single MPTCP option type, and with the subtype value of the symbolic name as defined in Section 8. This subtype is a 4-bit field -- the first 4 bits of the option payload, as shown in Figure 3. The MPTCP messages are defined in the following sections.
このドキュメント全体を通して、「MP_CAPABLE」などのシンボリック名でMPTCPオプションを参照する場合、これは、1つのMPTCPオプションタイプと、セクション8で定義されているシンボリック名のサブタイプ値を持つTCPオプションを指します。このサブタイプは4ビットのフィールドです。図3に示すように、オプションペイロードの最初の4ビットです。MPTCPメッセージは次のセクションで定義されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----------------------+
| Kind | Length |Subtype| |
+---------------+---------------+-------+ |
| Subtype-specific data |
| (variable length) |
+---------------------------------------------------------------+
Figure 3: MPTCP Option Format
図3：MPTCPオプションの形式
Those MPTCP options associated with subflow initiation are used on packets with the SYN flag set. Additionally, there is one MPTCP option for signaling metadata to ensure segmented data can be recombined for delivery to the application.
サブフローの開始に関連するMPTCPオプションは、SYNフラグが設定されたパケットで使用されます。さらに、メタデータをシグナリングするための1つのMPTCPオプションがあり、セグメント化されたデータを確実に再結合してアプリケーションに配信できます。
The remaining options, however, are signals that do not need to be on a specific packet, such as those for signaling additional addresses. Whilst an implementation may desire to send MPTCP options as soon as possible, it may not be possible to combine all desired options (both those for MPTCP and for regular TCP, such as SACK (selective acknowledgment) [11]) on a single packet. Therefore, an implementation may choose to send duplicate ACKs containing the additional signaling information. This changes the semantics of a duplicate ACK; these are usually only sent as a signal of a lost segment [12] in regular TCP. Therefore, an MPTCP implementation receiving a duplicate ACK that contains an MPTCP option MUST NOT treat it as a signal of congestion. Additionally, an MPTCP implementation SHOULD NOT send more than two duplicate ACKs in a row for the purposes of sending MPTCP options alone, in order to ensure no middleboxes misinterpret this as a sign of congestion.
ただし、残りのオプションは、追加のアドレスをシグナリングするためのものなど、特定のパケット上にある必要がない信号です。実装はMPTCPオプションをできるだけ早く送信することを望むかもしれませんが、単一のパケットですべての必要なオプション（MPTCPのオプションとSACK（選択的確認応答）[11]などの通常のTCPのオプションの両方）を組み合わせることができない場合があります。したがって、実装は、追加のシグナリング情報を含む重複したACKを送信することを選択できます。これにより、重複するACKのセマンティクスが変更されます。これらは通常、通常のTCPで失われたセグメント[12]の信号としてのみ送信されます。したがって、MPTCPオプションを含む重複ACKを受信するMPTCP実装は、それを輻輳の信号として処理してはなりません（MUST NOT）。さらに、ミドルボックスがこれを輻輳の兆候と誤って解釈しないようにするために、MPTCP実装は、MPTCPオプションのみを送信する目的で、3つ以上の重複したACKを続けて送信しないでください。
Furthermore, standard TCP validity checks (such as ensuring the sequence number and acknowledgment number are within window) MUST be undertaken before processing any MPTCP signals, as described in [13].
さらに、[13]で説明されているように、MPTCP信号を処理する前に、標準のTCP有効性チェック（シーケンス番号と確認応答番号がウィンドウ内にあることの確認など）を実行する必要があります。
Connection initiation begins with a SYN, SYN/ACK, ACK exchange on a single path. Each packet contains the Multipath Capable (MP_CAPABLE) TCP option (Figure 4). This option declares its sender is capable of performing Multipath TCP and wishes to do so on this particular connection.
接続の開始は、単一パスでのSYN、SYN / ACK、ACK交換で始まります。各パケットには、マルチパス対応（MP_CAPABLE）TCPオプションが含まれています（図4）。このオプションは、送信者がマルチパスTCPを実行できることを宣言し、この特定の接続で実行することを望んでいます。
This option is used to declare the 64-bit key that the sender has generated for this MPTCP connection. This key is used to authenticate the addition of future subflows to this connection. This is the only time the key will be sent in clear on the wire (unless "fast close", Section 3.5, is used); all future subflows will identify the connection using a 32-bit "token". This token is a cryptographic hash of this key. The algorithm for this process is dependent on the authentication algorithm selected; the method of selection is defined later in this section.
このオプションは、送信者がこのMPTCP接続用に生成した64ビットキーを宣言するために使用されます。このキーは、この接続への将来のサブフローの追加を認証するために使用されます。これは、鍵が平文で送信される唯一の時間です（「高速クローズ」、セクション3.5が使用されている場合を除く）。今後のすべてのサブフローは、32ビットの「トークン」を使用して接続を識別します。このトークンは、このキーの暗号化ハッシュです。このプロセスのアルゴリズムは、選択した認証アルゴリズムによって異なります。選択方法は、このセクションの後半で定義されています。
This key is generated by its sender, and its method of generation is implementation specific. The key MUST be hard to guess, and it MUST be unique for the sending host at any one time. Recommendations for generating random numbers for use in keys are given in [14]. Connections will be indexed at each host by the token (a one-way hash of the key). Therefore, an implementation will require a mapping from each token to the corresponding connection, and in turn to the keys for the connection.
このキーは送信者によって生成され、その生成方法は実装固有です。キーは推測が困難である必要があり、送信ホストに対して常に一意である必要があります。キーで使用する乱数を生成するための推奨事項は、[14]に記載されています。接続は、各ホストでトークン（キーの一方向ハッシュ）によってインデックスが作成されます。したがって、実装では、各トークンから対応する接続へのマッピング、そして接続のキーへのマッピングが必要になります。
There is a risk that two different keys will hash to the same token. The risk of hash collisions is usually small, unless the host is handling many tens of thousands of connections. Therefore, an implementation SHOULD check its list of connection tokens to ensure there is not a collision before sending its key in the SYN/ACK. This would, however, be costly for a server with thousands of connections. The subflow handshake mechanism (Section 3.2) will ensure that new subflows only join the correct connection, however, through the cryptographic handshake, as well as checking the connection tokens in both directions, and ensuring sequence numbers are in-window. So in the worst case if there was a token collision, the new subflow would not succeed, but the MPTCP connection would continue to provide a regular TCP service.
2つの異なるキーが同じトークンにハッシュされるリスクがあります。ホストが何万もの接続を処理していない限り、ハッシュの衝突のリスクは通常小さいです。したがって、実装では、SYN / ACKでキーを送信する前に、接続トークンのリストをチェックして衝突がないことを確認する必要があります（SHOULD）。ただし、これは何千もの接続を持つサーバーにとってはコストがかかります。サブフローハンドシェイクメカニズム（セクション3.2）は、新しいサブフローが正しい接続に参加することを保証しますが、暗号化ハンドシェイクを介して、双方向の接続トークンをチェックし、シーケンス番号がウィンドウ内にあることを確認します。したがって、最悪の場合、トークンの衝突があった場合、新しいサブフローは成功しませんが、MPTCP接続は通常のTCPサービスを提供し続けます。
The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets that start the first subflow of an MPTCP connection. The data carried by each packet is as follows, where A = initiator and B = listener.
MP_CAPABLEオプションは、MPTCP接続の最初のサブフローを開始するSYN、SYN / ACK、およびACKパケットで伝送されます。各パケットで伝送されるデータは次のとおりです。ここで、A =イニシエーターおよびB =リスナーです。
o SYN (A->B): A's Key for this connection.
o SYN（A-> B）：この接続のAのキー。
o SYN/ACK (B->A): B's Key for this connection.
o SYN / ACK（B-> A）：この接続のBのキー。
o ACK (A->B): A's Key followed by B's Key.
o ACK（A-> B）：Aのキーの後にBのキー。
The contents of the option is determined by the SYN and ACK flags of the packet, verified by the option's length field. For the diagram shown in Figure 4, "sender" and "receiver" refer to the sender or receiver of the TCP packet (which can be either host). If the SYN flag is set, a single key is included; if only an ACK flag is set, both keys are present.
オプションの内容は、パケットのSYNフラグとACKフラグによって決定され、オプションの長さフィールドによって確認されます。図4に示す図では、「送信者」と「受信者」はTCPパケットの送信者または受信者（どちらのホストでもかまいません）を指します。 SYNフラグが設定されている場合、単一のキーが含まれます。 ACKフラグのみが設定されている場合、両方のキーが存在します。
B's Key is echoed in the ACK in order to allow the listener (Host B) to act statelessly until the TCP connection reaches the ESTABLISHED state. If the listener acts in this way, however, it MUST generate its key in a way that would allow it to verify that it generated the key when it is echoed in the ACK.
Bのキーは、TCP接続がESTABLISHED状態に達するまでリスナー（ホストB）がステートレスに動作できるようにするために、ACKでエコーされます。ただし、リスナーがこのように動作する場合は、ACKにエコーされたときにキーを生成したことを確認できるように、キーを生成する必要があります。
This exchange allows the safe passage of MPTCP options on SYN packets to be determined. If any of these options are dropped, MPTCP will gracefully fall back to regular single-path TCP, as documented in Section 3.6. Note that new subflows MUST NOT be established (using the process documented in Section 3.2) until a Digital Signature Standard (DSS) option has been successfully received across the path (as documented in Section 3.3).
この交換により、SYNパケットのMPTCPオプションを安全に通過させることができます。これらのオプションのいずれかが削除されると、セクション3.6に記載されているように、MPTCPは通常の単一パスTCPに正常にフォールバックします。デジタル署名標準（DSS）オプションがパス全体で正常に受信されるまで（セクション3.2に記載されているプロセスを使用して）、新しいサブフローを確立してはならないことに注意してください（セクション3.3に記載されています）。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
| Kind | Length |Subtype|Version|A|B|C|D|E|F|G|H|
+---------------+---------------+-------+-------+---------------+
| Option Sender's Key (64 bits) |
| |
| |
+---------------------------------------------------------------+
| Option Receiver's Key (64 bits) |
| (if option Length == 20) |
| |
+---------------------------------------------------------------+
Figure 4: Multipath Capable (MP_CAPABLE) Option
図4：マルチパス対応（MP_CAPABLE）オプション
The first 4 bits of the first octet in the MP_CAPABLE option (Figure 4) define the MPTCP option subtype (see Section 8; for MP_CAPABLE, this is 0), and the remaining 4 bits of this octet specify the MPTCP version in use (for this specification, this is 0).
MP_CAPABLEオプション（図4）の最初のオクテットの最初の4ビットはMPTCPオプションサブタイプを定義し（セクション8を参照。MP_CAPABLEの場合、これは0です）、このオクテットの残りの4ビットは使用中のMPTCPバージョンを指定します（この仕様、これは0です）。
The second octet is reserved for flags, allocated as follows:
2番目のオクテットはフラグ用に予約されており、次のように割り当てられます。
A: The leftmost bit, labeled "A", SHOULD be set to 1 to indicate "Checksum Required", unless the system administrator has decided that checksums are not required (for example, if the environment is controlled and no middleboxes exist that might adjust the payload).
A：「A」というラベルの付いた左端のビットは、チェックサムが不要であるとシステム管理者が判断しない限り（たとえば、環境が制御されていて、調整される可能性のあるミドルボックスが存在しない場合）、「チェックサムが必要」を示す1に設定する必要があります。ペイロード）。
B: The second bit, labeled "B", is an extensibility flag, and MUST be set to 0 for current implementations. This will be used for an extensibility mechanism in a future specification, and the impact of this flag will be defined at a later date. If receiving a message with the 'B' flag set to 1, and this is not understood, then this SYN MUST be silently ignored; the sender is expected to retry with a format compatible with this legacy specification. Note that the length of the MP_CAPABLE option, and the meanings of bits "C" through "H", may be altered by setting B=1.
B：「B」というラベルが付いた2番目のビットは拡張性フラグであり、現在の実装では0に設定する必要があります。これは、将来の仕様で拡張メカニズムに使用され、このフラグの影響は後日定義されます。 「B」フラグが1に設定されたメッセージを受信し、これが理解されない場合、このSYNは黙って無視されなければならない（MUST）。送信者は、この従来の仕様と互換性のある形式で再試行することが期待されています。 MP_CAPABLEオプションの長さ、およびビット "C"から "H"の意味は、B = 1を設定することによって変更できることに注意してください。
C through H: The remaining bits, labeled "C" through "H", are used for crypto algorithm negotiation. Currently only the rightmost bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC-SHA1 (as defined in Section 3.2). An implementation that only supports this method MUST set bit "H" to 1, and bits "C" through "G" to 0.
CからH：「C」から「H」のラベルが付いた残りのビットは、暗号アルゴリズムのネゴシエーションに使用されます。現在、「H」というラベルの付いた右端のビットのみが割り当てられています。ビット「H」は、HMAC-SHA1（セクション3.2で定義）の使用を示します。このメソッドのみをサポートする実装では、ビット「H」を1に、ビット「C」から「G」を0に設定する必要があります。
A crypto algorithm MUST be specified. If flag bits C through H are all 0, the MP_CAPABLE option MUST be treated as invalid and ignored (that is, it must be treated as a regular TCP handshake).
暗号アルゴリズムを指定する必要があります。フラグビットCからHがすべて0の場合、MP_CAPABLEオプションは無効として扱われ、無視されなければなりません（つまり、通常のTCPハンドシェイクとして扱われなければなりません）。
The selection of the authentication algorithm also impacts the algorithm used to generate the token and the initial data sequence number (IDSN). In this specification, with only the SHA-1 algorithm (bit "H") specified and selected, the token MUST be a truncated (most significant 32 bits) SHA-1 hash ([4], [15]) of the key. A different, 64-bit truncation (the least significant 64 bits) of the SHA-1 hash of the key MUST be used as the initial data sequence number. Note that the key MUST be hashed in network byte order. Also note that the "least significant" bits MUST be the rightmost bits of the SHA-1 digest, as per [4]. Future specifications of the use of the crypto bits may choose to specify different algorithms for token and IDSN generation.
認証アルゴリズムの選択は、トークンと初期データシーケンス番号（IDSN）の生成に使用されるアルゴリズムにも影響します。この仕様では、SHA-1アルゴリズム（ビット "H"）のみが指定および選択されているため、トークンはキーの切り捨てられた（最上位32ビット）SHA-1ハッシュ（[4]、[15]）である必要があります。鍵のSHA-1ハッシュの別の64ビット切り捨て（最下位64ビット）を初期データシーケンス番号として使用する必要があります。キーはネットワークバイトオーダーでハッシュされなければならないことに注意してください。 [4]のように、「最下位」ビットはSHA-1ダイジェストの右端のビットでなければならないことに注意してください。暗号ビットの使用に関する将来の仕様では、トークンとIDSNの生成に異なるアルゴリズムを指定することを選択する可能性があります。
Both the crypto and checksum bits negotiate capabilities in similar ways. For the Checksum Required bit (labeled "A"), if either host requires the use of checksums, checksums MUST be used. In other words, the only way for checksums not to be used is if both hosts in their SYNs set A=0. This decision is confirmed by the setting of the "A" bit in the third packet (the ACK) of the handshake. For example, if the initiator sets A=0 in the SYN, but the responder sets A=1 in the SYN/ACK, checksums MUST be used in both directions, and the initiator will set A=1 in the ACK. The decision whether to use checksums will be stored by an implementation in a per-connection binary state variable.
暗号ビットとチェックサムビットの両方が、同様の方法で機能をネゴシエートします。チェックサム必須ビット（「A」のラベルが付いている）の場合、いずれかのホストでチェックサムの使用が必要な場合は、チェックサムを使用する必要があります。つまり、チェックサムが使用されない唯一の方法は、SYN内の両方のホストがA = 0に設定されている場合です。この決定は、ハンドシェイクの3番目のパケット（ACK）の「A」ビットの設定によって確認されます。たとえば、イニシエーターがSYNでA = 0を設定し、レスポンダーがSYN / ACKでA = 1を設定する場合、チェックサムを両方向で使用する必要があり、イニシエーターはACKでA = 1を設定します。チェックサムを使用するかどうかの決定は、接続ごとのバイナリ状態変数に実装によって格納されます。
For crypto negotiation, the responder has the choice. The initiator creates a proposal setting a bit for each algorithm it supports to 1 (in this version of the specification, there is only one proposal, so bit "H" will be always set to 1). The responder responds with only 1 bit set -- this is the chosen algorithm. The rationale for this behavior is that the responder will typically be a server with potentially many thousands of connections, so it may wish to choose an algorithm with minimal computational complexity, depending on the load. If a responder does not support (or does not want to support) any of the initiator's proposals, it can respond without an MP_CAPABLE option, thus forcing a fallback to regular TCP.
暗号ネゴシエーションでは、レスポンダが選択できます。イニシエーターは、サポートする各アルゴリズムのビットを1に設定する提案を作成します（このバージョンの仕様では、提案は1つしかないため、ビット "H"は常に1に設定されます）。レスポンダは1ビットセットだけで応答します。これが選択されたアルゴリズムです。この動作の理論的根拠は、レスポンダーは通常、何千もの接続を持つ可能性のあるサーバーであるため、負荷に応じて、計算の複雑さが最小限のアルゴリズムを選択することです。レスポンダがイニシエータの提案をサポートしていない（またはサポートしたくない）場合は、MP_CAPABLEオプションなしで応答できるため、通常のTCPに強制的にフォールバックします。
The MP_CAPABLE option is only used in the first subflow of a connection, in order to identify the connection; all following subflows will use the "Join" option (see Section 3.2) to join the existing connection.
MP_CAPABLEオプションは、接続を識別するために、接続の最初のサブフローでのみ使用されます。以下のすべてのサブフローは、「結合」オプション（セクション3.2を参照）を使用して既存の接続に結合します。
If a SYN contains an MP_CAPABLE option but the SYN/ACK does not, it is assumed that the passive opener is not multipath capable; thus, the MPTCP session MUST operate as a regular, single-path TCP. If a SYN does not contain a MP_CAPABLE option, the SYN/ACK MUST NOT contain one in response. If the third packet (the ACK) does not contain the MP_CAPABLE option, then the session MUST fall back to operating as a regular, single-path TCP. This is to maintain compatibility with middleboxes on the path that drop some or all TCP options. Note that an implementation MAY choose to attempt sending MPTCP options more than one time before making this decision to operate as regular TCP (see Section 3.8).
SYNにMP_CAPABLEオプションが含まれているが、SYN / ACKには含まれていない場合、パッシブオープナーはマルチパスに対応していないと見なされます。したがって、MPTCPセッションは、通常の単一パスTCPとして動作する必要があります。 SYNにMP_CAPABLEオプションが含まれていない場合、SYN / ACKは応答でオプションを含んではいけません（MUST NOT）。 3番目のパケット（ACK）にMP_CAPABLEオプションが含まれていない場合、セッションは通常の単一パスTCPとして動作するようにフォールバックする必要があります。これは、一部またはすべてのTCPオプションをドロップするパス上のミドルボックスとの互換性を維持するためです。実装は、通常のTCPとして動作することを決定する前に、MPTCPオプションの送信を複数回試みることを選択してもよいことに注意してください（セクション3.8を参照）。
If the SYN packets are unacknowledged, it is up to local policy to decide how to respond. It is expected that a sender will eventually fall back to single-path TCP (i.e., without the MP_CAPABLE option) in order to work around middleboxes that may drop packets with unknown options; however, the number of multipath-capable attempts that are made first will be up to local policy. It is possible that MPTCP and non-MPTCP SYNs could get reordered in the network. Therefore, the final state is inferred from the presence or absence of the MP_CAPABLE option in the third packet of the TCP handshake. If this option is not present, the connection SHOULD fall back to regular TCP, as documented in Section 3.6.
SYNパケットが未確認の場合、応答方法を決定するのはローカルポリシー次第です。不明なオプションでパケットをドロップする可能性があるミドルボックスを回避するために、送信者は最終的にシングルパスTCP（つまり、MP_CAPABLEオプションなし）にフォールバックすることが予想されます。ただし、最初に行われるマルチパス対応の試行回数はローカルポリシー次第です。 MPTCPと非MPTCP SYNがネットワークで並べ替えられる可能性があります。したがって、最終的な状態は、TCPハンドシェイクの3番目のパケット内のMP_CAPABLEオプションの有無から推測されます。このオプションが存在しない場合、セクション3.6で説明されているように、接続は通常のTCPにフォールバックする必要があります（SHOULD）。
The initial data sequence number on an MPTCP connection is generated from the key. The algorithm for IDSN generation is also determined from the negotiated authentication algorithm. In this specification, with only the SHA-1 algorithm specified and selected, the IDSN of a host MUST be the least significant 64 bits of the SHA-1 hash of its key, i.e., IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B). This deterministic generation of the IDSN allows a receiver to ensure that there are no gaps in sequence space at the start of the connection. The SYN with MP_CAPABLE occupies the first octet of data sequence space, although this does not need to be acknowledged at the connection level until the first data is sent (see Section 3.3).
MPTCP接続の初期データシーケンス番号は、キーから生成されます。 IDSN生成のアルゴリズムも、ネゴシエートされた認証アルゴリズムから決定されます。この仕様では、SHA-1アルゴリズムのみが指定および選択されているため、ホストのIDSNは、そのキーのSHA-1ハッシュの最下位64ビットでなければなりません。つまり、IDSN-A = Hash（Key-A）およびIDSN-B = Hash（Key-B）。 IDSNのこの確定的な生成により、受信者は接続の開始時にシーケンススペースにギャップがないことを確認できます。 MP_CAPABLEを指定したSYNは、データシーケンススペースの最初のオクテットを占有しますが、最初のデータが送信されるまで接続レベルで確認する必要はありません（セクション3.3を参照）。
Once an MPTCP connection has begun with the MP_CAPABLE exchange, further subflows can be added to the connection. Hosts have knowledge of their own address(es), and can become aware of the other host's addresses through signaling exchanges as described in Section 3.4. Using this knowledge, a host can initiate a new subflow over a currently unused pair of addresses. It is permitted for either host in a connection to initiate the creation of a new subflow, but it is expected that this will normally be the original connection initiator (see Section 3.8 for heuristics).
MP_CAPABLE交換でMPTCP接続が開始されると、さらにサブフローを接続に追加できます。ホストは自身のアドレスを知っており、セクション3.4で説明されているように、信号交換を通じて他のホストのアドレスを知ることができます。この知識を使用して、ホストは現在未使用のアドレスのペアに対して新しいサブフローを開始できます。接続内のいずれかのホストが新しいサブフローの作成を開始することは許可されていますが、これは通常、元の接続イニシエーターであることが予想されます（ヒューリスティックについては、セクション3.8を参照）。
A new subflow is started as a normal TCP SYN/ACK exchange. The Join Connection (MP_JOIN) TCP option is used to identify the connection to be joined by the new subflow. It uses keying material that was exchanged in the initial MP_CAPABLE handshake (Section 3.1), and that handshake also negotiates the crypto algorithm in use for the MP_JOIN handshake.
新しいサブフローは、通常のTCP SYN / ACK交換として開始されます。接続の結合（MP_JOIN）TCPオプションは、新しいサブフローによって結合される接続を識別するために使用されます。最初のMP_CAPABLEハンドシェイク（セクション3.1）で交換されたキー生成情報を使用し、そのハンドシェイクはMP_JOINハンドシェイクに使用されている暗号アルゴリズムもネゴシエートします。
This section specifies the behavior of MP_JOIN using the HMAC-SHA1 algorithm. An MP_JOIN option is present in the SYN, SYN/ACK, and ACK of the three-way handshake, although in each case with a different format.
このセクションでは、HMAC-SHA1アルゴリズムを使用したMP_JOINの動作を指定します。 MP_JOINオプションは、スリーウェイハンドシェイクのSYN、SYN / ACK、およびACKにありますが、いずれの場合もフォーマットは異なります。
In the first MP_JOIN on the SYN packet, illustrated in Figure 5, the initiator sends a token, random number, and address ID.
図5に示すように、SYNパケットの最初のMP_JOINでは、イニシエーターがトークン、乱数、およびアドレスIDを送信します。
The token is used to identify the MPTCP connection and is a cryptographic hash of the receiver's key, as exchanged in the initial MP_CAPABLE handshake (Section 3.1). In this specification, the tokens presented in this option are generated by the SHA-1 ([4], [15]) algorithm, truncated to the most significant 32 bits. The token included in the MP_JOIN option is the token that the receiver of the packet uses to identify this connection; i.e., Host A will send Token-B (which is generated from Key-B). Note that the hash generation algorithm can be overridden by the choice of cryptographic handshake algorithm, as defined in Section 3.1.
トークンはMPTCP接続を識別するために使用され、最初のMP_CAPABLEハンドシェイク（セクション3.1）で交換されるように、受信者のキーの暗号化ハッシュです。この仕様では、このオプションで提示されるトークンは、SHA-1（[4]、[15]）アルゴリズムによって生成され、最上位の32ビットに切り捨てられます。 MP_JOINオプションに含まれるトークンは、パケットの受信者がこの接続を識別するために使用するトークンです。つまり、ホストAはトークンB（Key-Bから生成）を送信します。ハッシュ生成アルゴリズムは、セクション3.1で定義されているように、暗号化ハンドシェイクアルゴリズムを選択することでオーバーライドできることに注意してください。
The MP_JOIN SYN sends not only the token (which is static for a connection) but also random numbers (nonces) that are used to prevent replay attacks on the authentication method. Recommendations for the generation of random numbers for this purpose are given in [14].
MP_JOIN SYNは、トークン（接続では静的）だけでなく、認証方法へのリプレイアタックを防ぐために使用される乱数（ナンス）も送信します。この目的で乱数を生成するための推奨事項は、[14]に記載されています。
The MP_JOIN option includes an "Address ID". This is an identifier that only has significance within a single connection, where it identifies the source address of this packet, even if the IP header has been changed in transit by a middlebox. The Address ID allows address removal (Section 3.4.2) without needing to know what the source address at the receiver is, thus allowing address removal through NATs. The Address ID also allows correlation between new subflow setup attempts and address signaling (Section 3.4.1), to prevent setting up duplicate subflows on the same path, if an MP_JOIN and ADD_ADDR are sent at the same time.
MP_JOINオプションには、「アドレスID」が含まれています。これは、単一の接続内でのみ意味を持つ識別子で、ミドルボックスによって転送中にIPヘッダーが変更された場合でも、このパケットの送信元アドレスを識別します。アドレスIDを使用すると、受信側の送信元アドレスが何であるかを知る必要なくアドレスを削除でき（セクション3.4.2）、NATを介してアドレスを削除できます。また、MP_JOINとADD_ADDRが同時に送信された場合に、アドレスIDを使用して、新しいサブフローのセットアップ試行とアドレスシグナリング（セクション3.4.1）を関連付け、同じパスに重複するサブフローをセットアップしないようにすることができます。
The Address IDs of the subflow used in the initial SYN exchange of the first subflow in the connection are implicit, and have the value zero. A host MUST store the mappings between Address IDs and addresses both for itself and the remote host. An implementation will also need to know which local and remote Address IDs are associated with which established subflows, for when addresses are removed from a local or remote host.
接続の最初のサブフローの最初のSYN交換で使用されるサブフローのアドレスIDは暗黙的であり、値はゼロです。ホストは、自身とリモートホストの両方のアドレスIDとアドレスの間のマッピングを保存する必要があります。ローカルまたはリモートのホストからアドレスが削除された場合、実装では、確立されたサブフローに関連付けられているローカルおよびリモートのアドレスIDを知る必要もあります。
The MP_JOIN option on packets with the SYN flag set also includes 4 bits of flags, 3 of which are currently reserved and MUST be set to zero by the sender. The final bit, labeled "B", indicates whether the sender of this option wishes this subflow to be used as a backup path (B=1) in the event of failure of other paths, or whether it wants it to be used as part of the connection immediately. By setting B=1, the sender of the option is requesting the other host to only send data on this subflow if there are no available subflows where B=0. Subflow policy is discussed in more detail in Section 3.3.8.
SYNフラグが設定されたパケットのMP_JOINオプションには、4ビットのフラグも含まれます。そのうちの3つは現在予約されており、送信者がゼロに設定する必要があります。 「B」というラベルが付いた最後のビットは、このオプションの送信側が、他のパスで障害が発生した場合に、このサブフローをバックアップパス（B = 1）として使用することを希望するか、それとも一部として使用することを希望するかを示します。接続のすぐ。 B = 1を設定することにより、オプションの送信者は、B = 0で使用可能なサブフローがない場合にのみ、このサブフローでデータを送信するように他のホストに要求します。サブフローポリシーについては、3.3.8項で詳しく説明します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----+-+---------------+
| Kind | Length = 12 |Subtype| |B| Address ID |
+---------------+---------------+-------+-----+-+---------------+
| Receiver's Token (32 bits) |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
Figure 5: Join Connection (MP_JOIN) Option (for Initial SYN)
図5：接続への参加（MP_JOIN）オプション（初期SYN用）
When receiving a SYN with an MP_JOIN option that contains a valid token for an existing MPTCP connection, the recipient SHOULD respond with a SYN/ACK also containing an MP_JOIN option containing a random number and a truncated (leftmost 64 bits) Hash-based Message Authentication Code (HMAC). This version of the option is shown in Figure 6. If the token is unknown, or the host wants to refuse subflow establishment (for example, due to a limit on the number of subflows it will permit), the receiver will send back a reset (RST) signal, analogous to an unknown port in TCP. Although calculating an HMAC requires cryptographic operations, it is believed that the 32- bit token in the MP_JOIN SYN gives sufficient protection against blind state exhaustion attacks; therefore, there is no need to provide mechanisms to allow a responder to operate statelessly at the MP_JOIN stage.
既存のMPTCP接続の有効なトークンを含むMP_JOINオプションを含むSYNを受信すると、受信者は、乱数と切り捨てられた（左端の64ビット）ハッシュベースのメッセージ認証を含むMP_JOINオプションを含むSYN / ACKで応答する必要があります（SHOULD）。コード（HMAC）。このバージョンのオプションを図6に示します。トークンが不明である場合、またはホストがサブフローの確立を拒否する場合（たとえば、許可するサブフローの数が制限されているため）、レシーバーはリセットを送り返します（RST）信号。TCPの不明なポートに似ています。 HMACの計算には暗号化操作が必要ですが、MP_JOIN SYNの32ビットトークンは、ブラインドステート枯渇攻撃に対する十分な保護を提供すると考えられています。したがって、レスポンダがMP_JOINステージでステートレスに動作できるようにするメカニズムを提供する必要はありません。
An HMAC is sent by both hosts -- by the initiator (Host A) in the third packet (the ACK) and by the responder (Host B) in the second packet (the SYN/ACK). Doing the HMAC exchange at this stage allows both hosts to have first exchanged random data (in the first two SYN packets) that is used as the "message". This specification defines that HMAC as defined in [10] is used, along with the SHA-1 hash algorithm [4] (potentially implemented as in [15]), thus generating a 160-bit / 20-octet HMAC. Due to option space limitations, the HMAC included in the SYN/ACK is truncated to the leftmost 64 bits, but this is acceptable since random numbers are used; thus, an attacker only has one chance to guess the HMAC correctly (if the HMAC is incorrect, the TCP connection is closed, so a new MP_JOIN negotiation with a new random number is required).
HMACは両方のホストから送信されます。3番目のパケット（ACK）でイニシエーター（ホストA）が送信し、2番目のパケット（SYN / ACK）でレスポンダー（ホストB）が送信します。この段階でHMAC交換を行うと、両方のホストが最初にランダムなデータを（最初の2つのSYNパケットで）交換し、「メッセージ」として使用されます。この仕様では、[10]で定義されているHMACがSHA-1ハッシュアルゴリズム[4]（[15]のように実装される可能性がある）とともに使用され、160ビット/ 20オクテットHMACが生成されることが定義されています。オプションのスペース制限により、SYN / ACKに含まれるHMACは左端の64ビットに切り捨てられますが、乱数が使用されるため、これは許容されます。したがって、攻撃者がHMACを正しく推測できるのは1回だけです（HMACが正しくない場合、TCP接続が閉じられるため、新しい乱数を使用した新しいMP_JOINネゴシエーションが必要です）。
The initiator's authentication information is sent in its first ACK (the third packet of the handshake), as shown in Figure 7. This data needs to be sent reliably, since it is the only time this HMAC is sent; therefore, receipt of this packet MUST trigger a regular TCP ACK in response, and the packet MUST be retransmitted if this ACK is not received. In other words, sending the ACK/MP_JOIN packet places the subflow in the PRE_ESTABLISHED state, and it moves to the ESTABLISHED state only on receipt of an ACK from the receiver. It is not permitted to send data while in the PRE_ESTABLISHED state. The reserved bits in this option MUST be set to zero by the sender.
イニシエーターの認証情報は、図7に示すように、最初のACK（ハンドシェイクの3番目のパケット）で送信されます。このHMACが送信されるのはこのデータだけなので、このデータは確実に送信される必要があります。したがって、このパケットの受信は応答として通常のTCP ACKをトリガーする必要があり、このACKが受信されない場合はパケットを再送信する必要があります。つまり、ACK / MP_JOINパケットを送信すると、サブフローがPRE_ESTABLISHED状態になり、受信側からのACKを受信したときにのみESTABLISHED状態に移行します。 PRE_ESTABLISHED状態のときにデータを送信することはできません。このオプションの予約済みビットは、送信者がゼロに設定する必要があります。
The key for the HMAC algorithm, in the case of the message transmitted by Host A, will be Key-A followed by Key-B, and in the case of Host B, Key-B followed by Key-A. These are the keys that were exchanged in the original MP_CAPABLE handshake. The "message" for the HMAC algorithm in each case is the concatenations of random number for each host (denoted by R): for Host A, R-A followed by R-B; and for Host B, R-B followed by R-A.
HMACアルゴリズムのキーは、ホストAから送信されたメッセージの場合、Key-Aの後にKey-Bが続き、ホストBの場合はKey-Bの後にKey-Aが続きます。これらは、元のMP_CAPABLEハンドシェイクで交換されたキーです。それぞれの場合のHMACアルゴリズムの「メッセージ」は、各ホストの乱数（Rで示される）の連結です。ホストAの場合、R-Aの後にR-Bが続きます。ホストBの場合、R-Bの後にR-Aが続きます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----+-+---------------+
| Kind | Length = 16 |Subtype| |B| Address ID |
+---------------+---------------+-------+-----+-+---------------+
| |
| Sender's Truncated HMAC (64 bits) |
| |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
Figure 6: Join Connection (MP_JOIN) Option (for Responding SYN/ACK)
図6：接続への参加（MP_JOIN）オプション（応答SYN / ACK用）
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----------------------+
| Kind | Length = 24 |Subtype| (reserved) |
+---------------+---------------+-------+-----------------------+
| |
| |
| Sender's HMAC (160 bits) |
| |
| |
+---------------------------------------------------------------+
Figure 7: Join Connection (MP_JOIN) Option (for Third ACK)
図7：接続への参加（MP_JOIN）オプション（3番目のACK用）
These various TCP options fit together to enable authenticated subflow setup as illustrated in Figure 8.
図8に示すように、これらのさまざまなTCPオプションを組み合わせて、認証済みサブフローのセットアップを有効にします。
Host A Host B
------------------------ ----------
Address A1 Address A2 Address B1
---------- ---------- ----------
| | |
| SYN + MP_CAPABLE(Key-A) |
|--------------------------------------------->|
|<---------------------------------------------|
| SYN/ACK + MP_CAPABLE(Key-B) |
| | |
| ACK + MP_CAPABLE(Key-A, Key-B) |
|--------------------------------------------->|
| | |
| | SYN + MP_JOIN(Token-B, R-A) |
| |------------------------------->|
| |<-------------------------------|
| | SYN/ACK + MP_JOIN(HMAC-B, R-B) |
| | |
| | ACK + MP_JOIN(HMAC-A) |
| |------------------------------->|
| |<-------------------------------|
| | ACK |
HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(R-A+R-B))
HMAC-B = HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A))
Figure 8: Example Use of MPTCP Authentication
図8：MPTCP認証の使用例
If the token received at Host B is unknown or local policy prohibits the acceptance of the new subflow, the recipient MUST respond with a TCP RST for the subflow.
ホストBで受信したトークンが不明であるか、ローカルポリシーが新しいサブフローの受け入れを禁止している場合、受信者はサブフローのTCP RSTで応答する必要があります。
If the token is accepted at Host B, but the HMAC returned to Host A does not match the one expected, Host A MUST close the subflow with a TCP RST.
トークンがホストBで受け入れられたが、ホストAに返されたHMACが予期されたものと一致しない場合、ホストAはTCP RSTでサブフローを閉じる必要があります。
If Host B does not receive the expected HMAC, or the MP_JOIN option is missing from the ACK, it MUST close the subflow with a TCP RST.
ホストBが期待されるHMACを受信しない場合、またはACKからMP_JOINオプションが欠落している場合、TCP RSTでサブフローを閉じる必要があります。
If the HMACs are verified as correct, then both hosts have authenticated each other as being the same peers as existed at the start of the connection, and they have agreed of which connection this subflow will become a part.
HMACが正しいことが検証された場合、両方のホストは、接続の開始時に存在していたものと同じピアであることを相互に認証し、このサブフローがどの接続になるかについて合意しました。
If the SYN/ACK as received at Host A does not have an MP_JOIN option, Host A MUST close the subflow with a RST.
ホストAで受信したSYN / ACKにMP_JOINオプションがない場合、ホストAはRSTでサブフローを閉じる必要があります。
This covers all cases of the loss of an MP_JOIN. In more detail, if MP_JOIN is stripped from the SYN on the path from A to B, and Host B does not have a passive opener on the relevant port, it will respond with a RST in the normal way. If in response to a SYN with an MP_JOIN option, a SYN/ACK is received without the MP_JOIN option (either since it was stripped on the return path, or it was stripped on the outgoing path but the passive opener on Host B responded as if it were a new regular TCP session), then the subflow is unusable and Host A MUST close it with a RST.
これは、MP_JOINの損失のすべてのケースをカバーします。より詳細には、MP_JOINがAからBへのパス上のSYNから取り除かれ、ホストBが関連するポートにパッシブオープナーを持っていない場合、通常の方法でRSTで応答します。 MP_JOINオプション付きのSYNに応答して、SYN / ACKがMP_JOINオプションなしで受信された場合（リターンパスで削除されたか、発信パスで削除されたが、ホストBのパッシブオープナーが応答したかのように応答した場合）それは新しい通常のTCPセッションでした）、サブフローは使用できず、ホストAはRSTでサブフローを閉じる必要があります。
Note that additional subflows can be created between any pair of ports (but see Section 3.8 for heuristics); no explicit application-level accept calls or bind calls are required to open additional subflows. To associate a new subflow with an existing connection, the token supplied in the subflow's SYN exchange is used for demultiplexing. This then binds the 5-tuple of the TCP subflow to the local token of the connection. A consequence is that it is possible to allow any port pairs to be used for a connection.
追加のサブフローを任意のポートのペア間に作成できることに注意してください（ただし、ヒューリスティックについてはセクション3.8を参照してください）。追加のサブフローを開くために、明示的なアプリケーションレベルの受け入れ呼び出しまたはバインド呼び出しは必要ありません。新しいサブフローを既存の接続に関連付けるには、サブフローのSYN交換で提供されるトークンを逆多重化に使用します。次に、TCPサブフローの5タプルを接続のローカルトークンにバインドします。結果として、任意のポートペアを接続に使用できるようになります。
Demultiplexing subflow SYNs MUST be done using the token; this is unlike traditional TCP, where the destination port is used for demultiplexing SYN packets. Once a subflow is set up, demultiplexing packets is done using the 5-tuple, as in traditional TCP. The 5-tuples will be mapped to the local connection identifier (token). Note that Host A will know its local token for the subflow even though it is not sent on the wire -- only the responder's token is sent.
サブフローSYNの逆多重化は、トークンを使用して実行する必要があります。これは、宛先ポートがSYNパケットの逆多重化に使用される従来のTCPとは異なります。サブフローがセットアップされると、従来のTCPと同様に、パケットの逆多重化は5タプルを使用して行われます。 5タプルはローカル接続識別子（トークン）にマップされます。ホストAは、それがネットワーク上で送信されなくても、サブフローのローカルトークンを知っていることに注意してください。レスポンダのトークンのみが送信されます。
This section discusses operation of MPTCP for data transfer. At a high level, an MPTCP implementation will take one input data stream from an application, and split it into one or more subflows, with sufficient control information to allow it to be reassembled and delivered reliably and in order to the recipient application. The following subsections define this behavior in detail.
このセクションでは、データ転送のためのMPTCPの操作について説明します。高レベルでは、MPTCP実装は、アプリケーションから1つの入力データストリームを受け取り、それを1つ以上のサブフローに分割します。十分な制御情報を使用して、再組み立てし、受信側アプリケーションに確実に配信できるようにします。以下のサブセクションでは、この動作を詳細に定義しています。
The data sequence mapping and the Data ACK are signaled in the Data Sequence Signal (DSS) option (Figure 9). Either or both can be signaled in one DSS, dependent on the flags set. The data sequence mapping defines how the sequence space on the subflow maps to the connection level, and the Data ACK acknowledges receipt of data at the connection level. These functions are described in more detail in the following two subsections.
データシーケンスマッピングとデータACKは、データシーケンス信号（DSS）オプションで通知されます（図9）。フラグセットに応じて、どちらかまたは両方を1つのDSSで通知できます。データシーケンスマッピングは、サブフローのシーケンススペースを接続レベルにマップする方法を定義し、データACKは接続レベルでのデータの受信を確認します。これらの機能については、次の2つのサブセクションで詳しく説明します。
Either or both the data sequence mapping and the Data ACK can be signaled in the DSS option, dependent on the flags set.
フラグセットに応じて、データシーケンスマッピングとデータACKのどちらかまたは両方をDSSオプションで通知できます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+----------------------+
| Kind | Length |Subtype| (reserved) |F|m|M|a|A|
+---------------+---------------+-------+----------------------+
| Data ACK (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| Data sequence number (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| Subflow Sequence Number (4 octets) |
+-------------------------------+------------------------------+
| Data-Level Length (2 octets) | Checksum (2 octets) |
+-------------------------------+------------------------------+
Figure 9: Data Sequence Signal (DSS) Option
図9：データシーケンス信号（DSS）オプション
The flags, when set, define the contents of this option, as follows:
フラグを設定すると、このオプションの内容が次のように定義されます。
o A = Data ACK present
o A =データACKが存在する
o a = Data ACK is 8 octets (if not set, Data ACK is 4 octets)
o a =データACKは8オクテット（設定されていない場合、データACKは4オクテット）
o M = Data Sequence Number (DSN), Subflow Sequence Number (SSN), Data-Level Length, and Checksum present
o M =データシーケンス番号（DSN）、サブフローシーケンス番号（SSN）、データレベルの長さ、チェックサムの存在
o m = Data sequence number is 8 octets (if not set, DSN is 4 octets)
o m =データシーケンス番号は8オクテット（設定されていない場合、DSNは4オクテット）
The flags 'a' and 'm' only have meaning if the corresponding 'A' or 'M' flags are set; otherwise, they will be ignored. The maximum length of this option, with all flags set, is 28 octets.
フラグ「a」と「m」は、対応する「A」または「M」フラグが設定されている場合にのみ意味があります。それ以外の場合は無視されます。このオプションの最大長は、すべてのフラグが設定された状態で、28オクテットです。
The 'F' flag indicates "DATA_FIN". If present, this means that this mapping covers the final data from the sender. This is the connection-level equivalent to the FIN flag in single-path TCP. A connection is not closed unless there has been a DATA_FIN exchange or a timeout. The purpose of the DATA_FIN and the interactions between this flag, the subflow-level FIN flag, and the data sequence mapping are described in Section 3.3.3. The remaining reserved bits MUST be set to zero by an implementation of this specification.
「F」フラグは「DATA_FIN」を示します。存在する場合、これは、このマッピングが送信者からの最終データをカバーすることを意味します。これは、シングルパスTCPのFINフラグに相当する接続レベルです。 DATA_FIN交換またはタイムアウトがない限り、接続は閉じられません。 DATA_FINの目的と、このフラグ、サブフローレベルのFINフラグ、およびデータシーケンスマッピング間の相互作用については、セクション3.3.3で説明します。残りの予約済みビットは、この仕様の実装によってゼロに設定する必要があります。
Note that the checksum is only present in this option if the use of MPTCP checksumming has been negotiated at the MP_CAPABLE handshake (see Section 3.1). The presence of the checksum can be inferred from the length of the option. If a checksum is present, but its use had not been negotiated in the MP_CAPABLE handshake, the checksum field MUST be ignored. If a checksum is not present when its use has been negotiated, the receiver MUST close the subflow with a RST as it is considered broken.
チェックサムは、MPTCPチェックサムの使用がMP_CAPABLEハンドシェイクでネゴシエートされている場合にのみ、このオプションに存在することに注意してください（セクション3.1を参照）。チェックサムの存在は、オプションの長さから推測できます。チェックサムは存在するが、その使用がMP_CAPABLEハンドシェイクでネゴシエートされていなかった場合、チェックサムフィールドは無視されなければなりません（MUST）。使用がネゴシエートされたときにチェックサムが存在しない場合、壊れていると見なされるため、受信者はRSTでサブフローを閉じる必要があります。
The data stream as a whole can be reassembled through the use of the data sequence mapping components of the DSS option (Figure 9), which define the mapping from the subflow sequence number to the data sequence number. This is used by the receiver to ensure in-order delivery to the application layer. Meanwhile, the subflow-level sequence numbers (i.e., the regular sequence numbers in the TCP header) have subflow-only relevance. It is expected (but not mandated) that SACK [11] is used at the subflow level to improve efficiency.
データストリームは、サブフローシーケンス番号からデータシーケンス番号へのマッピングを定義するDSSオプションのデータシーケンスマッピングコンポーネント（図9）を使用して、全体として再構成できます。これは、アプリケーション層への順序どおりの配信を保証するために受信者によって使用されます。一方、サブフローレベルのシーケンス番号（つまり、TCPヘッダーの通常のシーケンス番号）には、サブフローのみの関連性があります。効率を改善するためにサブフローレベルでSACK [11]が使用されることが期待されます（必須ではありません）。
The data sequence mapping specifies a mapping from subflow sequence space to data sequence space. This is expressed in terms of starting sequence numbers for the subflow and the data level, and a length of bytes for which this mapping is valid. This explicit mapping for a range of data was chosen rather than per-packet signaling to assist with compatibility with situations where TCP/IP segmentation or coalescing is undertaken separately from the stack that is generating the data flow (e.g., through the use of TCP segmentation offloading on network interface cards, or by middleboxes such as performance enhancing proxies). It also allows a single mapping to cover many packets, which may be useful in bulk transfer situations.
データシーケンスマッピングは、サブフローシーケンススペースからデータシーケンススペースへのマッピングを指定します。これは、サブフローとデータレベルの開始シーケンス番号、およびこのマッピングが有効なバイト長で表されます。データのフローを生成しているスタックとは別にTCP / IPセグメンテーションまたは合体が行われる状況との互換性を支援するために、パケットごとのシグナリングではなく、データの範囲に対するこの明示的なマッピングが選択されました（たとえば、TCPセグメンテーションの使用を通じて）ネットワークインターフェイスカードでのオフロード、またはパフォーマンス向上プロキシなどのミドルボックスによるオフロード）。また、単一のマッピングで多数のパケットをカバーできるため、バルク転送の状況で役立ちます。
A mapping is fixed, in that the subflow sequence number is bound to the data sequence number after the mapping has been processed. A sender MUST NOT change this mapping after it has been declared; however, the same data sequence number can be mapped to by different subflows for retransmission purposes (see Section 3.3.6). This would also permit the same data to be sent simultaneously on multiple subflows for resilience or efficiency purposes, especially in the case of lossy links. Although the detailed specification of such operation is outside the scope of this document, an implementation SHOULD treat the first data that is received at a subflow for the data sequence space as that which should be delivered to the application, and any later data for that sequence space ignored.
マッピングは固定されており、マッピングが処理された後、サブフローのシーケンス番号がデータのシーケンス番号にバインドされます。送信者は、宣言後にこのマッピングを変更してはなりません（MUST NOT）。ただし、同じデータシーケンス番号は、再送信のために異なるサブフローによってマッピングできます（セクション3.3.6を参照）。これは、特に損失の多いリンクの場合に、回復力または効率性の目的で、同じデータを複数のサブフローで同時に送信することもできます。そのような操作の詳細な仕様はこのドキュメントの範囲外ですが、実装では、データシーケンススペースのサブフローで受信される最初のデータを、アプリケーションに配信する必要があるものとして扱い、そのシーケンスのその後のデータを扱う必要があります（SHOULD）。スペースは無視されました。
The data sequence number is specified as an absolute value, whereas the subflow sequence numbering is relative (the SYN at the start of the subflow has relative subflow sequence number 0). This is to allow middleboxes to change the initial sequence number of a subflow, such as firewalls that undertake ISN randomization.
データシーケンス番号は絶対値として指定されますが、サブフローシーケンス番号は相対的です（サブフローの開始時のSYNには相対的なサブフローシーケンス番号0があります）。これは、ミドルボックスがISNランダム化を実行するファイアウォールなどのサブフローの初期シーケンス番号を変更できるようにするためです。
The data sequence mapping also contains a checksum of the data that this mapping covers, if use of checksums has been negotiated at the MP_CAPABLE exchange. Checksums are used to detect if the payload has been adjusted in any way by a non-MPTCP-aware middlebox. If this checksum fails, it will trigger a failure of the subflow, or a fallback to regular TCP, as documented in Section 3.6, since MPTCP can no longer reliably know the subflow sequence space at the receiver to build data sequence mappings.
チェックサムの使用がMP_CAPABLE交換でネゴシエートされている場合、データシーケンスマッピングには、このマッピングがカバーするデータのチェックサムも含まれます。チェックサムは、ペイロードが非MPTCP対応のミドルボックスによって何らかの方法で調整されたかどうかを検出するために使用されます。このチェックサムが失敗すると、セクション3.6に記載されているように、サブフローの失敗、または通常のTCPへのフォールバックがトリガーされます。これは、MPTCPがデータシーケンスマッピングを構築するためにレシーバーでサブフローシーケンススペースを確実に認識できないためです。
The checksum algorithm used is the standard TCP checksum [1], operating over the data covered by this mapping, along with a pseudo-header as shown in Figure 10.
使用されるチェックサムアルゴリズムは、標準のTCPチェックサム[1]であり、このマッピングの対象となるデータと、図10に示すような疑似ヘッダーを操作します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+--------------------------------------------------------------+
| |
| Data Sequence Number (8 octets) |
| |
+--------------------------------------------------------------+
| Subflow Sequence Number (4 octets) |
+-------------------------------+------------------------------+
| Data-Level Length (2 octets) | Zeros (2 octets) |
+-------------------------------+------------------------------+
Figure 10: Pseudo-Header for DSS Checksum
図10：DSSチェックサムの疑似ヘッダー
Note that the data sequence number used in the pseudo-header is always the 64-bit value, irrespective of what length is used in the DSS option itself. The standard TCP checksum algorithm has been chosen since it will be calculated anyway for the TCP subflow, and if calculated first over the data before adding the pseudo-headers, it only needs to be calculated once. Furthermore, since the TCP checksum is additive, the checksum for a DSN_MAP can be constructed by simply adding together the checksums for the data of each constituent TCP segment, and adding the checksum for the DSS pseudo-header.
疑似ヘッダーで使用されるデータシーケンス番号は、DSSオプション自体で使用される長さに関係なく、常に64ビット値であることに注意してください。標準のTCPチェックサムアルゴリズムは、TCPサブフローに対してとにかく計算されるため選択されました。疑似ヘッダーを追加する前にデータに対して最初に計算される場合は、一度だけ計算する必要があります。さらに、TCPチェックサムは付加的であるため、DSN_MAPのチェックサムは、構成する各TCPセグメントのデータのチェックサムを加算し、DSS疑似ヘッダーのチェックサムを追加するだけで作成できます。
Note that checksumming relies on the TCP subflow containing contiguous data; therefore, a TCP subflow MUST NOT use the Urgent Pointer to interrupt an existing mapping. Further note, however, that if Urgent data is received on a subflow, it SHOULD be mapped to the data sequence space and delivered to the application analogous to Urgent data in regular TCP.
チェックサムは、連続したデータを含むTCPサブフローに依存していることに注意してください。したがって、TCPサブフローは、既存のマッピングを中断するために緊急ポインターを使用してはなりません（MUST NOT）。ただし、サブフローで緊急データを受信した場合は、データシーケンススペースにマップして、通常のTCPの緊急データに類似したアプリケーションに配信する必要があることに注意してください。
To avoid possible deadlock scenarios, subflow-level processing should be undertaken separately from that at connection level. Therefore, even if a mapping does not exist from the subflow space to the data-level space, the data SHOULD still be ACKed at the subflow (if it is in-window). This data cannot, however, be acknowledged at the data level (Section 3.3.2) because its data sequence numbers are unknown. Implementations MAY hold onto such unmapped data for a short while in the expectation that a mapping will arrive shortly. Such unmapped data cannot be counted as being within the connection level receive window because this is relative to the data sequence numbers, so if the receiver runs out of memory to hold this data, it will have to be discarded. If a mapping for that subflow-level sequence space does not arrive within a receive window of data, that subflow SHOULD be treated as broken, closed with a RST, and any unmapped data silently discarded.
考えられるデッドロックシナリオを回避するには、サブフローレベルの処理を、接続レベルの処理とは別に行う必要があります。したがって、サブフロースペースからデータレベルスペースへのマッピングが存在しない場合でも、データはサブフローで引き続き確認する必要があります（ウィンドウ内にある場合）。ただし、このデータは、データシーケンス番号が不明であるため、データレベル（セクション3.3.2）では確認できません。実装は、マッピングが間もなく到着することを期待している間、そのようなマッピングされていないデータをしばらく保持する場合があります。このようなマップされていないデータは、データシーケンス番号に関連しているため、接続レベルの受信ウィンドウ内にあるものとしてカウントできません。このため、レシーバーがこのデータを保持するためのメモリを使い果たした場合、破棄する必要があります。そのサブフローレベルのシーケンススペースのマッピングがデータの受信ウィンドウ内に到着しない場合、そのサブフローは壊れたものとして扱われ、RSTで閉じられ、マッピングされていないデータはサイレントに破棄される必要があります（SHOULD）。
Data sequence numbers are always 64-bit quantities, and MUST be maintained as such in implementations. If a connection is progressing at a slow rate, so protection against wrapped sequence numbers is not required, then it is permissible to include just the lower 32 bits of the data sequence number in the data sequence mapping and/or Data ACK as an optimization, and an implementation can make this choice independently for each packet.
データシーケンス番号は常に64ビットの数量であり、実装ではそのように維持する必要があります。接続が遅い速度で進行しているため、ラップされたシーケンス番号に対する保護が不要な場合は、データシーケンスマッピングにデータシーケンス番号の下位32ビットだけを含めるか、最適化としてデータACKを含めることが許可されます。実装では、この選択をパケットごとに個別に行うことができます。
An implementation MUST send the full 64-bit data sequence number if it is transmitting at a sufficiently high rate that the 32-bit value could wrap within the Maximum Segment Lifetime (MSL) [16]. The lengths of the DSNs used in these values (which may be different) are declared with flags in the DSS option. Implementations MUST accept a 32-bit DSN and implicitly promote it to a 64-bit quantity by incrementing the upper 32 bits of sequence number each time the lower 32 bits wrap. A sanity check MUST be implemented to ensure that a wrap occurs at an expected time (e.g., the sequence number jumps from a very high number to a very low number) and is not triggered by out-of-order packets.
32ビット値が最大セグメント寿命（MSL）[16]内でラップできる十分に高いレートで送信している場合、実装は完全な64ビットデータシーケンス番号を送信する必要があります。これらの値で使用されるDSNの長さ（異なる場合があります）は、DSSオプションのフラグで宣言されます。実装は32ビットDSNを受け入れ、下位32ビットがラップするたびにシーケンス番号の上位32ビットをインクリメントすることにより、暗黙的に64ビット数量に昇格させる必要があります。正常性チェックを実装して、予期した時間にラップが発生し（シーケンス番号が非常に高い番号から非常に低い番号にジャンプするなど）、順序が正しくないパケットによってトリガーされないようにする必要があります。
As with the standard TCP sequence number, the data sequence number should not start at zero, but at a random value to make blind session hijacking harder. This specification requires setting the initial data sequence number (IDSN) of each host to the least significant 64 bits of the SHA-1 hash of the host's key, as described in Section 3.1.
標準のTCPシーケンス番号と同様に、データシーケンス番号はゼロではなくランダムな値で開始して、ブラインドセッションのハイジャックを困難にする必要があります。この仕様では、セクション3.1で説明されているように、各ホストの初期データシーケンス番号（IDSN）をホストのキーのSHA-1ハッシュの最下位64ビットに設定する必要があります。
A data sequence mapping does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver. This can be used to reduce overhead in cases where the mapping is known in advance; one such case is when there is a single subflow between the hosts, another is when segments of data are scheduled in larger than packet-sized chunks.
パケットのサブフローシーケンススペースが受信側で既知のマッピングによってカバーされている限り、データシーケンスマッピングをすべてのMPTCPパケットに含める必要はありません。これは、マッピングが事前にわかっている場合にオーバーヘッドを削減するために使用できます。そのようなケースの1つは、ホスト間に単一のサブフローがある場合、別のケースは、データのセグメントがパケットサイズのチャンクよりも大きいサイズでスケジュールされている場合です。
An "infinite" mapping can be used to fall back to regular TCP by mapping the subflow-level data to the connection-level data for the remainder of the connection (see Section 3.6). This is achieved by setting the Data-Level Length field of the DSS option to the reserved value of 0. The checksum, in such a case, will also be set to zero.
「無限」マッピングを使用して、サブフローレベルのデータを接続の残りの接続レベルのデータにマッピングすることにより、通常のTCPにフォールバックできます（セクション3.6を参照）。これは、DSSオプションのData-Level Lengthフィールドを予約済みの値0に設定することによって実現されます。このような場合、チェックサムもゼロに設定されます。
To provide full end-to-end resilience, MPTCP provides a connection-level acknowledgment, to act as a cumulative ACK for the connection as a whole. This is the "Data ACK" field of the DSS option (Figure 9). The Data ACK is analogous to the behavior of the standard TCP cumulative ACK -- indicating how much data has been successfully received (with no holes). This is in comparison to the subflow-level ACK, which acts analogous to TCP SACK, given that there may still be holes in the data stream at the connection level. The Data ACK specifies the next data sequence number it expects to receive.
エンドツーエンドの完全な復元力を提供するために、MPTCPは接続レベルの確認応答を提供し、接続全体の累積ACKとして機能します。これは、DSSオプションの「データACK」フィールドです（図9）。データACKは、標準のTCP累積ACKの動作に似ています-正常に受信されたデータ（ホールなし）の量を示します。これは、接続レベルのデータストリームにまだホールが存在する可能性がある場合、TCP SACKと同様に機能するサブフローレベルのACKと比較されます。データACKは、受信する予定の次のデータシーケンス番号を指定します。
The Data ACK, as for the DSN, can be sent as the full 64-bit value, or as the lower 32 bits. If data is received with a 64-bit DSN, it MUST be acknowledged with a 64-bit Data ACK. If the DSN received is 32 bits, it is valid for the implementation to choose whether to send a 32-bit or 64-bit Data ACK.
DSNと同様に、データACKは、完全な64ビット値として、または下位32ビットとして送信できます。データが64ビットDSNで受信された場合、64ビットデータACKで確認する必要があります。受信したDSNが32ビットの場合、実装が32ビットと64ビットのどちらのデータACKを送信するかを選択することは有効です。
The Data ACK proves that the data, and all required MPTCP signaling, has been received and accepted by the remote end. One key use of the Data ACK signal is that it is used to indicate the left edge of the advertised receive window. As explained in Section 3.3.4, the receive window is shared by all subflows and is relative to the Data ACK. Because of this, an implementation MUST NOT use the RCV.WND field of a TCP segment at the connection level if it does not also carry a DSS option with a Data ACK field. Furthermore, separating the connection-level acknowledgments from the subflow level allows processing to be done separately, and a receiver has the freedom to drop segments after acknowledgment at the subflow level, for example, due to memory constraints when many segments arrive out of order.
データACKは、データおよび必要なすべてのMPTCPシグナリングがリモートエンドで受信され、受け入れられたことを証明します。データACK信号の主な用途の1つは、アドバタイズされた受信ウィンドウの左端を示すために使用されることです。セクション3.3.4で説明したように、受信ウィンドウはすべてのサブフローで共有され、データACKに関連しています。このため、実装は、データACKフィールドを含むDSSオプションも伝送しない場合、接続レベルでTCPセグメントのRCV.WNDフィールドを使用してはなりません（MUST NOT）。さらに、接続レベルの確認応答をサブフローレベルから分離することで、処理を個別に行うことができ、レシーバーは、サブフローレベルでの確認応答後にセグメントを削除することができます。
An MPTCP sender MUST NOT free data from the send buffer until it has been acknowledged by both a Data ACK received on any subflow and at the subflow level by all subflows on which the data was sent. The former condition ensures liveness of the connection and the latter condition ensures liveness and self-consistence of a subflow when data needs to be retransmitted. Note, however, that if some data needs to be retransmitted multiple times over a subflow, there is a risk of blocking the sending window. In this case, the MPTCP sender can decide to terminate the subflow that is behaving badly by sending a RST.
MPTCP送信者は、任意のサブフローで受信されたデータACKと、データが送信されたすべてのサブフローによるサブフローレベルの両方で確認されるまで、送信バッファーからデータを解放してはなりません（MUST NOT）。前者の条件は接続の活性を保証し、後者の条件はデータを再送信する必要がある場合のサブフローの活性と自己整合性を保証します。ただし、サブフローを介して複数のデータを複数回再送信する必要がある場合、送信ウィンドウをブロックするリスクがあることに注意してください。この場合、MPTCP送信者は、RSTを送信することにより、動作が適切でないサブフローを終了することを決定できます。
The Data ACK MAY be included in all segments; however, optimizations SHOULD be considered in more advanced implementations, where the Data ACK is present in segments only when the Data ACK value advances, and this behavior MUST be treated as valid. This behavior ensures the sender buffer is freed, while reducing overhead when the data transfer is unidirectional.
データACKはすべてのセグメントに含まれる場合があります。ただし、最適化は、データACK値が進んだ場合にのみデータACKがセグメントに存在する、より高度な実装で検討する必要があります（SHOULD）。この動作は有効として扱う必要があります。この動作により、送信側バッファーが確実に解放され、データ転送が単方向である場合のオーバーヘッドが削減されます。
In regular TCP, a FIN announces the receiver that the sender has no more data to send. In order to allow subflows to operate independently and to keep the appearance of TCP over the wire, a FIN in MPTCP only affects the subflow on which it is sent. This allows nodes to exercise considerable freedom over which paths are in use at any one time. The semantics of a FIN remain as for regular TCP; i.e., it is not until both sides have ACKed each other's FINs that the subflow is fully closed.
通常のTCPでは、FINは送信側に送信するデータがないことを受信側に通知します。サブフローが独立して動作し、TCPの外観を回線上で維持できるようにするために、MPTCPのFINは、サブフローが送信されるサブフローにのみ影響します。これにより、ノードはいつでも使用中のパスに対してかなりの自由度を行使できます。 FINのセマンティクスは通常のTCPの場合と同じです。つまり、サブフローが完全に閉じられるのは、両側が互いのFINにACKするまでです。
When an application calls close() on a socket, this indicates that it has no more data to send; for regular TCP, this would result in a FIN on the connection. For MPTCP, an equivalent mechanism is needed, and this is referred to as the DATA_FIN.
アプリケーションがソケットでclose()を呼び出すと、これは送信するデータがなくなったことを示します。通常のTCPの場合、これにより接続でFINが発生します。 MPTCPの場合、同等のメカニズムが必要であり、これはDATA_FINと呼ばれます。
A DATA_FIN is an indication that the sender has no more data to send, and as such can be used to verify that all data has been successfully received. A DATA_FIN, as with the FIN on a regular TCP connection, is a unidirectional signal.
DATA_FINは、送信者に送信するデータがないことを示しているため、すべてのデータが正常に受信されたことを確認するために使用できます。 DATA_FINは、通常のTCP接続のFINと同様に、単方向信号です。
The DATA_FIN is signaled by setting the 'F' flag in the Data Sequence Signal option (Figure 9) to 1. A DATA_FIN occupies 1 octet (the final octet) of the connection-level sequence space. Note that the DATA_FIN is included in the Data-Level Length, but not at the subflow level: for example, a segment with DSN 80, and Data-Level Length 11, with DATA_FIN set, would map 10 octets from the subflow into data sequence space 80-89, the DATA_FIN is DSN 90; therefore, this segment including DATA_FIN would be acknowledged with a DATA_ACK of 91.
DATA_FINは、データシーケンス信号オプション（図9）の「F」フラグを1に設定することで通知されます。DATA_FINは、接続レベルのシーケンススペースの1オクテット（最後のオクテット）を占有します。 DATA_FINはデータレベルの長さに含まれていますが、サブフローレベルには含まれていません。たとえば、DSN 80のデータセグメントとDATA_FINが設定されたデータレベルの長さ11は、サブフローからデータシーケンスに10オクテットをマッピングします。スペース80〜89の場合、DATA_FINはDSN 90です。したがって、DATA_FINを含むこのセグメントは、91のDATA_ACKで確認されます。
Note that when the DATA_FIN is not attached to a TCP segment containing data, the Data Sequence Signal MUST have a subflow sequence number of 0, a Data-Level Length of 1, and the data sequence number that corresponds with the DATA_FIN itself. The checksum in this case will only cover the pseudo-header.
DATA_FINがデータを含むTCPセグメントに接続されていない場合、データシーケンス信号はサブフローシーケンス番号0、データレベル長1、およびDATA_FIN自体に対応するデータシーケンス番号を持つ必要があることに注意してください。この場合のチェックサムは、疑似ヘッダーのみを対象とします。
A DATA_FIN has the semantics and behavior as a regular TCP FIN, but at the connection level. Notably, it is only DATA_ACKed once all data has been successfully received at the connection level. Note, therefore, that a DATA_FIN is decoupled from a subflow FIN. It is only permissible to combine these signals on one subflow if there is no data outstanding on other subflows. Otherwise, it may be necessary to retransmit data on different subflows. Essentially, a host MUST NOT close all functioning subflows unless it is safe to do so, i.e., until all outstanding data has been DATA_ACKed, or until the segment with the DATA_FIN flag set is the only outstanding segment.
DATA_FINには、通常のTCP FINと同じセマンティクスと動作がありますが、接続レベルです。特に、接続レベルですべてのデータが正常に受信されると、DATA_ACKのみが返されます。したがって、DATA_FINはサブフローFINから切り離されていることに注意してください。他のサブフローで未処理のデータがない場合にのみ、これらの信号を1つのサブフローで組み合わせることが許可されます。そうでない場合は、異なるサブフローでデータを再送信する必要がある場合があります。基本的に、ホストは、安全である限り、つまり、すべての未処理のデータがDATA_ACKされるまで、またはDATA_FINフラグが設定されたセグメントが唯一の未処理のセグメントになるまで、機能しているすべてのサブフローを閉じてはなりません。
Once a DATA_FIN has been acknowledged, all remaining subflows MUST be closed with standard FIN exchanges. Both hosts SHOULD send FINs on all subflows, as a courtesy to allow middleboxes to clean up state even if an individual subflow has failed. It is also encouraged to reduce the timeouts (Maximum Segment Life) on subflows at end hosts. In particular, any subflows where there is still outstanding data queued (which has been retransmitted on other subflows in order to get the DATA_FIN acknowledged) MAY be closed with a RST.
DATA_FINが確認されたら、残りのすべてのサブフローを標準のFIN交換で閉じる必要があります。両方のホストは、個々のサブフローが失敗した場合でもミドルボックスが状態をクリーンアップできるように、すべてのサブフローでFINを送信する必要があります（SHOULD）。エンドホストでのサブフローのタイムアウト（最大セグメントライフ）を減らすこともお勧めします。特に、未処理のデータがキューに残っているサブフロー（DATA_FINを確認するために他のサブフローで再送信されたもの）は、RSTで閉じることができます。
A connection is considered closed once both hosts' DATA_FINs have been acknowledged by DATA_ACKs.
両方のホストのDATA_FINがDATA_ACKによって確認されると、接続は閉じられたと見なされます。
As specified above, a standard TCP FIN on an individual subflow only shuts down the subflow on which it was sent. If all subflows have been closed with a FIN exchange, but no DATA_FIN has been received and acknowledged, the MPTCP connection is treated as closed only after a timeout. This implies that an implementation will have TIME_WAIT states at both the subflow and connection levels (see Appendix C). This permits "break-before-make" scenarios where connectivity is lost on all subflows before a new one can be re-established.
上記のように、個々のサブフローの標準TCP FINは、それが送信されたサブフローのみをシャットダウンします。 FIN交換ですべてのサブフローが閉じられているが、DATA_FINが受信されて確認応答されていない場合、MPTCP接続はタイムアウト後にのみ閉じられたものとして扱われます。これは、実装がサブフローレベルと接続レベルの両方でTIME_WAIT状態になることを意味します（付録Cを参照）。これにより、「break-before-make」シナリオが可能になり、新しいサブフローを再確立する前にすべてのサブフローで接続が失われます。
Regular TCP advertises a receive window in each packet, telling the sender how much data the receiver is willing to accept past the cumulative ack. The receive window is used to implement flow control, throttling down fast senders when receivers cannot keep up.
通常のTCPは、各パケットの受信ウィンドウをアドバタイズし、受信者が累積ACKを超えて受け入れたいデータの量を送信者に通知します。受信ウィンドウはフロー制御を実装するために使用され、受信側が追いつけない場合に高速送信側を抑制します。
MPTCP also uses a unique receive window, shared between the subflows. The idea is to allow any subflow to send data as long as the receiver is willing to accept it. The alternative, maintaining per subflow receive windows, could end up stalling some subflows while others would not use up their window.
MPTCPは、サブフロー間で共有される一意の受信ウィンドウも使用します。アイデアは、受信側がそれを受け入れる用意がある限り、任意のサブフローがデータを送信できるようにすることです。別の方法として、サブフローごとの受信ウィンドウを維持すると、一部のサブフローが停止し、他のサブフローはウィンドウを使い果たしません。
The receive window is relative to the DATA_ACK. As in TCP, a receiver MUST NOT shrink the right edge of the receive window (i.e., DATA_ACK + receive window). The receiver will use the data sequence number to tell if a packet should be accepted at the connection level.
受信ウィンドウはDATA_ACKに関連しています。 TCPと同様に、受信側は受信ウィンドウの右端を縮小してはなりません（つまり、DATA_ACK +受信ウィンドウ）。受信側はデータシーケンス番号を使用して、接続レベルでパケットを受け入れるかどうかを通知します。
When deciding to accept packets at subflow level, regular TCP checks the sequence number in the packet against the allowed receive window. With multipath, such a check is done using only the connection-level window. A sanity check SHOULD be performed at subflow level to ensure that the subflow and mapped sequence numbers meet the following test: SSN - SUBFLOW_ACK <= DSN - DATA_ACK, where SSN is the subflow sequence number of the received packet and SUBFLOW_ACK is the RCV.NXT (next expected sequence number) of the subflow (with the equivalent connection-level definitions for DSN and DATA_ACK).
サブフローレベルでのパケットの受け入れを決定する場合、通常のTCPは、許可された受信ウィンドウに対してパケットのシーケンス番号をチェックします。マルチパスでは、このようなチェックは接続レベルのウィンドウのみを使用して行われます。サブフローレベルでサニティチェックを実行して、サブフローとマップされたシーケンス番号が次のテストを満たすことを確認する必要があります（SSN-SUBFLOW_ACK <= DSN-DATA_ACK、SSNは受信したパケットのサブフローシーケンス番号、SUBFLOW_ACKはRCV.NXT）サブフローの（次に予期されるシーケンス番号）（DSNおよびDATA_ACKの同等の接続レベル定義を使用）。
In regular TCP, once a segment is deemed in-window, it is put either in the in-order receive queue or in the out-of-order queue. In Multipath TCP, the same happens but at the connection level: a segment is placed in the connection level in-order or out-of-order queue if it is in-window at both connection and subflow levels. The stack still has to remember, for each subflow, which segments were received successfully so that it can ACK them at subflow level appropriately. Typically, this will be implemented by keeping per subflow out-of-order queues (containing only message headers, not the payloads) and remembering the value of the cumulative ACK.
通常のTCPでは、セグメントがウィンドウ内と見なされると、順序付き受信キューまたは順序外キューのいずれかに置かれます。マルチパスTCPでも同じことが発生しますが、接続レベルで行われます。接続レベルとサブフローレベルの両方でウィンドウ内にある場合、セグメントは接続レベルの順序どおりまたは順序外のキューに配置されます。スタックは、各サブフローについて、サブフローレベルで適切にACKできるように、正常に受信されたセグメントを覚えておく必要があります。通常、これは、サブフローごとに順不同キュー（ペイロードではなくメッセージヘッダーのみを含む）を保持し、累積ACKの値を記憶することで実装されます。
It is important for implementers to understand how large a receiver buffer is appropriate. The lower bound for full network utilization is the maximum bandwidth-delay product of any one of the paths. However, this might be insufficient when a packet is lost on a slower subflow and needs to be retransmitted (see Section 3.3.6). A tight upper bound would be the maximum round-trip time (RTT) of any path multiplied by the total bandwidth available across all paths. This permits all subflows to continue at full speed while a packet is fast-retransmitted on the maximum RTT path. Even this might be insufficient to maintain full performance in the event of a retransmit timeout on the maximum RTT path. It is for future study to determine the relationship between retransmission strategies and receive buffer sizing.
実装者にとって、レシーバーバッファーの適切な大きさを理解することが重要です。完全なネットワーク使用率の下限は、いずれかのパスの最大帯域幅遅延積です。ただし、遅いサブフローでパケットが失われ、再送信する必要がある場合は、これでは不十分な場合があります（セクション3.3.6を参照）。厳密な上限は、すべてのパスで利用可能な合計帯域幅を乗じたパスの最大往復時間（RTT）です。これにより、パケットが最大RTTパスで高速に再送信されている間、すべてのサブフローをフルスピードで続行できます。これでも、最大RTTパスで再送信タイムアウトが発生した場合に完全なパフォーマンスを維持するには不十分な場合があります。再送信戦略と受信バッファサイズの関係を決定することは、今後の研究のためです。
The sender remembers receiver window advertisements from the receiver. It should only update its local receive window values when the largest sequence number allowed (i.e., DATA_ACK + receive window) increases, on the receipt of a DATA_ACK. This is important to allow using paths with different RTTs, and thus different feedback loops.
送信者は、受信者からの受信者ウィンドウ広告を覚えています。 DATA_ACKの受信時に、許可されている最大のシーケンス番号（つまり、DATA_ACK +受信ウィンドウ）が増加した場合にのみ、ローカルの受信ウィンドウ値を更新する必要があります。これは、RTTが異なるパスを使用できるようにするために重要であり、したがってフィードバックループも異なります。
MPTCP uses a single receive window across all subflows, and if the receive window was guaranteed to be unchanged end-to-end, a host could always read the most recent receive window value. However, some classes of middleboxes may alter the TCP-level receive window. Typically, these will shrink the offered window, although for short periods of time it may be possible for the window to be larger (however, note that this would not continue for long periods since ultimately the middlebox must keep up with delivering data to the receiver). Therefore, if receive window sizes differ on multiple subflows, when sending data MPTCP SHOULD take the largest of the most recent window sizes as the one to use in calculations. This rule is implicit in the requirement not to reduce the right edge of the window.
MPTCPはすべてのサブフローで単一の受信ウィンドウを使用します。受信ウィンドウがエンドツーエンドで変更されないことが保証されている場合、ホストは常に最新の受信ウィンドウ値を読み取ることができます。ただし、ミドルボックスのクラスによっては、TCPレベルの受信ウィンドウが変更される場合があります。通常、これらは提供されるウィンドウを縮小しますが、短期間ではウィンドウが大きくなる可能性があります（ただし、最終的にミドルボックスはレシーバーへのデータの配信に追いつく必要があるため、これは長期間継続しないことに注意してください） ）。したがって、受信ウィンドウサイズが複数のサブフローで異なる場合、データを送信するときに、MPTCPは最新のウィンドウサイズの最大値を計算に使用するものとして使用する必要があります（SHOULD）。このルールは、ウィンドウの右端を縮小しないという要件に暗黙的に含まれています。
The sender MUST also remember the receive windows advertised by each subflow. The allowed window for subflow i is (ack_i, ack_i + rcv_wnd_i), where ack_i is the subflow-level cumulative ACK of subflow i. This ensures data will not be sent to a middlebox unless there is enough buffering for the data.
送信者は、各サブフローによってアドバタイズされた受信ウィンドウも記憶する必要があります。サブフローiに許可されるウィンドウは（ack_i、ack_i + rcv_wnd_i）です。ここで、ack_iはサブフローiのサブフローレベルの累積ACKです。これにより、データに十分なバッファリングがない限り、データがミドルボックスに送信されなくなります。
Putting the two rules together, we get the following: a sender is allowed to send data segments with data-level sequence numbers between (DATA_ACK, DATA_ACK + receive_window). Each of these segments will be mapped onto subflows, as long as subflow sequence numbers are in the allowed windows for those subflows. Note that subflow sequence numbers do not generally affect flow control if the same receive window is advertised across all subflows. They will perform flow control for those subflows with a smaller advertised receive window.
2つのルールをまとめると、次のようになります。送信者は、（DATA_ACK、DATA_ACK + receive_window）の間にデータレベルのシーケンス番号を持つデータセグメントを送信できます。これらの各セグメントは、サブフローのシーケンス番号がそれらのサブフローの許可されたウィンドウにある限り、サブフローにマップされます。すべてのサブフローにわたって同じ受信ウィンドウがアドバタイズされる場合、サブフローシーケンス番号は一般にフロー制御に影響しないことに注意してください。通知された受信ウィンドウが小さいサブフローに対してフロー制御を実行します。
The send buffer MUST, at a minimum, be as big as the receive buffer, to enable the sender to reach maximum throughput.
送信者が最大スループットに到達できるように、送信バッファは、少なくとも受信バッファと同じ大きさである必要があります。
The data sequence mapping allows senders to resend data with the same data sequence number on a different subflow. When doing this, a host MUST still retransmit the original data on the original subflow, in order to preserve the subflow integrity (middleboxes could replay old data, and/or could reject holes in subflows), and a receiver will ignore these retransmissions. While this is clearly suboptimal, for compatibility reasons this is sensible behavior. Optimizations could be negotiated in future versions of this protocol.
データシーケンスマッピングにより、送信者は同じデータシーケンス番号を持つデータを別のサブフローに再送信できます。これを行うとき、サブフローの整合性を維持するために、ホストは引き続き元のサブフローで元のデータを再送信する必要があります（ミドルボックスは古いデータを再生したり、サブフローのホールを拒否したりできます）。受信側はこれらの再送信を無視します。これは明らかに次善ですが、互換性の理由から、これは賢明な動作です。このプロトコルの将来のバージョンでは、最適化について交渉することができます。
This protocol specification does not mandate any mechanisms for handling retransmissions, and much will be dependent upon local policy (as discussed in Section 3.3.8). One can imagine aggressive connection-level retransmissions policies where every packet lost at subflow level is retransmitted on a different subflow (hence, wasting bandwidth but possibly reducing application-to-application delays), or conservative retransmission policies where connection-level retransmits are only used after a few subflow-level retransmission timeouts occur.
このプロトコル仕様は、再送信を処理するメカニズムを義務付けておらず、多くはローカルポリシーに依存します（セクション3.3.8で説明）。サブフローレベルで失われたすべてのパケットが別のサブフローで再送信される積極的な接続レベルの再送信ポリシー（したがって、帯域幅を浪費しますが、アプリケーション間の遅延を減らす可能性があります）、または接続レベルの再送信のみが使用される控えめな再送信ポリシーを想像できますいくつかのサブフローレベルの再送信タイムアウトが発生した後。
It is envisaged that a standard connection-level retransmission mechanism would be implemented around a connection-level data queue: all segments that haven't been DATA_ACKed are stored. A timer is set when the head of the connection-level is ACKed at subflow level but its corresponding data is not ACKed at data level. This timer will guard against failures in retransmission by middleboxes that proactively ACK data.
標準の接続レベルの再送信メカニズムが接続レベルのデータキューの周りに実装されることが想定されています。DATA_ACKされていないすべてのセグメントが格納されます。接続レベルの先頭がサブフローレベルでACKされるが、対応するデータがデータレベルでACKされない場合、タイマーが設定されます。このタイマーは、積極的にデータにACKを送信するミドルボックスによる再送信の失敗を防ぎます。
The sender MUST keep data in its send buffer as long as the data has not been acknowledged at both connection level and on all subflows on which it has been sent. In this way, the sender can always retransmit the data if needed, on the same subflow or on a different one. A special case is when a subflow fails: the sender will typically resend the data on other working subflows after a timeout, and will keep trying to retransmit the data on the failed subflow too. The sender will declare the subflow failed after a predefined upper bound on retransmissions is reached (which MAY be lower than the usual TCP limits of the Maximum Segment Life), or on the receipt of an ICMP error, and only then delete the outstanding data segments.
送信者は、接続レベルと送信されたすべてのサブフローの両方でデータが確認されない限り、送信バッファーにデータを保持する必要があります。このようにして、送信者は同じサブフローまたは別のサブフローで、必要に応じて常にデータを再送信できます。特殊なケースはサブフローが失敗した場合です。送信者は通常、タイムアウト後に他の動作中のサブフローでデータを再送信し、失敗したサブフローでもデータの再送信を試み続けます。送信者は、再送信の事前定義された上限に達した後（最大セグメント寿命の通常のTCP制限よりも低い場合があります）、またはICMPエラーの受信時にサブフローが失敗したと宣言し、未処理のデータセグメントのみを削除します。
Multiple retransmissions are triggers that will indicate that a subflow performs badly and could lead to a host resetting the subflow with a RST. However, additional research is required to understand the heuristics of how and when to reset underperforming subflows. For example, a highly asymmetric path may be misdiagnosed as underperforming.
複数の再送信は、サブフローのパフォーマンスが悪いことを示すトリガーであり、ホストがRSTでサブフローをリセットする可能性があります。ただし、パフォーマンスの低いサブフローをリセットする方法とタイミングのヒューリスティックを理解するには、追加の調査が必要です。たとえば、非対称性の高いパスは、パフォーマンスが低いと誤って診断されることがあります。
Different subflows in an MPTCP connection have different congestion windows. To achieve fairness at bottlenecks and resource pooling, it is necessary to couple the congestion windows in use on each subflow, in order to push most traffic to uncongested links. One algorithm for achieving this is presented in [5]; the algorithm does not achieve perfect resource pooling but is "safe" in that it is readily deployable in the current Internet. By this, we mean that it does not take up more capacity on any one path than if it was a single path flow using only that route, so this ensures fair coexistence with single-path TCP at shared bottlenecks.
MPTCP接続の異なるサブフローには、異なる輻輳ウィンドウがあります。ボトルネックとリソースプーリングで公平性を実現するには、ほとんどのトラフィックを輻輳していないリンクにプッシュするために、各サブフローで使用中の輻輳ウィンドウを結合する必要があります。これを達成するためのアルゴリズムの1つが[5]に示されています。このアルゴリズムは完全なリソースプーリングを実現しませんが、現在のインターネットに容易に展開できるという点で「安全」です。これは、1つのパスがそのルートのみを使用する単一パスフローである場合よりも、1つのパスで多くの容量を消費しないことを意味します。これにより、共有ボトルネックで単一パスTCPとの公平な共存が保証されます。
It is foreseeable that different congestion controllers will be implemented for MPTCP, each aiming to achieve different properties in the resource pooling/fairness/stability design space, as well as those for achieving different properties in quality of service, reliability, and resilience.
さまざまな輻輳コントローラーがMPTCPに実装され、それぞれがリソースプーリング/フェアネス/安定性設計スペースで異なるプロパティを実現することを目的としており、サービス品質、信頼性、および回復力で異なるプロパティを実現することが予測されます。
Regardless of the algorithm used, the design of the MPTCP protocol aims to provide the congestion control implementations sufficient information to take the right decisions; this information includes, for each subflow, which packets were lost and when.
使用されるアルゴリズムに関係なく、MPTCPプロトコルの設計は、輻輳制御の実装に適切な決定を行うための十分な情報を提供することを目的としています。この情報には、各サブフローについて、どのパケットがいつ失われたかが含まれます。
Within a local MPTCP implementation, a host may use any local policy it wishes to decide how to share the traffic to be sent over the available paths.
ローカルMPTCP実装内では、ホストは、利用可能なパスを介して送信されるトラフィックを共有する方法を決定したいローカルポリシーを使用できます。
In the typical use case, where the goal is to maximize throughput, all available paths will be used simultaneously for data transfer, using coupled congestion control as described in [5]. It is expected, however, that other use cases will appear.
スループットを最大化することを目的とする一般的な使用例では、[5]で説明されているように、結合された輻輳制御を使用して、すべての使用可能なパスが同時にデータ転送に使用されます。ただし、他のユースケースが現れることが予想されます。
For instance, a possibility is an 'all-or-nothing' approach, i.e., have a second path ready for use in the event of failure of the first path, but alternatives could include entirely saturating one path before using an additional path (the 'overflow' case). Such choices would be most likely based on the monetary cost of links, but may also be based on properties such as the delay or jitter of links, where stability (of delay or bandwidth) is more important than throughput. Application requirements such as these are discussed in detail in [6].
たとえば、可能性は「オールオアナッシング」アプローチです。つまり、最初のパスに障害が発生した場合に使用できるように2番目のパスを用意しますが、別のパスを使用する前に1つのパスを完全に飽和させることもできます（ 「オーバーフロー」の場合）。そのような選択は、リンクの金銭的コストに基づく可能性が最も高いですが、リンクの遅延やジッターなどのプロパティにも基づく場合があり、スループットよりも（遅延または帯域幅の）安定性が重要です。このようなアプリケーション要件については、[6]で詳しく説明しています。
The ability to make effective choices at the sender requires full knowledge of the path "cost", which is unlikely to be the case. It would be desirable for a receiver to be able to signal their own preferences for paths, since they will often be the multihomed party, and may have to pay for metered incoming bandwidth.
送信側で効果的な選択を行う機能には、パスの「コスト」に関する完全な知識が必要です。多くの場合、マルチホームパーティであり、計測された着信帯域幅の代金を支払う必要がある可能性があるため、受信機がパスの独自の設定を通知できることが望ましいでしょう。
Whilst fine-grained control may be the most powerful solution, that would require some mechanism such as overloading the Explicit Congestion Notification (ECN) signal [17], which is undesirable, and it is felt that there would not be sufficient benefit to justify an entirely new signal. Therefore, the MP_JOIN option (see Section 3.2) contains the 'B' bit, which allows a host to indicate to its peer that this path should be treated as a backup path to use only in the event of failure of other working subflows (i.e., a subflow where the receiver has indicated B=1 SHOULD NOT be used to send data unless there are no usable subflows where B=0).
きめの細かい制御が最も強力なソリューションである可能性がありますが、明示的輻輳通知（ECN）信号のオーバーロードなどのメカニズムが必要になるため[17]、これは望ましくなく、正当化するのに十分な利点がないと考えられますまったく新しいシグナル。したがって、MP_JOINオプション（セクション3.2を参照）には「B」ビットが含まれています。これにより、ホストは、このパスを他の動作しているサブフローで障害が発生した場合にのみ使用するバックアップパスとして扱う必要があることをピアに示すことができます（つまり、 、受信者がB = 1を示しているサブフローは、B = 0）の使用可能なサブフローがない限り、データを送信するために使用すべきではありません。
In the event that the available set of paths changes, a host may wish to signal a change in priority of subflows to the peer (e.g., a subflow that was previously set as backup should now take priority over all remaining subflows). Therefore, the MP_PRIO option, shown in Figure 11, can be used to change the 'B' flag of the subflow on which it is sent.
利用可能なパスのセットが変更された場合、ホストはサブフローの優先度の変更をピアに通知したい場合があります（たとえば、以前バックアップとして設定されていたサブフローが残りのすべてのサブフローよりも優先されるようになります）。したがって、図11に示すMP_PRIOオプションを使用して、送信されるサブフローの「B」フラグを変更できます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----+-+--------------+
| Kind | Length |Subtype| |B| AddrID (opt) |
+---------------+---------------+-------+-----+-+--------------+
Figure 11: Change Subflow Priority (MP_PRIO) Option
図11：サブフローの優先度の変更（MP_PRIO）オプション
It should be noted that the backup flag is a request from a data receiver to a data sender only, and the data sender SHOULD adhere to these requests. A host cannot assume that the data sender will do so, however, since local policies -- or technical difficulties -- may override MP_PRIO requests. Note also that this signal applies to a single direction, and so the sender of this option could choose to continue using the subflow to send data even if it has signaled B=1 to the other host.
バックアップフラグはデータレシーバーからデータセンダーへの要求のみであり、データセンダーはこれらの要求に従う必要があることに注意してください。ただし、ローカルポリシーまたは技術的な問題によりMP_PRIO要求が上書きされる可能性があるため、ホストはデータ送信者がそうすることを想定できません。また、この信号は単一方向に適用されるため、このオプションの送信者は、B = 1を他のホストに通知した場合でも、サブフローを使用してデータを送信し続けることもできます。
This option can also be applied to other subflows than the one on which it is sent, by setting the optional Address ID field. This applies the given setting of B to all subflows in this connection that use the address identified by the given Address ID. The presence of this field is determined by the option length; if Length==4 then it is present. If Length==3, then it applies to the current subflow only. The use case of this is that a host can signal to its peer that an address is temporarily unavailable (for example, if it has radio coverage issues) and the peer should therefore drop to backup state on all subflows using that Address ID.
このオプションは、オプションのアドレスIDフィールドを設定することにより、送信されたサブフロー以外のサブフローにも適用できます。これは、指定されたアドレスIDで識別されるアドレスを使用するこの接続のすべてのサブフローに、指定されたBの設定を適用します。このフィールドの存在は、オプションの長さによって決まります。 Length == 4の場合は存在します。 Length == 3の場合、現在のサブフローにのみ適用されます。このユースケースは、ホストがピアに、アドレスが一時的に利用不可であることを通知できる（たとえば、無線カバレッジの問題がある場合）ため、ピアはそのアドレスIDを使用するすべてのサブフローでバックアップ状態にドロップする必要があります。
We use the term "path management" to refer to the exchange of information about additional paths between hosts, which in this design is managed by multiple addresses at hosts. For more detail of the architectural thinking behind this design, see the MPTCP Architecture document [2].
「パス管理」という用語は、ホスト間の追加のパスに関する情報の交換を指すために使用します。この設計では、ホストの複数のアドレスによって管理されます。この設計の背後にあるアーキテクチャの考え方の詳細については、MPTCPアーキテクチャドキュメント[2]を参照してください。
This design makes use of two methods of sharing such information, and both can be used on a connection. The first is the direct setup of new subflows, already described in Section 3.2, where the initiator has an additional address. The second method, described in the following subsections, signals addresses explicitly to the other host to allow it to initiate new subflows. The two mechanisms are complementary: the first is implicit and simple, while the explicit is more complex but is more robust. Together, the mechanisms allow addresses to change in flight (and thus support operation through NATs, since the source address need not be known), and also allow the signaling of previously unknown addresses, and of addresses belonging to other address families (e.g., both IPv4 and IPv6).
この設計では、このような情報を共有する2つの方法を利用しており、どちらも接続で使用できます。 1つ目は、すでにセクション3.2で説明した新しいサブフローの直接セットアップで、イニシエーターが追加のアドレスを持っています。次のサブセクションで説明する2番目の方法は、他のホストにアドレスを明示的に通知して、新しいサブフローを開始できるようにします。 2つのメカニズムは相補的です。最初のメカニズムは暗黙的で単純ですが、明示的メカニズムはより複雑ですがより堅牢です。一緒に、メカニズムはアドレスが飛行中に変化することを可能にし（したがって、送信元アドレスが既知である必要がないため、NATを介した操作をサポートし）、また、以前は未知のアドレス、および他のアドレスファミリーに属するアドレス（例：両方）のシグナリングも可能にしますIPv4およびIPv6）。
Here is an example of typical operation of the protocol:
これは、プロトコルの典型的な操作の例です：
o An MPTCP connection is initially set up between address/port A1 of Host A and address/port B1 of Host B. If Host A is multihomed and multiaddressed, it can start an additional subflow from its address A2 to B1, by sending a SYN with a Join option from A2 to B1, using B's previously declared token for this connection. Alternatively, if B is multihomed, it can try to set up a new subflow from B2 to A1, using A's previously declared token. In either case, the SYN will be sent to the port already in use for the original subflow on the receiving host.
o MPTCP接続は、最初にホストAのアドレス/ポートA1とホストBのアドレス/ポートB1の間に設定されます。ホストAがマルチホームでマルチアドレスの場合、SYNを送信することにより、アドレスA2からB1への追加のサブフローを開始できます。 AからB1への結合オプション。この接続用に以前に宣言されたBのトークンを使用します。あるいは、Bがマルチホームである場合、Aの以前に宣言されたトークンを使用して、B2からA1への新しいサブフローのセットアップを試みることができます。どちらの場合も、SYNは受信ホストの元のサブフローですでに使用されているポートに送信されます。
o Simultaneously (or after a timeout), an ADD_ADDR option (Section 3.4.1) is sent on an existing subflow, informing the receiver of the sender's alternative address(es). The recipient can use this information to open a new subflow to the sender's additional address. In our example, A will send ADD_ADDR option informing B of address/port A2. The mix of using the SYN-based option and the ADD_ADDR option, including timeouts, is implementation specific and can be tailored to agree with local policy.
o 同時に（またはタイムアウト後に）、ADD_ADDRオプション（セクション3.4.1）が既存のサブフローで送信され、送信者の代替アドレスを受信者に通知します。受信者はこの情報を使用して、送信者の追加アドレスへの新しいサブフローを開くことができます。この例では、Aはアドレス/ポートA2をBに通知するADD_ADDRオプションを送信します。タイムアウトを含む、SYNベースのオプションとADD_ADDRオプションの使用の組み合わせは実装固有であり、ローカルポリシーに一致するように調整できます。
o If subflow A2-B1 is successfully set up, Host B can use the Address ID in the Join option to correlate this with the ADD_ADDR option that will also arrive on an existing subflow; now B knows not to open A2-B1, ignoring the ADD_ADDR. Otherwise, if B has not received the A2-B1 MP_JOIN SYN but received the ADD_ADDR, it can try to initiate a new subflow from one or more of its addresses to address A2. This permits new sessions to be opened if one host is behind a NAT.
o サブフローA2-B1が正常にセットアップされた場合、ホストBは、結合オプションのアドレスIDを使用して、これを既存のサブフローに到着するADD_ADDRオプションと関連付けることができます。これでBは、ADD_ADDRを無視してA2-B1を開かないことを認識します。それ以外の場合、BはA2-B1 MP_JOIN SYNを受信していないがADD_ADDRを受信している場合、そのアドレスの1つ以上からアドレスA2への新しいサブフローの開始を試みることができます。これにより、1つのホストがNATの背後にある場合、新しいセッションを開くことができます。
Other ways of using the two signaling mechanisms are possible; for instance, signaling addresses in other address families can only be done explicitly using the Add Address option.
2つの信号メカニズムを使用する他の方法も可能です。たとえば、他のアドレスファミリのシグナリングアドレスは、[アドレスの追加]オプションを使用して明示的にのみ実行できます。
The Add Address (ADD_ADDR) TCP option announces additional addresses (and optionally, ports) on which a host can be reached (Figure 12). Multiple instances of this TCP option can be added in a single message if there is sufficient TCP option space; otherwise, multiple TCP messages containing this option will be sent. This option can be used at any time during a connection, depending on when the sender wishes to enable multiple paths and/or when paths become available. As with all MPTCP signals, the receiver MUST undertake standard TCP validity checks before acting upon it.
Add Address（ADD_ADDR）TCPオプションは、ホストに到達できる追加のアドレス（およびオプションでポート）を通知します（図12）。十分なTCPオプションスペースがある場合、このTCPオプションの複数のインスタンスを単一のメッセージに追加できます。そうでない場合、このオプションを含む複数のTCPメッセージが送信されます。このオプションは、送信者が複数のパスを有効にしたい場合やパスが使用可能になった場合に応じて、接続中にいつでも使用できます。すべてのMPTCP信号と同様に、受信者はそれに作用する前に標準のTCP妥当性チェックを行わなければなりません（MUST）。
Every address has an Address ID that can be used for uniquely identifying the address within a connection for address removal. This is also used to identify MP_JOIN options (see Section 3.2) relating to the same address, even when address translators are in use. The Address ID MUST uniquely identify the address to the sender (within the scope of the connection), but the mechanism for allocating such IDs is implementation specific.
すべてのアドレスには、接続内のアドレスを一意に識別してアドレスを削除するために使用できるアドレスIDがあります。これは、アドレス変換プログラムが使用されている場合でも、同じアドレスに関連するMP_JOINオプション（セクション3.2を参照）を識別するためにも使用されます。アドレスIDは、送信者のアドレスを（接続の範囲内で）一意に識別しなければなりません（MUST）が、そのようなIDを割り当てるメカニズムは実装固有です。
All address IDs learned via either MP_JOIN or ADD_ADDR SHOULD be stored by the receiver in a data structure that gathers all the Address ID to address mappings for a connection (identified by a token pair). In this way, there is a stored mapping between Address ID, observed source address, and token pair for future processing of control information for a connection. Note that an implementation MAY discard incoming address advertisements at will, for example, for avoiding the required mapping state, or because advertised addresses are of no use to it (for example, IPv6 addresses when it has IPv4 only). Therefore, a host MUST treat address advertisements as soft state, and it MAY choose to refresh advertisements periodically.
MP_JOINまたはADD_ADDRのいずれかを介して学習されたすべてのアドレスIDは、接続のすべてのアドレスIDからアドレスへのマッピング（トークンペアで識別）を収集するデータ構造にレシーバーによって格納される必要があります（SHOULD）。このようにして、接続の制御情報の将来の処理のために、アドレスID、観測されたソースアドレス、およびトークンペアの間に保存されたマッピングがあります。たとえば、必要なマッピング状態を回避するため、またはアドバタイズされたアドレスが使用されないため（たとえば、IPv4のみの場合はIPv6アドレス）、実装は着信アドレスアドバタイズを自由に破棄できることに注意してください。したがって、ホストはアドレスアドバタイズメントをソフトステートとして扱う必要があり、定期的にアドバタイズメントを更新することを選択できます（MAY）。
This option is shown in Figure 12. The illustration is sized for IPv4 addresses (IPVer = 4). For IPv6, the IPVer field will read 6, and the length of the address will be 16 octets (instead of 4).
このオプションを図12に示します。図は、IPv4アドレス用にサイズ変更されています（IPVer = 4）。 IPv6の場合、IPVerフィールドは6を読み取り、アドレスの長さは（4ではなく）16オクテットになります。
The presence of the final 2 octets, specifying the TCP port number to use, are optional and can be inferred from the length of the option. Although it is expected that the majority of use cases will use the same port pairs as used for the initial subflow (e.g., port 80 remains port 80 on all subflows, as does the ephemeral port at the client), there may be cases (such as port-based load balancing) where the explicit specification of a different port is required. If no port is specified, MPTCP SHOULD attempt to connect to the specified address on the same port as is already in use by the subflow on which the ADD_ADDR signal was sent; this is discussed in more detail in Section 3.8.
最後の2オクテットの存在、使用するTCPポート番号の指定はオプションであり、オプションの長さから推測できます。大部分の使用例では、最初のサブフローに使用されるのと同じポートペアを使用することが予想されます（たとえば、ポート80はすべてのサブフローでポート80のままで、クライアントの一時ポートも同様です）。別のポートの明示的な指定が必要な場合は、ポートベースのロードバランシングとして）。ポートが指定されていない場合、MPTCPは、ADD_ADDRシグナルが送信されたサブフローによってすでに使用されているのと同じポート上の指定されたアドレスへの接続を試行する必要があります（SHOULD）。これについては、セクション3.8で詳しく説明します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
| Kind | Length |Subtype| IPVer | Address ID |
+---------------+---------------+-------+-------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+-------------------------------+
| Port (2 octets, optional) |
+-------------------------------+
Figure 12: Add Address (ADD_ADDR) Option
図12：アドレスの追加（ADD_ADDR）オプション
Due to the proliferation of NATs, it is reasonably likely that one host may attempt to advertise private addresses [18]. It is not desirable to prohibit this, since there may be cases where both hosts have additional interfaces on the same private network, and a host MAY want to advertise such addresses. The MP_JOIN handshake to create a new subflow (Section 3.2) provides mechanisms to minimize security risks. The MP_JOIN message contains a 32-bit token that uniquely identifies the connection to the receiving host. If the token is unknown, the host will return with a RST. In the unlikely event that the token is known, subflow setup will continue, but the HMAC exchange must occur for authentication. This will fail, and will provide sufficient protection against two unconnected hosts accidentally setting up a new subflow upon the signal of a private address. Further security considerations around the issue of ADD_ADDR messages that accidentally misdirect, or maliciously direct, new MP_JOIN attempts are discussed in Section 5.
NATの急増により、1つのホストがプライベートアドレスのアドバタイズを試みる可能性はかなりあります[18]。両方のホストが同じプライベートネットワーク上に追加のインターフェースを持ち、ホストがそのようなアドレスをアドバタイズしたい場合があるため、これを禁止することは望ましくありません。新しいサブフローを作成するためのMP_JOINハンドシェイク（セクション3.2）は、セキュリティリスクを最小限に抑えるメカニズムを提供します。 MP_JOINメッセージには、受信ホストへの接続を一意に識別する32ビットトークンが含まれています。トークンが不明な場合、ホストはRSTで戻ります。トークンが知られているというまれなイベントでは、サブフローのセットアップは続行されますが、認証のためにHMAC交換が発生する必要があります。これは失敗し、2つの接続されていないホストがプライベートアドレスの信号で誤って新しいサブフローをセットアップするのを防ぐ十分な保護を提供します。新しいMP_JOINの試みを誤って誤って、または悪意を持って指示するADD_ADDRメッセージの問題に関するセキュリティ上の考慮事項については、セクション5で説明します。
Ideally, ADD_ADDR and REMOVE_ADDR options would be sent reliably, and in order, to the other end. This would ensure that this address management does not unnecessarily cause an outage in the connection when remove/add addresses are processed in reverse order, and also to ensure that all possible paths are used. Note, however, that losing reliability and ordering will not break the multipath connections, it will just reduce the opportunity to open multipath paths and to survive different patterns of path failures.
理想的には、ADD_ADDRおよびREMOVE_ADDRオプションが確実に、順番に、もう一方の端に送信されます。これにより、アドレスの削除/追加が逆の順序で処理されるときに、このアドレス管理によって接続が不必要に停止することがなくなり、すべての可能なパスが使用されるようになります。ただし、信頼性と順序が失われてもマルチパス接続が切断されるわけではなく、マルチパスパスを開いてさまざまなパターンのパス障害に耐える機会が減ることに注意してください。
Therefore, implementing reliability signals for these TCP options is not necessary. In order to minimize the impact of the loss of these options, however, it is RECOMMENDED that a sender should send these options on all available subflows. If these options need to be received in order, an implementation SHOULD only send one ADD_ADDR/ REMOVE_ADDR option per RTT, to minimize the risk of misordering.
したがって、これらのTCPオプションの信頼性信号を実装する必要はありません。ただし、これらのオプションの喪失による影響を最小限に抑えるために、送信者はこれらのオプションをすべての使用可能なサブフローで送信することをお勧めします。これらのオプションを順番に受信する必要がある場合、実装は、RTTごとに1つのADD_ADDR / REMOVE_ADDRオプションのみを送信して、順序の誤りのリスクを最小限に抑える必要があります。
A host can send an ADD_ADDR message with an already assigned Address ID, but the Address MUST be the same as previously assigned to this Address ID, and the Port MUST be different from one already in use for this Address ID. If these conditions are not met, the receiver SHOULD silently ignore the ADD_ADDR. A host wishing to replace an existing Address ID MUST first remove the existing one (Section 3.4.2).
ホストは、すでに割り当てられたアドレスIDを使用してADD_ADDRメッセージを送信できますが、アドレスは以前にこのアドレスIDに割り当てられたものと同じである必要があり、ポートはこのアドレスIDですでに使用されているものとは異なる必要があります。これらの条件が満たされない場合、受信者はADD_ADDRを黙って無視すべきです（SHOULD）。既存のアドレスIDを置き換えたいホストは、まず既存のものを削除しなければなりません（セクション3.4.2）。
A host that receives an ADD_ADDR but finds a connection set up to that IP address and port number is unsuccessful SHOULD NOT perform further connection attempts to this address/port combination for this connection. A sender that wants to trigger a new incoming connection attempt on a previously advertised address/port combination can therefore refresh ADD_ADDR information by sending the option again.
ADD_ADDRを受信したが、そのIPアドレスとポート番号に設定された接続が見つからないホストは、この接続のこのアドレス/ポートの組み合わせに対してそれ以上の接続試行を実行してはなりません（SHOULD NOT）。そのため、以前にアドバタイズされたアドレスとポートの組み合わせで新しい着信接続の試行をトリガーしたい送信者は、オプションを再度送信してADD_ADDR情報を更新できます。
During normal MPTCP operation, it is unlikely that there will be sufficient TCP option space for ADD_ADDR to be included along with those for data sequence numbering (Section 3.3.1). Therefore, it is expected that an MPTCP implementation will send the ADD_ADDR option on separate ACKs. As discussed earlier, however, an MPTCP implementation MUST NOT treat duplicate ACKs with any MPTCP option, with the exception of the DSS option, as indications of congestion [12], and an MPTCP implementation SHOULD NOT send more than two duplicate ACKs in a row for signaling purposes.
通常のMPTCP操作中に、ADD_ADDRに十分なTCPオプションスペースがデータシーケンス番号付け用のスペースとともに含まれることはほとんどありません（セクション3.3.1）。したがって、MPTCP実装は、個別のACKでADD_ADDRオプションを送信することが予想されます。ただし、前述のように、MPTCP実装は、DSSオプションを除いて、MPTCPオプションを含む重複ACKを輻輳の兆候として処理してはなりません[12]。また、MPTCP実装は、2つ以上の重複ACKを続けて送信してはなりません（SHOULD NOT）。シグナリング用。
If, during the lifetime of an MPTCP connection, a previously announced address becomes invalid (e.g., if the interface disappears), the affected host SHOULD announce this so that the peer can remove subflows related to this address.
MPTCP接続の有効期間中に、以前にアナウンスされたアドレスが無効になった場合（たとえば、インターフェイスが消えた場合）、影響を受けるホストはこれをアナウンスして、ピアがこのアドレスに関連するサブフローを削除できるようにする必要があります（SHOULD）。
This is achieved through the Remove Address (REMOVE_ADDR) option (Figure 13), which will remove a previously added address (or list of addresses) from a connection and terminate any subflows currently using that address.
これは、アドレスの削除（REMOVE_ADDR）オプション（図13）によって実現されます。これにより、以前に追加されたアドレス（またはアドレスのリスト）が接続から削除され、そのアドレスを現在使用しているサブフローが終了します。
For security purposes, if a host receives a REMOVE_ADDR option, it must ensure the affected path(s) are no longer in use before it instigates closure. The receipt of REMOVE_ADDR SHOULD first trigger the sending of a TCP keepalive [19] on the path, and if a response is received the path SHOULD NOT be removed. Typical TCP validity tests on the subflow (e.g., ensuring sequence and ACK numbers are correct) MUST also be undertaken. An implementation can use indications of these test failures as part of intrusion detection or error logging.
セキュリティ上の理由から、ホストがREMOVE_ADDRオプションを受け取った場合、影響を受けるパスが閉鎖を開始する前に使用されていないことを確認する必要があります。 REMOVE_ADDRの受信は、最初にパス上のTCPキープアライブ[19]の送信をトリガーし、応答が受信された場合、パスは削除されるべきではありません（SHOULD NOT）。サブフローの一般的なTCP有効性テスト（たとえば、シーケンス番号とACK番号が正しいことを確認する）も実施する必要があります。実装では、侵入検知またはエラーログの一部として、これらのテストの失敗の兆候を使用できます。
The sending and receipt (if no keepalive response was received) of this message SHOULD trigger the sending of RSTs by both hosts on the affected subflow(s) (if possible), as a courtesy to cleaning up middlebox state, before cleaning up any local state.
このメッセージの送受信（キープアライブ応答が受信されなかった場合）は、ローカルでクリーンアップする前に、ミドルボックスの状態をクリーンアップするための礼儀として、影響を受けるサブフローの両方のホストによるRSTの送信をトリガーする必要があります（可能な場合）。状態。
Address removal is undertaken by ID, so as to permit the use of NATs and other middleboxes that rewrite source addresses. If there is no address at the requested ID, the receiver will silently ignore the request.
送信元アドレスを書き換えるNATおよびその他のミドルボックスの使用を許可するために、アドレスの削除はIDによって行われます。要求されたIDにアドレスがない場合、受信者は要求を黙って無視します。
A subflow that is still functioning MUST be closed with a FIN exchange as in regular TCP, rather than using this option. For more information, see Section 3.3.3.
まだ機能しているサブフローは、このオプションを使用するのではなく、通常のTCPのようにFIN交換で閉じる必要があります。詳細は、3.3.3項を参照してください。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
| Kind | Length = 3+n |Subtype|(resvd)| Address ID | ...
+---------------+---------------+-------+-------+---------------+
(followed by n-1 Address IDs, if required)
Figure 13: Remove Address (REMOVE_ADDR) Option
図13：アドレスの削除（REMOVE_ADDR）オプション
Regular TCP has the means of sending a reset (RST) signal to abruptly close a connection. With MPTCP, the RST only has the scope of the subflow and will only close the concerned subflow but not affect the remaining subflows. MPTCP's connection will stay alive at the data level, in order to permit break-before-make handover between subflows. It is therefore necessary to provide an MPTCP-level "reset" to allow the abrupt closure of the whole MPTCP connection, and this is the MP_FASTCLOSE option.
通常のTCPには、リセット（RST）信号を送信して接続を突然閉じる手段があります。 MPTCPを使用すると、RSTはサブフローのスコープのみを持ち、関連するサブフローを閉じるだけで、残りのサブフローには影響しません。 MPTCPの接続は、サブフロー間のブレークビフォアメイクハンドオーバーを可能にするために、データレベルで存続します。したがって、MPTCP接続全体の突然のクローズを可能にするために、MPTCPレベルの「リセット」を提供する必要があります。これはMP_FASTCLOSEオプションです。
MP_FASTCLOSE is used to indicate to the peer that the connection will be abruptly closed and no data will be accepted anymore. The reasons for triggering an MP_FASTCLOSE are implementation specific. Regular TCP does not allow sending a RST while the connection is in a synchronized state [1]. Nevertheless, implementations allow the sending of a RST in this state, if, for example, the operating system is running out of resources. In these cases, MPTCP should send the MP_FASTCLOSE. This option is illustrated in Figure 14.
MP_FASTCLOSEは、接続が突然閉じられ、データが受け入れられなくなることをピアに示すために使用されます。 MP_FASTCLOSEをトリガーする理由は実装固有です。通常のTCPでは、接続が同期状態にある間はRSTを送信できません[1]。それにもかかわらず、たとえばオペレーティングシステムのリソースが不足している場合、実装ではこの状態でRSTを送信できます。これらの場合、MPTCPはMP_FASTCLOSEを送信する必要があります。このオプションを図14に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----------------------+
| Kind | Length |Subtype| (reserved) |
+---------------+---------------+-------+-----------------------+
| Option Receiver's Key |
| (64 bits) |
| |
+---------------------------------------------------------------+
Figure 14: Fast Close (MP_FASTCLOSE) Option
図14：高速クローズ（MP_FASTCLOSE）オプション
If Host A wants to force the closure of an MPTCP connection, the MPTCP Fast Close procedure is as follows:
ホストAがMPTCP接続を強制的に閉じたい場合、MPTCP高速クローズ手順は次のとおりです。
o Host A sends an ACK containing the MP_FASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake. On all the other subflows, Host A sends a regular TCP RST to close these subflows, and tears them down. Host A now enters FASTCLOSE_WAIT state.
o ホストAは、最初の接続ハンドシェイクで宣言されたホストBのキーを含む、1つのサブフローでMP_FASTCLOSEオプションを含むACKを送信します。他のすべてのサブフローでは、ホストAは通常のTCP RSTを送信してこれらのサブフローを閉じ、それらを破棄します。これで、ホストAはFASTCLOSE_WAIT状態になります。
o Upon receipt of an MP_FASTCLOSE, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state).
o 有効なキーを含むMP_FASTCLOSEを受信すると、ホストBはTCP RSTを使用して同じサブフローで応答し、すべてのサブフローを破棄します。これで、ホストBはMPTCP接続全体を閉じることができます（直接CLOSED状態に移行します）。
o As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole connection (transition from FASTCLOSE_WAIT to CLOSED states). If Host A receives an MP_FASTCLOSE instead of a TCP RST, both hosts attempted fast closure simultaneously. Host A should reply with a TCP RST and tear down the connection.
o ホストAが残りのサブフローでTCP RSTを受信するとすぐに、ホストAはこのサブフローを閉じ、接続全体を切断できます（FASTCLOSE_WAITからCLOSED状態への遷移）。ホストAがTCP RSTではなくMP_FASTCLOSEを受信した場合、両方のホストが同時に高速クローズを試みました。ホストAはTCP RSTで応答し、接続を切断する必要があります。
o If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow where the MPTCP_RST has been sent), it SHOULD retransmit the MP_FASTCLOSE. The number of retransmissions SHOULD be limited to avoid this connection from being retained for a long time, but this limit is implementation specific. A RECOMMENDED number is 3.
o ホストAが1回の再送信タイムアウト（RTO）（MPTCP_RSTが送信されたサブフローのRTO）の後でMP_FASTCLOSEに応答してTCP RSTを受信しない場合、MP_FASTCLOSEを再送信する必要があります（SHOULD）。この接続が長期間保持されないように、再送信の数を制限する必要があります（SHOULD）が、この制限は実装固有のものです。推奨番号は3です。
Sometimes, middleboxes will exist on a path that could prevent the operation of MPTCP. MPTCP has been designed in order to cope with many middlebox modifications (see Section 6), but there are still some cases where a subflow could fail to operate within the MPTCP requirements. These cases are notably the following: the loss of TCP options on a path and the modification of payload data. If such an event occurs, it is necessary to "fall back" to the previous, safe operation. This may be either falling back to regular TCP or removing a problematic subflow.
MPTCPの動作を妨げる可能性のあるパス上にミドルボックスが存在する場合があります。 MPTCPは、ミドルボックスの多くの変更（セクション6を参照）に対応するように設計されていますが、サブフローがMPTCP要件の範囲内で機能しない場合もあります。これらのケースは特に次のとおりです。パスでのTCPオプションの損失とペイロードデータの変更。このようなイベントが発生した場合、以前の安全な操作に「フォールバック」する必要があります。これは、通常のTCPにフォールバックするか、問題のあるサブフローを削除するかのいずれかです。
At the start of an MPTCP connection (i.e., the first subflow), it is important to ensure that the path is fully MPTCP capable and the necessary TCP options can reach each host. The handshake as described in Section 3.1 SHOULD fall back to regular TCP if either of the SYN messages do not have the MPTCP options: this is the same, and desired, behavior in the case where a host is not MPTCP capable, or the path does not support the MPTCP options. When attempting to join an existing MPTCP connection (Section 3.2), if a path is not MPTCP capable and the TCP options do not get through on the SYNs, the subflow will be closed according to the MP_JOIN logic.
MPTCP接続の開始時に（つまり、最初のサブフロー）、パスが完全にMPTCP対応であり、必要なTCPオプションが各ホストに到達できることを確認することが重要です。セクション3.1で説明されているハンドシェイクは、いずれかのSYNメッセージにMPTCPオプションがない場合、通常のTCPにフォールバックする必要があります。これは、ホストがMPTCPに対応していない場合、またはパスがそうである場合と同じで望ましい動作です。 MPTCPオプションをサポートしていません。既存のMPTCP接続（セクション3.2）に参加しようとするときに、パスがMPTCP対応ではなく、TCPオプションがSYNを通過しない場合、MP_JOINロジックに従ってサブフローが閉じられます。
There is, however, another corner case that should be addressed. That is one of MPTCP options getting through on the SYN, but not on regular packets. This can be resolved if the subflow is the first subflow, and thus all data in flight is contiguous, using the following rules.
ただし、対処する必要がある別のコーナーケースがあります。これは、通常のパケットではなく、SYNを通過するMPTCPオプションの1つです。これは、サブフローが最初のサブフローであり、次のルールを使用して、処理中のすべてのデータが連続している場合に解決できます。
A sender MUST include a DSS option with data sequence mapping in every segment until one of the sent segments has been acknowledged with a DSS option containing a Data ACK. Upon reception of the acknowledgment, the sender has the confirmation that the DSS option passes in both directions and may choose to send fewer DSS options than once per segment.
送信者は、送信されたセグメントの1つがデータACKを含むDSSオプションで確認されるまで、すべてのセグメントにデータシーケンスマッピングのDSSオプションを含める必要があります。確認応答を受信すると、送信者はDSSオプションが両方向に渡されることを確認し、セグメントごとに1回よりも少ないDSSオプションを送信することを選択できます。
If, however, an ACK is received for data (not just for the SYN) without a DSS option containing a Data ACK, the sender determines the path is not MPTCP capable. In the case of this occurring on an additional subflow (i.e., one started with MP_JOIN), the host MUST close the subflow with a RST. In the case of the first subflow (i.e., that started with MP_CAPABLE), it MUST drop out of an MPTCP mode back to regular TCP. The sender will send one final data sequence mapping, with the Data-Level Length value of 0 indicating an infinite mapping (in case the path drops options in one direction only), and then revert to sending data on the single subflow without any MPTCP options.
ただし、データACKを含むDSSオプションを使用せずに（SYNだけでなく）データのACKを受信した場合、送信者はパスがMPTCP対応でないと判断します。これが追加のサブフローで発生した場合（つまり、MP_JOINで開始されたもの）、ホストはRSTでサブフローを閉じる必要があります。最初のサブフロー（つまり、MP_CAPABLEで開始されたサブフロー）の場合、MPTCPモードからドロップして通常のTCPに戻す必要があります。送信側は、1つの最終的なデータシーケンスマッピングを送信します。データレベルの長さの値が0で無限のマッピングであることを示し（パスが一方向にのみオプションをドロップする場合）、MPTCPオプションなしで単一のサブフローでのデータ送信に戻ります。 。
Note that this rule essentially prohibits the sending of data on the third packet of an MP_CAPABLE or MP_JOIN handshake, since both that option and a DSS cannot fit in TCP option space. If the initiator is to send first, another segment must be sent that contains the data and DSS. Note also that an additional subflow cannot be used until the initial path has been verified as MPTCP capable.
このオプションは、MP_CAPABLEまたはMP_JOINハンドシェイクの3番目のパケットでのデータの送信を基本的に禁止していることに注意してください。これは、そのオプションとDSSの両方がTCPオプションスペースに収まらないためです。イニシエーターが最初に送信する場合は、データとDSSを含む別のセグメントを送信する必要があります。また、初期パスがMPTCP対応であることが確認されるまで、追加のサブフローを使用できないことに注意してください。
These rules should cover all cases where such a failure could happen: whether it's on the forward or reverse path and whether the server or the client first sends data. If lost options on data packets occur on any other subflow apart from the initial subflow, it should be treated as a standard path failure. The data would not be DATA_ACKed (since there is no mapping for the data), and the subflow can be closed with a RST.
これらのルールは、そのような障害が発生する可能性のあるすべてのケースをカバーする必要があります。それがフォワードパスにあるかリバースパスにあるか、サーバーまたはクライアントが最初にデータを送信するかどうかです。データパケットの失われたオプションが、最初のサブフロー以外のサブフローで発生した場合、標準のパス障害として処理する必要があります。データはDATA_ACKされず（データのマッピングがないため）、RSTを使用してサブフローを閉じることができます。
The case described above is a specialized case of fallback, for when the lack of MPTCP support is detected before any data is acknowledged at the connection level on a subflow. More generally, fallback (either closing a subflow, or to regular TCP) can become necessary at any point during a connection if a non-MPTCP-aware middlebox changes the data stream.
上記のケースはフォールバックの特殊なケースで、サブフローの接続レベルでデータが確認される前にMPTCPサポートの欠如が検出された場合です。より一般的には、MPTCP非対応のミドルボックスがデータストリームを変更した場合、接続中の任意の時点で（サブフローを閉じるか、通常のTCPに）フォールバックが必要になる可能性があります。
As described in Section 3.3, each portion of data for which there is a mapping is protected by a checksum. This mechanism is used to detect if middleboxes have made any adjustments to the payload (added, removed, or changed data). A checksum will fail if the data has been changed in any way. This will also detect if the length of data on the subflow is increased or decreased, and this means the data sequence mapping is no longer valid. The sender no longer knows what subflow-level sequence number the receiver is genuinely operating at (the middlebox will be faking ACKs in return), and it cannot signal any further mappings. Furthermore, in addition to the possibility of payload modifications that are valid at the application layer, there is the possibility that false positives could be hit across MPTCP segment boundaries, corrupting the data. Therefore, all data from the start of the segment that failed the checksum onwards is not trustworthy.
セクション3.3で説明したように、マッピングがあるデータの各部分は、チェックサムによって保護されます。このメカニズムは、ミドルボックスがペイロードに調整（データの追加、削除、または変更）を行ったかどうかを検出するために使用されます。データが何らかの方法で変更されている場合、チェックサムは失敗します。これにより、サブフローのデータの長さが増減したかどうかも検出されます。これは、データシーケンスマッピングが無効になったことを意味します。送信側は、受信側が本当に動作しているサブフローレベルのシーケンス番号を認識できなくなり（ミドルボックスは代わりにACKを偽装します）、それ以上のマッピングを通知できません。さらに、アプリケーション層で有効なペイロード変更の可能性に加えて、誤検出がMPTCPセグメントの境界を越えてヒットし、データが破損する可能性があります。したがって、チェックサムに失敗したセグメントの開始以降のすべてのデータは信頼できません。
When multiple subflows are in use, the data in flight on a subflow will likely involve data that is not contiguously part of the connection-level stream, since segments will be spread across the multiple subflows. Due to the problems identified above, it is not possible to determine what the adjustment has done to the data (notably, any changes to the subflow sequence numbering). Therefore, it is not possible to recover the subflow, and the affected subflow must be immediately closed with a RST, featuring an MP_FAIL option (Figure 15), which defines the data sequence number at the start of the segment (defined by the data sequence mapping) that had the checksum failure. Note that the MP_FAIL option requires the use of the full 64-bit sequence number, even if 32-bit sequence numbers are normally in use in the DSS signals on the path.
複数のサブフローが使用されている場合、セグメントは複数のサブフローに分散されるため、サブフローで送信中のデータには、接続レベルのストリームの連続部分ではないデータが含まれる可能性があります。上記で特定された問題により、データに対して行われた調整（特に、サブフローのシーケンス番号の変更）を判別することはできません。したがって、サブフローを回復することはできません。影響を受けるサブフローは、RSTですぐに閉じる必要があります。これは、MP_FAILオプション（図15）を特徴とし、セグメントの開始時のデータシーケンス番号を定義します（データシーケンスによって定義されます）。マッピング）チェックサムエラーが発生しました。パスのDSS信号で32ビットのシーケンス番号が通常使用されている場合でも、MP_FAILオプションでは完全な64ビットのシーケンス番号を使用する必要があることに注意してください。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+----------------------+
| Kind | Length=12 |Subtype| (reserved) |
+---------------+---------------+-------+----------------------+
| |
| Data Sequence Number (8 octets) |
| |
+--------------------------------------------------------------+
Figure 15: Fallback (MP_FAIL) Option
図15：フォールバック（MP_FAIL）オプション
The receiver MUST discard all data following the data sequence number specified. Failed data MUST NOT be DATA_ACKed and so will be retransmitted on other subflows (Section 3.3.6).
受信者は、指定されたデータシーケンス番号に続くすべてのデータを破棄する必要があります。失敗したデータはDATA_ACKされてはならず（MUST NOT）、他のサブフローで再送信されます（セクション3.3.6）。
A special case is when there is a single subflow and it fails with a checksum error. If it is known that all unacknowledged data in flight is contiguous (which will usually be the case with a single subflow), an infinite mapping can be applied to the subflow without the need to close it first, and essentially turn off all further MPTCP signaling. In this case, if a receiver identifies a checksum failure when there is only one path, it will send back an MP_FAIL option on the subflow-level ACK, referring to the data-level sequence number of the start of the segment on which the checksum error was detected. The sender will receive this, and if all unacknowledged data in flight is contiguous, will signal an infinite mapping. This infinite mapping will be a DSS option (Section 3.3) on the first new packet, containing a data sequence mapping that acts retroactively, referring to the start of the subflow sequence number of the last segment that was known to be delivered intact. From that point onwards, data can be altered by a middlebox without affecting MPTCP, as the data stream is equivalent to a regular, legacy TCP session.
特殊なケースは、単一のサブフローがあり、チェックサムエラーで失敗する場合です。処理中のすべての未確認のデータが連続していることがわかっている場合（通常、単一のサブフローの場合が該当します）、最初にサブフローを閉じなくても、無限のマッピングをサブフローに適用できます。基本的に、以降のすべてのMPTCPシグナリングをオフにします。 。この場合、パスが1つしかないときにレシーバーがチェックサム障害を識別した場合、チェックサムが適用されるセグメントの開始のデータレベルのシーケンス番号を参照して、サブフローレベルのACKにMP_FAILオプションを送り返します。エラーが検出されました。送信側はこれを受信し、進行中のすべての未確認データが連続している場合は、無限マッピングを通知します。この無限のマッピングは、最初の新しいパケットのDSSオプション（セクション3.3）であり、そのまま配信されることがわかっている最後のセグメントのサブフローシーケンス番号の開始を参照して、遡及的に機能するデータシーケンスマッピングが含まれます。それ以降は、データストリームは通常のレガシーTCPセッションと同等であるため、MPTCPに影響を与えることなく、ミドルボックスによってデータを変更できます。
In the rare case that the data is not contiguous (which could happen when there is only one subflow but it is retransmitting data from a subflow that has recently been uncleanly closed), the receiver MUST close the subflow with a RST with MP_FAIL. The receiver MUST discard all data that follows the data sequence number specified. The sender MAY attempt to create a new subflow belonging to the same connection, and, if it chooses to do so, SHOULD place the single subflow immediately in single-path mode by setting an infinite data sequence mapping. This mapping will begin from the data-level sequence number that was declared in the MP_FAIL.
データが連続していないまれなケース（サブフローが1つしかないが、最近きれいに閉じられていないサブフローからデータを再送信しているときに発生する可能性があります）では、レシーバーはMP_FAILを使用してRSTでサブフローを閉じる必要があります。受信者は、指定されたデータシーケンス番号に続くすべてのデータを破棄する必要があります。送信者は、同じ接続に属する新しいサブフローを作成しようとする場合があり、そうすることを選択した場合は、無限のデータシーケンスマッピングを設定して、単一のサブフローをただちにシングルパスモードにする必要があります。このマッピングは、MP_FAILで宣言されたデータレベルのシーケンス番号から始まります。
After a sender signals an infinite mapping, it MUST only use subflow ACKs to clear its send buffer. This is because Data ACKs may become misaligned with the subflow ACKs when middleboxes insert or delete data. The receive SHOULD stop generating Data ACKs after it receives an infinite mapping.
送信者が無限マッピングをシグナリングした後、送信バッファをクリアするためにサブフローACKのみを使用する必要があります。これは、ミドルボックスがデータを挿入または削除すると、データACKがサブフローACKとずれてしまう可能性があるためです。受信は、無限マッピングを受信した後、データACKの生成を停止する必要があります（SHOULD）。
When a connection has fallen back, only one subflow can send data; otherwise, the receiver would not know how to reorder the data. In practice, this means that all MPTCP subflows will have to be terminated except one. Once MPTCP falls back to regular TCP, it MUST NOT revert to MPTCP later in the connection.
接続がフォールバックすると、1つのサブフローのみがデータを送信できます。そうしないと、受信者はデータを並べ替える方法がわかりません。実際には、これは、1つを除いてすべてのMPTCPサブフローを終了する必要があることを意味します。 MPTCPが通常のTCPにフォールバックした後は、接続の後半でMPTCPに戻してはなりません。
It should be emphasized that we are not attempting to prevent the use of middleboxes that want to adjust the payload. An MPTCP-aware middlebox could provide such functionality by also rewriting checksums.
ペイロードを調整したいミドルボックスの使用を妨げようとしているわけではないことを強調しておく必要があります。 MPTCP対応のミドルボックスは、チェックサムも書き換えることにより、このような機能を提供できます。
In addition to the fallback mechanism as described above, the standard classes of TCP errors may need to be handled in an MPTCP-specific way. Note that changing semantics -- such as the relevance of a RST -- are covered in Section 4. Where possible, we do not want to deviate from regular TCP behavior.
上記のフォールバックメカニズムに加えて、TCPエラーの標準クラスは、MPTCP固有の方法で処理する必要がある場合があります。 RSTの関連性などのセマンティクスの変更については、セクション4で説明していることに注意してください。可能な場合は、通常のTCP動作から逸脱することは望ましくありません。
The following list covers possible errors and the appropriate MPTCP behavior:
次のリストは、考えられるエラーと適切なMPTCPの動作を示しています。
o Unknown token in MP_JOIN (or HMAC failure in MP_JOIN ACK, or missing MP_JOIN in SYN/ACK response): send RST (analogous to TCP's behavior on an unknown port)
o MP_JOINの不明なトークン（またはMP_JOIN ACKのHMAC障害、またはSYN / ACK応答のMP_JOINの欠落）：RSTを送信（不明なポートでのTCPの動作に類似）
o DSN out of window (during normal operation): drop the data, do not send Data ACKs
o ウィンドウ外のDSN（通常の操作中）：データをドロップし、データACKを送信しない
o Remove request for unknown address ID: silently ignore
o 不明なアドレスIDの要求を削除します：黙って無視します
There are a number of heuristics that are needed for performance or deployment but that are not required for protocol correctness. In this section, we detail such heuristics. Note that discussion of buffering and certain sender and receiver window behaviors are presented in Sections 3.3.4 and 3.3.5, as well as retransmission in Section 3.3.6.
パフォーマンスまたはデプロイメントに必要なヒューリスティックがいくつかありますが、プロトコルの正確性には必要ありません。このセクションでは、そのようなヒューリスティックについて詳しく説明します。バッファリングと特定の送信側および受信側ウィンドウの動作についての説明は、セクション3.3.4および3.3.5に示され、再送信はセクション3.3.6に示されていることに注意してください。
Under typical operation, an MPTCP implementation SHOULD use the same ports as already in use. In other words, the destination port of a SYN containing an MP_JOIN option SHOULD be the same as the remote port of the first subflow in the connection. The local port for such SYNs SHOULD also be the same as for the first subflow (and as such, an implementation SHOULD reserve ephemeral ports across all local IP addresses), although there may be cases where this is infeasible. This strategy is intended to maximize the probability of the SYN being permitted by a firewall or NAT at the recipient and to avoid confusing any network monitoring software.
通常の操作では、MPTCP実装は、すでに使用されているのと同じポートを使用する必要があります（SHOULD）。つまり、MP_JOINオプションを含むSYNの宛先ポートは、接続の最初のサブフローのリモートポートと同じである必要があります（SHOULD）。そのようなSYNのローカルポートも最初のサブフローと同じである必要があります（したがって、実装はすべてのローカルIPアドレスにまたがる一時的なポートを予約する必要があります）。ただし、これが実行できない場合もあります。この戦略は、SYNが受信側でファイアウォールまたはNATによって許可される確率を最大化し、ネットワーク監視ソフトウェアの混乱を避けることを目的としています。
There may also be cases, however, where the passive opener wishes to signal to the other host that a specific port should be used, and this facility is provided in the Add Address option as documented in Section 3.4.1. It is therefore feasible to allow multiple subflows between the same two addresses but using different port pairs, and such a facility could be used to allow load balancing within the network based on 5-tuples (e.g., some ECMP implementations [7]).
ただし、パッシブオープナーが特定のポートを使用する必要があることを他のホストに通知したい場合もあり、この機能はセクション3.4.1に記載されている[アドレスの追加]オプションで提供されます。したがって、同じ2つのアドレス間で異なるポートペアを使用して複数のサブフローを許可することは可能であり、そのような機能を使用して、5タプルに基づくネットワーク内のロードバランシングを許可できます（たとえば、一部のECMP実装[7]）。
Many TCP connections are short-lived and consist only of a few segments, and so the overheads of using MPTCP outweigh any benefits. A heuristic is required, therefore, to decide when to start using additional subflows in an MPTCP connection. We expect that experience gathered from deployments will provide further guidance on this, and will be affected by particular application characteristics (which are likely to change over time). However, a suggested general-purpose heuristic that an implementation MAY choose to employ is as follows. Results from experimental deployments are needed in order to verify the correctness of this proposal.
多くのTCP接続は存続期間が短く、数個のセグメントのみで構成されているため、MPTCPを使用することによるオーバーヘッドは、利点よりも重要です。したがって、MPTCP接続で追加のサブフローの使用をいつ開始するかを決定するには、ヒューリスティックが必要です。展開から収集された経験がこれに関するさらなるガイダンスを提供し、特定のアプリケーション特性（時間の経過とともに変化する可能性が高い）の影響を受けることが予想されます。しかしながら、実装が採用することを選択するかもしれない提案された汎用ヒューリスティックは以下の通りです。この提案の正確性を検証するには、実験的展開の結果が必要です。
If a host has data buffered for its peer (which implies that the application has received a request for data), the host opens one subflow for each initial window's worth of data that is buffered.
ホストがピア用にバッファーされたデータを持っている場合（これは、アプリケーションがデータの要求を受け取ったことを意味します）、ホストは、バッファーされた初期ウィンドウのデータごとに1つのサブフローを開きます。
Consideration should also be given to limiting the rate of adding new subflows, as well as limiting the total number of subflows open for a particular connection. A host may choose to vary these values based on its load or knowledge of traffic and path characteristics.
新しいサブフローを追加する速度を制限すること、および特定の接続に対して開いているサブフローの総数を制限することも考慮する必要があります。ホストは、負荷またはトラフィックとパスの特性に関する知識に基づいて、これらの値を変更することを選択できます。
Note that this heuristic alone is probably insufficient. Traffic for many common applications, such as downloads, is highly asymmetric and the host that is multihomed may well be the client that will never fill its buffers, and thus never use MPTCP. Advanced APIs that allow an application to signal its traffic requirements would aid in these decisions.
このヒューリスティックだけではおそらく不十分であることに注意してください。ダウンロードなど、多くの一般的なアプリケーションのトラフィックは非常に非対称であり、マルチホームのホストは、バッファーを一杯にしないクライアントであり、MPTCPを使用しない可能性があります。アプリケーションがトラフィック要件を通知できる高度なAPIは、これらの決定に役立ちます。
An additional time-based heuristic could be applied, opening additional subflows after a given period of time has passed. This would alleviate the above issue, and also provide resilience for low-bandwidth but long-lived applications.
追加の時間ベースのヒューリスティックを適用して、一定期間が経過した後に追加のサブフローを開くことができます。これにより、上記の問題が軽減され、低帯域幅で長寿命のアプリケーションに回復力が提供されます。
This section has shown some of the considerations that an implementer should give when developing MPTCP heuristics, but is not intended to be prescriptive.
このセクションでは、MPTCPヒューリスティックを開発するときに実装者が行う必要があるいくつかの考慮事項を示しましたが、規範となることを意図したものではありません。
Requirements for MPTCP's handling of unexpected signals have been given in Section 3.7. There are other failure cases, however, where a hosts can choose appropriate behavior.
MPTCPが予期しないシグナルを処理するための要件は、セクション3.7に記載されています。ただし、ホストが適切な動作を選択できる他の障害ケースもあります。
For example, Section 3.1 suggests that a host SHOULD fall back to trying regular TCP SYNs after one or more failures of MPTCP SYNs for a connection. A host may keep a system-wide cache of such information, so that it can back off from using MPTCP, firstly for that particular destination host, and eventually on a whole interface, if MPTCP connections continue failing.
たとえば、セクション3.1では、接続のMPTCP SYNで1つ以上の障害が発生した後、ホストは通常のTCP SYNを試すようにフォールバックする必要があることを示唆しています。ホストは、そのような情報のシステム全体のキャッシュを保持できるため、最初に特定の宛先ホストに対してMPTCPの使用をバックオフし、MPTCP接続が引き続き失敗する場合は最終的にインターフェイス全体でバックオフできます。
Another failure could occur when the MP_JOIN handshake fails. Section 3.7 specifies that an incorrect handshake MUST lead to the subflow being closed with a RST. A host operating an active intrusion detection system may choose to start blocking MP_JOIN packets from the source host if multiple failed MP_JOIN attempts are seen. From the connection initiator's point of view, if an MP_JOIN fails, it SHOULD NOT attempt to connect to the same IP address and port during the lifetime of the connection, unless the other host refreshes the information with another ADD_ADDR option. Note that the ADD_ADDR option is informational only, and does not guarantee the other host will attempt a connection.
MP_JOINハンドシェイクが失敗すると、別の障害が発生する可能性があります。セクション3.7では、不適切なハンドシェイクによってサブフローがRSTで閉じられる必要があることを明記しています。アクティブな侵入検知システムを運用しているホストは、MP_JOINの試行が複数回失敗した場合、送信元ホストからのMP_JOINパケットのブロックを開始することを選択できます。接続イニシエーターの観点から見ると、MP_JOINが失敗した場合、他のホストが別のADD_ADDRオプションで情報を更新しない限り、接続の存続期間中に同じIPアドレスとポートへの接続を試みるべきではありません（SHOULD NOT）。 ADD_ADDRオプションは情報提供のみを目的としており、他のホストが接続を試行することを保証するものではないことに注意してください。
In addition, an implementation may learn, over a number of connections, that certain interfaces or destination addresses consistently fail and may default to not trying to use MPTCP for these. Behavior could also be learned for particularly badly performing subflows or subflows that regularly fail during use, in order to temporarily choose not to use these paths.
さらに、実装は、特定のインターフェイスまたは宛先アドレスが一貫して失敗し、デフォルトでこれらにMPTCPを使用しないことを、多くの接続にわたって学習する場合があります。これらのパスを使用しないように一時的に選択するために、動作が定期的に失敗する、特にパフォーマンスの悪いサブフローまたはサブフローの動作を学習することもできます。
In order to support multipath operation, the semantics of some TCP components have changed. To aid clarity, this section collects these semantic changes as a reference.
マルチパス操作をサポートするために、一部のTCPコンポーネントのセマンティクスが変更されました。わかりやすくするために、このセクションでは、これらのセマンティックの変更を参照として収集します。
Sequence number: The (in-header) TCP sequence number is specific to the subflow. To allow the receiver to reorder application data, an additional data-level sequence space is used. In this data-level sequence space, the initial SYN and the final DATA_FIN occupy 1 octet of sequence space. There is an explicit mapping of data sequence space to subflow sequence space, which is signaled through TCP options in data packets.
シーケンス番号：（ヘッダー内の）TCPシーケンス番号は、サブフローに固有です。レシーバーがアプリケーションデータを並べ替えられるようにするには、追加のデータレベルのシーケンススペースが使用されます。このデータレベルのシーケンススペースでは、最初のSYNと最後のDATA_FINが1オクテットのシーケンススペースを占めます。データシーケンススペースからサブフローシーケンススペースへの明示的なマッピングがあり、データパケットのTCPオプションを通じて通知されます。
ACK: The ACK field in the TCP header acknowledges only the subflow sequence number, not the data-level sequence space. Implementations SHOULD NOT attempt to infer a data-level acknowledgment from the subflow ACKs. This separates subflow- and connection-level processing at an end host.
ACK：TCPヘッダーのACKフィールドは、データレベルのシーケンススペースではなく、サブフローシーケンス番号のみを確認します。実装では、サブフローACKからデータレベルの確認応答を推測しようとしないでください。これにより、エンドホストでサブフローレベルと接続レベルの処理が分離されます。
Duplicate ACK: A duplicate ACK that includes any MPTCP signaling (with the exception of the DSS option) MUST NOT be treated as a signal of congestion. To limit the chances of non-MPTCP-aware entities mistakenly interpreting duplicate ACKs as a signal of congestion, MPTCP SHOULD NOT send more than two duplicate ACKs containing (non-DSS) MPTCP signals in a row.
重複ACK：MPDSシグナリング（DSSオプションを除く）を含む重複ACKは、輻輳の信号として扱われてはなりません（MUST NOT）。非MPTCP対応エンティティが重複ACKを混雑の信号として誤って解釈する可能性を制限するために、MPTCPは、（非DSS）MPTCP信号を含む2つ以上の重複ACKを続けて送信しないでください。
Receive Window: The receive window in the TCP header indicates the amount of free buffer space for the whole data-level connection (as opposed to for this subflow) that is available at the receiver. This is the same semantics as regular TCP, but to maintain these semantics the receive window must be interpreted at the sender as relative to the sequence number given in the DATA_ACK rather than the subflow ACK in the TCP header. In this way, the original flow control role is preserved. Note that some middleboxes may change the receive window, and so a host SHOULD use the maximum value of those recently seen on the constituent subflows for the connection-level receive window, and also needs to maintain a subflow-level window for subflow-level processing.
受信ウィンドウ：TCPヘッダーの受信ウィンドウは、受信側で使用可能な（このサブフローではなく）データレベル接続全体の空きバッファー領域の量を示します。これは通常のTCPと同じセマンティクスですが、これらのセマンティクスを維持するには、受信ウィンドウをTCPヘッダーのサブフローACKではなく、DATA_ACKで指定されたシーケンス番号に関連して送信側で解釈する必要があります。このようにして、元のフロー制御の役割が保持されます。一部のミドルボックスは受信ウィンドウを変更する可能性があるため、ホストは、接続レベルの受信ウィンドウの構成サブフローで最近確認された最大値を使用する必要があり、サブフローレベルの処理のためにサブフローレベルのウィンドウを維持する必要があることに注意してください。 。
FIN: The FIN flag in the TCP header applies only to the subflow it is sent on, not to the whole connection. For connection-level FIN semantics, the DATA_FIN option is used.
FIN：TCPヘッダーのFINフラグは、それが送信されるサブフローにのみ適用され、接続全体には適用されません。接続レベルのFINセマンティクスの場合、DATA_FINオプションが使用されます。
RST: The RST flag in the TCP header applies only to the subflow it is sent on, not to the whole connection. The MP_FASTCLOSE option provides the fast close functionality of a RST at the MPTCP connection level.
RST：TCPヘッダーのRSTフラグは、送信されたサブフローにのみ適用され、接続全体には適用されません。 MP_FASTCLOSEオプションは、MPTCP接続レベルでのRSTの高速クローズ機能を提供します。
Address List: Address list management (i.e., knowledge of the local and remote hosts' lists of available IP addresses) is handled on a per-connection basis (as opposed to per subflow, per host, or per pair of communicating hosts). This permits the application of per-connection local policy. Adding an address to one connection (either explicitly through an Add Address message, or implicitly through a Join) has no implication for other connections between the same pair of hosts.
アドレスリスト：アドレスリスト管理（つまり、ローカルおよびリモートホストの利用可能なIPアドレスのリストに関する知識）は、接続ごとに（サブフローごと、ホストごと、または通信するホストのペアごとではなく）処理されます。これにより、接続ごとのローカルポリシーを適用できます。 1つの接続にアドレスを追加する（アドレスの追加メッセージを介して明示的に、または結合を介して暗黙的に）と、同じホストのペア間の他の接続には影響しません。
5-tuple: The 5-tuple (protocol, local address, local port, remote address, remote port) presented by kernel APIs to the application layer in a non-multipath-aware application is that of the first subflow, even if the subflow has since been closed and removed from the connection. This decision, and other related API issues, are discussed in more detail in [6].
5タプル：カーネルAPIによって非マルチパス対応アプリケーションのアプリケーションレイヤーに提示される5タプル（プロトコル、ローカルアドレス、ローカルポート、リモートアドレス、リモートポート）は、サブフローであっても、最初のサブフローのものです。その後、閉じられ、接続から削除されました。この決定、およびその他の関連するAPIの問題については、[6]で詳しく説明しています。
As identified in [9], the addition of multipath capability to TCP will bring with it a number of new classes of threat. In order to prevent these, [2] presents a set of requirements for a security solution for MPTCP. The fundamental goal is for the security of MPTCP to be "no worse" than regular TCP today, and the key security requirements are:
[9]で確認されているように、TCPにマルチパス機能を追加すると、TCPにいくつかの新しいクラスの脅威がもたらされます。これらを防ぐために、[2]はMPTCPのセキュリティソリューションに対する一連の要件を示しています。基本的な目標は、MPTCPのセキュリティが今日の通常のTCPより「悪くない」ことであり、主要なセキュリティ要件は次のとおりです。
o Provide a mechanism to confirm that the parties in a subflow handshake are the same as in the original connection setup.
o サブフローハンドシェイクの関係者が元の接続設定と同じであることを確認するメカニズムを提供します。
o Provide verification that the peer can receive traffic at a new address before using it as part of a connection.
o ピアが接続の一部として使用する前に、ピアが新しいアドレスでトラフィックを受信できることを確認してください。
o Provide replay protection, i.e., ensure that a request to add/ remove a subflow is 'fresh'.
o リプレイ保護を提供します。つまり、サブフローを追加/削除するリクエストが「新鮮」であることを確認します。
In order to achieve these goals, MPTCP includes a hash-based handshake algorithm documented in Sections 3.1 and 3.2.
これらの目標を達成するために、MPTCPには、セクション3.1および3.2で説明されているハッシュベースのハンドシェイクアルゴリズムが含まれています。
The security of the MPTCP connection hangs on the use of keys that are shared once at the start of the first subflow, and are never sent again over the network (unless used in the fast close mechanism, Section 3.5). To ease demultiplexing while not giving away any cryptographic material, future subflows use a truncated cryptographic hash of this key as the connection identification "token". The keys are concatenated and used as keys for creating Hash-based Message Authentication Codes (HMACs) used on subflow setup, in order to verify that the parties in the handshake are the same as in the original connection setup. It also provides verification that the peer can receive traffic at this new address. Replay attacks would still be possible when only keys are used; therefore, the handshakes use single-use random numbers (nonces) at both ends -- this ensures the HMAC will never be the same on two handshakes. Guidance on generating random numbers suitable for use as keys is given in [14] and discussed in Section 3.1.
MPTCP接続のセキュリティは、最初のサブフローの開始時に一度共有され、ネットワークを介して再度送信されることのないキーを使用するとハングします（高速クローズメカニズムで使用しない限り、セクション3.5）。暗号化素材を提供せずに逆多重化を容易にするために、将来のサブフローでは、このキーの切り捨てられた暗号化ハッシュを接続識別「トークン」として使用します。キーは連結され、ハンドシェイクのパーティが元の接続セットアップと同じであることを確認するために、サブフローセットアップで使用されるハッシュベースのメッセージ認証コード（HMAC）を作成するためのキーとして使用されます。また、ピアがこの新しいアドレスでトラフィックを受信できることを確認します。キーのみを使用した場合でも、リプレイ攻撃は可能です。したがって、ハンドシェイクは両端で使い捨ての乱数（ノンス）を使用します。これにより、HMACが2つのハンドシェイクで同じになることはありません。キーとしての使用に適した乱数の生成に関するガイダンスは、[14]に記載されており、セクション3.1で説明されています。
The use of crypto capability bits in the initial connection handshake to negotiate use of a particular algorithm allows the deployment of additional crypto mechanisms in the future. Note that this would be susceptible to bid-down attacks only if the attacker was on-path (and thus would be able to modify the data anyway). The security mechanism presented in this document should therefore protect against all forms of flooding and hijacking attacks discussed in [9].
特定のアルゴリズムの使用をネゴシエートするための初期接続ハンドシェイクでの暗号機能ビットの使用により、将来的に追加の暗号メカニズムを導入できます。これは、攻撃者がパス上にいる場合にのみ（したがって、とにかくデータを変更できる場合）、ビッドダウン攻撃の影響を受けやすいことに注意してください。したがって、このドキュメントで説明するセキュリティメカニズムは、[9]で説明されているあらゆる形式のフラッディングおよびハイジャック攻撃から保護する必要があります。
During normal operation, regular TCP protection mechanisms (such as ensuring sequence numbers are in-window) will provide the same level of protection against attacks on individual TCP subflows as exists for regular TCP today. Implementations will introduce additional buffers compared to regular TCP, to reassemble data at the connection level. The application of window sizing will minimize the risk of denial-of-service attacks consuming resources.
通常の操作中、通常のTCP保護メカニズム（シーケンス番号がウィンドウ内にあることの確認など）は、現在の通常のTCPに存在するのと同じレベルの個々のTCPサブフローへの攻撃に対する保護を提供します。実装では、接続レベルでデータを再構成するために、通常のTCPと比較して追加のバッファーが導入されます。ウィンドウサイジングを適用すると、リソースを消費するサービス拒否攻撃のリスクを最小限に抑えることができます。
As discussed in Section 3.4.1, a host may advertise its private addresses, but these might point to different hosts in the receiver's network. The MP_JOIN handshake (Section 3.2) will ensure that this does not succeed in setting up a subflow to the incorrect host. However, it could still create unwanted TCP handshake traffic. This feature of MPTCP could be a target for denial-of-service exploits, with malicious participants in MPTCP connections encouraging the recipient to target other hosts in the network. Therefore, implementations should consider heuristics (Section 3.8) at both the sender and receiver to reduce the impact of this.
セクション3.4.1で説明したように、ホストはプライベートアドレスをアドバタイズできますが、これらはレシーバのネットワーク内の別のホストをポイントしている場合があります。 MP_JOINハンドシェイク（セクション3.2）は、これが正しくないホストへのサブフローの設定に成功しないことを保証します。ただし、それでも不要なTCPハンドシェイクトラフィックが作成される可能性があります。 MPTCPのこの機能は、サービス拒否攻撃の標的になる可能性があり、MPTCP接続の悪意のある参加者は、受信者にネットワーク内の他のホストを標的にするように仕向けます。したがって、実装では、この影響を減らすために、送信側と受信側の両方でヒューリスティック（セクション3.8）を検討する必要があります。
A small security risk could theoretically exist with key reuse, but in order to accomplish a replay attack, both the sender and receiver keys, and the sender and receiver random numbers, in the MP_JOIN handshake (Section 3.2) would have to match.
理論的にはキーの再利用には小さなセキュリティリスクが存在する可能性がありますが、リプレイアタックを実行するには、MP_JOINハンドシェイク（セクション3.2）で送信者と受信者のキー、および送信者と受信者の乱数の両方が一致する必要があります。
Whilst this specification defines a "medium" security solution, meeting the criteria specified at the start of this section and the threat analysis ([9]), since attacks only ever get worse, it is likely that a future Standards Track version of MPTCP would need to be able to support stronger security. There are several ways the security of MPTCP could potentially be improved; some of these would be compatible with MPTCP as defined in this document, whilst others may not be. For now, the best approach is to get experience with the current approach, establish what might work, and check that the threat analysis is still accurate.
この仕様は「中」のセキュリティソリューションを定義し、このセクションの冒頭で指定された基準と脅威分析（[9]）を満たしていますが、攻撃は悪化するだけなので、MPTCPの将来のスタンダードトラックバージョンではより強力なセキュリティをサポートできる必要があります。 MPTCPのセキュリティを向上させる方法はいくつかあります。これらの一部は、このドキュメントで定義されているようにMPTCPと互換性がありますが、そうでない場合もあります。現在のところ、最善のアプローチは、現在のアプローチの経験を得て、何が機能するかを確認し、脅威分析が依然として正確であることを確認することです。
Possible ways of improving MPTCP security could include:
MPTCPセキュリティを改善するための可能な方法には、次のものがあります。
o defining a new MPCTP cryptographic algorithm, as negotiated in MP_CAPABLE. A sub-case could be to include an additional deployment assumption, such as stateful servers, in order to allow a more powerful algorithm to be used.
o MP_CAPABLEでネゴシエートされた新しいMPCTP暗号アルゴリズムを定義します。サブケースは、より強力なアルゴリズムを使用できるようにするために、ステートフルサーバーなどの追加の展開の想定を含めることです。
o defining how to secure data transfer with MPTCP, whilst not changing the signaling part of the protocol.
o プロトコルのシグナリング部分を変更せずに、MPTCPでデータ転送を保護する方法を定義します。
o defining security that requires more option space, perhaps in conjunction with a "long options" proposal for extending the TCP options space (such as those surveyed in [20]), or perhaps building on the current approach with a second stage of MPTCP-option-based security.
o より多くのオプションスペースを必要とするセキュリティを定義し、おそらくTCPオプションスペースを拡張するための「長いオプション」の提案（[20]で調査したものなど）と組み合わせて、またはおそらくMPTCPオプションの第2ステージで現在のアプローチを構築ベースのセキュリティ。
o revisiting the working group's decision to exclusively use TCP options for MPTCP signaling, and instead look at also making use of the TCP payloads.
o MPTCPシグナリングにTCPオプションのみを使用するというワーキンググループの決定を再検討し、代わりにTCPペイロードを利用することも検討してください。
MPTCP has been designed with several methods available to indicate a new security mechanism, including:
MPTCPは、次のような新しいセキュリティメカニズムを示すために利用できるいくつかの方法で設計されています。
o available flags in MP_CAPABLE (Figure 4);
o MP_CAPABLE（図4）で使用可能なフラグ。
o available subtypes in the MPTCP option (Figure 3);
o MPTCPオプションで使用可能なサブタイプ（図3）。
o the version field in MP_CAPABLE (Figure 4);
o MP_CAPABLEのバージョンフィールド（図4）。
Multipath TCP was designed to be deployable in the present world. Its design takes into account "reasonable" existing middlebox behavior. In this section, we outline a few representative middlebox-related failure scenarios and show how Multipath TCP handles them. Next, we list the design decisions multipath has made to accommodate the different middleboxes.
マルチパスTCPは、現在の世界で展開できるように設計されています。その設計では、「合理的な」既存のミドルボックスの動作が考慮されています。このセクションでは、いくつかの代表的なミドルボックス関連の障害シナリオを概説し、マルチパスTCPがそれらを処理する方法を示します。次に、さまざまなミドルボックスに対応するためにマルチパスが行った設計上の決定をリストします。
A primary concern is our use of a new TCP option. Middleboxes should forward packets with unknown options unchanged, yet there are some that don't. These we expect will either strip options and pass the data, drop packets with new options, copy the same option into multiple segments (e.g., when doing segmentation), or drop options during segment coalescing.
主な懸念事項は、新しいTCPオプションの使用です。ミドルボックスは不明なオプションが変更されていないパケットを転送する必要がありますが、そうでないものもあります。これらは、オプションを取り除いてデータを渡すか、新しいオプションでパケットをドロップするか、同じオプションを複数のセグメントにコピーするか（たとえば、セグメンテーションを行う場合）、またはセグメントの結合中にオプションをドロップします。
MPTCP uses a single new TCP option "Kind", and all message types are defined by "subtype" values (see Section 8). This should reduce the chances of only some types of MPTCP options being passed, and instead the key differing characteristics are different paths, and the presence of the SYN flag.
MPTCPは単一の新しいTCPオプション「種類」を使用し、すべてのメッセージタイプは「サブタイプ」の値によって定義されます（セクション8を参照）。これにより、一部のタイプのMPTCPオプションのみが渡される可能性が減ります。代わりに、主要な異なる特性はパスが異なり、SYNフラグが存在します。
MPTCP SYN packets on the first subflow of a connection contain the MP_CAPABLE option (Section 3.1). If this is dropped, MPTCP SHOULD fall back to regular TCP. If packets with the MP_JOIN option (Section 3.2) are dropped, the paths will simply not be used.
接続の最初のサブフローのMPTCP SYNパケットには、MP_CAPABLEオプションが含まれています（セクション3.1）。これがドロップされた場合、MPTCPは通常のTCPにフォールバックする必要があります（SHOULD）。 MP_JOINオプション（セクション3.2）を含むパケットがドロップされた場合、パスは単に使用されません。
If a middlebox strips options but otherwise passes the packets unchanged, MPTCP will behave safely. If an MP_CAPABLE option is dropped on either the outgoing or the return path, the initiating host can fall back to regular TCP, as illustrated in Figure 16 and discussed in Section 3.1.
ミドルボックスがオプションを削除しても、パケットを変更せずに渡す場合、MPTCPは安全に動作します。 MP_CAPABLEオプションが発信パスまたは戻りパスのいずれかにドロップされた場合、図16に示され、セクション3.1で説明されているように、開始ホストは通常のTCPにフォールバックできます。
Subflow SYNs contain the MP_JOIN option. If this option is stripped on the outgoing path, the SYN will appear to be a regular SYN to Host B. Depending on whether there is a listening socket on the target port, Host B will reply either with SYN/ACK or RST (subflow connection fails). When Host A receives the SYN/ACK it sends a RST because the SYN/ACK does not contain the MP_JOIN option and its token. Either way, the subflow setup fails, but otherwise does not affect the MPTCP connection as a whole.
サブフローSYNには、MP_JOINオプションが含まれています。このオプションが発信パスで削除される場合、SYNはホストBへの通常のSYNであるように見えます。ターゲットポートにリスニングソケットがあるかどうかに応じて、ホストBはSYN / ACKまたはRST（サブフロー接続）で応答します失敗します）。ホストAがSYN / ACKを受信すると、SYN / ACKにMP_JOINオプションとそのトークンが含まれていないため、RSTを送信します。どちらの方法でも、サブフローのセットアップは失敗しますが、それ以外の場合はMPTCP接続全体には影響しません。
Host A Host B
| Middlebox M |
| | |
| SYN(MP_CAPABLE) | SYN |
|-------------------|---------------->|
| SYN/ACK |
|<------------------------------------|
a) MP_CAPABLE option stripped on outgoing path
Host A Host B
| SYN(MP_CAPABLE) |
|------------------------------------>|
| Middlebox M |
| | |
| SYN/ACK |SYN/ACK(MP_CAPABLE)|
|<----------------|-------------------|
b) MP_CAPABLE option stripped on return path
Figure 16: Connection Setup with Middleboxes that Strip Options from Packets
図16：パケットからオプションを取り除くミドルボックスを使用した接続設定
We now examine data flow with MPTCP, assuming the flow is correctly set up, which implies the options in the SYN packets were allowed through by the relevant middleboxes. If options are allowed through and there is no resegmentation or coalescing to TCP segments, Multipath TCP flows can proceed without problems.
フローが正しく設定されていると仮定して、MPTCPでデータフローを調べます。これは、SYNパケットのオプションが関連するミドルボックスによって許可されたことを意味します。オプションの通過が許可されており、TCPセグメントへの再分割または合体がない場合、マルチパスTCPフローは問題なく続行できます。
The case when options get stripped on data packets has been discussed in the Fallback section. If a fraction of options are stripped, behavior is not deterministic. If some data sequence mappings are lost, the connection can continue so long as mappings exist for the subflow-level data (e.g., if multiple maps have been sent that reinforce each other). If some subflow-level space is left unmapped, however, the subflow is treated as broken and is closed, through the process described in Section 3.6. MPTCP should survive with a loss of some Data ACKs, but performance will degrade as the fraction of stripped options increases. We do not expect such cases to appear in practice, though: most middleboxes will either strip all options or let them all through.
オプションがデータパケットで削除されるケースについては、「フォールバック」セクションで説明しました。オプションの一部が取り除かれた場合、動作は確定的ではありません。一部のデータシーケンスマッピングが失われた場合、サブフローレベルのデータのマッピングが存在する限り、接続は継続できます（たとえば、互いに補強する複数のマップが送信されている場合）。ただし、サブフローレベルのスペースがマップされていないままの場合、サブフローは壊れているものとして扱われ、セクション3.6で説明されているプロセスを通じて閉じられます。 MPTCPは一部のデータACKが失われても存続しますが、除去されたオプションの割合が増えるとパフォーマンスが低下します。ただし、このようなケースが実際に発生するとは想定されていません。ほとんどのミドルボックスでは、すべてのオプションが削除されるか、すべてが通過します。
We end this section with a list of middlebox classes, their behavior, and the elements in the MPTCP design that allow operation through such middleboxes. Issues surrounding dropping packets with options or stripping options were discussed above, and are not included here:
このセクションの最後に、ミドルボックスクラス、それらの動作、およびそのようなミドルボックスを介した操作を可能にするMPTCP設計の要素のリストを示します。オプション付きのパケットのドロップまたはオプションのストリッピングに関する問題は上記で説明されており、ここには含まれていません。
o NATs [21] (Network Address (and Port) Translators) change the source address (and often source port) of packets. This means that a host will not know its public-facing address for signaling in MPTCP. Therefore, MPTCP permits implicit address addition via the MP_JOIN option, and the handshake mechanism ensures that connection attempts to private addresses [18] do not cause problems. Explicit address removal is undertaken by an Address ID to allow no knowledge of the source address.
o NAT [21]（ネットワークアドレス（およびポート）トランスレータ）は、パケットの送信元アドレス（および多くの場合、送信元ポート）を変更します。これは、ホストがMPTCPでのシグナリング用の公開アドレスを知らないことを意味します。したがって、MPTCPはMP_JOINオプションを介した暗黙のアドレス追加を許可し、ハンドシェイクメカニズムはプライベートアドレスへの接続試行[18]が問題を引き起こさないことを保証します。送信元アドレスを認識できないようにするために、アドレスIDによって明示的なアドレス削除が行われます。
o Performance Enhancing Proxies (PEPs) [22] might proactively ACK data to increase performance. MPTCP, however, relies on accurate congestion control signals from the end host, and non-MPTCP-aware PEPs will not be able to provide such signals. MPTCP will, therefore, fall back to single-path TCP, or close the problematic subflow (see Section 3.6).
o Performance Enhancing Proxies（PEP）[22]は、データを積極的にACKしてパフォーマンスを向上させます。ただし、MPTCPはエンドホストからの正確な輻輳制御信号に依存しており、MPTCP非対応のPEPはそのような信号を提供できません。したがって、MPTCPはシングルパスTCPにフォールバックするか、問題のあるサブフローを閉じます（セクション3.6を参照）。
o Traffic Normalizers [23] may not allow holes in sequence numbers, and may cache packets and retransmit the same data. MPTCP looks like standard TCP on the wire, and will not retransmit different data on the same subflow sequence number. In the event of a retransmission, the same data will be retransmitted on the original TCP subflow even if it is additionally retransmitted at the connection level on a different subflow.
o トラフィックノーマライザ[23]はシーケンス番号のホールを許可しない場合があり、パケットをキャッシュして同じデータを再送信する場合があります。 MPTCPは、標準のTCPのように見え、同じサブフローシーケンス番号で異なるデータを再送信しません。再送信が発生した場合、同じデータは、別のサブフローの接続レベルでさらに再送信されても、元のTCPサブフローで再送信されます。
o Firewalls [24] might perform initial sequence number randomization on TCP connections. MPTCP uses relative sequence numbers in data sequence mapping to cope with this. Like NATs, firewalls will not permit many incoming connections, so MPTCP supports address signaling (ADD_ADDR) so that a multiaddressed host can invite its peer behind the firewall/NAT to connect out to its additional interface.
o ファイアウォール[24]は、TCP接続で初期シーケンス番号のランダム化を実行する場合があります。 MPTCPは、データシーケンスマッピングで相対シーケンス番号を使用してこれに対処します。 NATと同様に、ファイアウォールは多くの着信接続を許可しないため、MPTCPはアドレスシグナリング（ADD_ADDR）をサポートしているため、マルチアドレスのホストは、ファイアウォール/ NATの背後にあるピアを招待して、追加のインターフェイスに接続できます。
o Intrusion Detection Systems look out for traffic patterns and content that could threaten a network. Multipath will mean that such data is potentially spread, so it is more difficult for an IDS to analyze the whole traffic, and potentially increases the risk of false positives. However, for an MPTCP-aware IDS, tokens can be read by such systems to correlate multiple subflows and reassemble for analysis.
o 侵入検知システムは、ネットワークを脅かす可能性のあるトラフィックパターンとコンテンツを探します。マルチパスは、そのようなデータが拡散する可能性があることを意味するため、IDSがトラフィック全体を分析することがより困難になり、誤検知のリスクが増加する可能性があります。ただし、MPTCP対応IDSの場合、このようなシステムはトークンを読み取って、複数のサブフローを関連付け、分析のために再構成できます。
o Application-level middleboxes such as content-aware firewalls may alter the payload within a subflow, such as rewriting URIs in HTTP traffic. MPTCP will detect these using the checksum and close the affected subflow(s), if there are other subflows that can be used. If all subflows are affected, multipath will fall back to TCP, allowing such middleboxes to change the payload. MPTCP-aware middleboxes should be able to adjust the payload and MPTCP metadata in order not to break the connection.
o コンテンツ対応ファイアウォールなどのアプリケーションレベルのミドルボックスは、HTTPトラフィックのURIの書き換えなど、サブフロー内のペイロードを変更する可能性があります。 MPTCPは、使用できる他のサブフローがある場合、チェックサムを使用してこれらを検出し、影響を受けるサブフローを閉じます。すべてのサブフローが影響を受ける場合、マルチパスはTCPにフォールバックし、そのようなミドルボックスがペイロードを変更できるようにします。 MPTCP対応ミドルボックスは、接続を切断しないように、ペイロードとMPTCPメタデータを調整できる必要があります。
In addition, all classes of middleboxes may affect TCP traffic in the following ways:
さらに、ミドルボックスのすべてのクラスは、次のようにTCPトラフィックに影響を与える可能性があります。
o TCP options may be removed, or packets with unknown options dropped, by many classes of middleboxes. It is intended that the initial SYN exchange, with a TCP option, will be sufficient to identify the path capabilities. If such a packet does not get through, MPTCP will end up falling back to regular TCP.
o ミドルボックスの多くのクラスによって、TCPオプションが削除されるか、不明なオプションを持つパケットが削除される場合があります。これは、TCPオプションを使用した最初のSYN交換で、パス機能を特定するのに十分であることを意図しています。そのようなパケットが通過しない場合、MPTCPは通常のTCPにフォールバックします。
o Segmentation/Coalescing (e.g., TCP segmentation offloading) might copy options between packets and might strip some options. MPTCP's data sequence mapping includes the relative subflow sequence number instead of using the sequence number in the segment. In this way, the mapping is independent of the packets that carry it.
o セグメンテーション/結合（TCPセグメンテーションオフロードなど）により、パケット間でオプションがコピーされ、一部のオプションが削除される場合があります。 MPTCPのデータシーケンスマッピングには、セグメント内のシーケンス番号を使用する代わりに、相対サブフローシーケンス番号が含まれます。このように、マッピングはそれを運ぶパケットから独立しています。
o The receive window may be shrunk by some middleboxes at the subflow level. MPTCP will use the maximum window at data level, but will also obey subflow-specific windows.
o 受信ウィンドウは、一部のミドルボックスによってサブフローレベルで縮小される場合があります。 MPTCPはデータレベルで最大ウィンドウを使用しますが、サブフロー固有のウィンドウにも従います。
The authors were originally supported by Trilogy (http://www.trilogy-project.org), a research project (ICT-216372) partially funded by the European Community under its Seventh Framework Program.
著者はもともと、第7回フレームワークプログラムに基づいて欧州共同体によって部分的に資金提供された研究プロジェクト（ICT-216372）であるTrilogy（http://www.trilogy-project.org）によってサポートされていました。
Alan Ford was originally supported by Roke Manor Research.
Alan Fordは、もともとRoke Manor Researchによってサポートされていました。
The authors gratefully acknowledge significant input into this document from Sebastien Barre, Christoph Paasch, and Andrew McDonald.
著者は、セバスチャン・バレ、クリストフ・パーシュ、およびアンドリュー・マクドナルドからのこの文書への重要な情報に感謝します。
The authors also wish to acknowledge reviews and contributions from Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock, Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo, Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing, Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks, Sean Turner, Stephen Farrell, and Martin Stiemerling.
著者はまた、Iljitsch van Beijnum、Lars Eggert、Marcelo Bagnulo、Robert Hancock、Pasi Sarolahti、Toby Moncaster、Philip Eardley、Sergio Lembo、Lawrence Conroy、Yoshifumi Nishida、Bob Briscoe、Stein Gjesoring、Andrew McGregからのレビューと貢献を認めたいジョージハンペル、アヌミタビスワス、ウェスエディ、アレクセイメルニコフ、フランシスデュポン、エイドリアンファレル、バリーレイバ、ロバートスパークス、ショーンターナー、スティーブンファレル、マーティンスティーマーリング。
This document defines a new TCP option for MPTCP, assigned a value of 30 (decimal) from the TCP option space. This value is the value of "Kind" as seen in all MPTCP options in this document. This value is defined as:
このドキュメントでは、TCPオプションスペースから30（10進数）の値が割り当てられたMPTCPの新しいTCPオプションを定義します。この値は、このドキュメントのすべてのMPTCPオプションに見られる「種類」の値です。この値は次のように定義されます。
+------+--------+-----------------------+-----------+
| Kind | Length | Meaning | Reference |
+------+--------+-----------------------+-----------+
| 30 | N | Multipath TCP (MPTCP) | RFC 6824 |
+------+--------+-----------------------+-----------+
Table 1: TCP Option Kind Numbers
表1：TCPオプションの種類番号
This document also defines a 4-bit subtype field, for which IANA has created and will maintain a new sub-registry entitled "MPTCP Option Subtypes" under the "Transmission Control Protocol (TCP) Parameters" registry. Initial values for the MPTCP option subtype registry are given below; future assignments are to be defined by Standards Action as defined by [25]. Assignments consist of the MPTCP subtype's symbolic name and its associated value, as per the following table.
このドキュメントでは、4ビットのサブタイプフィールドも定義します。IANAは、「Transmission Control Protocol（TCP）Parameters」レジストリの下に「MPTCP Option Subtypes」という新しいサブレジストリを作成し、維持します。 MPTCPオプションサブタイプレジストリの初期値を以下に示します。将来の割り当ては、[25]で定義されているように、標準アクションによって定義されます。次の表に示すように、割り当てはMPTCPサブタイプの記号名とそれに関連付けられた値で構成されます。
+-------+--------------+----------------------------+---------------+
| Value | Symbol | Name | Reference |
+-------+--------------+----------------------------+---------------+
| 0x0 | MP_CAPABLE | Multipath Capable | Section 3.1 |
| 0x1 | MP_JOIN | Join Connection | Section 3.2 |
| 0x2 | DSS | Data Sequence Signal (Data | Section 3.3 |
| | | ACK and data sequence | |
| | | mapping) | |
| 0x3 | ADD_ADDR | Add Address | Section 3.4.1 |
| 0x4 | REMOVE_ADDR | Remove Address | Section 3.4.2 |
| 0x5 | MP_PRIO | Change Subflow Priority | Section 3.3.8 |
| 0x6 | MP_FAIL | Fallback | Section 3.6 |
| 0x7 | MP_FASTCLOSE | Fast Close | Section 3.5 |
+-------+--------------+----------------------------+---------------+
Table 2: MPTCP Option Subtypes
表2：MPTCPオプションのサブタイプ
Values 0x8 through 0xe are currently unassigned. The value 0xf is reserved for Private Use within controlled testbeds.
0x8から0xeまでの値は現在割り当てられていません。値0xfは、制御されたテストベッド内での私的使用のために予約されています。
IANA has created another sub-registry, "MPTCP Handshake Algorithms" under the "Transmission Control Protocol (TCP) Parameters" registry, based on the flags in MP_CAPABLE (Section 3.1). The flags consist of 8 bits, labeled "A" through "H", and this document assigns the bits as follows:
IANAは、MP_CAPABLE（セクション3.1）のフラグに基づいて、「Transmission Control Protocol（TCP）Parameters」レジストリの下に「MPTCP Handshake Algorithms」という別のサブレジストリを作成しました。フラグは「A」から「H」のラベルが付いた8ビットで構成され、このドキュメントでは次のようにビットを割り当てています。
+----------+-------------------+-----------------------+
| Flag Bit | Meaning | Reference |
+----------+-------------------+-----------------------+
| A | Checksum required | RFC 6824, Section 3.1 |
| B | Extensibility | RFC 6824, Section 3.1 |
| C-G | Unassigned | |
| H | HMAC-SHA1 | RFC 6824, Section 3.2 |
+----------+-------------------+-----------------------+
Table 3: MPTCP Handshake Algorithms
表3：MPTCPハンドシェイクアルゴリズム
Note that the meanings of bits C through H can be dependent upon bit B, depending on how Extensibility is defined in future specifications; see Section 3.1 for more information.
ビットCからHの意味は、拡張性が将来の仕様でどのように定義されるかに応じて、ビットBに依存する可能性があることに注意してください。詳細については、セクション3.1を参照してください。
Future assignments in this registry are also to be defined by Standards Action as defined by [25]. Assignments consist of the value of the flags, a symbolic name for the algorithm, and a reference to its specification.
このレジストリの将来の割り当ても、[25]で定義されているように、標準アクションによって定義されます。割り当ては、フラグの値、アルゴリズムのシンボル名、およびその仕様への参照で構成されます。
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[1] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[2] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.
[2] Ford、A.、Raiciu、C.、Handley、M.、Barre、S.、J。Iyengar、「Multipath TCP Development Architectural Guidelines」、RFC 6182、2011年3月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] National Institute of Science and Technology, "Secure Hash Standard", Federal Information Processing Standard (FIPS) 180-3, October 2008, <http://csrc.nist.gov/publications/ fips/fips180-3/fips180-3_final.pdf>.
[4] National Institute of Science and Technology、「Secure Hash Standard」、Federal Information Processing Standard（FIPS）180-3、2008年10月、<http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final。 pdf>。
[5] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, October 2011.
[5] Raiciu、C.、Handley、M。、およびD. Wischik、「マルチパストランスポートプロトコルの結合された輻輳制御」、RFC 6356、2011年10月。
[6] Scharf, M. and A. Ford, "MPTCP Application Interface Considerations", Work in Progress, October 2012.
[6] Scharf、M。、およびA. Ford、「MPTCP Application Interface考慮事項」、Work in Progress、2012年10月。
[7] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000.
[7] Hopps、C。、「Analysis of a Equal-Cost Multi-Path Algorithm」、RFC 2992、2000年11月。
[8] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., Duchene, F., Bonaventure, O., and M. Handley, "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP", Usenix Symposium on Networked Systems Design and Implementation 012, 2012, <https://www.usenix.org/conference/ nsdi12/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp>.
[8] Raiciu、C.、Paasch、C.、Barre、S.、Ford、A.、Honda、M.、Duchene、F.、Bonaventure、O。、およびM. Handley、「どれほど難しいか？設計および実装a Deployable Multipath TCP」、Usenix Symposium on Networked Systems Design and Implementation 012、2012、<https://www.usenix.org/conference/ nsdi12 / how-hard-can-it-be-designing-and-implementing-deployable -multipath-tcp>。
[9] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011.
[9] Bagnulo、M。、「複数のアドレスを使用したマルチパス操作のためのTCP拡張の脅威分析」、RFC 6181、2011年3月。
[10] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[10] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[11] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[11] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Acknowledgement Options」、RFC 2018、1996年10月。
[12] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[12] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、2009年9月。
[13] Gont, F., "Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations", Work in Progress, March 2012.
[13] Gont、F。、「伝送制御プロトコル（TCP）実装のためのセキュリティ強化方法の調査」、進行中の作業、2012年3月。
[14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[14] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[15] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[15] イーストレイクD.およびT.ハンセン、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、2011年5月。
[16] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[16] Jacobson、V.、Braden、B。、およびD. Borman、「高性能のTCP拡張機能」、RFC 1323、1992年5月。
[17] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[17] ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[18] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[18] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[19] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[19] ブレーデン、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[20] Ramaiah, A., "TCP option space extension", Work in Progress, March 2012.
[20] ラマイア、A。、「TCPオプションスペース拡張」、Work in Progress、2012年3月。
[21] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[21] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。
[22] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[22] Border、J.、Kojo、M.、Griner、J.、Montenegro、G.、and Z. Shelby、 "Performance Enhancing Proxies Intented to Mitiating Link-Related Degradations"、RFC 3135、2001年6月。
[23] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics", Usenix Security 2001, 2001, <http://www.usenix.org/events/sec01/full_papers/ handley/handley.pdf>.
[23] Handley、M.、Paxson、V。、およびC. Kreibich、「Network Intrusion Detection：Evasion、Traffic Normalization、and End-to-End Protocol Semantics」、Usenix Security 2001、2001、<http：//www.usenix。 org / events / sec01 / full_papers / handley / handley.pdf>。
[24] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[24] Freed、N。、「インターネットファイアウォールの動作と要件」、RFC 2979、2000年10月。
[25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[25] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
The TCP option space is limited due to the length of the Data Offset field in the TCP header (4 bits), which defines the TCP header length in 32-bit words. With the standard TCP header being 20 bytes, this leaves a maximum of 40 bytes for options, and many of these may already be used by options such as timestamp and SACK.
TCPヘッダーの長さを32ビットワードで定義するTCPヘッダーのデータオフセットフィールドの長さ（4ビット）により、TCPオプションスペースは制限されます。標準のTCPヘッダーが20バイトであるため、オプションには最大40バイトが残り、これらの多くは、タイムスタンプやSACKなどのオプションですでに使用されている可能性があります。
We have performed a brief study on the commonly used TCP options in SYN, data, and pure ACK packets, and found that there is enough room to fit all the options we propose using in this document.
SYN、データ、および純粋なACKパケットで一般的に使用されるTCPオプションについて簡単な調査を行ったところ、このドキュメントで使用するすべてのオプションに適合する十分な余地があることがわかりました。
SYN packets typically include Maximum Segment Size (MSS) (4 bytes), window scale (3 bytes), SACK permitted (2 bytes), and timestamp (10 bytes) options. Together these sum to 19 bytes. Some operating systems appear to pad each option up to a word boundary, thus using 24 bytes (a brief survey suggests Windows XP and Mac OS X do this, whereas Linux does not). Optimistically, therefore, we have 21 bytes spare, or 16 if it has to be word-aligned. In either case, however, the SYN versions of Multipath Capable (12 bytes) and Join (12 or 16 bytes) options will fit in this remaining space.
SYNパケットには通常、最大セグメントサイズ（MSS）（4バイト）、ウィンドウスケール（3バイト）、許可されたSACK（2バイト）、およびタイムスタンプ（10バイト）オプションが含まれます。これらを合計すると、19バイトになります。一部のオペレーティングシステムは、ワード境界まで各オプションを埋め込むように見えるため、24バイトを使用します（簡単な調査では、Windows XPおよびMac OS Xがこれを行うのに対し、Linuxはそうではないことを示唆しています）。したがって、楽観的には、21バイトの予備、またはワード境界で整列させる必要がある場合は16バイトの予備があります。ただし、どちらの場合でも、SYNバージョンのマルチパス対応（12バイト）および結合（12または16バイト）オプションは、この残りのスペースに収まります。
TCP data packets typically carry timestamp options in every packet, taking 10 bytes (or 12 with padding). That leaves 30 bytes (or 28, if word-aligned). The Data Sequence Signal (DSS) option varies in length depending on whether the data sequence mapping and DATA_ACK are included, and whether the sequence numbers in use are 4 or 8 octets. The maximum size of the DSS option is 28 bytes, so even that will fit in the available space. But unless a connection is both bidirectional and high-bandwidth, it is unlikely that all that option space will be required on each DSS option.
TCPデータパケットは通常、すべてのパケットにタイムスタンプオプションを持ち、10バイト（またはパディングで12バイト）を使用します。これにより、30バイト（ワード境界で整列されている場合は28バイト）が残ります。データシーケンス信号（DSS）オプションの長さは、データシーケンスマッピングとDATA_ACKが含まれているかどうか、および使用されているシーケンス番号が4オクテットか8オクテットかによって異なります。 DSSオプションの最大サイズは28バイトなので、それでも使用可能なスペースに収まります。ただし、接続が双方向で高帯域幅である場合を除き、各DSSオプションでそのすべてのオプションスペースが必要になることはほとんどありません。
Within the DSS option, it is not necessary to include the data sequence mapping and DATA_ACK in each packet, and in many cases it may be possible to alternate their presence (so long as the mapping covers the data being sent in the following packet). It would also be possible to alternate between 4- and 8-byte sequence numbers in each option.
DSSオプション内では、各パケットにデータシーケンスマッピングとDATA_ACKを含める必要はありません。多くの場合、それらの存在を変更できます（マッピングが次のパケットで送信されるデータをカバーする限り）。各オプションで4バイトと8バイトのシーケンス番号を交互に使用することもできます。
On subflow and connection setup, an MPTCP option is also set on the third packet (an ACK). These are 20 bytes (for Multipath Capable) and 24 bytes (for Join), both of which will fit in the available option space.
サブフローと接続のセットアップでは、3番目のパケット（ACK）にもMPTCPオプションが設定されます。これらは、20バイト（マルチパス対応の場合）と24バイト（参加の場合）で、どちらも使用可能なオプションスペースに収まります。
Pure ACKs in TCP typically contain only timestamps (10 bytes). Here, Multipath TCP typically needs to encode only the DATA_ACK (maximum of 12 bytes). Occasionally, ACKs will contain SACK information. Depending on the number of lost packets, SACK may utilize the entire option space. If a DATA_ACK had to be included, then it is probably necessary to reduce the number of SACK blocks to accommodate the DATA_ACK. However, the presence of the DATA_ACK is unlikely to be necessary in a case where SACK is in use, since until at least some of the SACK blocks have been retransmitted, the cumulative data-level ACK will not be moving forward (or if it does, due to retransmissions on another path, then that path can also be used to transmit the new DATA_ACK).
TCPの純粋なACKには、通常、タイムスタンプ（10バイト）のみが含まれます。ここで、マルチパスTCPは通常、DATA_ACK（最大12バイト）のみをエンコードする必要があります。時折、ACKにはSACK情報が含まれます。失われたパケットの数に応じて、SACKはオプション空間全体を利用する場合があります。 DATA_ACKを含める必要がある場合は、DATA_ACKに対応するためにSACKブロックの数を減らす必要があるでしょう。ただし、SACKが使用されている場合は、DATA_ACKの存在が必要になることはほとんどありません。SACKブロックの少なくとも一部が再送信されるまで、累積データレベルのACKは前進しないためです（または、 、別のパスでの再送信により、そのパスは新しいDATA_ACKの送信にも使用できます。
The ADD_ADDR option can be between 8 and 22 bytes, depending on whether IPv4 or IPv6 is used, and whether or not the port number is present. It is unlikely that such signaling would fit in a data packet (although if there is space, it is fine to include it). It is recommended to use duplicate ACKs with no other payload or options in order to transmit these rare signals. Note this is the reason for mandating that duplicate ACKs with MPTCP options are not taken as a signal of congestion.
ADD_ADDRオプションは、IPv4とIPv6のどちらが使用されているか、およびポート番号が存在するかどうかに応じて、8〜22バイトにすることができます。そのようなシグナリングがデータパケットに収まる可能性は低いです（ただし、スペースがある場合は、それを含めても問題ありません）。これらのまれな信号を送信するために、他のペイロードまたはオプションなしで重複したACKを使用することをお勧めします。これが、MPTCPオプションを使用した重複したACKが輻輳のシグナルとして受け取られないことを義務付ける理由であることに注意してください。
Finally, there are issues with reliable delivery of options. As options can also be sent on pure ACKs, these are not reliably sent. This is not an issue for DATA_ACK due to their cumulative nature, but may be an issue for ADD_ADDR/REMOVE_ADDR options. Here, it is recommended to send these options redundantly (whether on multiple paths or on the same path on a number of ACKs -- but interspersed with data in order to avoid interpretation as congestion). The cases where options are stripped by middleboxes are discussed in Section 6.
最後に、オプションの確実な提供には問題があります。オプションは純粋なACKでも送信できるため、これらは確実に送信されません。これは累積的な性質によるDATA_ACKの問題ではありませんが、ADD_ADDR / REMOVE_ADDRオプションの問題である可能性があります。ここでは、これらのオプションを重複して送信することをお勧めします（複数のパス上、または複数のACK上の同じパス上にありますが、輻輳と解釈されないようにデータが散在しています）。オプションがミドルボックスで削除されるケースについては、セクション6で説明します。
Conceptually, an MPTCP connection can be represented as an MPTCP control block that contains several variables that track the progress and the state of the MPTCP connection and a set of linked TCP control blocks that correspond to the subflows that have been established.
概念的には、MPTCP接続は、MPTCP接続の進行状況と状態を追跡するいくつかの変数と、確立されたサブフローに対応するリンクされたTCP制御ブロックのセットを含むMPTCP制御ブロックとして表すことができます。
RFC 793 [1] specifies several state variables. Whenever possible, we reuse the same terminology as RFC 793 to describe the state variables that are maintained by MPTCP.
RFC 793 [1]は、いくつかの状態変数を指定しています。可能な限り、RFC 793と同じ用語を再利用して、MPTCPによって維持される状態変数について説明します。
The MPTCP control block contains the following variable per connection.
MPTCP制御ブロックには、接続ごとに次の変数が含まれています。
Local.Token (32 bits): This is the token chosen by the local host on this MPTCP connection. The token MUST be unique among all established MPTCP connections, generated from the local key.
Local.Token（32ビット）：これは、このMPTCP接続のローカルホストによって選択されたトークンです。トークンは、ローカルキーから生成された、確立されたすべてのMPTCP接続間で一意である必要があります。
Local.Key (64 bits): This is the key sent by the local host on this MPTCP connection.
Local.Key（64ビット）：これは、このMPTCP接続でローカルホストによって送信されるキーです。
Remote.Token (32 bits): This is the token chosen by the remote host on this MPTCP connection, generated from the remote key.
Remote.Token（32ビット）：これは、このMPTCP接続でリモートホストによって選択されたトークンであり、リモートキーから生成されます。
Remote.Key (64 bits): This is the key chosen by the remote host on this MPTCP connection
Remote.Key（64ビット）：これは、このMPTCP接続のリモートホストによって選択されたキーです。
MPTCP.Checksum (flag): This flag is set to true if at least one of the hosts has set the C bit in the MP_CAPABLE options exchanged during connection establishment, and is set to false otherwise. If this flag is set, the checksum must be computed in all DSS options.
MPTCP.Checksum（フラグ）：このフラグは、少なくとも1つのホストが接続の確立時に交換されるMP_CAPABLEオプションのCビットを設定している場合はtrueに設定され、それ以外の場合はfalseに設定されます。このフラグが設定されている場合、すべてのDSSオプションでチェックサムを計算する必要があります。
SND.UNA (64 bits): This is the data sequence number of the next byte to be acknowledged, at the MPTCP connection level. This variable is updated upon reception of a DSS option containing a DATA_ACK.
SND.UNA（64ビット）：これは、MPTCP接続レベルで確認される次のバイトのデータシーケンス番号です。この変数は、DATA_ACKを含むDSSオプションを受信すると更新されます。
SND.NXT (64 bits): This is the data sequence number of the next byte to be sent. SND.NXT is used to determine the value of the DSN in the DSS option.
SND.NXT（64ビット）：これは、送信される次のバイトのデータシーケンス番号です。 SND.NXTは、DSSオプションのDSNの値を決定するために使用されます。
SND.WND (32 bits with RFC 1323, 16 bits otherwise): This is the sending window. MPTCP maintains the sending window at the MPTCP connection level and the same window is shared by all subflows. All subflows use the MPTCP connection level SND.WND to compute the SEQ.WND value that is sent in each transmitted segment.
SND.WND（RFC 1323では32ビット、それ以外は16ビット）：これは送信ウィンドウです。 MPTCPは、送信ウィンドウをMPTCP接続レベルで維持し、同じウィンドウがすべてのサブフローで共有されます。すべてのサブフローは、MPTCP接続レベルSND.WNDを使用して、送信された各セグメントで送信されるSEQ.WND値を計算します。
RCV.NXT (64 bits): This is the data sequence number of the next byte that is expected on the MPTCP connection. This state variable is modified upon reception of in-order data. The value of RCV.NXT is used to specify the DATA_ACK that is sent in the DSS option on all subflows.
RCV.NXT（64ビット）：これは、MPTCP接続で予期される次のバイトのデータシーケンス番号です。この状態変数は、順序正しいデータを受信すると変更されます。 RCV.NXTの値は、すべてのサブフローのDSSオプションで送信されるDATA_ACKを指定するために使用されます。
RCV.WND (32 bits with RFC 1323, 16 bits otherwise): This is the connection-level receive window, which is the maximum of the RCV.WND on all the subflows.
RCV.WND（RFC 1323では32ビット、それ以外は16ビット）：これは接続レベルの受信ウィンドウであり、すべてのサブフローのRCV.WNDの最大値です。
The MPTCP control block also contains a list of the TCP control blocks that are associated to the MPTCP connection.
MPTCP制御ブロックには、MPTCP接続に関連付けられているTCP制御ブロックのリストも含まれています。
Note that the TCP control block on the TCP subflows does not contain the RCV.WND and SND.WND state variables as these are maintained at the MPTCP connection level and not at the subflow level.
TCPサブフローのTCP制御ブロックには、RCV.WNDおよびSND.WND状態変数が含まれていないことに注意してください。これらは、サブフローレベルではなくMPTCP接続レベルで維持されるためです。
Inside each TCP control block, the following state variables are defined.
各TCP制御ブロック内では、次の状態変数が定義されています。
SND.UNA (32 bits): This is the sequence number of the next byte to be acknowledged on the subflow. This variable is updated upon reception of each TCP acknowledgment on the subflow.
SND.UNA（32ビット）：これは、サブフローで確認応答される次のバイトのシーケンス番号です。この変数は、サブフローで各TCP確認応答を受信すると更新されます。
SND.NXT (32 bits): This is the sequence number of the next byte to be sent on the subflow. SND.NXT is used to set the value of SEG.SEQ upon transmission of the next segment.
SND.NXT（32ビット）：これは、サブフローで送信される次のバイトのシーケンス番号です。 SND.NXTは、次のセグメントの送信時にSEG.SEQの値を設定するために使用されます。
RCV.NXT (32 bits): This is the sequence number of the next byte that is expected on the subflow. This state variable is modified upon reception of in-order segments. The value of RCV.NXT is copied to the SEG.ACK field of the next segments transmitted on the subflow.
RCV.NXT（32ビット）：これは、サブフローで予期される次のバイトのシーケンス番号です。この状態変数は、順序正しいセグメントを受信すると変更されます。 RCV.NXTの値は、サブフローで送信される次のセグメントのSEG.ACKフィールドにコピーされます。
RCV.WND (32 bits with RFC 1323, 16 bits otherwise): This is the subflow-level receive window that is updated with the window field from the segments received on this subflow.
RCV.WND（RFC 1323では32ビット、それ以外では16ビット）：これは、このサブフローで受信されたセグメントのウィンドウフィールドで更新されるサブフローレベルの受信ウィンドウです。
The diagram in Figure 17 shows the Finite State Machine for connection-level closure. This illustrates how the DATA_FIN connection-level signal (indicated as the DFIN flag on a DATA_ACK) interacts with subflow-level FINs, and permits "break-before-make" handover between subflows.
図17の図は、接続レベルのクロージャのための有限状態機械を示しています。これは、DATA_FIN接続レベル信号（DATA_ACKのDFINフラグとして示されます）がサブフローレベルのFINとどのように相互作用するかを示し、サブフロー間の「break-before-make」ハンドオーバーを許可します。
+---------+
| M_ESTAB |
+---------+
M_CLOSE | | rcv DATA_FIN
------- | | -------
+---------+ snd DATA_FIN / \ snd DATA_ACK[DFIN] +---------+
| M_FIN |<----------------- ------------------->| M_CLOSE |
| WAIT-1 |--------------------------- | WAIT |
+---------+ rcv DATA_FIN \ +---------+
| rcv DATA_ACK[DFIN] ------- | M_CLOSE |
| -------------- snd DATA_ACK | ------- |
| CLOSE all subflows | snd DATA_FIN |
V V V
+-----------+ +-----------+ +-----------+
|M_FINWAIT-2| | M_CLOSING | | M_LAST-ACK|
+-----------+ +-----------+ +-----------+
| rcv DATA_ACK[DFIN] | rcv DATA_ACK[DFIN] |
| rcv DATA_FIN -------------- | -------------- |
| ------- CLOSE all subflows | CLOSE all subflows |
| snd DATA_ACK[DFIN] V delete MPTCP PCB V
\ +-----------+ +---------+
------------------------>|M_TIME WAIT|----------------->| M_CLOSED|
+-----------+ +---------+
All subflows in CLOSED
------------
delete MPTCP PCB
Figure 17: Finite State Machine for Connection Closure
図17：接続を閉じるための有限状態マシン
Authors' Addresses
著者のアドレス
Alan Ford Cisco Ruscombe Business Park Ruscombe, Berkshire RG10 9NN UK
アランフォードCisco Ruscombe Business Park Ruscombe、Berkshire RG10 9NN UK
EMail: alanford@cisco.com
Costin Raiciu University Politehnica of Bucharest Splaiul Independentei 313 Bucharest Romania
Costin Raiciu University Politehnica of Bucharest Splaiul Independentei 313ブカレストルーマニア
EMail: costin.raiciu@cs.pub.ro
Mark Handley University College London Gower Street London WC1E 6BT UK
マークハンドラリーユニバーシティカレッジロンドンガワーストリートロンドンWC1E 6BT英国
EMail: m.handley@cs.ucl.ac.uk
Olivier Bonaventure Universite catholique de Louvain Pl. Ste Barbe, 2 Louvain-la-Neuve 1348 Belgium
Olivier Bonaventureカトリックルーヴァン大学Pl。Ste Barbe、2 Louvain-la-Neuve 1348ベルギー
EMail: olivier.bonaventure@uclouvain.be