I interviewed Dan Grosz who discussed Implementing NextGen Networks: A Corporate Perspective.
It’s nice to speak with you again, Dan. This is a follow-up interview to our last interview. Can you first give a little bit of background about what we talked about last time?
Sure, thank you, Dustin; it’s a pleasure to be with you again. Last time we talked about the provisioning of next-generation networks from a supply chain perspective, and I talked about some of the high-level features and characteristics of this new network architecture, which is far more dynamic and agile than anything we’ve known in the past. Today what I’d like to do is drill down a little bit and focus more on what this next-generation network means from a corporate perspective.
Thanks. My first question is: What are some key considerations corporations might have in their next-generation network architectures?
There are several. One is that traditional networks are simply not designed to handle the types of traffic growth anticipated for services such as presence, instant messaging, video streaming, call forking, as well as the massive migration that we’ve seen to mobile and cloud-based solutions. They need to really update their networks. That’s the basic impetus they need to consider.
Second is that networks will need to be increasingly agile and scalable, and that’s something not readily available with traditional network technology. Existing networks typically take a long time to roll out and to set up and provision and maintain, and they’re not designed to rapidly adapt to changing user patterns, new types of data, and so on. We’re seeing increasingly new kinds of data information proliferating.
Third, there are increasing security challenges, and it would require networks to behave differently than before. Essentially, networks will have to become intelligent and be able to adapt much more rapidly and intelligently to threats, which are also rising rapidly.
Fourth, companies will need to take an increasingly architectural perspective that fuses layers of what’s called the OSI stack, the open-systems information architecture stack. Particularly, there are three and seven, which is the network to application layers cohesively. These things will become more tightly coupled, actually, going forward, and I’ll explain what that means a little bit later on.
Finally, the other key consideration is the movement away from proprietary hardware to open standards and virtualization.
My second question is: What are corporate session border controllers, and how are they different from traditional SBCs, session border controllers?
First of all, this device, the session border controller, I think is the key piece of this new network that’s emerging. We’ve had SBCs for quite a while now, but traditional standalone units were designed primarily for large carriers and Fortune 500 companies.
Recently, they’ve been some key drivers to re-envision what an SBC is and how it works and who uses it. One of the major differences was spawned by a white paper that was presented in 2012 by 13 major international network operators. These included companies like Verizon and NTT and China Mobile, some really big major players around the world. They called for network function virtualization, which is actually being driven by advances in standard hardware that allow you to put an SBC function on a standard server. There is no longer a need for technical proprietary systems we used to have for SBCs.
Increasingly, there are new offerings from a number of vendors, such as Metaphase and Sonus that are addressing this rapidly growing opportunity space. Interestingly, vendors that have been slower to respond to this new kind of SBC, such as Cisco, have seen an unfavorable market response. Look to a lot more things to happen in this space with existing vendors. Interestingly, key software vendors, such as Oracle, are realizing the need to extend and fuse network functions into their core ERP offerings, and this was evidenced by Oracle’s acquisition of Acme Packet in February of 2013.
Finally, there’s an increased adoption of Microsoft’s Lync unified communications offering in corporate environments. Traditional PBX systems are being rapidly phased out. All of these things are drivers for corporate SBCs versus the network carrier SBCs that we’ve seen in the past.
What is the difference between an SBC and a firewall, and why does it matter?
Great question. It’s useful to think of an SBC as a super firewall, and the main difference is that an SBC is designed to handle real-time streams of information, what’s typically referred to as RTP, and that’s the major difference between old networks and the newer ones. The older ones were not really designed to handle real-time streams of information.
Beyond that, the role of an SBC is far broader than that of a firewall in that it can force complex policies or business rules. These rules can affect every aspect of network behavior, including security, bandwidth management, and quality of service. Corporate priorities can be instantiated as SBC business rules. An example of that is, let’s say, dynamically changing the quality of service under certain scenarios; let’s say reducing the resolution of video streams if there’s a network surge or dynamically reallocating resources from signaling to media and back as circumstances require. Fourth, the ability of SBCs to secure and encrypt endpoints across the enterprise is particularly irrelevant given the increased popularity of BYOD, or bring your own device, to the corporate environment.
Furthermore, SBCs can manage transcoding between analog and digital devices. This is important because most enterprises are unable to rip and replace older or analog technology in one shot, and SBCs allow them to do so incrementally because they can essentially manage the interaction between the legacy and new systems seamlessly.
Finally, cloud-based business applications that fuse information from multiple sources, such as business analytics, li-on, this SBC technology, and session-initiated protocols that run on SBCs to marshal and manage disparate data sources, and that’s really becoming a very important, new corporate IT function that really didn’t exist several years ago.
Do you have any case studies of companies actually using SBCs in this new way?
I can give you some examples that have come from the literature, but, mind you, this is really a new and emerging area, so the number of published case studies is still limited, but I think you will find that there will be a lot more as time goes on. One good example—and these are actually real case studies, not made-up ones—is the ability to quickly ramp up or down customer service resources or even rapidly change outsourced customer service vendors.
For example, if you have a holiday season coming on, like we do now, and you need to add a significant number of customer service reps, having an SBC with business rules embedded will allow you to do that and provision data and network and telecom resources much, much more quickly than you can with a traditional network.
Another example is the simplification of network hardware while allowing seamless transition from legacy PBX platforms and vendors to new ones. Again, the SBC, because they can do the transcoding, can mitigate the complexity of having to keep a lot of legacy hardware in place while doing this migration.
Another good example of how companies have used SBCs is with functional services such as fax services; being able to move these into a cloud-based solution, for example, while still maintaining the fax service but behind the front end, it’s a very different technology that enables this.
A fourth example or case study is enhanced collaboration by implementing a corporate unified communications infrastructure while, at the same time, reducing telecommunications charges. This will become an increasingly important function of SBCs.
Finally, the automation of provisioning and call routing, resulting in significant IT savings. Essentially, the automation of producing manual IT functions. Those are some examples I’ve been able to see in the marketplace, but there are a lot more coming down the road.
Thank you, Dan, for sharing your views today on implementing next-generation networks from a corporate perspective.
You’re very welcome, Dustin; my pleasure, as always.
About Dan Grosz
IT Executive and Information Architect.