Performance of Meshed Tree Protocols for Loop Avoidance in Switched Networks

Loop free frame forwarding in layer 2 switched networks that use meshed topologies to provision for link and path redundancy is a continuing challenge. The challenge is addressed through special protocols at layer 2 that build logical trees over the physically meshed topologies, along which frames can be forwarded. The first such protocol was based on the spanning tree. The spanning tree protocol (STP) had high convergence times subsequent to topology changes. Rapid STP and IETF RFC 5556 Transparent Interconnection of Lots of Links (TRILL) on Router Bridges (RBridges) were then developed to reduce the convergence times. RSTP cntinued to use the spanning tree while TRILL adopted link state routing to support a tree from every switch. TRILL introduces high processing complexity into layer 2 networks. In this article a new meshed tree algorithm (MTA) and a loop avoidance protocol based on the MTA, namely the meshed tree protocol (MTP) are discussed. The MTA allows constructing several overlapping trees from a single root switch. This speeds up convergence to link failures. The MTP proposes a simple numbering scheme to implement meshed trees – thus, the processing complexity is low. The specification for the MTP is currently an ongoing IEEE standard Project 1910.1. In this article the operational details of MTP are presented and its performance evaluated and compared with RSTP

Endpoint-transparent Multipath Transport with Software-defined Networks

Multipath forwarding consists of using multiple paths simultaneously to transport data over the network. While most such techniques require endpoint modifications, we investigate how multipath forwarding can be done inside the network, transparently to endpoint hosts. With such a network-centric approach, packet reordering becomes a critical issue as it may cause critical performance degradation. We present a Software Defined Network architecture which automatically sets up multipath forwarding, including solutions for reordering and performance improvement, both at the sending side through multipath scheduling algorithms, and the receiver side, by resequencing out-of-order packets in a dedicated in-network buffer. We implemented a prototype with commonly available technology and evaluated it in both emulated and real networks. Our results show consistent throughput improvements, thanks to the use of aggregated path capacity. We give comparisons to Multipath TCP, where we show our approach can achieve a similar performance while offering the advantage of endpoint transparency

Deliverable DJRA1.2. Solutions and protocols proposal for the network control, management and monitoring in a virtualized network context

This deliverable presents several research proposals for the FEDERICA network, in different subjects, such as monitoring, routing, signalling, resource discovery, and isolation. For each topic one or more possible solutions are elaborated, explaining the background, functioning and the implications of the proposed solutions.This deliverable goes further on the research aspects within FEDERICA. First of all the architecture of the control plane for the FEDERICA infrastructure will be defined. Several possibilities could be implemented, using the basic FEDERICA infrastructure as a starting point. The focus on this document is the intra-domain aspects of the control plane and their properties. Also some inter-domain aspects are addressed. The main objective of this deliverable is to lay great stress on creating and implementing the prototype/tool for the FEDERICA slice-oriented control system using the appropriate framework. This deliverable goes deeply into the definition of the containers between entities and their syntax, preparing this tool for the future implementation of any kind of algorithm related to the control plane, for both to apply UPB policies or to configure it by hand. We opt for an open solution despite the real time limitations that we could have (for instance, opening web services connexions or applying fast recovering mechanisms). The application being developed is the central element in the control plane, and additional features must be added to this application. This control plane, from the functionality point of view, is composed by several procedures that provide a reliable application and that include some mechanisms or algorithms to be able to discover and assign resources to the user. To achieve this, several topics must be researched in order to propose new protocols for the virtual infrastructure. The topics and necessary features covered in this document include resource discovery, resource allocation, signalling, routing, isolation and monitoring. All these topics must be researched in order to find a good solution for the FEDERICA network. Some of these algorithms have started to be analyzed and will be expanded in the next deliverable. Current standardization and existing solutions have been investigated in order to find a good solution for FEDERICA. Resource discovery is an important issue within the FEDERICA network, as manual resource discovery is no option, due to scalability requirement. Furthermore, no standardization exists, so knowledge must be obtained from related work. Ideally, the proposed solutions for these topics should not only be adequate specifically for this infrastructure, but could also be applied to other virtualized networks.Postprint (published version

Implementing ARP-Path Low Latency Bridges in NetFPGA

The demo is focused on the implementation of ARP-Path (a.k.a. FastPath) bridges, a recently proposed concept for low latency bridges. ARP-Path Bridges rely on the race between broadcast ARP Request packets, to discover the minimum latency path to the destination host. Several implementations (in Omnet++, Linux, OpenFlow, NetFPGA) have shown that ARP-Path exhibits loop-freedom, does not block links, is fully transparent to hosts and neither needs a spanning tree protocol to prevent loops nor a link state protocol to obtain low latency paths. This demo compares our hardware implementation on NetFPGA to bridges running STP, showing that ARP-Path finds lower latency paths than STP.Comunidad de MadridJunta de Comunidades de Castilla-La Manch

Implementing ARP-Path Low Latency Bridges in NetFPGA

The demo is focused on the implementation of ARP-Path (a.k.a. FastPath) bridges, a recently proposed concept for low latency bridges. ARP-Path Bridges rely on the race between broadcast ARP Request packets, to discover the minimum latency path to the destination host. Several implementations (in Omnet++, Linux, OpenFlow, NetFPGA) have shown that ARP-Path exhibits loop-freedom, does not block links, is fully transparent to hosts and neither needs a spanning tree protocol to prevent loops nor a link state protocol to obtain low latency paths. This demo compares our hardware implementation on NetFPGA to bridges running STP, showing that ARP-Path finds lower latency paths than STP

All-path bridging: Path exploration as an efficient alternative to path computation in bridging standards

This work is at: IEEE International Conference on Communications: Second Workshop on Telecommunication Standards: From Research to Standards. In Communications Workshops (ICC). Date 9-13 June 2013, Budapest, Hungary.Link-state based routing protocols are dominant in Shortest Path Bridges (IEEE 802.1aq) and also at TRILL (IETF) Rbridges. Both standards propose a hybrid of switch and router adding a link state routing protocol in layer two that computes shortest paths between bridges. Surprisingly, path exploration mechanisms have not yet been considered at standardization bodies, in spite of some outstanding advantages: simplicity,instantaneous path adaptation to traffic load with load adaptive routing and low latency. We have developed All-path, a family of protocols based on simple path exploration mechanisms based on full flooding of a single frame, as an alternative to the "beatentrail" of path computation. Path exploration (either instantaneous or periodical, proactive or reactive) is an efficient alternative to path computation for bridged networks because the processing cost of address learning at bridges from broad cast frames is very low and Ethernet links provide very high link capacity so that the extra packet broad casts do not impact load significantly. Standardization groups should consider the application of path exploration (instantaneous or periodical, proactive or reactive) mechanisms in Audio Video Bridges and ingeneric bridging networks like campus and data centers to find redundant paths, low latency and load distributionThis work was supported in part by grants from Comunidad de Madrid through Project MEDIANET-CM (S-2009/TIC-1468) .Publicad

A Simple, Zero-configuration, Low Latency, Bridging Protocol

This paper describes a demo for a new type of bridges, ARP-Path bridges. These ARP-based Ethernet Switches rely on the race between ARP Request packets flooded over all links, to discover the minimum latency path to the destination host. The protocol uses all links, is loop free, uses the standard Ethernet frame format, is fully transparent to hosts and neither needs a spanning tree protocol to prevent loops nor a links state protocol to obtain minimum latency paths. Implementations in Linux and Openflow on NetFPGA show inherent robustness and fast reconfiguration. Simulation results show throughput and delay performance superior to the Spanning Tree Protocol and similar to shortest path routing, with lower complexity.Comunidad de MadridJunta de Comunidades de Castilla-La Manch

ARP-Path: ARP-based Shortest Path Bridges

This letter is a summary proposal for an evolution of the Ethernet transparent bridge paradigm that provides simple, shortest path bridging in campus networks. ARP-Path Ethernet Switches set up an on-demand path between two hosts just reusing and flooding the standard ARP request frame through all links and confirming the path reaching to the destination host with the ARP reply frame. ARP-Path uses the standard Ethernet frame format, is fully transparent to hosts and does not require spanning tree or link state protocol. Simulation results show superior performance to spanning tree and similar to shortest path routing, with lower complexity. Our implementations confirm backward compatibility, robustness and performance.This work was supported in part by grants from Comunidad de Madrid and Comunidad de Castilla la Mancha through Projects MEDIANET-CM (S- 2009/TIC-1468) and EMARECE (PII1I09-0204-4319).Publicad