rfc9621v6.txt		rfc9621.txt
	skipping to change at line 12 ¶		skipping to change at line 12 ¶
	Internet Engineering Task Force (IETF) T. Pauly, Ed.		Internet Engineering Task Force (IETF) T. Pauly, Ed.
	Request for Comments: 9621 Apple Inc.		Request for Comments: 9621 Apple Inc.
	Category: Standards Track B. Trammell, Ed.		Category: Standards Track B. Trammell, Ed.
	ISSN: 2070-1721 Google Switzerland GmbH		ISSN: 2070-1721 Google Switzerland GmbH
	A. Brunstrom		A. Brunstrom
	Karlstad University		Karlstad University
	G. Fairhurst		G. Fairhurst
	University of Aberdeen		University of Aberdeen
	C. S. Perkins		C. S. Perkins
	University of Glasgow		University of Glasgow
	December 2024		January 2025
	Architecture and Requirements for Transport Services		Architecture and Requirements for Transport Services
	Abstract		Abstract
	This document describes an architecture that exposes transport		This document describes an architecture that exposes transport
	protocol features to applications for network communication. The		protocol features to applications for network communication. The
	Transport Services Application Programming Interface (API) is based		Transport Services Application Programming Interface (API) is based
	on an asynchronous, event-driven interaction pattern. This API uses		on an asynchronous, event-driven interaction pattern. This API uses
	Messages for representing data transfer to applications and describes		Messages for representing data transfer to applications and describes
	skipping to change at line 46 ¶		skipping to change at line 46 ¶
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc9621.		https://www.rfc-editor.org/info/rfc9621.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2025 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	skipping to change at line 527 ¶		skipping to change at line 527 ¶
	that arrived;		that arrived;
	* the ability to automatically assign Messages and connections to		* the ability to automatically assign Messages and connections to
	underlying transport connections to utilize multistreaming and		underlying transport connections to utilize multistreaming and
	create Pooled Connections.		create Pooled Connections.
	Allowing applications to interact with Messages is backward-		Allowing applications to interact with Messages is backward-
	compatible with existing protocols and APIs because it does not		compatible with existing protocols and APIs because it does not
	change the wire format of any protocol. Instead, it provides the		change the wire format of any protocol. Instead, it provides the
	Protocol Stack with additional information to allow it to make better		Protocol Stack with additional information to allow it to make better
	use of modern Transport Services, while simplifying the application's		use of modern transport protocols, while simplifying the
	role in parsing data. For protocols that inherently use a streaming		application's role in parsing data. For protocols that inherently
	abstraction, Framers (Section 4.1.5) bridge the gap between the two		use a streaming abstraction, Framers (Section 4.1.5) bridge the gap
	abstractions.		between the two abstractions.
	2.3. Flexible Implementation		2.3. Flexible Implementation
	The Socket API for protocols like TCP is generally limited to		The Socket API for protocols like TCP is generally limited to
	connecting to a single address over a single interface (IP source		connecting to a single address over a single interface (IP source
	address). It also presents a single stream to the application.		address). It also presents a single stream to the application.
	Software layers built upon this API often propagate this limitation		Software layers built upon this API often propagate this limitation
	of a single-address single-stream model. The Transport Services		of a single-address single-stream model. The Transport Services
	Architecture is designed to:		Architecture is designed to:
	skipping to change at line 616 ¶		skipping to change at line 616 ¶
	robustness to failure, or some other metric.		robustness to failure, or some other metric.
	Beyond these, if the Transport Services API remains the same over		Beyond these, if the Transport Services API remains the same over
	time, new protocols and features can be added to the Transport		time, new protocols and features can be added to the Transport
	Services Implementation without requiring changes in applications for		Services Implementation without requiring changes in applications for
	adoption. Similarly, this can provide a common basis for utilizing		adoption. Similarly, this can provide a common basis for utilizing
	information about a network path or interface, enabling evolution		information about a network path or interface, enabling evolution
	below the transport layer.		below the transport layer.
	The normative requirements described in this section allow Transport		The normative requirements described in this section allow Transport
	Services APIs and the Transport Services Implementation to provide		Services APIs and the Transport Services Implementations to provide
	this functionality without causing incompatibility or introducing		this functionality without causing incompatibility or introducing
	security vulnerabilities.		security vulnerabilities.
	3.1. Provide Common APIs for Common Features		3.1. Provide Common APIs for Common Features
	Any functionality that is common across multiple transport protocols		Any functionality that is common across multiple transport protocols
	SHOULD be made accessible through a unified set of calls using the		SHOULD be made accessible through a unified set of calls using the
	Transport Services API. As a baseline, any Transport Services API		Transport Services API. As a baseline, any Transport Services API
	SHOULD allow access to the minimal set of features offered by		SHOULD allow access to the minimal set of features offered by
	transport protocols [RFC8923]. If that minimal set is updated or		transport protocols [RFC8923]. If that minimal set is updated or
	skipping to change at line 1281 ¶		skipping to change at line 1281 ¶
	routes, addresses, and physical and virtual network interfaces.		routes, addresses, and physical and virtual network interfaces.
	Protocol Instance: A single instance of one protocol, including any		Protocol Instance: A single instance of one protocol, including any
	state necessary to establish connectivity or send and receive		state necessary to establish connectivity or send and receive
	Messages.		Messages.
	Protocol Stack: A set of protocol instances (including relevant		Protocol Stack: A set of protocol instances (including relevant
	application, security, transport, or Internet protocols) that are		application, security, transport, or Internet protocols) that are
	used together to establish connectivity or send and receive		used together to establish connectivity or send and receive
	Messages. A single stack can be simple (e.g., one application		Messages. A single stack can be simple (e.g., one application
	stream carried TCP running over IP) or complex (e.g,. multiple		stream carried over TCP running over IP) or complex (e.g,.
	application streams carried over a multipath transport protocol		multiple application streams carried over a multipath transport
	using multiple subflows over IP).		protocol using multiple subflows over IP).
	Candidate Path: One path that is available to an application and		Candidate Path: One path that is available to an application and
	conforms to the Selection Properties and System Policy, of which		conforms to the Selection Properties and System Policy, of which
	there can be several. Candidate Paths are identified during the		there can be several. Candidate Paths are identified during the
	gathering phase (Section 4.2.1) and can be used during the racing		gathering phase (Section 4.2.1) and can be used during the racing
	phase (Section 4.2.2).		phase (Section 4.2.2).
	Candidate Protocol Stack: One Protocol Stack that can be used by an		Candidate Protocol Stack: One Protocol Stack that can be used by an
	application for a connection, for which there can be several		application for a connection, for which there can be several
	candidates. Candidate Protocol Stacks are identified during the		candidates. Candidate Protocol Stacks are identified during the
	skipping to change at line 1534 ¶		skipping to change at line 1534 ¶
	<https://www.rfc-editor.org/info/rfc9113>.		<https://www.rfc-editor.org/info/rfc9113>.
	[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",		[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
	STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,		STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
	<https://www.rfc-editor.org/info/rfc9293>.		<https://www.rfc-editor.org/info/rfc9293>.
	[RFC9622] Trammell, B., Ed., Welzl, M., Ed., Enghardt, R.,		[RFC9622] Trammell, B., Ed., Welzl, M., Ed., Enghardt, R.,
	Fairhurst, G., Kühlewind, M., Perkins, C. S., Tiesel, P.,		Fairhurst, G., Kühlewind, M., Perkins, C. S., Tiesel, P.,
	and T. Pauly, "An Abstract Application Programming		and T. Pauly, "An Abstract Application Programming
	Interface (API) for Transport Services", RFC 9622,		Interface (API) for Transport Services", RFC 9622,
	DOI 10.17487/RFC9622, December 2024,		DOI 10.17487/RFC9622, January 2025,
	<https://www.rfc-editor.org/info/rfc9622>.		<https://www.rfc-editor.org/info/rfc9622>.
	[RFC9623] Brunstrom, A., Ed., Pauly, T., Ed., Enghardt, R., Tiesel,		[RFC9623] Brunstrom, A., Ed., Pauly, T., Ed., Enghardt, R., Tiesel,
	P., and M. Welzl, "Implementing Interfaces to Transport		P., and M. Welzl, "Implementing Interfaces to Transport
	Services", RFC 9623, DOI 10.17487/RFC9623, December 2024,		Services", RFC 9623, DOI 10.17487/RFC9623, January 2025,
	<https://www.rfc-editor.org/info/rfc9623>.		<https://www.rfc-editor.org/info/rfc9623>.
	Acknowledgements		Acknowledgements
	This work has received funding from the European Union's Horizon 2020		This work has received funding from the European Union's Horizon 2020
	research and innovation programme under grant agreements No. 644334		research and innovation programme under grant agreements No. 644334
	(NEAT), No. 688421 (MAMI), and No. 815178 (5GENESIS).		(NEAT), No. 688421 (MAMI), and No. 815178 (5GENESIS).
	This work has been supported by:		This work has been supported by:
End of changes. 7 change blocks.
	12 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.48.