The Importance of SD-WAN Solution Certification

Modern network solutions require use of piece parts from multiple manufacturers that must integrate to provide a complete solution.  In the past, single vendor solutions were the norm, allowing the original equipment manufacturer, OEM, to test products thoroughly prior to the point of sale.  A single vendor solution example could be a router, switch, firewall, or SD-WAN appliance.  Secure Access Service Edge (SASE) requires a comprehensive framework view of solution integration to ensure SECURE network communications are taking place according to the policy set by the organization consuming the solution.  SASE pushes industry to focus more on interoperability than was required in the past. According to a McKinsey & Company paper from March 2019 entitled Perspectives on transforming cybersecurity, the prescriptive deployment process used in the past must transition to “launch-review-adjust” mode in order to adapt to technology threat evolution.

Today, to provide a complete solution in any infrastructure deployment, a mixture of physical, virtual, and cloud-based products must be integrated into a solution. Often these solutions involve 3 or more OEM products that may not have had integration or compatibility testing. TechTarget recognized that with few exceptions SASE Services are going to require a “best of breed” or “service chaining” approach to provide all of the Service components in the framework.

“The Internet Engineering Task Force (IETF) publishes its specifications as Requests for Comments (RFCs).” (Interlink Networks, 2012) Modern network edge products can often be RFC compliant but still not interoperate with other RFC compliant products. This is often discovered after multi-million-dollar investments into a production deployment.  In the field often these types of after-the-fact discoveries can cause a project budget to double or more.

Due to product development, “DEVOPS” efficiencies the market is launching new product generational lifecycles at an average pace of one every 18 months. Minor software releases are deployable in production in 2-3 Sprint Cycles whereas in the past, production routers would see updates on every year or two and often only when an issue was being resolved. 

Today hardware being deployed for a 60-month capital depreciation schedule can and should evolve the software code 250% during its production lifetime. This means that the original purpose and workload of the hardware when installed evolves to be something potentially different prior to being upgraded with the next generation physical platform. For this reason, the majority of branch and datacenter edge hardware is evolving to Universal Customer Premise Equipment (UCPE) or essentially an appliance, equivalent to a small server that can handle the same temperature and electrical power capabilities as a branch router which does not operate in a datacenter.  This UCPE must be able to support a hypervisor or container system or both.  Often an operating system (OS) on bare metal build is feasible with multifunctional device images however, the virtual machine (VM) approach allows much more flexibility in deployment where upgrades to functionality can be performed without a truck roll to the installation site. Today more Virtual Network Function (VNF) deployments are taking place than are physical hardware deployments.

In the market for the past few years, virtual OEM network infrastructure has been primarily VM based whereas the market is turning to Docker container system for routers, firewalls, SD-WAN, and similar virtual infrastructure packages. Over the next few years network infrastructure is expected to normalize into Kubernetes native that will allow Cloud-native Network Function (CNF) look and feel. This CNF would be deployable into the edge, hybrid, multi, distributed, service mesh, on premise, native, and all types of CLOUD environments. This normalization allows the OEM functionality of branded and open source network infrastructure components to be delivered regardless of what hardware, hypervisor, container system, cloud native, or any environment they are deployed on.

When moving to VNF or CNF for networking, security, SD-WAN, or SASE, the additional topic of service chaining must be considered. For a simple working idea of service chaining, imagine virtual Ethernet cables within the virtual operating environment of the chassis, datacenter, or cloud deployment. Service chaining can be performed several ways however, it is common to use a virtual switching environment and develop a template that defines how each logical Ethernet interface connects to each other device such as a logical rack elevation diagram. This service chain is an additional level of risk for compatibility and security concerns in production. Significant testing should be performed to guarantee stated production performance and security goals prior to actual production deployment. (See ETSI unveils new standard for NFV deployment templates)

To solve for interoperability concerns, AT&T requires extensive certification testing for all standard solutions prior to offering for sale. This certification process is designed to identify non-compliance with published industry standards, as well as software issues at any level in the solution. Often performance can be hampered by incompatible execution on protocols or firmware. Most performance issues are uncovered with load testing of all components within a given solution.

AT&T works with MEF, formerly The Metro Ethernet Form, https://www.mef.net/ to develop standards for interoperating solutions across multiple different clouds and manufacturers. The MEF 3.0 certified services and technology programs allow customers to leverage best of breed solutions with common certification standards ensuring performance and function. Certifying a solution end to end is allows for resilience with predictable expectations.