100% found this document useful (1 vote)
68 views

White Paper - : Enabling Smart Software Defined Networks

SDN overview

Uploaded by

Cristina Messina
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
68 views

White Paper - : Enabling Smart Software Defined Networks

SDN overview

Uploaded by

Cristina Messina
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 16

White Paper |  E

 NABLING SMART SOFTWARE


DEFINED NETWORKS
Seong Hwan Kim, Ph.D.
System Architect at AMD
TABLE OF CONTENTS
1. Introduction 3
2. The Need for SDN 3
3. Overview of SDN 4
4. SDN Trends and Challenges 7
5. SDN Use Cases 9
5.1 Use Case 1: Data Center 9
5.2 Use Case 2: Wireless Mobile Edge - Seamless Roaming
10
between 3g/4g + WiFi
5.3 Use case 3: Carrier Network 11
5.4 Use case 4: Network Application Management 11
6. AMD Smart SDN Solution 11
6.1 Software Enablement for SDN 11
6.2 High Compute Power at a Low Power Envelope 11
6.3 Security Enhancement 12
6.3.1 DPI - Understanding of Traffic Flow 12
6.4 I/O Integration 12
6.5 Other - Software 13
7. AMD SDN Solution using the APU 13
7.1 AMD APU Details 13
8. Consequences of SDN 15
9. Conclusion 16

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 2


Abstract This paper provides background information on SDN,
addresses some of the key technology considerations
Legacy heterogeneous networks have become and requirements associated with it, and provides
very complex and hard to manage due to upgrade an overview of AMD’s approach to deploying smart
and interoperability challenges, evolving protocols, SDN solutions that streamline SDN adoption and
and management techniques traditionally hard- enable new levels of intelligence in next-generation
coded into the underlying hardware platform. SDN networking platforms.
addresses these problems by decoupling virtual
resources from the physical resources, abstracting
control planes and data forwarding planes, and The Need for SDN
automating network management while enabling Traditional network platforms have both control
centralized orchestration. This paper provides plane and data plane functionalities in a single
background information on SDN, addresses some of physical unit. In this traditional network, routing
the key technology considerations and requirements and switching decisions are made at each individual
associated with it, and provides an overview of AMD’s unit on a dynamic basis. SDN, however, depending
approach to deploying smart SDN solutions that on deployment models (described in a later section),
streamline SDN adoption and enable new levels of moves the control plane to a centralized location and
intelligence in next-generation networking platforms. keeps only the data plane in the switches.

SDN aims to solve the following issues found in


Introduction traditional networks:
• In traditional networks, forwarding decisions
The networking and communication industry is at
are based on predefined rules over which
a critical inflection point as it looks to embrace new
network operators have no control. Thus, all
technologies such as Software Defined Networking packets going to the same destination are
(SDN) and Network Functional Virtualization (NFV). routed along the same path and treated the
While there are incredible advantages to deploying an same way. If there were traffic congestion
SDN network, there are challenges as well: SDN and at any given link along the path, all traffic
NFV require a revamping of network components and would suffer from congestion even though an
structures and new approaches to writing software alternate path is available with less traffic.
for network management and implementing that In addition, legacy networks use a spanning
code in the hardware. tree protocol that limits the use of multilink/
bundling, which can increase bandwidth
A remarkable point to note is that SDN is not a between nodes.
new concept. Centralized network control and • From the network architecture perspective,
visibility have been around for a number of years, the current multitier network architecture (i.e.,
but what’s been missing until recently is a holistic multiple switches connecting switches for
view of networks and technology, with standardized switches) requires many more ports than the
separation of the control and data planes. SDN actual number of servers or end nodes. When
provides this capability and can efficiently enable virtual switches (vSwitches) are deployed, it
data center and service providers to manage
further adds another tier to the network. This
multitier architecture increases the complexity
network configuration, management, routing, and
in the network structure. SDN architecture can
policy enforcement for their evolving multitenant
simplify the multitier network architecture by
heterogeneous network.
virtualizing layers in the network.

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 3


• From a network scalability and expansion functions, enabling the network control to
perspective, a cloud infrastructure-based become directly programmable and the underlying
network with multiple tenants using numerous infrastructure to be abstracted for applications and
applications requires logical isolation from each network services.
other. However, traditional VLAN technology is
unable to provide enough network segments Unlike server virtualization, which enables sharing
to facilitate this. The future network requires of a single physical resource by many users or
scalable LAN segmentation. SDN networks entities, virtualizing network resources enables
can provide scalable LAN segmentation to a consolidation of different physical resources by
effectively manage cloud infrastructure
overlaying another or multiple layers of networks on
environments.
heterogeneous networks, resulting in a homogenous
• Network operators need to have the agility network. Figure 1 describes three requirements that
to quickly and easily upgrade their network commonly define SDN.
infrastructure, but they’re often impeded
by challenges, including real-time debug
Before delving deeply into SDN technology details,
processes, recovery time requirements,
let’s first review the architecture of a typical data
backward compatibility constraints, and more.
center switch. A typical switch consists of line card
SDN can enable much shorter development
times and easier management of the network modules and control card modules. The line modules
through the utilization of common, general are used for switching and forwarding and are
purpose hardware, while providing a holistic typically built-in, purpose-built devices such as ASICs.
way of managing and controlling the network. Control modules, built on low-end control processors,
Consequently, network operators can achieve handle network control and exception traffic. SDN
CAPEX and OPEX savings. moves network control from network elements/
switches to a centralized network controller (or
multiple controllers) using software running on
Overview of SDN general purpose hardware – this approach is designed
to achieve increased control and flexibility. Figure
As defined by the Open Networking Foundation1, 2 shows the base components of a traditional data
SDN decouples the network control and forwarding center switch vs. an SDN switch and network.

AUTOMATION
DECOUPLING ABSTRACTION AND
ORCHESTRATION

• Separation of virtual functions • Abstraction of the control plane • Efficient operation and automated
from the physical hardware, so and data forwarding plane, management of networks
that network functions can be which can allow separation
remotely located of the control plane from the
physical platform

• Centralized or
distributed centralized
control is enabled

Figure 1. SDN Definition

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 4


Control Plane (Centralized)
Control Channel
(OpenFlow API)

Traditional Platform SDN Enabled Platform


Control Plane SDN Client (OpenFlow Agent)

Data Plane Data Plane

a. Traditional Platform Architecture b. SDN Enabled Platform Architecture

Figure 2. Base Components in a Traditional Switch vs. an SDN Platform

OpenFlow is one of the enabling technologies used The following is a summary of OpenFlow:
in an SDN environment, defining the communication • It was initially deployed in the campus network
interface between a controller (control plane) to run experimental protocols and continues to
and forwarding switches (data plane). Supported be maintained as an open source standard.
primarily by the Open Networking Foundation (ONF), • It provides a standard interface to program
OpenFlow removes the entire control plane from the switches and routers without using any vendor-
network equipment. specific APIs.
• It allows network managers to access flow
On the other hand, Path Computation Element (PCE) tables and update the rules used for switches
is another SDN technology option and is mostly and routers to direct network traffic based on
preferred by closed environments like data centers. the entire view of the network. It gives network
It is standardized by the Internet Engineering Task managers the flexibility to have control over
Force (IETF), migrates only the path computation the switching/routing rules with priority control
component of networking devices to a centralized and ACL control, or utilize a custom/new
role, and is mostly preferred by carrier providers. protocol.
• It is independent from the underlying hardware
technology, thus enabling SDN.

Key Benefit Description

Most networks are composed of platforms from multiple vendors. Each vendor’s platform
Unifying multi-vendor
utilizes unique and mostly proprietary user interfaces and commands. SDN can put a unified
environments interface to these platforms, allowing centralized management of multivendor environments.

Reducing complexity SDN automates the process of updating and configuring multiple platforms in the network.

Simplifying network Using programmability provided by SDN, a new network protocol and policy management
update framework can be tested and deployed quickly.

Increasing network SDN controllers provide complete visibility and control over the network – network failure can
reliability and QoS be detected and managed easily. In addition, it can give better visibility into the traffic and
management network, providing network-level QoS.

Table 1. SDN Benefits

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 5


Figure 3 shows an overall SDN network architecture2 most popular southbound interface is OpenFlow.
and well-known solutions available for each layer. Between the control plane and the application layer,
Here, all data plane switches are considered as the northbound interface is defined. One of the more
individual switches, whether they are physical popular implementations of the northbound interface
switches or virtual switches. A virtual switch is is the REST (Representational State Transfer) based
a software switch that can be loaded on an x86 interface. OpenDaylight is one of the SDN controllers
server. As described in the previous sections, the available currently. An open source framework
control plane is separated from the data plane in and platform that includes code and architecture,
an SDN environment. Situated between the data OpenDaylight can help accelerate the adoption of
plane and control plane, the southbound interface SDN and NFV. The controller spans southbound and
includes the service abstraction layer (SAL) – the northbound interfaces, including the control plane.

Customer Application Solutions

Orchestration Networking Compute Storage OpenStack

Northbound Interface

Controller Platform OpenDayLight,


FloodLight
Southbound Interface
Service Abstraction Layer (SAL)

OpenFlow

Switch
Infastructure layer/
Data Plane

vSwitch
Switch Switch

Figure 3. Software Defined Network Architecture and Solutions

OpenStack is a commonly used open source • DashBoard: Provides interface to access,


application and orchestration layer, providing the provision, and automate cloud-based
ability to manage and control large numbers of resources (Horizon)
compute, storage, and networking resources in data • Identity Service: Configures centralized policies
center networks3. OpenStack has several across users and systems (Keystone)
major components: • Image Service: Enables administrators to
• Compute: Provision and manage large networks create base templates and users to choose
of virtual machines (NOVA) from available images or create their own from
• Storage: Object and block storage for use with existing servers (Glance)
servers and applications (Swift, Cinder)
In summary, OpenStack is a cloud operating system
• Network: Defines pluggable, scalable,
API-driven network and IP management (OS) that controls large pools of compute, storage,
(Neutron) and networking resources throughout a data center.

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 6


SDN Trends and Challenges plane hybrid architecture. In this model, the interface
between SDN control plane and data plane would
There are several different SDN deployment scenarios still follow the standard (e.g., OpenFlow API), but
in the industry, although the original SDN concept once the SDN control command reaches the switch
proposes to have a centralized control plane with only platform, the switch would do additional value-added
the data plane remaining in the network. processing with the localized control plane. This local-
ized control plane could potentially provide services
On the controller implementation, a few variations to the local traffic without relying on the central
have been considered in the industry. A central controller’s support (may report the locally performed
or distributed architecture has one or more SDN services to the central controller).
controllers, and it controls all the switches or subset
of switches in the network. Distributed architecture Another important challenge that needs to be
administers a cluster of switches via a dedicated addressed is the communication latency and load
controller, and there are many such clusters with sev- between the SDN controller and the switches. If the
eral SDN controllers in the network. This distributed network has one centralized controller, then all con-
architecture can lower the risk of failure, whereas nection setup requests as well as exception traffic
a single centralized SDN controller failure leads to get forwarded to the controller. This increases the
entire network failure. Using a hierarchical controller load on the controller significantly, and the result-
is another approach – the Logical xBar4 may provide ing latency caused from the communication may
better network scalability. be unacceptable for latency-sensitive applications.
In latency-sensitive environments, further study is
Apart from the controller, the data plane can also be- needed. DevoFlow6 is an example of an approach
come a challenge with the transition to SDN because that harnesses local intelligence to scale traffic flow,
traditional switching and/or forwarding devices/ overcoming performance and latency challenges.
ASICs will not be able to easily support SDN traffic
due to evolving standards. Hence the need to have a If the SDN network needs to provide higher levels of
hybrid approach. Specifically, a portion of the network service including traffic monitoring and application
(e.g., access network) can be SDN enabled while the recognition, traffic flows or packets selected for
other portion (e.g., core network) can remain as a monitoring need to be sent to the controller, as the
‘traditional’ network. Thus traditional platforms are SDN switching platform is a simple forwarder. Thus,
located in the intermediate nodes, acting as a big the amount of traffic that needs to be forwarded
pipe, and SDN enabled platforms are actual switch to the controller becomes significant. Furthermore,
and routing platforms. With this approach, an SDN if a secure channel is required between switches
network may be enabled immediately without having and controllers as recommended in the OpenFlow
the need to overhaul the entire network. standard (TLS secure channel), then the amount of
traffic that needs to be encrypted and decrypted
For most of the switch platform vendors, SDN is a can be significant and can draw hardware resources
disruptive technology; hence they may prefer to keep from the switching platforms’ processors and the
their value added technologies – including part of central controller. Therefore crypto acceleration
the control plane – in their platform. This is a control functionality can be needed to enable SDN.

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 7


SDN/OpenFlow Controller

Delay 2 (Switch ž Contoller)


DC Switch

Control Plane OpenFlow/SDN


Delay 1 (Internal Controller
(Slow Path) Agent Stack ž Data Plane)

MAC MAC IP IP TCP TCP


Data Plane Dest Src Dest Src Dest Src
•••
(Fast Path)
* * * 6.7.8.9 * *

Figure 4. SDN Deployment Problem - Delay

An SDN network may exhibit latency issues due to OpenFlow switch, the other (Delay 1) is an internal
centralized control mechanisms. Delay caused by delay between control processor and switch device.
communication between SDN controller and switch DevoFlow could be used to solve the Delay 2 issue.
could be a significant issue for delay-sensitive Delay 1 can be solved with high-speed, low-cost
applications. As shown in Figure 4, end-to-end delay processors with high-speed interfaces.
involved in SDN controller communication has two
major components. One is a delay (Delay 2) caused The following table lists the differences between
by communication between SDN controller and traditional networks and SDN.

Traditional Network SDN

• Configurable Networks • Programmable Networks

• Apps-Aware Networks • Network-Aware Apps

• Managed Networks • Automated Networks

• Closed Networks • Open Networks

• Fixed Network Interfaces • OpenFlow, OpenStack, NetOS

• Vendor Chassis/Appliances • Generic Switches & Servers

• Custom ASICs • x86, general purpose CPUs

Table 2. Changes from Traditional Networks to SDN

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 8


As networks move more into an “open” architecture, SDN Use Cases
security becomes a critical requirement. Providing
security in the centralized control is imperative to 5.1 Use Case 1: Data Center
avoid a single point of failure. The data center environment is the most common
use case for SDN. In the traditional data center
Challenges in SDN are still emerging as the network, there are ToR (Top of Rack), EoR (End of
definition of SDN continues to evolve. The scale- Row), aggregation, and core switches. Multitier
out network paradigm is evolving as well. Due networking is a common configuration. To increase
to these uncertainties, abstraction mechanisms data center network manageability, SDN can
from different vendors will compete or co-exist. In abstract physical elements and represent them
addition, creation of SDN controllers and switches as logical elements using software. It treats all
requires resolution of design challenges in many network elements as one large resource across
hardware platforms. multiple network segments. Therefore it can provide
complete visibility of the network and manage
policies across network nodes connected to virtual
and physical switches.

Figure 5 shows a traditional multitier data center network, and how an SDN controller can manage the entire
network from a centralized location.

SDN Controller

Core Switch

Aggregation Switch Aggregation Switch


or EoR or EoR

ToR ToR ToR ToR ToR ToR ToR ToR

•• ••

Figure 5. Data Center Network Architecture and SDN Controller

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 9


SDN Controller
Carrier A

SDN Switch
eNodeB
Mobile Access Network Mobile Core
Network
WiFi
SDN Switch
Carrier B
Mobile Backhaul Mobile Gateway
Mobile
Terminals
eNodeB
Figure 6. Heterogeneous Wireless Network with SDN Enablement

5.2 Use Case 2: Wireless Mobile Edge - device type to enable optimal usage of spectrum,
Seamless Roaming between 3g/4g + WiFi Wi-Fi and mobile backhaul links to ensure that the
A wireless network is another good use case for de- maximum number of users can access network
ployment of SDN7. The growing explosion of handheld resources. The SDN controller also provides a holistic
devices such as smartphones and 3G/4G-enabled view of the network and dynamically allocates re-
tablets has increased bandwidth consumption per sources based on the status of the network.
device in hyper-scale, causing spectrum availability
and coverage issues in many areas. As mobile spec- In wireless networks, SDN can also be used for
trum is expensive and limited, one proposed solution separating the control plane from the traditional
to these congestion issues is to use an SDN solution gateways where there is a control path and forward-
that leverages unlicensed spectrum via Wi-Fi to both ing path combined. A centralized SDN controller
offload spectrum and increase spectrum density. runs the control plane and manages the gateway
This solution is very effective for special events platform’s data plane, resulting in a simpler gateway
where many people gather in small areas (such as platform architecture. This approach enables dynamic
stadiums). The SDN solution also addresses network control plane updates and scalability. The ONF
management challenges, supporting fast, seamless Wireless and Mobile Working Group8 is currently
voice, data, and video transition from 3G/4G network studying this approach.
to Wi-Fi networks. In this case, as shown in Figure 6,
the SDN solution dynamically partitions access points
and cell radios based on carriers, usage, identity, and

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 10


5.3 Use Case 3: Carrier Network improve control, allowing the network to quickly
Carrier networks are mission critical. They are the adapt to changes in business needs. Other key
backbone of the communications infrastructure SDN requirements, as outlined before, are the
and are expected to be reliable and fully functional disaggregation of control and data planes, and
all the time. The costs of building and maintaining strong compute and packet processing capabilities.
these critical networks are tremendous, and it can AMD has developed the AMD Smart SDN solution
be extremely difficult and time-intensive to modify to meet SDN’s requirements as described in the
them. SDN for carrier networks is especially complex. following sections.
However, there are possible candidates for SDN use
including: 6.1 Software Enablement for SDN
1. Hotspot 2.0/LTE/Wi-Fi/3G converged access: AMD provides an integration of various components
This is the same use as in the wireless mobile needed to enable SDN, such as ODP, DPDK and Open-
edge network use case above, but it would be Stack. This middleware, e.g., DPDK or ODP, enables
offered as a carrier network service. fast packet I/O for general-purpose CPU platforms,
which tend to have a bottleneck in the data path if
2. Unique QoE per subscriber class: As SDN there is no user space pass-through enablement.
promises flow-level management, it can This middleware software is a must-have require-
enhance user level service quality. With a full ment to enable an SDN solution, providing a unified
view of the network, the controller can provide interface to various platforms including AMD x86
the best routing path for the user traffic. and ARM64 platforms.
Therefore service providers can create premium
services and can further enable network 6.2 High Compute Power at a Low Envelope
monetization. An SDN controller has to have strong compute
capability to handle large amounts of control traffic
coming from many SDN switches – each individual
5.4 Use Case 4: Network Application Management flow needs handling by the central SDN controller.
SDN can enable easy platform upgrades and mi- This brings concerns regarding the SDN controller in
gration for applications such as firewalls9. In this terms of performance and single point of failure.
example, an SDN controller can obtain firewall rule in-
formation from existing firewall appliances (through There are different architectures proposed in the
CLI) and extract firewall ruleset and route informa- industry to mitigate the load to the central controller.
tion. Then the SDN controller transfers firewall One example is a distributed centralized controller,
rulesets to a newer firewall platform, while the SDN which has several SDN controllers, each managing a
controller programs an OpenFlow switch connected subsection of the network, with an additional control
to both old and new firewall appliances to redirect layer managing these regional controllers. This archi-
the traffic from the old to the new firewall appliance. tecture requires smart, distributed powerful compute
Route information extracted from the old firewall ap- capabilities throughout the entire network of SDN
pliance can be used to program the OpenFlow switch, controllers.
as the route information would indicate which flows
are going through the firewall appliance. Once this AMD provides various platforms designed to meet
process gets established and processes are standard- different SDN needs and requirements, all with a
ized, full automation can be achieved. common interface. As mentioned above, different
nodes, including SDN switch nodes, require different
AMD Smart SDN Solution levels of performance and power. AMD provides a
wide range of low power to ultra-high performance
SDN’s basic tenet is to remove vendor specific
devices as listed in Figure 7.
dependencies, to reduce complexity, and to
.

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 11


ULTRA HIGH PERFORMANCE x86 HIGH PERFORMANCE x86 LOW-POWER x86 ARM

Data Center Up to 3.6GHz (w/boost) Up to 2.4GHz Networking/Storage


Server Networking Control Plane Line Card Wireless Infrastructure
Networking High End Control Plane Security Appliance Network Security
Security Supervisor Card Network Attached Storage Control + Data
8-16 Cores Up to 35W 6W-25W 5W-30W

Figure 7. AMD Embedded Solutions

6.3 Security Enhancement • Option 1: Based on the assumption of having


OpenFlow recommends TLS secure channels between a big pipe/channel between SDN switches
the OpenFlow controller and OpenFlow switches/ and SDN controller, all of the deep packet
agents. However, this will become a mandatory re- inspection or application recognition can be
quirement soon for most data center and enterprise done in the central controller with a powerful
applications, as there is a growing need for security. DPI engine.
As the amount of control traffic increases, the needs
of crypto acceleration or offload increase together. By • Option 2: A small DPI engine can be
offloading crypto operation to acceleration engines implemented in the distributed SDN switches.
such as CCP (Crypto Co-processor) on a CPU or GPU in These switches perform a basic deep packet
AMD APU (Accelerated Processing Unit) processors, inspection, then report the results or send only
the system level performance can be maintained streams of important traffic. As we have seen,
without compromising compute performance. AMD the latter case requires cheaper and simpler
provides embedded APUs (accelerated processing
implementation to meet the basic SDN tenet.
Low-cost and low-power AMD APU solutions
units) ranging from the high-end AMD Embedded
can be used for DPI applications through the
R-Series platform to the low-power AMD Embedded
utilization of the APU’s onboard GPU, which
G-Series platform.
is optimized for highly parallel programmable
applications.
6.3.1 DPI - Understanding of Traffic Flow
For an SDN controller to manage the network and 6.4 I/O Integration
associated policies, it requires a good understand- The main processor for SDN requires high-speed I/O
ing of networking traffic. Centralized or distributed interfaces, i.e., embedded network interfaces such as
SDN architectures can support a deep understanding 1G, 10GE, and PCIe. This can lower system cost and
of traffic by collecting sets of packets from a traffic ease system design complexity.
flow, and analyzing them. There are two different
ways to support this requirement.

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 12


Key Benefit Description

Support for the continuation of traditional control plane which does not
Control Plane
require a central controller – Hybrid approach

Value-added features such as


• Ethernet OAM/BFD,
• Security – Firewall and SSL/TLS,
• DPI
Control/Service Plane • Service and application awareness
• QoS management

Dynamic policy update/programmability

Table 3. SDN Intelligent Feature Requirements

6.5 Other - Software dynamic nature of SDN overlays. AMD is working dili-
As alluded to in the previous section, SDN-enabled gently with our ecosystem partners to enable these
systems will be based on commoditized switches and software features, all of which will be optimized for
need to support only basic system level control func- AMD platforms.
tions. However, future SDN-enabled platforms may
require a sub-set of intelligent control and data plane AMD SDN Solution Using the APU
instructions as listed in Table 3. Meanwhile, Most of
the intelligence resides in the central SDN controller. 7.1 AMD APU Details
AMD provides an integration of various components
Further complicating development of SDN solutions needed to enable SDN, such as ODP, DPDK and Open-
are the evolving standards. Throughout the industry, Stack. This middleware, e.g., DPDK or ODP, enables
there are different approaches to enabling network fast packet I/O for general-purpose CPU platforms,
virtualization (VXLAN, NVGRE, etc.), and these which tend to have a bottleneck in the data path if
standards evolve as they move to the next phases. To there is no user space pass-through enablement.
meet the requirements of these evolving standards This middleware software is a must-have require-
– and any emerging network overlaying protocols – ment to enable an SDN solution, providing a unified
platforms must be able to provide flexibility and ease interface to various platforms including AMD x86
of programmability. As an example, the transition and ARM64 platforms.
from the OpenFlow1.0 spec to the OpenFlow revision • General purpose, programmable scalar (CPU),
1.3 significantly increased complexity, as it aimed and vector processing cores (GPU)
to support many types of networking functions • High-performance bus
and protocols. AMD platforms can provide a scal- • Common, low-latency memory model (HSA)
able alternative to solve emerging complexities with
SDN protocols such as OpenFlow and, in general, the

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 13


HSA (Heterogeneous System Architecture) is implemented in some AMD APU platforms10, and is critical to maxi-
mizing throughput. With HSA, the CPU hands over only the pointers of the data blocks to the GPU. The GPU takes
the pointers and processes the data block in the specific memory location and hands them back to the CPU. HSA
ensures cache coherency between the CPU and the GPU. Figure 8 depicts an overview of the APU architecture.

Work-group "scope"

CPU CPU CU CU CU CU CU CU CU CU
L2
L1 L1 L1 L1 L1 L1 L1 L1

L2

Device "scope"

Shared global memory (ex. DDR3 or GDDR5)

System "scope"
Figure 8. APU High Level Architecture

GPUs are extremely efficient and effective for parallel Smart SDN solution, which can selectively accelerate
processing applications, and they can also be used or offload CPU compute-intensive operations to the
for crypto operations, DPI (deep packet inspection), GPU. Here are a few additional functions that can be
classification, compression and other applications. accelerated or offloaded to the GPU:
In the case of crypto operations, the CPU doesn’t • DPI: Implement PCRE based RegEx engine
have to get involved in the data plane crypto opera- • Security (such as IPSec) operations: RSA,
tion directly. With this architecture, the system crypto operation
level performance can be maintained even when the
• Compression operation for distributed
amount of traffic needing encryption or decryption
storage applications
increases. This is one of the key features of the AMD

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 14


SDN Controller
Central Compute
Aggregation Switch Processor

Data Center/Enterprise Network


Access Switch

Switch
Control
Processor

Figure 9. AMD Platform Use Cases in SDN Network

Figure 9 shows AMD’s SDN use case details. Multi-core AMD Embedded R-Series and G-Series processing plat-
forms can be deployed in central SDN controllers where high single thread compute power is used, as well as
SDN switch controllers which may need a subset of intelligence to lower the central controller’s load and localize
network traffic.

Consequences of SDN by low-cost original device manufacturers11. The open


architecture approach from Facebook is creating an
SDN introduces a new approach to network resource ecosystem where standard, high volume commod-
utilization and management, and each networking ity platforms could be used to minimize CAPEX and
vendor in the market is looking into their own way OPEX costs.
to build SDN solutions. One key action that needs to
be taken to enable SDN is to open up the intelligence Clearly the white box and open architecture
of switches and routers to enable the abstraction of approaches are creating major concerns for network-
proprietary vendor technologies. Many equipment ing equipment manufacturers who prefer to add their
vendors that have been traditionally reluctant to own value-added technologies into hardware and
open up their proprietary technologies have slowly software. SDN disrupts these existing technology
opened up their APIs in response to the growing and business models, but is creating more openness
adoption of SDN. Mega data center players (Amazon, and enabling new and different business models.
Google, Facebook and the like) are implementing
technologies that will allow them to enable greater SDN will drive toward a more software-centric
flexibility and lower costs. Amazon and Google are architecture and implementation. Thus, it becomes
building their own networking (white box) switches difficult to provide platform differentiators. With
so that they don’t have to rely on the platforms pro- SDN, the need for less expensive and easy-to-access
duced by OEM vendors. Facebook is driving the Open hardware becomes paramount, and platform-specific,
Compute Platform (OCP) to develop specifications for value-added services are deprioritized.
open architecture switches that will be manufactured

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 15


Conclusion This software enablement can provide a unified
interface to various platforms including AMD
SDN aims to minimize the complexity of heteroge- x86 and ARM64 platforms
neous networks, protocols and management tech-
• GPU-enabled security enhancements. SSL/TLS
niques, thereby achieving CAPEX and OPEX savings. is an optional feature for the communication
This paper addresses the definition of SDN, trends between controllers and switches. In an APU,
and challenges associated with SDN, requirements, the on-board GPU can be used for crypto
potential SDN use cases, and how AMD focuses on acceleration and offload
deploying smart SDN solutions that facilitate the
• Other GPU acceleration and offload features
seamless adoption of SDN while enabling greater including DPI, compression, etc.
intelligence in next generation networking platforms.
• Integrated I/O and various interfaces
AMD provides differentiated technologies and en- • Open source integration, including
ablement solutions to meet the requirements OpenDaylight and OpenStack integration.
of SDN, including:
• A wide selection of low power and high AMD’s Smart APU solution provides an intelligent
performance processing platforms processing platform capable of offloading and
accelerating SDN protocols and functions making
• Integration of the middleware - DPDK or ODP. it ideally suited to handle the performance
This middleware is required to enable fast requirements of next generation networks.
packet I/O for general purpose CPU platforms.

www.amd.com/embedded

Keywords – Software Defined Network, OpenFlow, Network virtualization, Centralized Control, Acceleration, GPU compute.

DISCLAIMER
1) ONF, “Software-Defined Networking (SDN) Definition, WHAT IS SDN?,” 2013 Open Networking Foundation, https://www.opennetworking.org/sdn-resources/sdn-definition
2) ONF, “OpenFlow™-Enabled Mobile and Wireless Networks,” ONF Solution Brief, September 30, 2013
3) OpenStack, “OpenStack: The 5-minute Overview,” http://www.openstack.org/
4) McCauley, James, et al. "Extending SDN to Large-Scale Networks." ONS 2013
5) Dan Levin, et al. "Incremental SDN Deployment in Enterprise Networks,” SIGNCOMM’13, August 12-16, China.
6) Andrew R. Curtis, et al, “DevoFlow: Scaling Flow Management for High-Performance Networks,” SIGCOMM’11, August 15–19, 2011, Toronto, Ontario, Canada
7) Palmer Wiretap Ventures, “WAN & Carrier Network,” ONS Summit 2012, Santa Clara, CA
8) As of December 2014
9) Greg Ferro, “SDN Use Case: Firewall Migration in the Enterprise,” Ethereal Mind, March 18, 2013
10) For details, please contact your AMD representative.
11) Jack Clark, “Amazon, Facebook, Google give Cisco's switches the COLD shoulder,” The Register, http://www.theregister.co.uk/2013/11/18/cisco_cloud_problem/?page=1, 18th November 2013

The information contained herein is for informational purposes only, and is subject to change without notice. While every precaution has been taken in the preparation of this document, it may contain technical inaccuracies, omissions and typographical errors, and
AMD is under no obligation to update or otherwise correct this information. Advanced Micro Devices, Inc. makes no representations or warranties with respect to the accuracy or completeness of the contents of this document, and assumes no liability of any kind,
including the implied warranties of non-infringement, merchantability or fitness for particular purposes, with respect to the operation or use of AMD hardware, software or other products described herein. No license, including implied or arising by estoppel, to any
intellectual property rights is granted by this document. Terms and limitations applicable to the purchase or use of AMD’s products are as set forth in a signed agreement between the parties or in AMD's Standard Terms and Conditions of Sale.

AMD, the AMD Arrow logo, and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names used in this publication are for identification purposes only and may be trademarks of their respective companies.
© 2015 Advanced Micro Devices, Inc. All rights reserved. PID# 156640-A

WHITE PAPER: ENABLING SMART SOFTWARE DEFINED NETWORKS 16

You might also like