- Host sends an ARP request (who is the destination) For finding mac-address.
- When ARP reply comes to the host start sending data packets.
- When a switch gets an ARP request from the host switch sends a fake ARP reply with a fake mac-address.
- When a switch get data packets to switch calculate the next-hop(using Dijkstra algorithm) and outport of the switch and insert a flow_mod so that the next packets can easily flow from the switch.
- When a packet reaches destination switch. Switch check table where mac-address of destination host is present or not. if mac-address is not present then switch broadcast ARP request.
- When a switch get ARP request switch check ethernet src mac if src mac is not fake mac then only switch reply otherwise switch drop ARP-request
- Switch processing Delay
- Remaining Bandwidth of link
For calculating switch processing delay we use flow mod message. Firstly when the switch gets to connect to the controller we insert a dummy flow entry in the switch with some hard time out and we store insert-time in the database. When dummy flow removes from the switch we catch the dummy flow and insert remove-time in the database. The Flow mod message allows the controller (RYU) to easily modify the state of an OpenFlow switch. The Flow_Mod message begin with the defined standard OpenFlow header which contains the version of OpenFlow and type values which is followed by the FlowMod structure.
Flow_Mod message starts with the standard header followed by cookie, which is being set by the controller, its table, command and mask which specifies the type of flow table modification which needs to done. This is being followed by priority, hard_timeout and idle_timeout.The priority field defines an order for matches that overlaps with higher numbers i.e. representing higher priorities. Idle_timeout and hard_timeout represent number of seconds since packet inactivity and creation since expiration, respectively Next the FlowMod contains buffer_id, out_port, out_group and flags. Buffer_id is the id of the buffered packets that created a packet_in inside the switch, make FlowMod and then reprocess the packet. Finally, 2 byte padding, match and instructions are also added at the end. #####Structure of Dummy Flow_Mod Packet
The following snippets shows how the header is being modified according to our requirement which shows how the flow_mod_entry is being installed in the switch:
FlowRemoved is a message which is sent to the controller by the switch when a particular flow entry in a flow table gets removed/deleted. It happens after a particular timeout occurs, it maybe due to inactivity or hard timeout. The switch sends a FlowRemoved message after a particular timeout(idle timeout/hard timeout) is specified by the FlowMod. The removal of flow entry with a FlowMod message from the controller can lead to a FlowRemoved message as shown below:
Switch processing delay=remove_time-insert_time-2*hard_time_out
The remaining bandwidth can be calculated by monitoring the port status of the switch. When a dummy flow removes message comes to the controller. The controller sends a port-status request to switch. Switch reply with the port status message. we store transmitted bytes by ports of the switch in the table to find byte transfer per unit time by link.
For calculating the matrix, we discover the topology of the network.
We have already calculated the Processing delay of each and every switch of the topology and the remaining bandwidth of the links between the switches. The next part is to calculate the weight of each of the links using the processing delay and the remaining bandwidth of the link which will help to form the weighted routing matrix
The routing matrix will be calculated with the help of processing delay of each and every switch and the remaining bandwidth of the link between the switches according to the mathematical formula. Mathematical Formula: Distance = Switch Delay*1000 + Utilized Bandwidth
This matrix is used for finding the next node using the Dijkstra algorithm.
We have taken an example topology as shown above to explain the flow of packet between the two host. As per the example one of the host will be acting as a SERVER and the other as a CLIENT Steps Involved:
In the above example, the CLIENT IP :10.0.0.1 and the SERVER IP: 10.0.0.4. For connecting client to the server the host h1 will send ARP (Address Resolution Protocol) request having the destination set to IP Address: 10.0.0.4
Then the Switch1 will reply Host1:10.0.0.1 with FAKE MAC Address impersonating itself as Host4
After that Host1 will be sending a TCP packet to Switch1 (impersonating as Host4).After receiving the TCP packet Switch1 will be handling the packet.
In this step the Switch1 will be finding the next hop and out_port using Dijkstra’s Algorithm by analyzing the topology (as shown in section 12.1).
After that the Switch1 will be inserting a flow entry in the flow table of itself so that in future the next TCP packets referring to same destination can be transferred accordingly. Let’s assume the next hop is Switch2 then Switch1 will be sending the TCP packet to Switch2 without modifying the TCP packet further.
In this step as the TCP packet reaches the Destination switch i.e. Switch4 and when the Switch4 tries to find the next hop and out port using Dijkstra’s Algorithm it will report that it’s the final destination. After reaching the final destination the TCP packet tries to find the Destination Host i.e. Host4. It will be done by searching the host_dictionary containing the information of all the host’s connected with that particular switch i.e. Switch4.
If the entry is not present in the host_dictionary then the switch i.e.Switch4 will broadcast ARP request
with SOURCE = FAKE MAC Address DESTINATION = BROADCAST_MAC
If host is connected with the Switch, ARP reply comes to switch and the host_dictionary gets modified.
After the modification of the host_dictionary, we will modify the TCP_ethernet packet. Modification Done: SOURCE_MAC = FAKE_MAC Address DESTINATION_MAC = DESTINATION_HOST_MAC Address Also we insert a FLOW_MOD i.e. entry will be inserted in the Flow_Table accordingly and then the TCP packet will be forwarded to the out_port and the TCP packet reaches the destination i.e. Host4 successfully. So, that’s how the client gets connected with the server
When a host tries to send a TCP packet to the destination host first sends an ARP request message to switch. Switch reply with a fake ARP packet using a fake mac-address
When a packet reaches the destination switch. The controller checks the IP mac table if the mac-address is not present in the table then the Controller broadcasts the ARP request.