Problem 13 - An Introduction to Computer Networks

Question

Consider the following arrangement of three switches S1-S3, three hosts h1-h3 and one OpenFlow controller C. As with exercise 12.0, assume that the switches report packets to \(\mathrm{C}\) only if they do not already have a forwarding- table entry for the packet's destination. After each report, C installs a forwarding-table entry on the reporting switch for reaching the packet's source address via the arrival port. At that point the switch floods the packet (as the destination must not have been known). If a switch can forward a packet without reporting to \(\mathrm{C}\), no new forwarding entries are installed. Packets are now sent as follows: \(h 1 \rightarrow h 2\) \(h 2 \rightarrow h 1\) \(h 1 \rightarrow h 3\) \(h 3 \rightarrow h 1\) \(h 2 \rightarrow h 3\) \(h 3 \rightarrow h 2\) At the end, what are the forwarding tables on \(\mathrm{S} 1 \diamond, \mathrm{S} 2\) and \(\mathrm{S} 3\) ?

Step-by-Step Solution

Answer

In summary, the final forwarding tables after all packets have been sent would be: For \(S1\), a rule for \(h2\) accessible via \(S2\) and a rule for \(h3\) accessible via \(S2\); for \(S2\), it will have a rule for \(h1\) and \(h3\) accessible via \(S1\) and \(S3\) respectively; and for \(S3\), it will have rules for \(h1\) and \(h2\) accessible via \(S2\) and \(S1\) respectively.

Step 1 - Analyze the Packet Flow

Start by analyzing the packet flow one by one. Remember that if a switch has no forwarding rule for the destination, it reports back to the controller and then creates a rule before forwarding. The first packet is from \(h1\) to \(h2\). The rule set will be updated for \(S1\) and \(S3\). A rule will be created for \(h2\) in \(S1\) and a rule for \(h1\) in \(S3\).

Step 2 - Continue the Packet Analysis

Now, analyze the second packet, from \(h2\) to \(h1\). This time, \(S3\) and \(S1\) will update their forwarding tables. \(S3\) will create a rule for \(h1\) and \(S1\) will create a rule for \(h2\). The process must be continued for all the remaining packets in the same manner.

Step 3 - Fill the Remaining Flow-Tables

Following similarly for the remaining packets, we can come up with the final forwarding tables for all the switches \(S1\), \(S2\) and \(S3\).

Key Concepts

Forwarding Table

A forwarding table is essentially a roadmap for switches on the network. It's like a directory that helps the switch know where to send packets. When a switch receives a packet, it checks its forwarding table to see if there is already a rule about how to handle packets for the packet’s destination. If there is a rule, the switch forwards the packet accordingly.

• If there is no rule in the table, the switch informs the OpenFlow controller.
• The controller will then create a rule for the switch to know how to route the packet.

Forwarding tables are crucial in reducing the need for switches to constantly report to the controller, which improves the efficiency of the network's data flow.

Packet Flow

Packet flow refers to the path taken by data packets across a network from the source to the destination. In OpenFlow, if the packet flow is unfamiliar - meaning the switch doesn't yet know where to send it from its forwarding table - the switch will communicate with its controller.

• The controller acts like a navigator, deciding the best path and updating the switch's forwarding table so it knows the way next time.
• Packets travel between hosts through several switches, and understanding the flow helps in setting up efficient routes.

This systematic flow ensures that networks can handle many packets simultaneously, directing them effectively by learning from the interactions.

Switch Rules

Switch rules in OpenFlow are guidelines that determine how packets should be handled when they arrive at a switch. The rules indicate:

• What action the switch should take if a packet matches a certain flow.
• Whether to forward, drop, or flood the packet to find its destination.

The switch utilizes these rules to decide actions quickly without always having to check with the controller. This kind of autonomy is crucial for maintaining swift data flow in networks, decreasing the load on the controller and accelerating the processing of data packets.