Juniper Session Smart SD-WAN Deep Dive Part 1: 128 Technology and the Tunnel-Free Premise

The Contrail arc that closed out the previous series ended on a specific verdict: Juniper didn’t fix CSO, it bought a company that had built something structurally different from day one. This series is about that company’s product, now shipping as Juniper’s primary enterprise SD-WAN platform. It starts, appropriately, with where the idea came from — because the pedigree explains the architecture better than any feature list would.

Session border controllers, not routers

128 Technology was founded in July 2014 by Andy Ory and Patrick MeLampy, alongside the technical team that had built Acme Packet — a session border controller (SBC) vendor sold to Oracle for $2.1 billion in 2013. That’s not a routing company’s pedigree. SBCs sit at the edge of VoIP and real-time communications networks doing something routers traditionally don’t: tracking individual sessions — a specific call, a specific media stream — with full awareness of where each one starts, where it’s going, and what policy applies to it specifically, rather than treating every packet as an independent forwarding decision.

128 Technology’s founding bet was that the same session-aware discipline that made sense for voice traffic at an SBC made sense for all enterprise WAN traffic — and that building a router around sessions as the first-class object, rather than packets or tunnels, would eliminate a category of overhead every tunnel-based SD-WAN vendor was carrying by design.

What “tunnel-free” actually means

Every SD-WAN architecture covered elsewhere on this site — Fortinet’s IPsec overlay, Cisco/Viptela’s OMP-signalled tunnels, Arista/VeloCloud’s DMPO-optimized tunnels, Palo Alto’s Secure Fabric Links — moves traffic by encapsulating it: wrap the original packet in a new IP/UDP header, carry it across the underlay inside that wrapper, decapsulate at the far end. That wrapper is what makes the overlay work, and it’s also fixed overhead on every single packet, plus the operational cost of building, maintaining, and rekeying the tunnels themselves at scale.

128 Technology’s Session Smart Router — the product this whole series covers — does not encapsulate traffic in this sense at all. Its underlying protocol, Secure Vector Routing (SVR), works by modifying the original packet’s header fields directly and relying on ordinary IP routing across the underlay to move it, with cryptographic metadata carried in the packet itself rather than in a tunnel wrapper around it. Then-CEO Andy Ory put the pitch bluntly at the time: “we leverage the underlay, we don’t instantiate really costly, computationally expensive tunnels.” The next post in this series goes into exactly how that metadata and routing works; this post is about why that goal mattered enough to build a company around it.

What tunnels cost that a session-aware model doesn’t have to pay

Three costs specifically motivated the tunnel-free bet, and they’re worth naming because they’re the yardstick the rest of this series measures Session Smart Routing against:

Per-packet encapsulation overhead. Every IPsec ESP-wrapped packet carries extra header bytes and encryption/decryption cost on every hop that touches it, which is a real, if usually modest, tax on throughput and MTU budget — a tax this site’s IPsec deep dive series covers in detail from the conventional-overlay side.

Tunnel-state operational load. A tunnel is a piece of state that has to be built, kept alive, rekeyed, and torn down — multiplied by every site-pair in a mesh topology, or by every spoke-to-hub relationship in a hub-and-spoke one. The Contrail routing deep dive showed what that state management looked like at the hub in a VRF-segmented multi-tenant deployment; it’s real infrastructure that has to be sized, monitored, and maintained regardless of vendor.

Coarse-grained policy. A tunnel is typically the unit of policy — traffic either goes into this tunnel or it doesn’t — which pushes fine-grained, per-application or per-service policy decisions up into a separate classification layer sitting in front of the tunnel selection. A session-native architecture, by contrast, can make that policy decision as a property of the session itself, at the point the session is first recognized.

A pioneer’s product, not an incumbent’s retrofit

It’s worth being precise about a claim 128 Technology made about itself: it billed Session Smart Router as the first, and for some time the only, SD-WAN solution that was genuinely IPsec-tunnel-free. Whether or not it stayed unique on that specific point as the market matured, the origin story matters for understanding the architecture that follows in this series — this wasn’t an existing router vendor bolting SD-WAN features onto an established forwarding plane, the way SRX-based Contrail SD-WAN was built on an existing firewall platform. It was a from-scratch forwarding architecture, built by people whose prior product had made “track the session, not the packet” work at carrier scale for real-time voice traffic, aimed squarely at the assumption every other SD-WAN vendor had built on top of rather than questioned.

Juniper’s acquisition of 128 Technology was announced in October 2020 and closed that December, for approximately $450 million. What Juniper got wasn’t an incremental feature — it was an entirely different premise for what an SD-WAN router’s core job should be. The rest of this series covers what Juniper built on top of that premise: the routing mechanics themselves, the two control-plane options (Session Smart Conductor and Mist), the AI-native operations layer, the security model, cloud onramp, a migration playbook, and finally how it stacks up against the four other SD-WAN philosophies already covered on this site.