19
B orn in 1969 as a Defense Advanced Research
Projects Agency (DARPA) test network, the
Internet is now more than 40 years old. The
TCP/IP-based Internet was destined to succeed due to three factors – connectionless packet switching, besteffort operational principles, and end-to-end transmission; all have helped it prevail over traditional circuit-switched architecture at each turning point in its development.
However, the Internet has inherent flaws in its scalability, security, mobility, and QoS. Improvements and innovations have been carried out to address them, including classless inter-domain routing (CIDR), network address translation (NAT), and multiprotocol label switching (MPLS), which, miraculously, have enabled the Internet to stay ahead of obsolescence to this day. However, the Internet’s fundamental flaws remain, and no amount of patching can ultimately overcome them. Many researchers are starting to believe that the problem can be ultimately solved by redefining the network structure, though this a task is on par with replacing a jet engine at 30,000 feet.
This radical solution, known in academia as the “Clean
Slate,” represents the abandoning of the original network structure altogether with a new one built from scratch, one that can satisfy current as well as future needs.
The Clean Slate moniker in its proper sense refers to a research program initiated by Nick McKeown from
Stanford, but it has since expanded to include a variety of government-led projects such as the Global Environment for Network Innovations (GENI) project, a subproject of the Future Internet Network Design (FIND) initiated by the U.S. National Science Foundation (NSF); the Future
Internet Research and Experimentation (FIRE) project, a subproject of the Seventh Framework Programme (FP7) of the EU; and the AKARI and corresponding testbed
JGN2+ projects sponsored by Japan’s National Institute of
Information and Communications Technology (NICT).
APR 2013
20

21
In 2007, Nick McKeown, his student Martin Casado, and Professor Scott Shenker from the University of California-Berkeley, founded Nicira, a network virtualization company with the slogan “OpenFlow.” In
July, 2012, Nicira was acquired by VMware in a USD1.26 billion deal; what VMware was after was Nicira’s network virtualization technology. In 2011, Nick McKeown and Scott Shenker co-founded the Open Networking
Foundation (ONF), a non-profit organization, seeking to expand the influence of OpenFlow and SDN beyond academia.
Though a college-level project, Clean Slate has a bold aim – reinvent the Internet. It advocates starting from scratch and abandoning the traditional incremental and backwards-compatible rules. Program coordinators have identified five key areas for research – network architecture, heterogeneous applications, heterogeneous physical-layer technologies, security, and economics & policy.
This program relies on the academic, scientific, and commercial resources of Silicon Valley to successfully draw both attention and funding. Clean Slate was phased out in
January 2012, giving way to four major follow-up projects
– Internet Infrastructure: OpenFlow and Softwaredefined Networking; Mobile Internet: Programmable
Open Mobile Internet 2020 (POMI 2020); Mobile Social
Networking: MobiSocial; and Data Centers: Stanford
Experimental Data Center Laboratory. As an incubator,
Clean Slate has undoubtedly been successful. The four follow-up projects are also attractive and promising.
Clean Slate’s research on network architecture started with OpenFlow. OpenFlow can be explained in traditional routing and switching terms. A traditional router or
APR 2013
22

21
switch has a forwarding plane and a control plane, with the latter performing route calculation and the former forwarding data. An OpenFlow switch separates the two planes by shifting the route calculation function to an independent controller. The controller and the OpenFlow switch communicate through the OpenFlow protocol.
The forwarding plane on the OpenFlow switch can then abstract the flow table to determine formats, matching rules, and actions for packets. One of the aims for
OpenFlow is the development of new network protocols so that the forwarding plane does not necessarily forward packets based on IP xTuple.
Initially, OpenFlow was simply defined as a Layer-2 control protocol, which is certainly not enough to revolutionize Internet architecture. If the forwarding planes for all nodes in a network are deployed externally through OpenFlow, the control and the forwarding for the entire network will be separated, allowing for more refined and sophisticated traffic management than access control lists (ACLs) and routing protocols on traditional routers would allow. In terms of network applications, separation of the control from the forwarding also facilitates virtual machine (VM) migration and security policy control.
This flexible software-based control lays the basis for the software-defined networking (SDN). More revolutionary than OpenFlow, SDN popularizes the idea of network virtualization, with OpenFlow functioning as an enabler.
Centralized network control and distributed forwarding are not new concepts. OpenFlow was first developed to control the forwarding planes of switches or routers through the network.
This out-of-band model very much resembles public switched telephone network (PSTN) architecture – a typical example of centralized control. Centralized network control is orthogonal to distributed Internet route calculation. The new wrinkle here is that OpenFlow is capable of controlling out-of-band equipment and testing new network-layer protocols in incubators such as campus networks. By supporting OpenFlow, a traditional equipment vendor is able to provide hooks to users that enable out-of-band control of devices, without releasing system implementation details.
After the control and forwarding planes are separated, the gear no longer needs to calculate routes for packet forwarding, making the task itself that much easier. With
SDN, bottom-layer hardware is virtualized, independent of VMs and applications running on it. OpenFlow’s design goal also aims at router commoditization, just like
PCs with Windows operating systems and applications.
Existing routers on the network can be transformed into
OpenFlow-enabled nodes, with newly-deployed network elements now OpenFlow-dedicated nodes, all with a simple forwarding plane. Network services can then be delivered flexibly as applications through application programming interfaces (APIs) or native applications.
However, the communications community is known for its resistance to radical reform. Since router design is dominated by major vendors as opposed to the OpenFlow community, the software layer is commonly added between the applications and the network engine, which functions as an alternate controller. Some alternate controllers are open-source applications, others are provided with APIs to access the network engine, while still others have no APIs at all. However, OpenFlow is only one of many possible ways to connect the forwarding plane with the controller, and major vendors often choose other practice-proven protocols.
APR 2013
22

23
Technically, SDN-based network virtualization makes connection between applications and the network possible.
The type of controller determines how difficult that connection is to make. However, technical difficulty is a secondary concern to carriers, who may be more worried about network deployment and evolution.
The jury is still out on this question. For the Clean Slate project, SDN is a new networking method that features the separation of the control plane from the forwarding plane, with unified OpenFlow acting as the channel and interface between the control plane and forwarding planes.
The centralized control plane makes the entire network topology transparent to applications and services, as well as virtualization and bottom-layer programming. In other words, this network restructuring does nothing less than redefine the Internet.
However, SDN cannot replace the Internet at this point, and neither can a lot of other innovations. In fact, it is inappropriate to compare SDN with the Internet, as each attempts to solve different problems.
If the forwarding and the control planes are separated, they still need to be connected in some way. And what’s more, distributed controllers also need to be connected, but direct interconnection of the planes or the controllers is surely impossible on a large scale. So what else can be used? Most current SDN ideas assume a traditional network, which means standard autonomous systems, routing, and peering architecture for interconnection.
In this sense, SDN is a supplementary layer or a virtualization layer of the current network, driven by technologies such as cloud architecture, dynamic resource allocation, mobile computing, and virtualized computing.
It aims to help carriers decouple services from interfaces to facilitate network O&M and simplify network structure.
SDN and the routing-based Internet can be compared to the kernel space and user space in an operating system.
Modern operating systems use process space to realize isolation and protection, and employ system calls to help applications access the kernel, while the memory management unit (MMU) maps virtual and physical addresses. However, isolation of the kernel and user space would seem to degrade system performance, and therefore many high-performance embedded operating systems allow users to directly access the kernel, without employing user space. Nevertheless, isolation, protection, and virtualization do have their uses. Programmers need only visit the virtual address, without considering the problem of kernel crash.
This makes application development kernel-independent, facilitating development and maintenance, and today’s software industry is based on this mechanism.
If SDN is to be applied to the current network, the prerequisite is the keeping of traditional bridging, routing, and switching functionalities, which secure scalability, interoperability, and reliability (similar to the basic functions of the operating system kernel). The upper SDN layer (or virtualization layer) decouples services from physical interfaces, interface features, and network topologies (similar to the kernel/user space isolation in the operating system). The upper layer services are similar to applications in the operating system. Such services seen in carrier use today are basically cache, carrier grade NAT (CGN), firewalls, load balancing, IPTV, and VPN. In view of the development of the software industry, it’s easy to envision that new
SDN application scenarios will be available for carrier, enterprise, and data center networks.
APR 2013
24

23
SDN cannot replace the Internet at this time, but it can be used in certain scenarios, especially in data centers and infrastructure as a service (IaaS) applications that use large numbers of VMs. Network virtualization obscures the location information for VMs, so customers who buy a large number of them need not know the details. Network virtualization, along with storage & computing virtualization, can implement flexible resource allocation in cloud environments, while simulating traditional interprocess communication (IPC) to deliver resource scheduling among VMs.
Niche applications will also be easier through SDN.
In an operating system, consecutive virtual addresses may correspond to discrete physical addresses. Similarly, the scattered storage space of data centers can be integrated into a pool to improve resource use efficiency. What’s more,
SDN makes their load balancing easier. Traditionally, link state update notifications are sent to each egress router, while distributed SDN can inform each server cluster, or even each hypervisor (virtual machine monitor) for link state updates. VMs and SDN have spawned many startups, who apply distributed dynamic resource computing to traditional services such as load balancing and firewalls.
As the old stomping grounds of SDN, campus networks are natural applications. FlowVisor (an OpenFlow controller) and SDN can create multiple independent and programmable logical networks (slices) on a physical network, which is advocated by the Global Environment for Network Innovations (GENI).
In the telco field, the most likely market is access services as carrier networks are in desperate need of flexible service migration. SDN and network virtualization effectively control traffic, making network planning and
O&M easier than static in-band processing.
Key challenges of applying SDN to carrier networks are performance, service complexity, and security. Most conservative carriers are skeptical of network openness; thanks to, or unfortunately because of, subscriber-aware services such as AAA (authentication, authorization and accounting), IPTV, and VPN, carriers cannot change their services/applications as often as Google and Facebook do.
IT enterprises are service-oriented. They hope to use
SDN to virtualize networks, computing, and storage, ensuring dynamic and flexible resource allocation for profitable business. Carriers, thus far, have been network oriented. Network bandwidth is a scarce resource and carriers face less competition than enterprises in other industries. In this sense, SDN helps carriers improve operational efficiency, service quality, and resource usage, while facilitating service deployment and not bringing about network architecture revolution.
SDN can serve as a guiding philosophy, with
OpenFlow, controllers, floodless deployment, and symmetrical/asymmetrical deployment supporting it.
Networking, computing, storage virtualization, and cloud computing have brought limitless opportunities for SDN and have greatly driven its development.
SDN is a rare opportunity for IT enterprises, carriers, and manufacturers. The problem is how to seize the opportunity. Once a bold presumption is established, you need to verify it. In the case of SDN, what the IT/telecom enterprises need to do is to see it through, to figure out the best ways (mechanisms) to fulfill their goals.
Editor: Michael huangzhuojian@huawei.com
APR 2013
24