Ouroboros Tutorial 02 - Revision history

Thijs: Use long form command line options in documentation & tutorials.

2023-11-30T11:56:13Z

Use long form command line options in documentation & tutorials.

← Older revision		Revision as of 11:56, 30 November 2023
Line 255:		Line 255:
	A small note on performance: don't worry too much about the latencies being hundreds of microseconds. That's because of CPU scaling and the system not doing much (and a little bit because we are using a debug build). Latencies drop to a few microseconds if the system is under load. To see this for yourself, you can run:		A small note on performance: don't worry too much about the latencies being hundreds of microseconds. That's because of CPU scaling and the system not doing much (and a little bit because we are using a debug build). Latencies drop to a few microseconds if the system is under load. To see this for yourself, you can run:

	$ oping -n oping-server -c 10000 -i 0 -Q		$ oping -n oping-server -c 10000 --interval 0 --quiet

	--- oping-server ping statistics ---		--- oping-server ping statistics ---

Thijs: More formatting

2023-11-30T11:50:04Z

More formatting

← Older revision		Revision as of 11:50, 30 November 2023
Line 198:		Line 198:
	==07907== irmd(II): Bound program /usr/bin/oping to name oping-server.		==07907== irmd(II): Bound program /usr/bin/oping to name oping-server.

	In our case, it found oping in /usr/bin oping.		In our case, it found oping in <code>/usr/bin/oping</code>.

	When we now start the oping server using the ''oping --listen'' command, we will see the following in the IRMd log:		When we now start the oping server using the ''oping --listen'' command, we will see the following in the IRMd log:
Line 241:		Line 241:
	Ouroboros will always use the ''lowest'' layer in the network to establish flows. To demonstrate this, see what happens if we register the name ''oping-server'' in the local layer:		Ouroboros will always use the ''lowest'' layer in the network to establish flows. To demonstrate this, see what happens if we register the name ''oping-server'' in the local layer:

	$ irm n r oping-server layer local-layer		$ irm n r oping-server layer local-layer

	and then run the oping client again. We see that the ipcpd-local is now used instead of the unicast Layer:		and then run the oping client again. We see that the ipcpd-local is now used instead of the unicast Layer:

Thijs: fix code formatting

2023-11-30T11:46:44Z

fix code formatting

← Older revision		Revision as of 11:46, 30 November 2023
Line 192:		Line 192:
	In [[Ouroboros Tutorial 01\| the first tutorial]], we first started the server and then bound that process to the ''oping-server'' name. Here, we will it a bit differently: will bind the program to that name.		In [[Ouroboros Tutorial 01\| the first tutorial]], we first started the server and then bound that process to the ''oping-server'' name. Here, we will it a bit differently: will bind the program to that name.

	$ irm b prog oping n oping-server auto -- --listen		$ irm b prog oping n oping-server auto -- --listen

	The command ''irm b prog'' is CLI shorthand for ''irm bind program''. It will look for the specified binary in some default locations.		The command ''irm b prog'' is CLI shorthand for ''irm bind program''. It will look for the specified binary in some default locations.

	==07907== irmd(II): Bound program /usr/bin/oping to name oping-server.		==07907== irmd(II): Bound program /usr/bin/oping to name oping-server.

	In our case, it found oping in /usr/bin oping.		In our case, it found oping in /usr/bin oping.

Dimitri at 16:19, 5 November 2023

2023-11-05T16:19:38Z

← Older revision		Revision as of 16:19, 5 November 2023
Line 4:		Line 4:

	The objective for this tutorial is to create a 2-layer network. We will add a simple 2-node ''unicast Layer'' on top of a [[ouroboros Tutorial 01 \| local Layer]] and will ping an oping server from an oping client over this network.		The objective for this tutorial is to create a 2-layer network. We will add a simple 2-node ''unicast Layer'' on top of a [[ouroboros Tutorial 01 \| local Layer]] and will ping an oping server from an oping client over this network.

	Initially, this will probably sound like gibberish, especially if configuring VLANs and defining IP subnets are your bread and butter, but once the concepts of ''flow allocation'' and ''binding / registering names'' become familiar, this will all 'click'.

	We recommend opening a couple of terminal windows for this tutorial.		We recommend opening a couple of terminal windows for this tutorial.

Dimitri at 15:17, 5 November 2023

2023-11-05T15:17:24Z

Show changes

Dimitri at 14:01, 5 November 2023

2023-11-05T14:01:38Z

@@ Line 38: / Line 38: @@
 After bootstrapping the IPCP, we see that it has no bound names yet. To be able to enroll, the second IPCP will need to ''allocate a flow'' to the first one (over the local Layer), and to be able to allocate the flow, the first IPCP will need to be bound to a name that is registered into the local Layer.
-When creating layers, we will leverage Ouroboros' ''anycast'': instead of binding the IPCP to a single name, we will bind it to ''two'' names: the first name will be unique for each IPCP and can be used to create flows to that specific IPCP,  the second name will be common for all IPCPs in the layer. This is useful for enrollment, as the new IPCP can enroll with any IPCP in the network.
+When creating layers, we will leverage Ouroboros' ''anycast'': instead of binding the IPCP to a single name, we will bind it to ''two'' names: the first name will be unique for each IPCP and can be used to create flows to that specific IPCP,  the second name will be common for all IPCPs in the layer. This is useful for enrollment, as the new IPCP can enroll with any IPCP in the network. Let's bind and register these names now:
   $ irm bind ipcp uni-1 name uni-1
@@ Line 44: / Line 44: @@
   $ irm name register uni-1 layer local-layer
   $ irm name register unicast-layer layer local-layer

Dimitri at 13:40, 5 November 2023

2023-11-05T13:40:49Z

← Older revision		Revision as of 13:40, 5 November 2023
Line 34:		Line 34:
	==07907== irmd(DB): This process accepts flows for:		==07907== irmd(DB): This process accepts flows for:

	~~To be able to enroll, the second IPCP will need to ''allocate a flow'' to the first one (over the local Layer). To be able to allocate the flow, the~~ first IPCP ~~will need to be bound to a name that is registered into the local Layer. When creating layers~~, ~~we will leverage Ouroboros' ''anycast'': instead of binding the IPCP to a single name, we will bind~~ it ~~to ''two'' names: the first name will be unique for each IPCP~~ and ~~can be used to create flows to that specific IPCP, the second name will be common for all IPCPs in the layer~~. ~~This~~ is ~~useful for enrollment~~, ~~as the new IPCP can enroll~~ with ~~any IPCP in the network~~.		The IRMd has created our first IPCP, in our case it has pid 8030 and got address 3241766228. It is using the default policies: explicit congestion notification (ECN), flat addressing, and link-state routing with a simple forwarding function. Other forwarding functions currently implemented are loop-free alternates and equal-cost multi-path.

	~~<syntaxhighlight>~~		After bootstrapping the IPCP, we see that it has no bound names yet. To be able to enroll, the second IPCP will need to ''allocate a flow'' to the first one (over the local Layer), and to be able to allocate the flow, the first IPCP will need to be bound to a name that is registered into the local Layer.
	$ irm bind ipcp uni-1 name uni-1
	$ irm bind ipcp uni-1 name unicast-layer		When creating layers, we will leverage Ouroboros' ''anycast'': instead of binding the IPCP to a single name, we will bind it to ''two'' names: the first name will be unique for each IPCP and can be used to create flows to that specific IPCP, the second name will be common for all IPCPs in the layer. This is useful for enrollment, as the new IPCP can enroll with any IPCP in the network.
	$ irm name register uni-1 layer local-layer
	$ irm name register unicast-layer layer local-layer		$ irm bind ipcp uni-1 name uni-1
	~~</syntaxhighlight>~~		$ irm bind ipcp uni-1 name unicast-layer
			$ irm name register uni-1 layer local-layer
			$ irm name register unicast-layer layer local-layer

Dimitri at 13:31, 5 November 2023

2023-11-05T13:31:34Z

← Older revision		Revision as of 13:31, 5 November 2023
Line 11:		Line 11:
	First, we will create a local ''loopback'' network like in the previous tutorial:		First, we will create a local ''loopback'' network like in the previous tutorial:

	~~<syntaxhighlight>~~		$ irm ipcp bootstrap type local name local-ipcp layer local-layer
	$ irm ipcp bootstrap type local name local-ipcp layer local-layer
	~~</syntaxhighlight>~~

	Now we will create the 2-node unicast network on top of this Local Layer 'network'.		Now we will create the 2-node unicast network on top of this Local Layer 'network'.
Line 19:		Line 17:
	To create this small unicast network, we ''bootstrap'' the first IPCP; and then enroll a second IPCP with that first IPCP.		To create this small unicast network, we ''bootstrap'' the first IPCP; and then enroll a second IPCP with that first IPCP.

	~~<syntaxhighlight>~~		$ irm ipcp bootstrap type unicast name uni-1 layer unicast-layer
	$ irm ipcp bootstrap type unicast name uni-1 layer unicast-layer
	~~</syntaxhighlight>~~

	Let's quickly have a look at the IRMd log, which shows the following output:		Let's quickly have a look at the IRMd log, which shows the following output:

Dimitri at 13:31, 5 November 2023

2023-11-05T13:31:06Z

← Older revision		Revision as of 13:31, 5 November 2023
Line 15:		Line 15:
	</syntaxhighlight>		</syntaxhighlight>

	Now we will ~~creating~~ the 2-node unicast network		Now we will create the 2-node unicast network on top of this Local Layer 'network'.

	To create this small unicast network, we ''bootstrap'' the first IPCP; and then enroll a second IPCP with that first IPCP. To be able to enroll, the second IPCP will need to ''allocate a flow'' to the first one (over the local Layer). To be able to allocate the flow, the first IPCP will need to be bound to a name that is registered into the local Layer. When creating layers, we will leverage Ouroboros' ''anycast'': instead of binding the IPCP to a single name, we will bind it to ''two'' names: the first name will be unique for each IPCP, and can be used to create flows to that specific IPCP. The second name will be common for all IPCPs in the layer.		To create this small unicast network, we ''bootstrap'' the first IPCP; and then enroll a second IPCP with that first IPCP.

	<syntaxhighlight>		<syntaxhighlight>
	$ irm ipcp bootstrap type unicast name uni-1 layer unicast-layer		$ irm ipcp bootstrap type unicast name uni-1 layer unicast-layer
			</syntaxhighlight>

			Let's quickly have a look at the IRMd log, which shows the following output:

			==07907== irmd(II): Created IPCP 8030.
			==08030== ipcpd/ipcp(II): Bootstrapping...
			==08030== unicast-ipcp(II): IPCP got address 3241766228.
			==08030== ca(DB): Using multi-bit ECN.
			==08030== link-state-routing(DB): Using link state routing policy.
			==08030== pff(DB): Using simple PFF policy.
			==08030== pff(DB): Using simple PFF policy.
			==08030== pff(DB): Using simple PFF policy.
			==08030== ipcpd/ipcp(II): Finished bootstrapping: 0.
			==07907== irmd(II): Bootstrapped IPCP 8030 in layer unicast-layer.
			==07907== irmd(DB): New instance (8030) of ipcpd-unicast added.
			==07907== irmd(DB): This process accepts flows for:

			To be able to enroll, the second IPCP will need to ''allocate a flow'' to the first one (over the local Layer). To be able to allocate the flow, the first IPCP will need to be bound to a name that is registered into the local Layer. When creating layers, we will leverage Ouroboros' ''anycast'': instead of binding the IPCP to a single name, we will bind it to ''two'' names: the first name will be unique for each IPCP and can be used to create flows to that specific IPCP, the second name will be common for all IPCPs in the layer. This is useful for enrollment, as the new IPCP can enroll with any IPCP in the network.

			<syntaxhighlight>
	$ irm bind ipcp uni-1 name uni-1		$ irm bind ipcp uni-1 name uni-1
	$ irm bind ipcp uni-1 name unicast-layer		$ irm bind ipcp uni-1 name unicast-layer

Dimitri at 13:23, 5 November 2023

2023-11-05T13:23:32Z

← Older revision		Revision as of 13:23, 5 November 2023
Line 2:		Line 2:

	The description of this tutorial uses a [[Ouroboros Build Parameters\|debug build]].		The description of this tutorial uses a [[Ouroboros Build Parameters\|debug build]].

			The objective for this tutorial is to create a 2-layer network. We will add a simple 2-node ''unicast Layer'' on top of a [[ouroboros Tutorial 01 \| local Layer]] and will ping an oping server from an oping client over this network.

			Initially, this will probably sound like gibberish, especially if configuring VLANs and defining IP subnets are your bread and butter, but once the concepts of ''flow allocation'' and ''binding / registering names'' become familiar, this will all 'click'.

			We recommend opening a couple of terminal windows for this tutorial.

			First, we will create a local ''loopback'' network like in the previous tutorial:

			<syntaxhighlight>
			$ irm ipcp bootstrap type local name local-ipcp layer local-layer
			</syntaxhighlight>

			Now we will creating the 2-node unicast network

			To create this small unicast network, we ''bootstrap'' the first IPCP; and then enroll a second IPCP with that first IPCP. To be able to enroll, the second IPCP will need to ''allocate a flow'' to the first one (over the local Layer). To be able to allocate the flow, the first IPCP will need to be bound to a name that is registered into the local Layer. When creating layers, we will leverage Ouroboros' ''anycast'': instead of binding the IPCP to a single name, we will bind it to ''two'' names: the first name will be unique for each IPCP, and can be used to create flows to that specific IPCP. The second name will be common for all IPCPs in the layer.

			<syntaxhighlight>
			$ irm ipcp bootstrap type unicast name uni-1 layer unicast-layer
			$ irm bind ipcp uni-1 name uni-1
			$ irm bind ipcp uni-1 name unicast-layer
			$ irm name register uni-1 layer local-layer
			$ irm name register unicast-layer layer local-layer
			</syntaxhighlight>