CIS 656, Spring 2005, Dr Ott.

Students in this class will do a project.

The project consists of two parts: Project A and project B.

Students will do project A in teams of one.

Students will do project B in teams of either one student or two 
students. Teams of two is recommended.

Students are encouraged to discuss how to tackle the projects on a 
``conceptual'' or ``idea'' level. Sharing code between teams is not 
allowed.

In both projects you will write and hand in a program. We will run the
program on a secret input, which consists of a set of IP Headers in
the format shown in example files on this page. Your grade depends
on for how many packets your program gives the correct output.

Your programs must be in either C, C++, or Java. It must run on an afs
computer (solaris, linux, unix), with either javac, cc, CC, gcc, or
g++.  It is very important you do your software development from the
start on a solaris or unix or linux computer. If you start on
microsoft, it will later be very hard to find all the tiny problems
that keep your code from running on afs.

So the way to do this is as follows: Use your laptop or PC to log
(from home or where-ever you happen to be) into an afs
computer. Create a directory (with a few subdirectories) for your
Project. Always work in that directory or those subdirectories.

Use of Java is a bit safer than use of C or C++: Due to the lawsuit 
Sun Microsystems won a few years ago, MS could not develop its own
non-conforming version of Java. 

You hand in your code with clear instructions on how to compile it. 
It must be a simple one-line command.
If the compiled file is called (say) a.out, your program must run with

a.out < inputfile > outputfile

(input and output redirection). ``inputfile'' and ``outputfile'' are of
course the names of the files from which we read and to which we
write. ( < and > stand for ``input redirection'' and 
``output redirection''.)

In project A you will take the input packet, compute all the fields
in the packet, and print the values of those fields. Examples are 
given on this page. 

The input file is in ``pseudo binary'': 32 characters per line, each
(supposedly) either a zero or a one.

In order to make grading easy, make sure to use exactly the same format
as in the example files.

In Project A, do not worry about the field ``Router 1'' that you see 
in the output. In project B you will have to deduce the router from
the input port. In project A, just say ``Router 1''.

The headers wil be:

Simple IP headers without options;
IP headers with strict source route, loose source route, record route, 
No-Op, EoO.

The content of the ``checksum field'' will be random and almost
certainly wrong. You will compute the value from the checksum bits in
the input file, and print it, but you will not check it for correctness.
(Unless you insist  :-)   ).

The first 6 bits of the ToS field will be interpreted as a single 
number (Differentiated Services Code Point) which you compute but do not 
interprete. The seventh bit is the ECN bit (ECN Capable Bit) and the 
eight bith is the CE bit (Congestion Experienced Bit). You will compute
them and print them, but you wil not interprete them.
These two bits will be discussed when we discuss TCP.

For project B you will be given a network description (layout and
description). For two of the routers in the network you will make a
routing table. The network will be ``somewhat similar to, but
different from'' the networks used in previous semesters of CIS 656.
These examples are still on the web, feel free to use them.

The input will consist of a sequence of IP headers and interfaces on 
which they enter the routers.
You will deduce the router from the interface. If it is not a router 
for which you were told to make a routing table, you can discard the 
packet, but not later packets!
Your program will give as output:
(usually) the interface on which the packet or fragments leave the router,
the next hop address if forwarded,
or ``direct delivery'' if approprate,
and will describe the packet or fragments. 
Your router must be able to do fragmentation, and must be able to do 
strict source route. (No loose source route or record route).
When appropriate, your router will drop a packet and send an ICMP packet, 
in that case you add a short sentence on the type of ICMP packet
(why the packet was dropped).

By the end of 02/12/2005 you will be able to do project A. In the next
few weeks you will learn enough to do project B.

It is recommended you do project A in such a way that you can use your
code in project B!

I put some error codes in, in case I goofed with the input. You do not
need to worry about those error codes. Apart from that, get your
output layout as identical as possible to the layout in the examples.

I may have errors in the input. I promise, there will never be an
error in HLEN of a header. Other errors your program must be able to
survive. I do not greatly care if your program ``mishandles'' an 
erroneous packet, but make sure it still correctly handles later packets
that are not erroneous!

Common errors I noticed in the past:

1. If there is a bad packet, a bad program does not recover and
   mishandles (or does not even read!) later packets.

2. If a longer header (larger HLEN) is followed by a shorter header
   (smaller HLEN), the later header ``inherits'' fields from previous
   headers. If that happens, you have not properly reset values before
   handling the next header.