Departure From TCP/IP
In a software-defined network, a central controller maintains all the rules for the network and disseminates the appropriate instructions for each router or switch. That centralized controller breaks a fundamental precept of TCP/IP, which was designed not to rely on a central device that, if disconnected, could cause entire networks to go down. TCP/IP's design has its roots in a day when hardware failures were much more common, and in fact part of the U.S. military's Defense Advanced Research Projects Agency's intent in sponsoring the original research behind the Internet was to develop Cold War-era systems that could continue to operate even when whole chunks of the network had been vaporized by a nuclear bomb.
Today's needs are far different. Letting virtualized servers and other network resources pop up anywhere on the network and instantly reroute traffic as they do is far more important than gracefully recovering from router or switch crashes. Large enterprise Wi-Fi networks already make wide use of controller-based architectures, and the SDN concept is well proven there. Breaking into the data center and other core enterprise network functions is another matter.
Two major obstacles stand in the way of generalized acceptance of software-defined networks. The first is the absence of a technical specification that describes how hardware vendors should implement the SDN constructs in their products. That problem's easy to solve, and good progress is being made with the OpenFlow standard, first proposed by Stanford researchers and now on its way to becoming a recognized standard.
The second problem is tougher to solve because it involves convincing the likes of Cisco, Juniper, and Brocade--the three vendors of TCP/IP networking equipment to both the enterprise and to carriers and big-data Internet companies--that it's in their interests to participate in OpenFlow.
OpenFlow itself doesn't fully solve the problem of creating a software-defined networking environment, but it adds some important pieces missing from the existing IP network management and control protocols.
First, OpenFlow defines what a controller is and how it can connect securely to network devices that it will control. Second, OpenFlow specifies how a controller will manipulate a switch's or router's forwarding table, which specifies how incoming packets get processed and sent on. Previous to OpenFlow, there was no standardized way to directly manipulate the forwarding table, so SDNs were either completely proprietary or functionally handicapped.
| 2011 | 2010 | |
| 71% | 62% | High availability of applications/services |
| 52 | 40 | Ability to deploy IT services faster |
| 51 | 52 | Disaster recovery |
| 43 | 42 | Lower data center operating costs |
| 17 | 22 | Ability to build prototype IT services faster |
| 15 | 6 | Reduced data center carbon footprint |
| 15 | 35 | Continuous data protection |
| 13 | 8 | Ability to use fewer IT staffers in data center |
| 4 | 6 | Self-provisioning by business units |
| 1 | 8 | Ability to charge business units for IT resources |
| Data: InformationWeek Virtualization Management Survey of 396 business technology professionals in August 2011 and 203 in August 2010 | ||
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
