[要約] RFC 8303は、IETFトランスポートプロトコルが提供するトランスポート機能の使用に関するガイドラインです。その目的は、ネットワークエンジニアや開発者がトランスポートプロトコルの機能を適切に活用するための指針を提供することです。
Internet Engineering Task Force (IETF) M. Welzl
Request for Comments: 8303 University of Oslo
Category: Informational M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
N. Khademi
University of Oslo
February 2018
On the Usage of Transport Features Provided by IETF Transport Protocols
IETFトランスポートプロトコルによって提供されるトランスポート機能の使用について
Abstract
概要
This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services (TAPS) API.
このドキュメントでは、トランスポートプロトコルの伝送制御プロトコル（TCP）、マルチパスTCP（MPTCP）、ストリーム制御伝送プロトコル（SCTP）、ユーザーデータグラムプロトコル（UDP）、および軽量ユーザーデータグラムプロトコル（UDP-Lite）がアプリケーションとアプリケーションにサービスを公開する方法について説明しますアプリケーションがこれらのサービスを構成する機能を構成および使用する方法。また、Low Extra Delay Background Transport（LEDBAT）輻輳制御メカニズムによって提供されるサービスについても説明します。説明により、トランスポートサービス（TAPS）APIでエクスポートできるトランスポート抽象化のセットが生成されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc8303.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8303で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Pass 1 ..........................................................6
3.1. Primitives Provided by TCP .................................6
3.1.1. Excluded Primitives or Parameters ...................9
3.2. Primitives Provided by MPTCP ..............................10
3.3. Primitives Provided by SCTP ...............................11
3.3.1. Excluded Primitives or Parameters ..................18
3.4. Primitives Provided by UDP and UDP-Lite ...................18
3.5. The Service of LEDBAT .....................................19
4. Pass 2 .........................................................20
4.1. CONNECTION-Related Primitives .............................21
4.2. DATA-Transfer-Related Primitives ..........................38
5. Pass 3 .........................................................41
5.1. CONNECTION-Related Transport Features .....................41
5.2. DATA-Transfer-Related Transport Features ..................47
5.2.1. Sending Data .......................................47
5.2.2. Receiving Data .....................................48
5.2.3. Errors .............................................49
6. IANA Considerations ............................................49
7. Security Considerations ........................................49
8. References .....................................................50
8.1. Normative References ......................................50
8.2. Informative References ....................................52
Appendix A. Overview of RFCs Used as Input for Pass 1 .............54
Appendix B. How This Document Was Developed .......................54
Acknowledgements ..................................................56
Authors' Addresses ................................................56
This specification describes how transport protocols offer transport services, such that applications using them are no longer directly tied to a specific protocol. Breaking this strict connection can reduce the effort for an application programmer, yet attain greater transport flexibility by pushing complexity into an underlying transport services (TAPS) system.
この仕様は、トランスポートプロトコルがトランスポートサービスをどのように提供するかを説明し、それらを使用するアプリケーションが特定のプロトコルに直接関連付けられないようにします。この厳密な接続を解除すると、アプリケーションプログラマーの労力を軽減できますが、基礎となるトランスポートサービス（TAPS）システムに複雑さを押し込むことにより、トランスポートの柔軟性を高めることができます。
This design process has started with a survey of the services provided by IETF transport protocols and congestion control mechanisms [RFC8095]. The present document and [RFC8304] complement this survey with an in-depth look at the defined interactions between applications and the following unicast transport protocols: Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite). We also define a primitive to enable/disable and configure the Low Extra Delay Background Transport (LEDBAT) unicast congestion control mechanism. For UDP and UDP-Lite, the first step of the protocol analysis -- a discussion of relevant RFC text -- is documented in [RFC8304].
この設計プロセスは、IETFトランスポートプロトコルおよび輻輳制御メカニズム[RFC8095]によって提供されるサービスの調査から始まりました。現在のドキュメントと[RFC8304]は、アプリケーションと次のユニキャストトランスポートプロトコルとの間に定義された相互作用を詳細に調べて、この調査を補足しています。伝送制御プロトコル（TCP）、マルチパスTCP（MPTCP）、ストリーム制御伝送プロトコル（SCTP）、ユーザーデータグラムプロトコル（UDP）、および軽量ユーザーデータグラムプロトコル（UDP-Lite）。また、低追加遅延バックグラウンドトランスポート（LEDBAT）ユニキャスト輻輳制御メカニズムを有効/無効にして構成するためのプリミティブを定義します。 UDPおよびUDP-Liteの場合、プロトコル分析の最初のステップ（関連するRFCテキストの説明）が[RFC8304]に文書化されています。
This snapshot in time of the IETF transport protocols is published as an RFC to document the analysis by the authors and the TAPS Working Group; this generates a set of transport abstractions that can be exported in a TAPS API. It provides the basis for the minimal set of transport services that end systems supporting TAPS should implement [TAPS-MINSET].
IETFトランスポートプロトコルのこの時点でのスナップショットは、作者とTAPSワーキンググループによる分析を文書化するためにRFCとして公開されています。これにより、TAPS APIでエクスポートできるトランスポートアブストラクションのセットが生成されます。 TAPSをサポートするエンドシステムが[TAPS-MINSET]を実装する必要がある最小限のトランスポートサービスのセットの基礎を提供します。
The list of primitives, events, and transport features in this document is strictly based on the parts of protocol specifications that describe what the protocol provides to an application using it and how the application interacts with it. Transport protocols provide communication between processes that operate on network endpoints, which means that they allow for multiplexing of communication between the same IP addresses, and this multiplexing is achieved using port numbers. Port multiplexing is therefore assumed to be always provided and not discussed in this document.
このドキュメントのプリミティブ、イベント、およびトランスポート機能のリストは、プロトコルがそれを使用するアプリケーションに何を提供するか、およびアプリケーションがそれと対話する方法を説明するプロトコル仕様の部分に厳密に基づいています。トランスポートプロトコルは、ネットワークエンドポイント上で動作するプロセス間の通信を提供します。つまり、同じIPアドレス間の通信の多重化を可能にし、この多重化はポート番号を使用して実現されます。したがって、ポートの多重化は常に提供されると想定されており、このドキュメントでは説明していません。
Parts of a protocol that are explicitly stated as optional to implement are not covered. Interactions between the application and a transport protocol that are not directly related to the operation of the protocol are also not covered. For example, there are various ways for an application to use socket options to indicate its interest in receiving certain notifications [RFC6458]. However, for the purpose of identifying primitives, events, and transport features, the ability to enable or disable the reception of notifications is irrelevant. Similarly, "one-to-many style sockets"
実装するオプションとして明示的に述べられているプロトコルの部分はカバーされません。プロトコルの動作に直接関係しないアプリケーションとトランスポートプロトコル間の相互作用についても説明しません。たとえば、アプリケーションがソケットオプションを使用して、特定の通知を受信することに関心があることを示すさまざまな方法があります[RFC6458]。ただし、プリミティブ、イベント、およびトランスポート機能を識別するために、通知の受信を有効または無効にする機能は関係ありません。同様に、「1対多スタイルのソケット」
[RFC6458] just affect the application programming style, not how the underlying protocol operates, and they are therefore not discussed here. The same is true for the ability to obtain the unchanged value of a parameter that an application has previously set (e.g., via "get" in get/set operations [RFC6458]).
[RFC6458]は、基礎となるプロトコルの動作方法ではなく、アプリケーションプログラミングスタイルに影響するだけなので、ここでは説明しません。アプリケーションが以前に設定したパラメーターの変更されていない値を取得する機能（たとえば、get / set操作[RFC6458]の「get」を介して）にも同じことが当てはまります。
The document presents a three-pass process to arrive at a list of transport features. In the first pass (pass 1), the relevant RFC text is discussed per protocol. In the second pass (pass 2), this discussion is used to derive a list of primitives and events that are uniformly categorized across protocols. Here, an attempt is made to present or -- where text describing primitives or events does not yet exist -- construct primitives or events in a slightly generalized form to highlight similarities. This is, for example, achieved by renaming primitives or events of protocols or by avoiding a strict 1:1 mapping between the primitives or events in the protocol specification and primitives or events in the list. Finally, the third pass (pass 3) presents transport features based on pass 2, identifying which protocols implement them.
このドキュメントは、トランスポート機能のリストに到達するための3つのパスのプロセスを示しています。最初のパス（パス1）では、関連するRFCテキストがプロトコルごとに説明されます。 2番目のパス（パス2）では、この説明を使用して、プロトコル全体で均一に分類されるプリミティブとイベントのリストを導出します。ここでは、またはプリミティブまたはイベントを説明するテキストがまだ存在しない場合に、プリミティブまたはイベントを少し一般化された形式で作成して類似性を強調する試みが行われています。これは、たとえば、プロトコルのプリミティブまたはイベントの名前を変更することによって、またはプロトコル仕様のプリミティブまたはイベントとリストのプリミティブまたはイベントの間の厳密な1：1マッピングを回避することによって達成されます。最後に、3番目のパス（パス3）は、パス2に基づくトランスポート機能を示し、どのプロトコルがそれらを実装するかを識別します。
In the list resulting from the second pass, some transport features are missing because they are implicit in some protocols, and they only become explicit when we consider the superset of all transport features offered by all protocols. For example, TCP always carries out congestion control; we have to consider it together with a protocol like UDP (which does not have congestion control) before we can consider congestion control as a transport feature. The complete list of transport features across all protocols is therefore only available after pass 3.
2番目のパスの結果のリストでは、一部のトランスポート機能は一部のプロトコルで暗黙的であるため欠落しており、すべてのプロトコルによって提供されるすべてのトランスポート機能のスーパーセットを検討した場合にのみ明示的になります。たとえば、TCPは常に輻輳制御を実行します。トランスポート機能として輻輳制御を検討する前に、UDP（輻輳制御を持たない）のようなプロトコルと共にそれを検討する必要があります。したがって、すべてのプロトコルにわたるトランスポート機能の完全なリストは、パス3以降でのみ利用できます。
Some protocols are connection oriented. Connection-oriented protocols often use an initial call to a specific primitive to open a connection before communication can progress and require communication to be explicitly terminated by issuing another call to a primitive (usually called 'Close'). A "connection" is the common state that some transport primitives refer to, e.g., to adjust general configuration settings. Connection establishment, maintenance, and termination are therefore used to categorize transport primitives of connection-oriented transport protocols in pass 2 and pass 3. For this purpose, UDP is assumed to be used with "connected" sockets, i.e., sockets that are bound to a specific pair of addresses and ports [RFC8304].
一部のプロトコルは接続指向です。接続指向プロトコルは、特定のプリミティブへの最初の呼び出しを使用して通信を開始する前に接続を開き、プリミティブへの別の呼び出し（通常は「閉じる」と呼ばれます）を発行して通信を明示的に終了する必要があります。 「接続」とは、一部のトランスポートプリミティブが、たとえば一般的な構成設定を調整するために参照する一般的な状態です。したがって、接続の確立、保守、および終了は、パス2およびパス3の接続指向のトランスポートプロトコルのトランスポートプリミティブを分類するために使用されます。この目的のために、UDPは「接続された」ソケット、つまり、アドレスとポートの特定のペア[RFC8304]。
Transport Feature: a specific end-to-end feature that the transport layer provides to an application. Examples include confidentiality, reliable delivery, ordered delivery, message-versus-stream orientation, etc.
トランスポート機能：トランスポート層がアプリケーションに提供する特定のエンドツーエンド機能。例としては、機密性、信頼できる配信、順序付き配信、メッセージ対ストリーム指向などが含まれます。
Transport Service: a set of transport features, without an association to any given framing protocol, which provides a complete service to an application.
トランスポートサービス：特定のフレーミングプロトコルに関連付けられていない一連のトランスポート機能。アプリケーションに完全なサービスを提供します。
Transport Protocol: an implementation that provides one or more transport services using a specific framing and header format on the wire.
トランスポートプロトコル：ワイヤー上で特定のフレーミングおよびヘッダー形式を使用して1つ以上のトランスポートサービスを提供する実装。
Transport Protocol Component: an implementation of a transport feature within a protocol.
トランスポートプロトコルコンポーネント：プロトコル内のトランスポート機能の実装。
Transport Service Instance: an arrangement of transport protocols with a selected set of features and configuration parameters that implement a single transport service, e.g., a protocol stack (RTP over UDP).
トランスポートサービスインスタンス：プロトコルスタック（RTP over UDP）などの単一のトランスポートサービスを実装する、選択された機能と構成パラメーターのセットを備えたトランスポートプロトコルの配置。
Application: an entity that uses the transport layer for end-to-end delivery of data across the network (this may also be an upper-layer protocol or tunnel encapsulation).
アプリケーション：ネットワークを介したエンドツーエンドのデータ配信にトランスポート層を使用するエンティティ（これは、上位層プロトコルまたはトンネルカプセル化の場合もあります）。
Endpoint: an entity that communicates with one or more other endpoints using a transport protocol.
エンドポイント：トランスポートプロトコルを使用して1つ以上の他のエンドポイントと通信するエンティティ。
Connection: shared state of two or more endpoints that persists across messages that are transmitted between these endpoints.
接続：2つ以上のエンドポイントの共有状態。これらのエンドポイント間で送信されるメッセージ全体で持続します。
Primitive: a function call that is used to locally communicate between an application and a transport endpoint. A primitive is related to one or more transport features.
プリミティブ：アプリケーションとトランスポートエンドポイントの間でローカルに通信するために使用される関数呼び出し。プリミティブは、1つ以上のトランスポート機能に関連しています。
Event: a primitive that is invoked by a transport endpoint.
イベント：トランスポートエンドポイントによって呼び出されるプリミティブ。
Parameter: a value passed between an application and a transport protocol by a primitive.
パラメータ：プリミティブによってアプリケーションとトランスポートプロトコルの間で渡される値。
Socket: the combination of a destination IP address and a destination port number.
ソケット：宛先IPアドレスと宛先ポート番号の組み合わせ。
Transport Address: the combination of an IP address, transport protocol, and the port number used by the transport protocol.
トランスポートアドレス：IPアドレス、トランスポートプロトコル、およびトランスポートプロトコルで使用されるポート番号の組み合わせ。
This first iteration summarizes the relevant text parts of the RFCs describing the protocols, focusing on what each transport protocol provides to the application and how it is used (abstract API descriptions, where they are available). When presenting primitives, events, and parameters, the use of lower- and upper-case characters is made uniform for the sake of readability.
この最初の反復では、プロトコルを説明するRFCの関連テキスト部分を要約し、各トランスポートプロトコルがアプリケーションに提供するものとそれがどのように使用されるかに焦点を当てています（使用可能な場合は、抽象APIの説明）。プリミティブ、イベント、およびパラメーターを提示する場合、読みやすさのために小文字と大文字の使用は統一されています。
The initial TCP specification [RFC0793] states:
最初のTCP仕様[RFC0793]は次のように述べています：
The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks.
伝送制御プロトコル（TCP）は、パケット交換コンピュータ通信ネットワーク内のホスト間、およびそのようなネットワークの相互接続されたシステム内のホスト間の信頼性の高いホスト間プロトコルとして使用することを目的としています。
Section 3.8 of [RFC0793] further specifies the interaction with the application by listing several transport primitives. It is also assumed that an Operating System provides a means for TCP to asynchronously signal the application; the primitives representing such signals are called 'events' in this section. This section describes the relevant primitives.
[RFC0793]のセクション3.8は、いくつかのトランスポートプリミティブをリストすることで、アプリケーションとの相互作用をさらに指定しています。また、オペレーティングシステムは、TCPがアプリケーションに非同期で信号を送るための手段を提供すると想定されています。このような信号を表すプリミティブは、このセクションでは「イベント」と呼ばれます。このセクションでは、関連するプリミティブについて説明します。
Open: This is either active or passive, to initiate a connection or listen for incoming connections. All other primitives are associated with a specific connection, which is assumed to first have been opened. An active open call contains a socket. A passive open call with a socket waits for a particular connection; alternatively, a passive open call can leave the socket unspecified to accept any incoming connection. A fully specified passive call can later be made active by calling 'Send'. Optionally, a timeout can be specified, after which TCP will abort the connection if data has not been successfully delivered to the destination (else a default timeout value is used). A procedure for aborting the connection is used to avoid excessive retransmissions, and an application is able to control the threshold used to determine the condition for aborting; this threshold may be measured in time units or as a count of retransmission [RFC1122]. This indicates that the timeout could also be specified as a count of retransmission.
オープン：これはアクティブまたはパッシブであり、接続を開始したり、着信接続をリッスンしたりします。他のすべてのプリミティブは特定の接続に関連付けられており、最初に開かれたと見なされます。アクティブなオープンコールにはソケットが含まれています。ソケットを使用するパッシブオープンコールは、特定の接続を待ちます。または、パッシブオープンコールでは、ソケットを未指定のままにして、着信接続を受け入れることができます。完全に指定されたパッシブコールは、後で「送信」を呼び出すことによってアクティブにすることができます。オプションで、タイムアウトを指定できます。その後、データが宛先に正常に配信されなかった場合、TCPは接続を中止します（そうでない場合、デフォルトのタイムアウト値が使用されます）。接続を中止する手順は、過度の再送信を回避するために使用され、アプリケーションは中止の条件を決定するために使用されるしきい値を制御できます。このしきい値は、時間単位で、または再送信のカウントとして測定できます[RFC1122]。これは、タイムアウトを再送信の回数として指定することもできることを示しています。
Also optional, for multihomed hosts, the local IP address can be provided [RFC1122]. If it is not provided, a default choice will be made in case of active open calls. A passive open call will await incoming connection requests to all local addresses and then maintain usage of the local IP address where the incoming connection request has arrived. Finally, the 'options' parameter allows the application to specify IP options such as Source Route, Record Route, or Timestamp [RFC1122]. It is not stated on which segments of a connection these options should be applied, but probably on all segments, as this is also stated in a specification given for the usage of the Source Route IP option (Section 4.2.3.8 of [RFC1122]). Source Route is the only non-optional IP option in this parameter, allowing an application to specify a source route when it actively opens a TCP connection.
また、オプションで、マルチホームホストの場合、ローカルIPアドレスを提供できます[RFC1122]。指定しない場合、アクティブなオープンコールの場合にデフォルトの選択が行われます。パッシブオープンコールは、すべてのローカルアドレスへの着信接続要求を待機し、着信接続要求が到着したローカルIPアドレスの使用を維持します。最後に、「options」パラメータを使用すると、アプリケーションでソースルート、レコードルート、タイムスタンプなどのIPオプションを指定できます[RFC1122]。接続のどのセグメントにこれらのオプションを適用する必要があるかは明記されていませんが、ソースルートIPオプションの使用に関する仕様（[RFC1122]のセクション4.2.3.8）に記載されているため、おそらくすべてのセグメントに適用されます。 。ソースルートは、このパラメーターのオプションではない唯一のIPオプションであり、アプリケーションがTCP接続をアクティブに開いたときにソースルートを指定できるようにします。
Master Key Tuples (MKTs) for authentication can optionally be configured when calling 'Open' (Section 7.1 of [RFC5925]). When authentication is in use, complete TCP segments are authenticated, including the TCP IPv4 pseudoheader, TCP header, and TCP data.
認証用のマスターキータプル（MKT）は、「開く」を呼び出すときにオプションで設定できます（[RFC5925]のセクション7.1）。認証が使用されている場合、TCP IPv4疑似ヘッダー、TCPヘッダー、TCPデータを含む完全なTCPセグメントが認証されます。
TCP Fast Open (TFO) [RFC7413] allows applications to immediately hand over a message from the active open to the passive open side of a TCP connection together with the first message establishment packet (the SYN). This can be useful for applications that are sensitive to TCP's connection setup delay. [RFC7413] states that "TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service-port basis." The size of the message sent with TFO cannot be more than TCP's maximum segment size (minus options used in the SYN). For the active open side, it is recommended to change or replace the connect() call in order to support a user data buffer argument [RFC7413]. For the passive open side, the application needs to enable the reception of Fast Open requests, e.g., via a new TCP_FASTOPEN setsockopt() socket option before listen(). The receiving application must be prepared to accept duplicates of the TFO message, as the first data written to a socket can be delivered more than once to the application on the remote host.
TCP Fast Open（TFO）[RFC7413]を使用すると、アプリケーションは、TCP接続のアクティブオープン側からパッシブオープン側に、最初のメッセージ確立パケット（SYN）とともにメッセージをすぐに渡すことができます。これは、TCPの接続セットアップ遅延の影響を受けやすいアプリケーションに役立ちます。 [RFC7413]は、「TCP実装はデフォルトでTFOを使用してはならず、サービスポートごとにアプリケーションによって明示的に要求された場合にのみTFOを使用する必要がある」と述べています。 TFOで送信されるメッセージのサイズは、TCPの最大セグメントサイズ（SYNで使用されるマイナスオプション）を超えることはできません。アクティブなオープン側では、ユーザーデータバッファー引数[RFC7413]をサポートするために、connect()コールを変更または置き換えることをお勧めします。パッシブオープンサイドの場合、アプリケーションは、Fast Openリクエストの受信を有効にする必要があります。たとえば、listen()の前に新しいTCP_FASTOPEN setsockopt()ソケットオプションを使用します。ソケットに書き込まれた最初のデータは、リモートホスト上のアプリケーションに複数回配信される可能性があるため、受信アプリケーションはTFOメッセージの複製を受け入れる準備をする必要があります。
Send: This is the primitive that an application uses to give the local TCP transport endpoint a number of bytes that TCP should reliably send to the other side of the connection. The 'urgent' flag, if set, states that the data handed over by this send call is urgent and this urgency should be indicated to the receiving process in case the receiving application has not yet consumed all non-urgent data preceding it. An optional timeout parameter can be provided that updates the connection's timeout (see 'Open'). Additionally, optional parameters allow the ability to indicate the preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection (Section 7.1 of [RFC5925]).
送信：これは、TCPが接続の反対側に確実に送信する必要があるバイト数をローカルTCPトランスポートエンドポイントに与えるためにアプリケーションが使用するプリミティブです。 「緊急」フラグが設定されている場合は、この送信呼び出しによって渡されたデータが緊急であることを示し、受信アプリケーションがその前のすべての非緊急データをまだ消費していない場合に備えて、この緊急性を受信プロセスに示す必要があります。オプションのタイムアウトパラメータを指定して、接続のタイムアウトを更新できます（「開く」を参照）。さらに、オプションのパラメータを使用すると、接続の優先送信MKT（current_key）や優先受信MKT（rnext_key）を指定できます（[RFC5925]のセクション7.1）。
Receive: This primitive allocates a receiving buffer for a provided number of bytes. It returns the number of received bytes provided in the buffer when these bytes have been received and written into the buffer by TCP. The application is informed of urgent data via an 'urgent' flag: if it is on, there is urgent data; if it is off, there is no urgent data or this call to 'Receive' has returned all the urgent data. The application is also informed about the current_key and rnext_key information carried in a recently received segment via an optional parameter (Section 7.1 of [RFC5925]).
受信：このプリミティブは、指定されたバイト数の受信バッファーを割り当てます。これらのバイトが受信され、TCPによってバッファーに書き込まれたときに、バッファーに提供された受信バイト数を返します。アプリケーションは、「緊急」フラグを介して緊急データを通知されます。オンの場合、緊急データがあります。オフの場合、緊急データはないか、この 'Receive'の呼び出しによりすべての緊急データが返されました。アプリケーションは、オプションのパラメーターを介して、最近受信したセグメントで運ばれるcurrent_keyおよびrnext_key情報についても通知されます（[RFC5925]のセクション7.1）。
Close: This primitive closes one side of a connection. It is semantically equivalent to "I have no more data to send" but does not mean "I will not receive any more", as the other side may still have data to send. This call reliably delivers any data that has already been given to TCP (and if that fails, 'Close' becomes 'abort').
Close：このプリミティブは、接続の片側を閉じます。これは、意味的には「送信するデータがない」と同じですが、「もう受信しない」という意味ではありません。相手側に送信するデータがある可能性があるためです。この呼び出しは、TCPにすでに与えられているすべてのデータを確実に配信します（失敗した場合、「閉じる」は「中止」になります）。
Abort: This primitive causes all pending 'Send' and 'Receive' calls to be aborted. A TCP "RESET" message is sent to the TCP endpoint on the other side of the connection [RFC0793].
中止：このプリミティブにより、保留中のすべての「送信」および「受信」呼び出しが中止されます。 TCP "RESET"メッセージは、接続の反対側のTCPエンドポイントに送信されます[RFC0793]。
Close Event: TCP uses this primitive to inform an application that the application on the other side has called the 'Close' primitive, so the local application can also issue a 'Close' and terminate the connection gracefully. See [RFC0793], Section 3.5.
Closeイベント：TCPはこのプリミティブを使用して、反対側のアプリケーションが「Close」プリミティブを呼び出したことをアプリケーションに通知します。したがって、ローカルアプリケーションも「Close」を発行して接続を正常に終了できます。 [RFC0793]、セクション3.5をご覧ください。
Abort Event: When TCP aborts a connection upon receiving a "RESET" from the peer, it "advises the user and goes to the CLOSED state." See [RFC0793], Section 3.4.
中止イベント：ピアから「リセット」を受信したときにTCPが接続を中止すると、「ユーザーに通知してCLOSED状態になります」。 [RFC0793]のセクション3.4をご覧ください。
User Timeout Event: This event is executed when the user timeout (Section 3.9 of [RFC0793]) expires (see the definition of 'Open' in this section). All queues are flushed, and the application is informed that the connection had to be aborted due to user timeout.
ユーザータイムアウトイベント：このイベントは、ユーザータイムアウト（[RFC0793]のセクション3.9）が期限切れになると実行されます（このセクションの「開く」の定義を参照）。すべてのキューがフラッシュされ、ユーザータイムアウトのために接続を中止する必要があることがアプリケーションに通知されます。
Error_Report event: This event informs the application of "soft errors" that can be safely ignored [RFC5461], including the arrival of an ICMP error message or excessive retransmissions (reaching a threshold below the threshold where the connection is aborted). See Section 4.2.4.1 of [RFC1122].
Error_Reportイベント：このイベントは、安全に無視できる[ソフトエラー]をアプリケーションに通知します[RFC5461]。これには、ICMPエラーメッセージの到着や過度の再送信（接続が中止されるしきい値を下回るしきい値に達する）が含まれます。 [RFC1122]のセクション4.2.4.1を参照してください。
Type-of-Service: Section 4.2.4.2 of the requirements for Internet hosts [RFC1122] states that "The application layer MUST be able to specify the Type-of-Service (TOS) for segments that are sent on a connection." The application should be able to change the TOS during the connection lifetime, and the TOS value should be passed to the IP layer unchanged. Since then, the TOS field has been redefined. The Differentiated Services (Diffserv) model [RFC2475] [RFC3260] replaces this field in the IP header, assigning the six most significant bits to carry the Differentiated Services Code Point (DSCP) field [RFC2474].
Type-of-Service：インターネットホストの要件のセクション4.2.4.2 [RFC1122]には、「アプリケーションレイヤーは、接続で送信されるセグメントのType-of-Service（TOS）を指定できなければならない」と述べています。アプリケーションは接続の存続期間中にTOSを変更でき、TOS値は変更されずにIP層に渡される必要があります。その後、TOSフィールドが再定義されました。 Differentiated Services（Diffserv）モデル[RFC2475] [RFC3260]は、IPヘッダーのこのフィールドを置き換え、Differentiated Services Code Point（DSCP）フィールド[RFC2474]を伝送するために最上位6ビットを割り当てます。
Nagle: The Nagle algorithm delays sending data for some time to increase the likelihood of sending a full-sized segment (Section 4.2.3.4 of [RFC1122]). An application can disable the Nagle algorithm for an individual connection.
Nagle：Nagleアルゴリズムは、フルサイズのセグメントを送信する可能性を高めるために、データの送信をしばらく遅延させます（[RFC1122]のセクション4.2.3.4）。アプリケーションは、個々の接続に対してNagleアルゴリズムを無効にすることができます。
User Timeout Option: The User Timeout Option (UTO) [RFC5482] allows one end of a TCP connection to advertise its current user timeout value so that the other end of the TCP connection can adapt its own user timeout accordingly. In addition to the configurable value of the user timeout (see 'Send'), there are three per-connection state variables that an application can adjust to control the operation of the UTO: 'adv_uto' is the value of the UTO advertised to the remote TCP peer (default: system-wide default user timeout); 'enabled' (default false) is a boolean-type flag that controls whether the UTO option is enabled for a connection. This applies to both sending and receiving. 'changeable' is a boolean-type flag (default true) that controls whether the user timeout may be changed based on a UTO option received from the other end of the connection. 'changeable' becomes false when an application explicitly sets the user timeout (see 'Send').
ユーザータイムアウトオプション：ユーザータイムアウトオプション（UTO）[RFC5482]を使用すると、TCP接続の一方の端で現在のユーザータイムアウト値をアドバタイズできるため、TCP接続のもう一方の端で独自のユーザータイムアウトを適切に調整できます。ユーザータイムアウトの構成可能な値（「送信」を参照）に加えて、アプリケーションがUTOの操作を制御するために調整できる接続ごとの状態変数が3つあります。「adv_uto」は、アドバタイズされたUTOの値です。リモートTCPピア（デフォルト：システム全体のデフォルトのユーザータイムアウト）; 'enabled'（デフォルトはfalse）は、接続に対してUTOオプションを有効にするかどうかを制御するブール型のフラグです。これは送信と受信の両方に適用されます。 'changeable'は、接続の反対側から受信したUTOオプションに基づいてユーザータイムアウトを変更できるかどうかを制御するブール型のフラグ（デフォルトはtrue）です。アプリケーションがユーザータイムアウトを明示的に設定すると、「変更可能」はfalseになります（「送信」を参照）。
Set/Get Authentication Parameters: The preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection can be configured. Information about current_key and rnext_key carried in a recently received segment can be retrieved (Section 7.1 of [RFC5925]).
認証パラメータの設定/取得：接続の優先送信MKT（current_key）および/または優先受信MKT（rnext_key）を構成できます。最近受信したセグメントに含まれるcurrent_keyとrnext_keyに関する情報を取得できます（[RFC5925]のセクション7.1）。
The 'Open' primitive can be handed optional precedence or security/ compartment information [RFC0793], but this was not included here because it is mostly irrelevant today [RFC7414].
「Open」プリミティブは、オプションの優先順位またはセキュリティ/コンパートメント情報を渡すことができます[RFC0793]が、今日はほとんど関係がないため、ここには含まれていません[RFC7414]。
The 'Status' primitive was not included because the initial TCP
specification describes this primitive as "implementation dependent"
and states that it "could be excluded without adverse effect"
[RFC0793]. Moreover, while a data block containing specific
information is described, it is also stated that not all of this
information may always be available. While [RFC5925] states that
'Status' "SHOULD be augmented to allow the MKTs of a current or
pending connection to be read (for confirmation)", the same
information is also available via 'Receive', which, following
[RFC5925], "MUST be augmented" with that functionality. The 'Send'
primitive includes an optional 'push' flag which, if set, requires
data to be promptly transmitted to the receiver without delay
[RFC0793]; the 'Receive' primitive described in can (under some
conditions) yield the status of the 'push' flag. Because "push"
functionality is optional to implement for both the 'Send' and
'Receive' primitives [RFC1122], this functionality is not included
here. The requirements for Internet hosts [RFC1122] also introduce
keep-alives to TCP, but these are optional to implement and hence not
considered here. The same document also describes that "some TCP
implementations have included a FLUSH call", indicating that this
call is also optional to implement; therefore, it is not considered
here.
MPTCP is an extension to TCP that allows the use of multiple paths for a single data stream. It achieves this by creating different so-called TCP subflows for each of the interfaces and scheduling the traffic across these TCP subflows. The service provided by MPTCP is described as follows in [RFC6182]:
MPTCPはTCPの拡張機能で、単一のデータストリームに複数のパスを使用できます。これは、インターフェイスごとに異なるいわゆるTCPサブフローを作成し、これらのTCPサブフロー全体でトラフィックをスケジュールすることによって実現します。 MPTCPによって提供されるサービスは、[RFC6182]で次のように説明されています。
Multipath TCP MUST follow the same service model as TCP [RFC0793]: in-order, reliable, and byte-oriented delivery. Furthermore, a Multipath TCP connection SHOULD provide the application with no worse throughput or resilience than it would expect from running a single TCP connection over any one of its available paths.
マルチパスTCPは、TCP [RFC0793]と同じサービスモデルに従う必要があります：順序正しく、信頼性があり、バイト指向の配信。さらに、マルチパスTCP接続は、利用可能なパスのいずれかを介して単一のTCP接続を実行することから期待されるよりも悪いスループットや回復力をアプリケーションに提供する必要があります（SHOULD）。
Further, there are some constraints on the API exposed by MPTCP, as stated in [RFC6182]:
さらに、[RFC6182]で述べられているように、MPTCPによって公開されるAPIにはいくつかの制約があります。
A multipath-capable equivalent of TCP MUST retain some level of backward compatibility with existing TCP APIs, so that existing applications can use the newer transport merely by upgrading the operating systems of the end hosts.
マルチパス対応のTCPは、既存のTCP APIとのある程度の下位互換性を維持する必要があるため、既存のアプリケーションは、エンドホストのオペレーティングシステムをアップグレードするだけで新しいトランスポートを使用できます。
As such, the primitives provided by MPTCP are equivalent to the ones provided by TCP. Nevertheless, the MPTCP RFCs [RFC6824] and [RFC6897] clarify some parts of TCP's primitives with respect to MPTCP and add some extensions for better control on MPTCP's subflows. Hereafter is a list of the clarifications and extensions the above-cited RFCs provide to TCP's primitives.
そのため、MPTCPが提供するプリミティブは、TCPが提供するプリミティブと同等です。それにもかかわらず、MPTCP RFC [RFC6824]および[RFC6897]は、MPTCPに関するTCPのプリミティブの一部を明確にし、MPTCPのサブフローをより適切に制御するためにいくつかの拡張機能を追加します。以下は、上記のRFCがTCPのプリミティブに提供する明確化と拡張のリストです。
Open: "An application should be able to request to turn on or turn off the usage of MPTCP" [RFC6897]. This functionality can be provided through a socket option called 'tcp_multipath_enable'. Further, MPTCP must be disabled in case the application is binding to a specific address [RFC6897].
開く：「アプリケーションは、MPTCPの使用をオンまたはオフにするように要求できる必要があります」[RFC6897]。この機能は、「tcp_multipath_enable」と呼ばれるソケットオプションを通じて提供できます。さらに、アプリケーションが特定のアドレスにバインドしている場合は、MPTCPを無効にする必要があります[RFC6897]。
Send/Receive: The sending and receiving of data does not require any changes to the application when MPTCP is being used [RFC6824]. The MPTCP-layer will take one input data stream from an application, and split it into one or more subflows, with sufficient control information to allow it to be reassembled and delivered reliably and in order to the recipient application.
送受信：MPTCPが使用されている場合、データの送受信でアプリケーションを変更する必要はありません[RFC6824]。 MPTCP層は、アプリケーションから1つの入力データストリームを受け取り、それを1つまたは複数のサブフローに分割します。十分な制御情報を使用して、再構築し、受信側アプリケーションに確実に配信できるようにします。
The use of the Urgent Pointer is special in MPTCP [RFC6824], which states: "a TCP subflow MUST NOT use the Urgent Pointer to interrupt an existing mapping."
緊急ポインターの使用はMPTCP [RFC6824]で特別であり、「TCPサブフローは、既存のマッピングを中断するために緊急ポインターを使用してはなりません（MUST NOT）」。
Address and Subflow Management: MPTCP uses different addresses and allows a host to announce these addresses as part of the protocol. The MPTCP API Considerations RFC [RFC6897] says "An application should be able to restrict MPTCP to binding to a given set of addresses" and thus allows applications to limit the set of addresses that are being used by MPTCP. Further, "An application should be able to obtain information on the pairs of addresses used by the MPTCP subflows."
アドレスとサブフローの管理：MPTCPは異なるアドレスを使用し、ホストがこれらのアドレスをプロトコルの一部としてアナウンスできるようにします。 MPTCP APIに関する考慮事項RFC [RFC6897]は、「アプリケーションはMPTCPを特定のアドレスセットへのバインドに制限できる必要がある」と述べており、アプリケーションがMPTCPによって使用されているアドレスセットを制限できるようにします。さらに、「アプリケーションは、MPTCPサブフローで使用されるアドレスのペアに関する情報を取得できる必要があります。」
TCP has a number of limitations that SCTP removes (Section 1.1 of [RFC4960]). The following three removed limitations directly translate into transport features that are visible to an application using SCTP: 1) it allows for preservation of message delimiters; 2) it does not provide in-order or reliable delivery unless the application wants that; 3) multihoming is supported. In SCTP, connections are called "associations" and they can be between not only two (as in TCP) but multiple addresses at each endpoint.
TCPには、SCTPによって削除されるいくつかの制限があります（[RFC4960]のセクション1.1）。削除された次の3つの制限は、SCTPを使用するアプリケーションに表示されるトランスポート機能に直接変換されます。1）メッセージ区切り文字の保持を可能にします。 2）アプリケーションが必要としない限り、順序どおりの配信や信頼性の高い配信は提供されません。 3）マルチホーミングがサポートされています。 SCTPでは、接続は「アソシエーション」と呼ばれ、2つの（TCPの場合のような）間だけでなく、各エンドポイントの複数のアドレス間でも可能です。
Section 10 of the SCTP base protocol specification [RFC4960] specifies the interaction with the application (which SCTP calls the "Upper-Layer Protocol (ULP)"). It is assumed that the Operating System provides a means for SCTP to asynchronously signal the application; the primitives representing such signals are called 'events' in this section. Here, we describe the relevant primitives. In addition to the abstract API described in Section 10 of [RFC4960], an extension to the sockets API is described in [RFC6458]. This covers the functionality of the base protocol [RFC4960] and some of its extensions [RFC3758] [RFC4895] [RFC5061]. For other protocol extensions [RFC6525] [RFC6951] [RFC7053] [RFC7496] [RFC7829]
SCTP基本プロトコル仕様[RFC4960]のセクション10は、アプリケーション（SCTPが「上位層プロトコル（ULP）と呼ぶ」との対話を指定しています。オペレーティングシステムは、SCTPがアプリケーションに非同期に信号を送るための手段を提供すると想定されています。このような信号を表すプリミティブは、このセクションでは「イベント」と呼ばれます。ここでは、関連するプリミティブについて説明します。 [RFC4960]のセクション10で説明されている抽象APIに加えて、ソケットAPIの拡張機能が[RFC6458]で説明されています。これは、基本プロトコル[RFC4960]とその拡張機能[RFC3758] [RFC4895] [RFC5061]の機能をカバーしています。他のプロトコル拡張[RFC6525] [RFC6951] [RFC7053] [RFC7496] [RFC7829]
[RFC8260], the corresponding extensions of the sockets API are specified in these protocol specifications. The functionality exposed to the ULP through all these APIs is considered here.
[RFC8260]、ソケットAPIの対応する拡張機能は、これらのプロトコル仕様で指定されています。これらすべてのAPIを通じてULPに公開される機能は、ここで考慮されます。
The abstract API contains a 'SetProtocolParameters' primitive that allows elements of a parameter list [RFC4960] to be adjusted; it is stated that SCTP implementations "may allow ULP to customize some of these protocol parameters", indicating that none of the elements of this parameter list are mandatory to make ULP configurable. Thus, we only consider the parameters in the abstract API that are also covered in one of the other RFCs listed above, which leads us to exclude the parameters 'RTO.Alpha', 'RTO.Beta', and 'HB.Max.Burst'. For clarity, we also replace 'SetProtocolParameters' itself with primitives that adjust parameters or groups of parameters that fit together.
抽象APIには、パラメータリスト[RFC4960]の要素を調整できる「SetProtocolParameters」プリミティブが含まれています。 SCTP実装は「ULPがこれらのプロトコルパラメータの一部をカスタマイズできるようにする」と述べられており、このパラメータリストのどの要素もULPを構成可能にするために必須ではないことを示しています。したがって、上記にリストされた他のRFCの1つでもカバーされている抽象APIのパラメーターのみを考慮するため、パラメーター 'RTO.Alpha'、 'RTO.Beta'、および 'HB.Max.Burstが除外されます。 '。わかりやすくするために、「SetProtocolParameters」自体も、パラメータまたはパラメータグループを調整して調整するプリミティブに置き換えます。
Initialize: Initialize creates a local SCTP instance that it binds to a set of local addresses (and, if provided, a local port number) [RFC4960]. Initialize needs to be called only once per set of local addresses. A number of per-association initialization parameters can be used when an association is created, but before it is connected (via the primitive 'Associate' below): the maximum number of inbound streams the application is prepared to support, the maximum number of attempts to be made when sending the INIT (the first message of association establishment), and the maximum retransmission timeout (RTO) value to use when attempting an INIT [RFC6458]. At this point, before connecting, an application can also enable UDP encapsulation by configuring the remote UDP encapsulation port number [RFC6951].
Initialize：Initializeは、ローカルSCTPインスタンスを作成します。このインスタンスは、一連のローカルアドレス（および、指定されている場合はローカルポート番号）[RFC4960]にバインドします。 Initializeは、ローカルアドレスのセットごとに1回だけ呼び出す必要があります。アソシエーションの作成時に、アソシエーションごとにいくつかの初期化パラメーターを使用できますが、アソシエーションが接続される前に（以下のプリミティブ「Associate」を介して）、アプリケーションがサポートする準備ができているインバウンドストリームの最大数、最大試行回数INIT（アソシエーション確立の最初のメッセージ）を送信するときに行われ、INIT [RFC6458]を試行するときに使用する最大再送信タイムアウト（RTO）値。この時点で、アプリケーションは接続する前に、リモートUDPカプセル化ポート番号[RFC6951]を構成することにより、UDPカプセル化を有効にすることもできます。
Associate: This creates an association (the SCTP equivalent of a connection) that connects the local SCTP instance and a remote SCTP instance. To identify the remote endpoint, it can be given one or multiple (using "connectx") sockets (Section 9.9 of [RFC6458]). Most primitives are associated with a specific association, which is assumed to first have been created. Associate can return a list of destination transport addresses so that multiple paths can later be used. One of the returned sockets will be selected by the local endpoint as the default primary path for sending SCTP packets to this peer, but this choice can be changed by the application using the list of destination addresses. Associate is also given the number of outgoing streams to request and optionally returns the number of negotiated outgoing streams. An optional parameter of 32 bits, the adaptation layer indication, can be provided [RFC5061]. If authenticated chunks are used, the chunk types required to be sent authenticated by the peer can be provided [RFC4895]. An 'SCTP_Cant_Str_Assoc' notification is used to inform the application of a failure to create an association [RFC6458]. An application could use sendto() or sendmsg() to implicitly set up an association, thereby handing over a message that SCTP might send during the association setup phase [RFC6458]. Note that this mechanism is different from TCP's TFO mechanism: the message would arrive only once, after at least one RTT, as it is sent together with the third message exchanged during association setup, the COOKIE-ECHO chunk).
関連付け：これにより、ローカルSCTPインスタンスとリモートSCTPインスタンスを接続する関連付け（接続に相当するSCTP）が作成されます。リモートエンドポイントを識別するために、1つまたは複数の（「connectx」を使用して）ソケットを指定できます（[RFC6458]のセクション9.9）。ほとんどのプリミティブは特定の関連付けに関連付けられており、最初に作成されたと見なされます。 Associateは宛先トランスポートアドレスのリストを返すことができるため、後で複数のパスを使用できます。返されたソケットの1つは、ローカルエンドポイントによって、このピアにSCTPパケットを送信するためのデフォルトのプライマリパスとして選択されますが、この選択は、宛先アドレスのリストを使用するアプリケーションによって変更できます。アソシエイトには、要求する発信ストリームの数も与えられ、オプションでネゴシエートされた発信ストリームの数を返します。 32ビットのオプションのパラメーターであるアダプテーション層の表示を提供できます[RFC5061]。認証されたチャンクが使用される場合、ピアによって認証されて送信される必要があるチャンクタイプを提供することができます[RFC4895]。 'SCTP_Cant_Str_Assoc'通知は、アソシエーションの作成の失敗をアプリケーションに通知するために使用されます[RFC6458]。アプリケーションは、sendto()またはsendmsg()を使用して関連付けを暗黙的にセットアップし、それによって、関連付けセットアップフェーズ中にSCTPが送信するメッセージを引き渡すことができます[RFC6458]。このメカニズムはTCPのTFOメカニズムとは異なることに注意してください。メッセージは、アソシエーションのセットアップ中に交換される3番目のメッセージであるCOOKIE-ECHOチャンクと一緒に送信されるため、少なくとも1つのRTTの後で1回だけ到着します。
Send: This sends a message of a certain length in bytes over an association. A number can be provided to later refer to the correct message when reporting an error, and a stream id is provided to specify the stream to be used inside an association (we consider this as a mandatory parameter here for simplicity: if not provided, the stream id defaults to 0). A condition to abandon the message can be specified (for example limiting the number of retransmissions or the lifetime of the user message). This allows control of the partial reliability extension [RFC3758] [RFC7496]. An optional maximum lifetime can specify the time after which the message should be discarded rather than sent. A choice (advisory, i.e., not guaranteed) of the preferred path can be made by providing a socket, and the message can be delivered out-of-order if the 'unordered' flag is set. An advisory flag indicates that the peer should not delay the acknowledgement of the user message provided [RFC7053]. Another advisory flag indicates whether the application prefers to avoid bundling user data with other outbound DATA chunks (i.e., in the same packet). A payload protocol-id can be provided to pass a value that indicates the type of payload protocol data to the peer. If authenticated chunks are used, the key identifier for authenticating DATA chunks can be provided [RFC4895].
送信：これは、関連付けを介してバイト単位で特定の長さのメッセージを送信します。後でエラーを報告するときに正しいメッセージを参照するために番号を指定できます。関連付け内で使用するストリームを指定するためにストリームIDを指定します（ここでは、簡単にするためにこれを必須パラメーターと見なします。指定しない場合は、ストリームIDのデフォルトは0です）。メッセージを破棄する条件を指定できます（たとえば、再送信の数やユーザーメッセージの有効期間を制限します）。これにより、部分信頼性拡張[RFC3758] [RFC7496]を制御できます。オプションの最大有効期間は、メッセージが送信されるのではなく破棄されるまでの時間を指定できます。優先パスの選択（助言、つまり保証されない）は、ソケットを提供することによって行うことができ、「順序付けられていない」フラグが設定されている場合、メッセージは順序どおりに配信されない可能性があります。助言フラグは、ピアが提供されたユーザーメッセージ[RFC7053]の確認応答を遅延させてはならないことを示します。別の助言フラグは、アプリケーションがユーザーデータを他の送信DATAチャンク（つまり、同じパケット内）にバンドルすることを避けることを好むかどうかを示します。ペイロードプロトコルデータのタイプを示す値をピアに渡すために、ペイロードプロトコルIDを提供できます。認証されたチャンクが使用される場合、DATAチャンクを認証するためのキー識別子を提供できます[RFC4895]。
Receive: Messages are received from an association, and optionally a stream within the association, with their size returned. The application is notified of the availability of data via a 'Data Arrive' notification. If the sender has included a payload protocol-id, this value is also returned. If the received message is only a partial delivery of a whole message, a 'partial' flag will indicate so, in which case the stream id and a stream sequence number are provided to the application.
受信：アソシエーションからメッセージが受信され、オプションでアソシエーション内のストリームが受信され、サイズが返されます。アプリケーションは、「データ到着」通知を介してデータの可用性を通知されます。送信者がペイロードのプロトコルIDを含めた場合、この値も返されます。受信したメッセージがメッセージ全体の一部のみの配信である場合、「部分的」フラグがそうであることを示します。この場合、ストリームIDとストリームシーケンス番号がアプリケーションに提供されます。
Shutdown: This primitive gracefully closes an association, reliably delivering any data that has already been handed over to SCTP. A parameter lets the application control whether further receive or send operations or both are disabled when the call is issued. A return code informs about success or failure of this procedure.
シャットダウン：このプリミティブは関連付けを適切に閉じ、すでにSCTPに渡されたデータを確実に配信します。パラメータを使用すると、アプリケーションは、呼び出しが発行されたときに、以降の受信操作または送信操作、あるいはその両方を無効にするかどうかを制御できます。戻りコードは、この手順の成功または失敗を通知します。
Abort: This ungracefully closes an association, by discarding any locally queued data and informing the peer that the association was aborted. Optionally, an abort reason to be passed to the peer may be provided by the application. A return code informs about success or failure of this procedure.
中止：これは、ローカルでキューに入れられたデータを破棄し、関連付けが中止されたことをピアに通知することで、関連付けを不注意に閉じます。必要に応じて、ピアに渡される中止理由がアプリケーションによって提供されます。戻りコードは、この手順の成功または失敗を通知します。
Change Heartbeat / Request Heartbeat: This allows the application to enable/disable heartbeats and optionally specify a heartbeat frequency as well as requesting a single heartbeat to be carried out upon a function call, with a notification about success or failure of transmitting the HEARTBEAT chunk to the destination.
ハートビートの変更/ハートビートの要求：これにより、アプリケーションはハートビートを有効/無効にしたり、オプションでハートビート頻度を指定したり、関数呼び出し時に単一のハートビートを実行したり、HEARTBEATチャンクの送信の成功または失敗に関する通知を要求したりできます。目的地。
Configure Max. Retransmissions of an Association: The parameter 'Association.Max.Retrans' [RFC4960] (called "sasoc_maxrxt" in the SCTP sockets API extensions [RFC6458]) allows the configuration of the number of unsuccessful retransmissions after which an entire association is considered as failed; this should invoke a 'Communication Lost' notification.
最大を構成します。アソシエーションの再送信：パラメータ 'Association.Max.Retrans' [RFC4960]（SCTPソケットAPI拡張[RFC6458]では "sasoc_maxrxt"と呼ばれます）により、アソシエーション全体が失敗したと見なされるまでの再送信の失敗回数を設定できます。 ;これにより、「通信喪失」通知が呼び出されます。
Set Primary: This allows the ability to set a new primary default path for an association by providing a socket. Optionally, a default source address to be used in IP datagrams can be provided.
プライマリの設定：ソケットを提供することで、関連付けの新しいプライマリデフォルトパスを設定できます。オプションで、IPデータグラムで使用されるデフォルトの送信元アドレスを指定できます。
Change Local Address / Set Peer Primary: This allows an endpoint to add/remove local addresses to/from an association. In addition, the peer can be given a hint for which address to use as the primary address [RFC5061].
ローカルアドレスの変更/ピアプライマリの設定：これにより、エンドポイントはローカルアドレスを関連付けに追加したり、関連付けから削除したりできます。さらに、ピアには、プライマリアドレスとして使用するアドレスのヒントを与えることができます[RFC5061]。
Configure Path Switchover: The abstract API contains a primitive called 'Set Failure Threshold' [RFC4960]. This configures the parameter 'Path.Max.Retrans', which determines after how many retransmissions a particular transport address is considered as unreachable. If there are more transport addresses available in an association, reaching this limit will invoke a path switchover. An extension called "SCTP-PF" adds a concept of "Potentially Failed (PF)" paths to this method [RFC7829]. When a path is in PF state, SCTP will not entirely give up sending on that path, but it will preferably send data on other active paths if such paths are available. Entering the PF state is done upon exceeding a configured maximum number of retransmissions. Thus, for all paths where this mechanism is used, there are two configurable error thresholds: one to decide that a path is in PF state, and one to decide that the transport address is unreachable.
パスの切り替えの構成：抽象APIには、「Set Failure Threshold」というプリミティブが含まれています[RFC4960]。これは、パラメーター 'Path.Max.Retrans'を構成します。これは、特定のトランスポートアドレスが到達不能と見なされる再送信回数を決定します。アソシエーションで使用可能なトランスポートアドレスがさらにある場合、この制限に達すると、パススイッチオーバーが呼び出されます。 「SCTP-PF」と呼ばれる拡張機能は、「Potentially Failed（PF）」パスの概念をこのメソッドに追加します[RFC7829]。パスがPF状態の場合、SCTPはそのパスでの送信を完全に中止するわけではありませんが、他のアクティブなパスが使用可能な場合は、そのパスでデータを送信することが望ましいです。 PF状態に入るのは、構成済みの再送信の最大数を超えると行われます。したがって、このメカニズムが使用されるすべてのパスには、2つの構成可能なエラーしきい値があります。1つはパスがPF状態であることを決定するためのもので、もう1つはトランスポートアドレスが到達不能であることを決定するためのものです。
Set/Get Authentication Parameters: This allows an endpoint to add/ remove key material to/from an association. In addition, the chunk types being authenticated can be queried [RFC4895].
認証パラメータの設定/取得：これにより、エンドポイントは、関連付けに対してキーマテリアルを追加/削除できます。さらに、認証されているチャンクタイプを照会できます[RFC4895]。
Add/Reset Streams, Reset Association: This allows an endpoint to add streams to an existing association or to reset them individually. Additionally, the association can be reset [RFC6525].
ストリームの追加/リセット、関連付けのリセット：これにより、エンドポイントはストリームを既存の関連付けに追加したり、個別にリセットしたりできます。さらに、関連付けはリセットできます[RFC6525]。
Status: The 'Status' primitive returns a data block with information about a specified association, containing: an association connection state; a destination transport address list; destination transport address reachability states; current local and peer receiver window sizes; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; a primary path; the most recent Smoothed Round-Trip Time (SRTT) on a primary path; RTO on a primary path; SRTT and RTO on other destination addresses [RFC4960]; and an MTU per path [RFC6458].
ステータス：「ステータス」プリミティブは、指定された関連付けに関する情報を含むデータブロックを返します。宛先トランスポートアドレスリスト;宛先トランスポートアドレスの到達可能性の状態。現在のローカルおよびピアレシーバーウィンドウのサイズ。現在のローカルの輻輳ウィンドウサイズ。未確認のDATAチャンクの数。受信保留中のDATAチャンクの数。プライマリパス;プライマリパス上の最新の平滑化ラウンドトリップ時間（SRTT）。プライマリパスのRTO。他の宛先アドレスのSRTTおよびRTO [RFC4960];パスごとのMTU [RFC6458]。
Enable/Disable Interleaving: This allows the negotiation of user message interleaving support for future associations to be enabled or disabled. For existing associations, it is possible to query whether user message interleaving support was negotiated or not on a particular association [RFC8260].
インターリーブの有効化/無効化：これにより、ユーザーメッセージインターリービングサポートのネゴシエーションを有効にしたり無効にしたりできるようになります。既存のアソシエーションの場合、特定のアソシエーションでユーザーメッセージインターリービングのサポートがネゴシエートされたかどうかを照会できます[RFC8260]。
Set Stream Scheduler: This allows the ability to select a stream scheduler per association, with a choice of: First-Come, First-Served; Round-Robin; Round-Robin per Packet; Priority-Based; Fair Bandwidth; and Weighted Fair Queuing [RFC8260].
ストリームスケジューラの設定：これにより、関連付けごとにストリームスケジューラを選択でき、次の選択肢があります。ラウンドロビン;パケットごとのラウンドロビン。優先度ベース;公平な帯域幅;および重み付けされたフェアキューイング[RFC8260]。
Configure Stream Scheduler: This allows the ability to change a parameter per stream for the schedulers: a priority value for the Priority-Based scheduler and a weight for the Weighted Fair Queuing scheduler.
ストリームスケジューラの構成：これにより、スケジューラーのストリームごとのパラメーターを変更できます。優先度ベースのスケジューラーの優先度の値と、均等化キュースケジューラーの重みです。
Enable/Disable NoDelay: This turns on/off any Nagle-like algorithm for an association [RFC6458].
NoDelayの有効化/無効化：これは、関連付けのNagleのようなアルゴリズムをオン/オフにします[RFC6458]。
Configure Send Buffer Size: This controls the amount of data SCTP may have waiting in internal buffers to be sent or retransmitted [RFC6458].
送信バッファサイズの構成：これは、SCTPが送信または再送信される内部バッファで待機しているデータの量を制御します[RFC6458]。
Configure Receive Buffer Size: This sets the receive buffer size in octets, thereby controlling the receiver window for an association [RFC6458].
受信バッファサイズの構成：これは受信バッファサイズをオクテットで設定し、それによって関連付けの受信ウィンドウを制御します[RFC6458]。
Configure Message Fragmentation: If a user message causes an SCTP packet to exceed the maximum fragmentation size (which can be provided by the application and is otherwise the Path MTU (PMTU) size), then the message will be fragmented by SCTP. Disabling message fragmentation will produce an error instead of fragmenting the message [RFC6458].
メッセージの断片化の構成：ユーザーメッセージによってSCTPパケットが最大の断片化サイズ（アプリケーションによって提供され、それ以外の場合はパスMTU（PMTU）サイズ）を超える場合、メッセージはSCTPによって断片化されます。メッセージの断片化を無効にすると、メッセージを断片化する代わりにエラーが生成されます[RFC6458]。
Configure Path MTU Discovery: Path MTU Discovery (PMTUD) can be enabled or disabled per peer address of an association (Section 8.1.12 of [RFC6458]). When it is enabled, the current Path MTU value can be obtained. When it is disabled, the Path MTU to be used can be controlled by the application.
パスMTU検出の構成：パスMTU検出（PMTUD）は、関連付けのピアアドレスごとに有効または無効にできます（[RFC6458]のセクション8.1.12）。有効にすると、現在のパスMTU値を取得できます。無効にすると、使用するパスMTUをアプリケーションで制御できます。
Configure Delayed SACK Timer: The time before sending a SACK can be adjusted; delaying SACKs can be disabled; and the number of packets that must be received before a SACK is sent without waiting for the delay timer to expire can be configured [RFC6458].
遅延SACKタイマーの構成：SACKを送信するまでの時間を調整できます。 SACKの遅延は無効にできます。また、遅延タイマーの期限が切れるのを待たずにSACKが送信される前に受信する必要があるパケットの数を構成できます[RFC6458]。
Set Cookie Life Value: The cookie life value can be adjusted (Section 8.1.2 of [RFC6458]). 'Valid.Cookie.Life' is also one of the parameters that is potentially adjustable with 'SetProtocolParameters' [RFC4960].
Cookieの有効期限の設定：Cookieの有効期限の値を調整できます（[RFC6458]のセクション8.1.2）。 'Valid.Cookie.Life'も 'SetProtocolParameters' [RFC4960]で調整できる可能性のあるパラメーターの1つです。
Set Maximum Burst: The maximum burst of packets that can be emitted by a particular association (default 4, and values above 4 are optional to implement) can be adjusted (Section 8.1.2 of [RFC6458]). 'Max.Burst' is also one of the parameters that is potentially adjustable with 'SetProtocolParameters' [RFC4960].
最大バーストの設定：特定のアソシエーション（デフォルト4、および4を超える値の実装はオプションです）が送信できるパケットの最大バーストを調整できます（[RFC6458]のセクション8.1.2）。 'Max.Burst'も、 'SetProtocolParameters' [RFC4960]で調整可能なパラメータの1つです。
Configure RTO Calculation: The abstract API contains the following adjustable parameters: 'RTO.Initial'; 'RTO.Min'; 'RTO.Max'; 'RTO.Alpha'; and 'RTO.Beta'. Only the initial, minimum and maximum RTOs are also described as configurable in the SCTP sockets API extensions [RFC6458].
RTO計算の構成：抽象APIには、次の調整可能なパラメーターが含まれています。 'RTO.Initial'; 'RTO.Min'; 'RTO.Max'; 'RTO.Alpha';および「RTO.Beta」。 SCTPソケットAPI拡張[RFC6458]では、初期RTO、最小RTO、最大RTOのみが構成可能であると説明されています。
Set DSCP Value: The DSCP value can be set per peer address of an association (Section 8.1.12 of [RFC6458]).
DSCP値の設定：DSCP値は、関連付けのピアアドレスごとに設定できます（[RFC6458]のセクション8.1.12）。
Set IPv6 Flow Label: The flow label field can be set per peer address of an association (Section 8.1.12 of [RFC6458]).
IPv6フローラベルの設定：フローラベルフィールドは、関連付けのピアアドレスごとに設定できます（[RFC6458]のセクション8.1.12）。
Set Partial Delivery Point: This allows the ability to specify the size of a message where partial delivery will be invoked. Setting this to a lower value will cause partial deliveries to happen more often [RFC6458].
部分配信ポイントの設定：これにより、部分配信が呼び出されるメッセージのサイズを指定できます。これを低い値に設定すると、部分配信がより頻繁に発生します[RFC6458]。
Communication Up Notification: When a lost communication to an endpoint is restored or when SCTP becomes ready to send or receive user messages, this notification informs the application process about the affected association, the type of event that has occurred, the complete set of sockets of the peer, the maximum number of allowed streams, and the inbound stream count (the number of streams the peer endpoint has requested). If interleaving is supported by both endpoints, this information is also included in this notification.
通信アップ通知：エンドポイントとの通信が失われた場合、またはSCTPがユーザーメッセージを送受信できるようになると、この通知は、影響を受ける関連付け、発生したイベントのタイプ、ソケットの完全なセットについてアプリケーションプロセスに通知しますピア、許可されたストリームの最大数、およびインバウンドストリームの数（ピアエンドポイントが要求したストリームの数）。インターリーブが両方のエンドポイントでサポートされている場合、この情報もこの通知に含まれます。
Restart Notification: When SCTP has detected that the peer has restarted, this notification is passed to the upper layer [RFC6458].
再起動通知：ピアが再起動したことをSCTPが検出すると、この通知は上位層[RFC6458]に渡されます。
Data Arrive Notification: When a message is ready to be retrieved via the 'Receive' primitive, the application is informed by this notification.
データ到着通知：「受信」プリミティブを介してメッセージを取得する準備ができると、アプリケーションにこの通知が通知されます。
Send Failure Notification / Receive Unsent Message / Receive Unacknowledged Message: When a message cannot be delivered via an association, the sender can be informed about it and learn whether the message has just not been acknowledged or (e.g., in case of lifetime expiry) if it has not even been sent. This can also inform the sender that a part of the message has been successfully delivered.
失敗通知の送信/未送信メッセージの受信/未確認メッセージの受信：アソシエーションを介してメッセージを配信できない場合、送信者はそのことを通知され、メッセージが確認されていないかどうか（たとえば、有効期限切れの場合）を確認できます。それも送られていません。これは、メッセージの一部が正常に配信されたことを送信者に通知することもできます。
Network Status Change Notification: This informs the application about a socket becoming active/inactive [RFC4960] or "Potentially Failed" [RFC7829].
ネットワークステータス変更通知：これは、ソケットがアクティブ/非アクティブになること[RFC4960]または「潜在的に失敗した」[RFC7829]についてアプリケーションに通知します。
Communication Lost Notification: When SCTP loses communication to an endpoint (e.g., via heartbeats or excessive retransmission) or detects an abort, this notification informs the application process of the affected association and the type of event (failure OR termination in response to a shutdown or abort request).
通信喪失通知：SCTPがエンドポイントとの通信を失う（たとえば、ハートビートまたは過剰な再送信を介して）か、異常終了を検出すると、この通知は、影響を受けるアソシエーションとイベントのタイプ（失敗またはシャットダウンへの応答での終了または終了）をアプリケーションプロセスに通知します中止リクエスト）。
Shutdown Complete Notification: When SCTP completes the shutdown procedures, this notification is passed to the upper layer, informing it about the affected association.
シャットダウン完了通知：SCTPがシャットダウン手順を完了すると、この通知は上位層に渡され、影響を受ける関連付けについて通知されます。
Authentication Notification: When SCTP wants to notify the upper layer regarding the key management related to authenticated chunks [RFC4895], this notification is passed to the upper layer.
認証通知：認証されたチャンクに関連するキー管理[RFC4895]に関してSCTPが上位層に通知する場合、この通知は上位層に渡されます。
Adaptation Layer Indication Notification: When SCTP completes the association setup and the peer provided an adaptation layer indication, this is passed to the upper layer [RFC5061] [RFC6458].
適応層表示通知：SCTPがアソシエーションセットアップを完了し、ピアが適応層表示を提供すると、これは上位層[RFC5061] [RFC6458]に渡されます。
Stream Reset Notification: When SCTP completes the procedure for resetting streams [RFC6525], this notification is passed to the upper layer, informing it about the result.
ストリームリセット通知：SCTPがストリームのリセット手順[RFC6525]を完了すると、この通知は上位層に渡され、結果が通知されます。
Association Reset Notification: When SCTP completes the association reset procedure [RFC6525], this notification is passed to the upper layer, informing it about the result.
アソシエーションリセット通知：SCTPがアソシエーションリセット手順[RFC6525]を完了すると、この通知は上位層に渡され、結果が通知されます。
Stream Change Notification: When SCTP completes the procedure used to increase the number of streams [RFC6525], this notification is passed to the upper layer, informing it about the result.
ストリーム変更通知：SCTPがストリーム数を増やすために使用される手順[RFC6525]を完了すると、この通知は上位層に渡され、結果が通知されます。
Sender Dry Notification: When SCTP has no more user data to send or retransmit on a particular association, this notification is passed to the upper layer [RFC6458].
送信者ドライ通知：特定のアソシエーションで送信または再送信するユーザーデータがSCTPになくなると、この通知は上位層[RFC6458]に渡されます。
Partial Delivery Aborted Notification: When a receiver has begun to receive parts of a user message but the delivery of this message is then aborted, this notification is passed to the upper layer (Section 6.1.7 of [RFC6458]).
部分配信中止通知：受信者がユーザーメッセージの一部の受信を開始したが、このメッセージの配信が中止された場合、この通知は上位層に渡されます（[RFC6458]のセクション6.1.7）。
The 'Receive' primitive can return certain additional information, but this is optional to implement and therefore not considered. With a 'Communication Lost' notification, some more information may optionally be passed to the application (e.g., identification to retrieve unsent and unacknowledged data). SCTP "can invoke" a 'Communication Error' notification and "may send" a 'Restart' notification, making these two notifications optional to implement. The list provided under 'Status' includes "etc.", indicating that more information could be provided. The primitive 'Get SRTT Report' returns information that is included in the information that 'Status' provides and is therefore not discussed. The 'Destroy SCTP Instance' API function was excluded: it erases the SCTP instance that was created by 'Initialize' but is not a primitive as defined in this document because it does not relate to a transport feature. The 'Shutdown' event informs an application that the peer has sent a SHUTDOWN, and hence no further data should be sent on this socket (Section 6.1 of [RFC6458]). However, if an application would try to send data on the socket, it would get an error message anyway; thus, this event is classified as "just affecting the application programming style, not how the underlying protocol operates" and is not included here.
'Receive'プリミティブは特定の追加情報を返すことができますが、これは実装のオプションであるため、考慮されません。 「通信が失われた」通知では、さらにいくつかの情報をオプションでアプリケーションに渡すことができます（たとえば、未送信および未確認のデータを取得するための識別）。 SCTPは「通信エラー」通知を「呼び出す」ことができ、「再起動」通知を「送信する」ことができるため、これら2つの通知の実装はオプションになります。 「ステータス」の下に表示されるリストには「その他」が含まれ、より多くの情報を提供できることを示しています。プリミティブ「Get SRTT Report」は、「Status」が提供する情報に含まれているため、説明されていない情報を返します。 「SCTPインスタンスの破棄」API関数は除外されました。「初期化」によって作成されたSCTPインスタンスは消去されますが、トランスポート機能に関連しないため、このドキュメントで定義されているプリミティブではありません。 「Shutdown」イベントは、ピアがSHUTDOWNを送信したことをアプリケーションに通知するため、このソケットでこれ以上データを送信しないでください（[RFC6458]のセクション6.1）。ただし、アプリケーションがソケットでデータを送信しようとすると、とにかくエラーメッセージが表示されます。したがって、このイベントは「基礎となるプロトコルの動作方法ではなく、アプリケーションプログラミングスタイルにのみ影響する」と分類され、ここには含まれません。
The set of pass 1 primitives for UDP and UDP-Lite is documented in [RFC8304].
UDPおよびUDP-Liteのパス1プリミティブのセットは、[RFC8304]で文書化されています。
The service of the LEDBAT congestion control mechanism is described as follows:
LEDBAT輻輳制御メカニズムのサービスは次のとおりです。
LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows [RFC6817].
LEDBATは、バックグラウンドのバルク転送アプリケーションが標準のTCP輻輳制御（RFC 5681で指定されている）よりも積極的でなく、競合するフローが存在する場合に制御できるように設計されているため、競合するフローのネットワークパフォーマンスへの干渉が制限されます[RFC6817 ]。
LEDBAT does not have any primitives, as LEDBAT is not a transport protocol. According to its specification [RFC6817]:
LEDBATはトランスポートプロトコルではないため、LEDBATにはプリミティブがありません。その仕様によれば[RFC6817]：
LEDBAT can be used as part of a transport protocol or as part of an application, as long as the data transmission mechanisms are capable of carrying timestamps and acknowledging data frequently. LEDBAT can be used with TCP, Stream Control Transmission Protocol (SCTP), and Datagram Congestion Control Protocol (DCCP), with appropriate extensions where necessary; and it can be used with proprietary application protocols, such as those built on top of UDP for peer-to-peer (P2P) applications.
LEDBATは、データ転送メカニズムがタイムスタンプを伝送し、データを頻繁に確認できる限り、トランスポートプロトコルの一部として、またはアプリケーションの一部として使用できます。 LEDBATは、TCP、ストリーム制御伝送プロトコル（SCTP）、およびデータグラム輻輳制御プロトコル（DCCP）で使用でき、必要に応じて適切な拡張を行います。また、ピアツーピア（P2P）アプリケーションのUDPの上に構築されたプロトコルなど、独自のアプリケーションプロトコルで使用できます。
At the time of writing, the appropriate extensions for TCP, SCTP, or DCCP do not exist.
執筆時点では、TCP、SCTP、またはDCCPの適切な拡張機能は存在しません。
A number of configurable parameters exist in the LEDBAT specification: TARGET, which is the queuing delay target at which LEDBAT tries to operate, must be set to 100 ms or less. 'allowed_increase' (should be 1, must be greater than 0) limits the speed at which LEDBAT increases its rate. 'gain', which according to [RFC6817] "MUST be set to 1 or less" to avoid a faster ramp-up than TCP Reno, determines how quickly the sender responds to changes in queueing delay. Implementations may divide 'gain' into two parameters: one for increase and a possibly larger one for decrease. We call these parameters 'Gain_Inc' and 'Gain_Dec' here. 'Base_History' is the size of the list of measured base delays, and, according to [RFC6817], "SHOULD be 10". This list can be filtered using a 'Filter' function, which is not prescribed [RFC6817], that yields a list of size 'Current_Filter'. The initial and minimum congestion windows, 'Init_CWND' and 'Min_CWND', should both be 2.
LEDBAT仕様にはいくつかの構成可能なパラメーターが存在します。LEDBATが動作しようとするキューイング遅延ターゲットであるTARGETは、100 ms以下に設定する必要があります。 「allowed_increase」（1である必要があります。0より大きい必要があります）は、LEDBATがレートを増加させる速度を制限します。 [ゲイン]は、[RFC6817]に従って「1以下に設定する必要がある」ことで、TCP Renoよりも高速のランプアップを回避し、送信者がキューイング遅延の変化に応答する速さを決定します。実装では、「ゲイン」を2つのパラメータに分割する場合があります。1つは増加用、もう1つはおそらく減少用です。ここでは、これらのパラメーターを「Gain_Inc」および「Gain_Dec」と呼びます。 「Base_History」は、測定された基本遅延のリストのサイズであり、[RFC6817]によれば、「SHOULD be 10」です。このリストは、サイズが「Current_Filter」のリストを生成する「RFC6817」で規定されていない「Filter」関数を使用してフィルタリングできます。初期および最小の輻輳ウィンドウである「Init_CWND」と「Min_CWND」は両方とも2である必要があります。
Regarding which of these parameters should be under control of an application, the possible range goes from exposing nothing on the one hand to considering everything that is not prescribed with a "MUST" in the specification as a parameter on the other hand. Function implementations are not provided as a parameter to any of the transport protocols discussed here; hence, we do not regard the
これらのパラメーターのどれがアプリケーションの制御下にあるべきかに関して、可能な範囲は、一方では何も公開しないことから、他方ではパラメーターとして仕様で「MUST」で規定されていないすべてを考慮することになります。関数の実装は、ここで説明するトランスポートプロトコルのパラメーターとして提供されていません。したがって、私たちは考慮しません
'Filter' function as a parameter. However, to avoid unnecessarily limiting future implementations, we consider all other parameters above as tunable parameters that should be exposed.
パラメータとしての「フィルタ」機能。ただし、将来の実装を不必要に制限することを避けるために、上記の他のすべてのパラメーターを公開する必要のある調整可能なパラメーターと見なします。
This pass categorizes the primitives from pass 1 based on whether they relate to a connection or to data transmission. Primitives are presented following the nomenclature "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL". The CATEGORY can be CONNECTION or DATA. Within the CONNECTION category, ESTABLISHMENT, AVAILABILITY, MAINTENANCE, and TERMINATION subcategories can be considered. The DATA category does not have any SUBCATEGORY. The PROTOCOL name "UDP(-Lite)" is used when primitives are equivalent for UDP and UDP-Lite; the PROTOCOL name "TCP" refers to both TCP and MPTCP. We present "connection" as a general protocol-independent concept and use it to refer to, e.g., TCP connections (identifiable by a unique pair of IP addresses and TCP port numbers), SCTP associations (identifiable by multiple IP address and port number pairs), as well UDP and UDP-Lite connections (identifiable by a unique socket pair).
このパスは、接続に関連するかデータ送信に関連するかに基づいて、パス1のプリミティブを分類します。プリミティブは、「CATEGORY。[SUBCATEGORY] .PRIMITIVENAME.PROTOCOL」という命名法に従って表示されます。 CATEGORYはCONNECTIONまたはDATAです。 CONNECTIONカテゴリでは、ESTABLISHMENT、AVAILABILITY、MAINTENANCE、およびTERMINATIONサブカテゴリを検討できます。 DATAカテゴリにはSUBCATEGORYがありません。プロトコル名「UDP（-Lite）」は、プリミティブがUDPとUDP-Liteで同等である場合に使用されます。プロトコル名「TCP」は、TCPとMPTCPの両方を指します。プロトコルに依存しない一般的な概念として「接続」を提示し、それを使用して、たとえば、TCP接続（IPアドレスとTCPポート番号の一意のペアによって識別可能）、SCTPアソシエーション（複数のIPアドレスとポート番号のペアによって識別可能） ）、UDPおよびUDP-Lite接続（一意のソケットペアで識別可能）。
Some minor details are omitted for the sake of generalization -- e.g., SCTP's 'Close' [RFC4960] returns success or failure and lets the application control whether further receive or send operations, or both, are disabled [RFC6458]. This is not described in the same way for TCP [RFC0793], but these details play no significant role for the primitives provided by either TCP or SCTP (for the sake of being generic, it could be assumed that both receive and send operations are disabled in both cases).
一般化のために、いくつかの細かい詳細は省略されています。たとえば、SCTPの「Close」[RFC4960]は成功または失敗を返し、アプリケーションは、以降の受信または送信操作、あるいはその両方が無効かどうかを制御できます[RFC6458]。これはTCP [RFC0793]について同じ方法で説明されていませんが、これらの詳細はTCPまたはSCTPのいずれかによって提供されるプリミティブには重要な役割を果たしません（一般的に、受信と送信の両方の操作が無効になっていると想定できます）両方の場合において）。
The TCP 'Send' and 'Receive' primitives include usage of an 'urgent' parameter. This parameter controls a mechanism that is required to implement the "synch signal" used by telnet [RFC0854], but [RFC6093] states that "new applications SHOULD NOT employ the TCP urgent mechanism." Because pass 2 is meant as a basis for the creation of future systems, the "urgent" mechanism is excluded. This also concerns the notification 'Urgent Pointer Advance' in the 'Error_Report' (Section 4.2.4.1 of [RFC1122]).
TCPの「送信」および「受信」プリミティブには、「緊急」パラメーターの使用が含まれます。このパラメータは、Telnet [RFC0854]が使用する「同期信号」を実装するために必要なメカニズムを制御しますが、[RFC6093]は、「新しいアプリケーションはTCP緊急メカニズムを採用してはならない」と述べています。パス2は将来のシステムを作成するための基礎として意図されているため、「緊急」メカニズムは除外されます。これは、「Error_Report」の[Urgent Pointer Advance]通知にも関係します（[RFC1122]のセクション4.2.4.1）。
Since LEDBAT is a congestion control mechanism and not a protocol, it is not currently defined when to enable/disable or configure the mechanism. For instance, it could be a one-time choice upon connection establishment or when listening for incoming connections, in which case it should be categorized under CONNECTION.ESTABLISHMENT or CONNECTION.AVAILABILITY, respectively. To avoid unnecessarily limiting future implementations, it was decided to place it under CONNECTION.MAINTENANCE, with all parameters that are described in the specification [RFC6817] made configurable.
LEDBATはプロトコルではなく輻輳制御メカニズムであるため、現在メカニズムを有効化/無効化または構成するタイミングは定義されていません。たとえば、接続の確立時または着信接続のリッスン時に一度だけ選択できます。その場合、それぞれCONNECTION.ESTABLISHMENTまたはCONNECTION.AVAILABILITYに分類する必要があります。将来の実装を不必要に制限することを避けるために、仕様[RFC6817]で説明されているすべてのパラメーターを構成可能にして、CONNECTION.MAINTENANCEの下に配置することが決定されました。
ESTABLISHMENT:
確立：
Active creation of a connection from one transport endpoint to one or more transport endpoints. Interfaces to UDP and UDP-Lite allow both connection-oriented and connection-less usage of the API [RFC8085].
1つのトランスポートエンドポイントから1つ以上のトランスポートエンドポイントへの接続のアクティブな作成。 UDPおよびUDP-Liteへのインターフェースは、APIのコネクション型およびコネクションレスの両方の使用を可能にします[RFC8085]。
o CONNECT.TCP:
o CONNECT.TCP：
Pass 1 primitive/event: 'Open' (active) or 'Open' (passive) with socket, followed by 'Send'
1つのプリミティブ/イベントを渡す：ソケットで「開く」（アクティブ）または「開く」（パッシブ）、その後に「送信」
Parameters: 1 local IP address (optional); 1 destination transport
address (for active open; else the socket and the local IP address
of the succeeding incoming connection request will be maintained);
timeout (optional); options (optional); MKT configuration
(optional); and user message (optional)
Comments: if the local IP address is not provided, a default choice will automatically be made. The timeout can also be a retransmission count. The options are IP options to be used on all segments of the connection. At least the Source Route option is mandatory for TCP to provide. 'MKT configuration' refers to the ability to configure MKTs for authentication. The user message may be transmitted to the peer application immediately upon reception of the TCP SYN packet. To benefit from the lower latency this provides as part of the experimental TFO mechanism, its length must be at most the TCP's maximum segment size (minus TCP options used in the SYN). The message may also be delivered more than once to the application on the remote host.
コメント：ローカルIPアドレスが指定されていない場合、デフォルトの選択が自動的に行われます。タイムアウトは、再送信回数の場合もあります。オプションは、接続のすべてのセグメントで使用されるIPオプションです。 TCPを提供するには、少なくともソースルートオプションが必須です。 「MKT構成」とは、認証用にMKTを構成する機能を指します。ユーザーメッセージは、TCP SYNパケットを受信するとすぐにピアアプリケーションに送信されます。これが実験的なTFOメカニズムの一部として提供する低レイテンシの恩恵を受けるには、その長さは最大でTCPの最大セグメントサイズでなければなりません（SYNで使用されるTCPオプションを差し引いたもの）。メッセージは、リモートホスト上のアプリケーションに複数回配信される場合もあります。
o CONNECT.SCTP:
o CONNECT.SCTP：
Pass 1 primitive/event: 'Initialize', followed by 'Enable/Disable Interleaving' (optional), followed by 'Associate'
1つのプリミティブ/イベントを渡す：「初期化」、「インターリーブの有効化/無効化」（オプション）、「関連付け」
Parameters: list of local SCTP port number / IP address pairs
('Initialize'); one or several sockets (identifying the peer);
outbound stream count; maximum allowed inbound stream count;
adaptation layer indication (optional); chunk types required to be
authenticated (optional); request interleaving on/off; maximum
number of INIT attempts (optional); maximum init. RTO for INIT
(optional); user message (optional); and remote UDP port number
(optional)
Returns: socket list or failure
戻り値：ソケットリストまたは失敗
Comments: 'Initialize' needs to be called only once per list of local SCTP port number / IP address pairs. One socket will automatically be chosen; it can later be changed in MAINTENANCE. The user message may be transmitted to the peer application immediately upon reception of the packet containing the COOKIE-ECHO chunk. To benefit from the lower latency this provides, its length must be limited such that it fits into the packet containing the COOKIE-ECHO chunk. If a remote UDP port number is provided, SCTP packets will be encapsulated in UDP.
コメント：「初期化」は、ローカルSCTPポート番号/ IPアドレスのペアのリストごとに1回だけ呼び出す必要があります。 1つのソケットが自動的に選択されます。後でメンテナンスで変更できます。 COOKIE-ECHOチャンクを含むパケットを受信するとすぐに、ユーザーメッセージをピアアプリケーションに送信できます。これが提供するより低いレイテンシの恩恵を受けるには、COOKIE-ECHOチャンクを含むパケットに収まるように長さを制限する必要があります。リモートUDPポート番号が指定されている場合、SCTPパケットはUDPでカプセル化されます。
o CONNECT.MPTCP:
o CONNECT.MPTCP：
This is similar to CONNECT.TCP except for one additional boolean parameter that allows the ability to enable or disable MPTCP for a particular connection or socket (default: enabled).
これはCONNECT.TCPに似ていますが、特定の接続またはソケットに対してMPTCPを有効または無効にする機能を1つ追加するブールパラメータがあります（デフォルト：有効）。
o CONNECT.UDP(-Lite):
o CONNECT.UDP（-Lite）：
Pass 1 primitive/event: 'Connect' followed by 'Send'
1つのプリミティブ/イベントを渡す：「接続」の後に「送信」
Parameters: 1 local IP address (default (ANY) or specified); 1 destination transport address; 1 local port (default (OS chooses) or specified); and 1 destination port (default (OS chooses) or specified).
パラメータ：1つのローカルIPアドレス（デフォルト（任意）または指定）。 1つの宛先トランスポートアドレス。 1つのローカルポート（デフォルト（OSが選択）または指定）。および1つの宛先ポート（デフォルト（OSが選択）または指定）。
Comments: associates a transport address creating a UDP(-Lite) socket connection. This can be called again with a new transport address to create a new connection. The CONNECT function allows an application to receive errors from messages sent to a transport address.
コメント：UDP（-Lite）ソケット接続を作成するトランスポートアドレスを関連付けます。これは、新しい接続を作成するために、新しいトランスポートアドレスで再度呼び出すことができます。 CONNECT関数を使用すると、アプリケーションはトランスポートアドレスに送信されたメッセージからエラーを受信できます。
AVAILABILITY:
可用性：
Preparing to receive incoming connection requests.
着信接続要求を受信する準備をしています。
o LISTEN.TCP:
o LISTEN.TCP：
Pass 1 primitive/event: 'Open' (passive)
1つのプリミティブ/イベントを渡す：「オープン」（パッシブ）
Parameters: 1 local IP address (optional); 1 socket (optional);
timeout (optional); buffer to receive a user message (optional);
and MKT configuration (optional)
Comments: if the socket and/or local IP address is provided, this
waits for incoming connections from only and/or to only the
provided address. Else this waits for incoming connections
without this/these constraint(s). ESTABLISHMENT can later be
performed with 'Send'. If a buffer is provided to receive a user
message, a user message can be received from a TFO-enabled sender
before the TCP's connection handshake is completed. This message
may arrive multiple times. 'MKT configuration' refers to the
ability to configure MKTs for authentication.
o LISTEN.SCTP:
o LISTEN.SCTP：
Pass 1 primitive/event: 'Initialize', followed by the 'Communication Up' or 'Restart' notification and possibly the 'Adaptation Layer' notification
1つのプリミティブ/イベントを渡す：「初期化」、続いて「通信アップ」または「再起動」通知、そして場合によっては「適応層」通知
Parameters: list of local SCTP port number / IP address pairs (initialize)
パラメータ：ローカルSCTPポート番号/ IPアドレスのペアのリスト（初期化）
Returns: socket list; outbound stream count; inbound stream count;
adaptation layer indication; chunks required to be authenticated;
and interleaving supported on both sides yes/no
Comments: 'Initialize' needs to be called only once per list of local SCTP port number / IP address pairs. 'Communication Up' can also follow a 'Communication Lost' notification, indicating that the lost communication is restored. If the peer has provided an adaptation layer indication, an 'Adaptation Layer' notification is issued.
コメント：「初期化」は、ローカルSCTPポート番号/ IPアドレスのペアのリストごとに1回だけ呼び出す必要があります。 「Communication Up」は「Communication Lost」通知に続いて、失われた通信が復元されたことを示すことができます。ピアがアダプテーションレイヤーの表示を提供している場合、「アダプテーションレイヤー」通知が発行されます。
o LISTEN.MPTCP:
o LISTEN.MPTCP：
This is similar to LISTEN.TCP except for one additional boolean parameter that allows the ability to enable or disable MPTCP for a particular connection or socket (default: enabled).
これはLISTEN.TCPに似ていますが、特定の接続またはソケット（デフォルト：有効）に対してMPTCPを有効または無効にする機能を1つ追加するブールパラメータがあります。
o LISTEN.UDP(-Lite):
o LISTEN.UDP（-Lite）：
Pass 1 primitive/event: 'Receive'
1つのプリミティブ/イベントを渡す：「受信」
Parameters: 1 local IP address (default (ANY) or specified); 1 destination transport address; local port (default (OS chooses) or specified); and destination port (default (OS chooses) or specified)
パラメータ：1つのローカルIPアドレス（デフォルト（任意）または指定）。 1つの宛先トランスポートアドレス。ローカルポート（デフォルト（OSが選択）または指定）;および宛先ポート（デフォルト（OSが選択）または指定）
Comments: the 'Receive' function registers the application to listen for incoming UDP(-Lite) datagrams at an endpoint.
コメント：「受信」機能は、エンドポイントで着信UDP（-Lite）データグラムをリッスンするようにアプリケーションを登録します。
MAINTENANCE:
メンテナンス：
Adjustments made to an open connection, or notifications about it. These are out-of-band messages to the protocol that can be issued at any time, at least after a connection has been established and before it has been terminated (with one exception: CHANGE_TIMEOUT.TCP can only be issued for an open connection when DATA.SEND.TCP is called). In some cases, these primitives can also be immediately issued during ESTABLISHMENT or AVAILABILITY, without waiting for the connection to be opened (e.g., CHANGE_TIMEOUT.TCP can be done using TCP's 'Open' primitive). For UDP and UDP-Lite, these functions may establish a setting per connection but may also be changed per datagram message.
開いている接続に加えられた調整、またはそれに関する通知。これらは、プロトコルへのアウトオブバンドメッセージであり、少なくとも接続が確立されてから終了するまでの間にいつでも発行できます（1つの例外：CHANGE_TIMEOUT.TCPは、開いている接続に対してのみ発行できます。 DATA.SEND.TCPが呼び出されます）。場合によっては、接続が開かれるのを待たずに、ESTABLISHMENTまたはAVAILABILITY中にこれらのプリミティブをすぐに発行することもできます（たとえば、TCPの「Open」プリミティブを使用してCHANGE_TIMEOUT.TCPを実行できます）。 UDPおよびUDP-Liteの場合、これらの関数は接続ごとに設定を確立できますが、データグラムメッセージごとに変更することもできます。
o CHANGE_TIMEOUT.TCP:
o CHANGE_TIMEOUT.TCP：
Pass 1 primitive/event: 'Open' or 'Send' combined with unspecified control of per-connection state variables
1つのプリミティブ/イベントを渡す：接続ごとの状態変数の未指定の制御と組み合わせた「開く」または「送信」
Parameters: timeout value (optional); adv_uto (optional); boolean
uto_enabled (optional, default false); and boolean changeable
(optional, default true)
Comments: when sending data, an application can adjust the connection's timeout value (the time after which the connection will be aborted if data could not be delivered). If 'uto_enabled' is true, the 'timeout value' (or, if provided, the value 'adv_uto') will be advertised for the TCP on the other side of the connection to adapt its own user timeout accordingly. 'uto_enabled' controls whether the UTO option is enabled for a connection. This applies to both sending and receiving. 'changeable' controls whether the user timeout may be changed based on a UTO option received from the other end of the connection; it becomes false when the 'timeout value' is used.
コメント：データを送信するとき、アプリケーションは接続のタイムアウト値（データを配信できなかった場合に接続が中止されるまでの時間）を調整できます。 'uto_enabled'がtrueの場合、 'timeout value'（または、指定されている場合は、 'adv_uto'の値）が接続の反対側のTCPに通知され、それに応じて独自のユーザータイムアウトが調整されます。 'uto_enabled'は、接続に対してUTOオプションを有効にするかどうかを制御します。これは送信と受信の両方に適用されます。 「変更可能」は、接続の反対側から受信したUTOオプションに基づいてユーザータイムアウトを変更できるかどうかを制御します。 「タイムアウト値」を使用するとfalseになります。
o CHANGE_TIMEOUT.SCTP:
o CHANGE_TIMEOUT.SCTP：
Pass 1 primitive/event: 'Change Heartbeat' combined with 'Configure Max. Retransmissions of an Association'
1つのプリミティブ/イベントを渡す：「最大の構成」と組み合わせた「ハートビートの変更」協会の再送」
Parameters: 'Change Heartbeat': heartbeat frequency and 'Configure Max. Retransmissions of an Association': Association.Max.Retrans
パラメータ：「ハートビートの変更」：ハートビートの頻度と「最大の構成」。アソシエーションの再送信 '：Association.Max.Retrans
Comments: 'Change Heartbeat' can enable/disable heartbeats in SCTP as well as change their frequency. The parameter 'Association.Max.Retrans' defines after how many unsuccessful transmissions of any packets (including heartbeats) the association will be terminated; thus, these two primitives/ parameters together can yield a similar behavior for SCTP associations as CHANGE_TIMEOUT.TCP does for TCP connections.
コメント：「ハートビートの変更」は、SCTPでハートビートを有効/無効にしたり、その頻度を変更したりできます。パラメータ 'Association.Max.Retrans'は、パケット（ハートビートを含む）の送信に失敗した後、関連付けを終了する回数を定義します。したがって、これらの2つのプリミティブ/パラメーターを一緒に使用すると、SCTPアソシエーションに対して、CHANGE_TIMEOUT.TCPがTCP接続に対して行うのと同じような動作が得られます。
o DISABLE_NAGLE.TCP:
o DISABLE_NAGLE.TCP：
Pass 1 primitive/event: not specified
1つのプリミティブ/イベントを渡す：指定されていません
Parameters: one boolean value
パラメータ：1つのブール値
Comments: the Nagle algorithm delays data transmission to increase the chance of sending a full-sized segment. An application must be able to disable this algorithm for a connection.
コメント：Nagleアルゴリズムはデータ送信を遅らせて、フルサイズのセグメントを送信する可能性を高めます。アプリケーションは、接続に対してこのアルゴリズムを無効にできる必要があります。
o DISABLE_NAGLE.SCTP:
o DISABLE_NAGLE.SCTP：
Pass 1 primitive/event: 'Enable/Disable NoDelay'
Parameters: one boolean value
パラメータ：1つのブール値
Comments: Nagle-like algorithms delay data transmission to increase the chance of sending a full-sized packet.
コメント：Nagleのようなアルゴリズムは、フルサイズのパケットを送信する可能性を高めるためにデータ送信を遅らせます。
o REQUEST_HEARTBEAT.SCTP:
o REQUEST_HEARTBEAT.SCTP：
Pass 1 primitive/event: 'Request Heartbeat'
1つのプリミティブ/イベントを渡す： 'Request Heartbeat'
Parameters: socket
パラメータ：ソケット
Returns: success or failure
戻り値：成功または失敗
Comments: requests an immediate heartbeat on a path, returning success or failure.
コメント：パスの即時ハートビートを要求し、成功または失敗を返します。
o ADD_PATH.MPTCP:
o ADD_PATH.MPTCP：
Pass 1 primitive/event: not specified
1つのプリミティブ/イベントを渡す：指定されていません
Parameters: local IP address and optionally the local port number
パラメータ：ローカルIPアドレスおよびオプションでローカルポート番号
Comments: the application specifies the local IP address and port number that must be used for a new subflow.
コメント：アプリケーションは、新しいサブフローに使用する必要があるローカルIPアドレスとポート番号を指定します。
o ADD_PATH.SCTP:
o ADD_PATH.SCTP：
Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
Parameters: local IP address
パラメータ：ローカルIPアドレス
o REM_PATH.MPTCP:
o REM_PATH.MPTCP：
Pass 1 primitive/event: not specified
1つのプリミティブ/イベントを渡す：指定されていません
Parameters: local IP address; local port number; remote IP
address; and remote port number
Comments: the application removes the subflow specified by the IP/ port-pair. The MPTCP implementation must trigger a removal of the subflow that belongs to this IP/port-pair.
コメント：アプリケーションは、IP /ポートペアで指定されたサブフローを削除します。 MPTCP実装は、このIP /ポートペアに属するサブフローの削除をトリガーする必要があります。
o REM_PATH.SCTP:
o REM_PATH.SCTP：
Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
Parameters: local IP address
パラメータ：ローカルIPアドレス
o SET_PRIMARY.SCTP:
o SET_PRIMARY.SCTP：
Pass 1 primitive/event: 'Set Primary'
1つのプリミティブ/イベントを渡す：「プライマリーに設定」
Parameters: socket
パラメータ：ソケット
Returns: result of attempting this operation
戻り値：この操作を試みた結果
Comments: update the current primary address to be used, based on the set of available sockets of the association.
コメント：関連付けの利用可能なソケットのセットに基づいて、使用される現在のプライマリアドレスを更新します。
o SET_PEER_PRIMARY.SCTP:
o SET_PEER_PRIMARY.SCTP：
Pass 1 primitive/event: 'Change Local Address / Set Peer Primary'
Parameters: local IP address
パラメータ：ローカルIPアドレス
Comments: this is only advisory for the peer.
コメント：これは同業他社にのみ助言するものです。
o CONFIG_SWITCHOVER.SCTP:
o CONFIG_SWITCHOVER.SCTP：
Pass 1 primitive/event: 'Configure Path Switchover'
1つのプリミティブ/イベントを渡す：「パススイッチオーバーの構成」
Parameters: primary max retrans (number of retransmissions after which a path is considered inactive) and PF max retrans (number of retransmissions after which a path is considered to be "Potentially Failed", and others will be preferably used) (optional)
パラメータ：プライマリ最大再送（パスが非アクティブであると見なされるまでの再送信の数）およびPF最大再送（パスが「潜在的に失敗した」と見なされるまでの再送信の数。他のパスが優先的に使用される）（オプション）
o STATUS.SCTP:
o STATUS.SCTP：
Pass 1 primitive/event: 'Status', 'Enable/Disable Interleaving', and 'Network Status Change' notification
1つのプリミティブ/イベントを渡す：「ステータス」、「インターリーブの有効化/無効化」、および「ネットワークステータスの変更」通知
Returns: data block with information about a specified
association, containing: association connection state; destination
transport address list; destination transport address reachability
states; current local and peer receiver window sizes; current
local congestion window sizes; number of unacknowledged DATA
chunks; number of DATA chunks pending receipt; primary path; most
recent SRTT on primary path; RTO on primary path; SRTT and RTO on
other destination addresses; MTU per path; and interleaving
supported yes/no
Comments: the 'Network Status Change' notification informs the application about a socket becoming active/inactive; this only affects the programming style, as the same information is also available via 'Status'.
コメント：「ネットワークステータスの変更」通知は、ソケットがアクティブ/非アクティブになることをアプリケーションに通知します。これはプログラミングスタイルにのみ影響します。「ステータス」からも同じ情報を入手できます。
o STATUS.MPTCP:
o STATUS.MPTCP：
Pass 1 primitive/event: not specified
1つのプリミティブ/イベントを渡す：指定されていません
Returns: list of pairs of tuples of IP address and TCP port number of each subflow. The first of the pair is the local IP and port number, while the second is the remote IP and port number.
戻り値：各サブフローのIPアドレスとTCPポート番号のタプルのペアのリスト。ペアの1つ目はローカルIPとポート番号、2つ目はリモートIPとポート番号です。
o SET_DSCP.TCP:
o SET_DSCP.TCP：
Pass 1 primitive/event: not specified
1つのプリミティブ/イベントを渡す：指定されていません
Parameters: DSCP value
パラメータ：DSCP値
Comments: this allows an application to change the DSCP value for outgoing segments.
コメント：これにより、アプリケーションは発信セグメントのDSCP値を変更できます。
o SET_DSCP.SCTP:
o SET_DSCP.SCTP：
Pass 1 primitive/event: 'Set DSCP value'
1つのプリミティブ/イベントを渡す：「DSCP値を設定する」
Parameters: DSCP value
パラメータ：DSCP値
Comments: this allows an application to change the DSCP value for outgoing packets on a path.
コメント：これにより、アプリケーションはパス上の発信パケットのDSCP値を変更できます。
o SET_DSCP.UDP(-Lite):
o SET_DSCP.UDP（-Lite）：
Pass 1 primitive/event: 'Set_DSCP'
1つのプリミティブ/イベントを渡す： 'Set_DSCP'
Parameter: DSCP value
パラメータ：DSCP値
Comments: this allows an application to change the DSCP value for outgoing UDP(-Lite) datagrams. [RFC7657] and [RFC8085] provide current guidance on using this value with UDP.
コメント：これにより、アプリケーションは発信UDP（-Lite）データグラムのDSCP値を変更できます。 [RFC7657]と[RFC8085]は、UDPでこの値を使用する際の最新のガイダンスを提供しています。
o ERROR.TCP:
o ERROR.TCP：
Pass 1 primitive/event: 'Error_Report'
1つのプリミティブ/イベントを渡す： 'Error_Report'
Returns: reason (encoding not specified) and subreason (encoding not specified)
戻り値：理由（エンコーディングが指定されていない）およびサブ理由（エンコーディングが指定されていない）
Comments: soft errors that can be ignored without harm by many applications; an application should be able to disable these notifications. The reported conditions include at least: ICMP error message arrived and excessive retransmissions.
コメント：多くのアプリケーションに害を与えることなく無視できるソフトエラー。アプリケーションはこれらの通知を無効にできる必要があります。報告される条件には、少なくとも次のものが含まれます。ICMPエラーメッセージが到着し、過剰な再送信が行われます。
o ERROR.UDP(-Lite):
o ERROR.UDP（-Lite）：
Pass 1 primitive/event: 'Error_Report'
1つのプリミティブ/イベントを渡す： 'Error_Report'
Returns: Error report
戻り値：エラーレポート
Comments: this returns soft errors that may be ignored without harm by many applications; an application must connect to be able receive these notifications.
コメント：これは、多くのアプリケーションに害を与えることなく無視できるソフトエラーを返します。アプリケーションは、これらの通知を受信できるように接続する必要があります。
o SET_AUTH.TCP:
o SET_AUTH.TCP：
Pass 1 primitive/event: not specified
1つのプリミティブ/イベントを渡す：指定されていません
Parameters: current_key and rnext_key
パラメータ：current_keyおよびrnext_key
Comments: current_key and rnext_key are the preferred outgoing MKT and the preferred incoming MKT, respectively, for a segment that is sent on the connection.
コメント：current_keyとrnext_keyは、それぞれ接続で送信されるセグメントの優先発信MKTと優先着信MKTです。
o SET_AUTH.SCTP:
o SET_AUTH.SCTP：
Pass 1 primitive/event: 'Set/Get Authentication Parameters'
Parameters: key_id; key; and hmac_id
o GET_AUTH.TCP:
o GET_AUTH.TCP：
Pass 1 primitive/event: not specified
1つのプリミティブ/イベントを渡す：指定されていません
Parameters: current_key and rnext_key
パラメータ：current_keyおよびrnext_key
Comments: current_key and rnext_key are the preferred outgoing MKT and the preferred incoming MKT, respectively, that were carried on a recently received segment.
コメント：current_keyとrnext_keyは、それぞれ、最近受信したセグメントで伝送された、優先する発信MKTと優先する着信MKTです。
o GET_AUTH.SCTP:
o GET_AUTH.SCTP：
Pass 1 primitive/event: 'Set/Get Authentication Parameters'
Parameters: key_id and chunk_list
パラメータ：key_idおよびchunk_list
o RESET_STREAM.SCTP:
o RESET_STREAM.SCTP：
Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
Parameters: sid and direction
パラメータ：sidおよびdirection
o RESET_STREAM-EVENT.SCTP:
o RESET_STREAM-EVENT.SCTP：
Pass 1 primitive/event: 'Stream Reset' notification
1つのプリミティブ/イベントを渡す：「ストリームリセット」通知
Parameters: information about the result of RESET_STREAM.SCTP
パラメータ：RESET_STREAM.SCTPの結果に関する情報
Comments: this is issued when the procedure for resetting streams has completed.
コメント：ストリームをリセットする手順が完了したときに発行されます。
o RESET_ASSOC.SCTP:
o RESET_ASSOC.SCTP：
Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
Parameters: information related to the extension, as defined in [RFC3260]
パラメータ：[RFC3260]で定義されている、拡張に関連する情報
o RESET_ASSOC-EVENT.SCTP:
o RESET_ASSOC-EVENT.SCTP：
Pass 1 primitive/event: 'Association Reset' notification
1つのプリミティブ/イベントを渡す：「関連付けのリセット」通知
Parameters: information about the result of RESET_ASSOC.SCTP
パラメータ：RESET_ASSOC.SCTPの結果に関する情報
Comments: this is issued when the procedure for resetting an association has completed.
コメント：これは、関連付けをリセットする手順が完了したときに発行されます。
o ADD_STREAM.SCTP:
o ADD_STREAM.SCTP：
Pass 1 primitive/event: 'Add/Reset Streams, Reset Association'
Parameters: number of outgoing and incoming streams to be added
パラメータ：追加する送信ストリームと受信ストリームの数
o ADD_STREAM-EVENT.SCTP:
o ADD_STREAM-EVENT.SCTP：
Pass 1 primitive/event: 'Stream Change' notification
1つのプリミティブ/イベントを渡す：「ストリーム変更」通知
Parameters: information about the result of ADD_STREAM.SCTP
パラメータ：ADD_STREAM.SCTPの結果に関する情報
Comments: this is issued when the procedure for adding a stream has completed.
コメント：ストリームを追加する手順が完了したときに発行されます。
o SET_STREAM_SCHEDULER.SCTP:
o SET_STREAM_SCHEDULER.SCTP：
Pass 1 primitive/event: 'Set Stream Scheduler'
1つのプリミティブ/イベントを渡す： 'Set Stream Scheduler'
Parameters: scheduler identifier
パラメータ：スケジューラ識別子
Comments: choice of First-Come, First-Served; Round-Robin; Round-Robin per Packet; Priority-Based; Fair Bandwidth; and Weighted Fair Queuing.
コメント：先着順、先着順の選択。ラウンドロビン;パケットごとのラウンドロビン。優先度ベース;公平な帯域幅;加重フェアキューイング。
o CONFIGURE_STREAM_SCHEDULER.SCTP:
o CONFIGURE_STREAM_SCHEDULER.SCTP：
Pass 1 primitive/event: 'Configure Stream Scheduler'
1つのプリミティブ/イベントを渡す： 'Configure Stream Scheduler'
Parameters: priority
パラメータ：優先度
Comments: the priority value only applies when Priority-Based or Weighted Fair Queuing scheduling is chosen with SET_STREAM_SCHEDULER.SCTP. The meaning of the parameter differs between these two schedulers, but in both cases, it realizes some form of prioritization regarding how bandwidth is divided among streams.
コメント：優先度の値は、SET_STREAM_SCHEDULER.SCTPで優先度ベースまたは重み付けされた均等化キュースケジューリングが選択されている場合にのみ適用されます。パラメータの意味はこれら2つのスケジューラの間で異なりますが、どちらの場合も、帯域幅がストリーム間でどのように分割されるかに関して、何らかの形式の優先順位付けを実現します。
o SET_FLOWLABEL.SCTP:
o SET_FLOWLABEL.SCTP：
Pass 1 primitive/event: 'Set IPv6 Flow Label'
1つのプリミティブ/イベントを渡す：「IPv6フローラベルの設定」
Parameters: flow label
パラメータ：フローラベル
Comments: this allows an application to change the IPv6 header's flow label field for outgoing packets on a path.
コメント：これにより、アプリケーションは、パス上の発信パケットのIPv6ヘッダーのフローラベルフィールドを変更できます。
o AUTHENTICATION_NOTIFICATION-EVENT.SCTP:
o AUTHENTICATION_NOTIFICATION-EVENT.SCTP：
Pass 1 primitive/event: 'Authentication' notification
1つのプリミティブ/イベントを渡す：「認証」通知
Returns: information regarding key management
戻り値：キー管理に関する情報
o CONFIG_SEND_BUFFER.SCTP:
o CONFIG_SEND_BUFFER.SCTP：
Pass 1 primitive/event: 'Configure Send Buffer Size'
1つのプリミティブ/イベントを渡す：「Configure Send Buffer Size」
Parameters: size value in octets
パラメータ：オクテットのサイズ値
o CONFIG_RECEIVE_BUFFER.SCTP:
o CONFIG_RECEIVE_BUFFER.SCTP：
Pass 1 primitive/event: 'Configure Receive Buffer Size'
1つのプリミティブ/イベントを渡す： 'Configure Receive Buffer Size'
Parameters: size value in octets
パラメータ：オクテットのサイズ値
Comments: this controls the receiver window.
コメント：これはレシーバーウィンドウを制御します。
o CONFIG_FRAGMENTATION.SCTP:
o CONFIG_FRAGMENTATION.SCTP：
Pass 1 primitive/event: 'Configure Message Fragmentation'
1つのプリミティブ/イベントを渡す：「メッセージの断片化を構成する」
Parameters: one boolean value (enable/disable) and maximum
fragmentation size (optional; default: PMTU)
Comments: if fragmentation is enabled, messages exceeding the maximum fragmentation size will be fragmented. If fragmentation is disabled, trying to send a message that exceeds the maximum fragmentation size will produce an error.
コメント：断片化が有効になっている場合、最大断片化サイズを超えるメッセージは断片化されます。断片化が無効になっている場合、最大断片化サイズを超えるメッセージを送信しようとすると、エラーが発生します。
o CONFIG_PMTUD.SCTP:
o CONFIG_PMTUD.SCTP：
Pass 1 primitive/event: 'Configure Path MTU Discovery'
1つのプリミティブ/イベントを渡す：「パスMTUディスカバリーの構成」
Parameters: one boolean value (PMTUD on/off) and PMTU value (optional)
パラメータ：1つのブール値（PMTUDオン/オフ）およびPMTU値（オプション）
Returns: PMTU value
戻り値：PMTU値
Comments: this returns a meaningful PMTU value when PMTUD is enabled (the boolean is true), and the PMTU value can be set if PMTUD is disabled (the boolean is false).
コメント：これは、PMTUDが有効（ブール値がtrue）の場合に意味のあるPMTU値を返します。PMTUDが無効（ブール値がfalse）の場合は、PMTU値を設定できます。
o CONFIG_DELAYED_SACK.SCTP:
o CONFIG_DELAYED_SACK.SCTP：
Pass 1 primitive/event: 'Configure Delayed SACK Timer'
1つのプリミティブ/イベントを渡す： 'Configure Delayed SACK Timer'
Parameters: one boolean value (delayed SACK on/off); timer value
(optional); and number of packets to wait for (default 2)
Comments: if delayed SACK is enabled, SCTP will send a SACK either upon receiving the provided number of packets or when the timer expires, whatever occurs first.
コメント：遅延SACKが有効になっている場合、SCTPは、指定された数のパケットを受信したとき、またはタイマーが切れたときに、最初に発生したもののいずれかでSACKを送信します。
o CONFIG_RTO.SCTP:
o CONFIG_RTO.SCTP：
Pass 1 primitive/event: 'Configure RTO Calculation'
1つのプリミティブ/イベントを渡す：「RTO計算の構成」
Parameters: init (optional); min (optional); and max (optional)
Comments: this adjusts the initial, minimum, and maximum RTO values.
コメント：これにより、RTOの初期値、最小値、および最大値が調整されます。
o SET_COOKIE_LIFE.SCTP:
o SET_COOKIE_LIFE.SCTP：
Pass 1 primitive/event: 'Set Cookie Life Value'
1つのプリミティブ/イベントを渡す：「Set Cookie Life Value」
Parameters: cookie life value
パラメータ：Cookieライフの値
o SET_MAX_BURST.SCTP:
o SET_MAX_BURST.SCTP：
Pass 1 primitive/event: 'Set Maximum Burst'
1つのプリミティブ/イベントを渡す： 'Set Maximum Burst'
Parameters: max burst value
パラメータ：最大バースト値
Comments: not all implementations allow values above the default of 4.
コメント：すべての実装がデフォルトの4を超える値を許可するわけではありません。
o SET_PARTIAL_DELIVERY_POINT.SCTP:
o SET_PARTIAL_DELIVERY_POINT.SCTP：
Pass 1 primitive/event: 'Set Partial Delivery Point'
1つのプリミティブ/イベントを渡す： 'Set Partial Delivery Point'
Parameters: partial delivery point (integer)
パラメータ：部分配信ポイント（整数）
Comments: this parameter must be smaller or equal to the socket receive buffer size.
コメント：このパラメーターは、ソケット受信バッファーサイズ以下でなければなりません。
o SET_CHECKSUM_ENABLED.UDP:
o SET_CHECKSUM_ENABLED.UDP：
Pass 1 primitive/event: 'Checksum_Enabled'
1つのプリミティブ/イベントを渡す： 'Checksum_Enabled'
Parameters: 0 when zero checksum is used at sender, 1 for checksum at sender (default)
パラメータ：0は送信側でゼロのチェックサムが使用される場合、1は送信側でのチェックサム（デフォルト）
o SET_CHECKSUM_REQUIRED.UDP:
o SET_CHECKSUM_REQUIRED.UDP：
Pass 1 primitive/event: 'Require_Checksum'
1つのプリミティブ/イベントを渡す： 'Require_Checksum'
Parameter: 0 to allow zero checksum, 1 when a non-zero checksum is required (default) at the receiver
パラメータ：0はゼロチェックサムを許可し、1はレシーバーでゼロ以外のチェックサムが必要な場合（デフォルト）
o SET_CHECKSUM_COVERAGE.UDP-Lite:
o SET_CHECKSUM_COVERAGE.UDP-Lite：
Pass 1 primitive/event: 'Set_Checksum_Coverage'
1つのプリミティブ/イベントを渡す： 'Set_Checksum_Coverage'
Parameters: coverage length at sender (default maximum coverage)
パラメータ：送信者のカバレッジ長（デフォルトの最大カバレッジ）
o SET_MIN_CHECKSUM_COVERAGE.UDP-Lite:
o SET_MIN_CHECKSUM_COVERAGE.UDP-Lite：
Pass 1 primitive/event: 'Set_Min_Coverage'
1つのプリミティブ/イベントを渡す： 'Set_Min_Coverage'
Parameter: coverage length at receiver (default minimum coverage)
パラメータ：レシーバーでのカバレッジ長（デフォルトの最小カバレッジ）
o SET_DF.UDP(-Lite):
o SET_DF.UDP（-Lite）：
Pass 1 primitive event: 'Set_DF'
1つのプリミティブイベントを渡す： 'Set_DF'
Parameter: 0 when DF is not set (default) in the IPv4 header, 1 when DF is set
パラメータ：IPv4ヘッダーでDFが設定されていない場合（デフォルト）は0、DFが設定されている場合は1
o GET_MMS_S.UDP(-Lite):
o GET_MMS_S.UDP（-Lite）：
Pass 1 primitive event: 'Get_MM_S'
1つのプリミティブイベントを渡す： 'Get_MM_S'
Comments: this retrieves the maximum transport-message size that may be sent using a non-fragmented IP packet from the configured interface.
コメント：これは、構成されたインターフェースからフラグメント化されていないIPパケットを使用して送信できるトランスポートメッセージの最大サイズを取得します。
o GET_MMS_R.UDP(-Lite):
o GET_MMS_R.UDP（-Lite）：
Pass 1 primitive event: 'Get_MMS_R'
1つのプリミティブイベントを渡す： 'Get_MMS_R'
Comments: this retrieves the maximum transport-message size that may be received from the configured interface.
コメント：これは、構成されたインターフェースから受信できるトランスポートメッセージの最大サイズを取得します。
o SET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):
o SET_TTL.UDP（-Lite）（IPV6_UNICAST_HOPS）：
Pass 1 primitive/event: 'Set_TTL' and 'Set_IPV6_Unicast_Hops'
1つのプリミティブ/イベントを渡す： 'Set_TTL'および 'Set_IPV6_Unicast_Hops'
Parameters: IPv4 TTL value or IPv6 Hop Count value
パラメータ：IPv4 TTL値またはIPv6ホップカウント値
Comments: this allows an application to change the IPv4 TTL of IPv6 Hop Count value for outgoing UDP(-Lite) datagrams.
コメント：これにより、アプリケーションは発信UDP（-Lite）データグラムのIPv6ホップカウント値のIPv4 TTLを変更できます。
o GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):
o GET_TTL.UDP（-Lite）（IPV6_UNICAST_HOPS）：
Pass 1 primitive/event: 'Get_TTL' and 'Get_IPV6_Unicast_Hops'
1つのプリミティブ/イベントを渡す： 'Get_TTL'および 'Get_IPV6_Unicast_Hops'
Returns: IPv4 TTL value or IPv6 Hop Count value
戻り値：IPv4 TTL値またはIPv6ホップカウント値
Comments: this allows an application to read the IPv4 TTL of the IPv6 Hop Count value from a received UDP(-Lite) datagram.
コメント：これにより、アプリケーションは受信したUDP（-Lite）データグラムからIPv6ホップカウント値のIPv4 TTLを読み取ることができます。
o SET_ECN.UDP(-Lite):
o SET_ECN.UDP（-Lite）：
Pass 1 primitive/event: 'Set_ECN'
1つのプリミティブ/イベントを渡す： 'Set_ECN'
Parameters: ECN value
パラメータ：ECN値
Comments: this allows a UDP(-Lite) application to set the Explicit Congestion Notification (ECN) code point field for outgoing UDP(-Lite) datagrams. It defaults to sending '00'.
コメント：これにより、UDP（-Lite）アプリケーションは、発信UDP（-Lite）データグラムの明示的輻輳通知（ECN）コードポイントフィールドを設定できます。デフォルトでは「00」が送信されます。
o GET_ECN.UDP(-Lite):
o GET_ECN.UDP（-Lite）：
Pass 1 primitive/event: 'Get_ECN'
Pass 1 primitive/event: 'Get_ECN'
Parameters: ECN value
パラメータ：ECN値
Comments: this allows a UDP(-Lite) application to read the ECN code point field from a received UDP(-Lite) datagram.
コメント：これにより、UDP（-Lite）アプリケーションは、受信したUDP（-Lite）データグラムからECNコードポイントフィールドを読み取ることができます。
o SET_IP_OPTIONS.UDP(-Lite):
o SET_IP_OPTIONS.UDP（-Lite）：
Pass 1 primitive/event: 'Set_IP_Options'
1つのプリミティブ/イベントを渡す： 'Set_IP_Options'
Parameters: options
Parameters: options
Comments: this allows a UDP(-Lite) application to set IP options for outgoing UDP(-Lite) datagrams. These options can at least be the Source Route, Record Route, and Timestamp option.
コメント：これにより、UDP（-Lite）アプリケーションは、発信UDP（-Lite）データグラムのIPオプションを設定できます。これらのオプションは、少なくともソースルート、レコードルート、およびタイムスタンプオプションにすることができます。
o GET_IP_OPTIONS.UDP(-Lite):
o GET_IP_OPTIONS.UDP（-Lite）：
Pass 1 primitive/event: 'Get_IP_Options'
1つのプリミティブ/イベントを渡す： 'Get_IP_Options'
Returns: options
戻り値：オプション
Comments: this allows a UDP(-Lite) application to receive any IP options that are contained in a received UDP(-Lite) datagram.
コメント：これにより、UDP（-Lite）アプリケーションは、受信したUDP（-Lite）データグラムに含まれているIPオプションを受信できます。
o CONFIGURE.LEDBAT:
o CONFIGURE.LEDBAT：
Pass 1 primitive/event: N/A
Parameters: enable (boolean); target; allowed_increase; gain_inc;
gain_dec; base_history; current_filter; init_cwnd; and min_cwnd
Comments: 'enable' is a newly invented parameter that enables or disables the whole LEDBAT service.
コメント： 'enable'は、LEDBATサービス全体を有効または無効にする、新しく発明されたパラメーターです。
TERMINATION:
終了：
Gracefully or forcefully closing a connection or being informed about this event happening.
正常にまたは強制的に接続を閉じる、またはこのイベントの発生について通知を受ける。
o CLOSE.TCP:
o CLOSE.TCP：
Pass 1 primitive/event: 'Close'
1つのプリミティブ/イベントを渡す：「閉じる」
Comments: this terminates the sending side of a connection after reliably delivering all remaining data.
コメント：これは、残りのすべてのデータを確実に配信した後、接続の送信側を終了します。
o CLOSE.SCTP:
o CLOSE.SCTP：
Pass 1 primitive/event: 'Shutdown'
1つのプリミティブ/イベントを渡す：「シャットダウン」
Comments: this terminates a connection after reliably delivering all remaining data.
コメント：残りのすべてのデータを確実に配信した後、接続を終了します。
o ABORT.TCP:
o ABORT.TCP：
Pass 1 primitive/event: 'Abort'
1つのプリミティブ/イベントを渡す：「中止」
Comments: this terminates a connection without delivering remaining data and sends an error message to the other side.
コメント：これは、残りのデータを配信せずに接続を終了し、反対側にエラーメッセージを送信します。
o ABORT.SCTP:
o ABORT.SCTP:
Pass 1 primitive/event: 'Abort'
1つのプリミティブ/イベントを渡す：「中止」
Parameters: abort reason to be given to the peer (optional)
Parameters: abort reason to be given to the peer (optional)
Comments: this terminates a connection without delivering remaining data and sends an error message to the other side.
コメント：これは、残りのデータを配信せずに接続を終了し、反対側にエラーメッセージを送信します。
o ABORT.UDP(-Lite):
o ABORT.UDP（-Lite）：
Pass 1 primitive event: 'Close'
1つのプリミティブイベントを渡す：「閉じる」
Comments: this terminates a connection without delivering remaining data. No further UDP(-Lite) datagrams are sent/received for this transport service instance.
コメント：残りのデータを配信せずに接続を終了します。このトランスポートサービスインスタンスでは、これ以上UDP（-Lite）データグラムは送受信されません。
o TIMEOUT.TCP:
o TIMEOUT.TCP：
Pass 1 primitive/event: 'User Timeout' event
1つのプリミティブ/イベントを渡す：「ユーザータイムアウト」イベント
Comments: the application is informed that the connection is aborted. This event is executed on expiration of the timeout set in CONNECTION.ESTABLISHMENT.CONNECT.TCP (possibly adjusted in CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP).
コメント：接続が中止されたことがアプリケーションに通知されます。このイベントは、CONNECTION.ESTABLISHMENT.CONNECT.TCPで設定されたタイムアウトの終了時に実行されます（CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCPで調整される可能性があります）。
o TIMEOUT.SCTP:
o TIMEOUT.SCTP：
Pass 1 primitive/event: 'Communication Lost' event
1つのプリミティブ/イベントを渡す：「通信喪失」イベント
Comments: the application is informed that the connection is aborted. This event is executed on expiration of the timeout that should be enabled by default (see the beginning of Section 8.3 in [RFC4960]) and was possibly adjusted in CONNECTION.MAINTENANCE.CHANGE_TIMEOOUT.SCTP.
コメント：接続が中止されたことがアプリケーションに通知されます。このイベントは、デフォルトで有効になるはずのタイムアウトの満了時に実行され（[RFC4960]のセクション8.3の冒頭を参照）、おそらくCONNECTION.MAINTENANCE.CHANGE_TIMEOOUT.SCTPで調整されました。
o ABORT-EVENT.TCP:
o ABORT-EVENT.TCP：
Pass 1 primitive/event: not specified
1つのプリミティブ/イベントを渡す：指定されていません
o ABORT-EVENT.SCTP:
o ABORT-EVENT.SCTP：
Pass 1 primitive/event: 'Communication Lost' event
1つのプリミティブ/イベントを渡す：「通信喪失」イベント
Returns: abort reason from the peer (if available)
戻り値：ピアからの中止理由（利用可能な場合）
Comments: the application is informed that the other side has aborted the connection using CONNECTION.TERMINATION.ABORT.SCTP.
コメント：アプリケーションは、相手側がCONNECTION.TERMINATION.ABORT.SCTPを使用して接続を中止したことを通知されます。
o CLOSE-EVENT.TCP:
o CLOSE-EVENT.TCP：
Pass 1 primitive/event: not specified
1つのプリミティブ/イベントを渡す：指定されていません
o CLOSE-EVENT.SCTP:
o CLOSE-EVENT.SCTP：
Pass 1 primitive/event: 'Shutdown Complete' event
Pass 1 primitive/event: 'Shutdown Complete' event
Comments: the application is informed that CONNECTION.TERMINATION.CLOSE.SCTP was successfully completed.
Comments: the application is informed that CONNECTION.TERMINATION.CLOSE.SCTP was successfully completed.
All primitives in this section refer to an existing connection, i.e., a connection that was either established or made available for receiving data (although this is optional for the primitives of UDP(-Lite)). In addition to the listed parameters, all sending primitives contain a reference to a data block, and all receiving primitives contain a reference to available buffer space for the data. Note that CONNECT.TCP and LISTEN.TCP in the ESTABLISHMENT and AVAILABILITY categories also allow to transfer data (an optional user message) before the connection is fully established.
このセクションのすべてのプリミティブは、既存の接続、つまり確立された、またはデータの受信に使用できるようになった接続を指します（ただし、これはUDP（-Lite）のプリミティブではオプションです）。リストされたパラメーターに加えて、すべての送信プリミティブにはデータブロックへの参照が含まれ、すべての受信プリミティブにはデータに利用可能なバッファースペースへの参照が含まれます。 ESTABLISHMENTおよびAVAILABILITYカテゴリのCONNECT.TCPおよびLISTEN.TCPでは、接続が完全に確立される前にデータ（オプションのユーザーメッセージ）を転送することもできます。
o SEND.TCP:
o SEND.TCP:
Pass 1 primitive/event: 'Send'
1つのプリミティブ/イベントを渡す：「送信」
Parameters: timeout (optional); current_key (optional); and rnext_key (optional)
パラメータ：タイムアウト（オプション）; current_key（オプション）;およびrnext_key（オプション）
Comments: this gives TCP a data block for reliable transmission to the TCP on the other side of the connection. The timeout can be configured with this call (see also CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP). 'current_key' and 'rnext_key' are authentication parameters that can be configured with this call (see also CONNECTION.MAINTENANCE.SET_AUTH.TCP).
コメント：これは、TCPに接続の反対側のTCPへの信頼できる伝送のためのデータブロックを与えます。タイムアウトはこの呼び出しで構成できます（CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCPも参照）。 「current_key」および「rnext_key」は、この呼び出しで構成できる認証パラメーターです（CONNECTION.MAINTENANCE.SET_AUTH.TCPも参照）。
o SEND.SCTP:
o SEND.SCTP：
Pass 1 primitive/event: 'Send'
1つのプリミティブ/イベントを渡す：「送信」
Parameters: stream number; context (optional); socket (optional);
unordered flag (optional); no-bundle flag (optional); payload
protocol-id (optional); pr-policy (optional) pr-value (optional);
sack-immediately flag (optional); and key-id (optional)
Comments: this gives SCTP a data block for transmission to the SCTP on the other side of the connection (SCTP association). The 'stream number' denotes the stream to be used. The 'context' number can later be used to refer to the correct message when an error is reported. The 'socket' can be used to state which path should be preferred, if there are multiple paths available (see also CONNECTION.MAINTENANCE.SETPRIMARY.SCTP). The data block can be delivered out of order if the 'unordered' flag is set. The 'no-bundle flag' can be set to indicate a preference to avoid bundling. The 'payload protocol-id' is a number that will, if provided, be handed over to the receiving application. Using pr-policy and pr-value, the level of reliability can be controlled. The 'sack-immediately' flag can be used to indicate that the peer should not delay the sending of a SACK corresponding to the provided user message. If specified, the provided key-id is used for authenticating the user message.
コメント：これにより、接続の反対側のSCTPに送信するためのデータブロックがSCTPに提供されます（SCTPアソシエーション）。 「ストリーム番号」は、使用するストリームを示します。 「コンテキスト」番号は、後でエラーが報告されたときに正しいメッセージを参照するために使用できます。 「ソケット」は、複数のパスが利用可能な場合にどのパスを優先するかを示すために使用できます（CONNECTION.MAINTENANCE.SETPRIMARY.SCTPも参照）。 'unordered'フラグが設定されている場合、データブロックは順不同で配信される可能性があります。 「バンドルなしフラグ」を設定して、バンドルを回避するための設定を示すことができます。 「ペイロードプロトコルID」は、提供された場合、受信アプリケーションに渡される番号です。 pr-policyとpr-valueを使用して、信頼性のレベルを制御できます。 「sack-immediately」フラグは、ピアが、提供されたユーザーメッセージに対応するSACKの送信を遅らせてはならないことを示すために使用できます。指定した場合、提供されたキーIDはユーザーメッセージの認証に使用されます。
o SEND.UDP(-Lite):
o SEND.UDP（-Lite）：
Pass 1 primitive/event: 'Send'
1つのプリミティブ/イベントを渡す：「送信」
Parameters: IP address and port number of the destination endpoint (optional if connected)
パラメーター：宛先エンドポイントのIPアドレスとポート番号（接続されている場合はオプション）
Comments: this provides a message for unreliable transmission using UDP(-Lite) to the specified transport address. The IP address and port number may be omitted for connected UDP(-Lite) sockets. All CONNECTION.MAINTENANCE.SET_*.UDP(-Lite) primitives apply per message sent.
コメント：これは、指定されたトランスポートアドレスへのUDP（-Lite）を使用した信頼性の低い送信に関するメッセージを提供します。接続されているUDP（-Lite）ソケットの場合、IPアドレスとポート番号は省略できます。すべてのCONNECTION.MAINTENANCE.SET _ *。UDP（-Lite）プリミティブは、送信されるメッセージごとに適用されます。
o RECEIVE.TCP:
o RECEIVE.TCP:
Pass 1 primitive/event: 'Receive'
1つのプリミティブ/イベントを渡す：「受信」
Parameters: current_key (optional) and rnext_key (optional)
パラメータ：current_key（オプション）およびrnext_key（オプション）
Comments: 'current_key' and 'rnext_key' are authentication parameters that can be read with this call (see also CONNECTION.MAINTENANCE.GET_AUTH.TCP).
Comments: 'current_key' and 'rnext_key' are authentication parameters that can be read with this call (see also CONNECTION.MAINTENANCE.GET_AUTH.TCP).
o RECEIVE.SCTP:
o RECEIVE.SCTP：
Pass 1 primitive/event: 'Data Arrive' notification, followed by 'Receive'
1つのプリミティブ/イベントを渡す：「データ到着」通知、続いて「受信」
Parameters: stream number (optional)
パラメータ：ストリーム番号（オプション）
Returns: stream sequence number (optional) and partial flag (optional)
戻り値：ストリームシーケンス番号（オプション）および部分フラグ（オプション）
Comments: if the 'stream number' is provided, the call to receive only receives data on one particular stream. If a partial message arrives, this is indicated by the 'partial flag', and then the 'stream sequence number' must be provided such that an application can restore the correct order of data blocks that comprise an entire message.
Comments: if the 'stream number' is provided, the call to receive only receives data on one particular stream. If a partial message arrives, this is indicated by the 'partial flag', and then the 'stream sequence number' must be provided such that an application can restore the correct order of data blocks that comprise an entire message.
o RECEIVE.UDP(-Lite):
o RECEIVE.UDP（-Lite）：
Pass 1 primitive/event: 'Receive'
1つのプリミティブ/イベントを渡す：「受信」
Parameters: buffer for received datagram
パラメータ：受信したデータグラムのバッファー
Comments: all CONNECTION.MAINTENANCE.GET_*.UDP(-Lite) primitives apply per message received.
コメント：すべてのCONNECTION.MAINTENANCE.GET _ *。UDP（-Lite）プリミティブは、受信したメッセージごとに適用されます。
o SENDFAILURE-EVENT.SCTP:
o SENDFAILURE-EVENT.SCTP:
Pass 1 primitive/event: 'Send Failure' notification, optionally followed by 'Receive Unsent Message' or 'Receive Unacknowledged Message'
1つのプリミティブ/イベントを渡す：「送信失敗」通知、オプションで「未送信メッセージの受信」または「未確認メッセージの受信」
Returns: cause code; context; and unsent or unacknowledged message
(optional)
Comments: 'cause code' indicates the reason of the failure, and 'context' is the context number if such a number has been provided in DATA.SEND.SCTP, for later use with 'Receive Unsent Message' or 'Receive Unacknowledged Message', respectively. These primitives can be used to retrieve the unsent or unacknowledged message (or part of the message, in case a part was delivered) if desired.
コメント：「原因コード」は失敗の理由を示し、「context」はDATA.SEND.SCTPで提供されている場合のコンテキスト番号であり、後で「Receive Unsent Message」または「Receive Unacknowledged Message」で使用されます。 、それぞれ。これらのプリミティブは、必要に応じて、未送信または未確認のメッセージ（または一部が配信された場合はメッセージの一部）を取得するために使用できます。
o SEND_FAILURE.UDP(-Lite):
o SEND_FAILURE.UDP（-Lite）：
Pass 1 primitive/event: 'Send'
Pass 1 primitive/event: 'Send'
Comments: this may be used to probe for the effective PMTU when using in combination with the 'MAINTENANCE.SET_DF' primitive.
コメント：これは、 'MAINTENANCE.SET_DF'プリミティブと組み合わせて使用するときに、有効なPMTUをプローブするために使用できます。
o SENDER_DRY-EVENT.SCTP:
o SENDER_DRY-EVENT.SCTP：
Pass 1 primitive/event: 'Sender Dry' notification
1つのプリミティブ/イベントを渡す：「送信者ドライ」通知
Comments: this informs the application that the stack has no more user data to send.
Comments: this informs the application that the stack has no more user data to send.
o PARTIAL_DELIVERY_ABORTED-EVENT.SCTP:
o PARTIAL_DELIVERY_ABORTED-EVENT.SCTP：
Pass 1 primitive/event: 'Partial Delivery Aborted' notification
1つのプリミティブ/イベントを渡す：「Partial Delivery Aborted」通知
Comments: this informs the receiver of a partial message that the further delivery of the message has been aborted.
コメント：メッセージの部分的な配信が中止されたことを部分的なメッセージの受信者に通知します。
This section presents the superset of all transport features in all protocols that were discussed in the preceding sections, based on the list of primitives in pass 2 but also on text in pass 1 to include transport features that can be configured in one protocol and are static properties in another (congestion control, for example). Again, some minor details are omitted for the sake of generalization -- e.g., TCP may provide various different IP options, but only source route is mandatory to implement, and this detail is not visible in the pass 3 transport feature "Specify IP options". As before, "UDP(-Lite)" represents both UDP and UDP-Lite, and "TCP" refers to both TCP and MPTCP.
このセクションでは、前のセクションで説明したすべてのプロトコルのすべてのトランスポート機能のスーパーセットを、パス2のプリミティブのリストだけでなく、パス1のテキストにも基づいて示し、1つのプロトコルで構成でき、静的なトランスポート機能を含めます。別のプロパティ（輻輳制御など）。繰り返しになりますが、一般化のためにいくつかの細かい詳細は省略されています。たとえば、TCPはさまざまな異なるIPオプションを提供することがありますが、実装にはソースルートのみが必須であり、この詳細はパス3トランスポート機能の「Specify IP options」には表示されません。 。以前と同様に、「UDP（-Lite）」はUDPとUDP-Liteの両方を表し、「TCP」はTCPとMPTCPの両方を表します。
ESTABLISHMENT: Active creation of a connection from one transport endpoint to one or more transport endpoints.
ESTABLISHMENT：1つのトランスポートエンドポイントから1つ以上のトランスポートエンドポイントへの接続のアクティブな作成。
o Connect Protocols: TCP, SCTP, and UDP(-Lite)
o Connect Protocols: TCP, SCTP, and UDP(-Lite)
o Specify which IP options must always be used Protocols: TCP and UDP(-Lite)
o 常に使用する必要があるIPオプションを指定するプロトコル：TCPおよびUDP（-Lite）
o Request multiple streams Protocols: SCTP
o 複数のストリームを要求するプロトコル：SCTP
o Limit the number of inbound streams Protocols: SCTP
o インバウンドストリームの数を制限するプロトコル：SCTP
o Specify number of attempts and/or timeout for the first establishment message Protocols: TCP and SCTP
o 最初の確立メッセージの試行回数やタイムアウトを指定するプロトコル：TCPおよびSCTP
o Obtain multiple sockets Protocols: SCTP
o 複数のソケットを取得するプロトコル：SCTP
o Disable MPTCP Protocols: MPTCP
o MPTCPプロトコルを無効にする：MPTCP
o Configure authentication Protocols: TCP and SCTP Comments: with TCP, this allows the configuration of MKTs. In SCTP, this allows the specification of which chunk types must always be authenticated. DATA, ACK, etc., are different 'chunks' in SCTP; one or more chunks may be included in a single packet.
o 認証プロトコルの構成：TCPおよびSCTPコメント：TCPでは、これによりMKTを構成できます。 SCTPでは、これにより、どのチャンクタイプを常に認証する必要があるかを指定できます。 DATA、ACKなどは、SCTPでは異なる「チャンク」です。 1つまたは複数のチャンクを1つのパケットに含めることができます。
o Indicate an Adaptation Layer (via an adaptation code point) Protocols: SCTP
o 適応層を示す（適応コードポイントを介して）プロトコル：SCTP
o Request to negotiate interleaving of user messages Protocols: SCTP
o ユーザーメッセージのインターリーブをネゴシエートする要求プロトコル：SCTP
o Hand over a message to reliably transfer (possibly multiple times) before connection establishment Protocols: TCP
o 接続確立前に確実に転送するためにメッセージを引き渡します（おそらく複数回）プロトコル：TCP
o Hand over a message to reliably transfer during connection establishment Protocols: SCTP
o 接続確立中に確実に転送するためにメッセージを引き渡すプロトコル：SCTP
o Enable UDP encapsulation with a specified remote UDP port number Protocols: SCTP
o 指定されたリモートUDPポート番号でUDPカプセル化を有効にするプロトコル：SCTP
AVAILABILITY:
可用性：
Preparing to receive incoming connection requests.
着信接続要求を受信する準備をしています。
o Listen, 1 specified local interface Protocols: TCP, SCTP, and UDP(-Lite)
o リッスン、1つの指定されたローカルインターフェイスプロトコル：TCP、SCTP、およびUDP（-Lite）
o Listen, N specified local interfaces Protocols: SCTP
o Listen, N specified local interfaces Protocols: SCTP
o Listen, all local interfaces Protocols: TCP, SCTP, and UDP(-Lite)
o リスニング、すべてのローカルインターフェースプロトコル：TCP、SCTP、およびUDP（-Lite）
o Obtain requested number of streams Protocols: SCTP
o 要求されたストリーム数を取得するプロトコル：SCTP
o Limit the number of inbound streams Protocols: SCTP
o Limit the number of inbound streams Protocols: SCTP
o Specify which IP options must always be used Protocols: TCP and UDP(-Lite)
o Specify which IP options must always be used Protocols: TCP and UDP(-Lite)
o Disable MPTCP Protocols: MPTCP
o MPTCPプロトコルを無効にする：MPTCP
o Configure authentication Protocols: TCP and SCTP Comments: with TCP, this allows the configuration of MKTs. In SCTP, this allows the specification of which chunk types must always be authenticated. DATA, ACK, etc., are different 'chunks' in SCTP; one or more chunks may be included in a single packet.
o 認証プロトコルの構成：TCPおよびSCTPコメント：TCPでは、これによりMKTを構成できます。 SCTPでは、これにより、どのチャンクタイプを常に認証する必要があるかを指定できます。 DATA、ACKなどは、SCTPでは異なる「チャンク」です。 1つまたは複数のチャンクを1つのパケットに含めることができます。
o Indicate an Adaptation Layer (via an adaptation code point) Protocols: SCTP
o Indicate an Adaptation Layer (via an adaptation code point) Protocols: SCTP
MAINTENANCE:
メンテナンス：
Adjustments made to an open connection, or notifications about it.
Adjustments made to an open connection, or notifications about it.
o Change timeout for aborting connection (using retransmit limit or time value) Protocols: TCP and SCTP
o 接続を中止するためのタイムアウトを変更（再送信制限または時間値を使用）プロトコル：TCPおよびSCTP
o Suggest timeout to the peer Protocols: TCP
o ピアプロトコルにタイムアウトを提案：TCP
o Disable Nagle algorithm Protocols: TCP and SCTP
o Nagleアルゴリズムプロトコルを無効にする：TCPおよびSCTP
o Request an immediate heartbeat, returning success/failure Protocols: SCTP
o 即時ハートビートを要求し、成功/失敗を返すプロトコル：SCTP
o Notification of excessive retransmissions (early warning below abortion threshold) Protocols: TCP
o Notification of excessive retransmissions (early warning below abortion threshold) Protocols: TCP
o Add path Protocols: MPTCP and SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; and destination-Port SCTP Parameters: local IP address
o パスプロトコルを追加します：MPTCPおよびSCTP MPTCPパラメータ：source-IP; source-Port;宛先IP;および宛先ポートSCTPパラメータ：ローカルIPアドレス
o Remove path Protocols: MPTCP and SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; and destination-Port SCTP Parameters: local IP address
o パスプロトコルの削除：MPTCPおよびSCTP MPTCPパラメータ：source-IP; source-Port;宛先IP;および宛先ポートSCTPパラメータ：ローカルIPアドレス
o Set primary path Protocols: SCTP
o プライマリパスプロトコルの設定：SCTP
o Suggest primary path to the peer Protocols: SCTP
o ピアプロトコルへのプライマリパスを提案する：SCTP
o Configure Path Switchover Protocols: SCTP
o パススイッチオーバープロトコルの構成：SCTP
o Obtain status (query or notification) Protocols: SCTP and MPTCP SCTP parameters: association connection state; destination transport address list; destination transport address reachability states; current local and peer receiver window sizes; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; primary path; most recent SRTT on primary path; RTO on primary path; SRTT and RTO on other destination addresses; MTU per path; and interleaving supported yes/no MPTCP parameters: subflow-list (identified by source-IP; source-Port; destination-IP; and destination-Port)
o ステータス（クエリまたは通知）の取得プロトコル：SCTPおよびMPTCP SCTPパラメータ：アソシエーション接続状態。宛先トランスポートアドレスリスト。宛先トランスポートアドレスの到達可能性の状態。現在のローカルおよびピアレシーバーウィンドウのサイズ。現在のローカルの輻輳ウィンドウサイズ。未確認のDATAチャンクの数。受信保留中のDATAチャンクの数。プライマリパス;プライマリパス上の最新のSRTT。プライマリパスのRTO。他の宛先アドレスのSRTTおよびRTO。パスごとのMTU。およびインターリーブがサポートされているはい/いいえのMPTCPパラメータ：サブフローリスト（送信元IP、送信元ポート、宛先IP、および宛先ポートで識別）
o Specify DSCP field Protocols: TCP, SCTP, and UDP(-Lite)
o DSCPフィールドプロトコルの指定：TCP、SCTP、およびUDP（-Lite）
o Notification of ICMP error message arrival Protocols: TCP and UDP(-Lite)
o ICMPエラーメッセージの到着通知プロトコル：TCPおよびUDP（-Lite）
o Change authentication parameters Protocols: TCP and SCTP
o 認証パラメーターの変更プロトコル：TCPおよびSCTP
o Obtain authentication information Protocols: TCP and SCTP
o 認証情報の取得プロトコル：TCPおよびSCTP
o Reset Stream Protocols: SCTP
o ストリームプロトコルのリセット：SCTP
o Notification of Stream Reset Protocols: STCP
o ストリームリセットプロトコルの通知：STCP
o Reset Association Protocols: SCTP
o アソシエーションプロトコルのリセット：SCTP
o Notification of Association Reset Protocols: STCP
o アソシエーションリセットプロトコルの通知：STCP
o Add Streams Protocols: SCTP
o ストリームプロトコルの追加：SCTP
o Notification of Added Stream Protocols: STCP
o 追加されたストリームプロトコルの通知：STCP
o Choose a scheduler to operate between streams of an association Protocols: SCTP
o アソシエーションのストリーム間で動作するスケジューラを選択するプロトコル：SCTP
o Configure priority or weight for a scheduler Protocols: SCTP
o スケジューラの優先度または重みを構成するプロトコル：SCTP
o Specify IPv6 flow label field Protocols: SCTP
o IPv6フローラベルフィールドプロトコルの指定：SCTP
o Configure send buffer size Protocols: SCTP
o 送信バッファーサイズプロトコルの構成：SCTP
o Configure receive buffer (and rwnd) size Protocols: SCTP
o 受信バッファー（およびrwnd）サイズを構成するプロトコル：SCTP
o Configure message fragmentation Protocols: SCTP
o メッセージフラグメンテーションプロトコルの構成：SCTP
o Configure PMTUD Protocols: SCTP
o PMTUDプロトコルの構成：SCTP
o Configure delayed SACK timer Protocols: SCTP
o 遅延SACKタイマープロトコルの構成：SCTP
o Set Cookie life value Protocols: SCTP
o Cookieライフバリュープロトコルの設定：SCTP
o Set maximum burst Protocols: SCTP
o 最大バーストプロトコルの設定：SCTP
o Configure size where messages are broken up for partial delivery Protocols: SCTP
o メッセージが分割配信されるサイズを構成するプロトコル：SCTP
o Disable checksum when sending Protocols: UDP
o プロトコルの送信時にチェックサムを無効にする：UDP
o Disable checksum requirement when receiving Protocols: UDP
o プロトコルの受信時にチェックサム要件を無効にする：UDP
o Specify checksum coverage used by the sender Protocols: UDP-Lite
o 送信者が使用するチェックサムカバレッジを指定するプロトコル：UDP-Lite
o Specify minimum checksum coverage required by receiver Protocols: UDP-Lite
o 受信者が必要とする最小チェックサムカバレッジを指定するプロトコル：UDP-Lite
o Specify DF field Protocols: UDP(-Lite)
o DFフィールドプロトコルの指定：UDP（-Lite）
o Get max. transport-message size that may be sent using a non-fragmented IP packet from the configured interface Protocols: UDP(-Lite)
o 最大を取得構成されたインターフェースからフラグメント化されていないIPパケットを使用して送信できるトランスポートメッセージサイズプロトコル：UDP（-Lite）
o Get max. transport-message size that may be received from the configured interface Protocols: UDP(-Lite)
o 最大を取得構成されたインターフェイスから受信できるトランスポートメッセージサイズプロトコル：UDP（-Lite）
o Specify TTL/Hop Count field Protocols: UDP(-Lite)
o TTL /ホップ数フィールドの指定プロトコル：UDP（-Lite）
o Obtain TTL/Hop Count field Protocols: UDP(-Lite)
o TTL /ホップカウントフィールドの取得プロトコル：UDP（-Lite）
o Specify ECN field Protocols: UDP(-Lite)
o ECNフィールドプロトコルの指定：UDP（-Lite）
o Obtain ECN field Protocols: UDP(-Lite)
o ECNフィールドプロトコルの取得：UDP（-Lite）
o Specify IP options Protocols: UDP(-Lite)
o IPオプションの指定プロトコル：UDP（-Lite）
o Obtain IP options Protocols: UDP(-Lite)
o IPオプションの取得プロトコル：UDP（-Lite）
o Enable and configure "Low Extra Delay Background Transfer" Protocols: A protocol implementing the LEDBAT congestion control mechanism
o 「低エクストラ遅延バックグラウンド転送」プロトコルを有効にして構成する：LEDBAT輻輳制御メカニズムを実装するプロトコル
TERMINATION:
終了：
Gracefully or forcefully closing a connection, or being informed about this event happening.
接続を正常にまたは強制的に閉じる、またはこのイベントの発生について通知を受ける。
o Close after reliably delivering all remaining data, causing an event informing the application on the other side Protocols: TCP and SCTP Comments: a TCP endpoint locally only closes the connection for sending; it may still receive data afterwards.
o 残りのすべてのデータを確実に配信した後に閉じると、反対側のアプリケーションに通知するイベントが発生します。プロトコル：TCPおよびSCTPコメント：TCPエンドポイントは、送信のためにローカルでのみ接続を閉じます。その後もデータを受信する場合があります。
o Abort without delivering remaining data, causing an event that informs the application on the other side Protocols: TCP and SCTP Comments: in SCTP, a reason can optionally be given by the application on the aborting side, which can then be received by the application on the other side.
o残りのデータを配信せずに中止し、反対側のアプリケーションに通知するイベントを発生させます。プロトコル：TCPおよびSCTPコメント：SCTPでは、中止側のアプリケーションがオプションで理由を示すことができ、アプリケーションがそれを受け取ることができます。反対側に。
o Abort without delivering remaining data, not causing an event that informs the application on the other side Protocols: UDP(-Lite)
o 残りのデータを配信せずに中止し、反対側のアプリケーションに通知するイベントを発生させないプロトコル：UDP（-Lite）
o Timeout event when data could not be delivered for too long Protocols: TCP and SCTP Comments: the timeout is configured with CONNECTION.MAINTENANCE "Change timeout for aborting connection (using retransmit limit or time value)".
o データが長すぎて配信できなかった場合のタイムアウトイベントプロトコル：TCPおよびSCTPコメント：タイムアウトはCONNECTION.MAINTENANCE "接続を中止するためのタイムアウトを変更します（再送信制限または時間値を使用）"。
All transport features in this section refer to an existing connection, i.e., a connection that was either established or made available for receiving data. Note that TCP allows the transfer of data (a single optional user message, possibly arriving multiple times) before the connection is fully established. Reliable data transfer entails delay -- e.g., for the sender to wait until it can transmit data or due to retransmission in case of packet loss.
このセクションのすべてのトランスポート機能は、既存の接続、つまり確立された、またはデータの受信に使用できるようになった接続を参照します。 TCPは、接続が完全に確立される前に、データ（単一のオプションのユーザーメッセージ、場合によっては複数回到着する）の転送を許可することに注意してください。信頼性の高いデータ転送には遅延が伴います。たとえば、送信者がデータを送信できるようになるまで、またはパケット損失の場合は再送信のために待機します。
All transport features in this section are provided by DATA.SEND from pass 2. DATA.SEND is given a data block from the application, which here we call a "message" if the beginning and end of the data block can be identified at the receiver, and "data" otherwise.
このセクションのすべてのトランスポート機能は、パス2のDATA.SENDによって提供されます。DATA.SENDには、アプリケーションからデータブロックが与えられます。データブロックの開始と終了がレシーバー、それ以外の場合は「データ」。
o Reliably transfer data, with congestion control Protocols: TCP
o 輻輳制御プロトコルでデータを確実に転送しますプロトコル：TCP
o Reliably transfer a message, with congestion control Protocols: SCTP
o 輻輳制御プロトコルでメッセージを確実に転送するプロトコル：SCTP
o Unreliably transfer a message, with congestion control Protocols: SCTP
o 輻輳制御プロトコルを使用してメッセージを信頼できない方法で転送する：SCTP
o Unreliably transfer a message, without congestion control Protocols: UDP(-Lite)
o 輻輳制御なしでメッセージを確実に転送しないプロトコル：UDP（-Lite）
o Configurable Message Reliability Protocols: SCTP
o 構成可能なメッセージ信頼性プロトコル：SCTP
o Choice of stream Protocols: SCTP
o ストリームプロトコルの選択：SCTP
o Choice of path (destination address) Protocols: SCTP
o パスの選択（宛先アドレス）プロトコル：SCTP
o Ordered message delivery (potentially slower than unordered) Protocols: SCTP
o 順序付けられたメッセージ配信（順序付けされていないものよりも潜在的に遅い）プロトコル：SCTP
o Unordered message delivery (potentially faster than ordered) Protocols: SCTP and UDP(-Lite)
o 順序付けられていないメッセージ配信（順序付けよりも潜在的に高速）プロトコル：SCTPおよびUDP（-Lite）
o Request not to bundle messages Protocols: SCTP
o メッセージをバンドルしないように要求するプロトコル：SCTP
o Specifying a 'payload protocol-id' (handed over as such by the receiver) Protocols: SCTP
o 「ペイロードプロトコルID」の指定（受信者から引き渡されるなど）プロトコル：SCTP
o Specifying a key identifier to be used to authenticate a message Protocols: SCTP
o メッセージの認証に使用されるキー識別子の指定プロトコル：SCTP
o Request not to delay the acknowledgement (SACK) of a message Protocols: SCTP
o メッセージの確認（SACK）を遅らせないように要求するプロトコル：SCTP
All transport features in this section are provided by DATA.RECEIVE from pass 2. DATA.RECEIVE fills a buffer provided by the application, with what here we call a "message" if the beginning and end of the data block can be identified at the receiver, and "data" otherwise.
このセクションのすべてのトランスポート機能は、パス2のDATA.RECEIVEによって提供されます。DATA.RECEIVEは、アプリケーションによって提供されるバッファーを満たします。データブロックの開始と終了がレシーバー、それ以外の場合は「データ」。
o Receive data (with no message delimiting) Protocols: TCP
o データの受信（メッセージ区切りなし）プロトコル：TCP
o Receive a message Protocols: SCTP and UDP(-Lite)
o メッセージの受信プロトコル：SCTPおよびUDP（-Lite）
o Choice of stream to receive from Protocols: SCTP
o プロトコルから受信するストリームの選択：SCTP
o Information about partial message arrival Protocols: SCTP Comments: in SCTP, partial messages are combined with a stream sequence number so that the application can restore the correct order of data blocks an entire message consists of.
o メッセージの部分的な到着に関する情報プロトコル：SCTPコメント：SCTPでは、メッセージ全体が構成するデータブロックの正しい順序をアプリケーションが復元できるように、部分的なメッセージがストリームシーケンス番号と組み合わされます。
This section describes sending failures that are associated with a specific call to DATA.SEND from pass 2.
このセクションでは、パス2からDATA.SENDへの特定の呼び出しに関連する送信エラーについて説明します。
o Notification of an unsent (part of a) message Protocols: SCTP and UDP(-Lite)
o 未送信（一部）のメッセージの通知プロトコル：SCTPおよびUDP（-Lite）
o Notification of an unacknowledged (part of a) message Protocols: SCTP
o 未確認（aの一部）メッセージの通知プロトコル：SCTP
o Notification that the stack has no more user data to send Protocols: SCTP
o スタックに送信するユーザーデータがなくなったという通知プロトコル：SCTP
o Notification to a receiver that a partial message delivery has been aborted Protocols: SCTP
o 部分的なメッセージ配信が中止されたという受信者への通知プロトコル：SCTP
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
Authentication, confidentiality protection, and integrity protection are identified as transport features [RFC8095]. These transport features are generally provided by a protocol or layer on top of the transport protocol; none of the transport protocols considered in this document provides these transport features on its own. Therefore, these transport features are not considered in this document, with the exception of native authentication capabilities of TCP and SCTP for which the security considerations in [RFC5925] and [RFC4895] apply.
認証、機密保護、および完全性保護は、トランスポート機能[RFC8095]として識別されます。これらのトランスポート機能は、通常、トランスポートプロトコルの上にあるプロトコルまたはレイヤーによって提供されます。このドキュメントで検討されているトランスポートプロトコルは、それ自体でこれらのトランスポート機能を提供していません。したがって、[RFC5925]および[RFC4895]のセキュリティに関する考慮事項が適用されるTCPおよびSCTPのネイティブ認証機能を除いて、これらのトランスポート機能はこのドキュメントでは考慮されていません。
Security considerations for the use of UDP and UDP-Lite are provided in the referenced RFCs. Security guidance for application usage is provided in the UDP Guidelines [RFC8085].
UDPおよびUDP-Liteの使用に関するセキュリティの考慮事項は、参照されているRFCで提供されています。アプリケーション使用のセキュリティガイダンスは、UDPガイドライン[RFC8085]で提供されています。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https://www.rfc-editor.org/info/ rfc1122>。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <https://www.rfc-editor.org/info/rfc3758>.
[RFC3758] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「Stream Control Transmission Protocol（SCTP）Partial Reliability Extension」、RFC 3758、DOI 10.17487 / RFC3758、May 2004、<https://www.rfc-editor.org/info/rfc3758>。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, <https://www.rfc-editor.org/info/rfc4895>.
[RFC4895] Tuexen、M.、Stewart、R.、Lei、P。、およびE. Rescorla、「Authenticated Chunks for the Stream Control Transmission Protocol（SCTP）」、RFC 4895、DOI 10.17487 / RFC4895、2007年8月、<https ：//www.rfc-editor.org/info/rfc4895>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, <https://www.rfc-editor.org/info/rfc5061>.
[RFC5061] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（SCTP）Dynamic Address Reconfiguration」、RFC 5061、DOI 10.17487 / RFC5061、9月2007、<https://www.rfc-editor.org/info/rfc5061>。
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, DOI 10.17487/RFC5482, March 2009, <https://www.rfc-editor.org/info/rfc5482>.
[RFC5482] Eggert、L。およびF. Gont、「TCPユーザータイムアウトオプション」、RFC 5482、DOI 10.17487 / RFC5482、2009年3月、<https://www.rfc-editor.org/info/rfc5482>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info / rfc5925>。
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, <https://www.rfc-editor.org/info/rfc6182>.
[RFC6182] Ford、A.、Raiciu、C.、Handley、M.、Barre、S.、J。Iyengar、「マルチパスTCP開発のアーキテクチャガイドライン」、RFC 6182、DOI 10.17487 / RFC6182、2011年3月、<https ：//www.rfc-editor.org/info/rfc6182>。
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011, <https://www.rfc-editor.org/info/rfc6458>.
[RFC6458] Stewart、R.、Tuexen、M.、Poon、K.、Lei、P。、およびV. Yasevich、「Socket Control Extensions for the Stream Control Transmission Protocol（SCTP）」、RFC 6458、DOI 10.17487 / RFC6458 、2011年12月、<https://www.rfc-editor.org/info/rfc6458>。
[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>.
[RFC6525] Stewart、R.、Tuexen、M。、およびP. Lei、「Stream Control Transmission Protocol（SCTP）Stream Reconfiguration」、RFC 6525、DOI 10.17487 / RFC6525、2012年2月、<https：//www.rfc- editor.org/info/rfc6525>。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<https：// www.rfc-editor.org/info/rfc6817>。
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <https://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスによるマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<https：// www.rfc-editor.org/info/rfc6824>。
[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, <https://www.rfc-editor.org/info/rfc6897>.
[RFC6897] Scharf、M。およびA. Ford、「マルチパスTCP（MPTCP）アプリケーションインターフェイスの考慮事項」、RFC 6897、DOI 10.17487 / RFC6897、2013年3月、<https://www.rfc-editor.org/info/rfc6897 >。
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <https://www.rfc-editor.org/info/rfc6951>.
[RFC6951] Tuexen、M。、およびR. Stewart、「エンドホストからエンドホストへの通信用のストリーム制御伝送プロトコル（SCTP）パケットのUDPカプセル化」、RFC 6951、DOI 10.17487 / RFC6951、2013年5月、<https：/ /www.rfc-editor.org/info/rfc6951>。
[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, <https://www.rfc-editor.org/info/rfc7053>.
[RFC7053] Tuexen、M.、Ruengeler、I。、およびR. Stewart、「SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol」、RFC 7053、DOI 10.17487 / RFC7053、2013年11月、<https：//www.rfc -editor.org/info/rfc7053>。
[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>.
[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S。、およびA. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：//www.rfc-editor .org / info / rfc7413>。
[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension", RFC 7496, DOI 10.17487/RFC7496, April 2015, <https://www.rfc-editor.org/info/rfc7496>.
[RFC7496] Tuexen、M.、Seggelmann、R.、Stewart、R。、およびS. Loreto、「Partially Reliable Stream Control Transmission Protocol Extensionの追加ポリシー」、RFC 7496、DOI 10.17487 / RFC7496、2015年4月、<https ：//www.rfc-editor.org/info/rfc7496>。
[RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. Nielsen, "SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol", RFC 7829, DOI 10.17487/RFC7829, April 2016, <https://www.rfc-editor.org/info/rfc7829>.
[RFC7829]ニシダY.、ナタラジャンP.、カロA.、アメルP.、およびK.ニールセン、「SCTP-PF：ストリーム制御伝送プロトコルのクイックフェイルオーバーアルゴリズム」、RFC 7829、DOI 10.17487 / RFC7829、2016年4月、<https://www.rfc-editor.org/info/rfc7829>。
[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>.
[RFC8085] Eggert、L.、Fairhurst、G。、およびG. Shepherd、「UDP使用ガイドライン」、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<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>.
[RFC8260] Stewart、R.、Tuexen、M.、Loreto、S。、およびR. Seggelmann、「Stream Scheduler and User Message Interleaving for the Stream Control Transmission Protocol」、RFC 8260、DOI 10.17487 / RFC8260、2017年11月、< https://www.rfc-editor.org/info/rfc8260>。
[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>.
[RFC8304]フェアハースト、G。およびT.ジョーンズ、「ユーザーデータグラムプロトコル（UDP）および軽量UDP（UDP-Lite）のトランスポート機能」、RFC 8304、DOI 10.17487 / RFC8304、2018年2月、<https：// www .rfc-editor.org / info / rfc8304>。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC0854] Postel、J。およびJ. Reynolds、「Telnet Protocol Specification」、STD 8、RFC 854、DOI 10.17487 / RFC0854、1983年5月、<https://www.rfc-editor.org/info/rfc854>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474]ニコルズ、K。、ブレイク、S。、ベイカー、F。、およびD.ブラック、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<https://www.rfc-editor.org/info/rfc2474>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<https://www.rfc-editor.org/info/rfc2475>。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, <https://www.rfc-editor.org/info/rfc3260>.
[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、DOI 10.17487 / RFC3260、2002年4月、<https://www.rfc-editor.org/info/rfc3260>。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI 10.17487/RFC5461, February 2009, <https://www.rfc-editor.org/info/rfc5461>.
[RFC5461] Gont、F。、「ソフトエラーに対するTCPの反応」、RFC 5461、DOI 10.17487 / RFC5461、2009年2月、<https://www.rfc-editor.org/info/rfc5461>。
[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, <https://www.rfc-editor.org/info/rfc6093>.
[RFC6093] Gont、F。およびA. Yourtchenko、「TCP緊急メカニズムの実装について」、RFC 6093、DOI 10.17487 / RFC6093、2011年1月、<https://www.rfc-editor.org/info/rfc6093 >。
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, <https://www.rfc-editor.org/info/rfc7414>.
[RFC7414]デューク、M。、ブレーデン、R。、エディ、W。、ブラントン、E。、およびA.ジマーマン、「A Transmission map for Transmission Control Protocol（TCP）Specification Documents」、RFC 7414、DOI 10.17487 / RFC7414、 2015年2月、<https://www.rfc-editor.org/info/rfc7414>。
[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>.
[RFC7657]ブラック、D。、エド。およびP.ジョーンズ、「Differentiated Services（Diffserv）and Real-Time Communication」、RFC 7657、DOI 10.17487 / RFC7657、2015年11月、<https://www.rfc-editor.org/info/rfc7657>。
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.
[RFC8095] Fairhurst、G。、編、Trammell、B。、編、およびM. Kuehlewind、編、「IETFトランスポートプロトコルおよび輻輳制御メカニズムによって提供されるサービス」、RFC 8095、DOI 10.17487 / RFC8095、2017年3月、<https://www.rfc-editor.org/info/rfc8095>。
[TAPS-MINSET] Welzl, M. and S. Gjessing, "A Minimal Set of Transport Services for TAPS Systems", Work in Progress, draft-ietf-taps-minset-01, February 2018.
[TAPS-MINSET] Welzl、M。、およびS. Gjessing、「TAPSシステムの最小限のトランスポートサービス」、作業中、draft-ietf-taps-minset-01、2018年2月。
TCP: [RFC0793], [RFC1122], [RFC5482], [RFC5925], and [RFC7413].
TCP：[RFC0793]、[RFC1122]、[RFC5482]、[RFC5925]、および[RFC7413]。
MPTCP: [RFC6182], [RFC6824], and [RFC6897].
MPTCP：[RFC6182]、[RFC6824]、および[RFC6897]。
SCTP: RFCs without a sockets API specification: [RFC3758], [RFC4895], [RFC4960], and [RFC5061].
SCTP：ソケットAPI仕様のないRFC：[RFC3758]、[RFC4895]、[RFC4960]、および[RFC5061]。
RFCs that include a sockets API specification: [RFC6458], [RFC6525], [RFC6951], [RFC7053], [RFC7496], and [RFC7829].
ソケットAPI仕様を含むRFC：[RFC6458]、[RFC6525]、[RFC6951]、[RFC7053]、[RFC7496]、および[RFC7829]。
UDP(-Lite): See [RFC8304].
UDP（-Lite）：[RFC8304]を参照してください。
LEDBAT: [RFC6817].
LEDBAT：[RFC6817]。
This section gives an overview of the method that was used to develop this document. It was given to contributors for guidance, and it can be helpful for future updates or extensions.
このセクションでは、このドキュメントの開発に使用された方法の概要を示します。これはガイダンスとして寄稿者に提供されたものであり、将来の更新や拡張に役立つ可能性があります。
This document is only concerned with transport features that are explicitly exposed to applications via primitives. It also strictly follows RFC text: if a transport feature is truly relevant for an application, the RFCs should say so, and they should describe how to use and configure it. Thus, the approach followed for developing this document was to identify the right RFCs, then analyze and process their text.
このドキュメントは、プリミティブを介してアプリケーションに明示的に公開されるトランスポート機能にのみ関係しています。また、厳密にRFCテキストに従います。トランスポート機能がアプリケーションに本当に関連している場合、RFCはそのように述べ、使用方法と構成方法を説明する必要があります。したがって、このドキュメントを作成するために採用されたアプローチは、適切なRFCを特定し、そのテキストを分析して処理することでした。
Primitives that "MAY" be implemented by a transport protocol were excluded. To be included, the minimum requirement level for a primitive to be implemented by a protocol was "SHOULD". Where style requirement levels as described in [RFC2119] are not used, primitives were excluded when they are described in conjunction with statements like, e.g., "some implementations also provide" or "an implementation may also". Excluded primitives or parameters were briefly described in a dedicated subsection.
トランスポートプロトコルによって「MAY」を実装できるプリミティブは除外されました。含まれるには、プロトコルによって実装されるプリミティブの最小要件レベルは「SHOULD」でした。 [RFC2119]で説明されているスタイル要件レベルが使用されていない場合、「一部の実装も提供する」または「実装も可能」などのステートメントと一緒に記述されるプリミティブは除外されました。除外されたプリミティブまたはパラメーターについては、専用のサブセクションで簡単に説明しました。
Pass 1: This began by identifying text that talks about primitives. An API specification, abstract or not, obviously describes primitives -- but we are not *only* interested in API specifications. The text describing the 'Send' primitive in the API specified in [RFC0793], for instance, does not say that data transfer is reliable. TCP's reliability is clear, however, from this text in Section 1 of [RFC0793]:
パス1：これは、プリミティブについて話すテキストを識別することから始まりました。 API仕様は、抽象であろうとなかろうと、明らかにプリミティブを記述しますが、API仕様にのみ関心があるわけではありません。たとえば、[RFC0793]で指定されているAPIの「送信」プリミティブを説明するテキストは、データ転送が信頼できるとは述べていません。ただし、TCPの信頼性は[RFC0793]のセクション1の次のテキストから明らかです。
The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks.
伝送制御プロトコル（TCP）は、パケット交換コンピュータ通信ネットワーク内のホスト間、およびそのようなネットワークの相互接続されたシステム内のホスト間の信頼性の高いホスト間プロトコルとして使用することを目的としています。
Some text for the pass 1 subsections was developed by copying and pasting all the relevant text parts from the relevant RFCs then adjusting the terminology to match that in Section 2 and shortening phrasing to match the general style of the document. An effort was made to formulate everything as a primitive description such that the primitive descriptions became as complete as possible (e.g., the 'SEND.TCP' primitive in pass 2 is explicitly described as reliably transferring data); text that is relevant for the primitives presented in this pass but still does not fit directly under any primitive was used in a subsection's introduction.
パス1のサブセクションの一部のテキストは、関連するRFCからすべての関連するテキスト部分をコピーして貼り付け、セクション2の用語と一致するように用語を調整し、文書の一般的なスタイルに一致するように句を短くすることによって開発されました。プリミティブ記述が可能な限り完全になるように、すべてをプリミティブ記述として定式化する努力が行われました（たとえば、パス2の「SEND.TCP」プリミティブは、確実にデータを転送すると明示されています）;このパスで提示されたプリミティブに関連するが、どのプリミティブにも直接適合しないテキストは、サブセクションの概要で使用されました。
Pass 2: The main goal of this pass is unification of primitives. As input, only text from pass 1 was used (no exterior sources). The list in pass 2 is not arranged by protocol (i.e., "first protocol X, here are all the primitives; then protocol Y, here are all the primitives, ...") but by primitive (i.e., "primitive A, implemented this way in protocol X, this way in protocol Y, ..."). It was a goal to obtain as many similar pass 2 primitives as possible. For instance, this was sometimes achieved by not always maintaining a 1:1 mapping between pass 1 and pass 2 primitives, renaming primitives, etc. For every new primitive, the already-existing primitives were considered to try to make them as coherent as possible.
パス2：このパスの主な目的は、プリミティブの統合です。入力として、パス1のテキストのみが使用されました（外部ソースはありません）。パス2のリストはプロトコル（つまり、「最初のプロトコルX、ここにすべてのプリミティブがあります。次にプロトコルY、ここにすべてのプリミティブがあります...」）ではなく、プリミティブ（つまり、「プリミティブA、実装済み」この方法でプロトコルX、この方法でプロトコルY、...」）。同様のパス2プリミティブをできるだけ多く取得することが目標でした。たとえば、これは、パス1プリミティブとパス2プリミティブの間の1：1マッピングを常に維持することではなく、プリミティブの名前を変更することによって達成された。 。
For each primitive, the following style was used:
プリミティブごとに、次のスタイルが使用されました。
o PRIMITIVENAME.PROTOCOL: Pass 1 primitive/event: Parameters: Returns: Comments:
o PRIMITIVENAME.PROTOCOL：1つのプリミティブ/イベントを渡します：パラメータ：戻り値：コメント：
The entries "Parameters", "Returns", and "Comments" were skipped when a primitive had no parameters, no described return value, or no comments seemed necessary, respectively. Optional parameters are followed by "(optional)". When known, default values were provided.
プリミティブにパラメーターがない場合、記述された戻り値がない場合、またはコメントが必要ないように見える場合、エントリー「パラメーター」、「戻り値」、および「コメント」はそれぞれスキップされました。オプションのパラメーターの後には「（オプション）」が続きます。既知の場合、デフォルト値が提供されました。
Pass 3: The main point of this pass is to identify transport features that are the result of static properties of protocols, for which all protocols have to be listed together; this is then the final list of all available transport features. This list was primarily based on text from pass 2, with additional input from pass 1 (but no external sources).
パス3：このパスの主なポイントは、プロトコルの静的プロパティの結果であるトランスポート機能を特定することです。これについて、すべてのプロトコルをまとめてリストする必要があります。これは、使用可能なすべてのトランスポート機能の最終的なリストです。このリストは主にパス2からのテキストに基づいており、パス1からの追加の入力があります（外部ソースはありません）。
Acknowledgements
謝辞
The authors would like to thank (in alphabetical order) Bob Briscoe, Spencer Dawkins, Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly, Joe Touch, and Brian Trammell for providing valuable feedback on this document. We especially thank Christoph Paasch for providing input related to Multipath TCP and Gorry Fairhurst and Tom Jones for providing input related to UDP(-Lite). This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT).
このドキュメントに関する貴重なフィードバックを提供してくれたBob Briscoe、Spencer Dawkins、Aaron Falk、David Hayes、Karen Nielsen、Tommy Pauly、Joe Touch、およびBrian Trammellに感謝します（アルファベット順）。マルチパスTCPに関連する入力を提供してくれたChristoph Paaschと、UDP（-Lite）に関連した入力を提供してくれたGorry FairhurstとTom Jonesに特に感謝します。この作品は、EUのHorizon 2020研究およびイノベーションプログラムから、助成金契約番号644334（NEAT）のもとで資金提供を受けています。
Authors' Addresses
著者のアドレス
Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
マイケルウェルズル大学オスロ私書箱1080ブリンデンオスロN-0316ノルウェー
Email: michawe@ifi.uio.no
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 Steinfurt 48565 Germany
Michael Tuexenミュンスター応用科学大学Stegerwaldstrasse 39シュタインフルト48565ドイツ
Email: tuexen@fh-muenster.de
Naeem Khademi University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
Naeem Khademi University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway
Email: naeemk@ifi.uio.no