Richard Brandon, VP of Marketing at RtBrick

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.

Tell us about your network architecture, what are the main features?

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.

What are the benefits of the Broadband Network Gateway?

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.

Tell us about the switch from traditional broadband networking to Cloud Networks.

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.

Can you see telcos releasing services and software similar to Facebook, Google and Netflix in the future?

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.

With telcos required to give legal accessibility, might this be a privacy concern for people using such software or would each have their own privacy policy?

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.

Tell us more about the modularity of the system. Would the modules interact seamlessly from one protocol to another, and how can that help telecom companies?

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’.

Can a telco switch to cloud 100%? Are there any drawbacks or pain points in doing so?

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.

What are some service potentials that telcos can tap into with this technology?

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.

The software comes with ‘single-pane-of-glass’ Web2.0 Management System, including a zero-touch-provisioning system.  Can you tell us about the advantages of these systems?

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).

What does it mean for telcos to be able to operate on web-scale?

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.

What are the implications of using merchant-silicon hardware?

Taking advantage of merchant silicon in bare-metal switches, and disaggregating the hardware from the software, brings some huge benefits to carriers:

• Lower cost hardware – per port costs are a fraction of traditional vendors’ systems
• You can swap and change software without throwing away or even upgrading the hardware
• You break the hardwiring between platforms and services, enabling easier re-use of common hardware across any service

Can you tell us about the IoT implications of this merging of hardware and software?

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.

What else could be achieved with the scalability and agility of the systems?

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.

So far, how are your initial trials going with mobile operators? What are the main challenges you are facing, and how do you plan to overcome them?

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.

What are some of the benefits of moving towards a more cloud-native business?

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.

What is the significance of being validated on several bare-metal switch platforms?

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.

What are some of the biggest obstacles you are currently facing regarding deployment?

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.

Are there any risks that operators might face when implementing the Broadband Network Gateway?

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.

How fast can operators deploy your solution, and how fast can they expect to see actual results?

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.

What plans are on the horizon for RtBrick?

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.