MCS-394 Lab 4: Link Layer (Spring 2002)
Due: May 8, 2002 (note postponement from initial syllabus)
Optional extra credit portion due: May 20, 2002
Objectives
In this lab, you will program the "learning" feature for a simple
simulated network bridge. That is, you will make the simulated bridge
pay attention to what source addresses are seen arriving through each
port, so that it when those addresses are used as destinations, the
bridge can direct traffic to only the relevant port. For the main
part of the lab, you will have to manually ensure that the bridges are
never connected in a cycle. For extra credit, you may optionally also
program a simplified version of the spanning-tree protocol, which
allows bridges to be connected in cycles by automatically turning off
some of the ports. If you choose to do the extra-credit portion, it
will carry as much additional credit as the main lab, 6% of the
course total (as calculated without extra credit). You may do
the lab either singly or with one partner. This applies to the main
lab and, independently, to the extra credit option.
The simulated network
The simulated network consists of three kinds of devices:
each of which has one or more Ports. A
Host has only one Port, whereas a Hub or Bridge can be constructed
with any specified number of Ports. Each Port on a Hub or Bridge is
referenced by number starting from 0; for example, a four-port Hub
refers to its Ports as numbers 0, 1, 2, and 3. These device-specific
port numbers are distinct from the addresses of the Ports, which are
unique across the whole network. (Even the Ports on Hubs have
addresses, unrealistically. You can just ignore these addresses; they
should never be used as source or destination addresses.) Each Port
can be connected to another Port, in which case they are known as
peers of each other. Any Message
transmitted by one of the Ports is received by the other, and treated
appropriately for the kind of device it is part of. Hosts simply
print out a textual report of the Message either being received (if
the destination address is a match) or ignored (otherwise). Hubs and
Bridges may forward the Message out through other Ports.
The simulated network is built using Java. For simplicity, you will
work with it in the BlueJ
environment, as I will demonstrate in class. This will allow you to
not only work with the code, but also interactively create objects
that are instances of the classes, invoke methods on those objects,
and inspect them. That way you will have full, direct access, without
needing a user interface for the simulation.
One unrealistic aspect of the simulation is that it makes no attempt
to accurately model the passage of time. When a Message is
transmitted, all the consequent actions elsewhere in the network will
take place one by one, at a pace and in an order that is determined
just by the way in which the Java methods call each other. There is
no concurrency; the whole simulation takes place within a single Java
thread. Bridges will need to do some housekeeping at intervals, for
example, to "age" and eventually discard learned addresses that have
not been seen in a while. To simulate this, you can manually invoke
the Bridge class's allTick
method, which notifies each Bridge that some time has passed.
Note that Bridges as provided to you are actually essentially the same
as Hubs. Both forward any Message received on one Port out all the
others. Only once you have modified the Bridge class to at least do
learning will it really deserve the name.
To experiment with the simulation, you will first need to download a
copy of the file BridgeLab.tar.gz.
Then you can unpack that file, creating a directory BridgeLab that
contains all the Java files, documentation, and the rest of the stuff
BlueJ needs. To do the unpacking, you can in a shell give the command
tar xzf BridgeLab.tar.gz
You can now run BlueJ by giving the command
~max/bluej/bluej BridgeLab &
Note that printing from BlueJ doesn't seem to be working at the
moment. To work around this, you can print Java files using shell
commands. For example, you could do
mpage -2f BridgeLab/Bridge.java | lpr -Pmcs-lab
For your initial experiments, try connecting some Hosts and Hubs in an
acyclic fashion. Verify that any message sent by any Host reaches all
the others, even if it winds up getting ignored based on the
destination address. Verify that this remains true even when the
network has already had a chance to see the addresses in question.
You can also repeat this with Bridges if you want, since they are
essentially the same as Hubs at this point. You can also try out a
cyclic network, though then you'll need to kill BlueJ.
Learning bridges
Modify the Bridge class so that each Bridge keeps track of addresses
it has learned and which one of the Bridge's Ports those addresses
correspond to. Messages destined for learned addresses should only be
forwarded out the single Port. (However, no message should ever be
forwarded to the port it arrived on.) Initially don't worry about aging and
discarding table entries. You may want to use a HashMap
to represent the table.
Verify experimentally that once a Host has transmitted a Message,
subsequent Messages destined for that Host aren't seen (and ignored)
by all the other Hosts. Also, verify experimentally that if you
disconnect a Host and reconnect it elsewhere in the network, Messages
destined for it may be lost (even if the Bridge class's allTick method
has been invoked repeatedly), until the relocated Host broadcasts a
Message of its own so as to give the Bridges a chance to learn its new
location.
Now add in aging. Each entry in the table should gain age each time
the tick method is invoked, and when an entry reaches some maximum
age, it should be removed.
Verify experimentally that so long as a Host keeps communicating
reasonably frequently (relative to the ticking), its entry remains,
but if it falls silent, the entry is removed. Repeat the experiment
of relocating a Host after the Bridges have learned about it. Do the
allTick method a few times and then try sending a Message to the
relocated Host. Hopefully the Message won't be lost now.
Lab report
Explain the experiments you have conducted and what you observed, as
well as showing your modifications to the Bridge class. You may
assume that the reader is familiar with networking concepts (including
bridging) and has access to this lab assignment.
Extra credit option
You may turn in a second lab report (by the later due date shown
above) in which you implement a spanning tree protocol.
You can find the spanning tree protocol in all its gory detail in
Clause 8 (pp. 58-109) of the ANSI/IEEE
Standard 802.1D, 1998 Edition. In practice, all you may
actually need to pay attention to are sections 8.1-8.3.3, pp. 58-63.
Even section 8.3.3 (regarding the aging of the spanning tree
information to allow for reconfiguration of the network) would be
something you could initially leave out and add in once you have the
basics working. You should also disregard anything pertaining to
"management." If you choose to work on the spanning tree protocol, I
would urge you to talk with me about it. I can also provide the
relevant portion of the 802.1D standard in hardcopy form if that would help.
Course web site: http://www.gac.edu/~max/courses/S2002/MCS-394/
Instructor: Max Hailperin <max@gac.edu>