CSU33031-Computer Networks Solved

1           Introduction
The focus of this assignment is to learn about decisions to forward flows of packets and the information that is kept at network devices that make forwarding decisions. The design of forwarding mechanisms aims to reduce the processing required by network elements that forward traffic while providing scalability and flexibility.

2           Protocol Details
Your are given the task to develop a replacement for IPv4 or IPv6 by designing a protocol that forwards payloads based on a collection of strings that identify the source and destination of traffic. The forwarding information will be kept in forwarding tables located at the individual network elements and the content of these tables will be controlled by a central controller.

 

Figure 1: An application will send UDP datagrams to a forwarding service on the local host. The forwarding service will consult a table to determine from the header information of your protocol where to forward the datagram to. The table will provide it with the IP address of the network element that is the next hop and your implementation should forward it to another instance of the forwarding service on this IP address.

The initial implementation of the forwarding mechanism will use a UDP service bound to port 51510 at every network element. Someone in future may use the same information that is currently transferred using

1

UDP and send it, using Ethernet frames as a complete replacement to current IP protocols, as shown in figure 2 b) (see also the use of faces in NDN [1]).

An application using your protocol will create a header you design, attach the payload to be transmitted, and send it as payload to a service you develop, bound to port 51510 on the local host, such as shown in figure 2 a). The service will examine the header and decide where to forward the information to based on the header information and a forwarding table. The forwarding table will indicate instances of the service on other network elements.

An application that intends to receive traffic will send a datagram to the forwarding service on its local host, indicating that it intends to receive traffic for a given string. The forwarding service will need to record the port number of that the application used and the string. Whenever datagrams arrive for the given string, it should deliver these datagrams to the port number that is associated with the string.

 

Figure 2: An application will transmit a header and payload to a forwarding service bound to port 51510 on the local host. The forwarding service will inspect the header and forward the header and payload to a forwarding service on another network element.

The header information should be encoded as type-length-value (TLV) format. Figure /refTLVExample shows an example where the first number of the encoding gives the type of the information that follows, the second number gives the length of the information and the third item of the field provides the value of the information itself. The first example shows a field that could represent a network ID, the network has the length of 7 characters and the value ’trinity’. The second example combines two network IDs by introducing a type combination that can hold any combination of further TLVs, in this case two network IDs. This example allows for construction of hierarchical networkIDs such as ’trinity.scss’.

 

Figure 3: The 1st number of the encoding gives the type of the information that follows, the 2nd number gives the length of the information and the 3rd item of the field provides the value of the information itself. The 1st example shows a field that could represent a network ID, the network has the length of 7 characters and the value ’trinity’. The 2nd example combines two network IDs by introducing a type combination that can hold any combination of further TLVs, in this case two network IDs.

So, the basic functionality that a forwarding service has to provide is to accept incoming packets, inspect the header information, consult the forwarding table and forward the header and payload information to the destination. In the first place, if a destination is not known, a forwarding service would drop an incoming packet; once a controller has been implemented, the forwarding service needs to contact the controller to enquire about a forwarding information to the unknown destination and if it receives forwarding information, integrate this into its forwarding table.

 

Figure 4: This example shows the forwarding of traffic with a label ’trinity’ from an endpoint E1 to an endpoint E4. The names E1, E4, and R1 to R4 should be replaced by IPv4 addresses. The forwarding information should be supplied to the network elements by a central controller

In general, the network elements should be controlled by a central controller that initializes the flow tables of the network elements and would inform them about routes to destinations as the network changes. In a first step though, in order to reduce complexity, the flow tables of the individual network elements should be hardcoded. The implementation of the controller element should only be pursued once the implementation of the forwarding functionality of the network elements is stable and allows for basic communication between two endpoints.

The Named Data Networking (NDN) protocol [1] and the OpenFlow protocol [6] are examples of similar protocols that you could look at for functionalities that may be interesting for you to include in your protocol. In the end, it is up to you what functionalities you implement in your protocol. In the deliverables, you need to describe these functionalities and justify why you included them in your protocol.

The following flow diagrams, figures 5 is an examples of visualizations of network traffic between network elements. It shows a sequence of messages exchanged between the elements.

Please use Flow Diagrams like these to document the communication between components of your implementation in your videos and in your final report.

The protocol can be implemented in a programming language of your choosing. One of the conditions is that the communication between the processes is realized using UDP sockets and Datagrams. Please avoid Python 2.7 because the implementation of Datagram sockets in the obsolete versions is based the transfer of strings instead of binary arrays.

The easiest way to start with the development of your solution is possibly to connect your components through the localhost interface of a machine; however, at the end, you will need to be able to demonstrate that your protocol can connect components located at a number of hosts. There are a number of platforms that support the simulation of topologies or provide virtual infrastructures e.g. Docker [3], Mininet [7], Kubernetes [2], etc. For someone starting with socket programming and networking, I would suggest to use a platform such as Docker or Mininet; for someone already familiar with these concepts, I would suggest to implement their solution using Kubernetes. However, these are only suggestion and you need to make the decision how to implement your solution.

 

Figure 5: The diagram shows a router contacting the controller with an initial ’Hello’ message and receives a modification message to its flow table. It replies to this with an acknowledgement. When a router receives a packet with an unknown destination, it will contact the controller and receive an additional modification to its flow table