rfc9623v6.txt		rfc9623.txt
	skipping to change at line 12 ¶		skipping to change at line 12 ¶
	Internet Engineering Task Force (IETF) A. Brunstrom, Ed.		Internet Engineering Task Force (IETF) A. Brunstrom, Ed.
	Request for Comments: 9623 Karlstad University		Request for Comments: 9623 Karlstad University
	Category: Informational T. Pauly, Ed.		Category: Informational T. Pauly, Ed.
	ISSN: 2070-1721 Apple Inc.		ISSN: 2070-1721 Apple Inc.
	R. Enghardt		R. Enghardt
	Netflix		Netflix
	P.S. Tiesel		P.S. Tiesel
	SAP SE		SAP SE
	M. Welzl		M. Welzl
	University of Oslo		University of Oslo
	December 2024		January 2025
	Implementing Interfaces to Transport Services		Implementing Interfaces to Transport Services
	Abstract		Abstract
	The Transport Services System enables applications to use transport		The Transport Services System enables applications to use transport
	protocols flexibly for network communication and defines a protocol-		protocols flexibly for network communication and defines a protocol-
	independent Transport Services Application Programming Interface		independent Transport Services Application Programming Interface
	(API) that is based on an asynchronous, event-driven interaction		(API) that is based on an asynchronous, event-driven interaction
	pattern. This document serves as a guide to implementing such a		pattern. This document serves as a guide to implementing such a
	skipping to change at line 43 ¶		skipping to change at line 43 ¶
	Internet Engineering Steering Group (IESG). Not all documents		Internet Engineering Steering Group (IESG). Not all documents
	approved by the IESG are candidates for any level of Internet		approved by the IESG are candidates for any level of Internet
	Standard; see Section 2 of RFC 7841.		Standard; see 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/rfc9623.		https://www.rfc-editor.org/info/rfc9623.
	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 313 ¶		skipping to change at line 313 ¶
	identify the paths, protocols, and endpoints to use (see		identify the paths, protocols, and endpoints to use (see
	Section 4.2) and		Section 4.2) and
	* Candidate Racing (defined in Section 4.2.2 of [RFC9621]), in which		* Candidate Racing (defined in Section 4.2.2 of [RFC9621]), in which
	the necessary protocol handshakes are conducted so that the		the necessary protocol handshakes are conducted so that the
	Transport Services System can select which set to use (see		Transport Services System can select which set to use (see
	Section 4.3).		Section 4.3).
	Candidate Racing involves attempting multiple options for Connection		Candidate Racing involves attempting multiple options for Connection
	establishment and choosing the first option to succeed as the		establishment and choosing the first option to succeed as the
	Protocol Stack to use for the connection. These attempts are usually		Protocol Stack to use for the Connection. These attempts are usually
	staggered, with each next option starting after a delay; however,		staggered, with each next option starting after a delay; however,
	they can also be performed in parallel or after failures occur.		they can also be performed in parallel or after failures occur.
	For ease of illustration, this document structures the candidates for		For ease of illustration, this document structures the candidates for
	racing as a tree (see Section 4.1). This is not meant to restrict		racing as a tree (see Section 4.1). This is not meant to restrict
	implementations from structuring racing candidates differently.		implementations from structuring racing candidates differently.
	The simplest example of this process might involve identifying the		The simplest example of this process might involve identifying the
	single IP address to which the implementation wishes to connect,		single IP address to which the implementation wishes to connect,
	using the system's current default path (i.e., using the default		using the system's current default path (i.e., using the default
	skipping to change at line 588 ¶		skipping to change at line 588 ¶
	different supported IP versions. Implementations need to be careful		different supported IP versions. Implementations need to be careful
	to branch in a consistent order that results in usable leaf nodes		to branch in a consistent order that results in usable leaf nodes
	whenever there are multiple branch types that could be used from a		whenever there are multiple branch types that could be used from a
	single node.		single node.
	This document recommends the following order of operations for		This document recommends the following order of operations for
	branching:		branching:
	1. Network paths		1. Network paths
	2. Protocol Options		2. Protocol options
	3. Derived Endpoints		3. Derived Endpoints
	where a lower number indicates higher precedence and, therefore,		where a lower number indicates higher precedence and, therefore,
	higher placement in the tree. Branching between paths is the first		higher placement in the tree. Branching between paths is the first
	in the list because results across multiple interfaces are likely not		in the list because results across multiple interfaces are likely not
	related to one another: endpoint resolution may return different		related to one another: endpoint resolution may return different
	results, especially when using locally resolved host and service		results, especially when using locally resolved host and service
	names and the protocols that are supported and preferred may differ		names and the protocols that are supported and preferred may differ
	across interfaces. Thus, if multiple paths are attempted, the		across interfaces. Thus, if multiple paths are attempted, the
	overall Connection establishment process can be seen as a race		overall Connection establishment process can be seen as a race
	between the available paths or interfaces.		between the available paths or interfaces.
	Protocol Options are next checked in order. Whether or not a set of		Protocol options are next checked in order. Whether or not a set of
	protocols, or protocol-specific options, can successfully connect is		protocols, or protocol-specific options, can successfully connect is
	generally not dependent on which specific IP address is used.		generally not dependent on which specific IP address is used.
	Furthermore, the Protocol Stacks being attempted may influence or		Furthermore, the Protocol Stacks being attempted may influence or
	altogether change the Endpoint Identifiers being used. Adding a		altogether change the Endpoint Identifiers being used. Adding a
	proxy to a connection's branch will change the Endpoint Identifier to		proxy to a connection's branch will change the Endpoint Identifier to
	the proxy's IP address or hostname. Choosing an alternate protocol		the proxy's IP address or hostname. Choosing an alternate protocol
	may also modify the ports that should be selected.		may also modify the ports that should be selected.
	Branching for derived endpoints is the final step and may have		Branching for derived endpoints is the final step and may have
	multiple layers of derivation or resolution, such as DNS service		multiple layers of derivation or resolution, such as DNS service
	skipping to change at line 782 ¶		skipping to change at line 782 ¶
	involve a directory service and can require communication between the		involve a directory service and can require communication between the
	Remote Endpoint and a rendezvous server as well as the exchange of		Remote Endpoint and a rendezvous server as well as the exchange of
	peer addresses. This can expose some or all of the candidate Local		peer addresses. This can expose some or all of the candidate Local
	Endpoints to the Remote Endpoint.		Endpoints to the Remote Endpoint.
	4.3. Candidate Racing		4.3. Candidate Racing
	The primary goal of the Candidate Racing process is to successfully		The primary goal of the Candidate Racing process is to successfully
	negotiate a Protocol Stack to an Endpoint over an interface to		negotiate a Protocol Stack to an Endpoint over an interface to
	connect a single leaf node of the tree with as little delay and as		connect a single leaf node of the tree with as little delay and as
	few unnecessary connections attempts as possible. Optimizing these		few unnecessary connection attempts as possible. Optimizing these
	two factors improves the user experience, while minimizing network		two factors improves the user experience, while minimizing network
	load.		load.
	This section covers the dynamic aspect of Connection establishment.		This section covers the dynamic aspect of Connection establishment.
	The tree described above is a useful conceptual and architectural		The tree described above is a useful conceptual and architectural
	model. However, an implementation is unable to know all of the nodes		model. However, an implementation is unable to know all of the nodes
	that will be used until steps like name resolution have occurred;		that will be used until steps like name resolution have occurred;
	many of the possible branches ultimately might not be attempted.		many of the possible branches ultimately might not be attempted.
	There are three different approaches to racing the attempts for		There are three different approaches to racing the attempts for
	skipping to change at line 1307 ¶		skipping to change at line 1307 ¶
	Implementation, but an implementation ought to allow custom Message		Implementation, but an implementation ought to allow custom Message
	Framers to be defined by the application or some other piece of		Framers to be defined by the application or some other piece of
	software. This section describes one possible API for defining		software. This section describes one possible API for defining
	Message Framers as an example.		Message Framers as an example.
	6.1. Defining Message Framers		6.1. Defining Message Framers
	A Message Framer is primarily defined by the code that handles events		A Message Framer is primarily defined by the code that handles events
	for a Framer implementation, specifically how it handles inbound and		for a Framer implementation, specifically how it handles inbound and
	outbound data parsing. The function that implements custom framing		outbound data parsing. The function that implements custom framing
	logic will be referred to as the "Framer implementation", which may		logic will be referred to as the "Framer Implementation", which may
	be provided by a Transport Services implementation or the application		be provided by a Transport Services Implementation or the application
	itself. The Message Framer holds a reference to the object or		itself. The Message Framer holds a reference to the object or
	function within the main Connection implementation that delivers		function within the main Connection implementation that delivers
	events to the custom Framer implementation whenever data is ready to		events to the custom Framer implementation whenever data is ready to
	be parsed or framed.		be parsed or framed.
	The API examples in this section use the notation conventions for the		The API examples in this section use the notation conventions for the
	Transport Services API defined in Section 1.1 of [RFC9622].		Transport Services API defined in Section 1.1 of [RFC9622].
	The Transport Services Implementation needs to ensure that all of the		The Transport Services Implementation needs to ensure that all of the
	events and actions taken on a Message Framer are synchronized to		events and actions taken on a Message Framer are synchronized to
	skipping to change at line 1641 ¶		skipping to change at line 1641 ¶
	Examples of cached protocol state include:		Examples of cached protocol state include:
	* The DNS protocol can cache resolved addresses (such as those		* The DNS protocol can cache resolved addresses (such as those
	retrieved from A and AAAA queries) associated with a Time To Live		retrieved from A and AAAA queries) associated with a Time To Live
	(TTL) to be used for future hostname resolutions without requiring		(TTL) to be used for future hostname resolutions without requiring
	asking the DNS resolver again.		asking the DNS resolver again.
	* TLS caches session state and tickets based on a hostname, which		* TLS caches session state and tickets based on a hostname, which
	can be used for resuming sessions with a server.		can be used for resuming sessions with a server.
	* TCP can cache cookies for use in TFO		* TCP can cache cookies for use in TFO.
	Cached protocol state is primarily used during Connection		Cached protocol state is primarily used during Connection
	establishment for a single Protocol Stack, but it may be used to		establishment for a single Protocol Stack, but it may be used to
	influence an implementation's preference between several candidate		influence an implementation's preference between several Candidate
	Protocol Stacks. For example, if two IP address Endpoint Identifiers		Protocol Stacks. For example, if two IP address Endpoint Identifiers
	are otherwise equally preferred, an implementation may choose to		are otherwise equally preferred, an implementation may choose to
	attempt a connection to an address for which it has a TFO cookie.		attempt a connection to an address for which it has a TFO cookie.
	Applications can use the Transport Services API to request that a		Applications can use the Transport Services API to request that a
	Connection Group maintain a separate cache for protocol state.		Connection Group maintain a separate cache for protocol state.
	Connections in the group will not use Cached State from Connections		Connections in the group will not use Cached State from Connections
	outside the group, and Connections outside the group will not use		outside the group, and Connections outside the group will not use
	state cached from Connections inside the group. This may be		state cached from Connections inside the group. This may be
	necessary, for example, if application-layer identifiers rotate and		necessary, for example, if application-layer identifiers rotate and
	skipping to change at line 1796 ¶		skipping to change at line 1796 ¶
	ConnectionError: Once established, TCP throws errors whenever the		ConnectionError: Once established, TCP throws errors whenever the
	connection is disconnected, such as due to receiving a RST from		connection is disconnected, such as due to receiving a RST from
	the peer.		the peer.
	Listen: LISTEN.TCP. Calling Listen for TCP binds a local port and		Listen: LISTEN.TCP. Calling Listen for TCP binds a local port and
	prepares it to receive inbound SYN packets from peers.		prepares it to receive inbound SYN packets from peers.
	ConnectionReceived: TCP Listeners will deliver new connections once		ConnectionReceived: TCP Listeners will deliver new connections once
	they have replied to an inbound SYN with a SYN-ACK.		they have replied to an inbound SYN with a SYN-ACK.
	Clone: Calling Clone on a TCP connection creates a new Connection		Clone: Calling Clone on a TCP connection creates a new TCP
	with equivalent parameters. These Connections, and Connections		connection with equivalent parameters. The two associated
	generated via later calls to Clone on an Established Connection,		Connection objects, and Connections generated via later calls to
	form a Connection Group. To realize entanglement for these		Clone on an Established Connection, form a Connection Group. To
	Connections, with the exception of connPriority, changing a		realize entanglement for these Connections, with the exception of
	Connection Property on one of them must affect the Connection		connPriority, changing a Connection Property on one of them must
	Properties of the others too. No guarantees of honoring the		affect the Connection Properties of the others too. No guarantees
	connPriority Connection Property are given; thus, it is safe for		of honoring the connPriority Connection Property are given; thus,
	an implementation of a Transport Services System to ignore this		it is safe for an implementation of a Transport Services System to
	Property. When it is reasonable to assume that Connections		ignore this Property. When it is reasonable to assume that
	traverse the same path (e.g., when they share the same		Connections traverse the same path (e.g., when they share the same
	encapsulation), support for it can also experimentally be		encapsulation), support for it can also experimentally be
	implemented using a congestion control coupling mechanism (for		implemented using a congestion control coupling mechanism (for
	example, see [TCP-COUPLING] or [RFC3124]).		example, see [TCP-COUPLING] or [RFC3124]).
	Send: SEND.TCP. On its own, TCP does not preserve Message		Send: SEND.TCP. On its own, TCP does not preserve Message
	boundaries. Calling Send on a TCP connection lays out the bytes		boundaries. Calling Send on a TCP connection lays out the bytes
	on the TCP send stream without any other delineation. Any Message		on the TCP send stream without any other delineation. Any Message
	marked as Final will cause TCP to send a FIN once the Message has		marked as Final will cause TCP to send a FIN once the Message has
	been completely written, by calling CLOSE.TCP immediately upon		been completely written, by calling CLOSE.TCP immediately upon
	successful termination of SEND.TCP. Note that transmitting a		successful termination of SEND.TCP. Note that transmitting a
	skipping to change at line 1831 ¶		skipping to change at line 1831 ¶
	Receive: With RECEIVE.TCP, TCP delivers a stream of bytes without		Receive: With RECEIVE.TCP, TCP delivers a stream of bytes without
	any Message delineation. All data delivered in the Received or		any Message delineation. All data delivered in the Received or
	ReceivedPartial event will be part of a single stream-wide Message		ReceivedPartial event will be part of a single stream-wide Message
	that is marked Final (unless a Message Framer is used). The value		that is marked Final (unless a Message Framer is used). The value
	of the endOfMessage Property will be delivered when the TCP		of the endOfMessage Property will be delivered when the TCP
	connection has received a FIN (CLOSE-EVENT.TCP) from the peer.		connection has received a FIN (CLOSE-EVENT.TCP) from the peer.
	Note that reception of a FIN should not cause the Closed event to		Note that reception of a FIN should not cause the Closed event to
	be delivered to the application, as it will still be possible for		be delivered to the application, as it will still be possible for
	the application to send data.		the application to send data.
	Close: Calling Close on a TCP connection indicates that the		Close: Calling Close on a TCP connection indicates that the TCP
	Connection should be gracefully closed (CLOSE.TCP) by sending a		connection should be gracefully closed (CLOSE.TCP) by sending a
	FIN to the peer. It will then still be possible to receive data		FIN to the peer. It will then still be possible to receive data
	until the peer closes or aborts the TCP connection. The Closed		until the peer closes or aborts the TCP connection. The Closed
	event will be issued upon reception of a FIN.		event will be issued upon reception of a FIN.
	Abort: Calling Abort on a TCP connection indicates that the		Abort: Calling Abort on a TCP connection indicates that the TCP
	Connection should be immediately closed by sending a RST to the		connection should be immediately closed by sending a RST to the
	peer (ABORT.TCP).		peer (ABORT.TCP).
	CloseGroup: Calling CloseGroup on a TCP connection (CLOSE.TCP) is		CloseGroup: Calling CloseGroup on a TCP connection (CLOSE.TCP) is
	identical to calling Close on this Connection and on all		identical to calling Close on its Connection object and on all
	Connections in the same ConnectionGroup.		Connections in the same ConnectionGroup.
	AbortGroup: Calling AbortGroup on a TCP connection (ABORT.TCP) is		AbortGroup: Calling AbortGroup on a TCP connection (ABORT.TCP) is
	identical to calling Abort on this Connection and on all		identical to calling Abort on its Connection object and on all
	Connections in the same ConnectionGroup.		Connections in the same ConnectionGroup.
	10.2. MPTCP		10.2. MPTCP
	Connectedness: Connected		Connectedness: Connected
	Data Unit: Byte-stream		Data Unit: Byte-stream
	The Transport Services API mappings for MPTCP are identical to TCP.		The Transport Services API mappings for MPTCP are identical to TCP.
	MPTCP adds support for multipath Properties, such as multipath and		MPTCP adds support for multipath Properties, such as multipath and
	skipping to change at line 1873 ¶		skipping to change at line 1873 ¶
	Data Unit: Datagram		Data Unit: Datagram
	Connection Object: UDP connections represent a pair of specific IP		Connection Object: UDP connections represent a pair of specific IP
	addresses and ports on two hosts.		addresses and ports on two hosts.
	Initiate: CONNECT.UDP. Calling Initiate on a UDP connection causes		Initiate: CONNECT.UDP. Calling Initiate on a UDP connection causes
	it to reserve a local port but does not generate any traffic.		it to reserve a local port but does not generate any traffic.
	InitiateWithSend: Early data on a UDP connection does not have any		InitiateWithSend: Early data on a UDP connection does not have any
	special meaning. The data is sent whenever the Connection is		special meaning. The data is sent whenever the connection is
	Ready.		Ready.
	Ready: A UDP connection is ready once the system has reserved a		Ready: A UDP connection is ready once the system has reserved a
	local port and has a path to send to the Remote Endpoint.		local port and has a path to send to the Remote Endpoint.
	EstablishmentError: UDP connections can only generate errors on		EstablishmentError: UDP connections can only generate errors on
	initiation due to port conflicts on the local system.		initiation due to port conflicts on the local system.
	ConnectionError: UDP connections can only generate Connection errors		ConnectionError: UDP connections can only generate Connection errors
	in response to Abort actions. (Once in use, UDP connections can		in response to Abort actions. (Once in use, UDP connections can
	also generate SoftError events (ERROR.UDP) upon receiving ICMP		also generate SoftError events (ERROR.UDP) upon receiving ICMP
	notifications indicating failures in the network.)		notifications indicating failures in the network.)
	Listen: LISTEN.UDP. Calling Listen for UDP binds a local port and		Listen: LISTEN.UDP. Calling Listen for UDP binds a local port and
	prepares it to receive inbound UDP datagrams from peers.		prepares it to receive inbound UDP datagrams from peers.
	ConnectionReceived: UDP Listeners will deliver new connections once		ConnectionReceived: UDP Listeners will deliver new Connections once
	they have received traffic from a new Remote Endpoint.		they have received traffic from a new Remote Endpoint.
	Clone: Calling Clone on a UDP connection creates a new Connection		Clone: Calling Clone on a UDP connection creates a new connection
	with equivalent parameters. The two Connections are otherwise		with equivalent parameters. The two Connection objects are
	independent.		otherwise independent.
	Send: SEND.UDP. Calling Send on a UDP connection sends the data as		Send: SEND.UDP. Calling Send on a UDP connection sends the data as
	the payload of a complete UDP datagram. Marking Messages as Final		the payload of a complete UDP datagram. Marking Messages as Final
	does not change anything in the datagram's contents. Upon sending		does not change anything in the datagram's contents. Upon sending
	a UDP datagram, some relevant fields and flags in the IP header		a UDP datagram, some relevant fields and flags in the IP header
	can be controlled: DSCP (SET_DSCP.UDP), DF in IPv4 (SET_DF.UDP),		can be controlled: DSCP (SET_DSCP.UDP), DF in IPv4 (SET_DF.UDP),
	and ECN flag (SET_ECN.UDP).		and ECN flag (SET_ECN.UDP).
	Receive: RECEIVE.UDP. UDP only delivers complete Messages to		Receive: RECEIVE.UDP. UDP only delivers complete Messages to
	Received, each of which represents a single datagram received in a		Received, each of which represents a single datagram received in a
	UDP packet. Upon receiving a UDP datagram, the ECN flag from the		UDP packet. Upon receiving a UDP datagram, the ECN flag from the
	IP header can be obtained (GET_ECN.UDP).		IP header can be obtained (GET_ECN.UDP).
	Close: Calling Close on a UDP connection (ABORT.UDP) releases the		Close: Calling Close on a UDP connection (ABORT.UDP) releases the
	local port reservation. The Connection then issues a Closed		local port reservation. A Closed event is then issued.
	event.
	Abort: Calling Abort on a UDP connection (ABORT.UDP) is identical to		Abort: Calling Abort on a UDP connection (ABORT.UDP) is identical to
	calling Close except that the Connection will send a		calling Close except that a ConnectionError event rather than a
	ConnectionError event rather than a Closed event.		Closed event is issued.
	CloseGroup: Calling CloseGroup on a UDP connection (ABORT.UDP) is		CloseGroup: Calling CloseGroup on a UDP connection (ABORT.UDP) is
	identical to calling Close on this Connection and on all		identical to calling Close on its Connection object and on all
	Connections in the same ConnectionGroup.		Connections in the same ConnectionGroup.
	AbortGroup: Calling AbortGroup on a UDP connection (ABORT.UDP) is		AbortGroup: Calling AbortGroup on a UDP connection (ABORT.UDP) is
	identical to calling Close on this Connection and on all		identical to calling Close on its Connection object and on all
	Connections in the same ConnectionGroup.		Connections in the same ConnectionGroup.
	10.4. UDP-Lite		10.4. UDP-Lite
	Connectedness: Connectionless		Connectedness: Connectionless
	Data Unit: Datagram		Data Unit: Datagram
	The Transport Services API mappings for UDP-Lite are identical to		The Transport Services API mappings for UDP-Lite are identical to
	UDP. In addition, UDP-Lite supports the msgChecksumLen and		UDP. In addition, UDP-Lite supports the msgChecksumLen and
	skipping to change at line 1953 ¶		skipping to change at line 1952 ¶
	Connectedness: Connectionless		Connectedness: Connectionless
	Data Unit: Datagram		Data Unit: Datagram
	Connection Object: Established UDP Multicast Receive connections		Connection Object: Established UDP Multicast Receive connections
	represent a pair of specific IP addresses and ports. The		represent a pair of specific IP addresses and ports. The
	direction Selection Property must be set to Unidirectional		direction Selection Property must be set to Unidirectional
	receive, and the Local Endpoint must be configured with a group IP		receive, and the Local Endpoint must be configured with a group IP
	address and a port.		address and a port.
	Initiate: Calling Initiate on a UDP Multicast Receive Connection		Initiate: Calling Initiate on a UDP Multicast Receive connection
	causes an immediate EstablishmentError. This is an unsupported		causes an immediate EstablishmentError. This is an unsupported
	operation.		operation.
	InitiateWithSend: Calling InitiateWithSend on a UDP Multicast		InitiateWithSend: Calling InitiateWithSend on a UDP Multicast
	Receive Connection causes an immediate EstablishmentError. This		Receive connection causes an immediate EstablishmentError. This
	is an unsupported operation.		is an unsupported operation.
	Ready: A UDP Multicast Receive Connection is ready once the system		Ready: A UDP Multicast Receive connection is ready once the system
	has received traffic for the appropriate group and port.		has received traffic for the appropriate group and port.
	EstablishmentError: UDP Multicast Receive Connections generate an		EstablishmentError: UDP Multicast Receive connections cause an
	EstablishmentError indicating that joining a multicast group		EstablishmentError indicating that joining a multicast group
	failed if Initiate is called.		failed if Initiate is called.
	ConnectionError: The only ConnectionError generated by a UDP		ConnectionError: The only ConnectionError generated by a UDP
	Multicast Receive Connection is in response to an Abort action.		Multicast Receive connection is in response to an Abort action.
	Listen: LISTEN.UDP. Calling Listen for UDP Multicast Receive binds		Listen: LISTEN.UDP. Calling Listen for UDP Multicast Receive binds
	a local port, prepares it to receive inbound UDP datagrams from		a local port, prepares it to receive inbound UDP datagrams from
	peers, and issues a multicast host join. If a Remote Endpoint		peers, and issues a multicast host join. If a Remote Endpoint
	Identifier with an address is supplied, the join is Source-		Identifier with an address is supplied, the join is Source-
	Specific Multicast, and the path selection is based on the route		Specific Multicast, and the path selection is based on the route
	to the Remote Endpoint. If a Remote Endpoint Identifier is not		to the Remote Endpoint. If a Remote Endpoint Identifier is not
	supplied, the join is Any-Source Multicast, and the path selection		supplied, the join is Any-Source Multicast, and the path selection
	is based on the outbound route to the group supplied in the Local		is based on the outbound route to the group supplied in the Local
	Endpoint.		Endpoint.
	skipping to change at line 1994 ¶		skipping to change at line 1993 ¶
	application later opens a separate Connection to the same group to		application later opens a separate Connection to the same group to
	send signals to and/or receive signals from the common bus. In such		send signals to and/or receive signals from the common bus. In such
	cases, the Transport Services System needs to explicitly enable reuse		cases, the Transport Services System needs to explicitly enable reuse
	of the same set of addresses (equivalent to setting SO_REUSEADDR in		of the same set of addresses (equivalent to setting SO_REUSEADDR in
	the Socket API).		the Socket API).
	ConnectionReceived: UDP Multicast Receive Listeners will deliver new		ConnectionReceived: UDP Multicast Receive Listeners will deliver new
	Connections once they have received traffic from a new Remote		Connections once they have received traffic from a new Remote
	Endpoint.		Endpoint.
	Clone: Calling Clone on a UDP Multicast Receive Connection creates a		Clone: Calling Clone on a UDP Multicast Receive connection creates a
	new Connection with equivalent parameters. The two Connections		new UDP Multicast Receive connection with equivalent parameters.
	are otherwise independent.		The two associated Connection objects are otherwise independent.
	Send: SEND.UDP. Calling Send on a UDP Multicast Receive Connection		Send: SEND.UDP. Calling Send on a UDP Multicast Receive connection
	causes an immediate SendError. This is an unsupported operation.		causes an immediate SendError. This is an unsupported operation.
	Receive: RECEIVE.UDP. The Receive action in a UDP Multicast Receive		Receive: RECEIVE.UDP. UDP Multicast Receive only delivers complete
	Connection only delivers complete Messages to Received, each of		Messages to Received, each of which represents a single datagram
	which represents a single datagram received in a UDP packet. Upon		received in a UDP packet. Upon receiving a UDP datagram, the ECN
	receiving a UDP datagram, the ECN flag from the IP header can be		flag from the IP header can be obtained (GET_ECN.UDP).
	obtained (GET_ECN.UDP).
	Close: Calling Close on a UDP Multicast Receive Connection		Close: Calling Close on a UDP Multicast Receive connection
	(ABORT.UDP) releases the local port reservation and leaves the		(ABORT.UDP) releases the local port reservation and leaves the
	group. The Connection then issues a Closed event.		group. A Closed event is then issued.
	Abort: Calling Abort on a UDP Multicast Receive Connection		Abort: Calling Abort on a UDP Multicast Receive connection
	(ABORT.UDP) is identical to calling Close except that the		(ABORT.UDP) is identical to calling Close except that a
	Connection will send a ConnectionError event rather than a Closed		ConnectionError event rather than a Closed event is issued.
	event.
	CloseGroup: Calling CloseGroup on a UDP Multicast Receive Connection		CloseGroup: Calling CloseGroup on a UDP Multicast Receive connection
	(ABORT.UDP) is identical to calling Close on this Connection and		(ABORT.UDP) is identical to calling Close on its Connection object
	on all Connections in the same ConnectionGroup.		and on all Connections in the same ConnectionGroup.
	AbortGroup: Calling AbortGroup on a UDP Multicast Receive Connection		AbortGroup: Calling AbortGroup on a UDP Multicast Receive connection
	(ABORT.UDP) is identical to calling Close on this Connection and		(ABORT.UDP) is identical to calling Close on its Connection object
	on all Connections in the same ConnectionGroup.		and on all Connections in the same ConnectionGroup.
	10.6. SCTP		10.6. SCTP
	Connectedness: Connected		Connectedness: Connected
	Data Unit: Message		Data Unit: Message
	Connection Object: Connection objects can be mapped to an SCTP		Connection Object: Connection objects can be mapped to an SCTP
	association or a stream in an SCTP association. Mapping		association or a stream in an SCTP association. Mapping
	Connection objects to SCTP streams is called "stream mapping" and		Connection objects to SCTP streams is called "stream mapping" and
	skipping to change at line 2131 ¶		skipping to change at line 2128 ¶
	Receive: RECEIVE.SCTP. The "partial flag" of RECEIVE.SCTP invokes a		Receive: RECEIVE.SCTP. The "partial flag" of RECEIVE.SCTP invokes a
	ReceivedPartial event.		ReceivedPartial event.
	Close: If this is the only Connection object that is assigned to the		Close: If this is the only Connection object that is assigned to the
	SCTP association, CLOSE.SCTP is called and the Closed event will		SCTP association, CLOSE.SCTP is called and the Closed event will
	be delivered to the application upon the ensuing CLOSE-EVENT.SCTP.		be delivered to the application upon the ensuing CLOSE-EVENT.SCTP.
	Else, the Connection object is one out of several Connection		Else, the Connection object is one out of several Connection
	objects that are assigned to the same SCTP association, and		objects that are assigned to the same SCTP association, and
	RESET_STREAM.SCTP must be called, which informs the peer that the		RESET_STREAM.SCTP must be called, which informs the peer that the
	stream will no longer be used for mapping and can be used by		stream will no longer be used for mapping and can be used by a
	future Initiate, InitiateWithSend, or Listen action. At the peer,		future Initiate, InitiateWithSend, or Listen action. At the peer,
	the event RESET_STREAM-EVENT.SCTP will be initiated, which the		the event RESET_STREAM-EVENT.SCTP will be initiated, which the
	peer must answer by issuing RESET_STREAM.SCTP too. The resulting		peer must answer by issuing RESET_STREAM.SCTP too. The resulting
	local RESET_STREAM-EVENT.SCTP informs the Transport Services		local RESET_STREAM-EVENT.SCTP informs the Transport Services
	System that the stream id can now be reused by the next Initiate,		System that the stream id can now be reused by the next Initiate,
	InitiateWithSend, or Listen actions, and invokes a Closed event		InitiateWithSend, or Listen action, and invokes a Closed event
	toward the application.		toward the application.
	Abort: If this is the only Connection object that is assigned to the		Abort: If this is the only Connection object that is assigned to the
	SCTP association, ABORT.SCTP is called. Else, the Connection		SCTP association, ABORT.SCTP is called. Else, the Connection
	object is one out of several Connection objects that are assigned		object is one out of several Connection objects that are assigned
	to the same SCTP association, and shutdown proceeds as described		to the same SCTP association, and shutdown proceeds as described
	under Close.		under Close.
	CloseGroup: Calling CloseGroup calls CLOSE.SCTP, which closes all		CloseGroup: Calling CloseGroup calls CLOSE.SCTP, which closes all
	Connections in the SCTP association.		Connections in the SCTP association.
	skipping to change at line 2248 ¶		skipping to change at line 2245 ¶
	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/info/rfc8923>.
	[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,		[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
	DOI 10.17487/RFC9113, June 2022,		DOI 10.17487/RFC9113, June 2022,
	<https://www.rfc-editor.org/info/rfc9113>.		<https://www.rfc-editor.org/info/rfc9113>.
	[RFC9621] Pauly, T., Ed., Trammell, B., Ed., Brunstrom, A.,		[RFC9621] Pauly, T., Ed., Trammell, B., Ed., Brunstrom, A.,
	Fairhurst, G., and C. S. Perkins, "Architecture and		Fairhurst, G., and C. S. Perkins, "Architecture and
	Requirements for Transport Services", RFC 9621,		Requirements for Transport Services", RFC 9621,
	DOI 10.17487/RFC9621, December 2024,		DOI 10.17487/RFC9621, January 2025,
	<https://www.rfc-editor.org/info/rfc9621>.		<https://www.rfc-editor.org/info/rfc9621>.
	[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.
	S., and T. Pauly, "An Abstract Application Programming		S., 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>.
	13.2. Informative References		13.2. Informative References
	[NEAT-flow-mapping]		[NEAT-flow-mapping]
	Weinrank, F. and M. Tuxen, "Transparent flow mapping for		Weinrank, F. and M. Tuxen, "Transparent flow mapping for
	NEAT", 2017 IFIP Networking Conference (IFIP Networking)		NEAT", 2017 IFIP Networking Conference (IFIP Networking)
	and Workshops, DOI 10.23919/IFIPNetworking.2017.8264876,		and Workshops, DOI 10.23919/IFIPNetworking.2017.8264876,
	June 2017, <https://ieeexplore.ieee.org/document/8264876>.		June 2017, <https://ieeexplore.ieee.org/document/8264876>.
End of changes. 38 change blocks.
	68 lines changed or deleted		65 lines changed or added
This html diff was produced by rfcdiff 1.48.