代写Implementing forwarding in a router代做R编程

Implementing forwarding in a router

Network Layer Forwarding

Task Overview

You will extend code that we provide to construct a forwarding table given a collection of networks and interface numbers, and then perform. the forwarding function for incoming IP datagrams, sending them out on the appropriate interface.

We are providing a tester that will exercise your router based on a script of datagrams to send to the router on particular interfaces.

IP Header Refresher

On the wire, an IP datagram, which is encapsulated in a UDP packet, uses the header defined by the following C structure:

typedef struct ipheader {

unsigned char verslen;   // version in first 4 bits (== 4), header len

in 32 bit words in second 4 bits (== 5)

unsigned char typeOfService;// Not used, must be 0

unsigned short length;   // Length in bytes of the entire datagram

unsigned short id;       // Not used, must be 0

unsigned short flagsoffset;   // Not used, must be 0

unsigned char ttl;       // Time to live in hops

unsigned char protocol; // Upper level protocol.  May be any value

unsigned short checksum; // Checksum of the IP header

unsigned int srcipaddr; // Src IP address

unsigned int dstipaddr;  // Dst IP address

} ipheader;

A few of the fields are described below:

●   Since we are only using IPv4 and your implementation does not need to deal with IP options,  the value of the verslen field must always be 0x45 (version 4, header length 5 32 bit words).

●   The length field gives, in bytes, the length of the entire datagram, including the length of the header.

●   The ttl field indicates how many more "hops" this datagram may experience before being  destroyed. Your router will decrement this field by 1, and if it reaches 0, then will discard the datagram rather than forwarding it anywhere.

● The protocol field indicates which upper-level protocol this datagram is intended for, and

may have any value. In the actual Internet, it will take on values like 6 for TCP, 17 for UDP, 33 for DCCP, or 132 for SCTP. You can see the list of all legal values at:

https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml, if you are interested. Your router will not pay attention to this field since it is only performing the forwarding function.

●   The checksum field is the value of the standard IP checksum algorithm computed on the header of the datagram only. The checksum field is set to 0 before the checksum is computed. Your router must verify the checksum before forwarding the datagram and must discard any datagram that arrives with an incorrect checksum. It must also recompute the checksum for each outgoing datagram, since it will have changed the ttl field.

●   The srcipaddr and dstipaddr fields are the IPv4 addresses of the host (technically, interface) that sent the datagram and the host that should receive the datagram, respectively.

Note that all fields that are longer than one byte are sent in network byte order (big-endian). The only interesting field that this applies to is the length field, since the checksum is computed in network byte order, and source and destination IP addresses are sent and used in network byte order. Since the Linux computers that your code will be tested on and your own computer are little-endian, this field will have to be byte-swapped before your code will be able to interpret it. We have provided a pair of functions in ip.c that will do this.

Router Configuration

Your router will have as many as 8 (simulated) network interface cards, each of which is connected to other routers. The configuration of your router will be specified in a configuration file, typically called router.config. See below for the command line arguments that your router should take.

We have provided code that reads this configuration file and calls two functions that you provide to configure your router. These are:

● void addForward Entry(uint32_t network, int netlength, int interface);

This informs your router that the network given by the CIDR address in the first two

arguments can be reached via the given interface. As an example, if the address

142.103.10.0/24 was to be reached by your router forwarding on interface 3, this function would be called as:

addForwardEntry(0x8e670a00, 24, 3);

0x8e is 142, 0x67 is 103, 0x0a is 10, and 0x00 is 0

● void addInterface(int interface);

This informs your router that the indicated network interface exists.

addInterface(i) will be called before i appears in any call to addForward Entry().

You router will call the function configLoad which is defined in config.h to read the router configuration file.

Implementation Constraints and Suggestions

A skeleton for implementing the router has been provided and is in the file router.c. Feel free to change the implementation of the main function and anything else that you wish to change.

The provided Makefile will compile and build the router application; router is the application that you are developing.

Except for router.c, you are not allowed to change any other source file. You will only be submitting your router.c file to the autograder.

There is no restriction regarding what the router prints on the default output stream. You may use it as you wish, for debugging or logging purposes.

Testing

You have been provided with an implementation of a testing program that you may use to test your router. You may also, of course, test your router using any other technique that you find valuable. We have provided executables for Linux on Intel processors, and MacOS (with both Apple and Intel processors). The Makefile will complain at you if you skip this step. You should create a link from the  version of the tester executable that runs on your hardware to the name tester. For example, if you are running on Linux, do:

ln tester_linux tester ; touch tester

On MacOS, to execute a downloaded executable (which the tester will be) you must first open it in  the Finder: navigate to the directory where you have downloaded it, right click on it, and then select Open. MacOS will ask you if you are sure, confirm your intention and then you will be able to run it  from any context.

tester will read a script. of datagrams that it will then send to your router and determine whether

your router is correctly handling each datagram. It takes two command line arguments, one of which is optional. The first optional one specifies the ports to use, and the second specifies the script.

% ./tester [routerport] scriptFile

Where:

●    routerport - the (optional) port your router will use to receive data on;

● script. - the name of a text file that contains datagrams that should be sent to the router.

The tester can be invoked without the routerport argument, in which case it will use port numbers that are generated based on your Linux user-id.

% ./tester scriptFile

The command to run the router takes two optional arguments. The first is the port it should use and the second is a configuration file name.

A typical router command would look like the following:

% ./router router.config

If the configuration file name is not provided, it defaults to "router.config".

Plan of Attack

Don't try to implement this all at once. Instead incrementally build the solution. A suggested strategy is to:

●    Read all the provided .c and .h files to make sure you understand what functions have been provided for you and what you need to implement.

●   Write code to receive a datagram on the provided socket, print out what is received, and send it back to where it came from. This will get the basic communication done. Turing on logging    will allow you to see the datagrams that you receive and send.

●   Then, decide what your forwarding table will look like, and implement: void addForward Entry(uint32_t network, int netlength, int interface);    void addInterface(int interface);

●    Implement a function that given a datagram and the interface that it came in on, decides   which interface it should be sent out on. Test this function carefully to make sure that your forwarding is correct.

●    Finally, worry about all the other stuff like verifying incoming checksums, decrementing the TTL field, computing the checksum of each outgoing datagram, etc.

●   Write small pieces of code and test them thoroughly before going to the next stage. For example write and test the code to setup a connection before transferring any data.

Script Files

The tester reads a script. file containing datagrams that it should construct and send to the router. An example file is:

//time src           dst           interface ttl length  extra

@0.234 142.103.10.41 142.103.11.99 1         63  27

@0.767 142.103.10.41 142.103.11.99 6         1   28

@0.888 98.97.96.95 17.0.0.1 1         5   32

@0.999 142.103.10.41 142.103.10.99 2         23  29

@1.299 142.103.10.41 142.103.10.99 2         23  29      corrupt

Each line contains a time at which the datagram should be sent, the source and destination IPv4 addresses, the network interface on which the router should receive the datagram, its TTL field value, and the length of the payload in the datagram. The payload will be random characters. Finally, if the word "corrupt" appears at the end of the line, the tester will flip one bit in the header of the datagram after the checksum has been computed so that you can verify your checksum checking code is correct.

Needs to pass all below tests:

Test Results

[0/1] Compile router.c

[0/1] Forwarding: Sanity check: Starter - test_sanity_check

[0/1] Forwarding: Default route - test_default_route

[0/1] Forwarding: Single destination - test_one_dest

[0/1] Forwarding: Checksum - test_checksum

[0/1] Forwarding: TTL - test_ttl

[0/1] Forwarding: Payload length - test_payloads

[0/1] Forwarding: A really tiny subnet - test_tiniest_subnet

[0/1] Forwarding: Forwarding to default route - test_default_loopback

[0/1] Forwarding: Forwarding to source interface - test_one_dest_loopback [0/1] Forwarding: Non-overlapping subnets - test_non_overlapping_subnets [0/1] Forwarding: Overlapping subnets - test_left_biased_tree_of_subnets

[0/1] Forwarding: Fully overlapping subnets - test_fully_overlapping_subnets [0/1] Forwarding: Large flood of packets - test_throughput