A group of organizations in Atlanta has launched a software-defined networking exchange, called the Southeast Network Access Point, which will allow carriers, research institutes and enterprises to interconnect physical networks using SDN.
Members of the software-defined networking (SDN) exchange will be able to stretch virtual network segments or tenants across multiple physical domains with policy intact, essentially forming a private Internet using Layer 2 interconnect. The Southeast Network Access Point (SNAP) could solve the challenge of networking across private and public data center clouds.
We've been talking about source-based routing for many years, but we've never been able to pull it off. SDN has [the] capability to do that.
CTO, Georgia Institute of Technology
The SDN exchange began as an experimental collaboration involving the Georgia Institute of Technology, Global Environments for Network Innovation (GENI), US Ignite, Southern Light Rail and PeachNet. It lives in the Colo Atl at 55 Marietta Street Carrier Hotel in Atlanta. But the idea was born across the street at the data center hotel, 56 Marietta, which was acquired by interconnect company The Telx Group in 2004. Over the years Telx executives continually heard the need for a new kind of interconnect.
"Collectively the Atlanta community determined there was a need for a physically diverse interconnect facility," said Hunter Newby, CEO of Allied Fiber and a former strategist for Telx. "They started doing interoperability testing, and they realized a need existed for interoperability at Layer 2 as opposed to just Layer 3."
SDN exchange use cases emerge
The idea of interconnection at Layer 2 became a reality with the emergence of SDN.
Most SDN research has focused on strategies that decouple the network control plane from the underlying physical infrastructure and provide a holistic vision of the network. With that visibility, engineers can use controllers to granularly program networks down to the individual data flow. This programming can be based on any number of factors, including bandwidth availability, time, traffic patterns, etc.
Until recently, SDN researchers and vendors have focused on applying network programmability within data centers or wide area network domains. However, in an SDN exchange, participants can stretch that visibility and programmability across physical networks.
In this scenario, controllers could be used across multi-protocol, multi-service, next-generation networks to change forwarding tables based on that same wide range of characteristics. In an SDN exchange, multiple carriers will be able to jointly implement policy-based routing, source-based routing and security and Quality of Service policy to provide a less expensive and improved service. They'll also be able to dynamically provision virtual network tenants or segments across domains.
Once this is possible, large institutions and enterprises might choose to avoid using the public Internet, instead creating private networks for sensitive data or multimedia applications that need special optimization, for example.
"We've been talking about source-based routing for many years, but we've never been able to pull it off; SDN has [the] capability to do that," said Ron Hutchins, CTO of Georgia Institute of Technology. Going further, carriers could implement "time-of-day routing," for example, where they could offer different prices or levels of service depending on time and availability, he added.
SDN exchanges would have an obvious advantage for cloud providers. Eric Dean, chief architect at SNAP, said he expects the technology will allow hypervisors and "computing systems to be aware of characteristics of the network." That means when a virtual machine (VM) must be replicated, the hypervisor would have knowledge of available network capacity and be able to locate the closest available server.
"You're seeing the need for cloud systems to no longer trust there is sufficient networking infrastructure to meet their needs, so they'll be more aware of what's going on," Dean said.
An SDN exchange: Many protocols, many architectures
SNAP is firm about not backing any one specific SDN protocol, architecture or underlying hardware. For now, the exchange is still a test bed, and the point of testing is to see what works.
While SNAP directors won't detail the range of hardware and software that has already been implemented, they have confirmed that OpenFlow-friendly Brocade is providing a cross-connect fabric. But there are also other "high-end" manufacturers' switches that have the ability to stretch up to 100 GbE with the right line cards.
More on SDN use cases
SDN may be the answer to Network as a Service
VIDEO: How SDN can boost security
Using SDN for granular security policy control
Why there's a role for SDN in the campus LAN
The presence of OpenFlow-friendly switching is not the only avenue of SDN the group is exploring. It plans to test out Cisco onePK and other approaches, as well.
"We are not tied to OpenFlow vs. the IEEE," Dean said. As time goes on, the protocols that don't work will be "weeded out," he explained.
And in some cases, the necessary protocols haven't yet emerged. SNAP is in the process of testing so-called "inter-controller protocols" that are still developing, and it will experiment with a number of different controllers.
"Rather than us choosing one SDN controller, we can do this on a port-by-port basis," Dean said.
SNAP is currently accepting members.