Ethernet Fabric – Towards Unified Networking

As Ethernet networks grow they invariably become more complex and difficult to manage, and due to the way they have to be configured they often suffer performance penalties as they grow. Ethernet networks also have to contend with an increasingly diverse set of applications, and now with iSCSI and AoE (as well as FCoE) we are seeing block storage being added to this mix. Different use cases have different requirements, and while web traffic is pretty latency tolerant the latest virtualised block storage requires very low latency and high bandwidth to maintain system performance. In order to be able to combine and scale the requirements of the Enterprise network, Ethernet needs to evolve into a new form that is capable of meeting these demands – Ethernet Fabric. Ethernet Fabric is borne out of the need to produce flatter, intelligent, more simple, scalable and efficient networks as demands on those networks increase. Traditional Ethernet networks were fine in the days of client/server, but as virtualisation develops into true heterogeneous cloud resource pools the way the network needs to tie these layers together needs to adapt to cope, if the network is not to become the bottleneck. Ethernet Fabric was developed to address these requirements. Flatter Classic Ethernet networks are hierarchical with three or more tiers. Traffic has to move up and down this logical tree to be able to flow between server racks (left hand image above), which adds latency and creates congestion on inter-switch links (ISLs). This is because in order to prevent traffic loops only 1 path in a redundant connection architecture can be allowed to be active...
Using MPLS to add routability to Coraid’s AoE

Using MPLS to add routability to Coraid’s AoE

A common point raised when comparing iSCSI to AoE protocols is that AoE is not routable and therefore not satisfactory for Enterprise use where there may be many sites between which you wish to share data. In fact this feature is what lead to the development of iSCSI in the first place. This is true in that AoE is a light layer 2 protocol integrated with Ethernet frames, and therefore by definition it is stopped when it meets a router. This provides security in that data cannot inadvertently be routed out of the network but also causes a headache when it needs to be routed away from a common LAN segment, with DR being a common requirement needing this feature. Because AoE does not have a built in authentication method like iSCSI, and can only secure data with LUN to MAC address masking, it would also be a risk to expose the data to any external network directly. Coraid have their own solution for this, which requires placement of a AoE gateway at the LAN segment edge before the router, which can then route encrypted AoE packets over IP to another gateway on another network. This works great over IP but is vendor specific, so what if you like the idea of AoE but want a more generic solution – AoE is Open Source after all? In research at University College Dublin, they found that AoE over MPLS provides a routable protocol which can be implemented without a need for tunnels, and with a very modest increase in the header size in comparison with raw AoE. As a side...