An exemplifying demo
The long-term view behind Linux XIA is to crowdsource the future Internet. Accomplishing this view means (1) embracing old and new technologies, (2) lowering developing and deployment costs, and (3) nurturing a level-playing field for anyone to experiment with their ideas. The demo described in this page leverages a diverse set of technologies to substantiate this view of the future.
Our exemplifying demo show how zFilter, Digital fountain, and TCP/IP can interoperate to distribute content over XIA. zFilter is a multicast fabric developed for the PURSUIT FIA; read more about it on page zFilter principal. Digital fountain is a 15-year-old coding technology that adds reliability to open-loop multicast transmissions; see page Digital fountain. Any viable future Internet must interoperate with TCP/IP to lever all the infrastructure already deployed. To this end, our demo uses U4ID principal; see more about it on page 4ID principals.
This demo requires three machines, each with one network card, and
one machine with three network cards.
The former machines will be hosts, whereas the latter a router.
The machines should be put together following the following topology:
One can adapt this demo to run on virtual machines, but given that
the intention is to present this demo in public, we have chosen to
do it on real machines.
All machines must run a Linux XIA kernel, and have xiaconf package installed; see page How to install. The server and clients will need the Digital Fountain application; see page Digital fountain. The demo requires that Wireshark with XIA extensions is installed on one of the machines to inspect the traffic that the demo produces; see page Debugging the Linux kernel. The experimenter may prefer to have this Wireshark yet on a fifth machine to keep the demo isolated. The demo also requires tcpdump(8) on the router, but it is a good idea to have it installed on all machines to help with troubleshooting. On Ubuntu, tcpdump can be installed with the command:
$ sudo apt-get install tcpdump
Once the machines are connected together, and all the software is in place, one has to assign HIDs to each machine, and enumerate the HID associated to each machine as shown below:
### On the router # xip hid new router # xip hid getpub router hid-eefa98af7649d454b9f2b704012c307ced00f87a -----BEGIN PUBLIC KEY----- OMITTED -----END PUBLIC KEY----- ### On client A # xip hid new client-a # xip hid getpub client-a hid-4a17e52f5dcc9dbadf15497a52b6f3a214616cff -----BEGIN PUBLIC KEY----- OMITTED -----END PUBLIC KEY----- ### On client B # xip hid new client-b # xip hid getpub client-b hid-897f3aa1bb04ad9fd4022ce33678ba9accc83f3e -----BEGIN PUBLIC KEY----- OMITTED -----END PUBLIC KEY-----
Notice that the commands above do not assign an HID XID to the server since the server is not attached to an XIA network directly.
The next step is to install the digital fountain application on the server and clients A and B, and create the address files that will be used during the demo. The page Digital fountain describes how to install the digital fountain application; please repeat those steps on the server and clients.
On the server, create the following address files:
server-bind-addr
xdp-007f4e38904e83634acc7e1340ef7665e3f1f57a-0
server-dst-addr-v1
u4id-0a024702c3d70000000000000000000000000000-21: zf-0110000000000000000000000000000000000000-2: xdp-007f4e38904e83634acc7e1340ef7665e3f1f57b-210
server-dst-addr-v2
zf-1110000000000000000000000000000000000000-0
The address server-bind-addr is just the XDP XID to which the digital fountain server will bind. The address server-dst-addr-v1 is the canonical "iterative refinement" addressing style of the chain of XIDs: U4ID, zFilter, and XDP; see page XIA 101 to review this addressing style. Finally, address server-dst-addr-v2 is a single zFilter XID that includes the IP link from the server to the router, all other links present in the zFilter XID of address server-dst-addr-v1, and the clients' XDP XID.
On the clients, create the following address file:
client-bind-addr
xdp-007f4e38904e83634acc7e1340ef7665e3f1f57b-0
The address clind-bind-addr is just an XDP XID to which the digital fountain clients will bind.
One only needs to execute the steps of this section once, whereas the steps in the following sections are supposed to be executed after each reboot.
The server will use principals XDP, U4ID, and zFilter. XDP will create the packets, U4ID will encapsulate the XIP packets into IP/UDP payloads, and zFilter will redirect to U4ID in the second part of the demo.
The commands below set up the IP stack, load the XIA stack, and populate the routing table of XIA. All commands must be executed as root:
# Set up IP stack ifconfig eth0 10.2.71.1 netmask 255.255.255.252 \ broadcast 10.2.71.3 # Loading XIA stack modprobe xia modprobe xia_ppal_xdp modprobe xia_ppal_u4id modprobe xia_ppal_zf # Populating routing table xip u4id add 10.2.71.1 0xc3d7 -tunnel xip zf addroute 1000000000000000000000000000000000000000 \ gw u4id-0a024702c3d70000000000000000000000000000
Warning: if you are running a DHCP client on your machine, make sure that it will not remove the address just associated to eth0. You can either disable the DHCP client, or use one of the options that Linux offers to set a static address to an interface. The same applies to the IP address set on the router.
The server will use principals HID, U4ID, and zFilter. HID will forward the packets to the intend neighbor, U4ID will de-encapsulate the IP packets and handle the XIP packets to the XIA stack, and zFilter will redirect to HID.
The commands below set up the IP stack, load the XIA stack, and populate the routing table of XIA. All commands must be executed as root:
# Set up IP stack ifconfig eth0 10.2.71.2 netmask 255.255.255.252 \ broadcast 10.2.71.3 # Loading XIA stack modprobe xia modprobe xia_ppal_hid modprobe xia_ppal_u4id modprobe xia_ppal_zf # Populating routing table xip hid addaddr router xip u4id add 10.2.71.2 0xc3d7 xip zf addroute 0100000000000000000000000000000000000000 \ gw hid-4a17e52f5dcc9dbadf15497a52b6f3a214616cff xip zf addroute 0010000000000000000000000000000000000000 \ gw hid-897f3aa1bb04ad9fd4022ce33678ba9accc83f3e
Once the router is set up, one can test the IP link between server and router as follows:
ping 10.2.71.1
A working link will show an output similar to this one:
PING 10.2.71.1 (10.2.71.1) 56(84) bytes of data. 64 bytes from 10.2.71.1: icmp_seq=1 ttl=64 time=0.234 ms 64 bytes from 10.2.71.1: icmp_seq=2 ttl=64 time=0.294 ms 64 bytes from 10.2.71.1: icmp_seq=3 ttl=64 time=0.322 ms ^C --- 10.2.71.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.234/0.283/0.322/0.039 ms
The server will use principals XDP, HID, and zFilter. XDP will deliver the packets, HID will receive the packets from the neighbors (i.e. the router), and zFilter will redirect to XDP in the second part of the demo.
The commands below load the XIA stack, and populate the routing table of XIA. All commands must be executed as root:
# Loading XIA stack modprobe xia modprobe xia_ppal_xdp modprobe xia_ppal_hid modprobe xia_ppal_zf # Populating routing table xip hid addaddr client-a xip zf addroute 0100000000000000000000000000000000000000 \ gw xdp-007f4e38904e83634acc7e1340ef7665e3f1f57b
The server will use principals XDP, HID, and zFilter. XDP will deliver the packets, HID will receive the packets from the neighbors (i.e. the router), and zFilter will redirect to XDP in the second part of the demo.
The commands below load the XIA stack, and populate the routing table of XIA. All commands must be executed as root:
# Loading XIA stack modprobe xia modprobe xia_ppal_xdp modprobe xia_ppal_hid modprobe xia_ppal_zf # Populating routing table xip hid addaddr client-b xip zf addroute 0010000000000000000000000000000000000000 \ gw xdp-007f4e38904e83634acc7e1340ef7665e3f1f57b
Once the router and clients are set up, one can test the XIP links between router and clients running the following command on the router:
xip hid showneighs
The command above must list the HID XIDs of both client A and B like the example below:
to hid-4a17e52f5dcc9dbadf15497a52b6f3a214616cff lladdr: 00:90:f5:c6:44:5b dev: eth2 flags [] to hid-897f3aa1bb04ad9fd4022ce33678ba9accc83f3e lladdr: 00:90:f5:c6:44:46 dev: eth1 flags []
This demo consists of multicasting a file from the server to the clients
leveraging technologies that have not been designed to interoperate.
The demo consists of two parts.
The first part, entirely summarized in the figure below,
uses a vanilla XIP Address to reach the clients,
whereas the second part precisely repeats the whole experiment with
the shortest XIP address possible (i.e. the entry node and a single XID).
At step 1, the fountain application sends an XIP packet whose destination address is the one contained in the address file server-dst-addr-v1. Step 2 starts when XIP evaluates the destination address, and transfer control to principal U4ID. U4ID principal encapsulates the packet and handles it to TCP/IP stack, which, in turn, sends the packet to the router; step 3.
When the packet arrives at the router, TCP/IP receives it and handles the packet U4ID principal. U4ID drops the IP and UDP headers, and handles the XIP packet to XIP; step 4. Evaluating the destination address, the XIP running at the router decides to forward the packet using the zFilter XID of the address. zFilter principal duplicate the original XIP packet and send each copy to client A and B; step 5. At the clients, XIP delivers each packet to the socket associated to the XDP XID in the destination address. The above steps are repeated to each packet that the digital fountain sends to clients.
In order to run the demo, run the following command on each client:
ruby drink.rb client-bind-addr
Finally, to send the file, run the following command on the server:
ruby spray.rb server-bind-addr server-dst-addr-v1 data_file_path failure_rate
Replace data_file_path with any file you want to transmit.
A suggestion is to video tape the audience with a smartphone, and
transmit this file.
Replace failure_rate with the failure rate that you want to impose.
Although the digital fountain application is theoretically capable of handling
up to a 50% loss rate, a 5-10% loss rate is reasonable and suggested.
One can easily verify that the file was successfully received at the clients comparing the SHA1 hash of the files. Use the following commands to obtain the hashes:
# On the server sha1sum data_file_path # On client A sha1sum decoded/file-sent # On client B sha1sum decoded/file-sent
The packets that cross the wires can be analyzed in Wireshark running each of the following commands on different terminals on the router as root:
tcpdump -i eth0 -w eth0.dump tcpdump -i eth1 -w eth1.dump tcpdump -i eth2 -w eth2.dump
At the end of the demo, files eth1.dump and eth2.dump should be about the same size, whereas eth0.dump should be bigger due to the extra IP and UDP headers. Nevertheless, the number of packets in each dump file should be about the same.
The second part ot the demo consists in repeating all steps above using address file server-dst-addr-v2 instead of file server-dst-addr-v1. The result must be same because the zFilter XID in server-dst-addr-v2 (1) routing redirects to the U4ID XID used in server-dst-addr-v1 at the server, (2) follows the same steps of the experiment in the first part of this demo at the router, and (3) routing redirects to the XDP XID of the clients at each client.
This demo is complex and, as such, full of details. One trying to navigate all these details will find guidance to go through the details if one works out the answer of the following question: when is the last-node pointer updated throughout the demo? Our suggestion is to first answer this question using only your understand of XIA, and checking if your understanding is correct looking into the dump files. The correct answer is not trivial.
The exemplifying demo described on this page shows two important facts: (1) XIA can embed other network architectures, and (2) XIA promotes interoperability among its principals. The first fact makes concrete the component of our view that asks for "embracing old and new technologies". The old technologies are TCP/IP and Digital fountain, whereas the new ones are zFilter and XIA itself.
The second fact highlights what we expect to become a great source of value in XIA: principal interoperability. Interoperability enables principals to focus on the things they do best, and to delegate everything else to other principals. This creates a network effect in which a principal, when deployed, can add value to the whole network not only for adding a new function, but also for increasing the value of the other already deployed principals. For example, adding U4ID principal in an XIA network which already has principals zFilter, HID, and XDP already deployed, leverages the infrastructure allocated to the TCP/IP internet, and adds value to all the other principals that gain more opportunities to be used.
In conclusion, Linux XIA provides a level-playing field that enables all Internet stakeholders to crowdsource the future Internet. The ball is in your court.