This is a description of the project for CIS656_105 in the fall of 2001. The project is due on Wed Nov 28, 6:00 pm. (NOT 6:01. If you may be late for class, hand it in Tuesday Nov 27). A drawing of the network has been handed out in class. It can also be found in http://web.njit.edu/~ott/images/project_network.gif . (Currently that page gives a messy picture: will be improved). I will re-arrange my web page in the next few days. It may be safer to start at http://web.njit.edu/~ott and then follow the directions. The network has 15 Routers numbered 1 through 15. The network has 16 networks, numbered in Roman numerals. (I through XVI). This network is supposed to be the network of a company that owns the whole address space 170.170.0.0/16 . Part of that space is not used. The next table gives the network addresses and the MTUs of the various networks: Network Address MTU I 170.170.16.0/20 4464 II 170.170.32.0/20 65535 III 170.170.80.0/20 65535 IV 170.170.64.0/20 65535 V 170.170.144.0/20 65535 VI 170.170.8.0/24 1500 VII 170.170.48.0/20 65535 VIII 170.170.128.0/20 65535 IX 170.170.192.0/24 65535 X 170.170.5.0/24 1500 XI 170.170.4.0/24 1500 XII 170.170.96.0/20 1500 XIII 170.170.112.0/20 65535 XIV 170.170.0.0/24 1500 XV 170.170.1.0/24 1500 XVI 170.170.2.0/24 1500 --- To save you some time: 170 = 1010 1010 20 = 0001 0100 16 = 0001 0000 32 = 0010 0000 80 = 0101 0000 64 = 0100 0000 144 = 1001 0000 8 = 0000 1000 48 = 0011 0000 128 = 1000 0000 192 = 1100 0000 5 = 0000 0101 4 = 0000 0100 96 = 0110 0000 112 = 0111 0000 0 = 0000 0000 1 = 0000 0001 2 = 0000 0010 Added on 11/13/2001: List of IP addresses of Interfaces. Interface Address A1 (R1 to XI) 170.170.4.1 A2 (R1 to II) 170.170.40.0 A3 (R1 to III) 170.170.80.1 A4 (R1 to I) 170.170.24.0 A5 (R2 to II) 170.170.32.1 A6 (R2 to VII) 170.170.56.0 A7 (R4 to VII) 170.170.48.1 A8 (R4 to IV) 170.170.72.0 A9 (R10 to IV) 170.170.64.1 A10 (R10 to VI) 170.170.8.128 A11 (R3 to II) 170.170.32.2 A12 (R3 to VIII) 170.170.136.0 A13 (R5 to VIII) 170.170.128.1 A14 (R5 to V) 170.170.152.0 A15 (R6 to V) 170.170.144.1 A16 (R6 to IX) 170.170.192.128 A17 (R9 to XI) 170.170.4.2 A18 (R9 to X) 170.170.5.128 A19 (R7 to III) 170.170.80.2 A20 (R7 to XII) 170.170.104.0 A21 (R8 to XII) 170.170.96.1 A22 (R8 to XIII) 170.170.120.0 A23 (R15 to XIII) 170.170.112.1 A24 (R15 to UUNET) 10.0.0.1 (we wish! :-) ) A25 (R14 to III) 170.170.88.0 A26 (R14 to IX) 170.170.192.1 A27 (R14 to XIII) 170.170.116.0 A28 (R12 to I) 170.170.16.1 A29 (R12 to XV) 170.170.1.128 A30 (R11 to XV) 170.170.1.1 A31 (R11 to XiV) 170.170.0.128 A32 (R13 to I) 170.170.16.2 A33 (R13 to XVI) 170.170.2.128 --- (BTW, this network is not a very good engineering design!). Please check that I did not goof in the design, like having overlapping address spaces. Any packet with a destination address in 170.170.0.0/16 that is not in one of the 16 networks above must be considered ``network unreachable''. Any packet with a destination address outside 170.170.0.0/16 must follow a default route to UUNET. Assume that UUNET has an MTU of 65535. When a destination address is given on any of the networks above, and it is not a special adress (e.g. directed broadcast, or a forbidden address) assume that the host indeed exists on that network. Some networks drawn as ethernets are given an MTU of 65535. That is OK. All routing is based on the ``min hop'' principle: If there is more than one route from the source to the destination, the route must be followed that visits the minimum possible number of routers. For example, packets from Router R1 to Network IX take the path R1 -> III -> R14 -> IX , NOT R1 -> II -> R3 -> VIII -> R5 -> V -> R6 -> IX There is (at least) one case of a tie: from R1 to V. In that case, follow the route R1 -> II -> R3 -> VIII -> R5 -> V . When a packet is directed at a destination inside 170.170.0.0/16 but the network does not exist, the packet is dropped on the floor, usually with an ICMP message (network unreachable). --- Given any IP packet, you must generate the decision Router R1 would make for the packet. Assume no congestion. Possible actions are: --- Added on 11/13/2001: 0. Hand the packet over to the higher layer software in R1. (for example: a packet with destination address 170.170.4.1). Say: ``To R1 itself''. --- 1. Throw the packet on the floor, send ICMP packet to the source. Say ``floor, ICMP'' and give the type of the ICMP packet. NOT the packet layout of the icmp packet. 2. Throw the packet on the floor, do not send an ICMP packet. Say ``floor, no ICMP''. 3. Do direct delivery to the appropriate host. Say ``direct delivery'' and give the interface on R1 where the packet is sent out. Give the layout of the packet as sent out. The exact layout will be described later. 4. Do a broadcast to the appropriate network. Say ``broadcast'' and give the interface on R1 where the packet is sent out. Give the layout of the packet sent out. 5. Forward the packet to the next-hop router. Say ``forward'', give the interface on R1 where the packet is sent out and the interface on the next hop router the packet is forwarded to. Give the layout of the packet sent out. 6. Do one of (4), (5) above AND send an ICMP packet. Say ``ICMP'', give the type of the ICMP packet, and the information as in (4) or (5). 7. In case of fragmentation (really special cases of 3 , 4 , 5, 6) add the word ``fragment, '' and give the layouts of the packets sent. (Warning: a packet may have been fragmented before!, and a fragment may need to be fragmented further). Do not give the layout of ICMP packets sent (if any), just the type. 8. The only option I may (therefore occasionally will) attach to IP headers is the ``strict source route''. In that case, make sure you correctly modify the options field. (Unless ...). 9. What happens if a host on network III has a packet directed to (say) network IX, but sends it to router R1 (possibly because router R1 is its default router)? Simplifications: Do not worry about the Checksum. It is always zero in the input packets and you can keep it zero. You can see whether the incoming packet itself contains an icmp packet: If the ``protocol field'' in an IP header is 1 (in binary: 00000001), the IP packet contains an icmp packet. In that case, always assume the type is 11 (time exceeded). The format of the packets for input will be the same as for your output. A description and examples will follow soon. Teun Ott.