Ethernet loop avoidance protocol with Multi-Path and Traffic Engineering

Abstract

Multiple protocols have been developed to prevent Ethernet loops. These include; Spanning Tree Protocol, Media Redundancy Protocol, Parallel Redundancy Protocol, Transparent Interconnection of Lots of Links and Shortest Path Bridging. Limitations of STP include blocking redundant paths to prevent loops, 30-50s convergence time when there is a link failure and frame forwarding not easily seen by network engineers. TRILL uses ISIS routing protocol to prevent loops. Introduction of this routing protocol leads to high configuration and computation requirements and does not support traffic engineering. The research objective is to design a protocol that prevents loops in Ethernet networks by carrying loop avoidance information within the header of an Ethernet frame. This is to be achieved by; (i) investigating the requirements for an effective Ethernet loop avoidance protocol, (ii) designing and implementing an algorithm that uses the domain and local Identifier to prevent loops and (iii) evaluating the proposed protocol in terms of; Ethernet loop/ broadcast storm control, using fastest path to deliver unicast frames and offering redundancy in case of link failure -Multipath. Through an in-depth analysis of the Ethernet frame structure and different Ethernet loop protocols, a new frame structure is proposed that contains loop control logic namely domain Identifier, local Identifier and payload type. There after applying simple processing rules on this control logic to prevent loops and forward unicast and broadcast frames. Objective Modular Network Testbed in C++ (OMNET++) provided an infrastructure to write, simulate and evaluate the algorithm. During simulation, it was observed that broadcast traffic created a transient behaviour that died out within a short period of time implying that no more broadcast frames are received by switches in the LAN. Also point to point traffic between switches was sent using the fastest path and lastly, in case of a link failure alternative path was available for use without need for the network to converge. Future work includes; (i) Creation of domains with variable number of switches, currently each is limited to 32. (ii) Performance analysis of the protocol’s traffic engineering capabilities since forwarding paths can be predicted (iii) Support for multipath load balancing in cases where more than one equal cost path exists to a given host. (iv) How multicast traffic is handled as the protocol was only tested on unicast and broadcast frames.