We’re starting a new series on Border Gateway Protocol (BGP), the routing protocol of the Internet. When it comes to BGP, service providers live and die by it. However, there are some divergents who don’t like BGP and decided against it in their core networks. We are going to cover these divergents. Keep in mind, we are not experts in BGP or networking, but Cato Networks is a different story.

The founders of Cato Networks are nothing short of legends in the world of security and cloud networking. Shlomo Kramer co-founded the pure-play security companies Check Point Software and Imperva and took them public. Gur Shatz founded Incapsula (now an Imperva company) which combined a cloud-based CDN with built in web security. Thereafter, Shlomo and Gur started Cato Networks. Cato Networks is the one of the most innovative networking and security companies in the world, merging three business models together: CDN, Cloud Security and SD-WAN.

Here are some thoughts on the why Cato Networks decided against BGP for its cloud service. A big thanks to Gur Shatz, CTO of Cato Networks.

BGP is the cornerstone of Internet routing, why did you decide against using it in your platform?

First, we did not throw out BGP completely. To work in the Internet today you must have communication between providers, and there is no alternative to BGP. It is the communication method of the internet and can’t be replaced wholesale (although we did discuss publicly its many weaknesses and misuse). BGP is still capable of binding together a very loosely coupled internet.

What we chose not to do, was to implement our backbone on top of BGP, or more advanced alternatives like MPLS and its extensions, or any other router-centric protocols. These protocols are commonly tied to proprietary router appliances. We rejected the router appliances themselves: we don’t believe they are suitable to build a modern, global network.

Routers, and the protocols they implement, have no notion of orchestration on the control plane, very limited processing capabilities on the data plane, and most important – are glacially slow to evolve. You can’t build a software-defined agile network on top of that technology.

This isn’t new or groundbreaking. This is why SDN emerged in the data center and SD-WAN at the edge: once you go software defined, a whole new set of capabilities become possible, even beyond path selection and congestion management: from application aware routing, to protocol optimizations. Once you go software defined, you can actually make these features simple to deploy.

So, how did you approach routing in your cloud network?

Our backbone design included no off the shelf communication equipment at the routing layer. We developed our own routing software, which allowed us to implement routing over a global control plane, as well as implement our custom logic at the data plane. Unfortunately we found we couldn’t use any of the available SDN tools as they were focused on datacenter connectivity not global Internet connectivity.

What we needed, required using multiple global providers as the edges in our network graph, deciding in real time the best route based on utilization, latency, packet loss, jitter, and application. The fact that we have a software implementation of the data plane allowed us to perform things like protocol optimization and FEC (forward error correction).

Since we operate our own global network we can expand the network footprint while continuing to deploy new versions as our software (and protocols) evolve. It is currently comprised of 34 PoPs in all regions of the world, interconnected by multiple IP transit providers. The PoPs are full-meshed into a global overlay, and continuously measure the behavior of each route in the mesh. All PoPs share context so each PoP knows the best route to reach any other PoP based on actual underlying network behavior. The network can grow seamlessly by deploying our software stack on any hosted physical, virtual or cloud-based servers. This also allows us to overlay our customers’ network as virtual instances on top of our physical infrastructure.

To conclude, this BGP discussion is not about the phasing out of a dated protocol but really about the architecture of the global network of the future. We are leveraging software-defined networking delivered and evolved as a cloud service, powered by commodity servers enhanced for high speed packet processing and affordable IP transit to offer an alternative to legacy appliance-based networks built on top of dedicated capacity.