Metaswitch pitches DC-SBC; should Acme Packet be afraid?

on

Metaswitch has been talking a lot lately about VoIP Session Border Controllers (SBCs). They recently took their DC-SBC product to the SIPit interop testing event in June. And they just published another white paper about SBCs and their role in IMS.

The Enfield company formerly called Data Connection Limited definitely makes solid software. Rumor has it some of these gents were hired to make some of the first VoIP implementations for Cisco and for Microsoft. And if you look closely when doing VoIP troubleshooting, you’ll still see Alcatel-Lucent gear advertising their SIP stack built years ago. So they certainly know VoIP protocols, and I have reason to expect great things from their SBC implementation.

Nevertheless, rolling out a Session Border Controller product at this stage in the market is tough. Acme Packet has a dominate lead in market share; but more importantly, they dominate in field-tested features. The Acme Packet Configuration Guide reads like a military history of battle plans of the form:

so your endpoint devices came at you with <insert insane endpoint behavior here>? Well, add this magic incantation to sip-options and you’re off and running!

But Metaswitch isn’t trying to go up against Acme Packet. In fact, in early 2009, they signed a deal to re-sell Acme Packet gear.

So what is Metaswitch’s angle on Session Border Controllers?

As the recent white paper “Session Border Controllers in IMS” discusses, they see three key markets for their SBC software:

  • High End Tier-1 Mongo Service Provider: Integrate the SBC into the other VoIP equipment, like the access media gateway.
  • Small/Medium Mom-and-Pop Telco: Integrate the SBC into the Service Provider Edge Router.
  • Enterprises: Integrate the SBC into the Access router.

SBC as part of Core VoIP Equipment

The brilliant minds behind IMS believe the SBC features will be smeared across your core feature server, media gateways, and other such devices. You’ll have bits of SBC functionality here and there. This logic follows the classic zero-one-infinity principle of Computer Science:

0: The IETF told us we didn’t need SBCs at all.

1: Most VoIP Service Providers wanted SBC at one point in the network.

&#8734: But we IMS guys love SBCs so much, we’ll put it everywhere!

The pros:

  • You get to do things like interworking, ALG, codec stripping, and policy enforcement where-ever you dream it to be.
  • You’ll get to share the power supplies and rack space of an existing chassis.

    The cons:

  • You get to troubleshoot things like interworking, ALG, codec stripping, and policy enforcement everywhere! The novice-engineers and technicians, given the power to configure these complex features at numerous points in the network, will inevitable create monsters where manipulations in behavior could occur anywhere. While the goal of IMS was to create a straightforward framework that network designers could build to match, the flexibility of the IMS standards will birth mind-blowing complexity.
  • Since when are things like media gateways put at the edge of the network? They’re always somewhere inside the core of the Walled Garden managed network, protected from attack or overload by the SBC.
  • Sprinkling SBC functionality throughout ignores one of the key SBC functions in actual working networks: high-performance security policy enforcement.

    Several vendors are trying to do this in the media gateway. Did you know Convergent is still in business? They’re attempting to sell a SIP version of their media gateway, complete with SBC functionality built right in. Genband is trying this too with their SBC product, integrating it into their core media gateway.

    SBC in the Service Provider Edge Router

    It’s clear from all the marketing that one of Metaswitch’s big pushes is get their DC-SIP software integrated into Service Provider Edge Routers. This is the router to which service providers connect their DSL, T1, DS3 and other customers.

    Metaswitch has some neat ideas here. For example, they discuss the ability to assign a virtual SBC instance to individual interfaces on the router. That sounds a lot like the way the Cisco Firewall Services Module (FWSM) lets you assign firewall instances to individual VLANs.


    But more specifically, this sounds like Metaswitch wants to provide exactly the kind of functionality found in the Cisco Unified Border Element, an SBC available in some of Cisco’s routers. (In fact, it’s possible Cisco is already using DC-SBC for this purpose, but I don’t have any direct evidence of that.)

    The pros:

  • You’ll have the SBC functionality close to the customers.
  • You’ll get to share the power supplies and rack space of an existing chassis.
  • This puts the SBC in the neighborhood of the VoIP-Edge firewall.

    The cons:

  • It’s possible the SBC functionality might be a little too close to some customers; you might have some complex routing to get all of your traffic through the SBC blades/line-cards. E.g., suppose you have fifty customer-edge routers but only one core VoIP network. Are you really going to buy 50x SBC cards/licenses, and connect every customer-edge router to the VoIP core network?
  • VoIP Carrier networks are already quite complex. It’s a challenge for carriers, currently, to manage the basic network; through in the additional virtualization complexity of VLANs and VRFs, and many smaller Carriers just can’t control their network. Further virtualization and combination will only make the network harder to manage. Metaswitch needs to think hard about ways to make the network comprehensible, and virtualization/integration of devices that would otherwise stand alone militates against it.

    SBC in the Customer-Premise Edge Router


    Metaswitch would love to get their DC-SBC into the customer premise equipment. Who wouldn’t? This is the device that gets sold millions of times. The Edgewater EdgeMarc is one leading Customer-premise SBC-type gadget.

    The pros:

  • It is helpful to have a device that’s aware of the phone calls at the customer edge for troubleshooting and monitoring.
  • The Edgemarc is very popular among network designers, so you’d expect a competing product to do well too.

    The cons:

  • Unfortunately, the Edgemarc is very popular among network designers of overweight networks. They design in so much complexity that the costs per customer can be significantly higher than more streamlined designs. Sometimes the complexity of the CPE ALG interworks with other complexity in the network in ways that make the network fragile.

    Many network designers want an ALG at the customer premise, so there’s good reason to expect Metaswitch could be quite successful here.

    MetaSwitch’s Gentle Argument against Standalone SBCs

    Metaswitch has gently argued against the standalone SBC, e.g., the Acme Packet SBC products.

    They seem to argue:

  • The IMS standards call for SBC functionality smeared everywhere, so a standalone device isn’t the best fit.
  • Having the SBC as a separate device, “adds another device into the network, increasing the network’s complexity and latency, and introducing another point of failure”.

    However, as a network integrator and operator for the past seven years, I find these arguments weak:

  • It’s hard to find a working, functional, profitable network with more than two bits of IMS resemblance. When IMS suggests that SBC features should be available at many points in the network, they’re daydreaming in the “wouldn’t it be nice if we could” genre.
  • If you install the SBC as separate line-card into an existing router or gateway, you’ve added all the same complexity that you’d have by installing a new device in the rack. You might be using an existing power supply and communications busses, but the complexity is equivalent.
  • If you DO integrate the SBC into the same software platform with another network element, you’ve genuinely increased the complexity of that software element while reducing the physical complexity.

    The SBC Integration that Makes Sense


    In many networks, the SBC sits side-by-side with a data firewall. It’s not parallel to the Media Gateway, and it’s not parallel to the Provider Edge router. So as designer of functional networks, I would be most interested in an SBC / data-firewall integration.

    The combination of two security devices that sit at the border of the same security domain would be quite practical. You could use the same two-plane architecture commonly employed in high-end SBCs (e.g., Acme 4250) and high-end firewalls (e.g., Cisco FWSM):

    • A conventional processor to handle signaling. Scale it up by splitting endpoints across different processors.
    • Network Processors to handle packets after the flows have been approved. Scale it up splitting flows across different NPs.

    Should Acme Packet fear?

    The key reasons I recommend Acme Packet for standalone SBC deployments are:

    1. Stability: The platform works all day, every day for months at a time.
    2. Features: I’m rarely the first to need a feature, so the oddball and innovative features are there by the time I need them. Plus, there are features that are only needed as a carrier scales up.
    3. Deployment Scale: Thousands of these things are out in use, which means they’re being tested heavily by those thousands of deployments.

    The DC-SBC might do great for Stability; let’s assume it will. And because DC-SBC is a young platform, it’s not clear just how widely used it is used, and actually knowing that will be tough. For example, it’s important to note that not ever Cisco ISR with IP-IP-Gateway functionality is actually using that functionality; likewise when the DC-SBC is integrated into another device, it’s not always clear when or if that will be used.

    But I don’t know that DC-SBC has the thousands of oddball features needed for interworking in modern, diverse carrier environments. When I talk to large service providers using Acme Packet SBC, they’re always employing tons of custom processing of the signaling by rewriting the SIP in many ways. Further, Service Providers large and small use many of the bizarre and obscure features of the SBC to get a reliable network.

    So if you, dear customer, are considering the DC-SBC, be sure it really has the features you actually need. And the only way to know that is to actually integrate and prove the network under load. And then you have to anticipate what features you’ll need as the network scales up.

    I’m not an Acme Packet shareholder, and I genuinely hope for some honest competition among SBCs. SBCs are mind-blowingly complex — almost as complex as the telephony application itself. For a new SBC to enter the market seriously, some service providers are going to have the guts to deploy and test the things, and the vendors are going to have to work awfully hard to meet the existing expectations for SBCs.⊗