CIS 456, Spring 2006, Dr Ott. --- Addendum 03/04/2006. My apologies. This information has been on my website for over a week, but I failed to change the appropriate index.html file. Project A is due Monday March 20, 9:00 am, by Email. Project B is due Monday April 17, 9:00 am, by Email. Project A should not take you more than half a day, even if you are rusty in programming. But do not dawdle: you need to do project A in order to do project B, and project B is harder. I strongly recommend you try to do both projects over the academic break. (March 11 - 19). I also strongly recommend you hand in B way before April 17: It is getting too close to finals. I decided to go for Mr Cho's suggestion of ``extra credit''. Project A basic: Only packets without options. (See first example file). Project A extra credit: Packets without options, and packets with options. Only Record Route, Strict Source Route, Loose Source Route, and of course No-Op and EoO. Project B basic: Check for TTL (drop packet and send ICMP if appropriate), Check for packet size and MTU and DF bit (fragment if appropriate, drop and send ICMP if appropriate), Route (see examples). Project B extra credit: also redirect if appropriate. In project B I will not have IP options. (No need to code the ``address rotation'' etc of SSR and LSR). If you can not get ``fragmentation'' to work: hand in code that does not do fragmentation. You will get reduced credit, it will not be a disaster. Not handing in the code at all will be a disaster. (Or handing in code that does not do anything). --- Students in this class will do a project. The project consists of two parts: Project A and project B. Students will do both projects by themselves. 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 I read and to which I 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. There are two sets of examples: Example 1 (input and output) has 10 IP headers without options. Use this until we are finished with IP options. Example 2 (input and output) has 7 IP headers, with some options thrown in. Make sure your program gives identical output. 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 are given a network description (layout and description). For one 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 456 and 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 the 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). In project B you will take care only of IP headers without options. (No need to program the ``address rotation'' of strict and loose source route), but you will need to take care of fragmentation. (Write code for fragmentation). Also for project B there are two sets of examples on this web page. By the end of 02/17/2006 you will be able to do project A. In fact: you can do almost all of project A already now, feel free to start. 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.