Ouroboros Functional Layering - Revision history

Dimitri: /* Application end-to-end layer */

2025-09-17T08:31:29Z

Application end-to-end layer

← Older revision		Revision as of 08:31, 17 September 2025
Line 27:		Line 27:

	The application end-to-end layer can provide the following operations:		The application end-to-end layer can provide the following operations:
	* Encryption (~~Public key or symmetric~~ key)		* Encryption (Symmetric key)
	* Reliability, implemented by the [[Flow_and_Retransmission_Control_Protocol\|FRCP protocol]]		* Reliability, implemented by the [[Flow_and_Retransmission_Control_Protocol\|FRCP protocol]]
	** Fragmentation		** Fragmentation
Line 36:		Line 36:
	* Integrity (hash-based checks such as CRC32)		* Integrity (hash-based checks such as CRC32)
	* Liveness monitoring		* Liveness monitoring
	* Authentication (validation/verification of certificate chains)

	All the above functionality is optional, and if reliability (FRCP) is disabled, we call the service a '''raw flow'''.		All the above functionality is optional, and if reliability (FRCP) is disabled, we call the service a '''raw flow'''.

Dimitri: /* O7s Layers vs RINA DIFs */

2025-08-17T06:48:51Z

O7s Layers vs RINA DIFs

← Older revision		Revision as of 06:48, 17 August 2025
Line 173:		Line 173:

	The 3-layer functional split in O7s raised a question for the location of FRCP: should it be part of the DIF, or part of the Application? It was immediately clear that putting it in the application solved some questions that arise with the RINA architecture.		The 3-layer functional split in O7s raised a question for the location of FRCP: should it be part of the DIF, or part of the Application? It was immediately clear that putting it in the application solved some questions that arise with the RINA architecture.
	# End-user application multi-homing (i.e. flows over different networks) is still a problem: only IPCPs can efficiently multi-home.		# End-user application multi-homing (i.e. flows over different networks) is still a problem in RINA: only IPCPs can efficiently multi-home. In O7s all processes can effectively multi-home.
	# Loss of IPCP state associated with DTCP (sequence numbers, DTCP windows) is not easily recoverable even when the application process survives.		# Loss of IPCP state associated with DTCP (sequence numbers, DTCP windows) after crash of an IPCP is not easily recoverable even when the application process survives.
	# Reliable flow allocation over a shim-DIF (needed by the IPCP) required the IPCP ~~allocating~~ flows over ''itself''.		# Reliable flow allocation over a shim-DIF (needed by the IPCP) required a hack for the IPCP to allocate a flows over ''itself''.
	# If an IPCP/DIF is needed to provided reliable IPC between two programs, who performs reliable IPC between those programs and the IPCP/DIF? The answer that the OS provides test-and-set is not satisfactory as it requires some (admittedly very reasonable) assumptions outside of the model that are not trivial.		# If an IPCP/DIF is needed to provided reliable IPC between two programs, who performs reliable IPC between those programs and the IPCP/DIF? The answer that the OS provides test-and-set is not satisfactory as it requires some (admittedly very reasonable) assumptions outside of the model that are not trivial.

Dimitri: /* Relation to Recursive InterNetwork Architecure (RINA) */

2025-08-17T06:45:44Z

Relation to Recursive InterNetwork Architecure (RINA)

← Older revision		Revision as of 06:45, 17 August 2025
Line 164:		Line 164:
	== Splitting data transfer control from data transfer ==		== Splitting data transfer control from data transfer ==

	RINA sees the [[Glossary#IP_fragmentation_problem\|IP fragmentation problem]] as evidence that the TCP/IP split was incorrect<ref>[https://ieeexplore.ieee.org/document/6126673 How in the Heck do you lose a layer!?]</ref>. The ~~proposed~~ solution is to keep the functionality of TCP and IP in a single logical layer and in a single protocol, called the Error and Flow Control Protocol (EFCP). EFCP is still subdivided in two component protocol (called Data Transfer Protocol (DTP) and Data Transfer Control Protocol (DTCP), but these two protocol ''share a state vector'' and are therefore not fully independent.		RINA sees the [[Glossary#IP_fragmentation_problem\|IP fragmentation problem]] as evidence that the TCP/IP split was incorrect<ref>[https://ieeexplore.ieee.org/document/6126673 How in the Heck do you lose a layer!?]</ref>. The solution put forward in RINA is to keep the functionality of TCP and IP in a single logical layer and in a single protocol, called the Error and Flow Control Protocol (EFCP). EFCP is still subdivided in two component protocol (called Data Transfer Protocol (DTP) and Data Transfer Control Protocol (DTCP), but these two protocol ''share a state vector'' and are therefore not fully independent.

	During the implementation of EFCP in Ouroboros we found that the functionality in EFCP (and thus TCP + IP) could (and therefore should) be split not in 2, but ''3'' independent layers: the application end-to-end layer, the network end-to-end layer and the network forwarding layer. The IP fragmentation problem is solved by putting the fragmentation bits in the [[Flow and Retransmission Control Protocol]] rather than the [[Ouroboros Data Transfer Protocol\|Data Transfer Protocol]] and the Flow Allocator reports the path maximum transmission unit (MTU) for a flow as input for the fragmentation function.		During the implementation of EFCP in Ouroboros we found that the functionality in EFCP (and thus TCP + IP) could (and therefore should) be split not in 2, but ''3'' independent layers: the application end-to-end layer, the network end-to-end layer and the network forwarding layer. The IP fragmentation problem is solved by putting the fragmentation bits in the [[Flow and Retransmission Control Protocol]] rather than the [[Ouroboros Data Transfer Protocol\|Data Transfer Protocol]] and the Flow Allocator reports the path maximum transmission unit (MTU) for a flow as input for the fragmentation function.

Dimitri: /* Layers and recursive networking */

2025-08-17T06:43:47Z

Layers and recursive networking

← Older revision		Revision as of 06:43, 17 August 2025
Line 91:		Line 91:
	= Layers and recursive networking =		= Layers and recursive networking =

	As an application end-to-end layer pairs with a corresponding network application end-to-layer, and the network flooding and network forwarding layers are part of a ''network application'', it is clear that the Ouroboros Unicast Model gives rise to a 'ham-and-cheese sandwich' structure that can be stacked repeatedly. If the network IPC API between the application and network end-to-end layers is a single universal standard, then all the Layers (capital L) in this sandwich can be moved around at will. This is what ~~we call~~ a '''recursive network'''. The Ouroboros model hints very strongly at recursion, but does not require it.		As an application end-to-end layer pairs with a corresponding network application end-to-layer, and the network flooding and network forwarding layers are part of a ''network application'', it is clear that the Ouroboros Unicast Model gives rise to a 'ham-and-cheese sandwich' structure that can be stacked repeatedly. If the network IPC API between the application and network end-to-end layers is a single universal standard, then all the Layers (capital L) in this sandwich can be moved around at will. This is what is called a '''recursive network'''. The Ouroboros model hints very strongly at recursion, but does not require it.

	== Unicast Layer ==		== Unicast Layer ==

Dimitri: /* Application end-to-end layer */

2024-11-17T12:48:26Z

Application end-to-end layer

← Older revision		Revision as of 12:48, 17 November 2024
Line 28:		Line 28:
	The application end-to-end layer can provide the following operations:		The application end-to-end layer can provide the following operations:
	* Encryption (Public key or symmetric key)		* Encryption (Public key or symmetric key)
	* Authentication (validation/verification of certificate chains, HMAC)
	* Reliability, implemented by the [[Flow_and_Retransmission_Control_Protocol\|FRCP protocol]]		* Reliability, implemented by the [[Flow_and_Retransmission_Control_Protocol\|FRCP protocol]]
	** Fragmentation		** Fragmentation
Line 37:		Line 36:
	* Integrity (hash-based checks such as CRC32)		* Integrity (hash-based checks such as CRC32)
	* Liveness monitoring		* Liveness monitoring
			* Authentication (validation/verification of certificate chains)

	All the above functionality is optional, and if reliability (FRCP) is disabled, we call the service a '''raw flow'''.		All the above functionality is optional, and if reliability (FRCP) is disabled, we call the service a '''raw flow'''.

Dimitri: /* Application end-to-end layer */

2024-11-10T08:27:52Z

Application end-to-end layer

← Older revision		Revision as of 08:27, 10 November 2024
Line 28:		Line 28:
	The application end-to-end layer can provide the following operations:		The application end-to-end layer can provide the following operations:
	* Encryption (Public key or symmetric key)		* Encryption (Public key or symmetric key)
			* Authentication (validation/verification of certificate chains, HMAC)
	* Reliability, implemented by the [[Flow_and_Retransmission_Control_Protocol\|FRCP protocol]]		* Reliability, implemented by the [[Flow_and_Retransmission_Control_Protocol\|FRCP protocol]]
	** Fragmentation		** Fragmentation

Dimitri: /* Network end-to-end layer / Flow Allocator */

2024-11-10T08:26:53Z

Network end-to-end layer / Flow Allocator

← Older revision		Revision as of 08:26, 10 November 2024
Line 48:		Line 48:
	We often refer to the Network End-to-End layer as the [[Flow allocator\|flow allocator]] after the core component in the IPCP that implements it.		We often refer to the Network End-to-End layer as the [[Flow allocator\|flow allocator]] after the core component in the IPCP that implements it.

	It provides ~~three~~ core functions:		It provides four core functions:
	# Name-to-address resolution: given a service name, find an address for a suitable IPCP that can serve as a destination for the network flow. The '''directory''' service holds this mapping for the layer.		# Name-to-address resolution: given a service name, find an address for a suitable IPCP that can serve as a destination for the network flow. The '''directory''' service holds this mapping for the layer.
	# Flow allocation: create shared state between the source and destination IPCP associated with a flow		# Flow allocation: create shared state between the source and destination IPCP associated with a flow
	## ~~Mutliplexing~~: generate a local Endpoint Identifier for a flow		## Multiplexing: generate a local Endpoint Identifier for a flow
	## Map this local Endpoint Identifier to the peer address		## Map this local Endpoint Identifier to the peer address
	# Congestion avoidance: Monitor the network flow for congestion and police throughput as needed.		# Congestion avoidance: Monitor the network flow for congestion and police throughput as needed.

Dimitri: /* Application end-to-end layer */

2024-11-10T08:26:15Z

Application end-to-end layer

← Older revision		Revision as of 08:26, 10 November 2024
Line 28:		Line 28:
	The application end-to-end layer can provide the following operations:		The application end-to-end layer can provide the following operations:
	* Encryption (Public key or symmetric key)		* Encryption (Public key or symmetric key)
	* Authentication (validation/verification of certificate chains, HMAC)
	* Reliability, implemented by the [[Flow_and_Retransmission_Control_Protocol\|FRCP protocol]]		* Reliability, implemented by the [[Flow_and_Retransmission_Control_Protocol\|FRCP protocol]]
	** Fragmentation		** Fragmentation

Dimitri at 06:27, 28 July 2024

2024-07-28T06:27:59Z

← Older revision		Revision as of 06:27, 28 July 2024
Line 1:		Line 1:
	[[File: O7s Model_01.png\|border\|right\|thumb\|frame\|Ouroboros network model - functional layering]]		[[File: O7s Model_01.png\|border\|right\|thumb\|frame\|Ouroboros network model - functional layering]]

	The Ouroboros model is the result of countless architectural refinements made during the (still ongoing) implementation of the Ouroboros prototype. The layered model [[Ouroboros multicast conjecture\|treats broadcast/multicast as distinct from unicast]].		The Ouroboros model is the result of countless architectural refinements made during the (still ongoing) implementation of the Ouroboros prototype. The layered model [[Ouroboros multicast conjecture\|treats broadcast/multicast as distinct from unicast]]. All layers in the model have a well-defined service API, which allows them to appear as black boxes to one another.

	The unicast model has 5 layers: the '''application layer''', the '''application end-to-end layer''', the '''network end-to-end layer''', the '''network forwarding layer''' and the '''transmission layer'''.		The unicast model has 5 layers: the '''application layer''', the '''application end-to-end layer''', the '''network end-to-end layer''', the '''network forwarding layer''' and the '''transmission layer'''.

	Broadcast is implemented by a '''network flooding layer'''.		Broadcast is implemented by a '''network flooding layer'''.

	~~All of these layers have a well-defined service API, which allows them to appear as black boxes to one another. The application layer requests~~ network services using the '''Unicast API''' and/or '''Broadcast API'''. For unicast, the application end-to-end layer interfaces with the network-end-to end layer via the '''Network IPC API''', which is invisible to the application itself. The network IPC API forms the demarcation line between 'the application' and 'the network'. The Broadcast API interfaces directly with the network flooding layer. Furthermore, a network (both of the unicast and broadcast variant) is seen as a distributed application, so it also inherits the application end-to-end layer, giving rise to a '''repeating network structure'''.		Applications request network services using the '''Unicast API''' and/or '''Broadcast API'''.

			For unicast, the application end-to-end layer interfaces with the network-end-to end layer via the '''Network IPC API''', which is invisible to the application itself. The network IPC API forms the demarcation line between 'the application' and 'the network'.

			The Broadcast API interfaces directly with the network flooding layer. Furthermore, a network (both of the unicast and broadcast variant) is seen as a distributed application, so it also inherits the application end-to-end layer, giving rise to a '''repeating network structure'''.

	This page provides an overview of this model as it currently stands, and some insights in how it compares to other models such as the TCP/IP Internet, Location/Identifier split and the Recursive InterNetwork Architecture (RINA).		This page provides an overview of this model as it currently stands, and some insights in how it compares to other models such as the TCP/IP Internet, Location/Identifier split and the Recursive InterNetwork Architecture (RINA).

Dimitri at 06:24, 28 July 2024

2024-07-28T06:24:03Z

← Older revision		Revision as of 06:24, 28 July 2024
Line 1:		Line 1:
	[[File: O7s Model_01.png\|border\|right\|thumb\|frame\|Ouroboros network model - functional layering]]		[[File: O7s Model_01.png\|border\|right\|thumb\|frame\|Ouroboros network model - functional layering]]

	The Ouroboros model is the result of countless architectural refinements made during the (still ongoing) implementation of the Ouroboros prototype. The model ~~has 5 layers: the '''application layer''', the '''application end-to-end layer''', the '''network end-to-end layer''', the '''network forwarding layer''' and the '''transmission layer'''~~.		The Ouroboros model is the result of countless architectural refinements made during the (still ongoing) implementation of the Ouroboros prototype. The layered model [[Ouroboros multicast conjecture\|treats broadcast/multicast as distinct from unicast]].

	The ~~layered~~ model ~~[[Ouroboros multicast conjecture\|treats broadcast/multicast as distinct from unicast]]~~. Broadcast is implemented by a '''network flooding layer'''.		The unicast model has 5 layers: the '''application layer''', the '''application end-to-end layer''', the '''network end-to-end layer''', the '''network forwarding layer''' and the '''transmission layer'''.

			Broadcast is implemented by a '''network flooding layer'''.

	All of these layers have a well-defined service API, which allows them to appear as black boxes to one another. The application layer requests network services using the '''Unicast API''' and/or '''Broadcast API'''. For unicast, the application end-to-end layer interfaces with the network-end-to end layer via the '''Network IPC API''', which is invisible to the application itself. The network IPC API forms the demarcation line between 'the application' and 'the network'. The Broadcast API interfaces directly with the network flooding layer. Furthermore, a network (both of the unicast and broadcast variant) is seen as a distributed application, so it also inherits the application end-to-end layer, giving rise to a '''repeating network structure'''.		All of these layers have a well-defined service API, which allows them to appear as black boxes to one another. The application layer requests network services using the '''Unicast API''' and/or '''Broadcast API'''. For unicast, the application end-to-end layer interfaces with the network-end-to end layer via the '''Network IPC API''', which is invisible to the application itself. The network IPC API forms the demarcation line between 'the application' and 'the network'. The Broadcast API interfaces directly with the network flooding layer. Furthermore, a network (both of the unicast and broadcast variant) is seen as a distributed application, so it also inherits the application end-to-end layer, giving rise to a '''repeating network structure'''.