Most SDN connections run less than 100 feet within one data center. The mission now is to move data center SDN into broader network uses, like DCI, SD-WAN, 5G wireless and CDNs.

Networks span the globe, connecting billions of users and devices. The average software-defined network connection is less than 100 feet, entirely within a single data center. It's hard to look at these two details and think software-defined networking, or SDN, is living up to its potential.

As cloud computing grows, cloud data centers will employ even more SDN. But will more data center success mean SDN has entered its golden age?

Most enterprises think SDN has to be used for more than switching inside the data center, so perhaps the biggest question surrounding SDN is how to break that 100-foot data center connection boundary.

One approach is to target SDN for a specific mission outside of the data center, like transport networking. While transport SDN is obviously a use that is outside of the data center, it is also an application that has little connection with data center SDN in an evolutionary sense. SDN has succeeded in the data center for a reason -- for several reasons, in fact. Some of these can provide a jumping-off point for a wider SDN mission, and all of them can point the way to identifying new and critical value propositions for SDN.

SDN for data center interconnections

SDN in the cloud data center succeeded because it solved two problems. First, SDN lets you build any number of Layer 2 Ethernet subnetworks to host multi-tenant applications. It also provides easy integration with cloud deployment tools, like OpenStack, Docker and DevOps products that facilitate deployment and redeployment. Second, SDN lets cloud providers build resilient network structures that avoid the old model of purely hierarchical switches and single-homed interswitch trunks.

The most obvious place to jump from this early area of SDN success is into the data center interconnect (DCI) space. Most cloud providers and large enterprises will have multiple data centers, with cloud-ready applications structured as multiple interconnected components. If those applications run in a multi-data-center business, they will likely spread across several data centers. This suggests any data center SDN could be spread out, as well.

The most important SDN feature for DCI support is inter-SDN controller cooperation or federation. Each SDN data center will likely have its own controller, and most SDN subnets will likely be built within a single data center. There needs to be a way to gracefully extend SDN across DCI, which means controllers need to cooperate in some way. Two proposed models are being discussed:

Building a controller hierarchy with a master controller on top.

Building another based on horizontal cooperation among controllers.

The first priority in getting SDN out of the data center is to create a single model for controller cooperation across DCI.

While it's nice to have choices, it's better to have a standard approach. The first priority in getting SDN out of the data center is to create a single model for controller cooperation across DCI.

The challenge in a good DCI-connected SDN deployment is defining how a multi-data-center deployment is divided among controllers. Clearly, you can't send a single service description to all of the controllers in all of the data centers and hope they'll come up with the right connections. You have to define specific DCI connectivity, then divide the service accordingly. This approach seems to argue for the use of a high-level controller to divide up the SDN mission based on where the hosting points are located. This approach hasn't been fully accepted, however.

Other SDN options: SD-WAN, 5G and CDNs

Multiple controllers and controller federations would let SDN extend IP subnets across multiple data centers, but all networks aren't IP subnets. A single, flat subnet structure would not scale even to a large corporate network. As a result, you have to move upward from a Layer 2 (data link) SDN structure to one at Layer 3 (transport layer). The easiest way to do that is to link SDN with another software-defined concept -- the software-defined WAN (SD-WAN).

SD-WANs are overlay networks, built using tunnels that act as virtual wires to build IP networks over any Layer 2 or Layer 3 infrastructure. SD-WANs can offer either Layer 2 Ethernet or Layer 3 IP services. SDN could be used to control the forwarding tables that route traffic across tunnels to other sites.

SD-WAN tunnels allow the same kind of multi-tenancy control in IP networks that SDN and virtual switching brought to the data center. While it is possible to control IP forwarding using SDN, the process risks having tenants compete to change common infrastructure. SD-WAN would eliminate that threat, making it possible to broaden SDN's mission.

The traffic-engineering mission of data center SDN can also be extended -- particularly in the metro area, where 5G wireless investment could offer a path to refreshing technology using funds already budgeted for mobile networking. Content delivery networks (CDNs) are distributed caches used primarily for video. As mobile broadband advances in importance, CDNs push closer to the mobile edge. Linking an appropriate cache to the mobile cell or cells a mobile broadband CDN serves is an important mission -- one that SDN could support by creating explicit connections between the two when video viewing demands it. All of this could be done with traffic-engineered quality of service, as well, which is critical for credible video quality of experience.

Network functions virtualization (NFV) in 5G applications could also increase SDN adoption. Many believe that 5G will encourage hosting virtual functions, which would create a direct data-center-to-5G linkage that SDN could exploit. Since NFV specifications already support SDN connectivity among virtual functions -- i.e., service chaining -- and in connections to users' service access points, NFV could directly drive service-wide SDN deployments.

Carrier cloud is going to make SDN a success, but the breadth of that success is still in question. With a little effort, SDN proponents can build a value proposition outward from data center SDN and eventually reach every part of the network. Taking the right steps to advance SDN specifications now can pay massive dividends in just a few years.

Join the conversation

2 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please create a username to comment.

Thanks Tom , thanks for sharing great ideas for transformation but as you know till now the NFV use cases and SDN use cases work in a bit silow . I mean only focus on DCI use cases , however even with DCI VxLAN has made possible to extend DC workloads across boundaries . What i understnad is that as of now SD-WAN is limited only to cases of ISV vendors where sole objective is scaling and not performance .

I can understand that bringing SD-WAN in this pipeline will enable faster and across boundary provision of workloads but really i do not think that this is what the industry looks for now . Even the 5G use case of MEC workload autoprovision in Edge DC with Central DC control can work if we have SDN DCI case and deploy SDN network on both DC and Metro rings .

So really which use case do you think will pull ISV's and enterprise use case in the Telecom or Service networks ......:)