There is no single, clear definition of softwaredefined networking (SDN), but there are two sets of beliefs centralized control and management of packet forwarding vs. a distributed architecture. This expert E-Guide discusses these SDN strategies and what kind of implementation will follow. Additionally, learn about a new portfolio of SDN products that will launch in 2013. There is no single, clear definition of software-defined networking. But there are two camps with two sets of beliefs: One camp consists of SDN purists and the other of SDN pragmatists. The purists believe in centralized control and management of packet forwarding, while the pragmatists rely on a distributed architecture where decision making is spread throughout the network. Each SDN strategy has its strong points and both are likely to see implementation depending on the scenario. The problem with traditional networks Switches in traditional physical networks forward information in packet form based on a combination of knowledge, including a network address in the packet and information about the topology and connectivity of the network itself. Forwarding tables tell each device what port should be used as the destination of a given packet. In traditional networks, these tables are built through the exchange of topology and status information among network devices. This discovery process is managed through special control packets, and thus the discovery and forwarding table is called the control plane, which is separate from the data plane where data packets are handled. But discovery and adaptive autonomic behavior makes it difficult to engineer traffic patterns, predict performance or create quick and orderly recovery from failures. problems create a period of disorder as devices attempt to discover new paths. During this period, data can be lost or Page 2 of 8
delayed significantly, and no device has full knowledge of what other devices might be contributing to its traffic. This makes load calculations and Quality of Service (QoS) difficult to secure. SDN purists and the centralized controller model The purist model of SDN technologies evolved from researchers who aimed to replace adaptive discovery with central control of forwarding. In this architecture, a central software process -- or centralized SDN controller -- maintains the entire topology and status of the network's devices and trunks and understands the network addressing and connectivity from the user's perspective. This central process then uses various algorithms and policies to define routes through the network for each permitted flow. The paths are created by telling all devices along the way to change their forwarding table to pass the packets along the path correctly. The OpenFlow protocol was designed to be the language used by the centralized controller to communicate forwarding table changes to network devices. This communication could happen proactively based on a network map or in response to a request from a device for instructions on how to handle a packet for which it had no forwarding entry. More on SDN architecture and strategy The challenge in this SDN approach is the lack of a proven model for centralized control. The Internet and its IP foundation demonstrably scale to the scope of today's online world, but there is no proof that central control of networking can scale and no currently accepted technology to test its capabilities. What is most likely to happen with centralized SDN is a kind of interior deployment. The problems of scalability and central control are most easily addressed not over the whole of the Internet or even an enterprise WAN, but in a data center, within a cloud, in a content delivery network or in a WAN core. Page 3 of 8
Deploying centralized SDN in these interior domains can spread widely and quickly. Over time, the standards bodies and vendors can address the best way of linking disparate SDN domains into a complete end-to-end network. When and if this happens, the centralized and distributed SDN models will be in a state suitable for side-by-side comparison, and the question of the ideal SDN technology can then be answered. Distributed SDN -- or evolution instead of revolution For now, many experts and vendors believe this centralized SDN strategy, however pure its foundation, is unnecessarily revolutionary; evolution is more prudent. The value of adaptive discovery in building forwarding tables has been established by decades of use, including the success of IP as the foundation of the Internet. To this group, which includes many IP experts and router equipment vendors, the software that should be defining network behavior is higher-level software, perhaps even application software. The centralized SDN strategy substitutes computer-hosted software processes to control forwarding behavior while the distributed model adds mechanisms for software (and increasingly cloud) control to traditional IP and Ethernet networks. The distributed model, like the centralized model of SDN, accepts the need to gather information about network status and collect it at a central point where it can be acted on to manage performance. But in the distributed model, the goal of SDN is to offer more controllable behavior, and that goal could be met by leveraging extension protocols like PCC/PCE/PCRF (policy and charging rules function), MPLS and GRE. Of these protocols, policy-controlled networking appears most important. Virtual networking principles, such as those used by Nicira (recently acquired by VMware), could make Ethernet and IP more suitable for virtual-network applications and cloud computing, and can be easily added on top of the evolutionary model. This could be executed using distributed decision making. Page 4 of 8
The challenge for distributed SDN is that it has yet to prove that it can offer the kind of tight control over traffic and connectivity that centralized SDN technologies could offer. Here again, there's also the problem of an accepted framework for applying distributed SDN principles. Many users fear that this model of SDN will become proprietary since vendors will work to integrate it into their existing closed systems. By: Shamus McGillicuddy Juniper s will launch a portfolio of software-defined networking products later this year under the brand name JunosV Contrail. The first Juniper SDN product -- available in the third quarter -- will be the Contrail Controller, which will initially provide centralized control for a virtual overlay network. The Juniper SDN controller is based on technology Juniper acquired last year when it bought startup Contrail Systems. Today, JunosV Contrail Controller is an overlay network solution comparable to VMware NSX, Midokura MidoNet and Nuage s. The controller interacts with virtual switches on hypervisor hosts using Extensible Messaging and Presence Protocol (XMPP) as its control plane protocol. Contrail Controller also uses Border Gateway Protocol (BGP) for control plane scaling across LANs and WANs. "XMPP offers lower overhead and higher performance," said Joe Skorupa, vice president and distinguished analyst at Stamford, Conn.-based Gartner Inc. "And they use BGP for federation across controllers." The Contrail Controller doesn't support OpenFlow or any other protocols for direct control of network hardware, but Juniper didn't rule out future support. For now, Juniper is focusing on delivering a virtual overlay network. Page 5 of 8
"Most of the infrastructure that is out there today either doesn't have OpenFlow capabilities on it or will require some upgrade to get it, which means rip and replace," said Brad Brooks, Juniper vice president of marketing and strategy. "The protocols we're using with Contrail mean you can overlay software right on top of existing infrastructure and get benefits right away. It's not to say we won't support OpenFlow [in our controller]. If it becomes a de facto standard for how to communicate with the underlying physical network, then we can put that in support for the controller. But we're really looking at and focusing on standard protocols that already exist in physical networks today." Juniper SDN eyes carriers and enterprises with scale, open APIs Juniper s Inc. is angling JunosV Contrail at both carriers and enterprises, said Jennifer Lin, senior director of product management for Sunnyvale, Calif.-based Juniper. Both are looking for "ways to drive better operational efficiency and ensure that the network is exposed as a service or set of services, and not just a siloed part of the infrastructure," she said. To that end, Juniper is exposing a RESTful application programming interface (API), instantiating its own OpenStack Quantum plug-in, and announcing several partnerships geared toward integrating its SDN technology with leading cloud orchestration systems. It's partnering with Citrix on CloudStack integration and with Cloudscaling and Mirantis on OpenStack integration. Contrail's scale-out control plane based on BGP will appeal to carriers, enterprises and cloud providers looking to federate controllers across the WAN. "We're focused on how to get a scale-out control plane. In this case, we're extending mature protocols like BGP, which run today's Internet, and linking together autonomous systems across IP networks," Lin said. Juniper SDN will integrate overlay and underlay for diagnostics and analytics Page 6 of 8
Like other vendors who are enabling an SDN-like virtual overlay network, Juniper requires basic Layer 3 connectivity on the underlying physical network. Juniper hopes to differentiate itself from VMware and others by connecting the physical and virtual networks together. "One difference between Juniper and VMware is that Juniper will link management of virtual and physical to enable debugging problems," Skorupa said. "Otherwise, figuring out if the [network] problem is in the overlay or the physical IP network is extremely difficult at best." Juniper is working on bridging protocols like BGP and MPLS into its overlay network so JunosV Contrail can interact with Juniper's switches and routers to extract diagnostics and analytics from the physical network and combine it with the software overlay, Lin said. "We're able to correlate if something goes wrong in your pod," she said. "You have both the diagnostics of the virtual infrastructure as well as the physical underlay." Integrating physical and overlay networks will be essential, according to Bob Laliberte, senior analyst with Milford, Mass.-based Enterprise Strategy Group. "Just like you can't keep on provisioning virtual machines in physical servers without an understanding of what is going on (memory and CPU usage, etc.), these overlay networks need to understand what is going on in the physical infrastructure or underlay," he said. Page 7 of 8
Free resources for technology professionals TechTarget publishes targeted technology media that address your need for information and resources for researching products, developing strategy and making cost-effective purchase decisions. Our network of technology-specific Web sites gives you access to industry experts, independent content and analysis and the Web s largest library of vendor-provided white papers, webcasts, podcasts, videos, virtual trade shows, research reports and more drawing on the rich R&D resources of technology providers to address market trends, challenges and solutions. Our live events and virtual seminars give you access to vendor neutral, expert commentary and advice on the issues and challenges you face daily. Our social community IT Knowledge Exchange allows you to share real world information in real time with peers and experts. What makes TechTarget unique? TechTarget is squarely focused on the enterprise IT space. Our team of editors and network of industry experts provide the richest, most relevant content to IT professionals and management. We leverage the immediacy of the Web, the networking and face-to-face opportunities of events and virtual events, and the ability to interact with peers all to create compelling and actionable information for enterprise IT professionals across all industries and markets. Related TechTarget Websites Page 8 of 8