The VoIP Peering Puzzle�Part 43: SBC Architectures�Juniper Networks

Juniper Networks, Inc., headquartered in Sunnyvale, California, develops high performance IP platforms that enable customers to support a wide variety of services and applications. The company claims to hold the number two market position for service-provider routers, high-end enterprise routers, and overall network security solutions. It has also pioneered many industry innovations, including delivering the first platform based upon application-specific integrated circuits (ASICs), the first ASIC-based firewalls, the first intrusion-detection-and-prevention product, plus secure socket layer (SSL) virtual private networking (VPN) products.

These systems have been deployed by service providers, enterprises, governments, and research and educational institutions worldwide. From its base of 89 offices in 39 countries around the globe, the company claims to serve all of the world’s top 30 service providers and 92 of the Fortune 100. The company has over 4,800 employees, and posted $2.6 billion in revenue in 2006.

Juniper Networks acquired Kagoor Networks, Inc. in May 2005, and with that purchase, obtained the company’s VoiceFlow session border controller products, which had been installed in over 100 carrier networks worldwide—most of which also used Juniper’s routing platforms. Given this product synergy, Juniper recently stopped development on standalone SBCs, to focus and prioritize development efforts on the integration of SBC functionality into their edge and core routing platforms. The company’s goal is to enable a carrier-grade VoIP/SIP-aware solution for next generation networks that is capable of supporting millions and millions of subscribers and sessions.

To better understand Juniper’s integrated system, consider the more traditional SBC architecture, which is typically comprised of two parts: a lower Packet Transport process—which includes routing and switching functions—and an upper Application Session process, where the session traffic, such as voice and video, flows between end stations. With these existing solutions, the Application and Transport processes are completely isolated from each other, without communication between the two. For example, the Application process might initiate packet delivery over the Transport process without alerting that lower layer of any quality or reliability requirements that are necessary for delivery. Absent these critical details, the Transport process could then assign that traffic a “best efforts” service, which could potentially degrade the performance required by that application.

Juniper’s solution to this challenge distributes the SBC functions in the network, and defines two architectural planes with distinct responsibilities: an upper Control Plane, which is responsible for general signaling services, and a lower IP-based Transport Plane, which handles the media services. An open interface would provide communication between these two planes.

The Control plane functions include connectivity, security services, protocol interworking, call routing, and load balancing, enhanced quality of service (QoS), and regulatory compliance functions. These functions would be supplied by Juniper business partners’ systems.

The Transport plane functions would include QoS marking of the signaling and media flows, Network Address Translation (NAT), Far End NAT traversal, bandwidth theft detection and notification, denial of service (DoS) prevention, and E911 bearer preemption. These functions would be provided by Juniper systems, which would incorporate the Kagoor technologies.

Juniper claims that distributing the SBC functionality at the edge of the network will provide some significant advantages over existing stand-alone or centralized SBC architectures. First, it provides the ability to filter or block unwanted flows (such as security attacks at the network edge) before these unauthorized flows enter the network. Second, flows can be prioritized at the edge of the network—thus ensuring QoS on an end-to-end basis—instead of sending the traffic through the network until it reaches the SBC for priority handling. Third, by rate-limiting flows at the edge based on bandwidth estimates, bandwidth can be preserved and associated network costs presumably reduced.

Furthermore, some scalability benefits are expected as well. This distribution of functionality allows service providers to scale as requirements increase, and also only scale the specific SBC functionality that is necessary. For example, service providers requiring additional SBC capacity would only purchase additional licenses or possibly add a new router line card into an existing router. This is in contrast to the stand-alone model that requires an entirely new SBC to be added to the network in order accommodate growth.

The as-yet-unnamed Juniper development is currently in beta testing with Tier 1 service providers, with early deployments expected early in 2008, and general availability of the integrated solution some time during the second half of 2008.

Further details on the Juniper Networks architecture and products can be found at Our next tutorial will continue our examination of vendors’ SBC architectures.

Copyright Acknowledgement: © 2007 DigiNet Corporation ®, All Rights Reserved

Author’s Biography
Mark A. Miller, P.E., is President of DigiNet Corporation®, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.

Latest Articles

Follow Us On Social Media

Explore More