Implementing Intent-Based Networking Without Lock-In, Part 1

The basics of intent-based networking and service automation—and why open source is the best way to implement them.

Part one of a two-part blog series.


In our Five Overlooked Factors of 5G eBook, we offered an overview of intent-based networking—basically, the ability to tell the network what you want it to accomplish without having to spell out every step it needs to take to accomplish it. If you’re working in a CSP network organization though, you may have some skepticism about how, exactly, you’re supposed to get there from where you are now.

In this two-part blog series, I’ll take a closer look at intent-based networking and the ways Lumina Networks is helping CSPs implement it—without locking themselves into closed, proprietary ecosystems. For Part 1, let’s review what intent-based networking looks like, why you want to do it, and why you should implement it using an open source approach. In Part 2, we’ll explore some of the technical details of how Lumina is helping CSPs make it happen.


Understanding Intent

Traditional network operations aim to achieve a result by providing explicit instructions to the network for each step of “how” that result will be achieved. For example, if the objective is to enable broadband connectivity to User X based on Subscription Plan Y, those steps could include:

  • Provision authentication/authorization server with user credentials
  • Provision DSLAM/BRAS with user identification parameters
  • Set up broadband transport network to establish tunnels for user and tie it into BRAS
  • Set up usage limits/billing
  • Set up closed-loop policies to restrict bandwidth post-FUP

Together, those steps create a workflow. Today, network operators build these workflows manually (and slowly, and often painfully). All that manual effort leads to plenty of human errors, as well as long lead times to onboard a new service instance. This is, in fact, the problem that SDN aims to solve: eliminating manual steps by automating the network through programmable interfaces.

“Intent-based networking” refers to a specific kind of programmable automation. Here, you define the high-level user intent using abstract and neutral data models, and have an SDN controller (or any network abstraction platform) automatically translate that “what” into a series of “how” workflows that network devices can understand and implement.


Why Intent Is So Important

Why go to the trouble of implementing intent-based networking? First, just to drive down human error and onboard service instances more quickly. Intent-based networking should move network operations from “high touch” to “zero touch” (or close to it), and service provisioning times from days or hours down to seconds. It should also enable self-provisioning models, where customers can define, purchase, and activate new services on their own—further reducing operating costs and time-to-revenue. From a broader business perspective, intent-based networking also makes the network itself more agile and adaptable to dynamic needs, providing more predictable operations and a more reliable network.

All of this sounds great to CSPs, but where intent-based networking becomes essential is when moving to 5G. 5G networks are defined and built to support a diverse set of industries with a wide array of use cases. They also bring together many different technologies (SDN, NFV, cloud-native computing, IoT, network slicing, traffic-engineering, QoS, and more), leading to a manifold growth in the complexity of the network. Many 5G use cases also place additional importance on edge computing, requiring network resources to move closer to applications to reduce latency and optimize bandwidth utilization.

All of this requires a lot of dynamism in carving out network resources for various applications, further ramping up complexity. Automation is the key to managing this complexity, and intent-based automation offers an ideal solution.


Implementing Vendor-Neutral Intent-Based Networking

Once CSPs decide to implement intent-based networking, they have a choice: they can buy into a network device OEM’s or independent software vendor’s (ISV) proprietary automation framework, locking themselves into that vendor’s approach. Or, they can implement intent-based networking using vendor-agnostic, centralized network control. At Lumina, our core mission is to help CSPs break free from vendor lock-in by successfully implementing open standards and open-source, so you can probably guess where we fall on this question.

Note that, while the industry has come a long way in acknowledging the downsides of proprietary vendor lock-in (such sacrificing your ability to rapidly innovate your network to keep up with customer demands), ISV solutions don’t really solve the problem either. By using standard interfaces and abstracting network elements using a common data model, ISVs can offer intent-based automation products that are indeed “vendor-neutral,” reducing the dependency on device vendors for management operations.  But CSPs are still locked in—just now to the ISV instead of the device vendor. An outside party still dictates the timeline (and price) for any updates, feature additions, product roadmaps, etc.

For all these reasons, forward-looking CSPs now insist on using open standards and open-source as the foundation for intent-based networking. That’s where companies like Lumina come in.

In Part 2 of this blog series, I’ll detail how we make intent-based networking possible with an entirely open source, vendor-neutral framework. Stay tuned!

Additional Resources: