Part of:How digital twins benefit the networking industry
Use cases of digital twins for networks
Network engineers can use digital twins for design, testing, security and maintenance. But limitations with vendor specificity and a lack of standards hinder wider adoption for now.
The most evolved use case is manufacturing, in which the end goal is to validate the functionality of objects prior to investing the time, effort and expense of physically creating the objects. In this use case, a component manufacturer might create a digital twin of one of its components, like a bolt, and provide it to the system manufacturer, such as an engine maker. The engine maker can add the virtual bolt to a virtual engine and test whether it meets the specs and has optimal performance.
This is great, but what's the relevance for network engineers and folks involved in network management and automation? Quite a lot, as it turns out.
Creating and monitoring network digital twins can assist at all stages of network support, from design to end of life. Here's a look at how and where network teams can apply digital twins to the networks they design and manage -- and what some of the speed bumps and roadblocks are.
Twins vs. models
First, it's important to differentiate between digital twins and simple models or simulations. The main difference with digital twins is they incorporate some degree of real-time data updates. So, while a model or simulation operates exclusively based on its initial conditions, a digital twin can incorporate real-time data from its real-world counterpart.
Types of digital twins
Digital twins don't have a standardized set of categories. But many vendors and others active in the industry define four core types of digital twins.
1. Component twins
Component twins are instantiations of individual components, such as the bolt in the example above. These twins include detailed information about the performance and behavior of the components. In a network environment, components might be individual motherboards or power supplies.
2. Asset twins
Asset twins are instantiations of physical assets, such as buildings, trucks or other vehicles or machines. These twins include operational status, performance data and environmental conditions. In a network environment, asset twins might be routers or switches.
3. System twins
System twins comprise groups of asset twins that work together at a system level. As the name implies, system twins are used to uncover how components and assets work together. In a network environment, system twins include networks such as WANs, LANs or other network segments.
4. Process twins
Process twins bring together system twins into complex processes or workflows. Process twins enable engineers to conduct what-if scenarios by tweaking inputs to see how they affect outputs. In a network environment, process twins cover routing protocols and the overall performance of the network.
Use cases for digital twins in the network
With these types in mind, it's easy to see how digital twins can work across the lifecycle of a network, from architecture and design through end of life.
Network architecture and design
One clear digital twin use case is in network architecture and design, whether in creating a greenfield network or making changes to an existing network. A key advantage to using digital twins at this stage is they enable engineers to optimize across different criteria -- e.g., "build the lowest-cost network that is resilient to my requirements."
Maintenance and configuration
Teams can use digital twin technology to address the effect of upgrades and configuration changes. By building a workflow step that includes testing with the twin, teams can minimize or eliminate errors caused by misconfiguration.
Use cases for network digital twins include security, maintenance and automation.
With a bit of creativity, network engineers can also security-harden their networks. Running penetration tests against the digital network and testing configuration changes for security are some clear use cases.
Traffic modeling and capacity planning
Many times, enterprise technologists want to know things like, "What is the network effect of rolling out application X?" or "How will moving to cloud provider Y affect my network traffic?" For example, a few years ago, many teams were concerned with the network effect of moving from on-premises email and video conferencing to cloud-based Microsoft 365. Network twinning provides a straightforward way to answer these questions before going live with applications. Another example is moving from technology like MPLS to software-defined WAN.
Equipment replacement and network end of life
Networks are constantly evolving, and ideally, teams phase out network devices and replace them with higher-performance devices. With digital twinning, network engineers can model the effect of phasing out certain devices or collapsing functionality from several devices into a single, higher-performance device.
Digital twins can revolutionize how network engineers manage their networks across the full lifecycle from design to end of life, including automation and security.
Limitations of network digital twinning
Given all these benefits, it's natural to wonder why more network engineers haven't deployed digital twinning technology. There are three main reasons.
1. Vendor specificity
Most major vendors -- such as Cisco, Extreme Networks, HPE, Juniper and others -- have digital twins of their own products. But they don't interoperate with one another. Nemertes' research indicated that only about a third of networks are single-vendor, so single-vendor digital twinning doesn't work for a majority of networks.
2. Lack of standards
There are currently a limited set of standards for conveying information across digital twins, regardless of type. One organization that's working on standardization is the Digital Twin Consortium. But it's noteworthy that none of its members include major network providers.
3. Lack of test labs
Even if standards and interoperability across vendor environments existed, one burning question remains: Where can network engineers build and maintain their digital twins? Given that these tools require a fair amount of computing horsepower, it's a nontrivial question. Although cloud vendors, like AWS, are building out digital twin laboratories, none at present are specifically designed for network devices and tools.
So, what's the bottom line? Digital twins can revolutionize how network engineers manage their networks across the full lifecycle from design to end of life, including automation and security. However, the current tools are limited due to lack of interoperability and lack of a centralized cloud environment. That said, network engineers would do well to plan to use network digital twins wherever they exist and plan for more comprehensive use as the technology evolves.
