Initial doc about multiplexed links and the issues with routing and

shaping with them. Also a discussion of jails and how they relate, and a
proposed solution using MAC addresses (potentially made up ones) to
perform the demultiplexing at the receiving node.

doc/multiplexed-links.txt

+From newbold@cs.utah.edu Tue Apr  1 11:11:13 2003
+Date: Tue, 1 Apr 2003 11:03:10 -0700 (MST)
+From: Mac Newbold <newbold@cs.utah.edu>
+To: Testbed Project <testbed@fast.cs.utah.edu>
+Subject: routing/shaping w/multiplexed links
+
+
+Here's notes from yesterday's discussion, and the proposed solution.
+
+What works now:
+
+A node A has 12 shaped virtual links (duplex links, not lans) multiplexed
+over 4 physical links. This works today, because all shaping in the
+non-LAN case happens on sending node. So it doesn't matter which virtual
+link the packet arrives on, since it doesn't affect routing or shaping.
+
+What doesn't work yet, but would be fixed by the proposed solution:
+
+1) shaped virtual multiplexed LANs
+ - For LANs, we have to do half of the shaping on the outgoing packet, and
+   the other half on the incoming packet. In order to do that, we need to
+   know which vlink it is coming in on to do the right shaping.
+
+2) multiple multiplexed links between the same two nodes
+ - You can't figure out which pipe it needs to be shaped by if there are
+   multiple vlinks/LANs between the same two nodes multiplexed on the same
+   interface.
+
+3) multiplexed links into a node with jails
+ - The phys. node needs to know which jail it belongs to, and which
+   routing table to use. If it is a shaped LAN, it also needs to figure
+   out which pipe to shape with.
+
+The proposed solution:
+
+The kernel can be modified to use information from the ethernet packet
+(specifically, the source MAC hardware address) to demultiplex. The
+receiving node can figure out what "virtual IP" the packet came to, and
+thus, which pipe and/or jail it came to, by looking up the source MAC
+ethernet hardware address in a table (ARP table, via RARP, or via a table
+generated and distributed apriori by emulab). The ARP and RARP approaches
+are most desirable, since they are not emulab specific, and simplify
+operation inside emulab.
+
+This works without changing any MAC addresses except in the case where
+there may be more than one virtual link on the source node that connects
+to the recieving node (probably an Emulab-only case, not something found
+in the real world). In this case, each virtual link would need a
+distict MAC address. We can do that by inventing MAC addresses for every
+virtual link endpoint. This set of endpoints is the same set of endpoints
+that we have to make up IP addresses for. So a one-to-one mapping of IP
+addresses and fake MAC addresses seems suitable.
+
+Chad and Rob suggested a good way to make these MAC addresses, that
+eliminates the need for a table. The top two bytes of the six byte MAC
+addr can be used for a tag that identifies a unique experiment in emulab.
+The lower four bytes can be the IP address assigned to that interface.
+Both nodes involved would have the new MAC addrs, and basically perform a
+proxy arp game for all of the MACs assigned to that interface. Then when a
+virtual link wanted to send a packet, the ethernet src MAC would have the
+sending IP in it, and the destination MAC would have the IP of the
+destination in it, and demultiplexing becomes trivial. This also works
+when there are multiple IP addresses in the same subnet assigned to the
+same interface, since we know which of the IPs it was intended for.
+
+The proposed meeting:
+
+We've got a 1:30pm round table, and I've got a 4pm commitment, so the
+proposed time (discussed w/Leigh and Mike already) is 2:30pm today. As Jay
+pointed out, we probably will not be able to use the CSL lib. but there
+are only about 5-6 people that need to come to this meeting anyway. So I
+nominate the south end ("snack room") table as the alternate location.
+
+Thanks,
+Mac
+
+--
+Mac Newbold		Univ. of Utah School of Computing
+newbold@cs.utah.edu	http://www.cs.utah.edu/~newbold/
+