PortLand Flashcards
a scalable, fault tolerant layer 2 routing and forwarding protocol for data center environments.
PortLand
holds promise for supporting a “plug-and-play” large-scale, data center network.
PortLand
Why PortLand?
the routing, forwarding,and management protocols that we run in data centers were designed for the general LAN setting and are proving inadequate along a number of dimensions.
PortLand, a set of Ethernet-compatible routing, forwarding, and address resolution protocols with the goal of meeting R1-R5 above.
Ideally, data center network architects and administrators would have “plug-and-play” deployment for switches. Consider some of the requirements for such a future scenario:
R1. Any VM may migrate to any physical machine.
Migrating VMs should not have to change their IP
addresses as doing so will break preexisting TCP connections and application-level state.
R2. An administrator should not need to configure
any switch before deployment.
R3. Any end host should be able to efficiently communicate with any other end host in the data center along any of the available physical communication paths.
R4. There should be no forwarding loops.
R5. Failures will be common at scale, so failure detection should be rapid and ecient. Existing unicast
and multicast sessions should proceed unaffected to the extent allowed by underlying physical connectivity.
The principal observation behind our work is that data center networks are often physically inter-connected as a multi-rooted tree
PortLand
employs a lightweight protocol to enable switches to discover their position in the topology. It also further assigns internal Pseudo MAC (PMAC) addresses to all end hosts to encode their position in the topology. PMAC addresses enable efficient, provably
loop-free forwarding with small switch state.
PortLand
PortLand Goal??
We hope that PortLand enables a move towards more
exible, efficient and fault-tolerant data centers where applications may flexibly be mapped to different hosts, i.e. where the data center network may be treated as one unied fabric.
For these reasons, certain data centers deploy a layer 2
network where forwarding is performed based on
at MAC addresses. A layer 2 fabric imposes less administrative overhead.
Unfortunately, Layer 3 forwarding does impose administrative burden. In general, the process
of adding a new switch requires manual administrator configuration and oversight, an error prone process. Worse, improperly synchronized state between system components, such as a DHCP server and a configured switch subnet identifier can lead to unreachable hosts and difficult to diagnose errors. Finally, the growing importance of end host virtualization makes Layer 3 solutions less desirable
Portland Goal
to deliver scalable layer 2 routing, forwarding, and addressing for data center network environments.
in data center environments, the baseline multi-rooted network topology is known and relatively fixed. Building and maintaining data centers with tens of thousands of compute elements requires modularity, advance planning, and minimal human interaction. Thus, the baseline data center topology is unlikely to evolve quickly. When expansion does occur to the net-
work, it typically involves adding more \leaves” (e.g., rows of servers)
True
maintains soft state about network configuration information such as topology and is a user
process running on a dedicated machine responsible for assisting with ARP resolution, fault tolerance, and multicast
Fabric Manager
may simply be a redundantly-connected host in the larger topology or it may run on a separate control network.
Fabric Manager
In PortLand, we restrict the amount of centralized knowledge and limit it to soft state. In this manner, we eliminate the need for any administrator configuration of the fabric manager (e.g., number of switches, their location, their identifier).
True
The PortLand approach takes inspiration from other recent large scale infrastructure deployments.
1) Modern storage and
2) data processing systems employ a centralized controller at the scale of tens of thousands of machines.
3) the Route Control Platform considers
centralized routing in ISP deployments.
The basis for efficient forwarding and routing as well as
VM migration in PortLandr design
hierarchical Pseudo MAC (PMAC) addresses
1) PortLand assigns a unique PMAC address to each end host.
2) The PMAC encodes the location of an end host in the topology.
3) Egress switches perform PMAC to AMAC header rewriting to maintain the illusion of unmodified MAC addresses at the destination host.
1) True
2) True
3) True
PortLand edge switches learn a unique pod number and a unique position number within each pod. We employ the Location Discovery Protocol (Section 3.4) to assign these values.
True
For all directly connected hosts, edge switches assign a 48-bit PMAC of the form pod:position:port:vmid to
all directly connected hosts
pod (16 bits) reflects the pod number of the edge switch, position (8 bits) is its position in the pod, and port (8 bits) is the switch-local view of the port number the host is connected to. We use vmid (16 bits) to multiplex multiple virtual machines on the same physical machine (or physical hosts on the other side of a bridge).
PortLand leverages the fabric manager to reduce broadcast overhead in the common case
True
PortLand switches periodically send a Location Discovery
Message (LDM) out all of their ports both, to set their positions and to monitor liveness in steady state. LDMs contain the following information:
Switch identifier (switch id): a globally unique identifier for each switch, e.g., the lowest MAC address of all local ports.
Pod number (pod): a number shared by all switches
in the same pod (see Figure 1). Switches in different
pods will have different pod numbers. This value is
never set for core switches.
Position (pos): a number assigned to each edge switch, unique within each pod.
Tree level (level): 0, 1, or 2 depending on whether the switch is an edge, aggregation, or core switch. Our approach generalizes to deeper hierarchies.
Up/down (dir): Up/down is a bit which indicates
whether a switch port is facing downward or upward
in the multi-rooted tree.
a location discovery protocol (LDP) that requires no administrator configuration. PortLand switches do not begin packet forwarding until their
location is established.
True
PortLand’s forwarding protocol is provably loop free by observing up-down semantics [27] in the forwarding process
True
Upon not receiving an LDM (also referred to as a keepalive in this context) for some configurable period of time…. so… the following happens
- a switch assumes a link failure
- The detecting switch informs the fabric manager about the failure .
- The fabric manager maintains a logical fault matrix with per-link connectivity information for the entire topology and updates it with the new information
- the fabric manager informs all affected switches of the failure, which then individually recalculate their forwarding tables based on the new version
of the topology.
Topology -> Multi-rooted tree
Forwarding - Switch State -> O(number of local ports)
Forwarding - Addressing -> Hierarchical
Routing -> Location , Discovery, Protocol; Fabric Manager for faults
ARP -> Fabric manager
Loops -> Provably loop free; no additional header
Multicast -> Broadcast-free routing; multi-rooted spanning trees
PortLand System
