Share this post:
Playing Lego has become an almost daily ritual to my 5-year-old son and I love playing with him. He always starts by emptying all the pieces from the storage box onto the playmat. I would plunge right in and start the familiar house or the roofless rectangular box. My son is the complete opposite, he would take a step back to take in the full view of all the pieces and give them a short ponder before he starts building. He would gradually but purposefully put the pieces together with a quiet determination. Sometimes, he goes real fast – one piece after another – but he definitely does not take the “everything-goes” approach. At times, he adds a piece, looks at it from different angles, and takes it off to replace it with another piece of a different color or a different shape. The only thing he absolutely forbids is me helping. I would tease him by swooping in at “high speed” with my piece onto his structure. He inevitably gives me an impatient grunt, “D-a-d!” and blocks me at my arm. Then he uses his back to prevent me from doing it again. It always makes me laugh but then I have no choice but to watch him continue his project on his own!
After he completes his handiwork, to the unknowing adult eyes, it may look like a big slab with a couple of mounds of different heights with some irregular interconnecting pieces. But then he would ardently explain to me what he has built. It can be a playground or even a whole castle for him and his friends! And it is very clear that he has given serious thoughts to every piece. He can describe where they snack, where they nap; the pit where he and his friends can roll and get dirty, and not to be missed, where the pee-pee room is! It is indeed a well-architected masterpiece! They don’t always look like the conventional playgrounds or castles in our mind but every piece, nook, and cranny has its function.
That’s how modern networking architectures need to be built. Not out of unrecognizable slabs, the sight should be set on building function-oriented systems.
Unlike data networking of yesteryear when services were deployed with much advanced planning, today’s networking is truly dynamic. Services and network provisioning in this cloud computing age needs to be set up, scaled up or down at a moment’s notice; they can be long-standing or short-lived without knowing beforehand. Network equipment must be able to satisfy such requirements no matter how challenging they may seem or business will be lost. To come up with the new generation of network devices, we cannot cling to the conventional network architectures. Instead, we must examine the problems that we are tackling and solve them with all available resources and technologies, old and new. That is the Deconstructed Router approach.
An important purpose of the Deconstructed Router is the ability to adapt to the more dynamic nature of data path setup in today’s networking. Josep Luis already discussed in his blog how only leaving the forwarding-plane functions on the networking hardware while implementing the distributed control-plane functions using cloud computes provides better scaling and performance without sacrificing compatibility to legacy and other network device implementations.
Another important goal of the Deconstructed Router is the ability to provide better abstractions to manage the data flows among the physical devices. Since the control-plane processor is external to the physical hardware, there are no constraints preventing having multiple control-plane processors to connect to a single physical hardware. Users can allocate different interface resources on the physical device to the different control-plane processors as long as each interface is only tied to one and only one control-plane processor. Each control-plane processor is only responsible for the interfaces assigned to it, and the overall forwarding-table of the physical device is the aggregated calculated data paths of all the connected control-plane processors. Since each interface resource can only be attached to a single control-plane processor, there will not be any conflicts among the data paths contributed by the different control-plane processors. With this design, carving out multiple Logical Network Elements from a physical device becomes trivial.
This Logical Network Element can even take on a different dimension. If a control-plane processor is assigned with different interface resources from different physical devices, the Logical Network Element now spans those multiple physical devices. This is even more useful in data-center environments. Servers can now be connected to any physical network device, and if a user spins up a number of VMs on the servers, it is then easy to assign the interfaces connecting to the VMs of the same function into the same Logical Network Element, even when the servers are connected to different physical Network Elements. Without the physical device boundaries, each Logical Network Element is managed as a single Network Element. This approach reduces the number of Network Elements operators having to manage, and increases the flexibility of how machines can be logically connected directly.
By deconstructing the router into the various functional components – management, control and forwarding-plane processors – and by utilizing white-box physical network-elements for the forwarding-plane, and the more scalable cloud-compute for the control-plane and management-plane, we gain the flexibility of being able to group interface resources from different physical network-elements to form a logical network-element that is operated by a single control-plane process.
By taking a step back first to examine the end-goals and all the available pieces to form the design allows the optimal architecture to be created. I can’t wait to play with my son and his Lego again tomorrow. Little one, what are we going to build?!