OpenFlow, SDN: Impact on Telecom networks
I heard of OpenFlow three years ago while working for a WiMAX operator, but it never peaked my interest to read up on it till Nicra was acquired by VMware this year. This is when it occurred to me that this space of the network industry is gearing up for serious change a scenario which will impact Mobile ecosystem even on the edge. In contrast to the LAN, the WAN is staid. In the early 2000s, IT organizations began to move away from Frame Relay and ATM and adopt MPLS WAN services. However, up until now, the conventional wisdom in the IT industry has been that there isn’t a fundamentally new technology in development that will replace MPLS. A key consequence of that assumption is that, on a going-forward basis, IT organizations will have to build their WANs using a combination of MPLS and the Internet.
Software defined networks (SDN) have the potential to change the conventional wisdom about WANs. SDN isn’t a technology, but a way of building networks. Like many of the good commercial successes in IT and software SDN was started as project in Stanford as a part of PhD thesis of Nick McKeown. SDN based on OpenFlow is a novel programmatic interface for controlling network switches, routers, Wi-Fi access points, cellular base stations and WDM/TDM equipment. While there is not uniform agreement within the industry on the definition of SDN, the general consensus is that it involves the separation of the control and the forwarding planes of networking devices, the centralization of the control planes and providing programmatic interfaces into the centralized control planes.
While most of the interest in SDN has been focused on the data center LAN, earlier this year Google discussed how it has used SDN in the WAN to carry traffic between its data centers. According to Google, when the project began, there weren’t any network devices that could meet its requirements, so the company built its own. It also built its own traffic engineering (TE) service. Its TE service collects both real-time utilization metrics and topology data from the underlying network as well as bandwidth demand from applications and services. The Google TE service uses this data to compute the best path for traffic flows and then programs those paths into their switches.
What is OpenFlow/SDN? SDN is a new approach to networking and its key attributes include: separation of data and control planes; a uniform vendor-agnostic interface called OpenFlow between control and data planes; a logically centralized control plane; and slicing and virtualization of the underlying network. The logically centralized control plane is realized using a network operating system that constructs and presents a logical map of the entire network to services or control applications implemented on top of it. With SDN, a researcher or network administrator can introduce a new capability by writing a simple software program that manipulates the logical map of a slice of the network. The rest is taken care of by the network operating system.
Promise of OpenFlow/SDN: Enabling innovation and creating choice has been a proven recipe for realizing best solutions in the market place and that is exactly what SDN is attempting to do with networking. SDN enables innovation with its network operating system and network virtualization. The network operating system provides a central vantage point and well defined API that make it easy for the operator or a third party to create new network management and control applications. The application developer essentially operates on a local network graph or even a simpler abstraction of the network and does not need to worry about all the complexity of the distributed control of the network. Network slicing and virtualization makes it easier to experiment with new capabilities in isolated slices of the network without impacting other part of the network. Network virtualization, as server virtualization, also significantly helps with efficient use of network resources with multiple customers and services.
SDN enables choice with the separation of data and control planes and a vendor agnostic interface OpenFlow between the two, well-defined API for the network operating system, and network virtualization. The OpenFlow interface allows a network operator to mix and match devices from different vendors and make independent choices for the control and data plane vendors. The well-defined API for the network operating system means third parties can develop and sell network control and management applications creating more choice for the network operators. Finally, network virtualization allows a network operator to use different and customized control plane solutions for different virtual networks and thus not become dependent on a single vendor.
The Network Operating System API combined with slicing and virtualization also makes it possible for researchers to experiment with their research ideas on a slice of a production network without impacting it – within or across campuses – offering researchers a much larger realistic infrastructure than has been possible before. Short videos of example research experiments enabled by OpenFlow/SDN can be found at http://www.openflow.org/videos/.
Real world problems of today: Big networks are expensive to run and service providers are always looking for ways to reduce their capital and operational costs. One approach is to combine different specialized networks, reducing the number of technologies the operator needs expertise in, and reducing the number of boundaries between different types of networks. For example, many network operators have combined their separate voice and data networks to great effect. We call this “horizontal convergence” in which (typically) IP data networks replace specialized voice, video and control networks.
Networks today running at two layers that can be converged. Over the years, there has been much talk about how transport networks (built from optical and electronic circuit switches) could be subsumed by the packet-switched services that run over them. There are several ways to do it. One way is to use only packet switching, and emulate circuits where fixed rate services are needed. Another way is to connect packet-switch routers with direct point-to-point optical WDM links, and remove transport layer switching altogether. Optical circuit switching cannot be eliminated; on the contrary, it offers significant advantages in the core of the network. First, optical switching is much more scalable; an optical circuit switch can switch much higher data rates, and consume much less power than an electronic packet switch. As a consequence, they are simpler, lower cost and more space efficient than an electronic packet switch. A useful rule of thumb is that an optical circuit switch consumes about 1/10th of the volume, 1/10th of the power and costs about 1/10th the price as an electronic packet switch with the same capacity. On the other hand, a circuit switch doesn’t have the statistical multiplexing benefits of a packet switch. This matters little at the core of the network where flows destined to the same next hop are naturally bundled, and their aggregate is relatively smooth. On the other hand, closer to the edge of the network packet switching offers big benefits due to statistical multiplexing and more fine-grain control. OpenFlow seeks a way to reap the benefits of both circuit switching and packet switching, by allowing a network operator to decide the correct mix of technologies. If both types of switch are controlled and used the same way, then it gives the operator maximum flexibility to design their own network. In particular, circuit and packet switched networks can be controlled via the OpenFlow protocol.
IP and transport networks today are separate: In a typical service provider’s organization, two networks are operated and managed by separate groups. For example, operators such as AT&T and Verizon run separate IP and SONET/WDM networks leading to lots of duplication. Fault tolerance is a prime example: The underlying transport network often operates with 1:1 protection, while the IP network running on top operates at less than 30% link utilization in preparation for unexpected traffic surges and link failures.
IP and transport networks do not interact: IP routers are typically connected via wide-area pseudo-static circuits. IP networks (L3) cannot benefit from dynamic switching in L1/L0 networks, and instead regard the links as dumb pipes. If an operator could dynamically create and destroy light paths, their networks could be more cost efficient, and use less energy.
What does it mean for the User expereince? Does the user/customer really care what happens in the ‘plumbing pipes’ ? Well it is but food for thought as with LTE & LTE-Adv the average round trip time for a RAN round trip time is less than 10ms.
Note: All the above discussion can be found here – http://www.openflow.org/wk/images/9/95/UArch_Cam_Rdy.pdf