The Performance Reality of Session Border Controllers

The Performance Reality of Session Border Controllers

How to Effectively Define, Evaluate and Measure IP Session Control Requirements

A Sonus Networks White Paper

sonusnetworks.com

The Performance Reality of Session Border Controllers

Table of Contents
Introduction Session Control: Measuring for Success Real-World Performance Factors Number of Subscribers Number of Concurrent Calls Call Attempts Per Second (CAPS) Codec and Sample Rates Performance Under Attack Performance Under Load Transcoding Signaling Manipulation The Performance Impact of NAT Traversal The Performance Impact of Presence Encryption SIP Call Flows High Availability Centralized vs. Distributed Routing Use Case Scenarios Residential Broadband VoIP SIP Trunking Carrier-to-Carrier Peering Scalability in the Real World Conclusion 2 2 3 3 3 3 4 5 5 6 6 6 8 9 9 9 9 10 10 11 12 12 13

sonusnetworks.com

Introduction
Session Border Controllers (SBCs) will play a vital role in the next generation of IP network architectures. Thats the consensus from global service providers polled in a recent survey by Infonetics Research (SBC Deployment Strategies, October 2009). The survey found that capacity, scalability, and performance were the #1 considerations of service providers when selecting a session border solution. And theyll have plenty to consider, as IP traffic is expected to double over the next four years. While network operators know that IP voice and multimedia traffic will grow for the foreseeable future, planning a session border strategy around that growth has proven problematic. SBC vendors have historically underestimated the complexity of IP session control when publishing their performance and capacity numbers, often basing those figures on simplistic SIP call flows, erroneous bandwidth figures, and a limited subset of factors. As a result, network operators may find it necessary to deploy more boxes than anticipated, thereby increasing deployment complexity and cost despite their best efforts to predict capacity and bandwidth. At Sonus Networks, we believe that the typical approach to evaluating SBC capacity based on number of subscribers, concurrent sessions, and Call Attempts Per Second (CAPS) is a good beginning, but its only a beginning. Network operators need to look beyond these basic metrics to weigh other key factors such as the network application, media transcoding, Network Address Translation (NAT) traversal, and encryptionfactors that can heavily influence SBC performance. This white paper seeks to explore SBC capacity and performance measurements by sharing the lessons learned from Sonus Networks decade-plus leadership in VoIP and IP session control. In particular, well highlight performance factors that every network operator should consider, how those factors change in various application settings, and the SBC features/functions that separate the true performers from the underperformers.

Session Control: Measuring for Success

When SBCs were first introduced, Voice over IP (VoIP) was the exception in a world still ruled by digitalswitched networks. SBC performance was rarely challenged because early IP-to-IP connections served a minority of subscribers/sessions. The primary business driver for an SBC was security; capacity and performance were secondary concerns that, conventional wisdom went, could always be solved by adding more boxes to the network (a practice that still prevails today). As session-based traffic explodesand the promise of data, video, and voice convergence on an IP infrastructure is realizednetwork operators require more from their SBCs than simply security; multimedia support, network intelligence, and transcoding capabilities must be tightly integrated as well. For their part, many SBC vendors have responded by adding new functionality like call routing and transcoding into their products. However, performance in a multimedia environment still remains an Achilles heel for many SBCs, resulting in an ever-growing number of network elements that are becoming increasingly difficult to manage.

The Performance Reality of Session Border Controllers

Traditionally, SBC vendors measure capacity and performance using basic metrics such as number of subscribers, maximum concurrent sessions, and CAPS. Capacity planning then follows the simple logic of aligning box capacity with network requirements. If an SBC claims to support X number of concurrent sessions, the logic goes, then two boxes should support a network with a maximum of 2X concurrent sessions. This approach is flawed in its presumption of a very simplified SIP session with no concessions for the network environment or additional features like transcoding and encryption. Planning a VoIP network based on an idealized expectation of IP session requirements can have dire consequences including overloads, outages, lost transactions, and compromised network integrity.

Real-World Performance Factors

Effectively measuring session border requirements demands a holistic perspective that looks at the reality of SIP sessions and considers the bandwidth/performance factors beyond the superficial characteristics of subscriber and session numbers. Each of the following real-world performance factors should be carefully weighed and explored when evaluating SBC solutions.

Number of Subscribers
For access network environments, an obvious metric for capacity is the maximum number of subscribers that can be supported by an SBC. But be careful: this number often fails to take into consideration factors like NAT traversal or quality assurance measures, which can boost SIP session complexity considerably and dramatically reduce the number of subscribers that can be supported.

Maximum Concurrent Sessions

This is a theoretical maximum number of media sessions that can be handled by the SBC at one time. In todays network environments, the maximum number of concurrent sessions is becoming an increasingly irrelevant metric. Network operators are often facing other choke points in the network that determine capacity before the number of sessions over a Gigabit Ethernet (GigE) interface are reached. In a peering environment, this might include the number of Virtual LANs (VLANs) that can be supported or, in an access environment, the impact of control plane policing on the traffic flow where a 1:1 subscriber/flow control policing ratio is required.

Call Attempts Per Second

CAPS represent the number of call attempts per second. SBC vendors offer quote CAPS under ideal conditions, such as a peering or trunking topology with a very simple SIP call flow (e.g., seven SIP messages) and without any additional features or functions enabled (transcoding, etc.). This inflates performance numbers and does not give a true indication of an SBCs call handling capabilities under real-world conditions. In addition, the CAPS numbers presented by SBC vendors are often based on UDP transport and not Real-Time Transport Control Protocol (RTCP). This is an important distinction because RTCP requires an extra pinhole for the RTCP stream, which can reduce the maximum number of concurrent calls supported by up to 50%.

sonusnetworks.com

Codecs and Sample Rates

SBCs typically connect to the network via GigE interfacesone for the trusted network and a matching interface for the untrusted (peer) networkwith each session passing through both interfaces. The media handling capacity of an SBC using a GigE interface varies greatly depending on the media codec; G.711, for example, has an approximate capacity of 10,000 sessions over a GigE interface. Even the same codec at the same sample rate can have different bandwidth numbers depending on the calculations used. For example, G.711 sampled at a 20-millisecond rate has a listed bandwidth of between 87.2 kpbs and 95.2 kbps. Why the difference? Because the lower figure omits the portion of the Media Access Control (MAC) Ethernet frame that goes undetected by sniffing toolsthe MAC frame/preamble, start-of-frame delimiter, and inter-frame gapeven though it still consumes 20 bytes of bandwidth per frame. This consideration pushes the G.711 - 20 ms bandwidth to 95.2 kpbs, and reflects a much more accurate picture of bandwidth requirements. Below is a list of popular voice codecs, their payload sizes, and payload delivery expressed as Packets Per Second (PPS). The estimated bandwidth for each is calculated using the following formula: [Voice Payload + 58 bytes (IP/UDP/RTP and Ethernet L2 headers)] x PPS The actual bandwidth is calculated as follows: [Voice Payload + 58 bytes (headers) + 20 bytes (other MAC frame elements)] x PPS The final number in both calculations is then multiplied by eight, as bandwidth is expressed in bits (one byte = eight bits). Codec G.711 G.722 G.723.1 G.726 G.728 G.729 iLBC Voice payload 160 bytes 160 bytes 20 bytes 60 bytes 60 bytes 20 bytes 38 bytes 50 50 33.3 50 33.3 50 33.3 PPS Est. bandwidth 87.2 kbps 87.2 kbps 20.8 kbps 47.2 kbps 31.5 kbps 31.2 kbps 28.8 kbps Actual bandwidth 95.2 kbps 95.2 kbps 26.1 kbps 55.2 kbps 36.8 kbps 39.2 kbps 30.9 kbps

Using the estimated bandwidth figure for G.711 (20 ms sample rate) would give us a session capacity of 11,467 sessions over GigE. However, using the actual bandwidth as shown above (95.2 kbps), that number drops to 10,504 sessions. From there, we need to calculate the link utilization rate. A 100% utilization rate would produce intolerable packet queues and poor performance. If we modify the capacity measurement by taking into account a more sustainable link utilization rate of 90%, we arrive at a figure of 9,454 maximum concurrent sessions more than 2,000 sessions less than our initial capacity formula indicated. Calculating CAPS then becomes a matter of multiplying the actual concurrent sessions figure by the ACHT.

The Performance Reality of Session Border Controllers

Voice codecs also have different sample rates, which can affect the total bandwidth. G.711, for example, has a base sample rate of 10 ms and can be delivered in voice payloads of 10x multiples (e.g., 20 ms, 40 ms) in a single packet, which reduces packet header sizes per payload and thus overall bandwidth. Of course, longer sample rates also introduce potential issues in regard to latency and packet loss, so network operators need to weigh all considerations carefully when choosing an ideal sample rate. The chart below illustrates the actual bandwidth differences between G.711 in 10-40 ms samples. Codec G.711 G.711 G.711 Sample rate 10 ms 20 ms 40 ms 100 50 25 PPS Payload 80 bytes 160 bytes 320 bytes Actual bandwidth 126.4 kbps 95.2 kbps 79.6 kbps

Finally, network operators need to consider the transport protocol for the media. Transport Control Protocol (TCP) or RTCP, for example, require more processing than UDP. If this processing is done on the main SBC processor, call processing performance will logically degrade. It may be only a small degradation in and of itself, but compounded by other processing requirements (IPsec encryption, media transcoding, signal interworking, CDR collection, etc.) the impact on SBC performance can be quite significant.

Performance Under Attack

Like many IP-based applications, VoIP networks are exposed to a variety of security risks that threaten quality and stability. By design, SBCs are on the first line of defense against malicious Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks. SBCs therefore must identify and subdue these attacks quickly and recover gracefully without impacting the main call processors performance. This requires an orchestrated approach that combines embedded security at the hardware processor level with software-based security (blacklisting, etc.).

Performance Under Load

Non-malicious overloads such as those caused by high-traffic network events (e.g., a cable cut or power outage in the network) can similarly affect SBC performance. Again, the key characteristic that network operators should look for is a combination of hardware- and software-based mechanisms that address overload scenarios while preserving session quality/performance. When evaluating SBCs, ensure that the systems ability to continue to process established sessions and complete new calls is maintainedeven during severe traffic conditions. This can significantly impact a subscribers perceived Quality of Service as SBCs under load conditions may no longer complete calls, thus propagating the outage and extending its duration.

sonusnetworks.com

Transcoding
VoIP sessions passing through an SBC often require some level of transcoding. However, not all SBCs deal with transcoding the same way; some, for example, hand off transcoding functionality to an external device. While this device may be dedicated to the SBC, it remains a distinct element that is managed separately in the network, requires additional rack space, and adds one more hop in the session media path. Other SBCs perform transcoding as a software function of the main processor. This reduces the available processing (and thus the performance) for primary SBC functions like session handling and security, and can have a significant impact on performance and call quality. The method that Sonus has embraced for audio/media transcoding in an SBC is a dedicated Digital Signal Processor (DSP) embedded with the SBC hardware itself. This provides committed transcoding resources without affecting the performance of other SBC functions or burdening the operations teams with the cost of deploying, managing, and maintaining separate transcoding elements.

Signaling Manipulation
VoIP networks employ a variety of signaling protocols including H.323, SIP, and SIP-ISUP (SIP-I). In order to enable calls and maintain call features between H.323 and SIP endpoints, for example, the SBC is expected to provide signaling interworking between both endpoints. Considerable signaling manipulation also takes place between SIP endpoints and the VoIP network for call control. These tasks can be processing intensive and significantly impact the media/session handling capabilities of the SBC. Many SBC vendors assume simple SIP-to-SIP interworking when quoting performance rather than the more processing-intensive SIP-to-H.323 scenario, so network operators would be wise to question signaling protocol interworking when measuring SBC performance.

The Performance Impact of NAT Traversal

Network Address Translation, a necessity for topology hiding, introduces a new set of complexities into the IP session border control landscape. Specifically, NAT traversal requires increased signaling traffic in the form of frequent SIP REGISTER messages in order to keep the session alive through the NATenabled firewall. SIP registration through the NAT firewall can dramatically effect the number of SIP signaling messages, increasing them by more than 400%. While others suggest that you can address this problem by reducing the SIP registration refresh rate, this would first require a crystal ball. Simply put, you need to know the precise number of NAT-enabled endpoints before you can calculate SIP registration requirements. To illustrate the impact of NAT traversal on a SIP session, lets examine two network environments: both with 250,000 subscribers, one with NAT traversal and one without. Both environments will share the same contention ratio (10:1), yielding a call handling requirement of 25,000 concurrent sessions. In addition, both will presume an Average Call Hold Time (ACHT) of 100 seconds, resulting in 250 CAPS. If we assume an average of 10 SIP messages per call flow, we arrive at a call handling requirement of 2,500 messages per second. In our non-NAT environment, we would add an additional contingency for our 250,000 subscribers to send a SIP REGISTER message every 60 minutes (the typical default refresh time), or 140 messages per second. Our new call handling capacity then becomes 2,640 SIP message per second:

The Performance Reality of Session Border Controllers

SIP Session Requirements in a Non-NAT Environment SIP Centrex subscribers Contention Ratio Maximum number of concurrent calls Average Call Hold Time CAPS SIP messages per call flow SIP messages per second SIP signaling messages per second Total SIP call/signaling messages per second 250,000 10:1 25,000 100 seconds 250 10 2,500 140 2,640

Now lets look at an environment where NAT traversal is a requirement for 200,000 subscribers (and where 50,000 subscribers will not need NAT traversal). In order to keep a SIP session open through a NAT firewall, a pinhole will have to be created by sending frequent SIP REGISTER messages. The message frequency is determined by the time it typically takes a NAT firewall to close a session after the last message is sent; in our example, 50 seconds. This would add an additional 8,000 messages per second for registration handling (REGISTER and 200 OK messages) for our 200,000 NAT-enabled subscribers, plus a relatively inconsequential 28 messages per second for the remaining 50,000 non-NAT subscribers (as in our previous example, presuming one SIP REGISTER message every 60 minutes). This calculation now gives us a dramatically different number for session requirements than before: SIP Session Requirements in a NAT-Enabled Environment Subscribers requiring NAT traversal Subscribers not requiring NAT traversal Maximum number of concurrent calls Contention Ratio Average Call Hold Time CAPS SIP message per call flow SIP messages per second (call media) NAT SIP signaling messages per second Total SIP call/signaling messages per second 200,000 50,000 25,000 10:1 100 seconds 250 10 2,500 8,000 10,528

sonusnetworks.com

Clearly, the introduction of NAT traversal in the network environment has a dramatic effect on the number of SIP call/signaling messages: from 2,640 per second to 10,528 per second. This is a good illustration of why network operators need to look beyond CAPS, subscribers, and concurrent calls when determining SBC capacity. In the case where an allowance for NAT traversal had not been made, the network operator would be forced to reduce the number of subscribers and calls in order to accommodate the bandwidth demands for frequent SIP registration and re-registration.

The Performance Impact of Presence

Another critical SBC scaling problem relates to presence or IM services based on SIP/SIMPLE protocols. The message flow in a presence environment is impacted by three key factors: the number of subscribers, the number of contacts or buddies that each is connected with, and the timeframe between status changes. As each of these grows, the number of messages will multiply. For example, in the first case below, with only a small percentage of subscribers using presence with relatively modest buddy lists, the number of SIP messages generated is fairly manageable. SIP Messages in a LOW Usage Presence Environment Subscribers Number of subscribers using presence Average number of buddies per subscriber Average time between status changes per sub. Status changes 25,000 2500 10 60 min 7 msg / sec

Now, lets explore the impact of implementing a full Unified Communications environment. In this case, subscriber usage is likely ubiquitous with each user possessing a much larger list of contacts, and statuses will update more frequently due to the inclusion of in a meeting, on the phone, etc. SIP Messages in a LOW usage Presence Environment Subscribers Number of subscribers using presence Average number of buddies per subscriber Average time between status changes per sub. Status changes 25,000 25,000 100 15 min 2,778 msg / sec

As you can see, the messages related to presence can quickly explodewith nearly a 400x increase seen in this example. If you are using session border control in the midst of this communication, the scalability requirements to support presence can rapidly eclipse that of voice and must be factored into any network design decisions.

The Performance Reality of Session Border Controllers

Encryption
As a security function, SBCs are expected to encrypt network connections, IP packets, and specific media via Transport Layer Security (TLS), Internet Protocol Security (IPsec), Secure Real-Time Transport Protocol (SRTP), and other security protocols. Encryption can be a processing-intensive step, however, and degrade SBC performance if it is performed as a software function by the SBCs main processor. In order to provide optimal call handling capacity during encryption, this function is better handled by dedicated hardware such as a separate but embedded network processor.

SIP Call Flows

The complexity of SIP call flows can vary greatly depending on factors such as NAT traversal, proxy servers, and Centrex services like call transfers. Often, SBC product performance numbers are based on a simple, seven-message SIP call flow when measuring concurrent session capacity and CAPS. This can be short-sighted and misleading, as simply enabling PRACK can result in a ten-message SIP call flow, while a dual proxy scenario can boost the call flow to beyond twenty messages. Network operators should therefore look beyond posted performance numbers to see how SBC vendors arrived at those numbers, or run the risk of basing their border capacity on bad math.

High Availability
As critical network components, SBCs are expected to deliver high availability, even during adverse conditions such as DoS/DDoS attacks, overloads, and systems failure. Most SBCs have a redundancy scheme in place, yet not all SBCs handle this transition in a seamless and elegant manner. In the contingency of a system failure, for example, call states will be passed between the in-service and redundant pair of SBCs, which can significantly impact SBC processing. How well an SBC handles these contingencies should be considered when estimating and evaluating SBC performance.

Centralized vs. Distributed Routing

Historically, SBCs have been dumb devices that left network intelligence such as call routing and policy management to third-party devices in the network core. While some SBCs still follow this model, many SBC vendors have recently begun to develop call routing technology and co-locate it in their products, a feature sometimes referred to as localized or distributed routing. These vendors suggest that localized routing helps to reduce latency in the network, which is true, although whether this is faster or more efficient than centralized call routing depends on the implementation and other architectural considerations. Sonus Networks, for example, offers a mixture of distributed call routing servers with centralized routing intelligence and management. This approach greatly simplifies call routing database updates and policy management for the network through the use of a master routing/policy database where information is automatically propagated to distributed replica routing/ policy servers co-located with the SBC. The centralized management of distributed intelligence solves the dual problem of consistent intelligence across the network with localized intelligence for reduced latency and is unique to the Sonus solution.

sonusnetworks.com

Use Case Scenarios

In addition to the individual factors listed above is an overarching factor that greatly influences SBC performance and capacity: the network application itself. For the purpose of this white paper, well examine three common user scenarios: residential broadband VoIP, SIP trunking, and carrierto-carrier peering.

FIGURE 1. Residential broadband VoIP network architecture

Residential Broadband VoIP

The SBC in this case would be deployed in an access role, which means it would reside between the service providers core network and the subscribers accessing services over a residential broadband connection. The most important considerations for SBC performance and capacity in this scenario would be: number of subscribers, NAT traversal, SIP-to-SIP interworking, high availability, SIP call flow, security, and DoS/DDoS protection. CAPS would be determined by dividing the total number of subscribers by the contention ratio (i.e., the percentage of subscribers using the network at any one time), and dividing the resulting number (i.e., concurrent calls) with the Average Call Hold Time (ACHT). Generally, as the number of NAT-enabled subscribers increase, the capacity of the SBC drops. As seen in the NAT traversal calculations, most SBCs will need to reduce the number of subscribers and calls that each box can handle in order to accommodate the heightened messaging demands of frequent SIP registration/re-registration. The solution often proposed by SBC vendors is to add more boxes, which in turn raises the cost of the solution and the complexity of managing additional devices in the network. By contrast, the Sonus Network Border Switch and NBS5200 can support a high number of NAT-enabled sessions. Fewer boxes are required and, because Sonus uses real-world performance measurements rather than fair-weather conditions, fewer surprises occur.

The Performance Reality of Session Border Controllers

FIGURE 2. SIP trunking network architecture

SIP Trunking
A second access scenario with different session characteristics is SIP trunking between a service provider and an enterprise customer. Here, the SBC would provide a secure access entrypoint and session border between the service providers core network and the enterprises PBX. Because of the greater need for security at the enterprise level and the likelihood of legacy PBX systems, there are different considerations to take into account when measuring SBC performance and capacity for SIP trunking, including: CAPS, SIP-to-H.323 interworking, encryption (e.g., TLS, SRTP), DoS/DDoS protection, high availability, and SIP call flows. When measuring SBC performance in this environment, network operators need to take a close look at the devices support for SIP-to-H.323 interworking. Encryption is also important, specifically where the SBC performs the encryptionin the main processor or a separate processoras this can negatively impact call handling performance. Finally, its important that the SBCs perform stateful call handling during DoS/DDoS attacks, which again depends largely on where the security functions of the SBC reside. Because the Sonus NBS performs transcoding and encryption in a dedicated, embedded DSP, call handling performance in the main processor is not impacted, even during DoS/DDoS attacks.

sonusnetworks.com

FIGURE 3. Carrier-to-carrier peering network architecture

Carrier-to-Carrier Peering
In the case of carrier-to-carrier peering, the SBC resides between two service provider (or peer) networks and handles the IP sessions between them. Key SBC considerations in a peering application are the number of trunks and concurrent calls, SIP-to-SIP interworking (including SIP-I), encryption, SIP call flows, security, high availability, and media transcoding. The absence of directly connected subscribers means that CAPS is now generated by simply dividing the maximum number of concurrent sessions with the ACHT. Here, the focus of the SBCs performance shifts from serving subscribers to maximizing bandwidth utilization. Protocol interworking and transcoding are again important factors in a peering environment. Where SBCs lack these as embedded functions or perform them as a software function from the main processor, call handling performance will be negatively impacted. The Sonus NBS addresses peering requirements in a more efficient manner by embedding a dedicated DSP to perform these roles independent of the call handling processor.

Scalability in the Real World

Some SBC vendors would have you believe that increasing session capacity is as simple as adding more SBC boxes to the network. Yet this kind of boxed-in thinking can actually have the unintended effect of scaling deficiencies. Weve already discussed how many SBCs have substantial gaps in terms of features and functionality. What happens to these gaps as more SBCs are added to the network? They grow wider, requiring network operators to plug them with additional network elements for media transcoding, hardware resources to manage the SBCs, etc. In addition to rising costs, network operators may see decreased performance as SBCs scale. This is especially true in the case of SBCs that delegate media transcoding and encryption to their main processor rather than a dedicated DSP. Sonus Networks offers two session border solutions; one that migrates elegantly from TDM switching to IP session control (the Sonus NBS9000), and another

A Sonus Networks White Paper

that scales elegantly in an all-IP environment (the Sonus NBS5200). Both feature embedded DSPs that preserve call handling capacity even as media manipulation demands such as transcoding and security increase.

Conclusion
When comparing session border solutions, network operators need to take a hard look at the numbers and the underlying architecture to avoid making a faulty apples vs. oranges comparison. Specifically, when evaluating a session border solution, potential buyers should ask for numbers derived from use cases that reflect:
> > > > > > > >

More than just featureless vanilla SIP sessions Different peering and access configurations Performance under attack Security-enabled SIP transactions NAT traversal Heterogeneous networks (legacy gateways, multivendor PBXs) Media transcoding Complex call routing

Capacity measurements based on fair-weather assumptions or select functionality dont offer a true measure of performance, and only serve to box network operators into an SBC strategy that will ultimately be costly to manage and maintain as IP traffic grows. Session border solutions should be evaluated from a holistic viewpoint that includes call handling, call routing, security, and media transcoding. Only when network operators look at SBC performance under real-world conditions will they be able to accurately assess and implement a scalable, reliable border solution for the all-IP world of tomorrow. To learn more, call your Sonus sales representative or visit us online at sonusnetworks.com.

Sonus Networks, Inc.

7 Technology Park Drive

Westford, MA 01886

978.614.8100

The content in this document is for informational purposes only and is subject to change by Sonus Networks without notice. While reasonable efforts have been made in the preparation of this publication to assure its accuracy, Sonus Networks assumes no liability resulting from technical or editorial errors or omissions, or for any damages resulting from the use of this information. Unless specifically included in a written agreement with Sonus Networks, Sonus Networks has no obligation to develop or deliver any future release or upgrade or any feature, enhancement or function. Copyright 2010 Sonus Networks, Inc. All rights reserved. Sonus is a registered trademark and NBS9000 and NBS5200 are trademarks of Sonus Networks, Inc. All other trademarks, service marks, registered trademarks or registered service marks may be the property of their respective owners. Printed in the USA 08/10 WP-1100 Rev. A