draft-ietf-taps-arch-10.txt   draft-ietf-taps-arch-11.txt 
TAPS Working Group T. Pauly, Ed. TAPS Working Group T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track B. Trammell, Ed. Intended status: Standards Track B. Trammell, Ed.
Expires: 1 November 2021 Google Switzerland GmbH Expires: 13 January 2022 Google Switzerland GmbH
A. Brunstrom A. Brunstrom
Karlstad University Karlstad University
G. Fairhurst G. Fairhurst
University of Aberdeen University of Aberdeen
C. Perkins C. Perkins
University of Glasgow University of Glasgow
P. Tiesel P. Tiesel
SAP SE SAP SE
C.A. Wood C.A. Wood
Cloudflare Cloudflare
30 April 2021 12 July 2021
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-10 draft-ietf-taps-arch-11
Abstract Abstract
This document describes an architecture for exposing transport This document describes an architecture for exposing transport
protocol features to applications for network communication, the protocol features to applications for network communication, the
Transport Services architecture. The Transport Services Application Transport Services architecture. The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern. It uses messages for representing data transfer interaction pattern. It uses messages for representing data transfer
to applications, and it describes how implementations can use to applications, and it describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and multiple IP addresses, multiple protocols, and multiple paths, and
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 1 November 2021. This Internet-Draft will expire on 13 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 28 skipping to change at page 2, line 28
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specification of Requirements . . . . . . . . . . . . . . 5 1.3. Specification of Requirements . . . . . . . . . . . . . . 5
2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 7
2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 7 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 8
2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 8 2.3. Flexibile Implementation . . . . . . . . . . . . . . . . 9
3. API and Implementation Requirements . . . . . . . . . . . . . 9 3. API and Implementation Requirements . . . . . . . . . . . . . 9
3.1. Provide Common APIs for Common Features . . . . . . . . . 9 3.1. Provide Common APIs for Common Features . . . . . . . . . 10
3.2. Allow Access to Specialized Features . . . . . . . . . . 10 3.2. Allow Access to Specialized Features . . . . . . . . . . 10
3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 11 3.3. Select Equivalent Protocol Stacks . . . . . . . . . . . . 11
3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 12 3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 12
4. Transport Services Architecture and Concepts . . . . . . . . 12 4. Transport Services Architecture and Concepts . . . . . . . . 13
4.1. Transport Services API Concepts . . . . . . . . . . . . . 13 4.1. Transport Services API Concepts . . . . . . . . . . . . . 14
4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 15 4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 16
4.1.2. Connections and Related Objects . . . . . . . . . . . 15 4.1.2. Connections and Related Objects . . . . . . . . . . . 16
4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 16 4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 17
4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 17 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 18
4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 18 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 19
4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 19 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 20
4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 20 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 21
4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 20 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 21
4.2. Transport Services Implementation Concepts . . . . . . . 21 4.2. Transport Services Implementation Concepts . . . . . . . 22
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 22 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 23
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 22 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 23
4.2.3. Separating Connection Contexts . . . . . . . . . . . 23 4.2.3. Separating Connection Contexts . . . . . . . . . . . 24
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Many application programming interfaces (APIs) to perform transport Many application programming interfaces (APIs) to perform transport
networking have been deployed, perhaps the most widely known and networking have been deployed, perhaps the most widely known and
imitated being the BSD Socket [POSIX] interface (Socket API). The imitated being the BSD Socket [POSIX] interface (Socket API). The
naming of objects and functions across these APIs is not consistent, naming of objects and functions across these APIs is not consistent,
and varies depending on the protocol being used. For example, and varies depending on the protocol being used. For example,
sending and receiving streams of data is conceptually the same for sending and receiving streams of data is conceptually the same for
both an unencrypted Transmission Control Protocol (TCP) stream and both an unencrypted Transmission Control Protocol (TCP) stream and
skipping to change at page 5, line 11 skipping to change at page 5, line 11
Services API. These principles are intended to make sure that Services API. These principles are intended to make sure that
transport protocols can continue to be enhanced and evolve without transport protocols can continue to be enhanced and evolve without
requiring significant changes by application developers. requiring significant changes by application developers.
* Section 4 presents the Transport Services architecture diagram and * Section 4 presents the Transport Services architecture diagram and
defines the concepts that are used by both the API and defines the concepts that are used by both the API and
implementation documents. The Preconnection allows applications implementation documents. The Preconnection allows applications
to configure Connection Properties, and the Connection represents to configure Connection Properties, and the Connection represents
an object that can be used to send and receive Messages. an object that can be used to send and receive Messages.
* A Connection is an abstraction that represents the communication.
If the transport services interface selects a protocol such as TCP
for the communication, a Connection will correspond to an
underlying protocol connection. If however a protocol such as UDP
is selected, the Connection remains an abstraction at the end
points.
1.3. Specification of Requirements 1.3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. API Model 2. API Model
skipping to change at page 18, line 8 skipping to change at page 19, line 8
local or remote state to enable the transmission of Messages. For local or remote state to enable the transmission of Messages. For
some protocols, this will initiate a client-to-server style some protocols, this will initiate a client-to-server style
handshake; for other protocols, this will just establish local handshake; for other protocols, this will just establish local
state (e.g., with connectionless protocols such as UDP). The state (e.g., with connectionless protocols such as UDP). The
process of identifying options for connecting, such as resolution process of identifying options for connecting, such as resolution
of the Remote Endpoint, occurs in response to the Initiate call. of the Remote Endpoint, occurs in response to the Initiate call.
* Listen: Enables a listener to accept incoming Connections. The * Listen: Enables a listener to accept incoming Connections. The
Listener will then create Connection objects as incoming Listener will then create Connection objects as incoming
connections are accepted (Section 4.1.6). Listeners by default connections are accepted (Section 4.1.6). Listeners by default
register with multiple paths, protocols, and local endpoints, register with multiple paths, protocols, and Local Endpoints,
unless constrained by Selection Properties and/or the specified unless constrained by Selection Properties and/or the specified
Local Endpoint(s). Connections can be accepted on any of the Local Endpoint(s). Connections can be accepted on any of the
available paths or endpoints. available paths or endpoints.
* Rendezvous: The action of establishing a peer-to-peer connection * Rendezvous: The action of establishing a peer-to-peer connection
with a Remote Endpoint. It simultaneously attempts to initiate a with a Remote Endpoint. It simultaneously attempts to initiate a
connection to a Remote Endpoint while listening for an incoming connection to a Remote Endpoint while listening for an incoming
connection from that endpoint. The process of identifying options connection from that endpoint. The process of identifying options
for the connection, such as resolution of the Remote Endpoint, for the connection, such as resolution of the Remote Endpoint,
occurs in response to the Rendezvous call. As with Listeners, the occurs in response to the Rendezvous call. As with Listeners, the
skipping to change at page 25, line 8 skipping to change at page 26, line 8
helped shape the architecture described here. Thanks as well to helped shape the architecture described here. Thanks as well to
Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear for Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear for
their implementation and design efforts, including Happy Eyeballs, their implementation and design efforts, including Happy Eyeballs,
that heavily influenced this work. that heavily influenced this work.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., Pauly, Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A.,
T., and K. Rose, "An Abstract Application Layer Interface Pauly, T., and K. Rose, "An Abstract Application Layer
to Transport Services", Work in Progress, Internet-Draft, Interface to Transport Services", Work in Progress,
draft-ietf-taps-interface-12, 9 April 2021, Internet-Draft, draft-ietf-taps-interface-12, 9 April
<https://www.ietf.org/internet-drafts/draft-ietf-taps- 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
interface-12.txt>. taps-interface-12>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-taps-impl] [I-D.ietf-taps-impl]
Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K.,
Jones, T., Tiesel, P., Perkins, C., and M. Welzl, Jones, T., Tiesel, P. S., Perkins, C., and M. Welzl,
"Implementing Interfaces to Transport Services", Work in "Implementing Interfaces to Transport Services", Work in
Progress, Internet-Draft, draft-ietf-taps-impl-08, 2 Progress, Internet-Draft, draft-ietf-taps-impl-09, 30
November 2020, <https://www.ietf.org/internet-drafts/ April 2021, <https://datatracker.ietf.org/doc/html/draft-
draft-ietf-taps-impl-08.txt>. ietf-taps-impl-09>.
[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology
-- Portable Operating System Interface (POSIX). Open -- Portable Operating System Interface (POSIX). Open
group Technical Standard: Base Specifications, Issue 7", group Technical Standard: Base Specifications, Issue 7",
2008. 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/rfc/rfc793>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/rfc/rfc4303>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/rfc/rfc6265>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/rfc/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/rfc/rfc7540>.
[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, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/info/rfc8095>. <https://www.rfc-editor.org/rfc/rfc8095>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/rfc/rfc8305>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/rfc/rfc8445>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. [RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C.
Wood, "A Survey of the Interaction between Security Wood, "A Survey of the Interaction between Security
Protocols and Transport Services", RFC 8922, Protocols and Transport Services", RFC 8922,
DOI 10.17487/RFC8922, October 2020, DOI 10.17487/RFC8922, October 2020,
<https://www.rfc-editor.org/info/rfc8922>. <https://www.rfc-editor.org/rfc/rfc8922>.
[RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport [RFC8923] Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", RFC 8923, DOI 10.17487/RFC8923, Services for End Systems", RFC 8923, DOI 10.17487/RFC8923,
October 2020, <https://www.rfc-editor.org/info/rfc8923>. October 2020, <https://www.rfc-editor.org/rfc/rfc8923>.
Authors' Addresses Authors' Addresses
Tommy Pauly (editor) Tommy Pauly (editor)
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014, Cupertino, California 95014,
United States of America United States of America
Email: tpauly@apple.com Email: tpauly@apple.com
 End of changes. 25 change blocks. 
52 lines changed or deleted 59 lines changed or added

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