multiplexed-links.txt 3.66 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80
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/