Juniper Session Smart SD-WAN Deep Dive Part 2: Secure Vector Routing — Tenants, Services, and Session Metadata

Part 1 covered why 128 Technology set out to build a tunnel-free SD-WAN router. This post is the mechanics: what Secure Vector Routing (SVR) actually does to a packet, and the data model — tenants and services — that makes session-aware, symmetric routing possible without encapsulation.

The core problem SVR has to solve without a tunnel

A conventional tunnel-based overlay gets symmetric, policy-aware forwarding almost for free: because traffic is encapsulated into a specific tunnel, both directions of a flow naturally follow the same logical path, and policy is applied at the tunnel boundary. Give that up, and you need another mechanism to guarantee the return leg of a session follows a path that’s aware of the same policy and state as the outbound leg — otherwise you risk asymmetric routing, which breaks stateful inspection and makes consistent policy enforcement much harder.

SVR’s answer is to make the session itself — not the packet, not the tunnel — the unit the network reasons about, and to establish that session explicitly on the first packet rather than inferring it after the fact.

What happens on the first packet

When the ingress Session Smart Router (SSR) sees the first packet of a new flow, it does two things a conventional router doesn’t: it identifies which tenant and which service that traffic belongs to, and it adds metadata onto the packet carrying that identity plus routing and policy information — described in Juniper’s own technical material as metadata covering original IP addressing, tenant, and policy information. That metadata travels with the session across the network, referenced (not re-derived) by every SSR the session’s path touches, and — critically — used to force the return traffic back through a path that’s aware of the same session state, giving symmetric, bidirectional forwarding without ever building a tunnel to guarantee it.

This is the piece of the architecture that makes “tunnel-free” more than a marketing claim rather than just “we don’t call it a tunnel.” The metadata is doing the job a tunnel’s encapsulation would otherwise do — carrying enough context for every hop to make a consistent decision about a given flow — but as an addition to the existing packet rather than a wrapper around it, and it’s evaluated as routing/policy context rather than as an opaque payload the way tunnel-encapsulated traffic is to intermediate hops.

Tenants and services: the policy data model

SVR’s policy model is built from two named object types, and getting comfortable with the distinction is the fastest way to actually read a Session Smart configuration:

• Tenants represent a collection of network endpoints that share a common network enforcement policy — think of a tenant as answering “who is this traffic from, in policy terms.” A namespace owner defines tenants to group endpoints — users, devices, sites — that should be treated identically for access-control purposes.
• Services represent accessible destinations and the traffic treatment policy that applies to reaching them — answering “what is this traffic going to, and how should it be handled once we know that.” A service definition is where SLA requirements, path preference, and destination reachability get attached.

Every session gets classified against both dimensions on ingress, and the resulting tenant/service pairing is what the routing and policy engine actually acts on for the life of that session — not a five-tuple lookup repeated packet by packet, but a single classification decision, cached against the session, referenced cheaply from then on.

IETF standardization: this isn’t just internal Juniper plumbing

Secure Vector Routing has been documented in an IETF Internet-Draft (draft-menon-svr), which frames it as an overlay networking protocol that communicates end-to-end network requirements using application-layer cookies — explicitly designed to work through middleboxes and address translators without requiring non-overlapping address spaces between sites. That last point is a genuinely practical benefit: enterprises merging overlapping private address ranges (a frequent headache after M&A, or when connecting two organizations’ networks) don’t automatically need the same kind of NAT gymnastics a conventional Layer 3 overlay would require, because SVR’s session metadata — not raw source/destination IP matching — is doing the routing decision.

What this buys, compared to the tunnel-based world

Put next to the tunnel-based architectures covered elsewhere on this site, SVR’s session-and-metadata model changes where the “unit of policy” lives. On a tunnel-based platform, policy is typically attached to path/link selection — which tunnel does this traffic ride — with application awareness bolted on as a classification step ahead of that decision. On SVR, the tenant/service pairing is the policy object from the first packet onward, and path selection is one of the things that pairing determines rather than the thing everything else is subordinate to.

The trade is the same one every architectural choice on this site eventually surfaces: SVR’s approach removes tunnel-management overhead and per-packet encapsulation cost, at the cost of asking an operator to think natively in tenant/service terms rather than the more familiar tunnel/interface/route language most WAN engineers already carry from fifteen years of MPLS and IPsec. The next post in this series covers where that policy gets authored and distributed: the Session Smart Conductor and Mist, the two control-plane options sitting above the data plane this post just described.