R. N. Mysore, A. Pamboris, N. Farrington, N. Huang, P. Miri, S. Radhakrishnan, V. Subramanya, A. Vahdat, “PortLand: A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric”, ACM SIGCOMM, (August 2009). [PDF]
Summary
PortLand is a scalable, fault-tolerant, and easily manageable layer 2 routing and forwarding protocol for data center environments that exploits the knowledge of the underlying topology of a data center, completely avoids broadcast-based mechanisms, and stresses on fast and easy virtual machine mobility within the data center. The authors outline several requirements for a future data center network and explain why existing layer 2 and layer 3 fabrics as well as VLAN-based solutions are not suitable. PortLand combines the advantages of such solutions using a pre-determined topology (fat-tree), hierarchical pseudo-MAC (PMAC) address, and logically centralized directory (fabric manager or FM) to resolve PMAC to actual MAC (AMAC) addresses to enable Ethernet-compatible plug-n-play networking.
The design philosophy of PortLand prefers changes in the internal nodes, keeping the end hosts unmodified. PortLand design revolves around the assumption that baseline multi-rooted fat tree topology is unlikely to change over time. Information regarding the topology as well as other configuration data are stored using soft states in a logically centralized FM. There is a explicit separation of host locaion and identifier in PortLand. Each node is assigned a hierarchical PMAC address that identify its exact position in the fat tree (as opposed to flat identifier MAC address) with the property that all the nodes in a pod subtree share the same PMAC prefix. All packets are routed and forwarded using PMAC prefixes with appropriate conversions between PMAC and AMAC addresses in ingress and egress points to give an illusion of unmodified MAC addresses to the end hosts. The mappings between PMAC, AMAC, and IP addresses are stored in and managed by the FM, which allows FM to handle ARP and DHCP without broadcasting. For increased manageability, PortLand proposes a location discovery protocol (LDP) that automates PMAC assigning process. Packets in PortLand are forwarded through the least common ancestor in the fat tree; hence, there is no possibility of a loop. The authors also consider different failure scenarios and propose explicit solutions.
To evaluate PortLand, the authors created a testbed using 20 4-port NetFPGA PCI card switches interconnecting 16 end hosts and use OpenFlow to control switch forwarding tables. They present several convergence characteristics, scalability measurements, and VM migration performance in PortLand (without comparing with competing architectures).
Critique
In PortLand design, the FM can become the bottleneck since all the functionalities rely on it. While the paper discusses several fault scenarios, it pretty much avoids discussion on FM failure saying that the FM is distributed and replicated, hence robust. Some qualitative evaluation of FM failure could provide important insight into PortLand’s fault tolerance. The evaluation section in general is not very strong. The authors could have evaluated the overheads of changing PMAC addresses, the affect of multiple VM migrations simultaneously among others.
PortLand is highly customized for multi-rooted fat tree topology. The qualitative comparison against SEATTLE is a bit unfair as SEATTLE, being for general topologies, couldn’t afford customized optimizations. Also in the evaluation section there is no quantitative comparison against any other architecture.
I also thought it was odd that they didn’t do a quantitative comparison against any other architectures. They state the numbers they got when testing the various criteria (eg. convergence time starts at 65ms for single failure, it takes 110ms to restore connectivity to a receiver, etc), but without any type of baseline to compare against, it’s hard to say how good PortLand performs.
I agree, but perhaps they didn’t really have any network topology based systems to compare with. A comparison with SEATTLE on a fat-tree based network topology would have been good, but obviously it would be biased towards PortLand. It would have been really great if PortLand and VL2 were accepted in different conferences so that one would have compared it with the other :-)
which better ? VL2 or portland ? and why ??
portland using Pmac , what is the different in using pmac and using addressing in vl2 ( mac and ip ) ?
9