One document matched: draft-ietf-taps-transports-usage-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.ietf.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!--<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
-->
<!-- http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml-->
<!ENTITY RFC0793 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC0854 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0854.xml">
<!ENTITY RFC1122 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3168 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3260 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3260.xml">
<!ENTITY RFC3758 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml">
<!ENTITY RFC3828 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3828.xml">
<!ENTITY RFC4895 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4895.xml">
<!ENTITY RFC4960 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC5061 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5061.xml">
<!ENTITY RFC5482 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5482.xml">
<!ENTITY RFC5461 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5461.xml">
<!ENTITY RFC6093 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6093.xml">
<!ENTITY RFC6182 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6182.xml">
<!ENTITY RFC6458 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6458.xml">
<!ENTITY RFC6525 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6525.xml">
<!ENTITY RFC6824 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6824.xml">
<!ENTITY RFC6897 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6897.xml">
<!ENTITY RFC6951 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6951.xml">
<!ENTITY RFC7053 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7053.xml">
<!ENTITY RFC7414 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7414.xml">
<!ENTITY RFC7657 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7657.xml">
<!ENTITY RFC7496 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7496.xml">
<!ENTITY RFC7829 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7829.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.draft-ietf-tsvwg-rfc5405bis SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tsvwg-rfc5405bis-07.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml2rfc.tools.ietf.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!-- do not keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<rfc category="info" docName="draft-ietf-taps-transports-usage-02"
ipr="trust200902">
<!-- noModificationTrust200902 noDerivativesTrust200902 pre5378Trust200902">-->
<!-- updates="6298"> -->
<!-- ipr="full3978"> -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<!-- <title abbrev="Abbreviated Title">Coupled congestion control</title> -->
<title abbrev="Transport Services">On the Usage of Transport Service Features Provided by IETF Transport Protocols</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Michael Welzl" initials="M." surname="Welzl">
<organization>University of Oslo</organization>
<address>
<postal>
<street>PO Box 1080 Blindern</street>
<!-- Reorder these if your country does things differently -->
<code>N-0316</code>
<city>Oslo</city>
<region></region>
<country>Norway</country>
</postal>
<phone>+47 22 85 24 20</phone>
<email>michawe@ifi.uio.no</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author initials="M." surname="Tuexen" fullname="Michael Tuexen">
<organization abbrev='Muenster Univ. of Appl. Sciences'>
Muenster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city> Steinfurt</city>
<country>Germany</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<author fullname="Naeem Khademi" initials="N." surname="Khademi">
<organization>University of Oslo</organization>
<address>
<postal>
<street>PO Box 1080 Blindern</street>
<!-- Reorder these if your country does things differently -->
<code>N-0316</code>
<city>Oslo</city>
<region></region>
<country>Norway</country>
</postal>
<email>naeemk@ifi.uio.no</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!-- <date day="06" month="June" year="2015" /> -->
<date year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>TAPS</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>taps, transport services</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document describes how transport protocols expose services
to applications and how an application can configure and use
the features of a transport service.</t>
</abstract>
</front>
<middle>
<section title="Terminology" anchor='sec-term'>
<!-- <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
-->
<t><list style="hanging">
<t hangText='Transport Service Feature:'>
a specific end-to-end feature that a transport service provides to its
clients. Examples include confidentiality, reliable delivery, ordered
delivery, message-versus-stream orientation, etc.</t>
<t hangText='Transport Service:'>
a set of transport service features, without an association to any given
framing protocol, which provides a complete service to an application.</t>
<t hangText='Transport Protocol:'>
an implementation that provides one or more different transport services
using a specific framing and header format on the wire.</t>
<t hangText='Transport Protocol Component:'>
an implementation of a transport service feature within a protocol.</t>
<t hangText='Transport Service Instance:'>
an arrangement of transport protocols with a selected set of features
and configuration parameters that implements a single transport service,
e.g., a protocol stack (RTP over UDP).</t>
<t hangText='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).</t>
<t hangText='Endpoint:'>
an entity that communicates with one or more other endpoints using
a transport protocol.</t>
<t hangText='Connection:'>
shared state of two or more endpoints that persists
across messages that are transmitted between these endpoints.</t>
<t hangText='Primitive:'>
a function call that is used to locally communicate between an application
and a transport endpoint and is related to one or more Transport Service Features.</t>
<t hangText='Parameter:'>
a value passed between an application and a transport protocol by a primitive.</t>
<t hangText='Socket:'>
the combination of a destination IP address and a destination port number.</t>
<t hangText='Transport Address:'>
the combination of an IP address, transport protocol and the port number used by the transport protocol.</t>
</list></t>
</section>
<section anchor="sec-intro" title="Introduction">
<t>This document presents defined interactions between transport
protocols and applications in the form of 'primitives'
(function calls). Primitives can be invoked
by an application or a transport protocol; the latter type
is called an "event".
The list of transport service features and primitives in this document
is strictly
based on the parts of protocol specifications
that relate to what the protocol provides
to an application using it and how the application interacts
with it.
<!--It is based on text that describes what a protocol provides to
the upper layer and how it is used (abstract API descriptions),
given for the base protocols in <xref target="RFC0793"/>,
<xref target="RFC1122"/> and <xref target="RFC4960"/>.
It does not cover API instances, for example the one
given for SCTP in <xref target="RFC6458"/>.
-->
It does not cover parts of a protocol that are explicitly
stated as optional to implement.</t>
<t>The document presents a three-pass process to arrive at a list
of transport service features. In the first pass, the relevant RFC
text is discussed per protocol. In the second pass, this discussion
is used to derive a list of primitives that are uniformly
categorized across protocols. Here, an attempt is made to present or -- where
text describing primitives does not yet exist -- construct primitives
in a slightly generalized form to highlight similarities. This is, for example,
achieved by renaming primitives of protocols or
by avoiding a strict 1:1-mapping between the primitives in the protocol specification
and primitives in the list. Finally, the third pass presents transport service
features based on pass 2, identifying which protocols implement them.</t>
<t> In the list resulting from the second pass, some transport service features
are missing because they are
implicit in some protocols, and they only become explicit when we
consider the superset of all features offered by all protocols. For
example, TCP's reliability includes integrity via a checksum, but we
have to include a protocol like UDP-Lite as specified in
<xref target="RFC3828"/> (which has a configurable checksum)
in the list before we can consider an
always-on checksum as a transport service feature. Similar arguments
apply to other protocol functions (e.g. congestion control).
The complete list of features across all protocols is therefore only
available after pass 3.</t>
<t>
This document discusses unicast
transport protocols. [AUTHOR'S NOTE: we skip "congestion control mechanisms"
for now. This simplifies the discussion; the congestion control
mechanisms part is about LEDBAT, which should be easy to add later.]
<!--The latter, to be usable, must be embedded in a transport protocol.-->
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 normally this multiplexing
is achieved using port numbers. Port multiplexing is therefore assumed to
be always provided and not discussed in this document.
</t>
<t>
Some protocols are connection-oriented. Connection-oriented
protocols often use an initial call to a specific transport primitive to
open a connection before communication can progress, and require
communication
to be explicitly terminated by issuing another call to a transport
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.
<!-- Congestion
control operates over a certain known time-scale, and can therefore be
expected to be implemented in a connection-oriented transport protocol.-->
</t>
</section>
<section anchor="pass1" title="Pass 1">
<t>
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).
</t>
<section anchor="tcp" title="Primitives Provided by TCP">
<t>
<xref target="RFC0793"/> states: "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".
<!--
<t>TCP therefore provides, as "always-on"
features:
</t>
<t>
<list style="symbols">
<t>reliability</t>
<t>connection-orientation</t>
</list>
</t>
-->
Section 3.8 in <xref target="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.
</t>
<t>
<list style="hanging">
<t hangText='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). <xref target="RFC1122"/> describes a procedure for aborting the connection
that must be used to avoid excessive retransmissions, and states that an application
must be able to control the threshold used to determine the condition for aborting -- and
that this threshold may be measured in time units or as a count of retransmission. This
indicates that the timeout could also be specified as a count of retransmission.
<vspace blankLines='1'/>
Also optional, for multihomed hosts, the local IP address can
be provided <xref target="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 is explained in <xref target="RFC1122"/> to allow
the application to specify IP options such as source route, record route, or timestamp.
It is not stated on which segments of a connection these options should be applied,
but probably all segments, as this is also stated in a specification given for
the usage of source route
(section 4.2.3.8 of <xref target="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.
<vspace blankLines='1'/>
</t>
<t hangText='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 PUSH flag, if set, requires data to be
promptly transmitted to the
receiver without delay. Conversely, not using PUSH can reduce
the number of unnecessary wakeup calls to the receiving application process.-->
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.
<!--<xref target="RFC1122"/> states that "Generally, an interactive application protocol must set
the PUSH flag at least in the last SEND call in each
primitive or response sequence. A bulk transfer protocol
like FTP should set the PUSH flag on the last segment
of a file or when necessary to prevent buffer deadlock."-->
An optional timeout parameter can be provided that updates
the connection's timeout (see 'open').
<vspace blankLines='1'/>
</t>
<t hangText='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.
<!-- as well as - optionally [RFC 1122] -
the status of the PUSH flag.
If enough data arrive to fill the buffer before a PUSH is seen,
the PUSH flag will not be set in the response to the RECEIVE.
The buffer will be filled with as much data as it can hold. If
a PUSH is seen before the buffer is filled the buffer will be
returned partially filled and PUSH indicated.
-->
<vspace blankLines='1'/>
</t>
<t hangText='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 also implies the push function.-->
<vspace blankLines='1'/>
</t>
<t hangText='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 <xref target="RFC0793"/>.
<vspace blankLines='1'/>
</t>
<t hangText='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 <xref target="RFC0793"/>, Section 3.5.
<vspace blankLines='1'/>
</t>
<t hangText='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 <xref target="RFC0793"/>, Section 3.4.
<vspace blankLines='1'/>
</t>
<t hangText='USER TIMEOUT event:'>
This event, described in Section 3.9 of <xref target="RFC0793"/>, is executed when the
user timeout expires (see 'open'). All queues are flushed and the application
is informed that the connection had to be aborted due to user timeout.
<vspace blankLines='1'/>
</t>
<t hangText='ERROR_REPORT event:'>
This event, described in Section 4.2.4.1 of <xref target="RFC1122"/>, informs the application
of "soft errors" that can be safely ignored <xref target="RFC5461"/>, including the arrival of an
ICMP error message or excessive retransmissions (reaching a threshold below
the threshold where the connection is aborted).
<vspace blankLines='1'/>
</t>
<!--
Commented because the text doesn't say that this immediately causes a signal to the app: it only says that data are handed over to RECEIVE buffers.
<t hangText='SEGMENT ARRIVES event:'>
This event, described in Section 3.9 of <xref target="RFC0793"/>, causes data to be delivered to
the buffers associated with the 'receive' primitive. Given the assumption that TCP is able to
asynchronously
signal the application when an event occurs, it is therefore reasonable to assume that the
reception of data is also signaled to the application.
<vspace blankLines='1'/>
</t>
-->
<t hangText='Type-of-Service:'>
Section 4.2.4.2 of <xref target="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. A part of the field has been assigned
to ECN <xref target="RFC3168"/> and the six most significant
bits have been assigned to carry the DiffServ CodePoint, DSField <xref target="RFC3260"/>. Staying with
the intention behind the application's ability to specify the "Type of Service",
this should probably be interpreted to mean the value in the DSField, which is
the Differentiated Services Codepoint (DSCP).<!-- [AUTHOR's NOTE: text trying to
"read between the lines" of RFCs here... this perhaps calls for an update
to <xref target="RFC1122"/>?] -->
<vspace blankLines='1'/>
</t>
<t hangText='Nagle:'>
The Nagle algorithm, described in Section 4.2.3.4 of <xref target="RFC1122"/>, delays sending data for some
time to increase the likelihood of
sending a full-sized segment.
An application can disable the Nagle algorithm for an individual connection.
<vspace blankLines='1'/>
</t>
<t hangText='User Timeout Option:'>
The User Timeout Option (UTO) <xref target="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'),
<xref target="RFC5482"/> introduces three per-connection state variables that an application can adjust to control the operation
of the User Timeout Option (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').
<vspace blankLines='1'/>
</t>
</list>
</t>
<section anchor="tcp-excluded" title="Excluded Primitives or Parameters">
<t>The 'open' primitive specified in <xref target="RFC0793"/> can be handed optional Precedence or security/compartment information
according to <xref target="RFC0793"/>, but this was not included here because it is mostly irrelevant today, as
explained in <xref target="RFC7414"/>.
<!-- The 'open' primitive also includes a parameter "options"
that is explained in <xref target="RFC1122"/> to let the application specify IP options such as
source route, record
route, or timestamp. This parameter was not included here because it is not clear
which segments of a connection (all?) these options would then be applied to. -->
</t>
<t>The 'status' primitive was not included because <xref target="RFC0793"/> describes this primitive
as "implementation
dependent" and states that it "could be
excluded without adverse effect". Moreover, while a data block containing specific
information is described, it is also stated
that not all of this information may always be available.
The 'send' primitive described in <xref target="RFC0793"/> includes an optional PUSH flag which,
if set, requires data to be promptly transmitted to the receiver without delay; the 'receive'
primitive described in <xref target="RFC0793"/> can (under some conditions)
yield the status of the PUSH flag.
Because PUSH functionality is made optional to implement for both the 'send' and 'receive' primitives in <xref target="RFC1122"/>,
this functionality is not included here.
<xref target="RFC1122"/> also introduces keep-alives to TCP, but
these are optional to implement and hence not considered here. <xref target="RFC1122"/> describes that "some TCP
implementations have included a FLUSH call", indicating that this call is also
optional to implement. It is therefore not considered here.
</t>
<!--
<t><xref target="RFC0793"/> does not describe some interactions with the application that
are initiated by the communicating peer, e.g. when the application on
the other side has issued commands to open, close or abort the connection;
a possible implementation could be to somehow notify the application of
these events. Another implementation could be to let commands
that try to use a
connection succeed or fail, and thereby implicitly inform the application
of the protocol state change.</t>
-->
</section>
<!-- <t>
TCP data transfers are congestion controlled [RFC 5681]. Message
boundaries are not visible in TCP communication, making ordered
data delivery a necessity for reliability. Reliability also includes
ensuring end-to-end data integrity via a checksum.
</t>
-->
</section>
<section anchor="mptcp" title="Primitives Provided by MPTCP">
<t>
Multipath TCP (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 in
<xref target="RFC6182"/> "Multipath TCP MUST follow the same service model as TCP <xref target="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."
</t>
<t>
Further, <xref target="RFC6182"/> states constraints on the API exposed by MPTCP: "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 merely by upgrading the operating systems of the end hosts."
As such, the primitives provided by MPTCP are equivalent to the ones provided by
TCP. Nevertheless, <xref target="RFC6824"/> and <xref target="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.
</t>
<t>
<list style="hanging">
<t hangText='open:'> <xref target="RFC6897"/> states "An application should be able to request to turn on or turn
off the usage of MPTCP.". The RFC states that this functionality can be provided
through a socket-option called TCP_MULTIPATH_ENABLE.
Further, <xref target="RFC6897"/> says that MPTCP must be disabled in case the application is
binding to a specific address.
<vspace blankLines='1'/>
</t>
<t hangText='send/receive:'>
<xref target="RFC6824"/> states that the sending and receiving of data does not require any
changes to the application when MPTCP is being used. 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."
The use of the Urgent-Pointer is special in MPTCP and <xref target="RFC6824"/> says
"a TCP subflow MUST NOT use the Urgent Pointer to interrupt an existing mapping."
<vspace blankLines='1'/>
</t>
<t hangText='address and subflow management:'>
MPTCP uses different addresses and allows a host to announce these addresses as
part of the protocol. <xref target="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.".
<vspace blankLines='1'/>
</t>
</list>
</t>
</section>
<section anchor="sctp" title="Primitives Provided by SCTP">
<t>
Section 1.1 of <xref target="RFC4960"/> lists limitations of TCP that SCTP
removes. Three of the four mentioned limitations directly translate
into a transport service features that are visible to an application using SCTP: 1) it allows
for preservation of message delineations;
2) these messages, while reliably transferred, do not require to be in
order unless the application wants it; 3) multi-homing is supported.
In SCTP, connections are called "association" and they can be between
not only two (as in TCP) but multiple addresses
at each endpoint.
<!-- For SCTP running
over IP, <xref target="RFC4960"/> defines a "transport address" as "the combination of an
IP address and an SCTP port number (where SCTP is the transport protocol)". -->
</t>
<t>
Section 10 of <xref target="RFC4960"/> further specifies the interaction with the application
(which RFC <xref target="RFC4960"/> 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 <xref target="RFC4960"/>,
an extension to the socket API is described in <xref target="RFC6458"/> covering the
functionality of the base protocol specified in <xref target="RFC4960"/> and its
extensions specified in <xref target="RFC3758"/>, <xref target="RFC4895"/>, and
<xref target="RFC5061"/>. For the protocol extensions specified in <xref target="RFC6525"/>,
<xref target="RFC6951"/>, <xref target="RFC7053"/>, <xref target="RFC7496"/>, and <xref target="RFC7829"/> the
corresponding extensions of the socket API are specified in these protocol specifications.
The functionality exposed to the ULP through this socket API is considered here in addition
to the abstract API specified in Section 10 of <xref target="RFC4960"/>.</t>
<t>
<list style="hanging">
<t hangText='Initialize:'> Initialize creates a local SCTP instance
that it binds to a set of local addresses (and, if provided, port number).
Initialize needs to be called only once per set of local addresses.
<!--, and it is valid until Destroy is called.-->
<vspace blankLines='1'/>
</t>
<t hangText='Associate:'> This creates an association (the SCTP equivalent of a
connection) between the local SCTP instance and a remote SCTP instance. 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 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 outgoing streams negotiated.
An optional parameter of 32-bits, the adaptation layer indication,
can be provided, as specified in <xref target="RFC5061"/>.
If the extension specified in <xref target="RFC4895"/> is used, the chunk types
required to be sent authenticated by the peer can be provided.
<vspace blankLines='1'/>
</t>
<t hangText='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 to control the partial reliability extension specified in
<xref target="RFC3758"/> and <xref target="RFC7496"/>.
An optional maximum life time 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 by making use of the I-bit specified in
<xref target="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). <!--The handling of this no-bundle flags is similar to the
sender side handling of the TCP PUSH flag.-->
A payload protocol-id can be provided to pass a value
that indicates the type of payload protocol data to the peer.
If the extension specified in <xref target="RFC4895"/> is used, the key identifier
used for authenticating the DATA chunks can be provided.
<vspace blankLines='1'/>
</t>
<t hangText='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.
A delivery number lets the application detect reordering.
<!-- Implementations also provide the ordered/unordered bit. -->
<vspace blankLines='1'/>
</t>
<t hangText='Shutdown:'> This primitive gracefully closes an association,
reliably delivering any data that has already been handed over to
SCTP. A return code informs about success or failure of this procedure.
<vspace blankLines='1'/>
</t>
<t hangText='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.
<vspace blankLines='1'/>
</t>
<t hangText='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.
<vspace blankLines='1'/>
</t>
<t hangText='Set Protocol Parameters:'> This allows to set values for protocol
parameters per association; for some parameters, a setting can be made per
socket. The set listed in <xref target="RFC4960"/> is: RTO.Initial; RTO.Min;
RTO.Max; Max.Burst; RTO.Alpha; RTO.Beta; Valid.Cookie.Life;
Association.Max.Retrans; Path.Max.Retrans; Max.Init.Retransmits;
HB.interval; HB.Max.Burst. In addition to these, the Quick Failover Algorithm
specified in <xref target="RFC7829"/> can be controlled by the
PotentiallyFailed.Max.Retrans and Primary.Switchover.Max.Retrans parameter.
A remote UDP encapsulation port can be set for using UDP encapsulation as
specified in <xref target="RFC6951"/>.
<vspace blankLines='1'/>
</t>
<t hangText='Set Primary:'> This allows 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.
<vspace blankLines='1'/>
</t>
<t hangText='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.
This is provided by the protocol extension defined in
<xref target="RFC4895"/>.
<vspace blankLines='1'/>
</t>
<t hangText='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 which
address to use as the primary address.
This is provided by the protocol extension defined in
<xref target="RFC5061"/>.
<vspace blankLines='1'/>
</t>
<t hangText='Add / Reset Streams, Reset Association:'>
This allows an endpoint to add streams to an existing association or
or to reset them individually. Additionally, the association can be
reset. This is provided by the protocol extension defined in
<xref target="RFC6525"/>.
<vspace blankLines='1'/>
</t>
<t hangText='Status:'> The 'Status'
primitive returns a data block with information about
a specified association, containing: association
connection state; socket list; destination transport
address reachability states; current receiver window size; current 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.
<vspace blankLines='1'/>
</t>
<t hangText='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).
<vspace blankLines='1'/>
</t>
<t hangText='DATA ARRIVE notification:'>
When a message is ready to be retrieved via the Receive primitive, the application
is informed by this notification.
<vspace blankLines='1'/>
</t>
<t hangText='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.
<vspace blankLines='1'/>
</t>
<t hangText='NETWORK STATUS CHANGE notification:'> The NETWORK
STATUS CHANGE notification informs the application about a socket
becoming active/inactive.
<vspace blankLines='1'/>
</t>
<t hangText='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).
<vspace blankLines='1'/>
</t>
<t hangText='SHUTDOWN COMPLETE notification:'>
When SCTP completes the shutdown procedures,
this notification is passed to the upper layer, informing it about
the affected assocation.
<vspace blankLines='1'/>
</t>
<t hangText='AUTHENICATION notification:'>
When SCTP wants to notify the upper layer regarding the key management
related to the extension defined in <xref target="RFC4895"/>,
this notification is passed to the upper layer.
<vspace blankLines='1'/>
</t>
<t hangText='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.
This extension is defined in <xref target="RFC5061"/> and <xref target="RFC6458"/>.
<vspace blankLines='1'/>
</t>
<t hangText='STREAM RESET notification:'>
When SCTP completes the procedure for resetting streams as specified in
<xref target="RFC6525"/>, this notification is passed to the upper layer,
informing it about the result.
<vspace blankLines='1'/>
</t>
<t hangText='ASSOCIATION RESET notification:'>
When SCTP completes the association reset procedure as specified in
<xref target="RFC6525"/>, this notification is passed to the upper layer,
informing it about the result.
<vspace blankLines='1'/>
</t>
<t hangText='STREAM CHANGE notification:'>
When SCTP completes the procedure used to increase the number of streams
as specified in <xref target="RFC6525"/>, this notification is passed to
the upper layer, informing it about the result.
<vspace blankLines='1'/>
</t>
</list>
</t>
<section anchor="sctp-excluded" title="Excluded Primitives or Parameters">
<t> <!-- MICHAEL: We're skipping this discussion for now, but still need to
clarify how the source address is decided.
For the 'Set Primary' primitive, an optional possibility to specify the
source SCTP transport address to be used in outgoing IP datagrams is described, but
the RFC text says "some implementations may allow you to", indicating that
implementing this in SCTP is optional. This functionality is therefore not
considered here.-->
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. Similarly, 'Set Failure Threshold' sets only one out of various
possible parameters included in 'Set Protocol Parameters'. 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 Service Feature.</t>
</section>
</section>
<section anchor="udp-udplite" title="Primitives Provided by UDP and UDP-Lite">
<t>
The primitives provided by UDP and UDP-Lite are described in <xref target="FJ16"/>.
</t>
</section>
</section>
<section anchor="pass2" title="Pass 2">
<t>
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 (as of now).
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).
</t>
<t>
Some minor details are omitted for the sake of generalization -- e.g.,
SCTP's 'close' <xref target="RFC4960"/> returns success or failure,
whereas this is not described in the same way for TCP in <xref target="RFC0793"/>, but
this detail plays no significant role for the primitives provided
by either TCP or SCTP.</t>
<t> The TCP 'send' and 'receive' primitives include usage of an "URGENT" mechanism.
This mechanism is required to implement the "synch signal" used by telnet <xref target="RFC0854"/>, but
SHOULD NOT be used by new applications <xref target="RFC6093"/>. Because pass 2 is meant as a basis
for the creation of TAPS systems, the "URGENT" mechanism is excluded.
This also concerns the notification "Urgent pointer advance" in the ERROR_REPORT
described in Section 4.2.4.1 of <xref target="RFC1122"/>.
</t>
<section anchor="conn" title="CONNECTION Related Primitives">
<t>ESTABLISHMENT:<vspace />
Active creation of a connection from one transport endpoint to one or
more transport endpoints.<vspace />Interfaces to
UDP and UDP-Lite allow both connection-oriented and connection-less
usage of the API <xref target="I-D.ietf-tsvwg-rfc5405bis"></xref><vspace blankLines='1' />
<list style="symbols">
<t>CONNECT.TCP: <vspace />
Pass 1 primitive / event: 'open' (active) or 'open' (passive) with socket,
followed by 'send'<vspace />
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) <vspace />
Comments: If the local IP address is not provided, a default choice will
automatically be made.
<!-- [AUTHOR'S NOTE: <xref target="RFC1122"/> does not clearly state
this, but it seems to be the implication of some text there.] -->
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.<vspace />
<vspace />
<vspace blankLines='1'/>
</t>
<t>CONNECT.SCTP: <vspace />
Pass 1 primitive / event: 'initialize', followed by 'associate'<vspace />
Parameters: list of local SCTP port number / IP address pairs (initialize); 1 socket;
outbound stream count; adaptation layer indication; chunk types required to be authenticated<vspace />
Returns: socket list <vspace />
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.<vspace />
<vspace blankLines='1'/>
</t>
<t>CONNECT.MPTCP: <vspace />
This is similar to CONNECT.TCP except for one additional boolean parameter
that allows to enable or disable MPTCP for a particular connection or socket
(default: enabled).<vspace />
<vspace blankLines='1'/>
</t>
<t>CONNECT.UDP(-Lite): <vspace />
Pass 1 primitive / event: 'connect' followed by 'send'.<vspace />
Parameters: 1 local IP address
(default (ANY), or specified); 1 destination transport address; 1
local port (default (OS chooses), or specified); 1 destination
port (default (OS chooses), or specified).<vspace />
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. <vspace
blankLines="1" /></t>
</list></t>
<t>AVAILABILITY:<vspace />
Preparing to receive incoming connection requests.<vspace blankLines='1' />
<list style="symbols">
<t>LISTEN.TCP: <vspace />
Pass 1 primitive / event: 'open' (passive)<vspace />
Parameters: 1 local IP address (optional); 1 socket (optional); timeout (optional) <vspace />
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'.<vspace />
<vspace blankLines='1'/>
</t>
<t>LISTEN.SCTP: <vspace />
Pass 1 primitive / event: 'initialize', followed by 'COMMUNICATION UP' notification and possibly
'ADAPTATION LAYER' notification<vspace />
Parameters: list of local SCTP port number / IP address pairs (initialize)<vspace />
Returns: socket list; outbound stream count;
inbound stream count; adaptation layer indication; chunks required to be authenticated<vspace />
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.<vspace />
<vspace blankLines='1'/>
</t>
<t>LISTEN.MPTCP: <vspace />
This is similar to LISTEN.TCP except for one additional boolean parameter
that allows to enable or disable MPTCP for a particular connection or socket
(default: enabled).<vspace />
<vspace blankLines='1'/>
</t>
<t>LISTEN.UDP(-Lite): <vspace />
Pass 1 primitive / event: 'receive'. <vspace />
Parameters: 1 local IP address (default (ANY), or specified); 1
destination transport address; local port (default (OS chooses),
or specified); destination port (default (OS chooses), or
specified).<vspace />
Comments: The receive function registers the
application to listen for incoming UDP(-Lite) datagrams at an endpoint.<vspace />
<vspace blankLines="1" />
</t>
</list></t>
<t>MAINTENANCE:<vspace />
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.
<vspace blankLines='1' />
<list style="symbols">
<t>CHANGE-TIMEOUT.TCP: <vspace />
Pass 1 primitive / event: 'open' or 'send' combined with unspecified control of per-connection state variables<vspace />
Parameters: timeout value (optional); ADV_UTO (optional); boolean UTO_ENABLED (optional, default false); boolean CHANGEABLE (optional, default true) <vspace />
Comments: when sending data, an application can adjust the connection's timeout
value (time after
which the connection will be aborted if data could not be delivered).
If UTO_ENABLED is true, the user 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 'timeout value' is used.<vspace />
<vspace blankLines='1'/>
</t>
<t>CHANGE-TIMEOUT.SCTP: <vspace />
Pass 1 primitive / event: 'Change HeartBeat' combined with 'Set Protocol Parameters'<vspace />
Parameters: 'Change HeartBeat': heartbeat frequency; 'Set Protocol Parameters': Association.Max.Retrans (whole association) or Path.Max.Retrans
(per socket) <vspace />
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 heartbeats the connection will be terminated; thus these
two primitives / parameters together can yield a similar behavior to
CHANGE-TIMEOUT.TCP.<vspace />
<vspace blankLines='1'/>
</t>
<t>DISABLE-NAGLE.TCP: <vspace />
Pass 1 primitive / event: not specified<vspace />
Parameters: one boolean value <vspace />
Comments: the Nagle algorithm delays data transmission to increase the
chance to send a full-sized segment. An application must be able to
disable this algorithm for a connection.<vspace />
<vspace blankLines='1'/>
</t>
<t>REQUESTHEARTBEAT.SCTP: <vspace />
Pass 1 primitive / event: 'Request HeartBeat'<vspace />
Parameters: socket<vspace />
Returns: success or failure<vspace />
Comments: requests an immediate heartbeat on a path,
returning success or failure.<vspace />
<vspace blankLines='1'/>
</t>
<t>SETPROTOCOLPARAMETERS.SCTP: <vspace />
Pass 1 primitive / event: 'Set Protocol Parameters'<vspace />
Parameters: RTO.Initial; RTO.Min;
RTO.Max; Max.Burst; RTO.Alpha; RTO.Beta; Valid.Cookie.Life;
Association.Max.Retrans; Path.Max.Retrans; Max.Init.Retransmits;
HB.interval; HB.Max.Burst; PotentiallyFailed.Max.Retrans;
Primary.Switchover.Max.Retrans; Remote.UDPEncapsPort.<vspace />
<vspace blankLines='1'/>
</t>
<t>SETPRIMARY.SCTP: <vspace />
Pass 1 primitive / event: 'Set Primary'<vspace />
Parameters: socket<vspace />
Returns: result of attempting this operation<vspace />
Comments: update the current primary address to be used, based on
the set of available sockets of the association.<vspace />
<vspace blankLines='1'/>
</t>
<t>SETPEERPRIMARY.SCTP: <vspace />
Pass 1 primitive / event: Change Local Address / Set Peer Primary<vspace />
Parameters: local IP address<vspace />
Comments: this is only advisory for the peer.<vspace />
<vspace blankLines='1'/>
</t>
<t>SETAUTH.SCTP: <vspace />
Pass 1 primitive / event: Set / Get Authentication Parameters<vspace />
Parameters: key_id, key, hmac_id<vspace />
<vspace blankLines='1'/>
</t>
<t>GETAUTH.SCTP: <vspace />
Pass 1 primitive / event: Set / Get Authentication Parameters<vspace />
Parameters: key_id, chunk_list<vspace />
<vspace blankLines='1'/>
</t>
<t>RESETSTREAM.SCTP: <vspace />
Pass 1 primitive / event: Add / Reset Streams, Reset Association<vspace />
Parameters: sid, direction<vspace />
<vspace blankLines='1'/>
</t>
<t>RESETSTREAM-EVENT.SCTP: <vspace />
Pass 1 primitive / event: STREAM RESET notification<vspace />
Parameters: information about the result of RESETSTREAM.SCTP.<vspace />
Comments: This is issued when the procedure for resetting streams has completed.<vspace />
<vspace blankLines='1'/>
</t>
<t>RESETASSOC.SCTP: <vspace />
Pass 1 primitive / event: Add / Reset Streams, Reset Association<vspace />
Parameters: information related to the extension defined in <xref target="RFC3260"/>.<vspace />
<vspace blankLines='1'/>
</t>
<t>RESETASSOC-EVENT.SCTP: <vspace />
Pass 1 primitive / event: ASSOCIATION RESET notification<vspace />
Parameters: information about the result of RESETASSOC.SCTP.<vspace />
Comments: This is issued when the procedure for resetting an association has completed.<vspace />
<vspace blankLines='1'/>
</t>
<t>ADDSTREAM.SCTP: <vspace />
Pass 1 primitive / event: Add / Reset Streams, Reset Association<vspace />
Parameters: number if outgoing and incoming streams to be added<vspace />
<vspace blankLines='1'/>
</t>
<t>ADDSTREAM-EVENT.SCTP: <vspace />
Pass 1 primitive / event: STREAM CHANGE notification<vspace />
Parameters: information about the result of ADDSTREAM.SCTP.<vspace />
Comments: This is issued when the procedure for adding a stream has completed.<vspace />
<vspace blankLines='1'/>
</t>
<t>ERROR.TCP: <vspace />
Pass 1 primitive / event: 'ERROR_REPORT'<vspace />
Returns: reason (encoding not specified); subreason (encoding not specified) <vspace />
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; Excessive Retransmissions.
<!-- Urgent pointer advance.-->
<vspace />
<vspace blankLines='1'/>
</t>
<t>ERROR.UDP(-Lite): <vspace />
Pass 1 primitive / event: 'ERROR_REPORT'.<vspace />
Returns: Error report<vspace />
Comments: This returns soft errors that may be ignored
without harm by many applications; An application must connect to
be able receive these notifications.<vspace />
<vspace blankLines="1" />
</t>
<t>STATUS.SCTP: <vspace />
Pass 1 primitive / event: 'Status' and 'NETWORK STATUS CHANGE' notification<vspace />
Returns: data block with information about
a specified association, containing: association
connection state; socket list; destination transport
address reachability states; current receiver window size; current 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. The
NETWORK STATUS CHANGE notification informs the application about
a socket becoming active/inactive.<vspace />
<vspace blankLines='1'/>
</t>
<t>STATUS.MPTCP: <vspace />
Pass 1 primitive / event: not specified<vspace />
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.<vspace />
<vspace blankLines='1'/>
</t>
<t>SET_DSCP.TCP: <vspace />
Pass 1 primitive / event: not specified<vspace />
Parameters: DSCP value <vspace />
Comments: this allows an application to change the DSCP value for outgoing segments.
For TCP this was
originally specified for the TOS field <xref target="RFC1122"/>, which is here interpreted
to refer to the DSField <xref target="RFC3260"/>.<vspace />
<vspace blankLines='1'/>
</t>
<t>SET_DSCP.UDP(-Lite):<vspace />
Pass 1 primitive / event: 'SET_DSCP'<vspace />
Parameter: DSCP value <vspace />
Comments: This allows an application to change the
DSCP value for outgoing UDP(-Lite) datagrams. <xref
target="RFC7657"></xref> and <xref
target="I-D.ietf-tsvwg-rfc5405bis"></xref> provide current
guidance on using this value with UDP.<vspace />
<vspace blankLines="1" />
</t>
<t>ADD_SUBFLOW.MPTCP: <vspace />
Pass 1 primitive / event: not specified<vspace />
Parameters: local IP address and optionally the local port number<vspace />
Comments: the application specifies the local IP address and port number
that must be used for a new subflow.<vspace />
<vspace blankLines='1'/>
</t>
<t>ADD_ADDR.SCTP: <vspace />
Pass 1 primitive / event: Change Local Address / Set Peer Primary<vspace />
Parameters: local IP address<vspace />
<vspace blankLines='1'/>
</t>
<t>REM_SUBFLOW.MPTCP: <vspace />
Pass 1 primitive / event: not specified<vspace />
Parameters: local IP address, local port number, remote IP address, remote port number<vspace />
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.<vspace />
<vspace blankLines='1'/>
</t>
<t>REM_ADDR.SCTP: <vspace />
Pass 1 primitive / event: Change Local Address / Set Peer Primary<vspace />
Parameters: local IP address<vspace />
<vspace blankLines='1'/>
</t>
<t>CHECKSUM.UDP: <vspace />
Pass 1 primitive / event: 'DISABLE_CHECKSUM'.<vspace />
Parameters: 0 when no checksum is used at sender, 1 for
checksum at sender (default).<vspace />
<vspace blankLines="1" />
</t>
<t>CHECKSUM_REQUIRED.UDP: <vspace />
Pass 1 primitive / event: 'REQUIRE_CHECKSUM'.<vspace />
Parameter: 0 when checksum is required at receiver, 1 to
allow zero checksum at receiver (default).<vspace />
<vspace blankLines="1" />
</t>
<t>SET_CHECKSUM_COVERAGE.UDP-Lite:<vspace />
Pass 1 primitive / event: 'SET_CHECKSUM_COVERAGE'.<vspace />
Parameters: Coverage length at sender (default maximum
coverage)<vspace />
<vspace blankLines="1" />
</t>
<t>SET_MIN_CHECKSUM_COVERAGE.UDP-Lite:<vspace />
Pass 1 primitive / event: 'SET_MIN_COVERAGE'.<vspace />
Parameter: Coverage length at receiver (default minimum coverage)<vspace />
<vspace blankLines="1" />
</t>
<t>SET_DF.UDP(-Lite):<vspace />
Pass 1 primitive event: 'SET_DF'.<vspace />
Parameter: 0 when DF is not set (default), 1 when DF is set.<vspace />
<vspace blankLines="1" />
</t>
<t>SET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):<vspace />
Pass 1 primitive / event: 'SET_TTL' and 'SET_IPV6_UNICAST_HOPS' <vspace />
Parameters: IPv4 TTL value or IPv6 Hop Count value <vspace />
Comments: This allows an
application to change the IPv4 TTL of IPv6 Hop count value for
outgoing UDP(-Lite) datagrams.<vspace />
<vspace blankLines="1" />
</t>
<t>GET_TTL.UDP(-Lite) (IPV6_UNICAST_HOPS):<vspace />
Pass 1 primitive / event: 'GET_TTL' and 'GET_IPV6_UNICAST_HOPS' <vspace />
Returns: IPv4 TTL value or IPv6 Hop Count value <vspace />
Comments: This allows an
application to read the the IPv4 TTL of IPv6 Hop count value from a
received UDP(-Lite) datagram.<vspace />
<vspace blankLines="1" />
</t>
<t>SET_ECN.UDP(-Lite):<vspace />
Pass 1 primitive / event: 'SET_ECN' <vspace />
Parameters: ECN value<vspace />
Comments: This allows a UDP(-Lite) application to set the ECN
codepoint field for outgoing UDP(-Lite) datagrams.<vspace />
<vspace blankLines="1" />
</t>
<t>GET_ECN.UDP(-Lite):<vspace />
Pass 1 primitive / event: 'GET_ECN' <vspace />
Parameters: ECN value<vspace />
Comments: This allows a UDP(-Lite) application to read the ECN
codepoint field from a received UDP(-Lite) datagram.<vspace />
<vspace blankLines="1" />
</t>
<t>SET_IP_OPTIONS.UDP(-Lite):<vspace />
Pass 1 primitive / event: 'SET_IP_OPTIONS' <vspace />
Parameters: options<vspace />
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 Time Stamp option.<vspace />
<vspace blankLines="1" />
</t>
<t>GET_IP_OPTIONS.UDP(-Lite):<vspace />
Pass 1 primitive / event: 'GET_IP_OPTIONS' <vspace />
Returns: options<vspace />
Comments: This allows a UDP(-Lite) application to receive any
IP options that are contained in a received UDP(-Lite) datagram.<vspace />
<vspace blankLines="1" />
</t>
<t>AUTHENTICATION_NOTIFICATION-EVENT.SCTP: <vspace />
Pass 1 primitive / event: 'AUTHENTICATION notification'<vspace />
Returns: information regarding key management.<vspace />
<vspace blankLines='1'/>
</t>
</list></t>
<t>TERMINATION:<vspace />
Gracefully or forcefully closing a connection, or being informed
about this event happening.<vspace blankLines='1' />
<list style="symbols">
<t>CLOSE.TCP: <vspace />
Pass 1 primitive / event: 'close'<vspace />
Comments: this terminates the sending side of a connection after reliably delivering all
remaining data. <!--Close also implies the push function (see DATA.SEND.TCP).--><vspace />
<vspace blankLines='1'/>
</t>
<t>CLOSE.SCTP: <vspace />
Pass 1 primitive / event: 'Shutdown'<vspace />
Comments: this terminates a connection after reliably delivering all
remaining data.<vspace />
<vspace blankLines='1'/>
</t>
<t>CLOSE.UDP(-Lite):<vspace />
Pass 1 primitive event: 'CLOSE' <vspace />
Comments: No further UDP(-Lite) datagrams are sent/received on this connection.<vspace />
<vspace blankLines="1" />
</t>
<t>ABORT.TCP: <vspace />
Pass 1 primitive / event: 'abort'<vspace />
Comments: this terminates a connection without delivering remaining
data and sends an error message to the other side.<vspace />
<vspace blankLines='1'/>
</t>
<t>ABORT.SCTP: <vspace />
Pass 1 primitive / event: 'abort'<vspace />
Parameters: abort reason to be given to the peer (optional)<vspace />
Comments: this terminates a connection without delivering remaining
data and sends an error message to the other side.<vspace />
<vspace blankLines='1'/>
</t>
<t>TIMEOUT.TCP: <vspace />
Pass 1 primitive / event: 'USER TIMEOUT' event<vspace />
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).
<vspace />
<vspace blankLines='1'/>
</t>
<t>TIMEOUT.SCTP: <vspace />
Pass 1 primitive / event: 'COMMUNICATION LOST' event<vspace />
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 beginning of section 8.3 in <xref target="RFC4960"/>)
and was possibly adjusted in
CONNECTION.MAINTENANCE.CHANGE-TIMEOOUT.SCTP.<vspace />
<vspace blankLines='1'/>
</t>
<t>ABORT-EVENT.TCP: <vspace />
Pass 1 primitive / event: not specified.<vspace />
<vspace blankLines='1'/>
</t>
<t>ABORT-EVENT.SCTP: <vspace />
Pass 1 primitive / event: 'COMMUNICATION LOST' event<vspace />
Returns: abort reason from the peer (if available)<vspace />
Comments: the application is informed that the other side has
aborted the connection using CONNECTION.TERMINATION.ABORT.SCTP.<vspace />
<vspace blankLines='1'/>
</t>
<t>CLOSE-EVENT.TCP: <vspace />
Pass 1 primitive / event: not specified.<vspace />
<vspace blankLines='1'/>
</t>
<t>CLOSE-EVENT.SCTP: <vspace />
Pass 1 primitive / event: 'SHUTDOWN COMPLETE' event<vspace />
Comments: the application is informed that
CONNECTION.TERMINATION.CLOSE.SCTP was successfully completed.<vspace />
<vspace blankLines='1'/>
</t>
</list></t>
</section>
<section anchor="data" title="DATA Transfer Related Primitives">
<t>
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.
</t>
<t>
<list style="symbols">
<t>SEND.TCP: <vspace />
Pass 1 primitive / event: 'send'<vspace />
Parameters: timeout (optional)<vspace />
<!--PUSH flag (optional);-->
Comments:
<!-- If the push flag is
set, the data block should promptly
be transmitted to the receiver without waiting.-->
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 whenever data are sent (see also
CONNECTION.MAINTENANCE.CHANGE-TIMEOUT.TCP).<vspace />
<vspace blankLines='1'/>
</t>
<t>SEND.SCTP: <vspace />
Pass 1 primitive / event: 'Send'<vspace />
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); key-id (optional)<vspace />
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.
<!-- (this is related to CONNECTION.MAINTENANCE.DISABLE-NAGLE.TCP). -->
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.<vspace />
<vspace blankLines='1'/>
</t>
<t>SEND.UDP(-Lite): <vspace />
Pass 1 primitive / event: 'SEND'<vspace />
Parameters: IP Address and Port Number of the
destination endpoint (optional if connected). <vspace />
Comments:
This provides a message for unreliable transmission using UDP(-Lite) to
the specified transport address. IP address and Port may be
omitted for connected UDP(-Lite) sockets. All CONNECTION.MAINTENANCE.SET_*.UDP(-Lite)
primitives apply per message sent.<vspace />
<vspace blankLines="1" />
</t>
<t>RECEIVE.TCP: <vspace />
Pass 1 primitive / event: 'receive'.<vspace />
<vspace blankLines='1'/>
</t>
<t>RECEIVE.SCTP: <vspace />
Pass 1 primitive / event: 'DATA ARRIVE' notification, followed by 'Receive'<vspace />
Parameters: stream number (optional)<vspace />
Returns: stream sequence number (optional), partial flag (optional)<vspace />
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. Additionally, a delivery number lets the
application detect reordering.<vspace />
<vspace blankLines='1'/>
</t>
<t>RECEIVE.UDP(-Lite): <vspace />
Pass 1 primitive / event: 'RECEIVE', <vspace />
Parameters: Buffer for received datagram.<vspace />
Comments: All CONNECTION.MAINTENANCE.GET_*.UDP(-Lite)
primitives apply per message received. <vspace />
<vspace blankLines="1" />
</t>
<t>SENDFAILURE-EVENT.SCTP: <vspace />
Pass 1 primitive / event: 'SEND FAILURE' notification, optionally followed by
'Receive Unsent Message' or 'Receive Unacknowledged Message'<vspace />
Returns: cause code; context; unsent or unacknowledged message (optional) <vspace />
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 complete unsent or
unacknowledged message if desired.<vspace />
<vspace blankLines='1'/>
</t>
<t>SEND_FAILURE.UDP(-Lite): <vspace />
Pass 1 primitive / event: 'SEND'<vspace />
Comment: This may be used to probe
for the effective PMTU when using in combination with the 'MAINTENANCE.SET_DF'
primitive.<vspace />
<vspace blankLines="1" />
</t>
</list></t>
</section>
</section>
<section anchor="pass3" title="Pass 3">
<t>
This section presents the superset of all transport service 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 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
feature "Specify IP Options".
</t>
<section anchor="conn-pass3" title="CONNECTION Related Transport Service Features">
<t>ESTABLISHMENT:<vspace />
Active creation of a connection from one transport endpoint to one or
more transport endpoints.<vspace blankLines='1' />
<list style="symbols">
<t>Connect<vspace />
Protocols: TCP, SCTP, UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify which IP Options must always be used<vspace />
Protocols: TCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Request multiple streams<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Obtain multiple sockets<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Disable MPTCP<vspace />
Protocols: MPTCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify which chunk types must always be authenticated<vspace />
Protocols: SCTP<vspace />
Comments: DATA, ACK etc. are different 'chunks' in SCTP; one or more chunks may be included in a single packet.
<vspace blankLines='1'/>
</t>
<t>Indicate an Adaptation Layer (via an adaptation code point)<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
</list></t>
<t>AVAILABILITY:<vspace />
Preparing to receive incoming connection requests.<vspace blankLines='1' />
<list style="symbols">
<t>Listen, 1 specified local interface<vspace />
Protocols: TCP, SCTP, UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Listen, N specified local interfaces<vspace />
Protocols: SCTP, UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Listen, all local interfaces<vspace />
Protocols: TCP, SCTP, UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Obtain requested number of streams<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify which IP Options must always be used<vspace />
Protocols: TCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Disable MPTCP<vspace />
Protocols: MPTCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify which chunk types must always be authenticated<vspace />
Protocols: SCTP<vspace />
Comments: DATA, ACK etc. are different 'chunks' in SCTP; one or more chunks may be included in a single packet.
<vspace blankLines='1'/>
</t>
<t>Indicate an Adaptation Layer (via an adaptation code point)<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
</list></t>
<t>MAINTENANCE:<vspace />
Adjustments made to an open connection, or notifications about
it. NOTE: all features except "set primary path" in this category
apply to one out of multiple possible paths (identified via sockets)
in SCTP, whereas TCP uses only one path (one socket).
<vspace blankLines='1' />
<list style="symbols">
<t>Change timeout for aborting connection (using retransmit limit or time value)<vspace />
Protocols: TCP, SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Control advertising timeout for aborting connection to remote endpoint<vspace />
Protocols: TCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Disable Nagle algorithm<vspace />
Protocols: TCP, SCTP<vspace />
Comments: This is not specified in <xref target="RFC4960"/> but in <xref target="RFC6458"/>.<vspace />
<vspace blankLines='1'/>
</t>
<t>Request an immediate heartbeat, returning success/failure<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Set protocol parameters<vspace />
Protocols: SCTP<vspace />
SCTP parameters: RTO.Initial; RTO.Min;
RTO.Max; Max.Burst; RTO.Alpha; RTO.Beta; Valid.Cookie.Life;
Association.Max.Retrans; Path.Max.Retrans; Max.Init.Retransmits;
HB.interval; HB.Max.Burst; PotentiallyFailed.Max.Retrans;
Primary.Switchover.Max.Retrans; Remote.UDPEncapsPort<vspace />
Comments: as transport layer features from other protocols are added,
it might make sense to separate out some of these parameters -- e.g.,
if a different protocol
provides means to adjust the RTO calculation there could be
a common feature for them called "adjust RTO calculation".<vspace />
<vspace blankLines='1'/>
</t>
<t>Notification of Excessive Retransmissions (early warning below abortion threshold)<vspace />
Protocols: TCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Notification of ICMP error message arrival<vspace />
Protocols: TCP, UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Obtain status (query or notification)<vspace />
Protocols: SCTP, MPTCP<vspace />
SCTP parameters: association
connection state; socket list; socket reachability states;
current receiver window size; current 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;
socket becoming active / inactive<vspace />
MPTCP parameters: subflow-list (identified by source-IP; source-Port; destination-IP; destination-Port)<vspace />
<vspace blankLines='1'/>
</t>
<t>Change authentication parameters<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Obtain authentication information<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Set primary path<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Reset Stream<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Notification of Stream Reset<vspace />
Protocols: STCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Reset Association<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Notification of Association Reset<vspace />
Protocols: STCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Add Streams<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Notification of Added Stream<vspace />
Protocols: STCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Set peer primary path<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify DSCP field<vspace />
Protocols: TCP, SCTP, UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Add subflow<vspace />
Protocols: MPTCP<vspace />
MPTCP Parameters: source-IP; source-Port; destination-IP; destination-Port<vspace />
<vspace blankLines='1'/>
</t>
<t>Remove subflow<vspace />
Protocols: MPTCP<vspace />
MPTCP Parameters: source-IP; source-Port; destination-IP; destination-Port<vspace />
<vspace blankLines='1'/>
</t>
<t>Add local address<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Remove local address<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Disable checksum when sending<vspace />
Protocols: UDP<vspace />
<vspace blankLines='1'/>
</t>
<t>Disable checksum requirement when receiving<vspace />
Protocols: UDP<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify checksum coverage used by the sender<vspace />
Protocols: UDP-Lite<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify minimum checksum coverage required by receiver<vspace />
Protocols: UDP-Lite<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify DF field <vspace />
Protocols: UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify TTL/Hop count field<vspace />
Protocols: UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Obtain TTL/Hop count field<vspace />
Protocols: UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify ECN field<vspace />
Protocols: UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Obtain ECN field<vspace />
Protocols: UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Specify IP Options<vspace />
Protocols: UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Obtain IP Options<vspace />
Protocols: UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
</list></t>
<t>TERMINATION:<vspace />
Gracefully or forcefully closing a connection, or being informed
about this event happening.<vspace blankLines='1' />
<list style="symbols">
<t>Close after reliably delivering all remaining data, causing an event informing the application on the other side<vspace />
Protocols: TCP, SCTP<vspace />
Comments: A TCP endpoint locally only closes the connection for sending; it may still receive data afterwards.
<vspace blankLines='1'/>
</t>
<t>Abort without delivering remaining data, causing an event informing the application on the other side<vspace />
Protocols: TCP, SCTP<vspace />
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.<vspace />
<vspace blankLines='1'/>
</t>
<t>Timeout event when data could not be delivered for too long<vspace />
Protocols: TCP, SCTP<vspace />
Comments: the timeout is configured with CONNECTION.MAINTENANCE
"Change timeout for aborting connection (using retransmit limit or time value)".<vspace />
<vspace blankLines='1'/>
</t>
</list></t>
</section>
<section anchor="data-pass3" title="DATA Transfer Related Transport Service Features">
<t>
All features in this section refer to an existing connection, i.e. a
connection that was either established or made available for receiving data.
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.
</t>
<section anchor="data-sending-pass3" title="Sending Data">
<t>
All features in this section are provided by DATA.SEND from pass 2.
DATA.SEND is given a data block from the application, which we here call a "message" if the beginning
and end of the data block can be identified at the receiver, and "data" otherwise.
</t>
<t><list style="symbols">
<t>Reliably transfer data, with congestion control<vspace />
Protocols: TCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Reliably transfer a message, with congestion control<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Unreliably transfer a message, with congestion control<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Unreliably transfer a message, without congestion control<vspace />
Protocols: UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Configurable Message Reliability<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Choice of stream<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Choice of path (destination address)<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Choice between unordered (potentially faster) or ordered delivery of messages<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Request not to bundle messages<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Specifying a "payload protocol-id" (handed over as such by the receiver)<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Specifying a key id to be used to authenticate a message<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Request not to delay the acknowledgement (SACK) of a message<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
</list></t>
</section>
<section anchor="data-receiving-pass3" title="Receiving Data">
<t>
All features in this section are provided by DATA.RECEIVE from pass 2.
DATA.RECEIVE fills a buffer provided by the application, with what we here call a "message" if the beginning
and end of the data block can be identified at the receiver, and "data" otherwise.
</t>
<t>
<list style="symbols">
<t>Receive data<vspace />
Protocols: TCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Receive a message<vspace />
Protocols: SCTP, UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Choice of stream to receive from<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Information about partial message arrival<vspace />
Protocols: SCTP<vspace />
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.<vspace />
<vspace blankLines='1'/>
</t>
<t>Obtain a message delivery number<vspace />
Protocols: SCTP<vspace />
Comments: This number can let applications detect and, if desired, correct
reordering.<vspace />
<vspace blankLines='1'/>
</t>
</list>
</t>
</section>
<section anchor="data-errors-pass3" title="Errors">
<t>
This section describes sending failures that are associated with a specific call to DATA.SEND
from pass 2.
</t>
<t>
<list style="symbols">
<t>Notification of unsent messages<vspace />
Protocols: SCTP, UDP(-Lite)<vspace />
<vspace blankLines='1'/>
</t>
<t>Notification of unacknowledged messages<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank (in alphabetical order) Bob Briscoe, Gorry Fairhurst, David Hayes, Tom Jones, Karen Nielsen and Joe Touch for providing valuable feedback on this document. We especially thank to Christoph Paasch for providing input related to Multipath TCP.
This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). The views expressed are solely those of the author(s).</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>XX RFC ED - PLEASE REMOVE THIS SECTION XXX</t>
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security will be considered in future versions of this document.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC0793;
&RFC1122;
&RFC4960;
&RFC5482;
&I-D.draft-ietf-tsvwg-rfc5405bis;
</references>
<references title="Informative References">
&RFC2119;
&RFC0854;
&RFC3168;
&RFC3260;
&RFC3828;
&RFC3758;
&RFC4895;
&RFC5061;
&RFC5461;
&RFC6093;
&RFC6182;
&RFC6458;
&RFC6525;
&RFC6824;
&RFC6897;
&RFC6951;
&RFC7053;
&RFC7829;
&RFC7414;
&RFC7496;
&RFC7657;
<reference anchor="FA16" target="">
<front>
<title>Services provided by IETF transport protocols and congestion control mechanisms</title>
<author initials="G." surname="Fairhurst, Ed." fullname="G. Fairhurst, Ed."></author>
<author initials="B." surname="Trammell, Ed." fullname="B. Trammell, Ed."></author>
<author initials="M." surname="Kuehlewind, Ed." fullname="M. Kuehlewind, Ed."></author>
<date month="October" year="2016"/>
</front>
<seriesInfo name="Internet-draft" value="draft-ietf-taps-transports-12.txt"/>
</reference>
<reference anchor="FJ16" target="">
<front>
<title>Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite) Transport Protocols</title>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst"></author>
<author initials="T." surname="Jones" fullname="T. Jones"></author>
<date month="October" year="2016"/>
</front>
<seriesInfo name="Internet-draft" value="draft-fairhurst-taps-transports-usage-udp-03"/>
</reference>
</references>
<section anchor="sec-rfcs" title="Overview of RFCs used as input for pass 1">
<t><list style="hanging">
<t hangText='TCP:'>
<xref target="RFC0793"/>, <xref target="RFC1122"/>, <xref target="RFC5482"/>
</t>
<t hangText='MPTCP:'>
<xref target="RFC6182"/>, <xref target="RFC6824"/>, <xref target="RFC6897"/>
</t>
<t hangText='SCTP:'>
RFCs without a socket API specification:
<xref target="RFC3758"/>,
<xref target="RFC4895"/>,
<xref target="RFC4960"/>,
<xref target="RFC5061"/>.
RFCs that include a socket API specification:
<xref target="RFC6458"/>,
<xref target="RFC6525"/>,
<xref target="RFC6951"/>,
<xref target="RFC7053"/>,
<xref target="RFC7496"/>
<xref target="RFC7829"/>.
</t>
<t hangText='UDP(-Lite):'>
See <xref target="FJ16"/>
</t>
</list></t>
</section>
<section anchor="sec-howto" title="How to contribute">
<t>
This document is only concerned with transport service features that are
explicitly exposed to applications via primitives.
It also strictly follows RFC text:
if a feature is truly relevant for an application, the RFCs better
say so and in some way describe how to use and configure it.
Thus, the approach to follow for contributing to this document
is to identify the right RFCs, then analyze and process their text.
</t>
<t>
Experimental RFCs are excluded, and so are primitives that MAY be
implemented (by the transport protocol). To be included, the minimum
requirement level for a primitive to be implemented by a protocol is
SHOULD. If <xref target="RFC2119"/>-style requirements levels are not used, primitives
should be excluded when they are described in conjunction with statements
like, e.g.: "some implementations also provide"
or "an implementation may also". Briefly describe excluded primitives
in a subsection called "excluded primitives".
</t>
<t>
Pass 1: Identify text that talks about primitives.
An API specification, abstract or not, obviously describes primitives --
but note that we are not *only*
interested in API specifications. The text describing the 'send'
primitive in the API specified in <xref target="RFC0793"/>, for instance, does not say
that data transfer is reliable. TCP's reliability is clear, however,
from this text in Section 1 of <xref target="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."
</t>
<t>
For the new pass 1 subsection about the protocol you're describing, it is
recommendable to begin by copy+pasting all the relevant text parts from the
relevant RFCs, then adjust terminology to match the terminology in
<xref target="sec-term"/> and adjust (shorten!) phrasing to match the general
style of the document. Try to formulate everything as a primitive description
to make the primitive description as complete as possible (e.g., the "SEND.TCP"
primitive in pass 2 is explicitly described as reliably transferring data);
if there is text that is relevant for the primitives presented in this pass
but still does not fit directly under any primitive, use it as an introduction
for your subsection. However, do note that document length is a concern and
all the protocols and their services / features are already described in
<xref target="FA16"/>.
</t>
<t>
Pass 2: The main goal of this pass is unification of primitives.
As input, use your own text from Pass 1, no exterior sources.
If you find that something is missing there, fix the text in Pass 1.
The list in pass 2 is not done by protocol ("first protocol X, here
are all the primitives; then protocol Y, here are all the primitives, ..")
but by primitive ("primitive A, implemented this way in protocol X, this way
in protocol Y, ..."). We want as
many similar pass 2 primitives as possible. This can be achieved, for instance,
by not always maintaining a 1:1 mapping between pass 1 and pass 2 primitives,
renaming primitives etc. Please consider the primitives that are already there
and try to make the ones of the protocol you are describing as much in line
with the already existing ones as possible. In other words, we would rather
have a primitive with new parameters than a new primitive that
allows to send in a particular way.
</t>
<t>
Please make primitives fit within the already existing categories and subcategories.
For each primitive, please follow the style:<vspace blankLines='1'/>
<list style="symbols">
<t>PRIMITIVENAME.PROTOCOL: <vspace />
Pass 1 primitive / event:<vspace />
Parameters:<vspace />
Returns:<vspace />
Comments:<vspace />
<vspace blankLines='1'/>
</t>
</list>
The entries "Parameters", "Returns" and "Comments" may be skipped if
a primitive has no parameters, no described return value or no comments
seem necessary, respectively. Optional parameters must be followed by "(optional)".
If a default value is known, provide it too.
</t>
<t>
Pass 3: the main point of this pass is to identify 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 features.
For this, we need a list of features per category (similar categories as in
pass 2) along with the protocol supporting it. This should be primarily
based on text from pass 2 as input, but text from pass 1 can also be used.
Do not use external sources.
</t>
</section>
<section title="Revision information">
<t> XXX RFC-Ed please remove this section prior to publication.</t>
<t>-00 (from draft-welzl-taps-transports): this now covers TCP based on all TCP RFCs
(this means: if you know of something in any TCP RFC that you think
should be addressed, please speak up!) as well as SCTP, exclusively based on <xref target="RFC4960"/>.
We decided to also incorporate <xref target="RFC6458"/> for SCTP, but this hasn't
happened yet. Terminology made in line with <xref target="FA16"/>. Addressed comments
by Karen Nielsen and Gorry Fairhurst; various other fixes. Appendices (TCP overview and
how-to-contribute) added.</t>
<t>-01: this now also covers MPTCP based on <xref target="RFC6182"/>, <xref target="RFC6824"/> and <xref target="RFC6897"/>.</t>
<t>-02: included UDP, UDP-Lite, and all extensions of SCTPs. This includes fixing the <xref target="RFC6458"/> omission from -00.
</t>
<t>TODO: security considerations (see review in ML);
the "how to contribute" section (which, at some point, should be updated to reflect how the
document WAS created, not how it SHOULD BE created) still says "Experimental RFCs are excluded". This
is wrong, and accordingly, Experimental RFCs must also be considered - thus, TFO (are there more
Experimental ones for TCP?). Also, include LEDBAT.
SCTP: DSCP and SCTP_NODELAY (equivalent to Nagle) are missing in pass 1 and 2. Are we missing
more (DF, TTL, ..)? What about e.g. "notification of
ICMP error message arrival"? Also consider draft-ietf-tsvwg-sctp-ndata.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:43:15 |