draft-ietf-taps-transports-usage-07.txt   draft-ietf-taps-transports-usage-08.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: February 26, 2018 Muenster Univ. of Appl. Sciences Expires: February 27, 2018 Muenster Univ. of Appl. Sciences
N. Khademi N. Khademi
University of Oslo University of Oslo
August 25, 2017 August 26, 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-07 draft-ietf-taps-transports-usage-08
Abstract Abstract
This document describes how the transport protocols Transmission This document describes how the transport protocols Transmission
Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control
Transmission Protocol (SCTP), User Datagram Protocol (UDP) and Transmission Protocol (SCTP), User Datagram Protocol (UDP) and
Lightweight User Datagram Protocol (UDP-Lite) expose services to Lightweight User Datagram Protocol (UDP-Lite) expose services to
applications and how an application can configure and use the applications and how an application can configure and use the
features that make up these services. It also discusses the service features that make up these services. It also discusses the service
provided by the Low Extra Delay Background Transport (LEDBAT) provided by the Low Extra Delay Background Transport (LEDBAT)
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 February 26, 2018. This Internet-Draft will expire on February 27, 2018.
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 41 skipping to change at page 2, line 41
5.1. CONNECTION Related Transport Features . . . . . . . . . . 34 5.1. CONNECTION Related Transport Features . . . . . . . . . . 34
5.2. DATA Transfer Related Transport Features . . . . . . . . . 40 5.2. DATA Transfer Related Transport Features . . . . . . . . . 40
5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 40 5.2.1. Sending Data . . . . . . . . . . . . . . . . . . . . . 40
5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 41 5.2.2. Receiving Data . . . . . . . . . . . . . . . . . . . . 41
5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . 42
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Normative References . . . . . . . . . . . . . . . . . . . 43 9.1. Normative References . . . . . . . . . . . . . . . . . . . 43
9.2. Informative References . . . . . . . . . . . . . . . . . . 46 9.2. Informative References . . . . . . . . . . . . . . . . . . 45
Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 47 Appendix A. Overview of RFCs used as input for pass 1 . . . . . . 47
Appendix B. How this document was developed . . . . . . . . . . . 47 Appendix B. How this document was developed . . . . . . . . . . . 47
Appendix C. Revision information . . . . . . . . . . . . . . . . 49 Appendix C. Revision information . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
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
skipping to change at page 13, line 18 skipping to change at page 13, line 18
authenticated chunks are used, the key identifier for authenticated chunks are used, the key identifier for
authenticating DATA chunks can be provided [RFC4895]. authenticating DATA chunks can be provided [RFC4895].
Receive: Messages are received from an association, and optionally a Receive: Messages are received from an association, and optionally a
stream within the association, with their size returned. The stream within the association, with their size returned. The
application is notified of the availability of data via a 'Data application is notified of the availability of data via a 'Data
Arrive' notification. If the sender has included a payload Arrive' notification. If the sender has included a payload
protocol-id, this value is also returned. If the received message protocol-id, this value is also returned. If the received message
is only a partial delivery of a whole message, a partial flag will 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 indicate so, in which case the stream id and a stream sequence
number are provided to the application. A delivery number lets number are provided to the application.
the application detect reordering.
Shutdown: This primitive gracefully closes an association, reliably Shutdown: This primitive gracefully closes an association, reliably
delivering any data that has already been handed over to SCTP. A delivering any data that has already been handed over to SCTP. A
parameter lets the application control whether further receive or parameter lets the application control whether further receive or
send operations or both are disabled when the call is issued. A send operations or both are disabled when the call is issued. A
return code informs about success or failure of this procedure. return code informs about success or failure of this procedure.
Abort: This ungracefully closes an association, by discarding any Abort: This ungracefully closes an association, by discarding any
locally queued data and informing the peer that the association locally queued data and informing the peer that the association
was aborted. Optionally, an abort reason to be passed to the peer was aborted. Optionally, an abort reason to be passed to the peer
skipping to change at page 33, line 39 skipping to change at page 33, line 39
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
'stream sequence number' must be provided such that an application 'stream sequence number' must be provided such that an application
can restore the correct order of data blocks that comprise an can restore the correct order of data blocks that comprise an
entire message. Additionally, a delivery number lets the entire message.
application detect reordering.
o RECEIVE.UDP(-Lite): o RECEIVE.UDP(-Lite):
Pass 1 primitive / event: 'Receive', Pass 1 primitive / event: 'Receive',
Parameters: buffer for received datagram Parameters: buffer for received datagram
Comments: all CONNECTION.MAINTENANCE.GET_*.UDP(-Lite) primitives Comments: all CONNECTION.MAINTENANCE.GET_*.UDP(-Lite) primitives
apply per message received. apply per message received.
o SENDFAILURE-EVENT.SCTP: o SENDFAILURE-EVENT.SCTP:
Pass 1 primitive / event: 'Send Failure' notification, optionally Pass 1 primitive / event: 'Send Failure' notification, optionally
followed by 'Receive Unsent Message' or 'Receive Unacknowledged followed by 'Receive Unsent Message' or 'Receive Unacknowledged
skipping to change at page 42, line 20 skipping to change at page 42, line 20
o Choice of stream to receive from o Choice of stream to receive from
Protocols: SCTP Protocols: SCTP
o Information about partial message arrival o Information about partial message arrival
Protocols: SCTP Protocols: SCTP
Comments: in SCTP, partial messages are combined with a stream Comments: in SCTP, partial messages are combined with a stream
sequence number so that the application can restore the correct sequence number so that the application can restore the correct
order of data blocks an entire message consists of. order of data blocks an entire message consists of.
o Obtain a message delivery number
Protocols: SCTP
Comments: this number can let applications detect and, if desired,
correct reordering.
5.2.3. Errors 5.2.3. Errors
This section describes sending failures that are associated with a This section describes sending failures that are associated with a
specific call to DATA.SEND from pass 2. specific call to DATA.SEND from pass 2.
o Notification of an unsent (part of a) message o Notification of an unsent (part of a) message
Protocols: SCTP, UDP(-Lite) Protocols: SCTP, UDP(-Lite)
o Notification of an unacknowledged (part of a) message o Notification of an unacknowledged (part of a) message
Protocols: SCTP Protocols: SCTP
skipping to change at page 42, line 46 skipping to change at page 42, line 41
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,
Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly, Joe Touch and Spencer Dawkins, Aaron Falk, David Hayes, Karen Nielsen, Tommy Pauly,
Brian Trammell for providing valuable feedback on this document. We Joe Touch and Brian Trammell for providing valuable feedback on this
especially thank Christoph Paasch for providing input related to document. We especially thank Christoph Paasch for providing input
Multipath TCP, and Gorry Fairhurst and Tom Jones for providing input related to Multipath TCP, and Gorry Fairhurst and Tom Jones for
related to UDP(-Lite). This work has received funding from the providing input related to UDP(-Lite). This work has received
European Union's Horizon 2020 research and innovation programme under funding from the European Union's Horizon 2020 research and
grant agreement No. 644334 (NEAT). The views expressed are solely innovation programme under grant agreement No. 644334 (NEAT). The
those of the author(s). views expressed are solely those of 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
skipping to change at page 50, line 11 skipping to change at page 49, line 49
encompass both TCP and SCTP. Added citations of [RFC8095] and minset 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 [I-D.draft-gjessing-taps-minset] to the intro, to give the context of
this document. this document.
-05: minor fix to TCP authentication (comment from Joe Touch), -05: minor fix to TCP authentication (comment from Joe Touch),
several fixes from Gorry Fairhurst and Tom Jones. Language fixes; several fixes from Gorry Fairhurst and Tom Jones. Language fixes;
updated to align with latest taps-transport-usage-udp ID. updated to align with latest taps-transport-usage-udp ID.
-06: addressed WGLC comments from Aaron Falk and Tommy Pauly. -06: addressed WGLC comments from Aaron Falk and Tommy Pauly.
-07: addressed AD review comments from Spencer Dawkins.
-08: removed "delivery number" which was based on an error in RFC
4960: https://tools.ietf.org/html/
draft-ietf-tsvwg-rfc4960-errata-02#section-3.34.
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
Email: michawe@ifi.uio.no Email: michawe@ifi.uio.no
 End of changes. 11 change blocks. 
23 lines changed or deleted 22 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/