The Iron Triangle of scope, cost, and schedule is rarely more evident than when undertaking a new network design project. Business requirements, technical requirements, budget limitations, and staffing constraints all weigh into a series of compromises that all have a material impact on the finished product. Virtually every network on the planet — from the smallest LAN to the most expansive WAN deployments — are based upon a fairly Spartan blueprint. What I call the “Lowest Common Denominator” network: the physical connections, switches, and routers. These also happen to be the lowest layers (1, 2, and 3) of the venerable OSI model, collectively referred to as the “media layer.”
The media layer — along with the routing protocols that run over it — provides ubiquitous, end-to-end connectivity among all of the devices that connect to it. But there may be more devices than you initially anticipated. Consider this: Now that the entire enterprise can reach that web server you’ve stood up, will it scale? No — better put a load balancer in there to spread the traffic among multiple servers. Next, does the ubiquitous reachability on your network meet your corporate security requirements? No — you’d better sprinkle firewalls liberally around the perimeter of the network to keep the bad guys out. Now that you’ve put load balancers and firewalls into the network, you may consider deploying network probes at key locations to make sure you have visibility into where and how traffic is flowing. This is what we call the “middlebox mindset” — building a solid media layer foundation, then customizing it with bolt-on middleware products to suit.
The argument for perpetuating the “middlebox mindset” usually includes phrases such as — “we can choose best of breed” and “we have unique business needs;” but vendor selection, training, and system integration of these middleboxes has a material impact on the scope, cost, and schedule of your project. Furthermore, “middleboxes come with high infrastructure and management costs, which result from their complex and specialized processing, variations in management tools across devices and vendors, and the need to consider policy interactions between these appliance and other network infrastructure.” (Source). In the end, the “middlebox mindset” results in the deployment of a snowflake — a network that is unique among all other networks on the planet.
The 128T Networking Platform — a next generation router — was designed to obviate the need for many common middlebox functions. This is in large part due to its session-oriented, state-based architecture, which enables intelligent session distribution algorithms that packet-oriented forwarding planes cannot. (State enables middleboxes to load balance effectively, act as security appliances at network edges, and the like.) By incorporating state into the routing elements, there are fewer devices to manage, fewer policy interactions to be concerned with, and a clear path toward recouping some of the elusive scope, cost, and schedule in your project plan.
There will always be a place for middleboxes in IP networks; today’s network vendors can never predict tomorrow’s networking requirements with 100% certainty. But at 128 Technology, we believe a software-based, session-stateful routing plane represents the new foundation upon which scalable, flexible, and service-oriented networks will be built.