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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/