SIP and SDN: Perfect Together, Says Sonus and Juniper

We tend to think of SDN as being some modern revolution, but in fact there have been some pretty significant SDN antecedents in play for decades.  One, believe it or not, is in the VoIP space, and now this proto-SDN may be joining with the mainstream SDN wave through a vendor partnership.

One of the issues with session-based voice or video communication is the difficulty in providing QoS.  With pair-wise communication taking millions of possible paths, it’s essentially impossible to pre-position high-quality paths to carry the traffic.  While there are protocols available to reserve resources (RSVP), these aren’t typically supported for user-service missions today because there’s no mechanism for charging and settlement.  When the Session Initiation Protocol (SIP) and related services were launched, the architecture included the notion of intermediate session handling devices—Session Border Controllers or SBCs—to act as authentication elements for session services.  These gadgets created a kind of virtual-network overlay on top of IP, and if you provided quality paths between SBCs you could get traffic to go where it was assured better QoS because the SBCs were anchors that defined specific route points.  You can’t QoS-route a million voice sessions end to end, but you can QoS-route a couple dozen sessions between SBCs.

What’s now happening is that Sonus (one of the old-timers in the VoIP space) and Juniper have formed an alliance to marry SIP services and Juniper SDN.  The technical details of the marriage aren’t fully articulated, but what appears to be happening is that SBC-to-Juniper control traffic will allow policy-based management of the traffic flows, particularly for video but also voice and generalized UC/UCC.  Some Sonus SBC-related application elements are also expected to be made available on the JunosV App Engine at some point.

Sonus’ SBC-based services are already compatible with SDN even without the alliance, for the reason I stated above.  If I can create a virtual overlay with a few fixed “router” points I can easily prioritize paths among those points.  What the Juniper deal would do is to make it possible to accommodate the kind of dynamic traffic flows that are likely to emerge when video is added to the UC/UCC picture.  Reserving the capacity to support full video collaboration would be impractical for cost reasons; better to expand and contract traffic support as needed, which is what the deal can do.

Underneath all of this there’s a series of potentially significant developments at the systemic/strategy level.  First, we may be seeing an example of Juniper’s intentions to provide the same kind of policy-based vertical integration between an overlay-virtual-network technology (including SIP/SBC) and the data plane as it offers in its JunosV Contrail example.  That might mean that Juniper could add some value even to non-Contrail overlays.  Second, we may be seeing a way for Juniper to gain some end-to-end benefits for its JunosV Contrail Controller approach; link higher-layer service policies to the traffic plane from any source those policies can be made available.  Third, we may be seeing some specific progress toward defining how “SDN applications” could develop.

UC/UCC is one of those areas that everyone has said was on the verge of taking off, all the way back (so it feels like, anyway) to the Nixon presidency.  It hasn’t.  However, there is no question that enterprises are very interested in a fusion of mobile/behavioral services, cloud computing, and UC/UCC.  The “UCaaS” (pronounced “you-cass” for those who don’t like to spell out acronyms) model is for many network operators a natural leap into the software-as-a-service promise of the cloud.  SaaS, you will recall, will always support the highest profit margins because it displaces the largest costs.  Operators know that, and they also know it’s easier for their sales force to sell UCaaS than to sell CRM or some other business service.  The question has been how to create and differentiate the service.  Linking it to SDN would help in the latter mission, but not in the former.

The devil is in the details, of course, and you can see from all the bold qualifiers in the statements above that we don’t have much of the details yet.  This move could be highly strategic for both companies or simple naked opportunism.  It could even be a precursor to some M&A; Sonus rival Acme Packet was after all just bought by Oracle.  We’ll need to watch this development to see how it evolves, but in particular watch the way that the session infrastructure, the SDN framework, the underlying transport resources, and the UCaaS application layer all work together inside this alliance.  Something strong could be a very strong play for both parties, given operator interest in UCaaS as a kind of camel’s-nose SaaS strategy.  It could be strong enough, in fact, to make a significant difference in both Sonus’ and Juniper’s business models in 2014.  Whether it will depends on just how much technical thought the two companies are prepared to put into the deal.

Leave a Reply