SDN basics for service providers
A comprehensive collection of articles, videos and more, hand-picked by our editors
Amid all the talk of SDN innovation, there has been very little conversation about how SDN use cases will ever generate revenue. But Sonus Networks says using SDN and network virtualization to optimize capacity for video and collaboration applications could potentially increase revenue for service providers.
Sonus, a session border controller and unified communications vendor, announced this week that it will integrate its SBCs with Juniper Networks' network virtualization platform, the JunosV App Engine. The combined technologies will let service providers spin up capacity on demand for specific communications sessions and set policies that adjust the quality of service (QoS) level for each session, based on need.
That means, for example, that a service provider could choose to assign a QoS level to a telepresence session at noon on a Monday that was higher than the level assigned to a voice call placed at 11 p.m. on a Saturday. Over time, service providers will be able to "monetize network assets" by delivering service-level agreements (SLAs) that ensure varying tiers of service at different prices.
More on SDN use cases
What will happen when SDN and wireless meet?
How Microsoft is using SDN for network monitoring
SDN could make Network as a Service a reality
SDN for the campus LAN?
How SDN can change security policy enforcement
"We are talking about [providing] a finer grain of control over the network for these new services that require dynamic SLAs," said Aashu Virmani, Sonus' senior director of corporate strategy and business development. Providers will be able to ensure this better control over QoS without having to expand capacity because they'll be able to provision -- and deprovision -- network space based only on need.
Behind the scenes, Sonus' SBCs essentially will run on the JunosV App Engine as virtual machines (VMs). Because these VMs can communicate with Juniper's routing and forwarding plane, there is real-time communication between the application layer and the underlying network layer each time a communications session is established. The SBC tells the Juniper routers where a call must originate and terminate and at what level of quality.
"The SBC can talk to all of the routers from point A to point B, from Boston to New York [for example], to find out where there is capacity," Virmani said. "After the call is over, the SBC will communicate back to the routers and say, 'You can release the capacity.'"
In this scenario, scaling up collaboration services will require additional VMs that run on x86 machines. That means providers can bring up services much more quickly and at a significantly reduced cost, said Brad Brooks, vice president of marketing and business strategy for Juniper's software solutions division.
For now, the JunosV App Engine can manage these VMs across only underlying physical networks composed solely of Juniper hardware. But when Juniper's JunosV Contrail SDN technology launches later this year, Sonus will be able to spin up these VMs and services on virtual networks that stretch across any underlying physical network. These virtual networks will be managed by Juniper's new Contrail controllers, making service provisioning even more dynamic, Brooks said.