Wednesday, September 28, 2022
Published 2 Years Ago on Friday, Apr 10 2020 By Inside Telecom Staff
RtBrick has recently announced the availability of its Broadband Network Gateway (BNG) software. RtBrick’s BNG is the first use-case for its FullStack routing software, which runs on merchant-silicon hardware, transforming it into carrier IP/MPLS infrastructure.
Mr. Richard Brandon, VP of Marketing at RtBrick talks us through their new software for disaggregated networks.
Unlike traditional network equipment, our architecture uses a ‘disaggregated’ system, which in simple terms means, our network software is independent from its underlying hardware. For many years the only way to deliver the levels of throughput required by the Internet was to build monolithic routing systems using custom silicon and optimize the software around it. But our architecture uses a ‘cloud-native’ approach, with software running on off-the-shelf low-cost hardware.
Because our BNG (Broadband Network Gateway) can run on off-the-shelf hardware, per port costs are a fraction of those of traditional systems. A choice of software suppliers will make it faster for operators to deliver new features and services. And open standards and Web2.0 tools make the whole system easier to automate and to operate at larger scale without increasing staff.
Any hardware changes?
The shift toward a cloud-native approach is probably the biggest change we’ve seen in carrier networks since the arrival of the Internet. In terms of the hardware, this is due to adoption of merchant silicon. Silicon vendors now have the equivalent capabilities on their high-volume, low-cost networking chips that the traditional system vendors use on the line cards in their systems.
This merchant silicon is being used to build a new category of powerful low-cost ‘bare-metal’ switches, often constructed on the same outsourced assembly lines that manufacture the traditional vendors’ router systems.
Do customers need to shift anything in their usage of services?
For end-users, the change in service infrastructure should be transparent – other than new services that are developed faster and cost less.
And how can companies make the switch seamless?
There are many benefits of a cloud-native approach, but they will require the adoption of new skills and Web 2.0 tools. Most of the carriers we speak to are already committed to this journey.
Telcos will have the flexibility to deliver whatever services they like, whether that’s video or cloud services, but the biggest similarities between the telcos and the cloud-natives will be the way they deliver them. For example, they can drop a new service onto their platforms with relative ease – like adding Facebook Chat for 2 billion existing users. These are things that have seemed unattainable in the telco space – until now, that is. The telcos have seen how the giant ‘cloud-natives’ have found new ways to operate their businesses and now they can emulate them.
We need to distinguish between ‘the cloud’ and a ‘cloud-native’ approach. The cloud implies shared resources, which can have privacy challenges. A ‘cloud-native’ approach can still use dedicated infrastructure for a single operator, which in turn provides services for many private subscribers. There are also essential legal requirements that need to be provided across their subscriber services, such as providing Lawful Intercept for intelligence agencies.
We’ve taken an approach to our software that is native to cloud IT environments, with each use-case getting its own unique code-version, built from discrete blocks and delivered as a software container running on a Linux operating system. The code isn’t bloated with features that aren’t needed. This also allows us to upgrade or add each feature independently, in sub-milliseconds, with no service disruption. And you can test individual microservices in isolation, rather than having to test the whole system as a ‘black box’.
A greenfield telco could certainly apply a cloud-native approach to its entire operation, but in practice, most operators have to consider their legacy service portfolio. The nature of the legacy systems is that they ended up having to support a superset of all possible features, even though many are rarely, or never, used by each carrier. This makes them expensive to build and operate. We’d suggest this switch as an opportunity to rationalize legacy portfolios and focus the benefits of the cloud approach on the services which generate the bulk of the traffic.
The vast majority of traffic – and cost – in most telco networks is driven from large volumes of high-speed but relatively simple services. For many carriers, the place to start is their consumer broadband services, which generate the bulk of the traffic, but the same approach can be applied to their enterprise and wholesale service portfolios.
They eliminate human error through automation, reduce operating costs and save you re-inventing the wheel – as many powerful tools have already been developed. Simply power-on your bare metal switches and they will self-register, download the correct software image, discover their topology and all microservices self-start. You can glue this into your existing OSS using REST and RPC interfaces, such as gNMI (Google Network Management Interface).
Rather than try to build an unattainable flawless system, a web-scale approach focuses on self-healing systems. Our composable code and single state database makes it easier to contain risk. For example, we can isolate different routing universes (such as public and enterprise networks), watchdogs can detect issues and redeploy software if needed, and it’s inherently simpler to control.
Taking advantage of merchant silicon in bare-metal switches, and disaggregating the hardware from the software, brings some huge benefits to carriers:
The explosion of IoT devices means even more traffic generated and even more distributed networks. For a telco, this means more cost. It seems unlikely telcos will be able to match this with an equivalent increase in revenue, so they must find a way to deliver more broadband capacity at a lower unit cost. Disaggregating the software and hardware will cut their network costs by at least half.
Network disaggregation has only been possible because of the advances in performance of standard merchant silicon, which will increase even more over time. In addition, the same architectures that scale-out the huge cloud-native data centers can also be applied to telco Central Offices, with spine and leaf switching architectures scaling to support huge numbers of subscribers.
Our initial trials are with fixed broadband operators, including some of the largest in the world. This bring challenges of scale, rich service feature sets and robustness. But RtbRick is staffed with some of the world’s best telco engineering experience, and we’re reusing established and hardened telco protocols where it makes sense, like BGP and MPLS routing.
There are two main advantages: Cost, both purchase cost and operations, and service agility. It is much faster to deploy and test new services and infrastructure than has ever been possible before.
It gives the customer a new degree of choice, which helps drive down costs even further. They can reuse their hardware across any service, rather than deploy one platform for each service. And they can mix and match the best hardware platform for their use-case with the best software on the market, rather than having to compromise between the two.
Probably our biggest obstacle is our own ability to cope with the level of activity and interest in the market. We’re already working on some huge projects and we have to prioritize new features accordingly.
It’s important not to simply replicate everything that exists in the existing network and service feature set. Trying to build a ‘superset’ of all features on day-one will be self-defeating. We’d suggest solving ninety per cent of the problem with a cloud-native approach and leaving the niche 10% of services running on existing platforms.
No major telco will do this without a thorough trial, testing and implementation plan. That’s going to take more than a year from start to finish, which is why it’s important to start now. Cost savings are immediate from day-one of going live.
We have plenty to keep us busy in fixing the access network, which is where we see the major pain point in telco networks today. But we have lots of ideas about how we could apply our technology on other areas of the network in the near future.
Google Workspace vs Microsoft 365, which one is better for you? Many firms, especially startups, have a challenging time deciding. Consider this blog post a quick overview of what to expect from each. We will go through each product’s advantages and disadvantages as well as when and why you might prefer using one over the […]
Stay tuned with our weekly newsletter on all telecom and tech related news.
© Copyright 2022, All Rights Reserved