One document matched: draft-welzl-taps-transports-00.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.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
-->
<!-- http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml-->
<!ENTITY RFC0793 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC1122 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3168 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3260 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3260.xml">
<!ENTITY RFC3828 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3828.xml">
<!ENTITY RFC4960 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC6093 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6093.xml">
<!ENTITY RFC6458 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6458.xml">
<!ENTITY RFC7414 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7414.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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.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-welzl-taps-transports-00"
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">An Approach to Identify Services Provided by IETF Transport Protocols and Congestion Control Mechanisms</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="2015" />
<!-- 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 a method to identify services in
transport protocols and congestion control mechanisms. It shows the approach
using TCP and SCTP (base protocol)
as examples.</t>
</abstract>
</front>
<middle>
<!-- <section title="Definitions" anchor='sec-def'>
<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" hangIndent="6">
<t hangText="Wha'ever:">
<vspace />
Wha'ever is short for Whatever.</t>
</list></t>
</section>
-->
<section anchor="sec-intro" title="Introduction">
<t>This document considers every form of defined interaction between a transport
protocol and its user ("upper layer protocol" or "application") as
a "service". Here, the term "service" is NOT the same as the
term used to specify the entire "above transport" protocol that maps to
a port number or service name (which is another common meaning of the
term "service" in the context of transport protocols).</t>
<t>The list of services in this document is strictly
based on the parts of relevant 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 also does not cover parts of the 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 protocol services. 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 services that are uniformly
categorized across protocols. Here, an attempt is made to present services
in a slightly generalized form to highlight similarities. This is, for example,
achieved by renaming "commands" (or "transport primitives") of protocols or
by avoiding a strict 1:1-mapping between these commands
and services in the list. Finally, the third pass presents all services
from pass 2, identifying which protocol implements them.</t>
<t> In the list resulting from the second pass, some services
are missing because they are
implicit in some protocols, and they only become explicit when we
consider the superset of all services 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 to consider an
always-on checksum as a service (it would not be a service if
no protocol would allow to disable / configure the checksum). Similar arguments
apply to other protocol functions (e.g. congestion control).
The complete list of services across all protocols is therefore only
available after pass 3.</t>
</section>
<section anchor="general" title="General Considerations">
<t>
This document discusses unicast [AUTHOR'S NOTE: for simplicity, for now.
Hopefully forever, for simplicity.]
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 is 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 such
communication between the same IP addresses, and normally such multiplexing
is achieved using port numbers. Port multiplexing is therefore assumed to
be always provided and not discussed as a service.
</t>
<t>
Some protocols are connection-oriented. Connection-orientation, to the
user of an application, means that there is state shared
between the endpoints that persists across messages. Connection-oriented
protocols often use an initial call to
"open" a connection before communication can progress, and require
communication
to be explicitly terminated by issuing a "close" call. Moreover, a
"connection" is the common state that some transport primitives refer to,
e.g. to adjust general configuration settings. Connections establishment,
maintenance
and termination are therefore used to categorize certain services of
connection-oriented transport protocols in pass 2 and 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>
In this first iteration, the relevant text parts of the RFCs describing the
protocols are summarized, focusing on what a protocol provides to the upper
layer and how it is used (abstract API descriptions).
The resulting text is somewhat heterogeneous
in terminology - e.g. the user of the protocol is called "Application"
in TCP and "Upper-Layer Protocol (ULP)" in SCTP, and TCP's "user commands"
are called "ULP primitives" in SCTP.</t>
<section anchor="tcp" title="Services Provided by TCP">
<t>
<xref target="RFC0793"/> states: "TCP is a connection-oriented, end-to-end reliable protocol (..)".
<!--
<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 user commands. It is also assumed that the
Operating System provides a
means for TCP to asynchronously signal the user program. Here, we describe the relevant
user commands and notifications to the application.
</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 commands are associated with a specific connection, which
is assumed to first have been opened.
An active open call contains a fully specified foreign
socket (IP address + port number). A passive open call with a fully specified foreign socket waits
for a particular connection; alternatively, a passive open call can leave the foreign
socket unspecified to accept any incoming connection. A fully specified passive
call can later be made active
by executing 'send'. Optionally, a timeout can be specified, after which TCP will abort
the connection if data is not 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 let
the application 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"/>). As the only non-optional IP option
in this parameter, an application can specify a source route when it actively opens
a TCP connection.
<vspace blankLines='1'/>
</t>
<t hangText='send:'>
this command hands over a provided 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 delaying it. 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 should be indicated to the receiving
process as such.-->
<xref target="RFC1122"/> states that "Generally, an interactive application protocol must set
the PUSH flag at least in the last SEND call in each
command 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 command 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.
<!-- 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 command 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 handed over to
TCP (and if that fails, 'close' becomes 'abort'). Close also implies push function.
<vspace blankLines='1'/>
</t>
<t hangText='abort:'>
This command causes all pending SENDs and RECEIVES to be
aborted, the TCB to be removed, and a special RESET message to
be sent to the TCP on the other side of the connection.
See <xref target="RFC0793"/>.
<vspace blankLines='1'/>
</t>
<t hangText='close event:'>
TCP will signal a user, even if no
RECEIVEs are outstanding, that the other side has closed, so the user
can terminate his/her side 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 user
is signaled "error: connection 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, 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>
<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, parts
of the TOS field have been assigned to ECN <xref target="RFC3168"/> and the six most significant
bits have been assigned to DiffServ by the name of 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:'>
An application can disable the Nagle algorithm on an individual connection.
This algorithm delays sending data for some time to increase the likelihood of
sending a full-sized segment.
<vspace blankLines='1'/>
</t>
</list>
</t>
<section anchor="tcp-excluded" title="Excluded Services">
<t> The 'send' and 'receive' commands include usage of an "URGENT" mechanism, which
SHOULD NOT be implemented according to <xref target="RFC6093"/> and is therefore not described here.
This also concerns the notification "Urgent pointer advance" in the ERROR_REPORT
described in Section 4.2.4.1 of <xref target="RFC1122"/>.
</t>
<t>The 'open' command specified in <xref target="RFC0793"/> can be handed optional Precedence or security/compartment information
according to <xref target="RFC0793"/>, but this was not incuded here because it is mostly irrelevant today, as
explained in <xref target="RFC7414"/>.
The 'open' command 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' command was not included because <xref target="RFC0793"/> calls this command "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 'receive' command can (under some conditions) yield the status of the PUSH
flag according to <xref target="RFC0793"/>, but this TCP functionality is made optional
in <xref target="RFC1122"/> and hence not considered here. Generally, section 4.2.2.2
of <xref target="RFC1122"/>
says that PUSH on send calls MAY be implemented, which could be a reason not to consider
it here. However, the text then explains that "an interactive application protocol must set
the PUSH flag at least in the last SEND call in each command or response sequence", and
most implementations provide some option to cause a behavior that is in some way similar
to PUSH. Therefore PUSH is described as a part of SEND here.
<xref target="RFC1122"/> also introduces keep-alives to TCP, but
these are optional and hence not considered here. <xref target="RFC1122"/> describes that "some TCP
implementations have included a FLUSH call", indicating that this call is
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="sctp" title="Services 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 service that is 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 transport addresses
at each end point. 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 user program.
Here, we describe the relevant ULP primitives and notifications
to the ULP process:</t>
<t>
<list style="hanging">
<t hangText='Initialize:'> Initialize creates a local SCTP instance
which 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 transport addresses
from the returned destination addresses 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 ULP 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.
<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).
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 destination transport address, and the message can be delivered
out-of-order if the unordered flag is set. Another advisory flag indicates
the ULP's preference 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.
<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 ULP 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 ULP.
<!-- Implementations also prove 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 ULP.
A return code informs about success or failure of this procedure.
<vspace blankLines='1'/>
</t>
<t hangText='Change Heartbeat / Request Heartbeat:'> This allows the ULP
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
transport address. 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.
<vspace blankLines='1'/>
</t>
<t hangText='Set Primary:'> This allows to set a new primary default path for
an association by providing a transport address. Optionally, a default source
address to be used in IP datagrams can be provided.
<vspace blankLines='1'/>
</t>
<t hangText='Status:'> The 'Status'
primitive returns a data block with information about
a specified association, containing: association
connection state; destination transport address 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 ULP process about the affected association, the type of
event that has occurred, the complete set of transport addresses 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 ULP
process 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 ULP about a transport address
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 ULP 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>
</list>
</t>
<section anchor="sctp-excluded" title="Excluded Services">
<t> For the 'Set Primary' primitive, an optional possibility to specify the
source 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 also return certain additional
information, but this is also left up to the implementation and therefore
not considered. With a COMMUNICATION LOST notification, some more information
may optionally be passed to the ULP (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 what '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' primitive was excluded: it erases the SCTP instance that was created
by 'Initialize', but this does not translate into a service for the ULP.</t>
</section>
</section>
</section>
<section anchor="pass2" title="Pass 2">
<t>
Here we categorize the services from pass 1 based on whether they
relate to a connection or to data transmission. Services are presented
following the nomenclature
"CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL". We present "connection"
as a general protocol-independent concept and use it to refer to both
TCP's connections (which are identifiable by a unique socket pair, where
a socket is defined as an IP address and TCP port) and SCTP's associations
(which are identifiable by multiple IP address and port number pairs).
We define the
"transport address" as "the combination of an IP address and a transport
protocol's port number". The "application" is the user of the protocol
(called "Upper-Level Protocol (ULP)" in SCTP).</t>
<t>
Some minor details are omitted for the sake of generalization -- e.g., for
SCTP's 'close', <xref target="RFC4960"/> states that success or failure is returned,
whereas this is not described in the same way for TCP in <xref target="RFC0793"/>, but
this detail plays no significant role for the service provided
by either TCP or SCTP.</t>
<section anchor="conn" title="CONNECTION Related Services">
<t>ESTABLISHMENT:<vspace />
Active creation of a connection from one transport address to one or
more transport addresses.<vspace blankLines='1' />
<list style="symbols">
<t>CONNECT.TCP: <vspace />
Command / event: 'open' (active) or 'open' (passive) with destination transport
address, followed by 'send'<vspace />
Parameters: 1 local IP address (optional); 1 destination transport
address (for active open; else the destination transport address 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 />
Command / event: 'initialize', followed by 'associate'<vspace />
Parameters: list of local transport addresses (initialize); 1 destination
transport address; outbound stream count<vspace />
Returns: destination transport address list <vspace />
Comments: 'initialize' needs to be called only once per local transport address
list. One destination transport address will automatically be chosen; it
can later be changed in MAINTENANCE.<vspace />
<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 />
Command / event: 'open' (passive)<vspace />
Parameters: 1 local IP address (optional); 1 destination transport
address (optional); timeout (optional) <vspace />
Comments: if the transport address 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
restraint(s). ESTABLISHMENT can later be done with 'send'.<vspace />
<vspace blankLines='1'/>
</t>
<t>LISTEN.SCTP: <vspace />
Command / event: 'initialize', followed by 'COMMUNICATION UP' notification<vspace />
Parameters: list of local transport addresses (initialize)<vspace />
Returns: destination transport address list; outbound stream count;
inbound stream count<vspace />
Comments: initialize needs to be called only once per local transport address
list. COMMUNICATION UP can also follow a COMMUNICATION LOST notification,
indicating that the lost communication is restored.<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 when new data are handed over for sending).
<vspace blankLines='1' />
<list style="symbols">
<t>CHANGE-TIMEOUT.TCP: <vspace />
Command / event: 'send'<vspace />
Parameters: timeout value <vspace />
Comments: when sending data, the connection's timeout value (time after
which the connection will be aborted if data cannot be delivered) can
be adjusted.<vspace />
<vspace blankLines='1'/>
</t>
<t>CHANGE-TIMEOUT.SCTP: <vspace />
Command / 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 transport address) <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 commands / parameters together can yield a similar behavior to
CHANGE-TIMEOUT.TCP.<vspace />
<vspace blankLines='1'/>
</t>
<t>DISABLE-NAGLE.TCP: <vspace />
Command / 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. This is related to the no-bundle
flag in DATA.SEND.SCTP.<vspace />
<vspace blankLines='1'/>
</t>
<t>REQUESTHEARTBEAT.SCTP: <vspace />
Command / event: 'Request HeartBeat'<vspace />
Parameters: destination transport address<vspace />
Returns: success or failure<vspace />
Comments: requests a heartbeat to be immediately carried out on a path,
returning success or failure.<vspace />
<vspace blankLines='1'/>
</t>
<t>SETPROTOCOLPARAMETERS.SCTP: <vspace />
Command / 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<vspace />
<vspace blankLines='1'/>
</t>
<t>SETPRIMARY.SCTP: <vspace />
Command / event: 'Set Primary'<vspace />
Parameters: destination transport address<vspace />
Returns: result of attempting this operation<vspace />
Comments: update the current primary address to be used, based on
the set of available destination transport addresses of the association.<vspace />
<vspace blankLines='1'/>
</t>
<t>ERROR.TCP: <vspace />
Command / 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: Excessive Retransmissions and ICMP error
message arrived.<vspace />
<vspace blankLines='1'/>
</t>
<t>STATUS.SCTP: <vspace />
Command / event: 'Status' and 'NETWORK STATUS CHANGE' notification<vspace />
Returns: data block with information about
a specified association, containing: association
connection state; destination transport address 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 transport address becoming active/inactive.<vspace />
<vspace blankLines='1'/>
</t>
<t>CHANGE-DSCP.TCP: <vspace />
Command / event: not specified<vspace />
Parameters: DSCP value <vspace />
Comments: This allows an application to change the DSCP value. It was
only specified for the TOS field in <xref target="RFC1122"/>, which is here interpreted
to refer to the DSField as per <xref target="RFC3260"/>.<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 />
Command / event: 'close'<vspace />
Comments: this terminates the sending side of a connection after reliably delivering all
remaining data. Close also implies push function (see DATA.SEND.TCP).<vspace />
<vspace blankLines='1'/>
</t>
<t>CLOSE.SCTP: <vspace />
Command / event: 'Shutdown'<vspace />
Comments: this terminates a connection after reliably delivering all
remaining data.<vspace />
<vspace blankLines='1'/>
</t>
<t>ABORT.TCP: <vspace />
Command / 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 />
Command / 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 />
Command / event: 'USER TIMEOUT' event<vspace />
Comments: the application is informed that the connection is
aborted. This event is executed when the timeout set in
CONNECTION.ESTABLISHMENT.CONNECT.TCP (and possibly adjusted in
CONNECTION.MAINTENANCE.CHANGE-TIMEOOUT.TCP) expires.
<vspace />
<vspace blankLines='1'/>
</t>
<t>TIMEOUT.SCTP: <vspace />
Command / event: 'COMMUNICATION LOST' event<vspace />
Comments: the application is informed that the connection is
aborted. this event is executed when 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 expires.<vspace />
<vspace blankLines='1'/>
</t>
<t>ABORT-EVENT.TCP: <vspace />
Command / event: not specified<vspace />
<vspace blankLines='1'/>
</t>
<t>ABORT-EVENT.SCTP: <vspace />
Command / 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 />
Command / event: not specified<vspace />
<vspace blankLines='1'/>
</t>
<t>CLOSE-EVENT.SCTP: <vspace />
Command / 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 Services">
<t>
All commands in this section refer to an existing connection, i.e. a
connection that was either established or made available for receiving data.
In addition to the listed parameters, all sending commands contain a
reference to a data block and all receiving commands contain a reference
to available buffer space for the data.
</t>
<t>
<list style="symbols">
<t>SEND.TCP: <vspace />
Command / event: 'send'<vspace />
Parameters: PUSH flag (optional); timeout (optional)<vspace />
Comments: If the push flag is
set, the data block should promptly
be transmitted to the receiver without waiting. 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 />
Command / event: 'Send'<vspace />
Parameters: stream number; context (optional); life time (optional);
destination transport address (optional); unordered flag (optional);
no-bundle flag (optional); payload protocol-id (optional) <vspace />
Comments: 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 'life time' specifies a time after which this
data block will not be sent. The 'destination transport address' 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 it was provided,
be handed over to the receiving application.<vspace />
<vspace blankLines='1'/>
</t>
<t>RECEIVE.TCP: <vspace />
Command / event: 'receive'<vspace />
<vspace blankLines='1'/>
</t>
<t>RECEIVE.SCTP: <vspace />
Command / 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 an entire message consists of.<vspace />
<vspace blankLines='1'/>
</t>
<t>SENDFAILURE-EVENT.SCTP: <vspace />
Command / 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 commands can be used to retrieve the complete unsent or
unacknowledged message if desired.<vspace />
<vspace blankLines='1'/>
</t>
</list></t>
</section>
</section>
<section anchor="pass3" title="Pass 3">
<t>
Here we present the superset of all services in all protocols, based on the list in
pass 2 but also on text in pass 1 to include services
that can be configured in one protocol and are static properties in another.
Again, some minor details are omitted for the sake of generalization -- e.g., TCP
may provide various different IP options but only supporting source route is
mandatory to implement, and this detail is no longer visible in "Specify IP Options".
The detail was removed because no other protocols provide this features.
[AUTHOR'S NOTE: and if we find another one that does, we need that detail
again.]</t>
<t>
[AUTHOR'S NOTE: the list here looks pretty similar to the list in pass 2 for now.
This will change as more protocols are added. For example, if we add UDP, we will
find that UDP does not do congestion control, which is relevant to the application
using it. This will have to be reflected in pass 1 and pass 2, only for UDP.
In pass 3, we can derive "congestion control" as a service of TCP and SCTP
because it probably does not make much sense to write that only UDP provides
a congestion control related service: the "service" of not doing it -- meaning
that it may require more work from the application developer.]
</t>
<section anchor="conn-pass3" title="CONNECTION Related Services">
<t>ESTABLISHMENT:<vspace />
Active creation of a connection from one transport address to one or
more transport addresses.<vspace blankLines='1' />
<list style="symbols">
<t>Specify IP Options<vspace />
Protocols: TCP<vspace />
<vspace blankLines='1'/>
</t>
<t>Request multiple streams<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Obtain multiple destination transport addresses<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<vspace />
<vspace blankLines='1'/>
</t>
<t>Listen, N specified local interfaces<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Listen, all local interfaces (unspecified)<vspace />
Protocols: TCP, SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Obtain requested number of streams<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 services except "set primary path" in this category
apply to one out of multiple possible paths (identified via destination
transport addresses) in SCTP, whereas TCP uses only one path (one destination
transport address).<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>Disable Nagle algorithm<vspace />
Protocols: TCP<vspace />
Comments: This is available in SCTP implementations, but not specified in <xref target="RFC4960"/>.<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<vspace />
Comments: in future versions of this document, it might make sense to
split out some of these parameters -- e.g., if a different protocol
provides means to adjust the RTO calculation there could be
a common service 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<vspace />
<vspace blankLines='1'/>
</t>
<t>Status (query or notification)<vspace />
Protocols: SCTP<vspace />
SCTP parameters: association
connection state; destination transport address 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;
transport address becoming active / inactive<vspace />
<vspace blankLines='1'/>
</t>
<t>Set primary path<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Change DSCP<vspace />
Protocols: TCP<vspace />
Comments: This is described to be changeable for SCTP too in <xref target="RFC6458"/>.<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: TCP's 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 Services">
<t>
All services in this section refer to an existing connection, i.e. a
connection that was either established or made available for receiving data.
In addition to the listed parameters, all sending commands contain a
reference to a data block and all receiving commands contain a reference
to available buffer space for the 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 services 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".
</t>
<t><list style="symbols">
<t>Reliably transfer data<vspace />
Protocols: TCP, SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Notifying the receiver to promptly hand over data to application<vspace />
Protocols: TCP<vspace />
Comments: This seems unnecessary in SCTP, where data arrival causes
an event for the application.<vspace />
<vspace blankLines='1'/>
</t>
<t>Message identification<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>Message lifetime<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Choice between unordered (potentially faster) or ordered delivery<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>
</list></t>
</section>
<section anchor="data-receiving-pass3" title="Receiving Data">
<t>
All services in this section are provided by DATA.RECEIVE from pass 2.
DATA.RECEIVE fills a buffer provided to the application, with what we here call a "message".
</t>
<t>
<list style="symbols">
<t>Receive data<vspace />
Protocols: TCP, SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Choice of stream to receive on<vspace />
Protocols: SCTP<vspace />
<vspace blankLines='1'/>
</t>
<t>Message identification<vspace />
Protocols: SCTP<vspace />
Comments: In SCTP, this is optionally achieved with a "stream sequence number".
The stream sequence number is always provided in case of partial message arrival.<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>
</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<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 Joe Touch for comments on the TCP part.
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;
</references>
<references title="Informative References">
<!-- &RFC2119; -->
&RFC3168;
&RFC3260;
&RFC3828;
&RFC6093;
&RFC6458;
&RFC7414;
</references>
<!--
<section anchor="sec-internal" title="Internal comments">
<t>This is a place for taking notes.</t>
</section>
-->
<!-- Change Log
v00 2006-03-15 EBD Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:59:15 |