draft-ietf-taps-transports-usage-03.txt   draft-ietf-taps-transports-usage-04.txt 
TAPS M. Welzl TAPS M. Welzl
Internet-Draft University of Oslo Internet-Draft University of Oslo
Intended status: Informational M. Tuexen Intended status: Informational M. Tuexen
Expires: September 9, 2017 Muenster Univ. of Appl. Sciences Expires: October 7, 2017 Muenster Univ. of Appl. Sciences
N. Khademi N. Khademi
University of Oslo University of Oslo
March 8, 2017 April 5, 2017
On the Usage of Transport Features Provided by IETF Transport Protocols On the Usage of Transport Features Provided by IETF Transport Protocols
draft-ietf-taps-transports-usage-03 draft-ietf-taps-transports-usage-04
Abstract Abstract
This document describes how TCP, MPTCP, SCTP, UDP and UDP-Lite expose This document describes how TCP, MPTCP, SCTP, UDP and UDP-Lite expose
services to applications and how an application can configure and use services to applications and how an application can configure and use
the transport features that make up these services. It also the transport features that make up these services. It also
discusses the service provided by the LEDBAT congestion control discusses the service provided by the LEDBAT congestion control
mechanism. mechanism.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2017. This Internet-Draft will expire on October 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Primitives Provided by TCP . . . . . . . . . . . . . . . . 5 3.1. Primitives Provided by TCP . . . . . . . . . . . . . . . . 5
3.1.1. Excluded Primitives or Parameters . . . . . . . . . . 8 3.1.1. Excluded Primitives or Parameters . . . . . . . . . . 8
3.2. Primitives Provided by MPTCP . . . . . . . . . . . . . . . 9 3.2. Primitives Provided by MPTCP . . . . . . . . . . . . . . . 9
3.3. Primitives Provided by SCTP . . . . . . . . . . . . . . . 10 3.3. Primitives Provided by SCTP . . . . . . . . . . . . . . . 10
3.3.1. Excluded Primitives or Parameters . . . . . . . . . . 17 3.3.1. Excluded Primitives or Parameters . . . . . . . . . . 17
3.4. Primitives Provided by UDP and UDP-Lite . . . . . . . . . 17 3.4. Primitives Provided by UDP and UDP-Lite . . . . . . . . . 18
3.5. The service of LEDBAT . . . . . . . . . . . . . . . . . . 17 3.5. The service of LEDBAT . . . . . . . . . . . . . . . . . . 18
4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 19 4.1. CONNECTION Related Primitives . . . . . . . . . . . . . . 20
4.2. DATA Transfer Related Primitives . . . . . . . . . . . . . 30 4.2. DATA Transfer Related Primitives . . . . . . . . . . . . . 31
5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5. Pass 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. CONNECTION Related Transport Features . . . . . . . . . . 33 5.1. CONNECTION Related Transport Features . . . . . . . . . . 34
5.2. DATA Transfer Related Transport Features . . . . . . . . . 39 5.2. DATA Transfer Related Transport Features . . . . . . . . . 40
5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 39 5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 40
5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 40 5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 41
5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 41
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.1. Normative References . . . . . . . . . . . . . . . . . . . 41 9.1. Normative References . . . . . . . . . . . . . . . . . . . 42
9.2. Informative References . . . . . . . . . . . . . . . . . . 44 9.2. Informative References . . . . . . . . . . . . . . . . . . 45
Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 45 Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 46
Appendix B. How this document was developed . . . . . . . . . . . 45 Appendix B. How this document was developed . . . . . . . . . . . 46
Appendix C. Revision information . . . . . . . . . . . . . . . . 47 Appendix C. Revision information . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Terminology 1. Terminology
Transport Feature: a specific end-to-end feature that the transport Transport Feature: a specific end-to-end feature that the transport
layer provides to an application. Examples include layer provides to an application. Examples include
confidentiality, reliable delivery, ordered delivery, message- confidentiality, reliable delivery, ordered delivery, message-
versus-stream orientation, etc. versus-stream orientation, etc.
Transport Service: a set of Transport Features, without an Transport Service: a set of Transport Features, without an
association to any given framing protocol, which provides a association to any given framing protocol, which provides a
complete service to an application. complete service to an application.
skipping to change at page 3, line 50 skipping to change at page 3, line 50
2. Introduction 2. Introduction
This document presents defined interactions between applications and This document presents defined interactions between applications and
the transport protocols TCP, MPTCP, SCTP, UDP and UDP-Lite as well as the transport protocols TCP, MPTCP, SCTP, UDP and UDP-Lite as well as
the LEDBAT congestion control mechanism in the form of primitives and the LEDBAT congestion control mechanism in the form of primitives and
Transport Features. Primitives can be invoked by an application or a Transport Features. Primitives can be invoked by an application or a
transport protocol; the latter type is called an "event". The list transport protocol; the latter type is called an "event". The list
of primitives and Transport Features in this document is strictly of primitives and Transport Features in this document is strictly
based on the parts of protocol specifications that describe what the based on the parts of protocol specifications that describe what the
protocol provides to an application using it and how the application protocol provides to an application using it and how the application
interacts with it. interacts with it. Together with [RFC8095], it provides the basis
for the minimal set of transport services that end systems should
support; this minimal set is derived in
[I-D.draft-gjessing-taps-minset].
Parts of a protocol that are explicitly stated as optional to Parts of a protocol that are explicitly stated as optional to
implement are not covered. Interactions between the application and implement are not covered. Interactions between the application and
a transport protocol that are not directly related to the operation a transport protocol that are not directly related to the operation
of the protocol are also not covered. For example, [RFC6458] of the protocol are also not covered. For example, [RFC6458]
explains how an application can use socket options to indicate its explains how an application can use socket options to indicate its
interest in receiving certain notifications. However, for the interest in receiving certain notifications. However, for the
purpose of identifying primitives and Transport Services, the ability purpose of identifying primitives and Transport Services, the ability
to enable or disable the reception of notifications is irrelevant. to enable or disable the reception of notifications is irrelevant.
Similarly, one-to-many style sockets described in [RFC6458] just Similarly, one-to-many style sockets described in [RFC6458] just
skipping to change at page 6, line 23 skipping to change at page 6, line 24
connection request has arrived. Finally, the 'options' parameter connection request has arrived. Finally, the 'options' parameter
is explained in [RFC1122] to allow the application to specify IP is explained in [RFC1122] to allow the application to specify IP
options such as source route, record route, or timestamp. It is options such as source route, record route, or timestamp. It is
not stated on which segments of a connection these options should not stated on which segments of a connection these options should
be applied, but probably all segments, as this is also stated in a 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 specification given for the usage of source route (section 4.2.3.8
of [RFC1122]). Source route is the only non-optional IP option in of [RFC1122]). Source route is the only non-optional IP option in
this parameter, allowing an application to specify a source route this parameter, allowing an application to specify a source route
when it actively opens a TCP connection. when it actively opens a TCP connection.
Master Key Tuples (MKTs) for authentication can optionally be
configured when calling open (section 7.1 of [RFC5925]).
TCP Fast Open (TFO) [RFC7413] allows to immediately hand over a
message from the active open to the passive open side of a TCP
connection together with the first message establishment packet
(the SYN). This can be useful for applications that are sensitive
to TCP's connection setup delay. TCP implementations MUST NOT use
TFO by default, but only use TFO if requested explicitly by the
application on a per-service-port basis. To benefit from TFO, the
first application data unit (e.g., an HTTP request) needs to be no
more than TCP's maximum segment size (minus options used in the
SYN). For the active open side, [RFC7413] recommends changing or
replacing the connect() call in order to support a user data
buffer argument. For the passive open side, the application needs
to enable the reception of Fast Open requests, e.g. via a new
TCP_FASTOPEN setsockopt() socket option before listen(). The
receiving application must be prepared to accept duplicates of the
TFO message, as the first data written to a socket can be
delivered more than once to the application on the remote host.
send: this is the primitive that an application uses to give the send: this is the primitive that an application uses to give the
local TCP transport endpoint a number of bytes that TCP should local TCP transport endpoint a number of bytes that TCP should
reliably send to the other side of the connection. The URGENT reliably send to the other side of the connection. The URGENT
flag, if set, states that the data handed over by this send call flag, if set, states that the data handed over by this send call
is urgent and this urgency should be indicated to the receiving is urgent and this urgency should be indicated to the receiving
process in case the receiving application has not yet consumed all process in case the receiving application has not yet consumed all
non-urgent data preceding it. An optional timeout parameter can non-urgent data preceding it. An optional timeout parameter can
be provided that updates the connection's timeout (see 'open'). be provided that updates the connection's timeout (see 'open').
Additionally, optional parameters allow to indicate the preferred
outgoing MKT (current_key) and/or the preferred incoming MKT
(rnext_key) of a connection (section 7.1 of [RFC5925]).
receive: This primitive allocates a receiving buffer for a provided receive: This primitive allocates a receiving buffer for a provided
number of bytes. It returns the number of received bytes provided number of bytes. It returns the number of received bytes provided
in the buffer when these bytes have been received and written into in the buffer when these bytes have been received and written into
the buffer by TCP. The application is informed of urgent data via 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, 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 there is no urgent data or this call to 'receive' has returned all
the urgent data. the urgent data. The application is also informed about the
current_key and rnext_key information carried in a recently
received segment via an optional parameter (section 7.1 of
[RFC5925]).
close: This primitive closes one side of a connection. It is close: This primitive closes one side of a connection. It is
semantically equivalent to "I have no more data to send" but does 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 not mean "I will not receive any more", as the other side may
still have data to send. This call reliably delivers any data still have data to send. This call reliably delivers any data
that has already been given to TCP (and if that fails, 'close' that has already been given to TCP (and if that fails, 'close'
becomes 'abort'). becomes 'abort').
abort: This primitive causes all pending 'send' and 'receive' calls abort: This primitive causes all pending 'send' and 'receive' calls
to be aborted. A TCP RESET message is sent to the TCP endpoint on to be aborted. A TCP RESET message is sent to the TCP endpoint on
skipping to change at page 8, line 11 skipping to change at page 8, line 40
the value of the UTO advertised to the remote TCP peer (default: the value of the UTO advertised to the remote TCP peer (default:
system-wide default user timeout); ENABLED (default false) is a system-wide default user timeout); ENABLED (default false) is a
boolean-type flag that controls whether the UTO option is enabled boolean-type flag that controls whether the UTO option is enabled
for a connection. This applies to both sending and receiving. for a connection. This applies to both sending and receiving.
CHANGEABLE is a boolean-type flag (default true) that controls CHANGEABLE is a boolean-type flag (default true) that controls
whether the user timeout may be changed based on a UTO option whether the user timeout may be changed based on a UTO option
received from the other end of the connection. CHANGEABLE becomes received from the other end of the connection. CHANGEABLE becomes
false when an application explicitly sets the user timeout (see false when an application explicitly sets the user timeout (see
'send'). 'send').
Fast Open: TCP Fast Open (TFO) [RFC7413] allows to immediately hand
over a message from the active open to the passive open side of a
TCP connection together with the first message establishment
packet (the SYN). This can be useful for applications that are
sensitive to TCP's connection setup delay. TCP implementations
MUST NOT use TFO by default, but only use TFO if requested
explicitly by the application on a per-service-port basis. To
benefit from TFO, the first application data unit (e.g., an HTTP
request) needs to be no more than TCP's maximum segment size
(minus options used in the SYN). For the active open side,
[RFC7413] recommends changing or replacing the connect() call in
order to support a user data buffer argument. For the passive
open side, the application needs to enable the reception of Fast
Open requests, e.g. via a new TCP_FASTOPEN setsockopt() socket
option before listen(). The receiving application must be
prepared to accept duplicates of the TFO message, as the first
data written to a socket can be delivered more than once to the
application on the remote host.
3.1.1. Excluded Primitives or Parameters 3.1.1. Excluded Primitives or Parameters
The 'open' primitive specified in [RFC0793] can be handed optional The 'open' primitive specified in [RFC0793] can be handed optional
Precedence or security/compartment information according to Precedence or security/compartment information according to
[RFC0793], but this was not included here because it is mostly [RFC0793], but this was not included here because it is mostly
irrelevant today, as explained in [RFC7414]. irrelevant today, as explained in [RFC7414].
The 'status' primitive was not included because [RFC0793] describes The 'status' primitive was not included because [RFC0793] describes
this primitive as "implementation dependent" and states that it this primitive as "implementation dependent" and states that it
"could be excluded without adverse effect". Moreover, while a data "could be excluded without adverse effect". Moreover, while a data
block containing specific information is described, it is also stated block containing specific information is described, it is also stated
that not all of this information may always be available. The 'send' that not all of this information may always be available. While
[RFC5925] states that 'status' SHOULD be augmented to allow the MKTs
of a current or pending connection to be read (for confirmation), the
same information is also available via 'receive', which MUST be
augmented with that functionality according to [RFC5925]. The 'send'
primitive described in [RFC0793] includes an optional PUSH flag primitive described in [RFC0793] includes an optional PUSH flag
which, if set, requires data to be promptly transmitted to the which, if set, requires data to be promptly transmitted to the
receiver without delay; the 'receive' primitive described in receiver without delay; the 'receive' primitive described in
[RFC0793] can (under some conditions) yield the status of the PUSH [RFC0793] can (under some conditions) yield the status of the PUSH
flag. Because PUSH functionality is made optional to implement for flag. Because PUSH functionality is made optional to implement for
both the 'send' and 'receive' primitives in [RFC1122], this both the 'send' and 'receive' primitives in [RFC1122], this
functionality is not included here. [RFC1122] also introduces keep- functionality is not included here. [RFC1122] also introduces keep-
alives to TCP, but these are optional to implement and hence not alives to TCP, but these are optional to implement and hence not
considered here. [RFC1122] describes that "some TCP implementations considered here. [RFC1122] describes that "some TCP implementations
have included a FLUSH call", indicating that this call is also have included a FLUSH call", indicating that this call is also
skipping to change at page 18, line 39 skipping to change at page 19, line 9
should both be 2. should both be 2.
Regarding which of these parameters should be under control of an Regarding which of these parameters should be under control of an
application, the possible range goes from exposing nothing on the one application, the possible range goes from exposing nothing on the one
hand, to considering everything that is not fully prescribed with a hand, to considering everything that is not fully prescribed with a
MUST in [RFC6817] as a parameter on the other hand. Function MUST in [RFC6817] as a parameter on the other hand. Function
implementations are not provided as a parameter to any of the implementations are not provided as a parameter to any of the
transport protocols discussed here, and hence we do not regard the transport protocols discussed here, and hence we do not regard the
FILTER() function as a parameter. However, to avoid unnecessarily FILTER() function as a parameter. However, to avoid unnecessarily
limiting future implementations, we consider all other parameters limiting future implementations, we consider all other parameters
above as tunable parameters that a TAPS system should expose. above as tunable parameters that should be exposed.
4. Pass 2 4. Pass 2
This pass categorizes the primitives from pass 1 based on whether This pass categorizes the primitives from pass 1 based on whether
they relate to a connection or to data transmission. Primitives are they relate to a connection or to data transmission. Primitives are
presented following the nomenclature presented following the nomenclature
"CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL". The CATEGORY can be "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL". The CATEGORY can be
CONNECTION or DATA. Within the CONNECTION category, ESTABLISHMENT, CONNECTION or DATA. Within the CONNECTION category, ESTABLISHMENT,
AVAILABILITY, MAINTENANCE and TERMINATION subcategories can be AVAILABILITY, MAINTENANCE and TERMINATION subcategories can be
considered. The DATA category does not have any SUBCATEGORY. The considered. The DATA category does not have any SUBCATEGORY. The
skipping to change at page 19, line 25 skipping to change at page 19, line 42
both are disabled [RFC6458]. This is not described in the same way both are disabled [RFC6458]. This is not described in the same way
for TCP in [RFC0793], but these details play no significant role for for TCP in [RFC0793], but these details play no significant role for
the primitives provided by either TCP or SCTP (for the sake of being the primitives provided by either TCP or SCTP (for the sake of being
generic, it could be assumed that both receive and send operations generic, it could be assumed that both receive and send operations
are disabled in both cases). are disabled in both cases).
The TCP 'send' and 'receive' primitives include usage of an "URGENT" The TCP 'send' and 'receive' primitives include usage of an "URGENT"
mechanism. This mechanism is required to implement the "synch mechanism. This mechanism is required to implement the "synch
signal" used by telnet [RFC0854], but SHOULD NOT be used by new signal" used by telnet [RFC0854], but SHOULD NOT be used by new
applications [RFC6093]. Because pass 2 is meant as a basis for the applications [RFC6093]. Because pass 2 is meant as a basis for the
creation of TAPS systems, the "URGENT" mechanism is excluded. This creation of future systems, the "URGENT" mechanism is excluded. This
also concerns the notification "Urgent pointer advance" in the also concerns the notification "Urgent pointer advance" in the
ERROR_REPORT described in Section 4.2.4.1 of [RFC1122]. ERROR_REPORT described in Section 4.2.4.1 of [RFC1122].
Since LEDBAT is a congestion control mechanism and not a protocol, it Since LEDBAT is a congestion control mechanism and not a protocol, it
is not currently defined when to enable / disable or configure the is not currently defined when to enable / disable or configure the
mechanism. For instance, it could be a one-time choice upon mechanism. For instance, it could be a one-time choice upon
connection establishment or when listening for incoming connections, connection establishment or when listening for incoming connections,
in which case it should be categorized under CONNECTION.ESTABLISHMENT in which case it should be categorized under CONNECTION.ESTABLISHMENT
or CONNECTION.AVAILABILITY, respectively. To avoid unnecessarily or CONNECTION.AVAILABILITY, respectively. To avoid unnecessarily
limiting future implementations, it was decided to place it under limiting future implementations, it was decided to place it under
skipping to change at page 20, line 5 skipping to change at page 20, line 23
more transport endpoints. more transport endpoints.
Interfaces to UDP and UDP-Lite allow both connection-oriented and Interfaces to UDP and UDP-Lite allow both connection-oriented and
connection-less usage of the API . [RFC8085] connection-less usage of the API . [RFC8085]
o CONNECT.TCP: o CONNECT.TCP:
Pass 1 primitive / event: 'open' (active) or 'open' (passive) with Pass 1 primitive / event: 'open' (active) or 'open' (passive) with
socket, followed by 'send' socket, followed by 'send'
Parameters: 1 local IP address (optional); 1 destination transport Parameters: 1 local IP address (optional); 1 destination transport
address (for active open; else the socket and the local IP address address (for active open; else the socket and the local IP address
of the succeeding incoming connection request will be maintained); of the succeeding incoming connection request will be maintained);
timeout (optional); options (optional); user message (optional) timeout (optional); options (optional); MKT configuration
(optional); user message (optional)
Comments: If the local IP address is not provided, a default Comments: If the local IP address is not provided, a default
choice will automatically be made. The timeout can also be a choice will automatically be made. The timeout can also be a
retransmission count. The options are IP options to be used on retransmission count. The options are IP options to be used on
all segments of the connection. At least the Source Route option all segments of the connection. At least the Source Route option
is mandatory for TCP to provide. The user message may be is mandatory for TCP to provide. 'MKT configuration' refers to
transmitted to the peer application immediately upon reception of the ability to configure Master Key Tuples (MKTs) for
the TCP SYN packet. To benefit from the lower latency this authentication. The user message may be transmitted to the peer
provides as part of the experimental TFO mechanism, its length application immediately upon reception of the TCP SYN packet. To
must be at most the TCP's maximum segment size (minus TCP options benefit from the lower latency this provides as part of the
used in the SYN). The message may also be delivered more than experimental TFO mechanism, its length must be at most the TCP's
once to the application on the remote host. maximum segment size (minus TCP options used in the SYN). The
message may also be delivered more than once to the application on
the remote host.
o CONNECT.SCTP: o CONNECT.SCTP:
Pass 1 primitive / event: 'initialize', followed by 'enable / Pass 1 primitive / event: 'initialize', followed by 'enable /
disable interleaving' (optional), followed by 'associate' disable interleaving' (optional), followed by 'associate'
Parameters: list of local SCTP port number / IP address pairs Parameters: list of local SCTP port number / IP address pairs
(initialize); one or several sockets (identifying the peer); (initialize); one or several sockets (identifying the peer);
outbound stream count; maximum allowed inbound stream count; outbound stream count; maximum allowed inbound stream count;
adaptation layer indication (optional); chunk types required to be adaptation layer indication (optional); chunk types required to be
authenticated (optional); request interleaving on/off; maximum authenticated (optional); request interleaving on/off; maximum
number of INIT attemps (optional); maximum init. RTO for INIT number of INIT attemps (optional); maximum init. RTO for INIT
skipping to change at page 21, line 15 skipping to change at page 21, line 36
address to create a new connection. The CONNECT function allows address to create a new connection. The CONNECT function allows
an application to receive errors from messages sent to a transport an application to receive errors from messages sent to a transport
address. address.
AVAILABILITY: AVAILABILITY:
Preparing to receive incoming connection requests. Preparing to receive incoming connection requests.
o LISTEN.TCP: o LISTEN.TCP:
Pass 1 primitive / event: 'open' (passive) Pass 1 primitive / event: 'open' (passive)
Parameters: 1 local IP address (optional); 1 socket (optional); Parameters: 1 local IP address (optional); 1 socket (optional);
timeout (optional); buffer to receive a user message (optional) timeout (optional); buffer to receive a user message (optional);
MKT configuration (optional)
Comments: if the socket and/or local IP address is provided, this Comments: if the socket and/or local IP address is provided, this
waits for incoming connections from only and/or to only the waits for incoming connections from only and/or to only the
provided address. Else this waits for incoming connections provided address. Else this waits for incoming connections
without this / these constraint(s). ESTABLISHMENT can later be without this / these constraint(s). ESTABLISHMENT can later be
performed with 'send'. If a buffer is provided to receive a user performed with 'send'. If a buffer is provided to receive a user
message, a user message can be received from a TFO-enabled sender message, a user message can be received from a TFO-enabled sender
before TCP's connection handshake is completed. This message may before TCP's connection handshake is completed. This message may
arrive multiple times. arrive multiple times. 'MKT configuration' refers to the ability
to configure Master Key Tuples (MKTs) for authentication.
o LISTEN.SCTP: o LISTEN.SCTP:
Pass 1 primitive / event: 'initialize', followed by 'COMMUNICATION Pass 1 primitive / event: 'initialize', followed by 'COMMUNICATION
UP' or 'RESTART' notification and possibly 'ADAPTATION LAYER' UP' or 'RESTART' notification and possibly 'ADAPTATION LAYER'
notification notification
Parameters: list of local SCTP port number / IP address pairs Parameters: list of local SCTP port number / IP address pairs
(initialize) (initialize)
Returns: socket list; outbound stream count; inbound stream count; Returns: socket list; outbound stream count; inbound stream count;
adaptation layer indication; chunks required to be authenticated; adaptation layer indication; chunks required to be authenticated;
interleaving supported on both sides yes/no interleaving supported on both sides yes/no
skipping to change at page 25, line 34 skipping to change at page 26, line 6
notifications. The reported conditions include at least: ICMP notifications. The reported conditions include at least: ICMP
error message arrived; Excessive Retransmissions. error message arrived; Excessive Retransmissions.
o ERROR.UDP(-Lite): o ERROR.UDP(-Lite):
Pass 1 primitive / event: 'ERROR_REPORT'. Pass 1 primitive / event: 'ERROR_REPORT'.
Returns: Error report Returns: Error report
Comments: This returns soft errors that may be ignored without Comments: This returns soft errors that may be ignored without
harm by many applications; An application must connect to be able harm by many applications; An application must connect to be able
receive these notifications. receive these notifications.
o SET_AUTH.TCP:
Pass 1 primitive / event: 'send'
Parameters: current_key, rnext_key
Comments: current_key and rnext_key are the preferred outgoing MKT
and the preferred incoming MKT, respectively, for a segment that
is sent on an active option.
o SET_AUTH.SCTP: o SET_AUTH.SCTP:
Pass 1 primitive / event: 'Set / Get Authentication Parameters' Pass 1 primitive / event: 'Set / Get Authentication Parameters'
Parameters: key_id, key, hmac_id Parameters: key_id, key, hmac_id
o GET_AUTH.TCP:
Pass 1 primitive / event: 'receive'
Parameters: current_key, rnext_key
Comments: current_key and rnext_key are the preferred outgoing MKT
and the preferred incoming MKT, respectively, that were carried on
a recently received segment.
o GET_AUTH.SCTP: o GET_AUTH.SCTP:
Pass 1 primitive / event: 'Set / Get Authentication Parameters' Pass 1 primitive / event: 'Set / Get Authentication Parameters'
Parameters: key_id, chunk_list Parameters: key_id, chunk_list
o RESET_STREAM.SCTP: o RESET_STREAM.SCTP:
Pass 1 primitive / event: 'Add / Reset Streams, Reset Association' Pass 1 primitive / event: 'Add / Reset Streams, Reset Association'
Parameters: sid, direction Parameters: sid, direction
o RESET_STREAM-EVENT.SCTP: o RESET_STREAM-EVENT.SCTP:
Pass 1 primitive / event: 'STREAM RESET notification' Pass 1 primitive / event: 'STREAM RESET notification'
skipping to change at page 29, line 45 skipping to change at page 30, line 32
o CLOSE.TCP: o CLOSE.TCP:
Pass 1 primitive / event: 'close' Pass 1 primitive / event: 'close'
Comments: this terminates the sending side of a connection after Comments: this terminates the sending side of a connection after
reliably delivering all remaining data. reliably delivering all remaining data.
o CLOSE.SCTP: o CLOSE.SCTP:
Pass 1 primitive / event: 'Shutdown' Pass 1 primitive / event: 'Shutdown'
Comments: this terminates a connection after reliably delivering Comments: this terminates a connection after reliably delivering
all remaining data. all remaining data.
o CLOSE.UDP(-Lite):
Pass 1 primitive event: 'CLOSE'
Comments: No further UDP(-Lite) datagrams are sent/received on
this connection.
o ABORT.TCP: o ABORT.TCP:
Pass 1 primitive / event: 'abort' Pass 1 primitive / event: 'abort'
Comments: this terminates a connection without delivering Comments: this terminates a connection without delivering
remaining data and sends an error message to the other side. remaining data and sends an error message to the other side.
o ABORT.SCTP: o ABORT.SCTP:
Pass 1 primitive / event: 'abort' Pass 1 primitive / event: 'abort'
Parameters: abort reason to be given to the peer (optional) Parameters: abort reason to be given to the peer (optional)
Comments: this terminates a connection without delivering Comments: this terminates a connection without delivering
remaining data and sends an error message to the other side. remaining data and sends an error message to the other side.
o ABORT.UDP(-Lite):
Pass 1 primitive event: 'CLOSE'
Comments: this terminates a connection without delivering
remaining data. No further UDP(-Lite) datagrams are sent/received
on this connection.
o TIMEOUT.TCP: o TIMEOUT.TCP:
Pass 1 primitive / event: 'USER TIMEOUT' event Pass 1 primitive / event: 'USER TIMEOUT' event
Comments: the application is informed that the connection is Comments: the application is informed that the connection is
aborted. This event is executed on expiration of the timeout set aborted. This event is executed on expiration of the timeout set
in CONNECTION.ESTABLISHMENT.CONNECT.TCP (possibly adjusted in in CONNECTION.ESTABLISHMENT.CONNECT.TCP (possibly adjusted in
CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP). CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP).
o TIMEOUT.SCTP: o TIMEOUT.SCTP:
Pass 1 primitive / event: 'COMMUNICATION LOST' event Pass 1 primitive / event: 'COMMUNICATION LOST' event
Comments: the application is informed that the connection is Comments: the application is informed that the connection is
skipping to change at page 31, line 14 skipping to change at page 31, line 47
receiving data (although this is optional for the primitives of UDP(- receiving data (although this is optional for the primitives of UDP(-
Lite)). In addition to the listed parameters, all sending primitives 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 a data block and all receiving primitives
contain a reference to available buffer space for the data. Note contain a reference to available buffer space for the data. Note
that CONNECT.TCP and LISTEN.TCP in the ESTABLISHMENT and AVAILABILITY that CONNECT.TCP and LISTEN.TCP in the ESTABLISHMENT and AVAILABILITY
category also allow to transfer data (an optional user message) category also allow to transfer data (an optional user message)
before the connection is fully established. before the connection is fully established.
o SEND.TCP: o SEND.TCP:
Pass 1 primitive / event: 'send' Pass 1 primitive / event: 'send'
Parameters: timeout (optional) Parameters: timeout (optional), current_key (optional), rnext_key
(optional)
Comments: this gives TCP a data block for reliable transmission to Comments: this gives TCP a data block for reliable transmission to
the TCP on the other side of the connection. The timeout can be the TCP on the other side of the connection. The timeout can be
configured with this call whenever data are sent (see also configured with this call (see also
CONNECTION.MAINTENANCE.CHANGE-TIMEOUT.TCP). CONNECTION.MAINTENANCE.CHANGE_TIMEOUT.TCP). current_key and
rnext_key are authentication parameters that can be configured
with this call (see also CONNECTION.MAINTENANCE.SET_AUTH.TCP).
o SEND.SCTP: o SEND.SCTP:
Pass 1 primitive / event: 'Send' Pass 1 primitive / event: 'Send'
Parameters: stream number; context (optional); socket (optional); Parameters: stream number; context (optional); socket (optional);
unordered flag (optional); no-bundle flag (optional); payload unordered flag (optional); no-bundle flag (optional); payload
protocol-id (optional); pr-policy (optional) pr-value (optional); protocol-id (optional); pr-policy (optional) pr-value (optional);
sack-immediately flag (optional); key-id (optional) sack-immediately flag (optional); key-id (optional)
Comments: this gives SCTP a data block for transmission to the Comments: this gives SCTP a data block for transmission to the
SCTP on the other side of the connection (SCTP association). The SCTP on the other side of the connection (SCTP association). The
'stream number' denotes the stream to be used. The 'context' 'stream number' denotes the stream to be used. The 'context'
skipping to change at page 32, line 7 skipping to change at page 32, line 44
Parameters: IP Address and Port Number of the destination endpoint Parameters: IP Address and Port Number of the destination endpoint
(optional if connected). (optional if connected).
Comments: This provides a message for unreliable transmission Comments: This provides a message for unreliable transmission
using UDP(-Lite) to the specified transport address. IP address using UDP(-Lite) to the specified transport address. IP address
and Port may be omitted for connected UDP(-Lite) sockets. All and Port may be omitted for connected UDP(-Lite) sockets. All
CONNECTION.MAINTENANCE.SET_*.UDP(-Lite) primitives apply per CONNECTION.MAINTENANCE.SET_*.UDP(-Lite) primitives apply per
message sent. message sent.
o RECEIVE.TCP: o RECEIVE.TCP:
Pass 1 primitive / event: 'receive'. Pass 1 primitive / event: 'receive'.
Parameters: current_key (optional), rnext_key (optional).
Comments: current_key and rnext_key are authentication parameters
that can be read with this call (see also
CONNECTION.MAINTENANCE.GET_AUTH.TCP).
o RECEIVE.SCTP: o RECEIVE.SCTP:
Pass 1 primitive / event: 'DATA ARRIVE' notification, followed by Pass 1 primitive / event: 'DATA ARRIVE' notification, followed by
'Receive' 'Receive'
Parameters: stream number (optional) Parameters: stream number (optional)
Returns: stream sequence number (optional), partial flag Returns: stream sequence number (optional), partial flag
(optional) (optional)
Comments: if the 'stream number' is provided, the call to receive Comments: if the 'stream number' is provided, the call to receive
only receives data on one particular stream. If a partial message only receives data on one particular stream. If a partial message
arrives, this is indicated by the 'partial flag', and then the arrives, this is indicated by the 'partial flag', and then the
skipping to change at page 34, line 5 skipping to change at page 34, line 45
o Specify number of attempts and/or timeout for the first o Specify number of attempts and/or timeout for the first
establishment message establishment message
Protocols: TCP, SCTP Protocols: TCP, SCTP
o Obtain multiple sockets o Obtain multiple sockets
Protocols: SCTP Protocols: SCTP
o Disable MPTCP o Disable MPTCP
Protocols: MPTCP Protocols: MPTCP
o Specify which chunk types must always be authenticated o Configure authentication
Protocols: SCTP Protocols: TCP, SCTP
Comments: DATA, ACK etc. are different 'chunks' in SCTP; one or Comments: With TCP, this allows to configure Master Key Tuples
more chunks may be included in a single packet. (MKTs). In SCTP, this allows to specify which chunk types must
always be authenticated. DATA, ACK etc. are different 'chunks' in
SCTP; one or more chunks may be included in a single packet.
o Indicate an Adaptation Layer (via an adaptation code point) o Indicate an Adaptation Layer (via an adaptation code point)
Protocols: SCTP Protocols: SCTP
o Request to negotiate interleaving of user messages o Request to negotiate interleaving of user messages
Protocols: SCTP Protocols: SCTP
o Hand over a message to transfer (possibly multiple times) before o Hand over a message to transfer (possibly multiple times) before
connection establishment connection establishment
Protocols: TCP Protocols: TCP
skipping to change at page 35, line 5 skipping to change at page 35, line 45
o Limit the number of inbound streams o Limit the number of inbound streams
Protocols: SCTP Protocols: SCTP
o Specify which IP Options must always be used o Specify which IP Options must always be used
Protocols: TCP Protocols: TCP
o Disable MPTCP o Disable MPTCP
Protocols: MPTCP Protocols: MPTCP
o Specify which chunk types must always be authenticated o Configure authentication
Protocols: SCTP Protocols: TCP, SCTP
Comments: DATA, ACK etc. are different 'chunks' in SCTP; one or Comments: With TCP, this allows to configure Master Key Tuples
more chunks may be included in a single packet. (MKTs). In SCTP, this allows to specify which chunk types must
always be authenticated. DATA, ACK etc. are different 'chunks' in
SCTP; one or more chunks may be included in a single packet.
o Indicate an Adaptation Layer (via an adaptation code point) o Indicate an Adaptation Layer (via an adaptation code point)
Protocols: SCTP Protocols: SCTP
MAINTENANCE: MAINTENANCE:
Adjustments made to an open connection, or notifications about it. Adjustments made to an open connection, or notifications about it.
o Change timeout for aborting connection (using retransmit limit or o Change timeout for aborting connection (using retransmit limit or
time value) time value)
Protocols: TCP, SCTP Protocols: TCP, SCTP
skipping to change at page 36, line 28 skipping to change at page 37, line 21
MPTCP parameters: subflow-list (identified by source-IP; source- MPTCP parameters: subflow-list (identified by source-IP; source-
Port; destination-IP; destination-Port) Port; destination-IP; destination-Port)
o Specify DSCP field o Specify DSCP field
Protocols: TCP, SCTP, UDP(-Lite) Protocols: TCP, SCTP, UDP(-Lite)
o Notification of ICMP error message arrival o Notification of ICMP error message arrival
Protocols: TCP, UDP(-Lite) Protocols: TCP, UDP(-Lite)
o Change authentication parameters o Change authentication parameters
Protocols: SCTP Protocols: TCP, SCTP
o Obtain authentication information o Obtain authentication information
Protocols: SCTP Protocols: TCP, SCTP
o Reset Stream o Reset Stream
Protocols: SCTP Protocols: SCTP
o Notification of Stream Reset o Notification of Stream Reset
Protocols: STCP Protocols: STCP
o Reset Association o Reset Association
Protocols: SCTP Protocols: SCTP
skipping to change at page 38, line 44 skipping to change at page 39, line 38
Comments: A TCP endpoint locally only closes the connection for Comments: A TCP endpoint locally only closes the connection for
sending; it may still receive data afterwards. sending; it may still receive data afterwards.
o Abort without delivering remaining data, causing an event o Abort without delivering remaining data, causing an event
informing the application on the other side informing the application on the other side
Protocols: TCP, SCTP Protocols: TCP, SCTP
Comments: In SCTP a reason can optionally be given by the Comments: In SCTP a reason can optionally be given by the
application on the aborting side, which can then be received by application on the aborting side, which can then be received by
the application on the other side. the application on the other side.
o Abort without delivering remaining data, not causing an event
informing the application on the other side
Protocols: UDP(-Lite)
o Timeout event when data could not be delivered for too long o Timeout event when data could not be delivered for too long
Protocols: TCP, SCTP Protocols: TCP, SCTP
Comments: the timeout is configured with CONNECTION.MAINTENANCE Comments: the timeout is configured with CONNECTION.MAINTENANCE
"Change timeout for aborting connection (using retransmit limit or "Change timeout for aborting connection (using retransmit limit or
time value)". time value)".
5.2. DATA Transfer Related Transport Features 5.2. DATA Transfer Related Transport Features
All features in this section refer to an existing connection, i.e. a All features in this section refer to an existing connection, i.e. a
connection that was either established or made available for connection that was either established or made available for
skipping to change at page 41, line 15 skipping to change at page 42, line 15
o Notification that the stack has no more user data to send o Notification that the stack has no more user data to send
Protocols: SCTP Protocols: SCTP
o Notification to a receiver that a partial message delivery has o Notification to a receiver that a partial message delivery has
been aborted been aborted
Protocols: SCTP Protocols: SCTP
6. Acknowledgements 6. Acknowledgements
The authors would like to thank (in alphabetical order) Bob Briscoe, The authors would like to thank (in alphabetical order) Bob Briscoe,
Gorry Fairhurst, David Hayes, Tom Jones, Karen Nielsen, Joe Touch and David Hayes, Karen Nielsen, Joe Touch and Brian Trammell for
Brian Trammell for providing valuable feedback on this document. We providing valuable feedback on this document. We especially thank
especially thank Christoph Paasch for providing input related to Christoph Paasch for providing input related to Multipath TCP, and
Multipath TCP. This work has received funding from the European Gorry Fairhurst and Tom Jones for providing input related to UDP(-
Lite), via [FJ16]. This work has received funding from the European
Union's Horizon 2020 research and innovation programme under grant Union's Horizon 2020 research and innovation programme under grant
agreement No. 644334 (NEAT). The views expressed are solely those of agreement No. 644334 (NEAT). The views expressed are solely those of
the author(s). the author(s).
7. IANA Considerations 7. IANA Considerations
XX RFC ED - PLEASE REMOVE THIS SECTION XXX XX RFC ED - PLEASE REMOVE THIS SECTION XXX
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. Security Considerations
Authentication, confidentiality protection, and integrity protection Authentication, confidentiality protection, and integrity protection
are identified as Transport Features by [RFC8095]. As currently are identified as Transport Features by [RFC8095]. As currently
deployed in the Internet, these features are generally provided by a deployed in the Internet, these features are generally provided by a
protocol or layer on top of the transport protocol; no current full- protocol or layer on top of the transport protocol; no current full-
featured standards-track transport protocol provides these features featured standards-track transport protocol provides these features
on its own. Therefore, these features are not considered in this on its own. Therefore, these features are not considered in this
document, with the exception of native authentication capabilities of document, with the exception of native authentication capabilities of
SCTP for which the security considerations in [RFC4895] apply. TCP and SCTP for which the security considerations in [RFC5925] and
[RFC4895] apply.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FJ16] Fairhurst, G. and T. Jones, "Features of the User Datagram [FJ16] Fairhurst, G. and T. Jones, "Features of the User Datagram
Protocol (UDP) and Lightweight UDP (UDP-Lite) Transport Protocol (UDP) and Lightweight UDP (UDP-Lite) Transport
Protocols", draft-ietf-taps-transports-usage-udp-00 (work Protocols", draft-ietf-taps-transports-usage-udp-00 (work
in progress), November 2016. in progress), November 2016.
skipping to change at page 42, line 46 skipping to change at page 43, line 48
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP) Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/ Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/
RFC5061, September 2007, RFC5061, September 2007,
<http://www.rfc-editor.org/info/rfc5061>. <http://www.rfc-editor.org/info/rfc5061>.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",
RFC 5482, DOI 10.17487/RFC5482, March 2009, RFC 5482, DOI 10.17487/RFC5482, March 2009,
<http://www.rfc-editor.org/info/rfc5482>. <http://www.rfc-editor.org/info/rfc5482>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
<http://www.rfc-editor.org/info/rfc6182>. <http://www.rfc-editor.org/info/rfc6182>.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for the Stream Control Yasevich, "Sockets API Extensions for the Stream Control
Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/ Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/
RFC6458, December 2011, RFC6458, December 2011,
<http://www.rfc-editor.org/info/rfc6458>. <http://www.rfc-editor.org/info/rfc6458>.
skipping to change at page 44, line 12 skipping to change at page 45, line 19
Stream Control Transmission Protocol", RFC 7829, Stream Control Transmission Protocol", RFC 7829,
DOI 10.17487/RFC7829, April 2016, DOI 10.17487/RFC7829, April 2016,
<http://www.rfc-editor.org/info/rfc7829>. <http://www.rfc-editor.org/info/rfc7829>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <http://www.rfc-editor.org/info/rfc8085>. March 2017, <http://www.rfc-editor.org/info/rfc8085>.
9.2. Informative References 9.2. Informative References
[I-D.draft-gjessing-taps-minset]
Gjessing, S. and M. Welzl, "A Minimal Set of Transport
Services for TAPS Systems", draft-gjessing-taps-minset-04
(work in progress), March 2017.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, Specification", STD 8, RFC 854, DOI 10.17487/RFC0854,
May 1983, <http://www.rfc-editor.org/info/rfc854>. May 1983, <http://www.rfc-editor.org/info/rfc854>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
skipping to change at page 45, line 9 skipping to change at page 46, line 21
<http://www.rfc-editor.org/info/rfc7657>. <http://www.rfc-editor.org/info/rfc7657>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, DOI 10.17487/ Congestion Control Mechanisms", RFC 8095, DOI 10.17487/
RFC8095, March 2017, RFC8095, March 2017,
<http://www.rfc-editor.org/info/rfc8095>. <http://www.rfc-editor.org/info/rfc8095>.
Appendix A. Overview of RFCs used as input for pass 1 Appendix A. Overview of RFCs used as input for pass 1
TCP: [RFC0793], [RFC1122], [RFC5482], [RFC7413] TCP: [RFC0793], [RFC1122], [RFC5482], [RFC5925], [RFC7413]
MPTCP: [RFC6182], [RFC6824], [RFC6897] MPTCP: [RFC6182], [RFC6824], [RFC6897]
SCTP: RFCs without a socket API specification: [RFC3758], [RFC4895], SCTP: RFCs without a socket API specification: [RFC3758], [RFC4895],
[RFC4960], [RFC5061]. RFCs that include a socket API [RFC4960], [RFC5061].
specification: [RFC6458], [RFC6525], [RFC6951], [RFC7053], RFCs that include a socket API specification: [RFC6458],
[RFC7496] [RFC7829]. [RFC6525], [RFC6951], [RFC7053], [RFC7496] [RFC7829].
UDP(-Lite): See [FJ16] UDP(-Lite): See [FJ16]
LEDBAT: [RFC6817]. LEDBAT: [RFC6817].
Appendix B. How this document was developed Appendix B. How this document was developed
This section gives an overview of the method that was used to develop This section gives an overview of the method that was used to develop
this document. It was given to contributors for guidance, and it can this document. It was given to contributors for guidance, and it can
be helpful for future updates or extensions. be helpful for future updates or extensions.
This document is only concerned with Transport Features that are This document is only concerned with Transport Features that are
skipping to change at page 47, line 39 skipping to change at page 48, line 48
UDP, UDP-Lite, LEDBAT) instead of talking about "transport UDP, UDP-Lite, LEDBAT) instead of talking about "transport
protocols". Interleaving and stream scheduling added protocols". Interleaving and stream scheduling added
(draft-ietf-tsvwg-sctp-ndata). TFO added. "Set protocol parameters" (draft-ietf-tsvwg-sctp-ndata). TFO added. "Set protocol parameters"
in SCTP replaced with per-parameter (or parameter group) primitives. in SCTP replaced with per-parameter (or parameter group) primitives.
More primitives added, mostly previously overlooked ones from More primitives added, mostly previously overlooked ones from
[RFC6458]. Updated terminology (s/transport service feature/ [RFC6458]. Updated terminology (s/transport service feature/
transport feature) in line with an update of [RFC8095]. Made transport feature) in line with an update of [RFC8095]. Made
sequence of transport features / primitives more logical. Combined sequence of transport features / primitives more logical. Combined
MPTCP's add/rem subflow with SCTP's add/remove local address. MPTCP's add/rem subflow with SCTP's add/remove local address.
-04: changed UDP's close into an ABORT (to better fit with the
primitives of TCP and SCTP), and incorporated the corresponding
transport feature in step 3 (this addresses a comment from Gorry
Fairhurst). Added TCP Authentication (RFC 5925, section 7.1).
Changed TFO from looking like a primitive in pass 1 to be a part of
'open'. Changed description of SCTP authentication in pass 3 to
encompass both TCP and SCTP. Added citations of [RFC8095] and minset
[I-D.draft-gjessing-taps-minset] to the intro, to give the context of
this document.
Authors' Addresses Authors' Addresses
Michael Welzl Michael Welzl
University of Oslo University of Oslo
PO Box 1080 Blindern PO Box 1080 Blindern
Oslo, N-0316 Oslo, N-0316
Norway Norway
Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no Email: michawe@ifi.uio.no
Michael Tuexen Michael Tuexen
Muenster University of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstrasse 39 Stegerwaldstrasse 39
Steinfurt 48565 Steinfurt 48565
Germany Germany
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Naeem Khademi Naeem Khademi
University of Oslo University of Oslo
 End of changes. 38 change blocks. 
87 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/