Home Networking service Transformation of the transport network: an essential part of the CSP to DSP journey | VanillaMore

Transformation of the transport network: an essential part of the CSP to DSP journey | VanillaMore

0

Communications Service Providers (CSPs) are transforming into Digital Service Providers (DSPs). By a recent Optical report, 51% of CSPs believe their digital transformation is “well advanced” across their business, up from just 39% last year. In contrast, 47% said their digital transformation was only advanced in a few areas or at an early stage (Omdia 2022, n=67), says Tim Doiron, vice president of solutions marketing at Infinera.

No matter where a CSP is in their digital journey, you can’t transform the business without transforming the network. As all services require transport, there is no digital transformation without network transformation.

To understand how to transform the network, let’s look at why CSPs are transforming to begin with. What do they hope to achieve and what is driving their digital transformation? As shown in Figure 2, the key drivers of digital transformation are shortening time to market for products and services, improving competitive advantage through business agility, and improving customer experience and relationships. All three relate to transforming and improving the customer experience, with faster service delivery for existing services and increased agility to scale them as needed. While any transformation involves savings on operational/capital expenditures, these are secondary drivers.

If network transformation is critical to the success of CSP digital transformation, how do you get there and what roles do open source software and machine learning (ML) play?

Programmability via abstraction and open interfaces

To make the physical transportation network work more like computing and cloud infrastructure, we first need to abstract from the physical network. The abstraction involves creating a data model that represents the attributes of physical network elements, such as Infinera’s CHM6 coherent DWDM transponder module supporting 1.6 Tbps of optical transmission capacity over two data lengths. 800G wave. While other modeling tools exist, YANG-based data models are the preferred methodology today. To promote interoperability and minimize vendor differences, most optical network vendors are moving away from vendor-specific data models and adopting common models, as defined in conjunction with organizations such as OpenConfig, Open ROADM MSAand the IETF.

Once we have a common data model, management, control, and orchestration software must be able to communicate to/from the underlying transport network for configuration, lifecycle management, and data mining. data. Modern optical transport products like Infinera’s GX series support the NETCONF and RESTCONF APIs modeled by YANG for this purpose. CSPs also need an efficient and dynamic way to collect network infrastructure performance data at intervals of 15 minutes to milliseconds. Modern optical networking software supports gNMI/gRPC-based streaming telemetry. Streaming telemetry is a push-based approach that overcomes the challenges of legacy polling mechanisms. Leading streaming adaptive telemetry implementations use the state of the network to dynamically adjust the type of data to stream, its granularity, and the frequency of transmission, targeting the data most relevant to the current state of the network.

Direct or indirect?

By supporting common data models and APIs directly on the network infrastructure, optical providers provide maximum flexibility for various operational environments. While Internet Content Providers typically interface directly to optical infrastructure, it is less common for CSPs to do so. CSPs more frequently use a hierarchical framework where a transport controller like Infinera’s Transcend Controller interfaces directly with network hardware, transponders, and DWDM line systems while providing a northbound interface or API to higher-level commercial orchestration or support software. The Transport API/TAPI interface as defined by ONF is increasingly supported by optical network controller vendors, including Infinera. As networks have additional layers beyond optics, such as IP/routing, additional controllers are typically deployed for each domain. A multi-layered orchestrator brings together the technology layers for supporting operations or business systems of the CSP.

Open source for all?

How does open source software fit into network transformation? While legacy network infrastructure was closed and highly proprietary, today’s disaggregated and open optical network equipment is open, modular, and built as a microservices architecture. Network software is designed to run as a collection of virtual machines or containers. This makes it easy to embed open source software at runtime as a “guest container” or to embed open source into a software image as part of the standard software build process. gRPC is itself an open source version of from google microservices communication framework. Another example is Sonic, an open-source network operating system launched by Microsoft then handed over to a community of developers.

Sonic includes adaptive streaming telemetry capabilities. The same microservice can be integrated by multiple optical products and vendors, including Infinera’s GX-series, to provide consistent behavior across a class of products. But just grabbing open-source software doesn’t complete the picture. While open source software may work fine in idle conditions, how does it perform under extreme and transient network conditions? This is why most CSPs look beyond open source distribution models and rely on vendors to ensure that the complete software solution is carefully designed, integrated, tested, and supported throughout its lifetime. life cycle. CSPs are looking for suppliers to maintain, validate and guarantee the quality of their software, regardless of its origin, custom-developed in-house or integrated from open source.

Machine learning, anyone?

So where does ML fit into the transformational journey? While the use of ML in transport networks is still nascent, many aspects of optical networks seem well suited to ML techniques.

An example is the estimation of transmission quality, especially during network planning, design and initial deployment. ML can be particularly useful with open optical networks, as detailed third-party optical line system parameters may not be available. By using real-time optical performance data, an ML approach can reduce experimentation, maximize performance, and reduce deployment time.

ML also has the potential to bring self-optimizing transponders and networks to life. By analyzing an almost unlimited streaming telemetry dataset, optical engines can dynamically adjust any number of parameters to adapt bandwidth and overcome deficiencies, and services can be redirected before degradation.

Predictive network health that enables preventative maintenance and predictive network growth that enables early capacity additions are two approaches that can improve service reliability and customer experience.

There has been steady progress in these areas over the past few years, with testing and validation scenarios becoming more realistic, but are we looking at the right datasets and are our algorithms still drawing the right conclusions? The industry lacks trust in ML and our algorithms. This trust must be built in close collaboration between experts in the optical field and data scientists. Our industry needs to deliver ML-based recommendations and dashboards before moving to closed-loop automation. It is only when this trust is established that we will see network engineers willing to take their hands off certain parts of the transportation network wheel.

Are we already there?

As we continue to improve the programmability of the transportation network with abstraction, data modeling, and open interfaces, how do we know when we arrive at our destination? A major milestone will be reached when the physical transport network is almost invisible to the applications and services that depend on it. Like the electricity in our homes or the water in our taps, it is just there in sufficient quantity or as little as needed, without the need to think about it regularly. Along the way, we will continue to collaborate and integrate open source software to overcome specific challenges and apply ML to first guide our decision making and then close the loop on a fully automated network. Like any good road trip, the journey is just as fun and important as the destination.

The author is Tim Doiron, Vice President of Solutions Marketing at Infinera.

Comment on this article below or via Twitter: @VanillaMore WHERE @jcvplus