There’s More Than One Way to Build a Service Provider Network

The other night, we started a new book. We have a bedtime ritual where each one reads three pages to me. It’s good practice for their reading, and I love seeing them enjoy books. This time it was Yotam’s turn to start reading, and he wanted to start from the end. I explained that books are meant to be read from the beginning, as the author intended. After a short argument between Uri and Yotam, I decided to let Yotam read his way, thinking there was no reason to argue and that once we started, he’d see the logic in reading a book from the beginning.

So, we started from the back… and it was fantastic! After five pages, even Uri was into it. We gradually pieced together the story, and the lead-up to the ending/beginning was a great and surprising experience.

This reminded me that there are multiple ways to do things and that we should not go on autopilot every time. We should embrace different methods and approaches. At work, I’ve seen service providers (SPs) build networks differently yet achieve excellent results. As a vendor, we should recognize that there are many paths to success, yet the goal remains the same: to achieve more flexible and open network designs. Yotam, like many of our SPs, taught me this lesson once again.

Why service provider’s need to build networks differently

Today the Internet is a basic requirement for billions of users around the world, and SPs have been operating this crucial resource while watching others monetize it. The legacy hardware-centric models cripple their agility and cost a fortune to operate. Meanwhile, hyperscalers and over-the-top (OTT) media SPs are capitalizing on these very networks, offering innovative services without the operational toll that SPs have to struggle with.

That’s why it’s no surprise that SPs are seeking new ways to reinvent their networks and push toward more open, software-centric models with disaggregation at its core. Separating hardware from software breaks the vendor lock, simplifies operations, and accelerates innovation.

Open networks, open choices

Large networks with multiple domains traditionally relied on service-specific hardware for each network domain. This led to operational chaos: too many service-specific boxes requiring unique skills, teams, and a massive spare parts inventory.

Disaggregated solutions have changed this paradigm. Now, SPs recognize the benefits of using unified open hardware and software from the core to the edge.

DriveNets Network Cloud allows SPs to build their networks like cloud. This means separating hardware from software and allowing SPs to create any network use case with open white boxes. By adopting open white boxes, SPs gain several benefits:

• Unified hardware ecosystem: Using the same white boxes across all network domains allows for elasticity, easy hardware reuse, and simpler maintenance.

• Flexible network architecture: Build your network using any network architecture with large clusters, small clusters, or standalone units.

• Removed vendor lock: Mix and match any ODM, ASIC, optic, and even software component to get your best-of-breed solution drawing from a diverse supplier base.

When looking at these three key advantages, flexible network architecture presents the main challenge. Should SPs choose small network elements (standalone white boxes) or large clusters?

DriveNets Flexible network architectures

To answer this, we need to understand the value offered by each option:

• Large-scale clusters: Offer practically unlimited capacity (up to 819T) and extensive port fanout with built-in carrier-grade redundancy.

• Standalone white boxes: Provide complete control over the network and further simplify hardware maintenance and operations.

Ultimately, the SP’s decision depends on the specific requirements of the network domain. If the use case demands carrier-grade redundancy, high capacity, or a port fanout greater than what a standalone white box can offer, then large clusters are the preferable choice. Otherwise, standalone white boxes can be an ideal solution.

The white boxes, whether used within clusters or as standalone units, also offer SPs improved operations. This is thanks to their smaller footprint (2 rack units), lower power consumption, and easier troubleshooting due to a unified hardware setup and a reduced number of SKUs.

Same networking goal, many paths

Are SPs limited to just two options? Absolutely not! There are more options available. We have observed an SP strategy where network complexity is transferred from the routers to the network itself. This involves employing smaller routing elements across all network domains and implementing advanced routing techniques. While requiring a highly skilled team, this approach grants SPs access to nearly all the key benefits of both of the above options – capacity, port fanout, simplified hardware maintenance, and redundancy – without the need to use any clusters.

As Yotam has taught me, and as DriveNets has learned from its SPs, there is more than one way to do things. The goal is what’s important. For SPs, that means building a more flexible, open network to cut costs and improve service delivery.