Internet Engineering Task Force (IETF) A. Brunstrom, Ed.
Request for Comments: 9623 Karlstad University
Category: Informational T. Pauly, Ed.
ISSN: 2070-1721 Apple Inc.
R. Enghardt
Netflix
P.S. Tiesel
SAP SE
M. Welzl
University of Oslo
January 2025
The Transport Services System enables applications to use transport protocols flexibly for network communication and defines a protocol-independent Transport Services Application Programming Interface (API) that is based on an asynchronous, event-driven interaction pattern. This document serves as a guide to implementing such a system.
トランスポートサービスシステムにより、アプリケーションはネットワーク通信に輸送プロトコルを柔軟に使用でき、非同期のイベント駆動型インタラクションパターンに基づくプロトコルに依存しないトランスポートサービスアプリケーションプログラミングインターフェイス（API）を定義できます。このドキュメントは、そのようなシステムを実装するためのガイドとして機能します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9623.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9623で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Implementing Connection Objects
3. Implementing Preestablishment
3.1. Configuration-Time Errors
3.2. Role of System Policy
4. Implementing Connection Establishment
4.1. Structuring Candidates as a Tree
4.1.1. Branch Types
4.1.2. Branching Order-of-Operations
4.1.3. Sorting Branches
4.2. Candidate Gathering
4.2.1. Gathering Endpoint Candidates
4.3. Candidate Racing
4.3.1. Simultaneous
4.3.2. Staggered
4.3.3. Failover
4.4. Completing Establishment
4.4.1. Determining Successful Establishment
4.5. Establishing Multiplexed Connections
4.6. Handling Connectionless Protocols
4.7. Implementing Listeners
4.7.1. Implementing Listeners for Connected Protocols
4.7.2. Implementing Listeners for Connectionless Protocols
4.7.3. Implementing Listeners for Multiplexed Protocols
5. Implementing Sending and Receiving Data
5.1. Sending Messages
5.1.1. Message Properties
5.1.2. Send Completion
5.1.3. Batching Sends
5.2. Receiving Messages
5.3. Handling of Data for Fast-Open Protocols
6. Implementing Message Framers
6.1. Defining Message Framers
6.2. Sender-Side Message Framing
6.3. Receiver-Side Message Framing
7. Implementing Connection Management
7.1. Pooled Connection
7.2. Handling Path Changes
8. Implementing Connection Termination
9. Cached State
9.1. Protocol State Caches
9.2. Performance Caches
10. Specific Transport Protocol Considerations
10.1. TCP
10.2. MPTCP
10.3. UDP
10.4. UDP-Lite
10.5. UDP Multicast Receive
10.6. SCTP
11. IANA Considerations
12. Security Considerations
12.1. Considerations for Candidate Gathering
12.2. Considerations for Candidate Racing
13. References
13.1. Normative References
13.2. Informative References
Appendix A. API Mapping Template
Appendix B. Reasons for Errors
Appendix C. Existing Implementations
Acknowledgements
Authors' Addresses
The Transport Services Architecture [RFC9621] defines a system that allows applications to flexibly use transport networking protocols. The API that such a system exposes to applications is defined as the Transport Services API [RFC9622]. This API is designed to be generic across multiple transport protocols and sets of protocol features.
Transport Services Architecture [RFC9621]は、アプリケーションが輸送ネットワークプロトコルを柔軟に使用できるようにするシステムを定義しています。このようなシステムがアプリケーションに公開するAPIは、トランスポートサービスAPI [RFC9622]として定義されます。このAPIは、複数のトランスポートプロトコルとプロトコル機能のセットにわたって一般的になるように設計されています。
This document serves as a guide to implementing a system that provides a Transport Services API. This guide offers suggestions to developers, but it is not prescriptive: implementations are free to take any desired form as long as the API specification defined in [RFC9622] is honored. It is the job of an implementation of a Transport Services System to turn the requests of an application into decisions on how to establish connections and how to transfer data over those connections once established. The terminology used in this document is based on the terminology defined in the Transport Services Architecture [RFC9621].
このドキュメントは、Transport Services APIを提供するシステムを実装するためのガイドとして機能します。このガイドは開発者に提案を提供しますが、規範的ではありません。[RFC9622]で定義されているAPI仕様が尊重されている限り、実装は任意のフォームを自由に取得できます。アプリケーションのリクエストを、接続を確立する方法と、確立された接続を介してデータを転送する方法に関する決定に変えるための輸送サービスシステムの実装の仕事です。このドキュメントで使用される用語は、輸送サービスアーキテクチャ[RFC9621]で定義されている用語に基づいています。
The Connection objects that are exposed to applications for Transport Services are:
輸送サービスのアプリケーションにさらされている接続オブジェクトは次のとおりです。
* the Preconnection, the bundle of Properties that describes the application constraints on, and preferences for, the transport;
* 事前接続、輸送のアプリケーションの制約、および好みを記述するプロパティの束。
* the Connection, the basic object that represents a flow of data as Messages in either direction between the Local and Remote Endpoints;
* 接続、ローカルエンドポイントとリモートエンドポイント間のいずれかの方向にメッセージとしてデータのフローを表す基本オブジェクト。
* and the Listener, a passive waiting object that delivers new Connections.
* そして、リスナー、新しい接続を提供する受動的な待機オブジェクト。
Preconnection objects should be implemented as bundles of Properties that an application can both read and write. A Preconnection object influences a Connection only at one point in time: when the Connection is created. Connection objects represent the interface between the application and the implementation to manage transport state and conduct data transfer. During the process of establishment (Section 4), the Connection will not necessarily be immediately bound to a transport protocol instance, since multiple candidate Protocol Stacks might be raced.
事前接続オブジェクトは、アプリケーションが読み取りおよび書き込みの両方でできるプロパティのバンドルとして実装する必要があります。事前接続オブジェクトは、接続が作成されたときの1つの時点でのみ接続に影響します。接続オブジェクトは、アプリケーションと実装との間のインターフェイスを表し、輸送状態を管理し、データ転送を実行します。設立の過程（セクション4）の間、複数の候補プロトコルスタックがレースされる可能性があるため、接続は必ずしも輸送プロトコルインスタンスにすぐに拘束されるわけではありません。
Once a Preconnection has been used to create an outbound Connection or a Listener, the implementation should ensure that the copy of the Properties held by the Connection or Listener cannot be mutated by the application making changes to the original Preconnection object. This may involve the implementation performing a deep-copy, copying the object with all the objects that it references.
事前接続を使用してアウトバウンド接続またはリスナーを作成すると、実装により、接続またはリスナーが保有するプロパティのコピーがアプリケーションによって変更されないことを確認する必要があります。これには、実装がディープコピーを実行し、参照するすべてのオブジェクトをオブジェクトにコピーすることが含まれます。
Once the Connection is established, the Transport Services Implementation maps actions and events to the details of the chosen Protocol Stack. For example, the same Connection object may ultimately represent a single transport protocol instance (e.g., a TCP connection, a TLS session over TCP, a UDP flow with fully specified Local and Remote Endpoint Identifiers, a DTLS session, a Stream Control Transmission Protocol (SCTP) stream, a QUIC stream, or an HTTP/2 stream). The Connection Properties held by a Connection or Listener are independent of other Connections that are not part of the same Connection Group.
接続が確立されると、トランスポートサービスの実装は、選択したプロトコルスタックの詳細にアクションとイベントをマッピングします。たとえば、同じ接続オブジェクトは、最終的に単一の輸送プロトコルインスタンスを表すことができます（たとえば、TCP接続、TCP上のTLSセッション、完全に指定されたローカルエンドポイント識別子とDTLSセッション、ストリーム制御伝送プロトコルを備えたUDPフロー、sctp）ストリーム、quicストリーム、またはhttp/2ストリーム）。接続またはリスナーが保持する接続プロパティは、同じ接続グループの一部ではない他の接続とは無関係です。
Connection establishment is only a local operation for connectionless protocols, which serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports [RFC8085] (for example, using UDP or UDP-Lite transport without a connection handshake procedure).
接続確立は、Connectionless Protocolsのローカル操作にすぎません。これは、ローカル送信/受信機能を簡素化し、指定されたアドレスとポート[RFC8085]のトラフィックをフィルタリングするのに役立ちます（たとえば、接続ハンドシェイクなしでUDPまたはUDP-Liteトランスポートを使用する手順）。
Once Initiate has been called, the Selection Properties and Endpoint information of the created Connection are immutable (i.e., an application is not able to later modify the Properties of a Connection by manipulating the original Preconnection object). Listener objects are created with a Preconnection, at which point their configuration should be considered immutable by the implementation. The process of listening is described in Section 4.7.
開始が呼び出されると、作成された接続の選択プロパティとエンドポイント情報が不可能です（つまり、アプリケーションは、元のプレシャネクションオブジェクトを操作することで接続のプロパティを後で変更することはできません）。リスナーオブジェクトは、事前接続で作成されます。その時点で、その構成は実装によって不変と見なされる必要があります。リスニングのプロセスについては、セクション4.7で説明します。
The preestablishment phase allows applications to specify Properties for the Connections that they are about to make or to query the API about potential Connections they could make.
事前設計フェーズにより、アプリケーションは、アクセスしようとしている接続のプロパティを指定したり、潜在的な接続についてAPIを照会したりすることができます。
During preestablishment, the application specifies one or more Endpoints to be used for communication as well as protocol preferences and constraints via Selection Properties and, if desired, also Connection Properties. Section 4 of [RFC9622] states that Connection Properties should preferably be configured during preestablishment because they can serve as input to decisions that are made by the implementation (e.g., the capacity profile can guide usage of a protocol offering scavenger-type congestion control).
事前設定中、アプリケーションは、選択プロパティを介したプロトコルの好みと制約、および必要に応じて接続プロパティを介したプロトコルの好みと制約に使用する1つ以上のエンドポイントを指定します。[RFC9622]のセクション4は、実装によって行われる決定への入力として機能することができるため、接続プロパティは前提条件中にできれば構成する必要があると述べています（たとえば、容量プロファイルは、スカベンジャー型の混雑制御を提供するプロトコルの使用法を導くことができます）。
The implementation stores these Properties as a part of the Preconnection object for use during Connection establishment. For Selection Properties that are not provided by the application, the implementation uses the default values specified in the Transport Services API ([RFC9622]).
この実装は、これらのプロパティを、接続確立中に使用するための事前接続オブジェクトの一部として保存します。アプリケーションによって提供されていない選択プロパティの場合、実装はトランスポートサービスAPI（[RFC9622]）で指定されたデフォルト値を使用します。
The Transport Services System should have a list of supported protocols available, each of which has transport features reflecting the capabilities of the protocol. Once an application specifies its Transport Properties, the Transport Services System matches the required and prohibited Properties against the transport features of the available protocols (see Section 6.2 of [RFC9622] for the definition of Property Preferences).
トランスポートサービスシステムには、利用可能なサポートされているプロトコルのリストが必要です。各プロトコルには、プロトコルの機能を反映したトランスポート機能があります。アプリケーションが輸送プロパティを指定すると、輸送サービスシステムは、利用可能なプロトコルの輸送機能と一致します（プロパティの設定の定義については、[RFC9622]のセクション6.2を参照）。
In the following cases, failure should be detected during preestablishment:
以下の場合、事前設定中に障害を検出する必要があります。
* A request by an application for Properties that cannot be satisfied by any of the available protocols. For example, if an application requires perMsgReliability, but no such feature is available in any protocol on the host running the Transport Services System, this should result in an error.
* 利用可能なプロトコルのいずれでも満たすことができないプロパティのアプリケーションによる要求。たとえば、アプリケーションにPermsgrelivabilityが必要であるが、トランスポートサービスシステムを実行しているホストのプロトコルではそのような機能が利用できない場合、これによりエラーが発生します。
* A request by an application for Properties that are in conflict with each other, such as specifying required and prohibited Properties that cannot be satisfied by any protocol. For example, if an application prohibits reliability but then requires perMsgReliability, this mismatch should result in an error.
* プロトコルでは満たすことができない必要なプロパティを指定するなど、互いに競合するプロパティのアプリケーションによる要求。たとえば、アプリケーションが信頼性を禁止しているが、パームグレリ性が必要な場合、この不一致はエラーになるはずです。
To avoid allocating resources that are not needed, it is important that configuration-time errors fail as early as possible.
不要なリソースの割り当てを回避するには、構成時間エラーができるだけ早く失敗することが重要です。
The Properties specified during preestablishment have a close relationship to System Policy. The implementation is responsible for combining and reconciling several different sources of preferences when establishing Connections. These include, but are not limited to:
事前設定中に指定されたプロパティは、システムポリシーと密接な関係があります。この実装は、接続を確立する際にいくつかの異なる設定ソースを組み合わせて調整する責任があります。これらには以下が含まれますが、これらに限定されません。
1. Application preferences, i.e., preferences specified during preestablishment via Selection Properties.
1. アプリケーションの設定、つまり、選択プロパティによる事前設定中に指定された設定。
2. Dynamic System Policy, i.e., policy compiled from internally and externally acquired information about available network interfaces, supported transport protocols, and current/previous Connections. Examples of ways to externally retrieve policy-support information are through OS-specific statistics/ measurement tools and tools that reside on middleboxes and routers.
2. 動的システムポリシー、つまり、利用可能なネットワークインターフェイス、サポートされた輸送プロトコル、および現在/以前の接続に関する内部および外部から取得した情報からまとめられたポリシー。ポリシーサポート情報を外部的に取得する方法の例は、ミドルボックスとルーターに存在するOS固有の統計/測定ツールとツールを使用しています。
3. Default implementation policy, i.e., predefined policy by the OS or application.
3. デフォルトの実装ポリシー、つまり、OSまたはアプリケーションによる事前定義されたポリシー。
In general, any protocol or path used for a Connection must conform to all three sources of constraints. A violation that occurs at any of the policy layers should cause a protocol or path to be considered ineligible for use. If such a violation prevents a Connection from being established, this should be communicated to the application, e.g., via the EstablishmentError event. For an example of application preferences leading to constraints, an application may prohibit the use of metered network interfaces for a given Connection to avoid user cost. Similarly, the System Policy at a given time may prohibit the use of such a metered network interface from the application's process. Lastly, the implementation itself may default to disallowing certain network interfaces unless explicitly requested by the application.
一般に、接続に使用されるプロトコルまたはパスは、3つの制約ソースすべてに適合する必要があります。ポリシーレイヤーのいずれかで発生する違反は、プロトコルまたはパスを使用する不適格と見なされる必要があります。そのような違反が接続の確立を防ぐ場合、これは、たとえば、設立イベントを介してアプリケーションに伝える必要があります。制約につながるアプリケーションの設定の例では、アプリケーションは、ユーザーコストを回避するために、特定の接続にメーターネットワークインターフェイスを使用することを禁止する場合があります。同様に、特定の時間にシステムポリシーは、アプリケーションのプロセスからのこのようなメーターネットワークインターフェイスの使用を禁止する場合があります。最後に、実装自体は、アプリケーションによって明示的に要求されない限り、特定のネットワークインターフェイスを非難するデフォルトである場合があります。
It is expected that the database of system policies and the method of looking up these policies will vary across various platforms. An implementation should attempt to look up the relevant policies for the system in a dynamic way to make sure it reflects an accurate version of the System Policy, since the system's policy regarding the application's traffic may change over time due to user or administrative changes.
システムポリシーのデータベースとこれらのポリシーを検索する方法は、さまざまなプラットフォームによって異なることが期待されています。実装は、ユーザーまたは管理上の変更により、アプリケーションのトラフィックに関するシステムのポリシーが時間とともに変化する可能性があるため、システムの関連するポリシーを動的な方法で検索しようとする必要があります。
The process of establishing a network connection begins when an application expresses intent to communicate with a Remote Endpoint by calling Initiate, at which point the Preconnection object contains all constraints or requirements the application has configured. The establishment process can be considered complete once there is at least one Protocol Stack that has completed any required setup to the point that it can transmit and receive the application's data.
ネットワーク接続を確立するプロセスは、アプリケーションがInitiateを呼び出すことによりリモートエンドポイントと通信する意図を表すときに始まります。その時点で、事前接続オブジェクトにはアプリケーションが構成したすべての制約または要件が含まれます。設立プロセスは、アプリケーションのデータを送信および受信できるポイントまで必要なセットアップを完了した少なくとも1つのプロトコルスタックがあると、完全に完了すると見なすことができます。
Connection establishment is divided into two top-level steps:
接続確立は、2つのトップレベルのステップに分かれています。
* Candidate Gathering (defined in Section 4.2.1 of [RFC9621]) to identify the paths, protocols, and endpoints to use (see Section 4.2) and
* 候補者の収集（[RFC9621]のセクション4.2.1で定義）を使用して、使用するパス、プロトコル、およびエンドポイント（セクション4.2を参照）を特定します。
* Candidate Racing (defined in Section 4.2.2 of [RFC9621]), in which the necessary protocol handshakes are conducted so that the Transport Services System can select which set to use (see Section 4.3).
* 候補レース（[RFC9621]のセクション4.2.2で定義）。必要なプロトコルハンドシェイクが行われ、輸送サービスシステムが使用するセットを選択できるようにします（セクション4.3を参照）。
Candidate Racing involves attempting multiple options for Connection establishment and choosing the first option to succeed as the Protocol Stack to use for the Connection. These attempts are usually staggered, with each next option starting after a delay; however, they can also be performed in parallel or after failures occur.
候補レースには、接続の確立のための複数のオプションを試み、接続に使用するプロトコルスタックとして成功するための最初のオプションを選択することが含まれます。これらの試みは通常、遅延後に次のオプションを開始するたびによろめきます。ただし、それらは並列または障害が発生した後にも実行することもできます。
For ease of illustration, this document structures the candidates for racing as a tree (see Section 4.1). This is not meant to restrict implementations from structuring racing candidates differently.
簡単にするために、この文書は、レースの候補者を木として構成します（セクション4.1を参照）。これは、レース候補者の構造化から実装を異なる方法で制限することを意図したものではありません。
The simplest example of this process might involve identifying the single IP address to which the implementation wishes to connect, using the system's current default path (i.e., using the default interface), and starting a TCP handshake to establish a stream to the specified IP address. However, each step may also differ depending on the requirements of the connection:
このプロセスの最も単純な例には、実装が接続したい単一のIPアドレスを識別し、システムの現在のデフォルトパスを使用（つまり、デフォルトインターフェイスを使用する）、および指定されたIPアドレスへのストリームを確立するためにTCPハンドシェイクを開始することが含まれる場合があります。。ただし、各ステップは、接続の要件によっても異なる場合があります。
* if the Endpoint Identifier is a hostname and port, then there may be multiple resolved addresses that are available;
* エンドポイント識別子がホスト名とポートである場合、利用可能な複数の解決されたアドレスがある場合があります。
* there may also be multiple paths available (in this case using an interface other than the default system interface); and
* また、複数のパスが利用可能になる場合があります（この場合、デフォルトのシステムインターフェイス以外のインターフェイスを使用）。そして
* some protocols may not need any transport handshake to be considered "established" (such as UDP), while other connections may utilize layered protocol handshakes, such as TLS over TCP.
* 一部のプロトコルでは、「確立された」（UDPなど）と見なされるために輸送の握手を必要としない場合がありますが、他の接続ではTCPを介したTLSなどの層状プロトコルハンドシェイクを利用する場合があります。
Whenever an implementation has multiple options for Connection establishment, it can view the set of all individual Connection establishment options as a single aggregate Connection establishment. The aggregate set conceptually includes every valid combination of endpoints, paths, and protocols. As an example, consider an implementation that initiates a TCP connection to a hostname + port Endpoint Identifier and that has two valid interfaces available (Wi-Fi and LTE). The hostname resolves to a single IPv4 address on the Wi-Fi network, to the same IPv4 address on the LTE network, and to a single IPv6 address. The aggregate set of Connection establishment options can be viewed as follows, with the Endpoint Identifier abbreviated as "EId":
実装に接続確立の複数のオプションがある場合はいつでも、個々の接続確立オプションのセットを単一の集約接続確立と見なすことができます。集計セットには、エンドポイント、パス、およびプロトコルのすべての有効な組み合わせが概念的に含まれています。例として、ホスト名 +ポートエンドポイント識別子へのTCP接続を開始し、2つの有効なインターフェイス（Wi-FiとLTE）を使用できる実装を検討してください。ホスト名は、Wi-Fiネットワーク上の単一のIPv4アドレス、LTEネットワーク上の同じIPv4アドレス、および単一のIPv6アドレスに解決します。接続確立オプションの集約セットは、次のように表示でき、エンドポイント識別子は「eid」と略されます。
Aggregate [EId: example.com:443] [Interface: Any] [Protocol: TCP]
|-> [EId: [3fff:23::1]:443] [Interface: Wi-Fi] [Protocol: TCP]
|-> [EId: 192.0.2.1:443] [Interface: LTE] [Protocol: TCP]
|-> [EId: [3fff:42::1]:443] [Interface: LTE] [Protocol: TCP]
Any one of these subentries on the aggregate connection attempt would satisfy the original application intent. The concern of this section is the algorithm defining which of these options to try, when to try them, and in what order.
集約接続試行のこれらのサブエントリのいずれかが、元のアプリケーションの意図を満たします。このセクションの懸念は、これらのオプションのどれを試してみるのか、いつ試すべきか、どの順序でどのようなオプションを定義するかを示すアルゴリズムです。
During Candidate Gathering (Section 4.2), an implementation prunes and sorts branches according to the Selection Property Preferences (Section 6.2 of [RFC9622]). First, it excludes all protocols and paths that match a prohibited Property or do not match all required Properties. Then, it will sort branches according to preferred Properties, avoided Properties, and, possibly, other criteria.
候補者の収集（セクション4.2）中に、選択プロパティの選好に従って実装と並べ替えの分岐（[RFC9622]のセクション6.2）。まず、禁止されているプロパティに一致するすべてのプロトコルとパスを除外したり、必要なすべてのプロパティと一致しない。次に、優先プロパティ、回避されたプロパティ、そしておそらく他の基準に従って分岐をソートします。
As noted above, the consideration of multiple candidates in a gathering and racing process can be conceptually structured as a tree; this terminological convention is used throughout this document.
上記のように、集会とレースのプロセスにおける複数の候補者の考慮は、概念的にツリーとして構成できます。この用語条約は、このドキュメント全体で使用されています。
Each leaf node of the tree represents a single coherent connection attempt with an endpoint, a network path, and a set of protocols that can directly negotiate and send data on the network. Each node in the tree that is not a leaf represents a connection attempt that is either underspecified or includes multiple distinct options. For example, when connecting on an IP network, a connection attempt to a hostname and port is underspecified because the connection attempt requires a resolved IP address as its Remote Endpoint Identifier. In this case, the node represented by the connection attempt to the hostname is a parent node with child nodes for each IP address. Similarly, an implementation that is allowed to connect using multiple interfaces will have a parent node of the tree for the decision between the network paths with a branch for each interface.
ツリーの各リーフノードは、エンドポイント、ネットワークパス、およびネットワーク上のデータを直接ネゴシエートして送信できるプロトコルのセットとの単一のコヒーレント接続試行を表します。葉ではないツリー内の各ノードは、不足しているか、複数の異なるオプションを含む接続の試みを表します。たとえば、IPネットワークで接続する場合、接続試行にはリモートエンドポイント識別子として解決されたIPアドレスが必要であるため、ホスト名とポートへの接続試行が不十分です。この場合、ホスト名への接続試行で表されるノードは、各IPアドレスの子ノードを備えた親ノードです。同様に、複数のインターフェイスを使用して接続できる実装には、各インターフェイスのブランチを使用して、ネットワークパス間の決定のためにツリーの親ノードがあります。
The example aggregate connection attempt above can be drawn as a tree by grouping the addresses resolved on the same interface into branches:
上記の接続接続の例の例は、同じインターフェイスで解決されたアドレスを分岐にグループ化することにより、ツリーとして描画できます。
||
+============================+
www.example.com:443/any path
+============================+
// \\
+=========================+ +=======================+
www.example.com:443/Wi-Fi www.example.com:443/LTE
+=========================+ +=======================+
|| // \\
+======================+ +=================+ +====================+
[3fff:23::1]:443/Wi-Fi 192.0.2.1:443/LTE [3fff:42::1]:443/LTE
+======================+ +=================+ +====================+
The rest of this section will use a notation scheme to represent this tree. The root node (or parent node) of the tree will be represented by a single integer, such as "1". ("1" is used assuming that this is the first connection made by the system; future connections created by the application would allocate numbers in an increasing manner.) Each child of that node will have an integer that identifies it, from 1 to the number of children. That child node will be uniquely identified by concatenating its integer to its parent's identifier with a dot character (".") in between, such as "1.1" and "1.2". Each node will be summarized by a tuple of three elements: endpoint, path (labeled here by interface), and protocol. In Protocol Stacks, the layers are separated by a slash character ("/") and ordered with the protocol closest to the application first. The above example can now be written more succinctly as:
このセクションの残りの部分は、このツリーを表すために表記スキームを使用します。ツリーのルートノード（または親ノード）は、「1」などの単一の整数で表されます。（「1」は、これがシステムによって行われた最初の接続であると仮定して使用されます。アプリケーションによって作成された将来の接続は、ますます多くの方法で数値を割り当てます。）そのノードの各子には、1から1までそれを識別する整数があります。子供の数。その子ノードは、「1.1」や「1.2」などの間にあるドット文字（「。」）を持つ親の識別子に整数を連結することにより、一意に識別されます。各ノードは、エンドポイント、パス（インターフェイスでここでラベル付け）、およびプロトコルの3つの要素のタプルによって要約されます。プロトコルスタックでは、レイヤーはスラッシュ文字（ "/"）で分離され、最初にアプリケーションに最も近いプロトコルで順序付けられます。上記の例は、以下としてより簡潔に書くことができます。
1 [www.example.com:443, any path, TCP]
1.1 [www.example.com:443, Wi-Fi, TCP]
1.1.1 [[2001:db8:23::1]:443, Wi-Fi, TCP]
1.2 [www.example.com:443, LTE, TCP]
1.2.1 [192.0.2.1:443, LTE, TCP]
1.2.2 [[2001:db8.42::1]:443, LTE, TCP]
When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer data. Thus, once a single leaf node becomes ready to use, the Connection establishment tree is considered ready. One way to implement this is by having every leaf node update the state of its parent node when it becomes ready until the root node of the tree is ready, which then notifies the application that the Connection as a whole is ready to use.
実装が単一の接続を確立するように求められた場合、データの転送には候補セットのリーフノードの1つだけが必要です。したがって、単一のリーフノードが使用できるようになると、接続確立ツリーの準備が整います。これを実装する1つの方法は、すべてのリーフノードに、ツリーのルートノードが準備が整うまで準備ができたときに親ノードの状態を更新することです。これにより、接続全体が使用できることがアプリケーションに通知されます。
A Connection establishment tree may consist of only a single node, such as a connection attempt to an IP address over a single interface with a single protocol.
接続確立ツリーは、単一のプロトコルを使用した単一のインターフェイス上のIPアドレスへの接続試行など、単一のノードのみで構成されている場合があります。
1 [[2001:db8:23::1]:443, Wi-Fi, TCP]
A root node may also only have one child (or leaf) node, such as a when a hostname resolves to only a single IP address.
ルートノードには、ホスト名が単一のIPアドレスのみに解決する場合など、1人の子供（または葉）ノードのみがあります。
1 [www.example.com:443, Wi-Fi, TCP]
1.1 [[2001:db8:23::1]:443, Wi-Fi, TCP]
There are three types of branching from a parent node into one or more child nodes: Derived Endpoints, network paths, and protocol options. Any parent node of the tree must use only one type of branching.
親ノードから1つ以上の子ノードへの分岐には、派生エンドポイント、ネットワークパス、およびプロトコルオプションの3つのタイプがあります。ツリーの親ノードは、1つの種類の分岐のみを使用する必要があります。
If a connection originally targets a single Endpoint Identifier, there may be multiple endpoint candidates of different types that can be derived from the original. This creates an ordered list of the derived endpoint candidates according to application preference, System Policy, and expected performance.
接続が元々単一のエンドポイント識別子をターゲットにしている場合、オリジナルから導出できる異なるタイプの複数のエンドポイント候補が存在する場合があります。これにより、アプリケーションの好み、システムポリシー、および予想されるパフォーマンスに応じて、派生エンドポイント候補の順序付けられたリストが作成されます。
DNS hostname-to-address resolution is the most common method of endpoint derivation. When trying to connect to a hostname Endpoint Identifier on an IP network, the implementation should send all applicable DNS queries. Commonly, this will include both A (IPv4) and AAAA (IPv6) records if both address families are supported on the local interface. This can also include SRV records [RFC2782], SVCB and HTTPS records [RFC9460], or other future record types. The algorithm for ordering and racing these addresses should follow the recommendations in Happy Eyeballs [RFC8305].
DNSホスト名からアドレスへの解像度は、エンドポイント派生の最も一般的な方法です。IPネットワーク上のホスト名エンドポイント識別子に接続しようとする場合、実装はすべての該当するDNSクエリを送信する必要があります。通常、これには、両方のアドレスファミリがローカルインターフェイスでサポートされている場合、A（IPv4）とAAAA（IPv6）レコードの両方が含まれます。これには、SRVレコード[RFC2782]、SVCBおよびHTTPSレコード[RFC9460]、またはその他の将来のレコードタイプも含まれます。これらのアドレスを注文およびレースするためのアルゴリズムは、Happy Eyeballs [RFC8305]の推奨事項に従う必要があります。
1 [www.example.com:443, Wi-Fi, TCP]
1.1 [[2001:db8::1]:443, Wi-Fi, TCP]
1.2 [192.0.2.1:443, Wi-Fi, TCP]
1.3 [[2001:db8::2]:443, Wi-Fi, TCP]
1.4 [[2001:db8::3]:443, Wi-Fi, TCP]
DNS-Based Service Discovery [RFC6763] can also provide an endpoint derivation step. When trying to connect to a named service, the client may discover one or more hostname and port pairs on the local network using multicast DNS [RFC6762]. These hostnames should each be treated as a branch that can be attempted independently from other hostnames. Each of these hostnames might resolve to one or more addresses, which would create multiple layers of branching.
DNSベースのサービスディスカバリー[RFC6763]は、エンドポイント派生ステップを提供することもできます。名前付きサービスに接続しようとすると、クライアントは、マルチキャストDNS [RFC6762]を使用して、ローカルネットワーク上の1つ以上のホスト名とポートペアを発見する場合があります。これらのホスト名は、それぞれ他のホスト名から独立して試みることができるブランチとして扱う必要があります。これらの各ホスト名は、1つ以上のアドレスに解決する可能性があり、これにより複数の分岐層が作成されます。
1 [term-printer._ipp._tcp.meeting.example.com, Wi-Fi, TCP]
1.1 [term-printer.meeting.example.com:631, Wi-Fi, TCP]
1.1.1 [31.133.160.18:631, Wi-Fi, TCP]
Applications can influence which derived Endpoints are allowed and preferred via Selection Properties set on the Preconnection. For example, setting a preference for useTemporaryLocalAddress would prefer the use of IPv6 over IPv4, and requiring useTemporaryLocalAddress would eliminate IPv4 options since IPv4 does not support temporary addresses.
アプリケーションは、導出されたエンドポイントが許可され、プレシャネクションに設定された選択プロパティを介して優先されるかに影響を与える可能性があります。たとえば、UsetemporarylocalAddressの優先度を設定すると、IPv4を介してIPv6を使用することを好み、IPv4が一時的なアドレスをサポートしていないため、UsetemporarylocalAddressを必要とするとIPv4オプションが排除されます。
If a client has multiple network paths available to it, e.g., a mobile client with interfaces for both Wi-Fi and Cellular connectivity, it can attempt a connection over any of the paths. This represents a branch point in the Connection establishment. Similar to a derived endpoint, the paths should be ranked based on preference, policy, and performance. Attempts should be started on one path (e.g., a specific interface) and then successively on other paths (or interfaces) after delays based on the expected path RTT or other available metrics.
クライアントが使用可能な複数のネットワークパスを持っている場合、たとえば、Wi-Fiとセルラー接続の両方にインターフェイスを備えたモバイルクライアントがある場合、パスのいずれか上の接続を試みることができます。これは、接続施設の分岐点を表しています。派生エンドポイントと同様に、パスは好み、ポリシー、およびパフォーマンスに基づいてランク付けする必要があります。予想されるパスRTTまたは他の利用可能なメトリックに基づいて遅延した後、1つのパス（特定のインターフェイスなど）で、次に他のパス（またはインターフェイス）で連続して開始する必要があります。
1 [192.0.2.1:443, any path, TCP]
1.1 [192.0.2.1:443, Wi-Fi, TCP]
1.2 [192.0.2.1:443, LTE, TCP]
The same approach applies to any situation in which the client is aware of multiple links or views of the network. A single interface may be shared by multiple network paths, each with a coherent set of addresses, routes, DNS server, and more. A path may also represent a virtual interface service such as a Virtual Private Network (VPN).
同じアプローチが、クライアントがネットワークの複数のリンクまたはビューを認識している状況にも当てはまります。単一のインターフェイスは、複数のネットワークパスで共有される場合があり、それぞれがコヒーレントなアドレス、ルート、DNSサーバーなどを備えています。パスは、仮想プライベートネットワーク（VPN）などの仮想インターフェイスサービスを表すこともできます。
The list of available paths should be constrained by any requirements the application sets as well as by the System Policy.
利用可能なパスのリストは、アプリケーションが設定する要件とシステムポリシーによって制約される必要があります。
Differences in possible protocol compositions and options can also provide a branching point in Connection establishment. This allows clients to be resilient to situations in which a certain protocol is not functioning on a server or network.
考えられるプロトコルの構成とオプションの違いは、接続された確立の分岐点を提供することもできます。これにより、クライアントは、特定のプロトコルがサーバーまたはネットワークで機能していない状況に復元されることができます。
This approach is commonly used for connections with optional proxy server configurations. A single connection might have several options available: an HTTP-based proxy, a SOCKS-based proxy, or no proxy. As above, these options should be ranked based on preference, System Policy, and performance, and should be attempted in succession.
このアプローチは、一般的にオプションのプロキシサーバー構成との接続に使用されます。単一の接続には、HTTPベースのプロキシ、ソックスベースのプロキシ、またはプロキシなしのいくつかのオプションがある場合があります。上記のように、これらのオプションは、好み、システムポリシー、およびパフォーマンスに基づいてランク付けされる必要があり、連続して試みる必要があります。
1 [www.example.com:443, any path, HTTP/TCP]
1.1 [192.0.2.8:443, any path, HTTP/HTTP Proxy/TCP]
1.2 [192.0.2.7:10234, any path, HTTP/SOCKS/TCP]
1.3 [www.example.com:443, any path, HTTP/TCP]
1.3.1 [192.0.2.1:443, any path, HTTP/TCP]
This approach also allows a client to attempt different sets of application and transport protocols that, when available, could provide preferable features. For example, the protocol options could involve QUIC [RFC9000] over UDP on one branch and HTTP/2 [RFC9113] over TLS over TCP on the other:
また、このアプローチにより、クライアントは、利用可能な場合、望ましい機能を提供できるさまざまなアプリケーションおよび輸送プロトコルを試みることができます。たとえば、プロトコルオプションには、1つのブランチのUDPを超えるquic [rfc9000]、もう1つのブランチではhttp/2 [rfc9113]を含むことができます。
1 [www.example.com:443, any path, HTTP]
1.1 [www.example.com:443, any path, HTTP3/QUIC/UDP]
1.1.1 [192.0.2.1:443, any path, HTTP3/QUIC/UDP]
1.2 [www.example.com:443, any path, HTTP2/TLS/TCP]
1.2.1 [192.0.2.1:443, any path, HTTP2/TLS/TCP]
Another example is racing SCTP with TCP:
別の例は、TCPでSCTPをレースすることです。
1 [www.example.com:4740, any path, reliable-inorder-stream]
1.1 [www.example.com:4740, any path, SCTP]
1.1.1 [192.0.2.1:4740, any path, SCTP]
1.2 [www.example.com:4740, any path, TCP]
1.2.1 [192.0.2.1:4740, any path, TCP]
Implementations that support racing protocols and protocol options should maintain a history of which protocols and protocol options were successfully established on a per-network and per-endpoint basis (see Section 9.2). This information can influence future racing decisions to prioritize or prune branches.
レーシングプロトコルとプロトコルオプションをサポートする実装では、プロトコルとプロトコルオプションがネットワークごととエンドごとのベースで正常に確立された履歴を維持する必要があります（セクション9.2を参照）。この情報は、枝に優先順位を付けたりプルネットしたりするための将来のレースの決定に影響を与える可能性があります。
Branch types ought to occur in a specific order relative to one another to avoid creating leaf nodes with invalid or incompatible settings. In the example above, it would be invalid to branch for derived endpoints (the DNS results for www.example.com) before branching between interface paths since there are situations when the results will be different across networks due to private names or different supported IP versions. Implementations need to be careful to branch in a consistent order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node.
ブランチタイプは、無効または互換性のない設定で葉のノードの作成を避けるために、互いに互いに特定の順序で発生するはずです。上記の例では、インターフェイスパス間で分岐する前に派生エンドポイント（www.example.comのDNSの結果）の分岐に無効になります。バージョン。実装は、単一のノードから使用できる複数のブランチタイプがある場合はいつでも、使用可能なリーフノードをもたらす一貫した順序で分岐するように注意する必要があります。
This document recommends the following order of operations for branching:
このドキュメントは、分岐のために次の操作の順序を推奨しています。
1. Network paths
1. ネットワークパス
2. Protocol options
2. プロトコルオプション
3. Derived Endpoints
3. 派生エンドポイント
where a lower number indicates higher precedence and, therefore, higher placement in the tree. Branching between paths is the first in the list because results across multiple interfaces are likely not related to one another: endpoint resolution may return different results, especially when using locally resolved host and service names and the protocols that are supported and preferred may differ across interfaces. Thus, if multiple paths are attempted, the overall Connection establishment process can be seen as a race between the available paths or interfaces.
ここで、より低い数がより高い優先順位を示し、したがって、ツリーの配置が高いことを示します。パス間の分岐はリストの最初のものです。複数のインターフェイスにわたる結果は互いに関連していない可能性が高いためです。特に、局所的に解決されたホストとサービス名、およびサポートおよび好ましいプロトコルを使用する場合、エンドポイント解像度は異なる結果を返す可能性があります。インターフェイス間で異なる場合があります。したがって、複数のパスが試行された場合、全体的な接続確立プロセスは、利用可能なパスまたはインターフェイスの間の競争と見なすことができます。
Protocol options are next checked in order. Whether or not a set of protocols, or protocol-specific options, can successfully connect is generally not dependent on which specific IP address is used. Furthermore, the Protocol Stacks being attempted may influence or altogether change the Endpoint Identifiers being used. Adding a proxy to a connection's branch will change the Endpoint Identifier to the proxy's IP address or hostname. Choosing an alternate protocol may also modify the ports that should be selected.
次に、プロトコルオプションが順番にチェックされます。一連のプロトコル、またはプロトコル固有のオプションが正常に接続できるかどうかは、一般に、特定のIPアドレスが使用されるかに依存しません。さらに、試行されるプロトコルスタックは、使用されているエンドポイント識別子に影響を与えるか、完全に変更する場合があります。接続のブランチにプロキシを追加すると、エンドポイント識別子がプロキシのIPアドレスまたはホスト名に変更されます。代替プロトコルを選択すると、選択するポートを変更する場合があります。
Branching for derived endpoints is the final step and may have multiple layers of derivation or resolution, such as DNS service resolution and DNS hostname resolution.
導出されたエンドポイントの分岐が最終ステップであり、DNSサービス解像度やDNSホスト名解像度など、派生または解像度の複数の層がある場合があります。
For example, if the application has indicated both a preference for Wi-Fi over LTE and for a feature only available in SCTP, branches will first be sorted according to path selection, with Wi-Fi attempted as the first path. Then, branches with SCTP will be attempted within their subtree according to the Properties influencing protocol selection. However, if the implementation has current cache information that SCTP is not available on the path over Wi-Fi, there would be no SCTP node in the Wi-Fi subtree. Here, the path over Wi-Fi will be attempted first, and, if connection establishment succeeds, TCP will be used. Thus, the Selection Property preferring Wi-Fi takes precedence over the Property that led to a preference for SCTP.
たとえば、アプリケーションがLTEよりもWi-FiとSCTPでのみ利用可能な機能の両方の好みを示している場合、最初にBranchはパス選択に従ってソートされ、Wi-Fiは最初のパスとして試みられます。次に、プロトコルの選択に影響を与えるプロパティに応じて、SCTPの分岐がサブツリー内で試みられます。ただし、実装に現在のキャッシュ情報がある場合、SCTPがWi-Fiのパスで使用できない場合、Wi-FiサブツリーにSCTPノードはありません。ここでは、最初にWi-Fi上のパスが試みられ、接続確立が成功した場合、TCPが使用されます。したがって、Wi-Fiを好む選択プロパティは、SCTPを好むプロパティよりも優先されます。
1. [www.example.com:80, any path, reliable-inorder-stream]
1.1 [192.0.2.1:443, Wi-Fi, reliable-inorder-stream]
1.1.1 [192.0.2.1:443, Wi-Fi, TCP]
1.2 [192.0.3.1:443, LTE, reliable-inorder-stream]
1.2.1 [192.0.3.1:443, LTE, SCTP]
1.2.2 [192.0.3.1:443, LTE, TCP]
Implementations should sort the branches of the tree of connection options in order of their preference rank from most preferred to least preferred as specified by Selection Properties [RFC9622]. Leaf nodes on branches with higher rankings represent connection attempts that will be raced first.
実装は、選択プロパティ[RFC9622]で指定されているように、最先端から最も好まれるものから最小優先されるものまで、接続オプションのツリーの分岐を並べ替える必要があります。ランキングが高い枝の葉のノードは、最初にレースされる接続の試みを表します。
In addition to the Properties provided by the application, an implementation may include additional criteria such as cached performance estimates (see Section 9.2) or System Policy (see Section 3.2) in the ranking. Two examples of how Selection and Connection Properties may be used to sort branches are provided below:
アプリケーションが提供するプロパティに加えて、実装には、ランキングのキャッシュされたパフォーマンス推定値（セクション9.2を参照）またはシステムポリシー（セクション3.2を参照）などの追加の基準が含まれる場合があります。選択と接続のプロパティを使用して分岐をソートする方法の2つの例を以下に示します。
"Interface Instance or Type" (Property name interface):
「インターフェイスインスタンスまたはタイプ」（プロパティ名インターフェイス）：
If the application specifies an interface type to be preferred or avoided, implementations should accordingly rank the paths. If the application specifies an interface type to be required or prohibited, an implementation is expected to exclude the nonconforming paths.
アプリケーションが優先または回避するインターフェイスタイプを指定する場合、それに応じて実装がパスをランク付けする必要があります。アプリケーションが必要または禁止するインターフェイスタイプを指定する場合、実装は不適合パスを除外することが期待されます。
"Capacity Profile" (Property name connCapacityProfile):
「容量プロファイル」（プロパティ名conncapacityprofile）：
An implementation can use the capacity profile to prefer paths that match an application's expected traffic profile. This match will use cached performance estimates; see Section 9.2. Some examples of path preferences based on capacity profiles include:
実装では、容量プロファイルを使用して、アプリケーションの予想されるトラフィックプロファイルに一致するパスを好むことができます。この試合では、キャッシュされたパフォーマンスの見積もりが使用されます。セクション9.2を参照してください。容量プロファイルに基づいたパス設定の例には、次のものがあります。
Low Latency/Interactive:
低レイテンシー/インタラクティブ：
Prefer paths with the lowest expected Round-Trip Time (RTT), based on observed RTT estimates;
観測されたRTT推定に基づいて、予想される往復時間が最も低いパスを好む。
Low Latency/Non-Interactive:
低レイテンシー/非対話型：
Prefer paths with a low expected Round-Trip Time (RTT) and possible delay variation;
予想される往復時間が低いパス（RTT）と遅延変動の可能性を好む。
Constant-Rate Streaming:
一定のストリーミング：
Prefer paths that are expected to satisfy the requested stream send or receive bitrate based on the observed maximum throughput;
観測された最大スループットに基づいて、要求されたストリーム送信を満たすか、ビットレートを受信することが期待されるパスを好む。
Capacity-Seeking:
キャパシティシーキング：
Prefer adapting to paths to determine the highest available capacity based on the observed maximum throughput.
観測された最大スループットに基づいて、利用可能な最高の容量を決定するためにパスへの適応を好みます。
As another example, branch sorting can also be influenced by bounds on the send or receive rate (Selection Properties minSendRate / minRecvRate / maxSendRate / maxRecvRate): if the application indicates a bound on the expected send or receive bitrate, an implementation may prefer a path that can likely provide the desired bandwidth, based on cached maximum throughput (see Section 9.2). The application may know the send or receive bitrate from metadata in adaptive HTTP streaming, such as MPEG-DASH.
別の例として、ブランチの並べ替えは、送信または受信レートの境界（選択プロパティMinSendrate / MinRecvrate / Maxsendrate / MaxRecvrate）の影響を受けることもできます。キャッシュされた最大スループットに基づいて、目的の帯域幅を提供する可能性があります（セクション9.2を参照）。アプリケーションは、MPEG-Dashなどの適応型HTTPストリーミングでメタデータからの送信または受信を知っている場合があります。
Implementations process the Properties (Section 6.2 of [RFC9622]) in the following order: Prohibit, Require, Prefer, Avoid. If Selection Properties contain any prohibited Properties, the implementation should first purge branches containing nodes with these Properties. For required Properties, it should only keep branches that satisfy these requirements. Finally, it should order the branches according to the preferred Properties and use any avoided Properties as a tiebreaker. When ordering branches, an implementation can give more weight to Properties that the application has explicitly set rather than to the Properties that are set by default.
実装は、プロパティ（[RFC9622]のセクション6.2）を次の順序で処理します。選択プロパティに禁止されたプロパティが含まれている場合、実装は最初にこれらのプロパティを備えたノードを含む分岐をパージする必要があります。必要なプロパティの場合、これらの要件を満たすブランチのみを保持する必要があります。最後に、優先プロパティに従ってブランチを注文し、回避されたプロパティをタイブレーカーとして使用する必要があります。ブランチを注文する場合、実装は、デフォルトで設定されたプロパティではなく、アプリケーションが明示的に設定しているプロパティにより多くの重みを与えることができます。
The available protocols and paths on a specific system and in a specific context can change; therefore, the result of sorting and the outcome of racing may vary, even when using the same Selection and Connection Properties. However, an implementation ought to provide a consistent outcome to applications, e.g., by preferring protocols and paths that are already used by existing Connections that specified similar Properties.
特定のシステムおよび特定のコンテキストで利用可能なプロトコルとパスは変更される可能性があります。したがって、同じ選択プロパティと接続プロパティを使用する場合でも、ソートとレースの結果は異なる場合があります。ただし、実装は、例えば、同様のプロパティを指定した既存の接続ですでに使用されているプロトコルとパスを好むことにより、アプリケーションに一貫した結果を提供する必要があります。
The step of gathering candidates involves identifying which paths, protocols, and endpoints may be used for a given Connection. This list is determined by the requirements, prohibitions, preferences, and avoidances of the application as specified in the Selection Properties.
候補者を収集するステップには、特定の接続に使用できるパス、プロトコル、およびエンドポイントを特定することが含まれます。このリストは、選択プロパティで指定されているように、アプリケーションの要件、禁止、好み、および回避によって決定されます。
Both Local and Remote Endpoint Candidates must be discovered during Connection establishment. To support Interactive Connectivity Establishment (ICE) [RFC8445], or similar protocols that involve out-of-band indirect signaling to exchange candidates with the Remote Endpoint, it is important to query the set of candidate Local Endpoints and provide the Protocol Stack with a set of candidate Remote Endpoints before the Local Endpoint attempts to establish connections.
接続の確立中に、ローカルエンドポイント候補とリモートエンドポイント候補の両方を発見する必要があります。インタラクティブな接続確立（ICE）[RFC8445]、またはリモートエンドポイントと候補者を交換する帯域外の間接シグナリングを含む同様のプロトコルをサポートするには、候補のローカルエンドポイントのセットを照会し、プロトコルスタックを提供することが重要です。ローカルエンドポイントが接続を確立しようとする前に、候補のリモートエンドポイントのセット。
The set of possible Local Endpoints is gathered. In a simple case, this merely enumerates the local interfaces and protocols and allocates ephemeral source ports. For example, a system that has Wi-Fi and Ethernet and supports IPv4 and IPv6 might gather four candidate Local Endpoints (IPv4 on Ethernet, IPv6 on Ethernet, IPv4 on Wi-Fi, and IPv6 on Wi-Fi) that can form the source for a transient.
可能なローカルエンドポイントのセットが収集されます。簡単な場合、これは単にローカルインターフェイスとプロトコルを列挙し、短命ソースポートを割り当てます。たとえば、Wi-FiおよびEthernetを備え、IPv4とIPv6をサポートするシステムは、ソースを形成できる4つの候補のローカルエンドポイント（イーサネットのIPv4、Wi-FiのIPv4、Wi-FiのIPv6）を収集する可能性があります。一時的な場合。
If NAT traversal is required, the process of gathering Local Endpoints becomes broadly equivalent to the ICE Candidate Gathering phase (see Section 5.1.1 of [RFC8445]). The endpoint determines its server-reflexive Local Endpoints (i.e., the translated address of a Local Endpoint, on the other side of a NAT, e.g., via a STUN server [RFC8489]) and relayed Local Endpoints (e.g., via a TURN server [RFC8656] or other relay) for each interface and network protocol. These are added to the set of candidate Local Endpoint Identifiers for this connection.
NATトラバーサルが必要な場合、ローカルエンドポイントを収集するプロセスは、氷候補の収集段階とほぼ同等になります（[RFC8445]のセクション5.1.1を参照）。エンドポイントは、STUNサーバー[RFC8489]を介して、NATの反対側にあるローカルエンドポイントの翻訳されたアドレス（つまり、ローカルエンドポイントの翻訳されたアドレス[RFC8489]）を決定し、ローカルエンドポイントをリレーしました（例：ターンサーバーを介して[各インターフェイスおよびネットワークプロトコルのRFC8656]またはその他のリレー）。これらは、この接続の候補ローカルエンドポイント識別子のセットに追加されます。
Gathering Local Endpoints is primarily a local operation, although it might involve exchanges with a STUN server to derive server-reflexive Local Endpoints or with a TURN server or other relay to derive relayed Local Endpoints. However, it does not involve communication with the Remote Endpoint.
ローカルエンドポイントの収集は主にローカル操作ですが、サーバー反射性のローカルエンドポイントを導出するためのスタンサーバーとの交換、またはリレーされたローカルエンドポイントを導出するためのターンサーバーまたはその他のリレーを含む場合があります。ただし、リモートエンドポイントとの通信は含まれません。
The Remote Endpoint Identifier is typically a name that needs to be resolved into a set of possible addresses that can be used for communication. Resolving the Remote Endpoint is the process of recursively performing such name lookups, until fully resolved, to return the set of candidates for the Remote Endpoint of this Connection.
リモートエンドポイント識別子は、通常、通信に使用できる一連の可能なアドレスに解決する必要がある名前です。リモートエンドポイントの解決は、この接続のリモートエンドポイントの候補セットを返すために、完全に解決されるまで、そのような名前のルックアップを再帰的に実行するプロセスです。
How this resolution is done will depend on the type of the Remote Endpoint and can also be specific to each Local Endpoint. A common case is when the Remote Endpoint Identifier is a DNS name, in which case, it is resolved to give a set of IPv4 and IPv6 addresses representing that name. Some types of Remote Endpoint Identifiers might require more complex resolution. Resolving the Remote Endpoint for a peer-to-peer connection might involve communication with a rendezvous server. The server, in turn, contacts the peer to gain consent to communicate and retrieve its set of candidate Local Endpoints. These Endpoints are returned and form the candidate remote addresses for contacting that peer.
この解像度がどのように行われるかは、リモートエンドポイントのタイプに依存し、各ローカルエンドポイントにも固有です。一般的なケースは、リモートエンドポイント識別子がDNS名である場合です。その場合、その名前を表すIPv4およびIPv6アドレスのセットを提供することが解決されます。一部のタイプのリモートエンドポイント識別子は、より複雑な解像度が必要になる場合があります。ピアツーピア接続のリモートエンドポイントを解決するには、ランデブーサーバーとの通信が含まれる場合があります。サーバーは、ピアに連絡して、候補のローカルエンドポイントのセットを通信および取得することに同意します。これらのエンドポイントは返され、そのピアに連絡するために候補のリモートアドレスを形成します。
Resolving the Remote Endpoint is not a local operation. It will involve a directory service and can require communication between the Remote Endpoint and a rendezvous server as well as the exchange of peer addresses. This can expose some or all of the candidate Local Endpoints to the Remote Endpoint.
リモートエンドポイントの解決はローカル操作ではありません。ディレクトリサービスが含まれ、リモートエンドポイントとランデブーサーバーの間の通信、およびピアアドレスの交換が必要です。これにより、候補のローカルエンドポイントの一部またはすべてがリモートエンドポイントに公開されます。
The primary goal of the Candidate Racing process is to successfully negotiate a Protocol Stack to an Endpoint over an interface to connect a single leaf node of the tree with as little delay and as few unnecessary connection attempts as possible. Optimizing these two factors improves the user experience, while minimizing network load.
候補者レースプロセスの主な目標は、インターフェイス上のエンドポイントにプロトコルスタックを正常にネゴシエートして、ツリーの単一のリーフノードを遅延が少なく、不必要な接続の試行がほとんどないことを接続することです。これらの2つの要因を最適化すると、ネットワークの負荷を最小限に抑えながら、ユーザーエクスペリエンスが向上します。
This section covers the dynamic aspect of Connection establishment. The tree described above is a useful conceptual and architectural model. However, an implementation is unable to know all of the nodes that will be used until steps like name resolution have occurred; many of the possible branches ultimately might not be attempted.
このセクションでは、接続確立の動的な側面について説明します。上記のツリーは、有用な概念モデルであり、建築モデルです。ただし、実装では、名前解像度のようなステップが発生するまで使用されるすべてのノードを知ることができません。可能な枝の多くは最終的に試みられないかもしれません。
There are three different approaches to racing the attempts for different nodes of the Connection establishment tree:
接続確立ツリーのさまざまなノードの試みをレースするには、3つの異なるアプローチがあります。
1. Simultaneous
1. 同時
2. Staggered
2. よろめい
3. Failover
3. フェールオーバー
Each approach is appropriate in different use cases and branch types. However, to avoid consuming unnecessary network resources, implementations should not use simultaneous racing as a default approach.
各アプローチは、異なるユースケースとブランチタイプで適切です。ただし、不要なネットワークリソースの消費を避けるために、実装はデフォルトのアプローチとして同時レースを使用しないでください。
The timing algorithms for racing should remain independent across branches of the tree. Any timer or racing logic is isolated to a given parent node and is not ordered precisely with regard to children of other nodes.
レースのタイミングアルゴリズムは、ツリーの枝全体で独立したままでなければなりません。タイマーまたはレースロジックは、特定の親ノードに分離されており、他のノードの子供に関しては正確に順序付けられていません。
Simultaneous racing is when multiple alternate branches are started without waiting for any one branch to make progress before starting the next alternative. This means the attempts are effectively simultaneous. Simultaneous racing should be avoided by implementations since it consumes extra network resources and establishes state that might not be used.
同時レースとは、次の代替案を開始する前に、1つのブランチが進行するのを待つことなく、複数の代替ブランチが開始される場合です。これは、試みが効果的に同時にあることを意味します。追加のネットワークリソースを消費し、使用されていない可能性のある状態を確立するため、実装によって同時レースを回避する必要があります。
Staggered racing can be used whenever a single node of the tree has multiple child nodes. Based on the order determined when building the tree, the first child node will be initiated immediately, followed by the next child node after some delay. Once that second child node is initiated, the third child node (if present) will begin after another delay, and so on until all child nodes have been initiated or one of the child nodes successfully completes its negotiation.
ツリーの単一のノードに複数の子ノードがあるときはいつでも、ずらしてレースを使用できます。ツリーを構築するときに決定された順序に基づいて、最初の子ノードがすぐに開始され、遅延後に次の子ノードが続きます。2番目の子ノードが開始されると、3番目の子ノード（存在する場合）は、すべての子ノードが開始されるか、子ノードの1つが正常に交渉を完了するまで、また、3番目の子ノード（存在する場合）などになります。
Staggered racing attempts can proceed in parallel. Implementations should not terminate an earlier child connection attempt upon starting a secondary child.
ずらしたレースの試みは並行して進むことができます。実装は、セカンダリチャイルドを開始する際に、以前の子接続の試みを終了するべきではありません。
If a child node fails to establish connectivity (as in Section 4.4.1) before the delay time has expired for the next child, the next child should be started immediately.
次の子供の遅延時間が終了する前に（セクション4.4.1のように）、子ノードが接続性を確立できなかった場合、次の子供はすぐに開始する必要があります。
Staggered racing between IP addresses for a generic Connection should follow the Happy Eyeballs algorithm described in [RFC8305]. Guidance for racing when performing ICE can be found in [RFC8421].
一般的な接続のIPアドレス間のずらしたレースは、[RFC8305]で説明されているHappy Eyeballsアルゴリズムに従う必要があります。氷を実行するときのレースのガイダンスは、[RFC8421]にあります。
Generally, the delay before starting a given child node ought to be based on the length of time the previously started child node is expected to take before it succeeds or makes progress in connection establishment. Algorithms like Happy Eyeballs choose a delay based on how long the transport connection handshake is expected to take. When performing staggered races in multiple branch types (such as racing between network interfaces and then racing between IP addresses), a longer delay may be chosen for some branch types. For example, when racing between network interfaces, the delay should also take into account the amount of time it takes to prepare the network interface (such as radio association) and name resolution over that interface in addition to the delay that would be added for a single transport connection handshake.
Generally, the delay before starting a given child node ought to be based on the length of time the previously started child node is expected to take before it succeeds or makes progress in connection establishment.Happy Eyeballsのようなアルゴリズムは、トランスポート接続のハンドシェイクがかかると予想される時間に基づいて遅延を選択します。When performing staggered races in multiple branch types (such as racing between network interfaces and then racing between IP addresses), a longer delay may be chosen for some branch types.For example, when racing between network interfaces, the delay should also take into account the amount of time it takes to prepare the network interface (such as radio association) and name resolution over that interface in addition to the delay that would be added for a単一輸送接続の握手。
Since the staggered delay can be chosen based on dynamic information, such as predicted RTT, implementations should define upper and lower bounds for delay times. These bounds are implementation specific and may differ based on which branch type is being used.
予測されたRTTなどの動的な情報に基づいて、ずらした遅延を選択できるため、実装は遅延時間の上限と下限を定義する必要があります。これらの境界は実装固有であり、どのブランチタイプが使用されているかによって異なる場合があります。
If an implementation or application has a strong preference for one branch over another, the branching node may choose to wait until one child has failed before starting the next. Failure of a leaf node is determined by its protocol negotiation failing or timing out; failure of a parent branching node is determined by all of its children failing.
実装またはアプリケーションが1つのブランチよりも強い好みを持っている場合、分岐ノードは、次の子供が開始する前に1人の子供が故障するまで待つことを選択できます。葉のノードの障害は、プロトコルの交渉が失敗またはタイミングを出すことによって決定されます。親の分岐ノードの障害は、すべての子供が失敗することによって決定されます。
An example in which failover is recommended is a race between a preferred Protocol Stack that uses a proxy and an alternate Protocol Stack that bypasses the proxy. Failover is useful if the proxy is down or misconfigured, but any more aggressive type of racing may end up unnecessarily avoiding a proxy that was preferred by policy.
フェールオーバーが推奨される例は、プロキシとプロキシをバイパスする代替プロトコルスタックを使用する優先プロトコルスタック間のレースです。プロキシがダウンまたは誤解されている場合、フェールオーバーは有用ですが、これ以上の積極的なタイプのレースは、ポリシーによって好まれるプロキシを不必要に回避することになります。
The process of Connection establishment completes when one leaf node of the tree has successfully completed negotiation with the Remote Endpoint or when all nodes of the tree have failed to connect. The first leaf node to complete its connection is then used by the application to send and receive data. This is signaled to the application using the Ready event in the API (Section 7.1 of [RFC9622]).
接続確立のプロセスは、ツリーの1つのリーフノードがリモートエンドポイントとの交渉を正常に完了したとき、またはツリーのすべてのノードが接続に失敗したときに完了します。接続を完了する最初のリーフノードは、アプリケーションによってデータを送信および受信するために使用されます。これは、APIのReadyイベント（[RFC9622]のセクション7.1）を使用してアプリケーションに合図されます。
Successes and failures of a given attempt should be reported up to parent nodes (toward the root of the tree). For example, in the following case, if 1.1.1 fails to connect, it reports the failure to 1.1. Since 1.1 has no other child nodes, it also has failed and reports that failure to 1. Because 1.2 has not yet failed, 1 is not considered to have failed. Since 1.2 has not yet started, it is started and the process continues. Similarly, if 1.1.1 successfully connects, then it marks 1.1 as connected, which propagates to the root node 1. At this point, the Connection as a whole is considered to be successfully connected and ready to process application data.
特定の試みの成功と失敗は、親ノード（ツリーの根元に向かって）に報告する必要があります。たとえば、次の場合、1.1.1が接続に失敗した場合、1.1への失敗を報告します。1.1には他の子ノードがないため、失敗し、1.2がまだ失敗していないため、1は失敗したとは見なされないと報告しています。1.2がまだ開始されていないため、開始され、プロセスが継続されます。同様に、1.1.1が正常に接続すると、1.1が接続されています。これはルートノード1に伝播します。この時点で、接続全体が正常に接続され、アプリケーションデータを処理する準備ができていると見なされます。
1 [www.example.com:443, Any, TCP]
1.1 [www.example.com:443, Wi-Fi, TCP]
1.1.1 [192.0.2.1:443, Wi-Fi, TCP]
1.2 [www.example.com:443, LTE, TCP]
...
If a leaf node has successfully completed its connection, all other attempts should be made ineligible for use by the application for the original request. New connection attempts that involve transmitting data on the network ought not to be started after another leaf node has already successfully completed because the Connection as a whole has now been established. An implementation could choose to let certain handshakes and negotiations complete to gather metrics that influence future connections. Keeping additional connections is generally not recommended because those attempts were slower to connect and may exhibit less desirable properties.
リーフノードが接続を正常に完了した場合、他のすべての試行は、元のリクエストのためにアプリケーションによって使用される資格がないようにする必要があります。ネットワーク上のデータの送信を含む新しい接続試行は、接続全体が現在確立されているため、別のリーフノードがすでに正常に完了した後に開始されるべきではありません。実装は、将来のつながりに影響を与えるメトリックを収集するために、特定の握手と交渉を完了することを選択できます。これらの試みの接続が遅く、望ましい特性がそれほど低くなる可能性があるため、追加の接続を維持することは一般的に推奨されません。
On a per-protocol basis, implementations may select different criteria by which a leaf node is considered to be successfully connected. If the only protocol being used is a transport protocol with a clear handshake, like TCP, then the obvious choice is to declare that node "connected" when the three-way handshake completes. If the only protocol being used is a connectionless protocol, like UDP, the implementation may consider the node fully "connected" the moment it determines a route is present, before sending any packets on the network, see further in Section 4.6.
プロトコルごとに、実装は、リーフノードが正常に接続されていると見なされる異なる基準を選択する場合があります。使用されている唯一のプロトコルが、TCPのような明確な握手を備えたトランスポートプロトコルである場合、明らかな選択は、3方向の握手が完了したときにノードが「接続」されることを宣言することです。使用されている唯一のプロトコルがUDPのようなコネクションレスプロトコルである場合、実装は、ネットワーク上にパケットを送信する前に、ルートが存在する瞬間にノードを完全に「接続」することを検討する場合があります。セクション4.6をさらに参照してください。
Depending on the protocols involved, there is no guarantee that the Remote Endpoint will be notified when the Initiate action is called without any Messages being sent at the same time. Therefore, a passive Endpoint's application may not receive a ConnectionReceived event until it receives the first Message on the new Connection.
関連するプロトコルに応じて、メッセージが送信されることなく開始アクションが呼び出されたときにリモートエンドポイントに通知されるという保証はありません。したがって、パッシブエンドポイントのアプリケーションは、新しい接続で最初のメッセージを受信するまで、Connection Receediveedイベントを受信しない場合があります。
For Protocol Stacks with multiple handshakes, the decision becomes more nuanced. If the Protocol Stack involves both TLS and TCP, an implementation could determine that a leaf node is connected after the TCP handshake is complete, or it can wait for the TLS handshake to complete as well. The benefit of declaring completion when the TCP handshake finishes, and thus stopping the race for other branches of the tree, is reduced burden on the network and Remote Endpoints from further connection attempts that are likely to be abandoned. On the other hand, by waiting until the TLS handshake is complete, an implementation avoids the scenario in which a TCP handshake completes quickly, but TLS negotiation is either very slow or fails altogether in particular network conditions or to a particular endpoint. To avoid the issue of TLS possibly failing, the implementation should not generate a Ready event for the Connection until the TLS handshake is complete.
複数のハンドシェイクのあるプロトコルスタックの場合、決定はより微妙になります。プロトコルスタックにTLSとTCPの両方が含まれる場合、実装により、TCPの握手が完了した後に葉のノードが接続されているか、TLSの握手が完了するのを待つことができます。TCPの握手が終了し、したがってツリーの他のブランチのレースを停止するときに完了を宣言する利点は、放棄される可能性のあるさらなる接続試行からネットワークおよびリモートエンドポイントの負担を軽減します。一方、TLSの握手が完了するまで待つことで、実装により、TCPの握手が迅速に完了するシナリオを回避しますが、TLS交渉は非常に遅いか、特定のネットワーク条件または特定のエンドポイントで完全に失敗します。TLSが失敗する可能性があるという問題を回避するために、TLSの握手が完了するまで、接続の準備が整ったイベントを実装する必要はありません。
If all of the leaf nodes fail to connect during racing, i.e., none of the configurations that satisfy all requirements given in the Transport Properties actually work over the available paths, then the Transport Services System should report an EstablishmentError to the application. An EstablishmentError event should also be generated if the Transport Services System finds no usable candidates to race.
すべてのリーフノードがレース中に接続できない場合、つまり、輸送プロパティで与えられるすべての要件を実際に利用可能なパスで動作させる構成がない場合、輸送サービスシステムはアプリケーションにEndivestiventErrorを報告する必要があります。輸送サービスシステムが使用可能な候補者が競争することができない場合は、設立イベントも生成する必要があります。
Multiplexing several Connections over a single underlying transport connection requires that the multiplexed Connections belong to the same Connection Group (as is indicated by the application using the Clone action). When the underlying transport connection supports multistreaming, the Transport Services System can map each Connection in the Connection Group to a different stream of this connection.
単一の基礎となる輸送接続にわたって複数の接続を多重化するには、多重化された接続が同じ接続グループに属する必要があります（クローンアクションを使用したアプリケーションで示されているように）。基礎となる輸送接続がマルチストリーミングをサポートする場合、輸送サービスシステムは、接続グループ内の各接続をこの接続の異なるストリームにマッピングできます。
For such streams, there is often no explicit connection establishment procedure for the new stream prior to sending data on it (e.g., with SCTP). In this case, the same considerations apply to determining stream establishment as apply to establishing a UDP connection, as discussed in Section 4.4.1. This means that there might not be any "establishment" message (like a TCP SYN).
このようなストリームの場合、データを送信する前に、新しいストリームの明示的な接続確立手順はしばしばありません（例：SCTP）。この場合、セクション4.4.1で説明したように、UDP接続の確立に適用されるストリーム確立を決定することにも同じ考慮事項が適用されます。これは、「確立」メッセージ（TCP Synなど）がない可能性があることを意味します。
While protocols that use an explicit handshake to validate a connection to a peer can be used for racing multiple establishment attempts in parallel, connectionless protocols such as raw UDP do not offer a way to validate the presence of a peer or the usability of a Connection without application feedback. An implementation should consider such a Protocol Stack to be established as soon as the Transport Services System has selected a path on which to send data.
明示的な握手を使用してピアへの接続を検証するプロトコルは、並行して複数の施設の試みをレースするために使用できますが、生のUDPなどの接続のないプロトコルは、ピアの存在や接続の使いやすさを検証する方法を提供しません。アプリケーションフィードバック。実装では、このようなプロトコルスタックが、輸送サービスシステムがデータを送信するパスを選択するとすぐに確立されることを検討する必要があります。
However, this can cause a problem if a specific peer is not reachable over the network using the connectionless protocol or data cannot be exchanged with the peer for any other reason. To handle the lack of an explicit handshake in the underlying protocol, an application can use a Message Framer (Section 6) on top of a connectionless protocol to only mark a specific connection attempt as ready when some data has been received or after some application-level handshake has been performed by the Message Framer.
ただし、Connectionless Protocolまたはデータを他の理由でピアと交換できない場合、特定のピアがネットワーク上で到達できない場合、これは問題を引き起こす可能性があります。基礎となるプロトコルの明示的なハンドシェイクの欠如を処理するために、アプリケーションは、ConnectionLessプロトコルの上にメッセージフレーマー（セクション6）を使用して、一部のデータが受信されたときまたはアプリケーションの後に特定の接続試行をマークすることができます。レベルの握手は、メッセージフレーマーによって実行されました。
When an implementation is asked to Listen, it registers with the system to wait for incoming traffic to the Local Endpoint. If no Local Endpoint Identifier is specified, the implementation should use an ephemeral port.
実装がリッスンを求められると、ローカルエンドポイントへのトラフィックが入るのを待つためにシステムと登録します。ローカルエンドポイント識別子が指定されていない場合、実装は一時的なポートを使用する必要があります。
If the Selection Properties do not require a single network interface or path but allow the use of multiple paths, the Listener object should register for incoming traffic on all of the network interfaces or paths that conform to the Properties. The set of available paths can change over time, so the implementation should monitor network path changes and change the registration of the Listener across all usable paths as appropriate. When using multiple paths, the Listener is generally expected to use the same port for listening on each.
選択プロパティが単一のネットワークインターフェイスまたはパスを必要とせず、複数のパスの使用を許可する場合、リスナーオブジェクトは、プロパティに適合するすべてのネットワークインターフェイスまたはパスの着信トラフィックに登録する必要があります。利用可能なパスのセットは時間とともに変更される可能性があるため、実装はネットワークパスの変更を監視し、必要に応じてすべての使用可能なパスでリスナーの登録を変更する必要があります。複数のパスを使用する場合、リスナーは一般に、それぞれを聞くために同じポートを使用することが期待されます。
If the Selection Properties allow multiple protocols to be used for listening and the implementation supports it, the Listener object should support receiving inbound connections for each eligible protocol on each eligible path.
選択プロパティで複数のプロトコルをリスニングに使用し、実装がサポートする場合、リスナーオブジェクトは、各資格のあるパスで適格な各プロトコルのインバウンド接続の受信をサポートする必要があります。
Connected protocols such as TCP and TLS-over-TCP have a strong mapping between the Local and Remote Endpoint Identifiers (four-tuple) and their protocol connection state. These map to Connection objects. Whenever a new inbound handshake is being started, the Listener should generate a new Connection object and pass it to the application.
TCPやTLS-over-TCPなどの接続されたプロトコルには、ローカルエンドポイント識別子とそのプロトコル接続状態（4項）とそのプロトコル接続状態の間に強いマッピングがあります。これらのマップは接続オブジェクトです。新しいインバウンドハンドシェイクが開始されるたびに、リスナーは新しい接続オブジェクトを生成し、アプリケーションに渡す必要があります。
Connectionless protocols such as UDP and UDP-Lite generally do not provide the same mechanisms that connected protocols do to offer Connection objects. Implementations should wait for incoming packets for connectionless protocols on a listening port and should perform four-tuple matching of packets to existing Connection objects if possible. If a matching Connection object does not exist, an incoming packet from a connectionless protocol should cause a new Connection object to be created.
UDPやUDP-Liteなどのコネクションレスプロトコルは、一般に、接続プロトコルが接続オブジェクトを提供するのと同じメカニズムを提供しません。実装は、リスニングポートのコネクションレスプロトコルの着信パケットを待機し、可能であれば既存の接続オブジェクトにパケットを4対1マッチングする必要があります。一致する接続オブジェクトが存在しない場合、コネクションレスプロトコルからの着信パケットは、新しい接続オブジェクトを作成する必要があります。
Protocols that provide multiplexing of streams can listen for entirely new connections as well as for new subconnections (streams of an already-existing connection). A new stream arrival on an existing connection is presented to the application as a new Connection. This new Connection is grouped with all other Connections that are multiplexed via the same protocol.
ストリームの多重化を提供するプロトコルは、まったく新しい接続と新しいサブコネクション（既存の接続のストリーム）をリッスンできます。既存の接続に新しいストリーム到着が、新しい接続としてアプリケーションに表示されます。この新しい接続は、同じプロトコルを介して多重化された他のすべての接続とグループ化されます。
The most basic mapping for sending a Message is an abstraction of datagrams, in which the transport protocol naturally deals in discrete packets (such as UDP). Each Message here corresponds to a single datagram.
メッセージを送信するための最も基本的なマッピングは、データグラムの抽象化であり、この輸送プロトコルは自然に個別のパケット（UDPなど）で扱われます。ここでの各メッセージは、単一のデータグラムに対応しています。
For protocols that expose byte-streams (such as TCP), the only delineation provided by the protocol is the end of the stream in a given direction. Each Message in this case corresponds to the entire stream of bytes in a direction. These Messages may be quite long, in which case they can be sent in multiple parts.
バイトストリーム（TCPなど）を公開するプロトコルの場合、プロトコルによって提供される唯一の描写は、特定の方向のストリームの終わりです。この場合の各メッセージは、方向のバイトのストリーム全体に対応します。これらのメッセージは非常に長い場合があります。その場合、複数の部分で送信できます。
Protocols that provide framing (such as length-value protocols, or protocols that use delimiters like HTTP/1.1) may support Message sizes that do not fit within a single datagram. Each Message for framing protocols corresponds to a single frame, which may be sent either as a complete Message in the underlying protocol or in multiple parts.
フレーミングを提供するプロトコル（長さと値のプロトコル、またはHTTP/1.1などの区切り文字を使用するプロトコルなど）は、単一のデータグラムに収まらないメッセージサイズをサポートする場合があります。フレーミングプロトコルの各メッセージは、単一のフレームに対応し、基礎となるプロトコルまたは複数の部品の完全なメッセージとして送信できます。
Messages themselves generally consist of bytes passed in the messageData parameter intended to be processed at an application layer. However, Message objects presented through the API can carry associated Message Properties passed through the messageContext parameter. When these are Protocol-specific Properties, they can include metadata that exists separately from a byte encoding. For example, these Properties can include name-value pairs of information, like HTTP header fields. In such cases, Messages might be "empty" insofar as they contain zero bytes in the messageData parameter, but they can still include data in the messageContext that is interpreted by the Protocol Stack.
メッセージ自体は、一般に、アプリケーションレイヤーで処理することを目的としたMESSAGEDATAパラメーターで渡されたバイトで構成されています。ただし、APIを介して表示されるメッセージオブジェクトは、MessageContextパラメーターを通過した関連メッセージプロパティを運ぶことができます。これらがプロトコル固有の特性である場合、バイトエンコーディングとは別に存在するメタデータを含めることができます。たとえば、これらのプロパティには、HTTPヘッダーフィールドのような情報の名前値ペアを含めることができます。そのような場合、メッセージはMESSAGEDATAパラメーターにゼロバイトを含む限り「空」になる可能性がありますが、プロトコルスタックによって解釈されるMESSAGECONTEXTにデータを含めることができます。
The effect of the application sending a Message is determined by the top-level protocol in the established Protocol Stack. That is, if the top-level protocol provides an abstraction of framed Messages over a connection, the receiving application will be able to obtain multiple Messages on that connection, even if the framing protocol is built on a byte-stream protocol like TCP.
メッセージを送信するアプリケーションの効果は、確立されたプロトコルスタックのトップレベルプロトコルによって決定されます。つまり、トップレベルのプロトコルが接続上でフレーム付きメッセージの抽象化を提供する場合、フレーム化プロトコルがTCPのようなバイトストリームプロトコルで構築されている場合でも、受信アプリケーションはその接続で複数のメッセージを取得できます。
The API allows various Properties to be associated with each Message, which should be implemented as discussed below.
APIにより、さまざまなプロパティを各メッセージに関連付けることができます。これは、以下で説明するように実装する必要があります。
msgLifetime:
msglifetime：
This should be implemented by removing the Message from the queue of pending Messages after the Lifetime has expired. A queue of pending Messages within the Transport Services Implementation that have yet to be handed to the Protocol Stack can always support this Property, but once a Message has been sent into the send buffer of a protocol, only certain protocols may support removing it from their send buffer. For example, a Transport Services Implementation cannot remove bytes from a TCP send buffer, while it can remove data from an SCTP send buffer using the partial reliability extension [RFC8303]. When there is no standing queue of Messages within the system, and the Protocol Stack does not support the removal of a Message from the stack's send buffer, this Property may be ignored.
これは、寿命が経過した後に保留中のメッセージのキューからメッセージを削除することにより実装する必要があります。プロトコルスタックにまだ渡されていないトランスポートサービスの実装内で保留中のメッセージのキューは常にこのプロパティをサポートできますが、メッセージがプロトコルの送信バッファーに送信されると、特定のプロトコルのみがそれを削除することをサポートする可能性があります。バッファーを送信します。たとえば、トランスポートサービスの実装では、TCP送信バッファーからバイトを削除することはできませんが、部分信頼性拡張[RFC8303]を使用してSCTP送信バッファーからデータを削除できます。システム内のメッセージのスタンディングキューがなく、プロトコルスタックがスタックの送信バッファーからのメッセージの削除をサポートしていない場合、このプロパティは無視される場合があります。
msgPriority:
msgpriority：
This represents the ability to prioritize a Message over other Messages. This can be implemented by the Transport Services System by reordering Messages that have yet to be handed to the Protocol Stack or by giving relative priority hints to protocols that support priorities per Message. For example, an implementation of HTTP/2 could choose to send Messages of different priority on streams of different priority.
これは、他のメッセージよりもメッセージを優先する機能を表します。これは、プロトコルスタックにまだ渡されていないメッセージを並べ替えるか、メッセージごとの優先順位をサポートするプロトコルに相対的な優先度のヒントを与えることにより、トランスポートサービスシステムによって実装できます。たとえば、HTTP/2の実装は、異なる優先度のストリームで異なる優先度のメッセージを送信することを選択できます。
msgOrdered:
msgordered：
When this is false, it disables the requirement of in-order delivery for protocols that support configurable ordering. When the Protocol Stack does not support configurable ordering, this Property may be ignored.
これが間違っている場合、構成可能な順序付けをサポートするプロトコルの順序配信の要件を無効にします。プロトコルスタックが構成可能な順序付けをサポートしない場合、このプロパティは無視される場合があります。
safelyReplayable:
SafelyReplayable：
When this is true, it means that the Message can be used by a transport mechanism that might deliver it multiple times -- e.g., as a result of racing multiple transports or as part of TCP Fast Open (TFO). Also, protocols that do not protect against duplicated Messages, such as UDP (when used directly, without a protocol layered atop), can only be used with Messages that are safely replayable. When a Transport Services System is permitted to replay Messages, replay protection could be provided by the application.
これが真実である場合、メッセージは、複数の輸送の結果として、またはTCP Fast Open（TFO）の一部として、複数回それを提供する可能性のある輸送メカニズムで使用できることを意味します。また、UDPなどの重複したメッセージから保護しないプロトコル（Protocolが階層化されていない場合）など、安全に再生可能なメッセージでのみ使用できます。輸送サービスシステムがメッセージを再生することを許可されている場合、アプリケーションによってリプレイ保護を提供できます。
final:
ファイナル：
When this is true, it means that the sender will not send any further Messages. The Connection need not be closed (if the Protocol Stack supports half-closed operations, like TCP). Any Messages sent after a Message marked Final will result in a SendError.
これが真実である場合、それは送信者がさらなるメッセージを送信しないことを意味します。接続を閉じる必要はありません（プロトコルスタックがTCPのような半分閉鎖操作をサポートする場合）。ファイナルとマークされたメッセージの後に送信されたメッセージは、SendErrorになります。
msgChecksumLen:
msgchecksumlen：
When this is set to any value other than Full Coverage, it sets the minimum protection in protocols that allow limiting the checksum length (e.g., UDP-Lite). If the Protocol Stack does not support checksum length limitation, this Property may be ignored.
これが完全なカバレッジ以外の任意の値に設定されると、チェックサムの長さを制限できるプロトコルの最小保護を設定します（例：UDP-lite）。プロトコルスタックがチェックサムの長さの制限をサポートしていない場合、このプロパティは無視される場合があります。
msgReliable:
msgreliable：
When true, this Property specifies that the Message must be reliably transmitted. When false, and if unreliable transmission is supported by the underlying protocol, then the Message should be unreliably transmitted. If the underlying protocol does not support unreliable transmission, the Message should be reliably transmitted.
Trueの場合、このプロパティは、メッセージを確実に送信する必要があることを指定します。Falseの場合、および信頼性の低い送信が基礎となるプロトコルによってサポートされている場合、メッセージは信頼できないほど送信される必要があります。基礎となるプロトコルが信頼性の低い送信をサポートしていない場合、メッセージは確実に送信する必要があります。
msgCapacityProfile:
msgcapacityProfile：
When true, this expresses a wish to override the Generic Connection Property connCapacityProfile for this Message. Depending on the value, this can, for example, be implemented by changing the Differentiated Services Code Point (DSCP) value of the associated packet (note that the guidelines in Section 6 of [RFC7657] apply; for example, the DSCP value should not be changed for different packets within a reliable transport protocol session or DCCP connection).
真実の場合、これはこのメッセージに対して一般的な接続プロパティconncapacityprofileをオーバーライドする希望を表しています。値に応じて、これは、たとえば、関連するパケットの差別化されたサービスコードポイント（DSCP）値を変更することで実装できます（[RFC7657]のセクション6のガイドラインが適用されます。たとえば、DSCP値はそうすべきではありません。信頼性の高い輸送プロトコルセッションまたはDCCP接続内のさまざまなパケットに対して変更されます）。
noFragmentation:
nofragmentation：
Setting this avoids network-layer fragmentation. Messages exceeding the transport's current estimate of its maximum packet size (the singularTransmissionMsgMaxLen Connection Property) can result in transport segmentation when permitted or generate an error. When used with transports running over IPv4, the Don't Fragment (DF) bit should be set to avoid on-path IP fragmentation [RFC8304].
これを設定すると、ネットワーク層の断片化が回避されます。トランスポートの最大パケットサイズ（SingularTransmissionMsGmaxlen接続プロパティ）の現在の推定値を超えるメッセージは、許可された場合、またはエラーを生成すると輸送セグメンテーションにつながる可能性があります。IPv4を介して実行されるトランスポートで使用する場合、オンパスIP断片化を避けるために、断片（DF）ビットを設定する必要があります[RFC8304]。
noSegmentation:
ノーズグラメンテーション：
When set, this Property limits the Message size to the transport's current estimate of its maximum packet size (the singularTransmissionMsgMaxLen Connection Property). Messages larger than this size generate an error. Setting this avoids transport-layer segmentation and network-layer fragmentation. When used with transports running over IPv4, the DF bit should be set to avoid on-path IP fragmentation ([RFC8304]).
設定すると、このプロパティは、メッセージサイズをトランスポートの最大パケットサイズ（SingularTransmissionMsgmaxlen接続プロパティ）の現在の推定値に制限します。このサイズよりも大きいメッセージはエラーを生成します。これを設定すると、輸送層のセグメンテーションとネットワーク層の断片化が回避されます。IPv4を介して実行されるトランスポートで使用する場合、DFビットを設定して、パス上のIP断片化を避ける必要があります（[RFC8304]）。
The application should be notified (using a Sent, Expired, or SendError event) whenever a Message or partial Message has been consumed by the Protocol Stack or has failed to send. The time at which a Message is considered to have been consumed by the Protocol Stack may vary depending on the protocol. For example, for a basic datagram protocol like UDP, this may correspond to the time when the packet is sent into the interface driver. For a protocol that buffers data in queues, like TCP, this may correspond to when the data has entered the send buffer. The time at which a Message failed to send is when the Transport Services Implementation (including the Protocol Stack) has experienced a failure related to sending; this can depend on protocol-specific timeouts.
プロトコルスタックによってメッセージまたは部分的なメッセージが消費された場合、または送信に失敗した場合は、アプリケーションに通知する必要があります（送信、期限切れ、またはSendErrorイベントを使用してください）。プロトコルスタックによってメッセージが消費されたと見なされる時間は、プロトコルによって異なる場合があります。たとえば、UDPのような基本的なデータグラムプロトコルの場合、これはパケットがインターフェイスドライバーに送信される時間に対応する場合があります。TCPなどのキュー内のデータをバッファするプロトコルの場合、これはデータが送信バッファーに入力したときに対応する場合があります。メッセージが送信に失敗した時間は、トランスポートサービスの実装（プロトコルスタックを含む）が送信に関連する失敗を経験したときです。これは、プロトコル固有のタイムアウトに依存する可能性があります。
Sending multiple Messages can incur high overhead if each needs to be enqueued separately (e.g., each Message might involve a context switch between the application and the Transport Services System). To avoid this, the application can indicate a batch of Send actions through the API. When this is used, the implementation can defer the processing of Messages until the batch is complete.
複数のメッセージを送信すると、それぞれを個別にエンキューする必要がある場合、オーバーヘッドが高い場合があります（たとえば、各メッセージには、アプリケーションと輸送サービスシステムの間のコンテキストスイッチが含まれる場合があります）。これを回避するために、アプリケーションはAPIを介して送信アクションのバッチを示すことができます。これを使用すると、バッチが完了するまで、実装がメッセージの処理を延期できます。
Similar to sending, receiving a Message is determined by the top-level protocol in the established Protocol Stack. The main difference with receiving is that the size and boundaries of the Message are not known beforehand. The application can communicate the parameters for the Message in its Receive action, which can help the Transport Services Implementation know how much data to deliver and when. For example, if the application only wants to receive a complete Message, the implementation should wait until an entire Message (datagram, stream, or frame) is read before delivering any Message content to the application. This requires the implementation to understand where Messages end, either via a supplied Message Framer or because the top-level protocol in the established Protocol Stack preserves Message boundaries. The application can also control the flow of received data by specifying the minimum and maximum number of bytes of Message content it wants to receive at one time.
送信と同様に、メッセージの受信は、確立されたプロトコルスタックのトップレベルプロトコルによって決定されます。受信との主な違いは、メッセージのサイズと境界が事前に知られていないことです。アプリケーションは、受信アクションのメッセージのパラメーターを通知できます。これにより、トランスポートサービスの実装がいつ配信するデータの量を知ることができます。たとえば、アプリケーションが完全なメッセージのみを受信したい場合、[メッセージ]コンテンツをアプリケーションに配信する前に、メッセージ全体（データグラム、ストリーム、またはフレーム）が読み取られるまで実装が待機する必要があります。これには、提供されたメッセージフレーマーを介して、または確立されたプロトコルスタックのトップレベルのプロトコルがメッセージの境界を保持するため、メッセージがどこで終わるかを理解するための実装が必要です。また、アプリケーションは、一度に受信したいメッセージコンテンツの最小値と最大バイト数を指定することにより、受信データのフローを制御できます。
If a Connection finishes before a requested Receive action can be satisfied, the Transport Services System should deliver any outstanding partial Message content; if none is available, the system should indicate that there will be no additional received Messages.
要求された受信アクションが満たされる前に接続が終了する場合、トランスポートサービスシステムは、未解決の部分メッセージコンテンツを提供する必要があります。何も利用できない場合、システムは追加の受信メッセージがないことを示す必要があります。
Several protocols allow sending higher-level protocol or application data during their protocol establishment, such as TFO [RFC7413] and TLS 1.3 [RFC8446]. This approach is referred to as sending Zero-RTT (0-RTT) data. This is a desirable feature, but it poses challenges to an implementation that uses racing during Connection establishment.
いくつかのプロトコルにより、TFO [RFC7413]やTLS 1.3 [RFC8446]など、プロトコルの確立中に高レベルのプロトコルまたはアプリケーションデータを送信できます。このアプローチは、Zero-RTT（0-RTT）データの送信と呼ばれます。これは望ましい機能ですが、接続施設中にレースを使用する実装に課題をもたらします。
The application can express its preference for sending Messages as 0-RTT data by using the zeroRttMsg Selection Property on the Preconnection. Then, the application can provide the Message to send as 0-RTT data via the InitiateWithSend action. In order to be sent as 0-RTT data, the Message needs to be marked with the safelyReplayable Property. In general, 0-RTT data may be replayed (for example, if a TCP SYN contains data, and the SYN is retransmitted, the data will be retransmitted as well but may be considered a new connection instead of a retransmission). When racing connections, different leaf nodes have the opportunity to send the same data independently. If data is truly safely replayable, this is permissible.
アプリケーションは、事前接続でZerortTMSG選択プロパティを使用して、メッセージを0-RTTデータとして送信するという好みを表すことができます。次に、アプリケーションは、IntiateWithSendアクションを介して0-RTTデータを送信するメッセージを提供できます。0-RTTデータとして送信されるには、メッセージをSafely-Leplayableプロパティでマークする必要があります。一般に、0-RTTデータが再生される場合があります（たとえば、TCP Synにデータが含まれ、Synが再送信される場合、データも再送信されますが、再送信の代わりに新しい接続と見なされる場合があります）。レース接続の場合、異なる葉のノードは同じデータを独立して送信する機会があります。データが本当に安全に再生可能である場合、これは許容されます。
Once the application has provided its 0-RTT data, a Transport Services Implementation should keep a copy of this data and provide it to each new leaf node that is started and for which a protocol instance supporting 0-RTT is being used. Note that the amount of data that can actually be sent as 0-RTT data varies by protocol, so any given Protocol Stack might only consume part of the saved data prior to becoming established. The implementation needs to keep track of how much data a particular Protocol Stack has consumed and ensure that any pending 0-RTT-eligible data from the application is handled before subsequent Messages.
アプリケーションが0-RTTデータを提供すると、トランスポートサービスの実装はこのデータのコピーを保持し、開始され、0-RTTをサポートするプロトコルインスタンスが使用されている各新しいリーフノードに提供する必要があります。0-RTTデータとして実際に送信できるデータの量は、プロトコルによって異なるため、特定のプロトコルスタックは、確立される前に保存されたデータの一部のみを消費する可能性があることに注意してください。実装は、特定のプロトコルスタックが消費したデータの量を追跡し、アプリケーションからの0-RTT資格のあるデータが後続のメッセージの前に処理されることを保証する必要があります。
It is also possible for Protocol Stacks within a particular leaf node to use a 0-RTT handshake in a lower-level protocol without any safely replayable application data if a higher-level protocol in the stack has idempotent handshake data to send. For example, TFO could use a Client Hello from TLS as its 0-RTT data without any data being provided by the application.
また、特定のリーフノード内のプロトコルスタックは、スタック内の高レベルのプロトコルに送信するためのアイデル型ハンドシェイクデータがある場合、安全に再生可能なアプリケーションデータなしで低レベルのプロトコルで0-RTTハンドシェイクを使用することも可能です。たとえば、TFOは、アプリケーションで提供されるデータを使用せずに、TLSのクライアントHelloを0-RTTデータとして使用できます。
0-RTT handshakes often rely on previous state, such as TFO cookies, previously established TLS tickets, or out-of-band distributed pre-shared keys (PSKs). Implementations should be aware of security concerns around using these tokens across multiple addresses or paths when racing. In the case of TLS, any given ticket or PSK should only be used on one leaf node, since servers will likely reject duplicate tickets in order to prevent replays (see Section 8.1 of [RFC8446]). If implementations have multiple tickets available from a previous connection, each leaf node attempt can use a different ticket. In effect, each leaf node will send the same early application data, but the data will be encoded (encrypted) differently on the wire.
0-RTTの握手は、多くの場合、TFO Cookie、以前に確立されたTLSチケット、または帯域外配布された事前共有キー（PSK）などの以前の状態に依存しています。実装は、レース時に複数のアドレスまたはパスでこれらのトークンを使用することに関するセキュリティの懸念に注意する必要があります。TLSの場合、任意のチケットまたはPSKは1つのリーフノードでのみ使用する必要があります。これは、サーバーがリプレイを防ぐために重複チケットを拒否する可能性が高いためです（[RFC8446]のセクション8.1を参照）。実装が以前の接続から複数のチケットを使用できる場合、各リーフノードの試行では別のチケットを使用できます。実際には、各リーフノードは同じ初期のアプリケーションデータを送信しますが、データはワイヤー上で異なるエンコード（暗号化）されます。
Message Framers are functions that define simple transformations between application Message data and raw transport protocol data. Generally, a Message Framer implements a simple application protocol that can be provided either by the Transport Services implementation or by the application. It is optional for Transport Services Implementations to provide Message Framers: the API specification [RFC9622] does not prescribe any particular Message Framers to be implemented. A Framer can encapsulate or encode outbound Messages, decapsulate or decode inbound data into Messages, and implement parts of protocols that do not directly map to application Messages (such as protocol handshakes or preludes before Message exchange).
メッセージフレーマーは、アプリケーションメッセージデータと生の輸送プロトコルデータとの間の単純な変換を定義する関数です。一般的に、メッセージフレーマーは、トランスポートサービスの実装またはアプリケーションによって提供できる単純なアプリケーションプロトコルを実装します。トランスポートサービスの実装がメッセージフレーマーを提供することはオプションです。API仕様[RFC9622]は、実装する特定のメッセージフレーマーを規定していません。フレーマーは、アウトバウンドメッセージをカプセル化またはエンコードし、インバウンドデータをメッセージに脱カプセル化またはデコードし、アプリケーションメッセージに直接マッピングしないプロトコルの一部を実装できます（メッセージ交換前のプロトコルハンドシェイクまたはプレリュードなど）。
While many protocols can be represented as Message Framers, for the purposes of the Transport Services API, these are ways for applications or application frameworks to define their own Message parsing to be included within a Connection's Protocol Stack. As an example, TLS is a protocol that is by default built into the Transport Services API, even though it could also serve the purpose of framing data over TCP.
トランスポートサービスAPIの目的のために、多くのプロトコルをメッセージフレーマーとして表現できますが、これらはアプリケーションまたはアプリケーションフレームワークが接続のプロトコルスタックに含まれる独自のメッセージ解析を定義する方法です。例として、TLSは、TCPを介してデータをフレーミングする目的にも役立つにもかかわらず、デフォルトでトランスポートサービスAPIに組み込まれているプロトコルです。
Most Message Framers fall into one of two categories:
ほとんどのメッセージフレーマーは、2つのカテゴリのいずれかに分類されます。
* Header-prefixed record formats, such as a basic Type-Length-Value (TLV) structure
* 基本的なタイプ長値（TLV）構造などのヘッダーが育てたレコード形式
* Delimiter-separated formats, such as HTTP/1.1
* HTTP/1.1などの区切り文字分離形式
Common Message Framers can be provided by a Transport Services Implementation, but an implementation ought to allow custom Message Framers to be defined by the application or some other piece of software. This section describes one possible API for defining Message Framers as an example.
一般的なメッセージフレーマーは、トランスポートサービスの実装によって提供できますが、実装は、アプリケーションまたは他のソフトウェアによってカスタムメッセージフレーマーを定義できるようにする必要があります。このセクションでは、メッセージフレーマーを例として定義するための1つのAPIについて説明します。
A Message Framer is primarily defined by the code that handles events for a Framer implementation, specifically how it handles inbound and outbound data parsing. The function that implements custom framing logic will be referred to as the "Framer implementation", which may be provided by a Transport Services Implementation or the application itself. The Message Framer holds a reference to the object or function within the main Connection implementation that delivers events to the custom Framer implementation whenever data is ready to be parsed or framed.
メッセージフレーマーは、主に、フレーマーの実装のためのイベントを処理するコード、特にインバウンドデータの解析とアウトバウンドデータの処理方法によって定義されます。カスタムフレーミングロジックを実装する関数は、「フレーマーの実装」と呼ばれます。これは、トランスポートサービスの実装またはアプリケーション自体によって提供される場合があります。メッセージframerは、データを解析またはフレーム化する準備ができたときにカスタムフレーマーの実装にイベントを配信するメイン接続実装内のオブジェクトまたは関数への参照を保持します。
The API examples in this section use the notation conventions for the Transport Services API defined in Section 1.1 of [RFC9622].
このセクションのAPIの例は、[RFC9622]のセクション1.1で定義されている輸送サービスAPIの表記規則を使用します。
The Transport Services Implementation needs to ensure that all of the events and actions taken on a Message Framer are synchronized to ensure consistent behavior. For example, some of the actions defined below (such as PrependFramer and StartPassthrough) modify how data flows in a Protocol Stack and require synchronization with sending and parsing data in the Message Framer.
トランスポートサービスの実装では、一貫した動作を確保するために、フレーマーのメッセージフレーマーで行われたすべてのイベントとアクションが同期されるようにする必要があります。たとえば、以下に定義されているアクションの一部（PrependFramerやStartPassthroughなど）は、プロトコルスタック内のデータの流れがどのように流れ、メッセージフレーマーのデータの送信と解析と同期する必要があるかを変更します。
When a Connection establishment attempt begins, an event can be delivered to notify the Framer implementation that a new Connection is being created. Similarly, a Stop event can be delivered when a Connection is being torn down. The Framer implementation can use the Connection object to look up specific Properties of the Connection or the network being used that may influence how to frame Messages.
接続確立の試みが開始されると、新しい接続が作成されていることをフレーマーの実装に通知するためにイベントを配信できます。同様に、接続が取り壊されているときに停止イベントを配信できます。Framerの実装は、接続オブジェクトを使用して、メッセージをフレーム化する方法に影響を与える可能性のある接続または使用されているネットワークの特定のプロパティを検索できます。
MessageFramer -> Start<connection>
MessageFramer -> Stop<connection>
When a Message Framer generates a Start event, the Framer implementation has the opportunity to start writing some data prior to the Connection delivering its Ready event. This allows the implementation to communicate control data to the Remote Endpoint that can be used to parse Messages.
メッセージフレーマーがスタートイベントを生成すると、Framerの実装は、接続が準備が整ったイベントを提供する前に、いくつかのデータの書き込みを開始する機会があります。これにより、実装は、メッセージを使用してメッセージを解析するために使用できるリモートエンドポイントにコントロールデータを通知できます。
Once the Framer implementation has completed its setup or handshake, it can indicate to the application that it is ready for handling data with this call.
Framerの実装がセットアップまたは握手を完了すると、この呼び出しでデータを処理する準備ができていることをアプリケーションに示すことができます。
MessageFramer.MakeConnectionReady(connection)
Similarly, when a Message Framer generates a Stop event, the Framer implementation has the opportunity to write some final data or clear up its local state before the Closed event is delivered to the application. The Framer implementation can indicate that it has finished with this call.
同様に、メッセージフレーマーがストップイベントを生成すると、フレーマーの実装は、閉じたイベントがアプリケーションに配信される前に、いくつかの最終データを書き込むか、地元の状態をクリアする機会があります。フレーマーの実装は、この呼び出しで終了したことを示すことができます。
MessageFramer.MakeConnectionClosed(connection)
If the implementation encounters a fatal error at any time, it can also cause the Connection to fail and provide an error.
実装がいつでも致命的なエラーに遭遇すると、接続が失敗し、エラーが発生する可能性があります。
MessageFramer.FailConnection(connection, error)
Should the Framer implementation deem the candidate selected during racing unsuitable, it can signal this to the Transport Services API by failing the Connection prior to marking it as ready. If there are no other candidates available, the Connection will fail. Otherwise, the Connection will select a different candidate and the Message Framer will generate a new Start event.
Framerの実装が、レース中に選択された候補者を不適切に選択したと判断した場合、準備が整っている前に接続に失敗することにより、これをトランスポートサービスAPIに信号することができます。他に利用可能な候補者がいない場合、接続は失敗します。それ以外の場合、接続は別の候補を選択し、メッセージフレーマーは新しいスタートイベントを生成します。
Before an implementation marks a Message Framer as ready, it can also dynamically add a protocol or Framer above it in the stack. This allows protocols that need to add TLS conditionally, like STARTTLS [RFC3207], to modify the Protocol Stack based on a handshake result.
実装が準備が整ったメッセージフレーマーをマークする前に、スタック内の上にプロトコルまたはフレーマーを動的に追加することもできます。これにより、StartTLS [RFC3207]のように条件付きでTLSを追加する必要があるプロトコルが、ハンドシェイク結果に基づいてプロトコルスタックを変更できます。
otherFramer := NewMessageFramer()
MessageFramer.PrependFramer(connection, otherFramer)
A Message Framer might also choose to go into a passthrough mode once an initial exchange or handshake has been completed, such as the STARTTLS case mentioned above. This can also be useful for proxy protocols like SOCKS [RFC1928] or HTTP CONNECT [RFC9110]. In such cases, a Message Framer implementation can initially intercept Messages being sent and received and subsequently indicate that no further processing is needed.
Framerは、上記のStartTLSケースのように、最初の交換または握手が完了すると、パススルーモードに移動することもできます。これは、ソックス[RFC1928]やHTTP Connect [RFC9110]などのプロキシプロトコルにも役立ちます。そのような場合、メッセージフレーマーの実装は、最初に送信および受信されるメッセージを傍受することができ、その後、それ以上の処理が必要ないことを示します。
MessageFramer.StartPassthrough()
Message Framers generate an event whenever a Connection sends a new Message. The parameters to the event align with the Send action in the API (Section 9.2 of [RFC9622]).
メッセージフレーマーは、接続が新しいメッセージを送信するたびにイベントを生成します。イベントのパラメーターは、APIの送信アクション（[RFC9622]のセクション9.2）と一致します。
MessageFramer
|
V
NewSentMessage<connection, messageData, messageContext, endOfMessage>
Upon receiving this event, a Framer implementation is responsible for performing any necessary transformations and sending the resulting data back to the Message Framer, which, in turn, will send it to the next protocol. To improve performance, implementations should ensure that there is a way to pass the original data through without copying.
このイベントを受信すると、フレーマーの実装が必要な変換を実行し、結果のデータをメッセージフレーマーに送り返し、次のプロトコルに送信します。パフォーマンスを改善するには、実装がコピーせずに元のデータを通過させる方法があることを確認する必要があります。
MessageFramer.Send(connection, messageData)
To provide an example, a simple protocol that adds the length of the Message data as a header would receive the NewSentMessage event, create a data representation of the length of the Message data, and then send a block of data that is the concatenation of the length header and the original Message data.
例を提供するために、メッセージデータの長さをヘッダーとして追加する単純なプロトコルは、NewsEntMessageイベントを受信し、メッセージデータの長さのデータ表現を作成し、次に、長さヘッダーと元のメッセージデータ。
In order to parse a received flow of data into Messages, the Message Framer notifies the Framer implementation whenever new data is available to parse.
受信したデータのフローをメッセージに解析するために、メッセージフレーマーは、新しいデータが解析できるたびにフレイマーの実装に通知します。
The parameters to the events and calls for receiving data with a Framer align with the Receive action in the API (Section 9.3 of [RFC9622]).
イベントのパラメーターと、Framerを使用してデータを受信する必要があります。APIの受信アクション（[RFC9622]のセクション9.3）。
MessageFramer -> HandleReceivedData<connection>
Upon receiving this event, the Framer implementation can inspect the inbound data. The data is parsed from a particular cursor representing the unprocessed data. The application requests a specific amount of data it needs to have available in order to parse. If the data is not available, the parse fails.
このイベントを受信すると、Framerの実装はインバウンドデータを検査できます。データは、未処理のデータを表す特定のカーソルから解析されます。アプリケーションは、解析するために利用可能な特定の量のデータを要求します。データが利用できない場合、解析は失敗します。
MessageFramer.Parse(connection, minimumIncompleteLength, maximumLength)
|
V
(messageData, messageContext, endOfMessage)
The Framer implementation can directly advance the receive cursor once it has parsed data to effectively discard data (for example, discard a header once the content has been parsed).
Framerの実装は、データを解析してデータを効果的に破棄すると、受信カーソルを直接進めることができます（たとえば、コンテンツが解析されたらヘッダーを破棄します）。
To deliver a Message to the application, the Framer implementation can either directly deliver data that it has allocated or deliver a range of data directly from the underlying transport and simultaneously advance the receive cursor.
アプリケーションにメッセージを配信するために、Framerの実装は、基礎となるトランスポートから直接データを割り当てたデータを直接配信するか、同時に受信カーソルを前進させることができます。
MessageFramer.AdvanceReceiveCursor(connection, length)
MessageFramer.DeliverAndAdvanceReceiveCursor(connection, messageContext,
length, endOfMessage)
MessageFramer.Deliver(connection, messageContext, messageData,
endOfMessage)
Note that MessageFramer.DeliverAndAdvanceReceiveCursor allows the Framer implementation to earmark bytes as part of a Message even before they are received by the transport. This allows the delivery of very large Messages without requiring the implementation to directly inspect all of the bytes.
messageframer.deliverandadvancereceivecursorを使用すると、輸送が受信される前であっても、メッセージの一部としてフレーマーの実装がバイトを獲得できるようにすることに注意してください。これにより、すべてのバイトを直接検査するために実装を必要とせずに非常に大きなメッセージを配信できます。
To provide an example, a simple protocol that parses the length of the Message data as a header value would receive the HandleReceivedData event and call Parse with a minimum and maximum set to the length of the header field. Once the parse succeeded, it would call AdvanceReceiveCursor with the length of the header field and then call DeliverAndAdvanceReceiveCursor with the length of the body that was parsed from the header, marking the new Message as complete.
例を提供するために、メッセージデータの長さをヘッダー値として解析する単純なプロトコルは、HandlereceivedDataイベントを受信し、ヘッダーフィールドの長さに最小と最大設定でParseを呼び出します。解析が成功すると、ヘッダーフィールドの長さでAdvancereceivecursorを呼び出し、ヘッダーから解析された身体の長さでDerverandadadvancereceivecursorを呼び出し、新しいメッセージを完全にマークします。
Once a Connection is established, the Transport Services API allows applications to interact with the Connection by modifying or inspecting Connection Properties. A Connection can also generate error events in the form of SoftError events.
接続が確立されると、Transport Services APIにより、接続プロパティを変更または検査することにより、アプリケーションが接続と対話できます。接続は、柔軟なイベントの形でエラーイベントを生成することもできます。
The set of Connection Properties that are supported for setting and getting on a Connection are described in [RFC9622]. For any Properties that are generic and, thus, could apply to all protocols being used by a Connection, the Transport Services Implementation should store the Properties in storage common to all protocols and notify the Protocol Stack as a whole whenever the Properties have been modified by the application. [RFC8303] and [RFC8304] offer guidance on how to do this for TCP, Multipath TCP (MPTCP), SCTP, UDP, and UDP-Lite; see Section 10 for a description of a backtracking method to find the relevant protocol primitives using these documents. For Protocol-specific Properties, such as the User Timeout that applies to TCP, the Transport Services Implementation only needs to update the relevant protocol instance.
接続の設定と取得にサポートされる接続プロパティのセットは、[RFC9622]で説明されています。一般的なプロパティでは、接続で使用されているすべてのプロトコルに適用できるプロパティの場合、トランスポートサービスの実装は、すべてのプロトコルに共通するストレージにプロパティを保存し、プロパティが変更された場合はいつでもプロトコルスタック全体に通知する必要があります。アプリケーション。[RFC8303]および[RFC8304]は、TCP、MultiPath TCP（MPTCP）、SCTP、UDP、およびUDP-Liteのこれを行う方法に関するガイダンスを提供します。これらのドキュメントを使用して関連するプロトコルプリミティブを見つけるには、バックトラッキング方法の説明についてはセクション10を参照してください。TCPに適用されるユーザータイムアウトなどのプロトコル固有のプロパティの場合、交通サービスの実装は、関連するプロトコルインスタンスを更新するだけで必要です。
Some Connection Properties might apply to multiple protocols within a Protocol Stack. Depending on the specific Property, it might be appropriate to apply the Property across multiple protocols simultaneously or only apply it to one protocol. In general, the Transport Services Implementation should allow the protocol closest to the application to interpret Connection Properties and, potentially, modify the set of Connection Properties passed down to the next protocol in the stack. For example, if the application has requested to use keep-alives with the keepAlive Property, and the Protocol Stack contains both HTTP/2 and TCP, the HTTP/2 protocol can choose to enable its own keep-alives to satisfy the application request and disable TCP-level keep-alives. For cases where the application needs to have fine-grained per-protocol control, the Transport Services Implementation can expose Protocol-specific Properties.
一部の接続プロパティは、プロトコルスタック内の複数のプロトコルに適用される場合があります。特定のプロパティに応じて、複数のプロトコルに同時にプロパティを適用するか、1つのプロトコルにのみ適用することが適切かもしれません。一般に、トランスポートサービスの実装により、プロトコルがアプリケーションに最も近いプロトコルが接続プロパティを解釈し、潜在的に、スタック内の次のプロトコルに渡された接続プロパティのセットを変更する必要があります。たとえば、アプリケーションがKeepAliveプロパティを使用してKeep-Alivesを使用するように要求し、プロトコルスタックにHTTP/2とTCPの両方が含まれている場合、HTTP/2プロトコルは、独自のKeep-Alivesがアプリケーションリクエストを満たすことを可能にすることを選択できます。TCPレベルのKeep-Alivesを無効にします。アプリケーションが細粒のプロトコルごとの制御を持つ必要がある場合、輸送サービスの実装はプロトコル固有の特性を公開できます。
If an error is encountered in setting a Property (for example, if the application tries to set a TCP-specific Property on a Connection that is not using TCP), the action must fail gracefully. The application must be informed of the error but the Connection itself must not be terminated.
プロパティの設定でエラーが発生した場合（たとえば、アプリケーションがTCPを使用していない接続にTCP固有のプロパティを設定しようとする場合）、アクションは優雅に失敗する必要があります。アプリケーションにエラーを通知する必要がありますが、接続自体を終了してはなりません。
When protocol instances in the Protocol Stack report generic or protocol-specific errors, the API will deliver them to the application as SoftError events. These allow the application to be informed of ICMP errors and other similar events.
プロトコルスタックのプロトコルインスタンスがジェネリックまたはプロトコル固有のエラーをレポートする場合、APIはそれらをSofterorイベントとしてアプリケーションに配信します。これらにより、アプリケーションにICMPエラーやその他の同様のイベントを通知することができます。
For applications that do not need in-order delivery of Messages, the Transport Services Implementation may distribute Messages of a single Connection across several underlying transport connections or multiple streams of multistreaming connections between endpoints, as long as all of these satisfy the Selection Properties. The Transport Services Implementation will then hide this connection management and only expose a single Connection object, which we call a Pooled Connection. This is in contrast to Connection Groups, which explicitly expose combined treatment of Connections, giving the application control over multiplexing, for example.
メッセージの順序配信を必要としないアプリケーションの場合、トランスポートサービスの実装は、これらすべてが選択プロパティを満たしている限り、いくつかの基礎となる輸送接続またはエンドポイント間のマルチストリーミング接続の複数のストリームにわたって単一の接続のメッセージを配布する場合があります。トランスポートサービスの実装は、この接続管理を非表示にし、プールされた接続と呼ばれる単一の接続オブジェクトのみを公開します。これは、接続グループとは対照的であり、接続の組み合わせの処理を明示的に公開し、たとえばマルチプレックスのアプリケーション制御を提供します。
Pooled Connections can be useful when the application using the Transport Services System implements a protocol such as HTTP, which employs request/response pairs and does not require in-order delivery of responses. This enables implementations of Transport Services Systems to realize transparent connection coalescing and connection migration and to perform per-Message endpoint and path selection by choosing among multiple underlying connections.
プールされた接続は、トランスポートサービスシステムを使用するアプリケーションが、リクエスト/応答ペアを使用し、応答の順序配信を必要としないHTTPなどのプロトコルを実装する場合に役立ちます。これにより、トランスポートサービスシステムの実装により、透明な接続の合体と接続の移行が実現され、複数の基礎となる接続から選択することにより、メッセージごとのエンドポイントとパス選択を実行できます。
When a path change occurs, e.g., when the IP address of an interface changes or a new interface becomes available, the Transport Services Implementation is responsible for notifying the protocol instance of the change. The path change may interrupt connectivity on a path for an active Connection or provide an opportunity for a transport that supports multipath or migration to adapt to the new paths. Note that, in the model of the Transport Services API, migration is considered a part of multipath connectivity; it is just a limiting policy on multipath usage. If the multipath Selection Property is set to Disabled, migration is disallowed.
たとえば、インターフェイスのIPアドレスが変更されるか、新しいインターフェイスが利用可能になった場合、パスの変更が発生したとき、トランスポートサービスの実装は、プロトコルインスタンスの変更を通知する責任があります。パスの変更は、アクティブな接続のパスでの接続性を中断したり、マルチパスや移行をサポートして新しいパスに適応する輸送の機会を提供する場合があります。輸送サービスAPIのモデルでは、移行はマルチパス接続の一部と見なされていることに注意してください。これは、マルチパスの使用に関する制限ポリシーです。マルチパス選択プロパティが無効に設定されている場合、移行は許可されていません。
For protocols that do not support multipath or migration, the protocol instances should be informed of the path change but should not be forcibly disconnected if the previously used path becomes unavailable. There are many common usage scenarios that can lead to a path becoming temporarily unavailable and then recovering before the transport protocol reaches a timeout error. These are particularly common using mobile devices. Examples include:
マルチパスや移行をサポートしないプロトコルの場合、プロトコルインスタンスにパスの変更を通知する必要がありますが、以前に使用されたパスが利用できなくなった場合は強制的に切断されるべきではありません。多くの一般的な使用法シナリオがあり、パスが一時的に利用できなくなり、輸送プロトコルがタイムアウトエラーに達する前に回復することができます。これらは、モバイルデバイスを使用して特に一般的です。例は次のとおりです。
* an Ethernet cable becoming unplugged and then plugged back in;
* イーサネットケーブルが抜かれてから戻ってきました。
* a device losing a Wi-Fi signal while a user is in an elevator and reattaching when the user leaves the elevator; and
* ユーザーがエレベーターに入っているときにWi-Fi信号を失うデバイスは、ユーザーがエレベーターを離れると再触媒します。そして
* a user losing the radio signal while riding a train through a tunnel.
* トンネルを通って電車に乗っているときに電波信号を失うユーザー。
If the device is able to rejoin a network with the same IP address, a stateful transport connection can generally resume. Thus, while it is useful for a protocol instance to be aware of a temporary loss of connectivity, the Transport Services Implementation should not aggressively close Connections in these scenarios.
デバイスが同じIPアドレスでネットワークに再び参加できる場合、ステートフルな輸送接続が一般的に再開できます。したがって、プロトコルインスタンスが一時的な接続の損失を認識することは有用ですが、これらのシナリオでは、輸送サービスの実装が積極的に接続されるべきではありません。
If the Protocol Stack includes a transport protocol that supports multipath connectivity, the Transport Services Implementation should also inform the protocol instance about potentially new paths that become permissible based on the multipath Selection Property and the multipathPolicy Connection Property choices made by the application. A protocol can then establish new subflows over new paths while an active path is still available or after a break has been detected, and it should attempt to tear down subflows over paths that are no longer used. The Connection Property multipathPolicy of the Transport Services API allows an application to indicate when and how different paths should be used. However, detailed handling of these policies is implementation specific. For example, if the multipath Selection Property is set to Active, the decision about when to create a new path or to announce a new path or set of paths to the Remote Endpoint, e.g., in the form of additional IP addresses, is implementation specific. If the Protocol Stack includes a transport protocol that does not support multipath but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated.
プロトコルスタックにマルチパス接続をサポートするトランスポートプロトコルが含まれている場合、トランスポートサービスの実装は、マルチパス選択プロパティとアプリケーションによって行われたMultiPathpolicy Connectionプロパティの選択に基づいて許容される潜在的に新しいパスについてプロトコルインスタンスに通知する必要があります。その後、プロトコルは、アクティブパスがまだ利用可能である間、または休憩が検出された後、新しいパス上に新しいサブフローを確立することができ、使用されなくなったパス上でサブフローを取り壊そうとするはずです。Transport Services APIの接続プロパティMultiPathpolicyを使用すると、アプリケーションがいつ、どのように異なるパスを使用するかを示すことができます。ただし、これらのポリシーの詳細な処理は実装固有です。たとえば、MultiPath選択プロパティがアクティブに設定されている場合、新しいパスを作成するか、リモートエンドポイントへの新しいパスまたはパスのセットを発表する時期、たとえば、追加のIPアドレスの形式での決定は、実装固有です。プロトコルスタックには、マルチパスをサポートしていないがパス間の移行をサポートするトランスポートプロトコルが含まれている場合、使用可能なパスのセットへの更新が接続をトリガーする可能性があります。
In the case of a Pooled Connection (Section 7.1), the Transport Services Implementation may add connections over new paths to the pool if permissible based on the multipathPolicy and Selection Properties. If a previously used path becomes unavailable, the Transport Services System may disconnect all connections that require this path, but it should not disconnect the Pooled Connection object exposed to the application. The strategy to do so is implementation specific, but it should be consistent with the behavior of multipath transports.
プールされた接続の場合（セクション7.1）、輸送サービスの実装は、マルチパスポリティと選択プロパティに基づいて許容される場合、プールへの新しいパス上に接続を追加する場合があります。以前に使用されていたパスが利用できなくなった場合、トランスポートサービスシステムはこのパスを必要とするすべての接続を切断する場合がありますが、アプリケーションに公開されたプールされた接続オブジェクトを切断しないでください。そうするための戦略は実装固有ですが、マルチパス輸送の動作と一致するはずです。
For Close (which leads to a Closed event) and Abort (which leads to a ConnectionError event), the application might find it useful to be informed when a peer closes or aborts a Connection. Whether this is possible depends on the underlying protocol, and no guarantees can be given. When an underlying transport connection supports multistreaming (such as SCTP), the Transport Services System can use a stream reset procedure to cause a Finish event upon a Close action from the peer [NEAT-flow-mapping].
Close（閉じたイベントにつながる）と中止（ConnectionErrorイベントにつながる）の場合、アプリケーションは、ピアが接続を閉鎖または中止したときに通知されるのが有用であると思われる場合があります。これが可能かどうかは、基礎となるプロトコルに依存し、保証は与えられません。基礎となる輸送接続がマルチストリーミング（SCTPなど）をサポートする場合、トランスポートサービスシステムは、Peer [Neat-Flow-Mapping]からの緊密なアクションで、ストリームリセット手順を使用してフィニッシュイベントを引き起こすことができます。
Beyond a single Connection's lifetime, it is useful for an implementation to keep state and history. This cached state can help improve future Connection establishment due to reusing results and credentials and favoring paths and protocols that performed well in the past.
単一の接続の寿命を超えて、実装が状態と歴史を維持するのに役立ちます。このキャッシュされた状態は、結果と資格情報を再利用し、過去にうまく機能したパスとプロトコルを好むため、将来のつながりの確立を改善するのに役立ちます。
Cached state may be associated with different endpoints for the same Connection, depending on the protocol generating the cached content. For example, session tickets for TLS are associated with specific endpoints; thus, they should be cached based on a connection's hostname Endpoint Identifier (if applicable). However, performance characteristics of a path are more likely tied to the IP address and subnet being used.
キャッシュ状態は、キャッシュコンテンツを生成するプロトコルに応じて、同じ接続の異なるエンドポイントに関連付けられている場合があります。たとえば、TLSのセッションチケットは特定のエンドポイントに関連付けられています。したがって、接続のホスト名エンドポイント識別子（該当する場合）に基づいてキャッシュする必要があります。ただし、パスのパフォーマンス特性は、使用されているIPアドレスとサブネットに結び付けられる可能性が高くなります。
Some protocols will have long-term state to be cached in association with endpoints. This state often has some time after which it is expired, so the implementation should allow each protocol to specify an expiration for cached content.
一部のプロトコルには、エンドポイントに関連してキャッシュされる長期状態があります。この状態にはしばしばある程度の時間がかかるため、実装により各プロトコルがキャッシュされたコンテンツの有効期限を指定できるようにする必要があります。
Examples of cached protocol state include:
キャッシュされたプロトコル状態の例は次のとおりです。
* The DNS protocol can cache resolved addresses (such as those retrieved from A and AAAA queries) associated with a Time To Live (TTL) to be used for future hostname resolutions without requiring asking the DNS resolver again.
* DNSプロトコルは、DNS Resolverを再度尋ねることなく、将来のホスト名解決に使用する時間（TTL）に関連する時間に関連付けられている解決されたアドレス（AおよびAAAAクエリから取得されたものなど）をキャッシュできます。
* TLS caches session state and tickets based on a hostname, which can be used for resuming sessions with a server.
* TLSは、セッションの状態とホスト名に基づいたチケットをキャッシュします。これは、サーバーでのセッションの再開に使用できます。
* TCP can cache cookies for use in TFO.
* TCPは、TFOで使用するためにCookieをキャッシュできます。
Cached protocol state is primarily used during Connection establishment for a single Protocol Stack, but it may be used to influence an implementation's preference between several Candidate Protocol Stacks. For example, if two IP address Endpoint Identifiers are otherwise equally preferred, an implementation may choose to attempt a connection to an address for which it has a TFO cookie.
Cachedプロトコル状態は、主に単一のプロトコルスタックの接続確立中に使用されますが、いくつかの候補プロトコルスタック間の実装の好みに影響を与えるために使用される場合があります。たとえば、2つのIPアドレスエンドポイント識別子が等しく優先される場合、実装は、TFO Cookieを持つアドレスへの接続を試みることを選択できます。
Applications can use the Transport Services API to request that a Connection Group maintain a separate cache for protocol state. Connections in the group will not use Cached State from Connections outside the group, and Connections outside the group will not use state cached from Connections inside the group. This may be necessary, for example, if application-layer identifiers rotate and clients wish to avoid linkability via trackable TLS tickets or TFO cookies.
アプリケーションは、Transport Services APIを使用して、接続グループがプロトコル状態の個別のキャッシュを維持することを要求できます。グループ内の接続は、グループ外の接続からキャッシュ状態を使用せず、グループ外の接続はグループ内の接続からキャッシュされた状態を使用しません。これは、たとえば、アプリケーション層識別子が回転し、クライアントが追跡可能なTLSチケットまたはTFO Cookieを介してリンク可能性を回避したい場合に必要になる場合があります。
In addition to protocol state, protocol instances should provide data into a performance-oriented cache to help guide future protocol and path selection. Some performance information can be gathered generically across several protocols to allow predictive comparisons between protocols on given paths:
プロトコル状態に加えて、プロトコルインスタンスは、将来のプロトコルとパスの選択をガイドするために、パフォーマンス指向のキャッシュにデータを提供する必要があります。いくつかのパフォーマンス情報をいくつかのプロトコルで一般的に収集して、特定のパス上のプロトコル間の予測比較を可能にすることができます。
* Observed RTT
* RTTが観察されました
* Connection establishment latency
* 接続確立の待ち時間
* Connection establishment success rate
* 接続確立の成功率
These items can be cached on a per-address and per-subnet granularity and averaged between different values. The information should be cached on a per-network basis since it is expected that different network attachments will have different performance characteristics. Besides protocol instances, other system entities may also provide data into performance-oriented caches. This could for instance be signal strength information reported by radio modems like Wi-Fi and mobile broadband or information about the battery level of the device. Furthermore, the system may cache the observed maximum throughput on a path as an estimate of the available bandwidth.
これらの項目は、アドレスレスごととスブネットごとの粒度でキャッシュされ、異なる値間で平均化できます。さまざまなネットワーク添付ファイルに異なるパフォーマンス特性があると予想されるため、情報はネットワークごとにキャッシュする必要があります。プロトコルインスタンスに加えて、他のシステムエンティティは、パフォーマンス指向のキャッシュにデータを提供する場合があります。これは、たとえば、Wi-Fiやモバイルブロードバンドなどの無線モデムによって報告された信号強度情報またはデバイスのバッテリーレベルに関する情報である可能性があります。さらに、システムは、利用可能な帯域幅の推定として、パス上の観測された最大スループットをキャッシュする場合があります。
An implementation should use this information, when possible, to influence preference between Candidate Paths, endpoints, and protocol options. Eligible options that historically had significantly better performance than others should be selected first when gathering candidates (see Section 4.2) to ensure better performance for the application.
実装は、可能であれば、この情報を使用して、候補パス、エンドポイント、およびプロトコルオプションの間の好みに影響する必要があります。歴史的に他のパフォーマンスよりも大幅に優れたパフォーマンスを持っていた適格なオプションは、候補者を収集するときに最初に選択する必要があります（セクション4.2を参照）。
The reasonable lifetime for cached performance values will vary depending on the nature of the value. Certain information, like the connection establishment success rate to a Remote Endpoint using a given Protocol Stack, can be stored for a long period of time (hours or longer) since it is expected that the capabilities of the Remote Endpoint are not changing very quickly. On the other hand, the RTT observed by TCP over a particular network path may vary over a relatively short time interval. For such values, the implementation should remove them from the cache more quickly or treat older values with less confidence/weight.
キャッシュされたパフォーマンス値の合理的な寿命は、値の性質によって異なります。特定のプロトコルスタックを使用したリモートエンドポイントへの接続確立の成功率など、特定の情報は、リモートエンドポイントの機能が非常に迅速に変化しないと予想されるため、長期間（何時間以上）保存できます。一方、特定のネットワークパスでTCPによって観察されたRTTは、比較的短い時間間隔で異なる場合があります。このような値については、実装によりキャッシュからより迅速に削除するか、自信/重量で古い値を処理する必要があります。
[RFC9040] provides guidance about sharing of TCP Control Block information between connections on initialization.
[RFC9040]は、初期化時の接続間のTCP制御ブロック情報の共有に関するガイダンスを提供します。
Each protocol that is supported by a Transport Services Implementation should have a well-defined API mapping. API mappings for a protocol are important for Connections in which a given protocol is the "top" of the Protocol Stack. For example, the mapping of the Send action for TCP applies to Connections in which the application directly sends over TCP.
トランスポートサービスの実装によってサポートされている各プロトコルには、明確に定義されたAPIマッピングが必要です。プロトコルのAPIマッピングは、特定のプロトコルがプロトコルスタックの「上」である接続に重要です。たとえば、TCPの送信アクションのマッピングは、アプリケーションがTCPを介して直接送信する接続に適用されます。
Each protocol has a notion of "Connectedness". Possible definitions of Connectedness for various types of protocols are:
各プロトコルには「つながり」の概念があります。さまざまな種類のプロトコルのつながりの可能な定義は次のとおりです。
Connectionless:
コネクションレス：
Connectionless protocols do not establish explicit state between endpoints and do not perform a handshake during connection establishment.
コネクションレスプロトコルは、エンドポイント間の明示的な状態を確立せず、接続確立中に握手を実行しません。
Connected:
接続：
Connected (also called "connection-oriented") protocols establish state between endpoints and perform a handshake during connection establishment. The handshake may be 0-RTT to send data or resume a session, but bidirectional traffic is required to confirm Connectedness.
接続（「接続指向」とも呼ばれます）プロトコルは、エンドポイント間で状態を確立し、接続確立中に握手を実行します。握手は0-RTTである可能性があります。データを送信したり、セッションを再開したりしますが、接続性を確認するには双方向トラフィックが必要です。
Multiplexing connected:
マルチプレックス接続：
Multiplexing connected protocols share properties with connected protocols but also explicitly support opening multiple application-level flows. This means that they can support cloning new Connection objects without a new explicit handshake.
マルチプレックス接続プロトコルは、接続されたプロトコルとプロパティを共有しますが、複数のアプリケーションレベルのフローの開設を明示的にサポートしています。これは、新しい明示的な握手なしで新しい接続オブジェクトのクローニングをサポートできることを意味します。
Protocols also have a notion of "Data Unit". Possible values for Data Unit are:
プロトコルには、「データユニット」の概念もあります。データユニットの可能な値は次のとおりです。
Byte-stream:
バイトストリーム：
Byte-stream protocols do not define any message boundaries of their own apart from the end of a stream in each direction.
バイトストリームプロトコルは、各方向のストリームの端から離れて、独自のメッセージ境界を定義しません。
Datagram:
データグラム：
Datagram protocols define message boundaries at the same level of transmission, such that only complete (not partial) messages are supported.
Datagramプロトコルは、同じレベルの伝送でメッセージの境界を定義し、完全な（部分的ではない）メッセージのみがサポートされます。
Message:
メッセージ：
Message protocols support message boundaries that can be sent and received either as complete or partial messages. Maximum message lengths can be defined, and messages can be partially reliable.
メッセージプロトコルは、完全または部分的なメッセージとして送信および受信できるメッセージの境界をサポートします。最大メッセージの長さを定義でき、メッセージは部分的に信頼性があります。
Below, terms in capitals with a dot character (".") (e.g., "CONNECT.SCTP") refer to the primitives with the same name in Section 4 of [RFC8303]. For further implementation details, the description of these primitives in [RFC8303] points to Section 3 of [RFC8303] and Section 3 of [RFC8304], which refers back to the relevant specifications for each protocol. This applies to all elements of [RFC8923] (see Appendix C of [RFC9622]): they are listed in Appendix A of [RFC8923] with an implementation hint in the same style, pointing back to Section 4 of [RFC8303].
以下では、ドット文字（ "。"）（ "。" connect.sctp "）を持つ首都の用語[rfc8303]のセクション4で同じ名前のプリミティブを指します。さらなる実装の詳細については、[RFC8303]のこれらのプリミティブの説明は、[RFC8303]のセクション3と[RFC8304]のセクション3を指します。これは、各プロトコルの関連する仕様を参照しています。これは、[RFC8923]のすべての要素に適用されます（[RFC9622]の付録Cを参照）：[RFC8923]の付録Aにリストされています。
This document presents the protocol mappings defined in [RFC8923]. Other protocol mappings can be provided as separate documents, following the mapping template in Appendix A.
このドキュメントでは、[RFC8923]で定義されているプロトコルマッピングを示します。他のプロトコルマッピングは、付録Aのマッピングテンプレートに従って、個別のドキュメントとして提供できます。
Connectedness:
つながり：
Connected
接続
Data Unit:
データユニット：
Byte-stream
バイトストリーム
Connection Object:
接続オブジェクト：
TCP connections between two hosts map directly to Connection objects.
2つのホスト間のTCP接続は、接続オブジェクトに直接マッピングされます。
Initiate:
開始する：
CONNECT.TCP. Calling Initiate on a TCP connection causes it to reserve a local port and send a SYN to the Remote Endpoint.
connect.tcp。TCP接続で開始を呼び出すと、ローカルポートを予約し、リモートエンドポイントにSynを送信します。
InitiateWithSend:
eatiatewithsend：
CONNECT.TCP with parameter user message. Early safely replayable data is sent on a TCP connection in the SYN, as TFO data.
パラメーターユーザーメッセージを使用したConnect.tcp。初期の安全に再生可能なデータは、TFOデータとしてSynのTCP接続で送信されます。
Ready:
準備ができて：
A TCP connection is ready once the three-way handshake is complete.
3方向の握手が完了すると、TCP接続が準備されます。
EstablishmentError:
設立エラー：
Failure of CONNECT.TCP. TCP can throw various errors during connection setup. Specifically, it is important to handle a RST being sent by the peer during the handshake.
connect.tcpの障害。TCPは、接続セットアップ中にさまざまなエラーをスローできます。具体的には、握手中にピアから送信された最初の人を処理することが重要です。
ConnectionError:
ConnectionError：
Once established, TCP throws errors whenever the connection is disconnected, such as due to receiving a RST from the peer.
確立されると、TCPは、ピアからRSTを受信したためなど、接続が切断されるたびにエラーをスローします。
Listen:
聞く：
LISTEN.TCP. Calling Listen for TCP binds a local port and prepares it to receive inbound SYN packets from peers.
聞く。tcp。TCPをリッスンすると、ローカルポートにバインドされ、ピアからインバウンドsynパケットを受信するように準備します。
ConnectionReceived:
ConnectionReceived：
TCP Listeners will deliver new connections once they have replied to an inbound SYN with a SYN-ACK.
TCPリスナーは、syn-ackを使用してインバウンドsynに返信すると、新しい接続を提供します。
Clone:
クローン：
Calling Clone on a TCP connection creates a new TCP connection with equivalent parameters. The two associated Connection objects, and Connections generated via later calls to Clone on an Established Connection, form a Connection Group. To realize entanglement for these Connections, with the exception of connPriority, changing a Connection Property on one of them must affect the Connection Properties of the others too. No guarantees of honoring the connPriority Connection Property are given; thus, it is safe for an implementation of a Transport Services System to ignore this Property. When it is reasonable to assume that Connections traverse the same path (e.g., when they share the same encapsulation), support for it can also experimentally be implemented using a congestion control coupling mechanism (for example, see [TCP-COUPLING] or [RFC3124]).
TCP接続でクローンを呼び出すと、同等のパラメーターと新しいTCP接続が作成されます。2つの関連する接続オブジェクトと、後の呼び出しを介して生成された接続は、確立された接続をクローンし、接続グループを形成します。これらの接続の絡み合いを実現するには、conconpriorityを除いて、それらの1つで接続プロパティを変更すると、他の接続プロパティにも影響を与える必要があります。Connpriority Connectionプロパティを称えるという保証はありません。したがって、このプロパティを無視するために、輸送サービスシステムの実装が安全です。接続が同じパスを横断すると仮定するのが合理的である場合（たとえば、同じカプセル化を共有する場合）、それに対するサポートは、輻輳制御結合メカニズムを使用して実験的に実装することもできます（たとえば、[TCP結合]または[RFC31244を参照してください]）。
Send:
送信：
SEND.TCP. On its own, TCP does not preserve Message boundaries. Calling Send on a TCP connection lays out the bytes on the TCP send stream without any other delineation. Any Message marked as Final will cause TCP to send a FIN once the Message has been completely written, by calling CLOSE.TCP immediately upon successful termination of SEND.TCP. Note that transmitting a Message marked as Final should not cause the Closed event to be delivered to the application as it will still be possible to receive data until the peer closes or aborts the TCP connection.
send.tcp。それ自体では、TCPはメッセージの境界を保持しません。TCP接続の送信を呼び出すと、TCP送信ストリームのバイトが他の描写なしでレイアウトされます。ファイナルとしてマークされたメッセージは、send.tcpの終了を成功させるとすぐにClose.tcpを呼び出すことにより、メッセージが完全に記述された後、TCPがFINを送信します。ファイナルとしてマークされたメッセージを送信すると、ピアがTCP接続を閉鎖または中止するまでデータを受信することはできないため、クローズドイベントをアプリケーションに配信してはなりません。
Receive:
受け取る：
With RECEIVE.TCP, TCP delivers a stream of bytes without any Message delineation. All data delivered in the Received or ReceivedPartial event will be part of a single stream-wide Message that is marked Final (unless a Message Framer is used). The value of the endOfMessage Property will be delivered when the TCP connection has received a FIN (CLOSE-EVENT.TCP) from the peer. Note that reception of a FIN should not cause the Closed event to be delivered to the application, as it will still be possible for the application to send data.
receive.tcpを使用すると、TCPはメッセージの描写なしでバイトのストリームを提供します。受信または受信部門で配信されるすべてのデータは、最終的なマークされた単一のストリーム全体のメッセージの一部です（メッセージフレーマーが使用されない限り）。EndofMessageプロパティの値は、TCP接続がピアからFIN（Close-Event.TCP）を受信したときに配信されます。FINの受信は、アプリケーションがデータを送信できる可能性があるため、閉じたイベントをアプリケーションに配信するものではないことに注意してください。
Close:
近い：
Calling Close on a TCP connection indicates that the TCP connection should be gracefully closed (CLOSE.TCP) by sending a FIN to the peer. It will then still be possible to receive data until the peer closes or aborts the TCP connection. The Closed event will be issued upon reception of a FIN.
TCP接続で閉鎖を呼び出すと、フィンをピアに送信して、TCP接続を優雅に閉じて（close.tcp）ことが示されます。その後、ピアがTCP接続を閉じるか中止するまで、データを受信することができます。閉じたイベントは、フィンを受信すると発行されます。
Abort:
アボート：
Calling Abort on a TCP connection indicates that the TCP connection should be immediately closed by sending a RST to the peer (ABORT.TCP).
TCP接続を呼び出すと、PEER（abort.tcp）にRSTを送信することにより、TCP接続をすぐに閉じる必要があることがわかります。
CloseGroup:
CloseGroup：
Calling CloseGroup on a TCP connection (CLOSE.TCP) is identical to calling Close on its Connection object and on all Connections in the same ConnectionGroup.
TCP接続（close.tcp）でClosegroupを呼び出すことは、接続オブジェクトと同じ接続グループのすべての接続でCloseを呼び出すのと同じです。
AbortGroup:
abortgroup：
Calling AbortGroup on a TCP connection (ABORT.TCP) is identical to calling Abort on its Connection object and on all Connections in the same ConnectionGroup.
TCP接続（abort.tcp）でabortgroupを呼び出すことは、接続オブジェクトと同じ接続グループのすべての接続でAbortを呼び出すのと同じです。
Connectedness:
つながり：
Connected
接続
Data Unit:
データユニット：
Byte-stream
バイトストリーム
The Transport Services API mappings for MPTCP are identical to TCP. MPTCP adds support for multipath Properties, such as multipath and multipathPolicy, and actions for managing paths, such as AddRemote and RemoveRemote.
MPTCPのトランスポートサービスAPIマッピングは、TCPと同じです。MPTCPは、MultiPathやMultiPathpolicyなどのマルチパスプロパティのサポート、およびAddRemoteやRemovereMoteなどのパスを管理するためのアクションを追加します。
Connectedness:
つながり：
Connectionless
コネクションレス
Data Unit:
データユニット：
Datagram
データグラム
Connection Object:
接続オブジェクト：
UDP connections represent a pair of specific IP addresses and ports on two hosts.
UDP接続は、2つのホストの特定のIPアドレスとポートのペアを表します。
Initiate:
開始する：
CONNECT.UDP. Calling Initiate on a UDP connection causes it to reserve a local port but does not generate any traffic.
connect.udp。UDP接続で開始を呼び出すと、ローカルポートを予約しますが、トラフィックは生成されません。
InitiateWithSend:
eatiatewithsend：
Early data on a UDP connection does not have any special meaning. The data is sent whenever the connection is Ready.
UDP接続に関する初期のデータには、特別な意味がありません。接続の準備が整うたびにデータが送信されます。
Ready:
準備ができて：
A UDP connection is ready once the system has reserved a local port and has a path to send to the Remote Endpoint.
システムがローカルポートを予約し、リモートエンドポイントに送信するパスがあると、UDP接続の準備が整います。
EstablishmentError:
設立エラー：
UDP connections can only generate errors on initiation due to port conflicts on the local system.
UDP接続は、ローカルシステムでのポート競合により、開始時にエラーのみを生成できます。
ConnectionError:
ConnectionError：
UDP connections can only generate Connection errors in response to Abort actions. (Once in use, UDP connections can also generate SoftError events (ERROR.UDP) upon receiving ICMP notifications indicating failures in the network.)
UDP接続は、アクションを中止することで接続エラーのみを生成できます。（使用すると、UDP接続は、ネットワーク内の障害を示すICMP通知を受信すると、Softerrorイベント（ERROR.UDP）を生成することもできます。）
Listen:
聞く：
LISTEN.UDP. Calling Listen for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers.
聞きます.udp。Calling for UDPを呼び出すと、ローカルポートにバインドされ、ピアからインバウンドUDPデータグラムを受信するように準備します。
ConnectionReceived:
ConnectionReceived：
UDP Listeners will deliver new Connections once they have received traffic from a new Remote Endpoint.
UDPリスナーは、新しいリモートエンドポイントからトラフィックを受け取ったら、新しい接続を提供します。
Clone:
クローン：
Calling Clone on a UDP connection creates a new UDP connection with equivalent parameters. The two associated Connection objects are otherwise independent.
UDP接続でクローンを呼び出すと、同等のパラメーターと新しいUDP接続が作成されます。それ以外の場合、2つの関連する接続オブジェクトは独立しています。
Send:
送信：
SEND.UDP. Calling Send on a UDP connection sends the data as the payload of a complete UDP datagram. Marking Messages as Final does not change anything in the datagram's contents. Upon sending a UDP datagram, some relevant fields and flags in the IP header can be controlled: DSCP (SET_DSCP.UDP), DF in IPv4 (SET_DF.UDP), and ECN flag (SET_ECN.UDP).
send.udp。udp接続の送信を呼び出すと、完全なUDPデータグラムのペイロードとしてデータが送信されます。メッセージとしてメッセージをマークしても、データグラムのコンテンツには何も変更されません。UDPデータグラムを送信すると、IPヘッダーのいくつかの関連するフィールドとフラグを制御できます：DSCP（set_dscp.udp）、IPv4（set_df.udp）のDF、およびECNフラグ（set_ecn.udp）。
Receive:
受け取る：
RECEIVE.UDP. UDP only delivers complete Messages to Received, each of which represents a single datagram received in a UDP packet. Upon receiving a UDP datagram, the ECN flag from the IP header can be obtained (GET_ECN.UDP).
receive.udp。UDPは、受信する完全なメッセージのみを配信します。各メッセージは、UDPパケットで受信した単一のデータグラムを表します。UDPデータグラムを受信すると、IPヘッダーからECNフラグを取得できます（get_ecn.udp）。
Close:
近い：
Calling Close on a UDP connection (ABORT.UDP) releases the local port reservation. A Closed event is then issued.
UDP接続（abort.udp）でCloseを呼び出すと、ローカルポート予約がリリースされます。その後、閉じたイベントが発行されます。
Abort:
アボート：
Calling Abort on a UDP connection (ABORT.UDP) is identical to calling Close except that a ConnectionError event rather than a Closed event is issued.
UDP接続（abort.udp）でAbortを呼び出すことは、閉じたイベントではなくConnectionErrorイベントが発行されることを除いて、Close Closeと呼び出すのと同じです。
CloseGroup:
CloseGroup：
Calling CloseGroup on a UDP connection (ABORT.UDP) is identical to calling Close on its Connection object and on all Connections in the same ConnectionGroup.
UDP接続（abort.udp）でClosegroupを呼び出すことは、接続オブジェクトと同じ接続グループのすべての接続でCloseを呼び出すのと同じです。
AbortGroup:
abortgroup：
Calling AbortGroup on a UDP connection (ABORT.UDP) is identical to calling Close on its Connection object and on all Connections in the same ConnectionGroup.
UDP接続（abort.udp）でabortgroupを呼び出すことは、接続オブジェクトと同じ接続グループのすべての接続を閉じることと同じです。
Connectedness:
つながり：
Connectionless
コネクションレス
Data Unit:
データユニット：
Datagram
データグラム
The Transport Services API mappings for UDP-Lite are identical to UDP. In addition, UDP-Lite supports the msgChecksumLen and recvChecksumLen Properties that allow an application to specify the minimum number of bytes in a Message that need to be covered by a checksum.
UDP-Lite用のTransport Services APIマッピングは、UDPと同一です。さらに、UDP-Liteは、MSGCHECKSUMLENおよびRECVCHECKSUMLENプロパティをサポートし、アプリケーションがチェックサムでカバーする必要があるメッセージ内の最小バイト数を指定できるようにします。
This includes: CONNECT.UDP-Lite; LISTEN.UDP-Lite; SEND.UDP-Lite; RECEIVE.UDP-Lite; ABORT.UDP-Lite; ERROR.UDP-Lite; SET_DSCP.UDP-Lite; SET_DF.UDP-Lite; SET_ECN.UDP-Lite; GET_ECN.UDP-Lite.
これには、connect.udp-lite;聞きます.udp-lite;send.udp-lite;receive.udp-lite;abort.udp-lite;error.udp-lite;set_dscp.udp-lite;set_df.udp-lite;set_ecn.udp-lite;get_ecn.udp-lite。
Connectedness:
つながり：
Connectionless
コネクションレス
Data Unit:
データユニット：
Datagram
データグラム
Connection Object:
接続オブジェクト：
Established UDP Multicast Receive connections represent a pair of specific IP addresses and ports. The direction Selection Property must be set to Unidirectional receive, and the Local Endpoint must be configured with a group IP address and a port.
確立されたUDPマルチキャスト受信接続は、特定のIPアドレスとポートのペアを表します。方向選択プロパティは、単方向受信に設定する必要があり、ローカルエンドポイントはグループIPアドレスとポートで構成する必要があります。
Initiate:
開始する：
Calling Initiate on a UDP Multicast Receive connection causes an immediate EstablishmentError. This is an unsupported operation.
UDPマルチキャストの受信接続で開始を呼び出すと、即時の確立が発生します。これはサポートされていない操作です。
InitiateWithSend:
eatiatewithsend：
Calling InitiateWithSend on a UDP Multicast Receive connection causes an immediate EstablishmentError. This is an unsupported operation.
UDPマルチキャストの受信接続のinitiatewithsendを呼び出すと、即時の設立が発生します。これはサポートされていない操作です。
Ready:
準備ができて：
A UDP Multicast Receive connection is ready once the system has received traffic for the appropriate group and port.
システムが適切なグループとポートのトラフィックを受け取ったら、UDPマルチキャスト受信接続が準備が整います。
EstablishmentError:
設立エラー：
UDP Multicast Receive connections cause an EstablishmentError indicating that joining a multicast group failed if Initiate is called.
UDPマルチキャストの受信接続は、Intiventerrorを呼び出した場合にマルチキャストグループに参加したことを示すIndecizenterrorを引き起こします。
ConnectionError:
ConnectionError：
The only ConnectionError generated by a UDP Multicast Receive connection is in response to an Abort action.
UDPマルチキャスト受信接続によって生成された唯一のConnectionErrorは、中止アクションに応じています。
Listen:
聞く：
LISTEN.UDP. Calling Listen for UDP Multicast Receive binds a local port, prepares it to receive inbound UDP datagrams from peers, and issues a multicast host join. If a Remote Endpoint Identifier with an address is supplied, the join is Source-Specific Multicast, and the path selection is based on the route to the Remote Endpoint. If a Remote Endpoint Identifier is not supplied, the join is Any-Source Multicast, and the path selection is based on the outbound route to the group supplied in the Local Endpoint.
聞きます.udp。UDPのリスニングを呼び出すマルチキャスト受信はローカルポートにバインドされ、ピアからインバウンドUDPデータグラムを受信する準備をし、マルチキャストホストの結合を発行します。アドレスを持つリモートエンドポイント識別子が提供される場合、結合はソース固有のマルチキャストであり、パス選択はリモートエンドポイントへのルートに基づいています。リモートエンドポイント識別子が供給されない場合、結合は任意のソースマルチキャストであり、パス選択はローカルエンドポイントで提供されるグループへのアウトバウンドルートに基づいています。
There are cases where it is required to open multiple connections for the same address(es). For example, one Connection might be opened for a multicast group used for a shared control bus, and another application later opens a separate Connection to the same group to send signals to and/or receive signals from the common bus. In such cases, the Transport Services System needs to explicitly enable reuse of the same set of addresses (equivalent to setting SO_REUSEADDR in the Socket API).
同じアドレスに対して複数の接続を開く必要がある場合があります。たとえば、共有制御バスに使用されるマルチキャストグループには1つの接続が開かれ、別のアプリケーションは後に同じグループに別の接続を開き、共通バスから信号を送信および/または受信します。そのような場合、輸送サービスシステムは、同じアドレスのセットを明示的に再利用できるようにする必要があります（ソケットAPIにSO_ReuseadDRを設定することに相当）。
ConnectionReceived:
ConnectionReceived：
UDP Multicast Receive Listeners will deliver new Connections once they have received traffic from a new Remote Endpoint.
UDPマルチキャスト受信リスナーは、新しいリモートエンドポイントからトラフィックを受け取ったら、新しい接続を提供します。
Clone:
クローン：
Calling Clone on a UDP Multicast Receive connection creates a new UDP Multicast Receive connection with equivalent parameters. The two associated Connection objects are otherwise independent.
UDPマルチキャストのCOLEM CLONEを呼び出すと、CONENTERS接続は、等価パラメーターとの新しいUDPマルチキャスト受信接続が作成されます。それ以外の場合、2つの関連する接続オブジェクトは独立しています。
Send:
送信：
SEND.UDP. Calling Send on a UDP Multicast Receive connection causes an immediate SendError. This is an unsupported operation.
send.udp。udpマルチキャストの送信を呼び出して、受信接続が即座にsenderrorを引き起こします。これはサポートされていない操作です。
Receive:
受け取る：
RECEIVE.UDP. UDP Multicast Receive only delivers complete Messages to Received, each of which represents a single datagram received in a UDP packet. Upon receiving a UDP datagram, the ECN flag from the IP header can be obtained (GET_ECN.UDP).
receive.udp。UDPマルチキャスト受信は、受信する完全なメッセージのみを配信します。各メッセージは、UDPパケットで受信した単一のデータグラムを表します。UDPデータグラムを受信すると、IPヘッダーからECNフラグを取得できます（get_ecn.udp）。
Close:
近い：
Calling Close on a UDP Multicast Receive connection (ABORT.UDP) releases the local port reservation and leaves the group. A Closed event is then issued.
UDP Multicast Receim Connection（abort.udp）にCloseを呼び出すと、ローカルポート予約がリリースされ、グループが去ります。その後、閉じたイベントが発行されます。
Abort:
アボート：
Calling Abort on a UDP Multicast Receive connection (ABORT.UDP) is identical to calling Close except that a ConnectionError event rather than a Closed event is issued.
UDPマルチキャスト受信接続（abort.udp）でAbortを呼び出すことは、閉じたイベントではなくConnectionErrorイベントが発行されることを除いて、閉じることと同じです。
CloseGroup:
CloseGroup：
Calling CloseGroup on a UDP Multicast Receive connection (ABORT.UDP) is identical to calling Close on its Connection object and on all Connections in the same ConnectionGroup.
UDPマルチキャスト受信接続（abort.udp）でClosegroupを呼び出すことは、接続オブジェクトと同じ接続グループのすべての接続をCloseに呼び出すのと同じです。
AbortGroup:
abortgroup：
Calling AbortGroup on a UDP Multicast Receive connection (ABORT.UDP) is identical to calling Close on its Connection object and on all Connections in the same ConnectionGroup.
UDPマルチキャストの受信接続（abort.udp）でabortgroupを呼び出すことは、接続オブジェクトと同じ接続グループのすべての接続を閉じることと同じです。
Connectedness:
つながり：
Connected
接続
Data Unit:
データユニット：
Message
メッセージ
Connection Object:
接続オブジェクト：
Connection objects can be mapped to an SCTP association or a stream in an SCTP association. Mapping Connection objects to SCTP streams is called "stream mapping" and has additional requirements as follows. The following explanation assumes a client-server communication model.
接続オブジェクトは、SCTPアソシエーションまたはSCTPアソシエーションのストリームにマッピングできます。SCTPストリームへのマッピング接続オブジェクトは「ストリームマッピング」と呼ばれ、次のように追加の要件があります。次の説明は、クライアントサーバー通信モデルを想定しています。
Stream mapping requires an association to already be in place between the client and the server, and it requires the server to understand that a new incoming stream should be represented as a new Connection object by the Transport Services System. A new SCTP stream is created by sending an SCTP message with a new stream id. Thus, to implement stream mapping, the Transport Services API must provide a newly created Connection object to the application upon the reception of such a message. The necessary semantics to implement a Transport Services System's Close and Abort primitives are provided by the stream reconfiguration (reset) procedure described in [RFC6525]. This also allows a stream id to be reused after resetting ("closing") the stream. To implement this functionality, SCTP stream reconfiguration [RFC6525] must be supported by both the client and the server side.
ストリームマッピングでは、クライアントとサーバーの間に既にアソシエーションが整っている必要があり、サーバーは、新しい着信ストリームをトランスポートサービスシステムによって新しい接続オブジェクトとして表現する必要があることを理解する必要があります。新しいSCTPストリームは、新しいストリームIDを使用してSCTPメッセージを送信することにより作成されます。したがって、ストリームマッピングを実装するには、Transport Services APIは、このようなメッセージを受信する際に、新しく作成された接続オブジェクトをアプリケーションに提供する必要があります。[RFC6525]で説明されているストリーム再構成（リセット）手順によって、輸送サービスシステムの閉鎖および中止プリミティブを実装するために必要なセマンティクスが提供されます。これにより、ストリームをリセット（「閉じる」）後にストリームIDを再利用できます。この機能を実装するには、SCTPストリーム再構成[RFC6525]をクライアント側とサーバー側の両方でサポートする必要があります。
To avoid head-of-line blocking, stream mapping should only be implemented when both sides support message interleaving [RFC8260]. This allows a sender to schedule transmissions between multiple streams without risking that transmission of a large message on one stream will block transmissions on other streams for a long time.
頭のブロッキングを避けるために、ストリームマッピングは、双方がメッセージのインターリーブ[RFC8260]をサポートする場合にのみ実装する必要があります。これにより、送信者は、1つのストリーム上の大きなメッセージの送信が他のストリームの送信を長い間ブロックすることを危険にさらすことなく、複数のストリーム間の送信をスケジュールできます。
To avoid conflicts between stream ids, the following procedure is recommended: the first Connection, for which the SCTP association has been created, must always use stream id zero. All additional Connections are assigned to unused stream ids in ascending order. To avoid a conflict when both endpoints map new Connections simultaneously, the peer that initiated association must use even stream ids whereas the remote side must map its Connections to odd stream ids. Both sides maintain a status map of the assigned stream ids. Generally, new streams should consume the lowest available (even or odd, depending on the side) stream id; this rule is relevant when lower stream ids become available because Connection objects associated with the streams are closed.
ストリームID間の競合を回避するには、次の手順が推奨されます。SCTPアソシエーションが作成された最初の接続は、常にストリームIDゼロを使用する必要があります。すべての追加接続は、未使用のストリームIDに昇順で割り当てられます。両方のエンドポイントが新しい接続を同時にマッピングする場合、競合を回避するには、関連付けを開始したピアはストリームIDを使用する必要がありますが、リモート側は接続をOddストリームIDにマッピングする必要があります。双方は、割り当てられたストリームIDのステータスマップを維持します。一般に、新しいストリームは、利用可能な最低（側面に応じて偶数または奇数）を消費する必要があります。このルールは、ストリームに関連付けられた接続オブジェクトが閉じられているため、低いストリームIDが利用可能になったときに関連します。
SCTP stream mapping as described here has been implemented in a research prototype; a description of this implementation is given in [NEAT-flow-mapping].
ここで説明するSCTPストリームマッピングは、研究プロトタイプに実装されています。この実装の説明は、[ニートフローマッピング]に記載されています。
Initiate:
開始する：
If this is the only Connection object that is assigned to the SCTP association or stream mapping is not used, CONNECT.SCTP is called. Else, unless the Selection Property activeReadBeforeSend is preferred or required, a new stream is used: if there are enough streams available, Initiate is a local operation that assigns a new stream id to the Connection object. The number of streams is negotiated as a parameter of the prior CONNECT.SCTP call, and it represents a trade-off between local resource usage and the number of Connection objects that can be mapped without requiring a reconfiguration signal. When running out of streams, ADD_STREAM.SCTP must be called.
これがSCTPアソシエーションまたはストリームマッピングに割り当てられている唯一の接続オブジェクトである場合、Connect.SCTPが呼び出されます。それ以外の場合、選択プロパティActiveredBeforesEndが必要または必要な場合を除き、新しいストリームが使用されます。十分なストリームが利用可能な場合、Initiateは新しいストリームIDを接続オブジェクトに割り当てるローカル操作です。ストリームの数は、以前のconnect.sctp呼び出しのパラメーターとしてネゴシエートされ、ローカルリソースの使用と再構成信号を必要とせずにマッピングできる接続オブジェクトの数との間のトレードオフを表します。ストリームを使い果たすときは、add_stream.sctpを呼び出す必要があります。
InitiateWithSend:
eatiatewithsend：
If this is the only Connection object that is assigned to the SCTP association or stream mapping is not used, CONNECT.SCTP is called with the user message parameter. Else, a new stream is used (see Initiate for how to handle running out of streams), and this just sends the first message on a new stream.
これがSCTPアソシエーションまたはストリームマッピングに割り当てられている唯一の接続オブジェクトである場合、Connect.SCTPはユーザーメッセージパラメーターで呼び出されます。それ以外の場合、新しいストリームが使用されます（ストリームの不足を処理する方法については開始を参照）。これは、新しいストリームで最初のメッセージを送信するだけです。
Ready:
準備ができて：
Initiate or InitiateWithSend returns without an error, i.e., SCTP's four-way handshake has completed. If an association with the peer already exists, stream mapping is used, and enough streams are available, a Connection object instantly becomes Ready after calling Initiate or InitiateWithSend.
エラーなしで戻ってきた場合、つまりSCTPの4方向の握手が完了しました。ピアとの関連が既に存在する場合、ストリームマッピングが使用され、十分なストリームが使用されている場合、InitiateまたはInitiateWithSendを呼び出した後、接続オブジェクトがすぐに準備が整います。
EstablishmentError:
設立エラー：
Failure of CONNECT.SCTP.
connect.sctpの障害。
ConnectionError:
ConnectionError：
TIMEOUT.SCTP or ABORT-EVENT.SCTP.
timeout.sctpまたはabort-event.sctp。
Listen:
聞く：
LISTEN.SCTP. If an association with the peer already exists and stream mapping is used, Listen just expects to receive a new message with a new stream id (chosen in accordance with the stream id assignment procedure described above).
聞く.sctp。ピアとの関連が既に存在し、ストリームマッピングが使用されている場合、聞くことは、新しいストリームIDを使用して新しいメッセージを受信することを期待しています（上記のストリームID割り当て手順に従って選択）。
ConnectionReceived:
ConnectionReceived：
LISTEN.SCTP returns without an error (a result of successful CONNECT.SCTP from the peer) or, in the case of stream mapping, the first message has arrived on a new stream (in this case, Receive is also invoked).
rethure.sctpは、エラー（ピアからのConnect.sctpの成功の結果）なしで返されます。または、ストリームマッピングの場合、最初のメッセージが新しいストリームに届きました（この場合、受信も呼び出されます）。
Clone:
クローン：
Calling Clone on an SCTP association creates a new Connection object and assigns it a new stream id in accordance with the stream id assignment procedure described above. If there are not enough streams available, ADD_STREAM.SCTP must be called.
SCTP AssociationでCloneを呼び出すと、新しい接続オブジェクトが作成され、上記のストリームID割り当て手順に従って新しいストリームIDを割り当てます。利用可能なストリームが十分にない場合は、add_stream.sctpを呼び出す必要があります。
Send:
送信：
SEND.SCTP. Message Properties such as msgLifetime and msgOrdered map to parameters of this primitive.
send.sctp。このプリミティブのパラメーターにmsglifetimeやmsgorderedマップなどのメッセージプロパティ。
Receive:
受け取る：
RECEIVE.SCTP. The "partial flag" of RECEIVE.SCTP invokes a ReceivedPartial event.
receive.sctp。Receive.SCTPの「部分フラグ」は、受信した出来事を呼び出します。
Close:
近い：
If this is the only Connection object that is assigned to the SCTP association, CLOSE.SCTP is called and the Closed event will be delivered to the application upon the ensuing CLOSE-EVENT.SCTP. Else, the Connection object is one out of several Connection objects that are assigned to the same SCTP association, and RESET_STREAM.SCTP must be called, which informs the peer that the stream will no longer be used for mapping and can be used by a future Initiate, InitiateWithSend, or Listen action. At the peer, the event RESET_STREAM-EVENT.SCTP will be initiated, which the peer must answer by issuing RESET_STREAM.SCTP too. The resulting local RESET_STREAM-EVENT.SCTP informs the Transport Services System that the stream id can now be reused by the next Initiate, InitiateWithSend, or Listen action, and invokes a Closed event toward the application.
これがSCTP協会に割り当てられている唯一の接続オブジェクトである場合、close.sctpが呼び出され、閉じたイベントが次のClose-Event.sctpでアプリケーションに配信されます。それ以外の場合、接続オブジェクトは同じSCTPアソシエーションに割り当てられた複数の接続オブジェクトの1つであり、Reset_stream.SCTPを呼び出す必要があります。アクションを開始、開始、または聞く。ピアでは、イベントreset_stream-event.sctpが開始されます。これは、reset_stream.sctpも発行することで回答しなければなりません。結果のローカルReset_stream-event.sctpは、トランスポートサービスシステムに、次の開始、開始、またはリスションアクションによってストリームIDを再利用できることを通知し、アプリケーションに向けてクローズドイベントを呼び出します。
Abort:
アボート：
If this is the only Connection object that is assigned to the SCTP association, ABORT.SCTP is called. Else, the Connection object is one out of several Connection objects that are assigned to the same SCTP association, and shutdown proceeds as described under Close.
これがSCTP協会に割り当てられている唯一の接続オブジェクトである場合、abort.sctpが呼び出されます。それ以外の場合、接続オブジェクトは、同じSCTPアソシエーションに割り当てられた複数の接続オブジェクトのうちの1つであり、閉鎖は閉じると説明されています。
CloseGroup:
CloseGroup：
Calling CloseGroup calls CLOSE.SCTP, which closes all Connections in the SCTP association.
CloseGroupコールClose.SCTPを呼び出します。SCTPAssociationのすべての接続を閉じます。
AbortGroup:
abortgroup：
Calling AbortGroup calls ABORT.SCTP, which immediately closes all Connections in the SCTP association.
AbortGroupの呼び出しは、SCTP協会のすべての接続を直ちに閉じるabort.sctpを呼び出します。
In addition to the API mappings described above, when there are multiple Connection objects assigned to the same SCTP association, SCTP can support Connection Properties such as connPriority and connScheduler where CONFIGURE_STREAM_SCHEDULER.SCTP can be called to adjust the priorities of streams in the SCTP association.
上記のAPIマッピングに加えて、同じSCTPアソシエーションに割り当てられた複数の接続オブジェクトがある場合、SCTPはconnpriorityやconnschedulerなどの接続プロパティをサポートできます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC9621] outlines general security considerations and requirements for any system that implements the Transport Services Architecture. [RFC9622] provides further discussion on security and privacy implications of the Transport Services API. This document provides additional guidance on implementation specifics for the Transport Services API; as such, the security considerations in both of these documents apply. The next two subsections discuss further considerations that are specific to mechanisms specified in this document.
[RFC9621]は、輸送サービスアーキテクチャを実装するシステムの一般的なセキュリティに関する考慮事項と要件を概説します。[RFC9622]は、輸送サービスAPIのセキュリティとプライバシーへの影響に関するさらなる議論を提供します。このドキュメントは、トランスポートサービスAPIの実装詳細に関する追加のガイダンスを提供します。そのため、これらの両方のドキュメントのセキュリティ上の考慮事項が適用されます。次の2つのサブセクションでは、このドキュメントで指定されたメカニズムに固有のさらなる考慮事項について説明します。
As discussed in Sections 3 and 6 of [RFC9621], gathering and racing with Protocol Stacks that do not have equivalent security properties ought not be attempted. Therefore, implementations need to avoid downgrade attacks that allow network interference to cause the implementation to select less secure, or entirely insecure, combinations of paths and protocols.
[RFC9621]のセクション3および6で説明したように、同等のセキュリティプロパティを持たないプロトコルスタックで収集とレースを試みてはなりません。したがって、実装は、ネットワーク干渉がパスとプロトコルの組み合わせをより安全でない、または完全に安全ではないようにするために、ネットワーク干渉を選択できるようにする攻撃を避ける必要があります。
See Section 5.3 for security considerations around racing with 0-RTT data.
0-RTTデータを使用したレースに関するセキュリティに関する考慮事項については、セクション5.3を参照してください。
An attacker that knows a particular device is racing several options during Connection establishment may be able to block packets for the first connection attempt, thus inducing the device to fall back to a secondary attempt. This is a problem if the secondary attempts have worse security properties that enable further attacks. Implementations should ensure that all options have equivalent security properties to avoid incentivizing attacks.
特定のデバイスを知っている攻撃者は、接続確立中にいくつかのオプションをレースしていることが、最初の接続試行のためにパケットをブロックできる可能性があり、したがって、デバイスが二次試行に戻るように誘導する可能性があります。これは、二次試行がさらなる攻撃を可能にするセキュリティプロパティが悪い場合の問題です。実装では、すべてのオプションが攻撃の奨励を避けるために、同等のセキュリティプロパティを確保する必要があります。
Since results from the network can determine how a connection attempt tree is built, such as when DNS returns a list of resolved endpoints, it is possible for the network to cause an implementation to consume significant on-device resources. Implementations should limit the maximum amount of state allowed for any given node, including the number of child nodes, especially when the state is based on results from the network.
ネットワークの結果は、DNSが解決されたエンドポイントのリストを返すときなど、接続試行ツリーの構築方法を決定できるため、ネットワークが実装を重要なオンデバイスリソースを消費させる可能性があります。実装では、特に状態がネットワークの結果に基づいている場合、子ノードの数を含む、特定のノードに許可される状態の最大量を制限する必要があります。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
Transport Features Provided by IETF Transport Protocols",
RFC 8303, DOI 10.17487/RFC8303, February 2018,
<https://www.rfc-editor.org/info/rfc8303>.
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the
User Datagram Protocol (UDP) and Lightweight UDP (UDP-
Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
<https://www.rfc-editor.org/info/rfc8304>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC8421] Martinsen, P., Reddy, T., and P. Patil, "Guidelines for
Multihomed and IPv4/IPv6 Dual-Stack Interactive
Connectivity Establishment (ICE)", BCP 217, RFC 8421,
DOI 10.17487/RFC8421, July 2018,
<https://www.rfc-editor.org/info/rfc8421>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", RFC 8923, DOI 10.17487/RFC8923,
October 2020, <https://www.rfc-editor.org/info/rfc8923>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[RFC9621] Pauly, T., Ed., Trammell, B., Ed., Brunstrom, A.,
Fairhurst, G., and C. S. Perkins, "Architecture and
Requirements for Transport Services", RFC 9621,
DOI 10.17487/RFC9621, January 2025,
<https://www.rfc-editor.org/info/rfc9621>.
[RFC9622] Trammell, B., Ed., Welzl, M., Ed., Enghardt, R.,
Fairhurst, G., Kühlewind, M., Perkins, C. S., Tiesel, P.
S., and T. Pauly, "An Abstract Application Programming
Interface (API) for Transport Services", RFC 9622,
DOI 10.17487/RFC9622, January 2025,
<https://www.rfc-editor.org/info/rfc9622>.
[NEAT-flow-mapping]
Weinrank, F. and M. Tuxen, "Transparent flow mapping for
NEAT", 2017 IFIP Networking Conference (IFIP Networking)
and Workshops, DOI 10.23919/IFIPNetworking.2017.8264876,
June 2017, <https://ieeexplore.ieee.org/document/8264876>.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928,
DOI 10.17487/RFC1928, March 1996,
<https://www.rfc-editor.org/info/rfc1928>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, DOI 10.17487/RFC3124, June 2001,
<https://www.rfc-editor.org/info/rfc3124>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
Transmission Protocol (SCTP) Stream Reconfiguration",
RFC 6525, DOI 10.17487/RFC6525, February 2012,
<https://www.rfc-editor.org/info/rfc6525>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015,
<https://www.rfc-editor.org/info/rfc7657>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and User Message Interleaving for the
Stream Control Transmission Protocol", RFC 8260,
DOI 10.17487/RFC8260, November 2017,
<https://www.rfc-editor.org/info/rfc8260>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489,
February 2020, <https://www.rfc-editor.org/info/rfc8489>.
[RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J.
Rosenberg, "Traversal Using Relays around NAT (TURN):
Relay Extensions to Session Traversal Utilities for NAT
(STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020,
<https://www.rfc-editor.org/info/rfc8656>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9040] Touch, J., Welzl, M., and S. Islam, "TCP Control Block
Interdependence", RFC 9040, DOI 10.17487/RFC9040, July
2021, <https://www.rfc-editor.org/info/rfc9040>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
[TCP-COUPLING]
Islam, S., Welzl, M., Hiorth, K., Hayes, D., Armitage, G.,
and S. Gjessing, "ctrlTCP: Reducing latency through
coupled, heterogeneous multi-flow TCP congestion control",
IEEE INFOCOM 2018 - IEEE Conference on Computer
Communications Workshops (INFOCOM WKSHPS),
DOI 10.1109/INFCOMW.2018.8406887, 2018,
<https://ieeexplore.ieee.org/document/8406887>.
Any protocol mapping for the Transport Services API should follow a common template.
トランスポートサービスAPIのプロトコルマッピングは、共通のテンプレートに従う必要があります。
Connectedness: (Connectionless/Connected/Multiplexing Connected)
接続性：（ ConnectionLess/Connected/Multiplexing Connected）
Data Unit: (Byte-stream/Datagram/Message)
データユニット：（バイトストリーム/データグラム/メッセージ）
Connection Object:
接続オブジェクト：
Initiate:
開始する：
InitiateWithSend:
eatiatewithsend：
Ready:
準備ができて：
EstablishmentError:
設立エラー：
ConnectionError:
ConnectionError：
Listen:
聞く：
ConnectionReceived:
ConnectionReceived：
Clone:
クローン：
Send:
送信：
Receive:
受け取る：
Close:
近い：
Abort:
アボート：
CloseGroup:
CloseGroup：
AbortGroup:
abortgroup：
The Transport Services API [RFC9622] allows for several generic error types to specify a more detailed reason about why an error occurred. This appendix lists some of the possible reasons.
Transport Services API [RFC9622]により、いくつかの一般的なエラータイプが、エラーが発生した理由についてより詳細な理由を指定できるようになります。この付録には、考えられる理由のいくつかがリストされています。
InvalidConfiguration:
InvalidConfiguration：
The Properties and Endpoint Identifiers provided by the application are either contradictory or incomplete. Examples include the lack of a Remote Endpoint Identifier on an active open or using a multicast group address while not requesting a Unidirectional receive.
アプリケーションによって提供されるプロパティとエンドポイント識別子は、矛盾するものまたは不完全です。例には、アクティブなオープンにリモートエンドポイント識別子がないか、単方向の受信を要求している間にマルチキャストグループアドレスを使用することが含まれます。
NoCandidates:
nocandidates：
The configuration is valid, but none of the available transport protocols can satisfy the Properties provided by the application.
構成は有効ですが、利用可能な輸送プロトコルはいずれもアプリケーションによって提供されるプロパティを満たすことはできません。
ResolutionFailed:
ResolutionFailed：
The remote or local specifier provided by the application cannot be resolved.
アプリケーションによって提供されるリモートまたはローカル仕様を解決することはできません。
EstablishmentFailed:
施設が失敗しました：
The Transport Services System was unable to establish a transport-layer connection to the Remote Endpoint specified by the application.
輸送サービスシステムは、アプリケーションによって指定されたリモートエンドポイントへの輸送層接続を確立することができませんでした。
PolicyProhibited:
PolicyProhed：
The System Policy prevents the Transport Services System from performing the action requested by the application.
システムポリシーは、輸送サービスシステムがアプリケーションによって要求されたアクションの実行を防ぎます。
NotCloneable:
クローニングではない：
The Protocol Stack is not capable of being cloned.
プロトコルスタックはクローニングできません。
MessageTooLarge:
MessagetOlarge：
The Message is too big for the Transport Services System to handle.
メッセージは、輸送サービスシステムが処理するには大きすぎます。
ProtocolFailed:
プロトコルが失敗しました：
The underlying Protocol Stack failed.
基礎となるプロトコルスタックは失敗しました。
InvalidMessageProperties:
無効なプロパティ：
The Message Properties either contradict the Transport Properties or cannot be satisfied by the Transport Services System.
メッセージプロパティは、輸送プロパティと矛盾するか、輸送サービスシステムで満たすことができません。
DeframingFailed:
deframingfailed：
The data that was received by the underlying Protocol Stack could not be processed by the Message Framer.
基礎となるプロトコルスタックによって受信されたデータは、メッセージフレーマーによって処理できませんでした。
ConnectionAborted:
ConnectionAborted：
The connection was aborted by the peer.
接続はピアによって中止されました。
Timeout:
タイムアウト：
Delivery of a Message was not possible after a timeout.
タイムアウト後はメッセージの配信は不可能でした。
This appendix gives an overview of existing implementations, at the time of writing, of Transport Services Systems that are (to some degree) in line with this document.
この付録は、執筆時点での既存の実装の概要を、このドキュメントに沿って（ある程度）輸送サービスシステムの概要を示しています。
* Apple's Network.framework:
* AppleのNetwork.Framework：
- Network.framework is a transport-level API built for C, Objective-C, and Swift. It is a connect-by-name API that supports transport security protocols. It provides user-space implementations of TCP, UDP, TLS, DTLS, and proxy protocols, and it allows extension via custom Framers.
- Network.Frameworkは、C、Objective-C、およびSwift用に構築されたトランスポートレベルのAPIです。トランスポートセキュリティプロトコルをサポートするのは、名前ごとのAPIです。TCP、UDP、TLS、DTLS、およびプロキシプロトコルのユーザー空間実装を提供し、カスタムフレーマーを介して拡張を可能にします。
- Documentation: https://developer.apple.com/documentation/ network
- ドキュメント：https://developer.apple.com/documentation/ network
* NEAT and NEATPy:
* きちんとしたきちんとした：
- NEAT is the output of the European H2020 research project "NEAT"; it is a user-space library for protocol-independent communication on top of TCP, UDP, and SCTP, with many more features, such as a policy manager.
- ヨーロッパのH2020研究プロジェクト「きちんとした」の出力です。これは、TCP、UDP、およびSCTPの上にあるプロトコルに依存しない通信のためのユーザースペースライブラリであり、ポリシーマネージャーなどの多くの機能を備えています。
- Code: https://github.com/NEAT-project/neat
- コード：https://github.com/neat-project/neat
- Code at the Software Heritage Archive: https://archive.softwareheritage.org/swh:1:dir:737820840f83c4ec 9493a8c0cc89b3159e2e1a57;origin=https://github.com/NEAT-project/neat;visit=swh:1:snp:bbb611b04e355439d47e426e8ad5d07cdb f647e0;anchor=swh:1:rev:652ee991043ce3560a6e5715fa2a5c211139d15 c
- ソフトウェアHeritage Archiveのコード：https://archive.softwareheritage.org/swh:1:dir:737820840f83c4ec 9493a8c0cc89b3159e2e2e1a57; origin = https://github.com/neat-project/neatBBB611B04E3555439D47E426E8AD5D07CDB F647E0; ANCHOR = SWH：1：REV：652EE991043CE3560A6E5715FA2A5C2111139D15 C
- NEATPy is a Python shim over NEAT that updates the NEAT API to be in line with version 6 of the Transport Services API [RFC9622].
- Neatpyは、輸送サービスAPI [RFC9622]のバージョン6に沿ったきちんとしたAPIを更新するきちんとしたPythonシムです。
- Code: https://github.com/theagilepadawan/NEATPy
- コード：https://github.com/theagilepadawan/neatpy
- Code at the Software Heritage Archive: https://archive.softwareheritage.org/swh:1:dir:295ccd148cf918cc b9ed7ad14b5ae968a8d2c370;origin=https://github.com/ theagilepadawan/NEATPy;visit=swh:1:snp:6e1a3a9dd4c532ba6c0f52c8 f734c1256a06cedc;anchor=swh:1:rev:cd0788d7f7f34a0e9b8654516da7c 002c44d2e95
- ソフトウェアの遺産アーカイブのコード：https://archive.softwareheritage.org/swh:1:dir:295ccd148cf918cc 2BA6C0F52C8 F734C1256A06CEDC; anchor = swh：1：Rev：CD0788D7F7F34A0E9B8654516DA7C 002C44D2E95
* PyTAPS:
* Pytaps：
- A Transport Services (TAPS) implementation based on Python asyncio, offering protocol-independent communication to applications on top of TCP, UDP, and TLS, with support for multicast.
- Python Asyncioに基づくトランスポートサービス（TAPS）の実装は、マルチキャストをサポートして、TCP、UDP、およびTLSの上のアプリケーションにプロトコルに依存しない通信を提供します。
- Code: https://github.com/fg-inet/python-asyncio-taps
- コード：https://github.com/fg-inet/python-asyncio-taps
- Code at the Software Heritage Archive: https://archive.softwareheritage.org/swh:1:dir:a7151096d91352b4 39b092ef116d04f38e52e556;origin=https://github.com/fg-inet/ python-asyncio-taps;visit=swh:1:snp:4841e59b53b28bb385726e7d3a5 69bee0fea7fc4;anchor=swh:1:rev:63571fd7545da25142bc1a6371b8f130 97cba38e
- ソフトウェアHeritageアーカイブのコード：https://archive.softwareheritage.org/swh:1:dir:a7151096d91352b4 39b092ef116d04f38e52e556; origin = https://github.com/fg-inet/ python-asycio-taps;1：SNP：4841E59B53B28BB385726E7D3A5 69BEE0FEA7FC4; ANCHOR = SWH：1：REV：63571FD7545DA25142BC1A6371B8F130 97CBA38E
This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT) and No. 815178 (5GENESIS).
この作業は、助成金協定No. 644334（NEAT）およびNo. 815178（5GENESIS）に基づく欧州連合の2020年の研究およびイノベーションプログラムから資金を受け取っています。
This work has been supported by:
この作業は次のようにサポートされています。
* Leibniz Prize project funds from the DFG - German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1).
* DFGからのLeibniz賞プロジェクト資金 - ドイツの研究財団：Gottfried Wilhelm Leibniz-Preis 2011（FKZ FE 570/4-1）。
* the UK Engineering and Physical Sciences Research Council under grant EP/R04144X/1.
* Grant EP/R04144X/1の下での英国工学および物理科学研究評議会。
* the Research Council of Norway under its "Toppforsk" programme through the "OCARINA" project.
* ノルウェーの研究評議会は、「オカリナ」プロジェクトを通じて「Toppforsk」プログラムに基づいています。
Thanks to Colin S. Perkins, Tom Jones, Karl-Johan Grinnemo, and Gorry Fairhurst for their contributions to the design of this specification. Thanks also to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear for their implementation and design efforts, including Happy Eyeballs, that heavily influenced this work.
Colin S. Perkins、Tom Jones、Karl-Johan Grinnemo、Gorry Fairhurstに感謝します。この作品に大きな影響を与えたハッピーアイボールを含む実装とデザインの取り組みについて、スチュアートチェシャー、ジョシュグレスリー、デビッドシナジ、エリックキニアにも感謝します。
Anna Brunstrom (editor)
Karlstad University
Universitetsgatan 2
651 88 Karlstad
Sweden
Email: anna.brunstrom@kau.se
Tommy Pauly (editor)
Apple Inc.
One Apple Park Way
Cupertino, CA 95014
United States of America
Email: tpauly@apple.com
Reese Enghardt
Netflix
121 Albright Way
Los Gatos, CA 95032
United States of America
Email: ietf@tenghardt.net
Philipp S. Tiesel
SAP SE
George-Stephenson-Str. 7-13
10557 Berlin
Germany
Email: philipp@tiesel.net
Michael Welzl
University of Oslo
PO Box 1080 Blindern
0316 Oslo
Norway
Email: michawe@ifi.uio.no