A soft approach to defining networks

The communications architectures of the past 20 years have mainly comprised fixed control and data planes that didn’t expand as network requirements evolved. This rigid architecture required carriers to replace equipment frequently if they wanted to expand network functionality and increase overall bandwidth. The line cards at the heart of these systems were largely based on a mix of highly specialised ASICs, ASSPs and memory ICs. FPGAs served to accelerate and bridge communications among the chips on the line card. As the pace of demand quickened, carriers and the communications systems companies that serve them sought better alternatives. In the last few years, they have turned to software-defined networks (SDN) and network functions virtualisation (NFV). These architectures separate the control and data planes, and add more software virtualisation to the control plane. As a result, carriers can rapidly deploy new applications, and network equipment is easier to upgrade than in traditional networks. This improves longevity (and profitability) and simplifies network management (Figure 1).

Figure 1 - Today’s software-defined networks separate the control and data planes but still have fixed data planes, minimal differentiation and short life cycles

But even the most recent SDN and NFV architectures are too rigid in that the data planes are not programmable and the designs typically are based on off-the-shelf ASSPs. The line cards at the heart of the network use discrete off-the-shelf packet-processor and traffic-manager ASSPs connected to optics, along with coprocessors and external memory. The cards also include FPGAs to accelerate communications among all of these chips.

The latest versions of ASSPs that various chip makers have created for SDN and NFV architectures do comply with SDN specifications. But because the suppliers make the same ASSPs generally available to all network systems companies, these chips provide no competitive product differentiation or feature expansion. As a result, network system vendors are forced to compete on lowest pricing to carriers.

On the surface, one would think the carriers would love this lower equipment pricing. But in reality, fixed data-plane designs even in ASSP-based SDN architectures are still so rigid that carriers will have to make expensive in-field line-card swaps when they find out the ASSP’s fixed hardware functionality can’t accommodate ever-changing applications, protocol updates and new feature requirements. These line-card swaps require networks to shut down while technicians remove obsolete cards and install new ones. What’s more, ASSP vendors tend to overbuild the functionality of their designs in an attempt to address a broad number of markets with a single device. As a result, these ASSP-based line cards tend to be power hungry and thus run hot, so carriers must take extra measures to keep the equipment cool.

The soft approach

SDNet is Xilinx’s softly defined network approach, which will enable communications systems companies to develop integrated, low-power, programmable line cards that offer more than a software-defined control plane with network intelligence required by SDN architectures. This new technology will also let vendors differentiate their systems with software-defined data-plane hardware that has content intelligence, meaning that design teams can tailor the hardware to the exact network services and applications their systems require (Figure 2).

Figure 2 - SDNet brings flexibility and automation to the data plane, enabling a softly defined network approach for the design and upgrade of next-generation networks

Traditionally, network architects (who typically don’t have hardware design backgrounds) express the requirements of particular protocols in English-language descriptions, such as Internet requests for comment (RFCs) or ISO standards documents.

They then have to rely on specialised engineers who are very well-versed in the underlying architecture of the target device to manually turn those requirements into low-level, implementation-specific, descriptions (typically using highly specialised microcode). These hardware engineers will either specify how the general-purpose processors or specialised network processors should perform the packet processing, or they will design the functionality into a custom ASIC.

Network design teams then have to verify that the hardware achieves the architect’s original design intent or can at least accommodate the most recent version of the protocol they intend the card to use. If the line card doesn’t meet the requirements, they have to repeat the design process until they get it to work properly. This process is complicated by the fact that the relationship between the desired specification and the microcode is not intuitive and the underlying architecture has performance limitations and capabilities that vary based on the services companies are targeting.

SDNet’s softly defined network approach goes to the root of this problem and allows network system design teams to quickly design line cards that are correct by construction. In particular, SDNet focuses on automating the most complex aspect of line card design, namely the design and programming of the packet-processor and traffic-manager functions in modern line cards (Figure 3).

Figure 3 - With SDNet, companies can create a highly integrated All Programmable line cards

Instead of having two separate, discrete ASSPs handling these functions, network systems teams can integrate packet processing and traffic management as well as other line card functionality on a single Xilinx All Programmable FPGA or SoC. They can ensure they are creating optimal implementations for their targeted applications. In addition to integrating the functionality of many chips into one All Programmable device, SDNet streamlines the creation of a high-level behavioural specification of the line card and automatically generates RTL blocks for implementation in Xilinx All Programmable devices, firmware and a validation testbench.

In the SDNet flow, system architects define line-card functionality using a high-level functional specification. SDNet allows architects to describe the required behaviour of various types of packet-processing engines, including parsing, editing, search and quality-of-service (QoS) policy engines. Architects can describe engines hierarchically in terms of simpler sub-engines that they can interconnect and arrange into packet data flows. These sub-engines can include user-provided engines. The SDNet specification environment contains no implementation details. That gives customers the freedom to scale the performance and resources of their design without the need to understand the details of the underlying architecture. The SDNet specifications are also not limited to any specific network protocols.

Once architects have finished defining the system engines and flows in the SDNet specification environment, they provide SDNet’s compiler with throughput and latency requirements and run-time programmability requirements that influence the optimised hardware architecture generated by the compiler. They then execute a command, and SDNet’s compiler automatically generates the RTL for the hardware blocks the design requires. The compiler also generates firmware and a verification/validation testbench. The SDNet design environment includes integration of Xilinx-optimised SmartCOREs for networking and LogiCOREs for connectivity, external memory control and embedded processors.

After compilation, network engineers can then finish the implementation of the design in the Vivado Design Suite using the IP Integrator (IPI) tool. They first use the Vivado tools and IPI to transform the RTL architecture description the SDNet compiler has generated into an optimised Xilinx FPGA implementation. They can then integrate any additional line-card functionality into the FPGA, given sufficient resources on the device they’ve selected, essentially creating an All Programmable line card on a chip.

What’s more, SDNet generates data for functional verification and validation to guide correct-by-construction design. Specifically, SDNet’s compiler accepts a collection of test packets for testing input and output of the design. Architects can use the packets in the specification-definition phase of the process to ensure they are creating an accurate interpretation of the SDNet description. Network engineers can use test packets during the simulation of the RTL description generated by the SDNet compiler. Last but not least, the packets can help with hardware validation of the final implementation of the design using network test equipment. In addition, SDNet will generate corresponding contents for search engine lookup tables. This verification-and-validation ability vastly reduces design time and eliminates iterations between system architects and network hardware engineers, allowing the teams to get highly differentiated products to market faster.