If there’s one thing that makes the blood of a voice engineer run cold, it’s IP routing. In the old TDM days you have the assurance of circuits that were provisioned at every hop along the path. There was no guesswork about where a packet entered the network and where it exited. Call routing was predictable and stable. Sure, some trunks could get overwhelmed with large numbers of calls. There were also some paths that were over-provisioned and rarely used. But it all worked for the traditional TDM systems.
Then came the world of Voice over IP (VoIP). With the advent of running traditional voice services on top of IP there were a whole host of new issues introduced into the platforms. We traded flexibility for complexity. Sure, we could run software phones on our laptops across the country. We could run SIP trunks to add capacity at any time without analog setups. But we now had to worry about the paths those packets were taking. We quickly found out that TCP was a horrible solution for call routing because of the overhead. We built systems that were increasingly fast but needlessly complex. Things like NAT and asymmetric routing made people throw their hands up in disgust.
Vector For Voice
That’s why I was pleasantly surprised to see the platform that 128 Technology has built at a recent Networking Field Day Exclusive event held at their headquarters outside Boston, MA. I’d seen their technology back at Networking Field Day 20 in February and I even wrote up a piece about the 128 Technology tunnel-free architecture. But there’s way more to that architecture than it first appears on the surface.
After the presentation, I talked briefly with Jordan Martin (@BCJordo) and Chris Marget (@ChrisMarget) about the applications of the technology that we’d seen. After running down some of the highlights of what they’re trying to accomplish, the answer hit me smack in the face. And given the pedigree of the founders of 128 Technology, it makes perfect sense.
128 Technology utilizes a concept they call Secure Vector Routing, or SVR. In video above, they describe why they use this technology for forwarding traffic. The key takeaway is that 128 Technology focuses on using a session path instead of forwarding traffic on a per-packet basis. This allows them to build a stable path throughout their network to ensure that all of the packets are forwarded to the same endpoint, which 128 Technology refers to as a service.
Why would that be important? Well, as it turns out, for real-time traffic like video and voice, you want a predictable low-latency path. It doesn’t matter if there is slightly high one-way latency going through the network, but the variation between those packets making up the session should be minimal. Not-so-coincidentally this is one of the reasons why voice packets use UDP for transmission instead of TCP. We don’t care if an individual packet gets lost but the latency between packets gets all out of whack when you’re acknowledging each of them and requesting retransmission for lost data grams.
Another thing that makes 128 Technology very suitable as a voice routing platform is the aforementioned lack of tunneling technology. 128 Technology is still able to use metadata to tag session packets to ensure they wind up in the right spot. But even that metadata is only a few hundred bytes appended to the first packet of the session. Because the 5-tuple information of the source router is considered a unique identifier for the session, the 128 Technology router network creates a session table entry for the flow and starts treating packets with that same 5-tuple as part of the same flow. So, for example, a voice call between to IP phone endpoints would qualify as a session. So you can transmit the call from HQ to branch office and all the individual UDP voice packets would be treated as the same flow and follow the same path.
Lastly, one of the added benefits for the 128 Technology solution is payload encryption. 128 Technology can encrypt the payload of an individual packet in a session or the payload of all the packets in the session. It’s instantiated by the L4 policies on the network device or traffic flow. That means you can choose not to double encrypt traffic that’s already encrypted, like SSL or SSH traffic. The flip side is that you can encrypt traffic that isn’t already encrypted, such as voice traffic. The payload encryption is based on ephemeral keys held in router memory along the path. That means you don’t have to mess around with icky certificates or try to create IPsec tunnels that cris-cross the network. Everything is controlled from a central policy engine. You can make a couple of clicks and ensure that all the voice calls in the network are encrypted in transit. Or you could just encrypt specific endpoints, such as the CEO’s phone or the security operations center.
The Packet Pedigree
So, how is it that 128 Technology managed to build the perfect voice routing platform without realizing it? Remember earlier when I said that they had the pedigree to do just that? Well, the founders of 128 Technology came from Oracle by way of the Acme Packet acquisition. Acme Packet had been building VoIP Session Border Controllers (SBCs) and multi-service gateways for years before getting acquired by Oracle in 2013.
The Acme Packet team had a lot of experience solving the challenges of voice routing through SBCs. That’s a kind of dark magic that no one should have to sort out. But they did it so well that they were the leader in the technology right up until they were acquired. To them, solving the problems of routing packets across the WAN wasn’t much different from routing voice sessions. And when they started treating those data packets as sessions they were able to apply all their knowledge to the problem and make it work the way they wanted.
Is 128 Technology the solution for everyone? Probably not. There are some very specialized networks out there that are tuned to high performance. There are also a lot of networking professionals that worship on the altar of BGP and other routing protocols. Or perhaps they love the idea that every packet path through the network is really an IPSec tunnel for super duper security. If any of those apply to you then 128 Technology likely isn’t the best solution for you. Instead, for those companies looking to build security into their WAN routing setup or for those network professionals looking to build an SD-WAN or cloud on-ramp network starting from square one, it’s worth it to take a look at the 128 Technology solution. You might just find a solution in the best voice routing platform that’s been built in the last decade.
For more information about 128 Technology, be sure to check out their website at 128technology.com. For more coverage of the Networking Field Day Exclusive with 128 Technology event where these topics were discussed, make sure you check out the following posts:
- Packet Walking Through A 128 Technology Network by Ethan Banks
- Network Collective Short Take with 128 Technology by Jordan Martin
- Packet Pushers Briefings in Brief 81: 128 Technology Rethinks the WAN Router
- Wi-Fi6 Ratification: Not So Fast My Friend - October 14, 2019
- Connectivity Solved with Aryaka - October 11, 2019
- All-In on AI With Mist and Juniper - October 10, 2019
- Firefox DNS-over-HTTPS for the Enterprise - October 9, 2019
- When Is Something SD-WAN? - October 8, 2019
- Supply-Chain Security and Trust - October 3, 2019
- Using SD-WAN to Unify Communications with NEC and InfoVista - October 3, 2019
- Customer FAQ: Is NAT Security? Should I Remove My Public IPv4 From My Internal Network? - October 1, 2019
- Technologies and the Protocols May Not Be Used for What They Were Intended - September 26, 2019
- Securing Open WiFi With OWE - September 24, 2019