At a high level, a session is “a temporary connection between two endpoints for the purposes of communicating information.”
But ask five people what that means, and you’ll get five different answers. HTTP sessions, SIP sessions, virtual circuits, and more – the notion of a session exists up and down the network stack.
Regardless of protocol, though, all sessions DO have some common characteristics – they all require some sort of signal to be established (and in most cases, ended), there is a two-way exchange of information, and each session is singularly unique.
At 128 Technology, when we refer to “sessions” we’re primarily talking about connections that occur at the Transport and Internet layers – Layers 3 and 4 in the OSI stack.
These types of sessions can have distinct characteristics that make them interesting:
- First, they have fixed addresses for the source and destination endpoints – at Layer 4, throw in the protocol and you have yourself a 5-tuple
- Second, they can have “biflow” – comprised of two related unidirectional flows in opposite directions/vectors. For more on the difference between sessions and flows, check out this blog
- Third, sessions have directionality, reflecting which endpoint initiated the exchange
- Finally, sessions have state – they have a recognizable start and end , along with any number of other parameters specific to that session
These characteristics make it possible to associate packets and flows with a unique session, and manage that session.
To be sure, session awareness is not a brand-new concept. Nearly all of the advanced service functions available today – including firewalls and load balancers – require an understanding of, and control over sessions.
So why don’t routers have session awareness? The answer is part technological and part religious (as if there is a difference).
Until recently, specialized hardware was the only game in town for router data planes, and the focus was on forwarding as many packets as possible, as fast as possible. Plus, the practical limitations of hardware product cycles and custom chip design made it far more onerous (and distracting) to incorporate advanced network functions into routers. It was just easier to build standalone network appliances and put them around/behind/in front of the router.
Holding state in the network was/is somewhat controversial, and for good reason. The very notion of a high-speed, best-effort network relied on routers to “forward and forget” packets. Also, why hold state in the router, when you can do it at the host – or in a new shiny middlebox?
Boy, have things changed. General purpose compute platforms (i.e. x86) can now handle all but the most demanding packet forwarding tasks, with cycles available for advanced functions. This means routing functionality can be created in software, and be put anywhere you can put an x86 chip.
Software-based packet forwarding means that you can incorporate advanced network functionality into the act of routing itself, like firewalling and load balancing. In fact, you can change how session state is maintained (how much and how long) and where it’s maintained, in a way that makes more sense for the network.
As a result, you can now re-think routing with a session orientation, and innovate new ways to provide network services. You can eliminate overlays, but still enforce path selection and segmentation. You can offer zero trust security and adaptive encryption. You can more tightly align applications with the underlying network capabilities. You can manage many simultaneous sessions dynamically and intelligently end-to-end. In short, you can create a network that is fundamentally simpler, smarter, more secure, and more transparent.
For us at 128 Technology, session-orientation is one of the key enablers for what we’re calling Secure Vector Routing. In the coming weeks and months, we’ll continue to share more info on how Secure Vector Routing works, and many of the other principles driving this adventure.