This article was published in The Mobile Network on May 7, 2020. You can read the original article here
As the industry hurtles, or crawls (ymmv), towards a disaggregated, software-controlled and automated network, one aspect crawls (or hurtles) along with it: the ability to manage such a thing.
When you disaggregate parts of a network – an access or core router, say – you split the hardware from the software, and the control from the user plane. And your aim is then to be able to exploit that by building on much cheaper hardware platforms, or placing the software in the cloud so it can flex as required. And so on.
So take the new generation of router software providers. It could be DriveNets or Volta Networks or, a company we will focus on now, RtBrick.
All of them do slightly different things, but in the words of RtBrick’s VP Marketing, Richard Brandon, they form “a sort of a batch of new players that are looking to do routing software that runs on bare metal switches. There’s a handful of us really around the world.”
The designed-in benefit of this approach is that telcos can get a new way to manage the functions and services within their networks. But it’s no good if they replace their vertical network OS with another batch of management systems. They require the ability to manage these disaggregated instances in a coherent and automated way.
RtBrick focuses on the network access edge where routing functions like the BNG (Broadband Network Gateway) resides. In the mobile network that might also be a router in the backhaul domain.
Its cloud-native architecture means that RtBrick holds a single database in the system, containing things like routing forwarding tables, through to the temperature of the CPUs on the switch.
“Traditionally, these databases were employed so that there was a different database for each function. And that was a bit of a chip and silicon limitation. You’d end up optimising your databases so that you are not using more of your processing capacity, and you end up with literally hundreds of different databases in each router. Junos (Juniper’s OS) has nearly 2000 databases, for example.
“So when we started that was one of the fundamentally different things we did. And it makes it much simpler to interface with this device because you can do that from one place with everything in it. So when it comes to things like automation and management of operations, it’s a lot easier to do.”
The second area where the new players differentiate is that they have a more of a modular code base. So a daemon that runs a routing protocol like BGP or a management daemon are very distinct. That means they can be tested, loaded and upgraded individually.
“That’s pretty good from a kind of testing and robustness perspective. And it makes it agile for us to develop new features within the codebase.”
A third differentiator, Brandon says, is “being more cloud native like in our approach.”
“Every feature is running on Linux in a container, everything’s got open interfaces. You know you can even create your own shell if you want to because we’ve published everything. So it feels like culturally much more like a cloud software solution than a traditional networking OS.”
“I think, for me, this is one of the biggest shifts – it’s the first big shift since the first chassis based router came out of Cisco in the 90s. I’ve been in internet networking for a long time. And actually, you know, with Juniper and Cisco they were always building the next biggest and fastest chassis on the next generation of silicon. And really not much has changed: it’s still, you know, a chassis with a backplane and line cards and network cards.
“A lot of the drivers for disaggregation in the first place were that telcos saw that they could build the equivalent of a single system with multiple vendors products from the hardware and software side. So there are now individual bare metal switches which are doing the job of line cards, and individual bare metal switches that do the job of fabric cards, and others that are doing the job of kind of network facing cards, and there’s no need to buy those from the same company. So it’s a bit like saying I’ll take my backplane from Juniper or my line cards from Cisco and my network cards from Huawei please. And actually the software is split up as well.”
That level of disaggregation means that the management of the different instances needs to be coherent, and automated.
“For instance, you’re taking your bare metal switches and putting them in a rack. You want them to learn about their topology, draw down the right software image and turn themselves into a point of presence (PoP). The ones that are facing the customers will want a different software image, an access protocol, from the ones that are facing the core of the network that might want BGP. The process of getting all that to happen without any human intervention would be one of the things that we’ve done, alongside our actual code.”
It is this management process has now been picked up by DT and EWETel who have formed an initiative known as Leitstand. Leitstand calls its mission, “Carrier Operations at Webscale, Freely Available”, and it aims to use the open source model to develop something that telcos can use to operate the underlying infrastructure in a network built from disaggregated software and hardware systems.
The decision to make that an open initiative is something the telcos were particularly keen on, Brandon says. “In general, of course it’s kind of in the interest of an operator to have multi vendor supply, and then this is extending that logic to the operating systems and the management systems. So a network operator doesn’t don’t feel like it should have to go to RtBrick or anybody else for that management system. It wants to have a choice.”
Brandon acknowledges there are a lot of open network management initiatives, but argues that there is nothing as yet that points at the emerging underlying, disaggregated infrastructure.
Brandon: “We are going into a new world with new problems that aren’t really being solved in a traditional fashion. There wasn’t anything that was out there that was off-the-shelf to provision and manage and fault-find these disaggregated networks. So we were encouraged to contribute what we were doing to make it open source, which I think makes a lot of sense. We’re not a network management company, we’ll never make our profits from network management, so we’d rather contribute that to the general community and have people contribute their bits as well so we’re not all reinventing the wheel.”
And as it goes forward, Leitstand might end up joining other initiatives. “Like lots of theses sorts of open source initiatives it might end up being wrapped under a bigger parent at some point, you know, that’s quite commonly how things can evolve,” Brandon says.