Logical Switch Slicing. In order to overcome the limited TU/e switch resources for the demonstrators, we need to logically "slice" each physical switch into several logical switches. To that end, ports of the same switch can be physically connected by an optical link. Based on that physical connection, the switch is configured with corresponding open-flow rules. For instance, Figure 4 demonstrates the "slicing" of the switch into two logical switches. Whenever a packet is required to be transmitted from Logical Switch 1 to Logical Switch 2, the packet is transmitted through port 32, which in turn transmits the packet through the physical optical link back to port 33, which is considered to be Logical Switch 2. Therefore, such ingress packet from port 33 is considered to be transmitted from Logical Switch 1. Each such egress and re-ingress transmission contributes latency which consists of the optical-to-electrical conversion, queuing, packet processing, and switching. In extreme case where much higher switch hops are required, one can define logical switches which consist of only two ports to be used for receive packets on one port and forward to the other port. Hence, such minimal logical switch can be used for building up latency. However, such "slicing" technique complicates the controller decisions; it should be aware of the physical links between ports of the same switch, and how the physical topology maps into the "logical sliced" topology. Furthermore, the open-flow rules scope of each logical switch should be limited to its ports range only; e.g. Logical Switch 1 cannot forward packets to ports higher than 32. An additional option to the logical switch slicing is to create a closed loop in the switch, such that a flow will be transmitted through the same physical switch infinitely. To that end, the Open Flow matching rules should modify the TTL field in order to keep this flow alive in the switch. Such an approach can further increase the switch overload. Moreover, one might be able to generate such flow by a server for a limited time period, which after that the flow will be self-existed in the switch without being generated by a server.
