Software Defined Networks and the OpenFlow Project – Part 2
This is part two of my three part blog post about the idea of software defined networks.
In part one, I talked about how software plays an incredibly important role in service provider networks, providing the mechanisms whereby telecom services are provisioned, controlled and monitored. Before diving into a description of OpenFlow in part three of my post, let’s review some networking fundamentals.
Let’s step back and discuss at a high-level how packet switches such as Ethernet switches and IP routers operate. First and foremost, every packet switch has some number of interfaces linking it to other switches using local, metropolitan or wide-area links of some kind, and the collection of such switches and links form a network under the administrative control of some entity. Packets of digital information traverse the network links, and are switched from one link to another by the connecting switches. Each packet consists of a header and a body, with the body devoted to the actual data payload and the header consisting of fixed fields containing information that switches use to make forwarding decisions, moving a given packet towards its destination.
In the case of Ethernet and IP switches, the header information includes a destination address (MAC and IP addresses, respectively) that labels the destination computer. Each switch maintains a forwarding table that is used along with data from packet header fields to make a forwarding decision, determining which link to transmit a received packet on. For example, an Ethernet switch forwarding table entry consists of at least a MAC address and egress switch port, and all packets entering the switch with a destination MAC address matching the MAC address in a given table entry are switched out the corresponding egress port.
Thus, the destination address in an entering packet is used as a key in table look-up to determine the egress port. That is fundamentally what any packet switch has to do upon receiving a packet; use header information from the packet and local state maintained in the switch to make a decision as to how to forward the packet. To be sure, forwarding decisions can be and often are more complicated in order to achieve some desired behavior—examples include the use of a quality-of-service (QoS) field in the packet along with additional switch data to offer some packets preferential service.
Now that we have a model for how a packet switch forwards packets, a natural question arises: where does the forwarding state of an Ethernet switch, an IP router, or any type of packet switch come from? In our simple example above, how is the forwarding table of an Ethernet switch built? The answer depends on the details of the specific type of packet switch in question, but at the highest level there are two sources of forwarding information. One is that a network of switches executes one or more distributed networking protocols amongst themselves, exchanging information about network topology and reach-ability (what addresses can be reached from a given switch). This exchange of information is usually seeded by some degree of local switch configuration, or by learning. IP routers are configured with directly connected subnets, and Ethernet switches learn the location of MAC addresses by examining the source MAC addresses of packets on ingress. The details are less important than the fundamental idea of a combination of local, per-switch configuration or learning, and the distribution of this per-switch information across the network via switches participating in a distributed computation defined by a network protocols such as OSPF or BGP for IP routers, or STP for Ethernet switches. By participating in these protocols, a set if switches constituting a network obtain sufficient information to build and maintain their forwarding tables. Changes in the network due to failures or network expansion are to a large degree adapted to dynamically by the constituent switches, which are constantly chattering away with their neighbors, exchanging topology and reach-ability information. Such a decentralized and distributed approach to establishing the control plane of a network is how most networks work today. By control plane we mean the collection of mechanisms (software, protocols, and state) used to build and maintain a forwarding table within a switch, and more generally a set of such tables across an entire network of switches. The data plane is the set of mechanisms (primarily hardware) within a given switch that actually switch a packet from its ingress port to its egress port. An individual switch’s data plane operates under the guidance of that switch’s control plane.
A second approach to building a network wide control plane is via a centralized controller that establishes and maintains the forwarding state in each of the switches in the network. Conceptually, the network controller (software running on a server) connects to each switch and builds its forwarding table to achieve the desired network behavior. All network configuration starts with the centralized controller, which then programs the behavior of each of the constituent switches as required. Switches communicate with the controller as well, informing it of fault conditions, utilization and other data to allow the controller to adapt the network to changing conditions. Since there is no direct switch-to-switch communication in this scenario, and all computation is centralized on a single computer, the software complexity of the switches is reduced to the local maintenance of its forwarding table using information supplied by the controller. The switch resident portion of the control plane is clearly simpler in the case of centralized control than was the case of a distributed control plane executing in all of the switches simultaneously. Note that a centralized approach requires reliable communication between the controller and its switches, which can be provided by the network itself, or via an external out-of-band mechanism, as well as a very reliable controller. In practice, redundant controllers would be required, but let’s keep things simple for now and assume a single controller. We won’t debate here the pros and cons of the two approaches (distributed and centralized) to network control. Examples of both exist—the Internet uses a distributed control plane with multiple administrators/operators, while circuit-switched telephony uses a centralized approach to call routing. Many Frame Relay and ATM networks also were based on the centralized establishment of forwarding state, so large-scale packet networks have also been built this way.
We have one more networking concept to discuss before returning to the OpenFlow project. In our discussion thus far we have talked about switches making forwarding decisions based on their forwarding table and data in the header of individual packets. This is an accurate model of how packet switched networks work, but it is useful to observe that packets don’t usually occur in splendid isolation. They tend to occur in related multi-packet streams, or flows, between endpoints of communications, which each flow having some application specific duration. A great example is the set of packets between a web browser and a web server corresponding to a single HTTP transaction that downloads a web page, an example that would be considered two uni-directional streams (client->server and server->client) of packets. The recognition that a number of packets transiting a switch may be correlated in some relevant way leads to more general way of thinking and operating packet switches and networks, and we can generalize the notion of a forwarding table to that of a flow table, and speak more generally of flow switching, a superset of packet switching. An entry in a flow table in a given switch could be as simple as switching all packets entering a switch on a specific port with a particular VLAN tag to a specified egress port with the old VLAN tag replaced by a new one.
In part three of my post, I’ll discuss the OpenFlow project in more detail and will describe interesting applications and use cases. We’ll look at mirroring traffic flows for diagnostics and forensics, as well as datacenter applications. I’ll write about some of the influential companies involved and describe a standard for switch vendors to follow and the potential use to service providers.
Category : Industry Trends, Networking
