CCS365 -SOFTWARE DEFINED NETWORKS

UNIT I SDN: INTRODUCTION

=======================

Evolving Network Requirements – The SDN Approach – SDN architecture - SDN Data Plane , Control
plane and Application Plane

Evolving Network Requirements :

A number of trends are driving network providers and users to reevaluate traditional
approaches to network architecture. These trends can be grouped under the categories of
demand, supply, and traffic patterns.

Demand Is Increasing

As was described in Chapter 2, “Requirements and Technology,” a number of trends are increasing the
load on enterprise networks, the Internet, and other internets. Of particular note are the following:

■ Cloud computing: There has been a dramatic shift by enterprises to both public and private cloud
services.

■ Big data: The processing of huge data sets requires massive parallel processing on thousands of
servers, all of which require a degree of interconnection to each other. Therefore, there is a large and
constantly growing demand for network capacity within the data canter.

■ Mobile traffic: Employees are increasingly accessing enterprise network resources via mobile personal
devices, such as smartphones, tablets, and notebooks. These devices support sophisticated apps that
can consume and generate image and video traffic, placing new burdens on the enterprise network.

■ The Internet of Things (IoT): Most “things” in the IoT generate modest traffic, although there are
exceptions, such as surveillance video cameras. But the sheer number of such devices for some
enterprises results in a significant load on the enterprise network.

Supply Is Increasing

As the demand on networks is rising, so is the capacity of network technologies to absorb rising loads. In
terms of transmission technology, Chapter 1, “Elements of Modern Networking,” established that the
key enterprise wired and wireless network technologies, Ethernet and Wi-Fi respectively, are well into
the gigabits per second (Gbps) range. Similarly, 4G and 5G cellular networks provide greater capacity for
mobile devices from remote employees who access the enterprise network via cellular networks rather
than Wi-Fi.

The increase in the capacity of the network transmission technologies has been matched by an
increase in the performance of network devices, such as LAN switches, routers, firewalls, intrusion
detection system/intrusion prevention systems (IDS/IPS),and network monitoring and management
systems. Year by year, these devices have larger, faster memories, enabling greater buffer capacity and
faster buffer access, as well as faster processor speeds.
Traffic Patterns Are More Complex

If it were simply a matter of supply and demand, it would appear that today’s networks should
be able to cope with today’s data traffic. But as traffic patterns have changed and become more
complex, traditional enterprise network architectures are increasingly ill suited to the demand.

Until recently, and still common today, the typical enterprise network architecture consisted of
a local or campus-wide tree structure of Ethernet switches with routers connecting large Ethernet LANs
and connecting to the Internet and WAN facilities. This architecture is well suited to the client/server
computing model that was at one time dominant in the enterprise environment. With this model,
interaction, and therefore traffic, was mostly between one client and one server. In such an
environment, networks could be laid out and configured with relatively static client and server locations
and relatively predictable traffic volumes between clients and servers.

A number of developments have resulted in far more dynamic and complex traffic patterns
within the enterprise data center, local and regional enterprise networks, and carrier networks. These
include the following:

■ Client/server applications typically access multiple databases and servers that must
communicate with each other, generating “horizontal” traffic between servers as well as “vertical”
traffic between servers and clients.

■ Network convergence of voice, data, and video traffic creates unpredictable traffic patterns,
often of large multimedia data transfers.

■ Unified communications (UC) strategies involve heavy use of applications that trigger access to
multiple servers.

■ The heavy use of mobile devices, including personal bring your own device (BYOD) policies,
results in user access to corporate content and applications from any device anywhere any time. As
illustrated previously in Figure 2.6 in Chapter 2, this mobile traffic is becoming an increasingly significant
fraction of enterprise network traffic.

■ The widespread use of public clouds has shifted a significant amount of what previously had
been local traffic onto WANs for many enterprises, resulting in increased and often very unpredictable
loads on enterprise routers.

■ The now-common practice of application and database server virtualization has significantly
increased the number of hosts requiring high-volume network access and results in every-changing
physical location of server resources.

Traditional Network Architectures are Inadequate

Even with the greater capacity of transmission schemes and the greater performance of
network devices, traditional network architectures are increasingly inadequate in the face of the
growing complexity, variability, and high volume of the imposed load. In addition, as quality of service
(QoS) and quality of experience (QoE) requirements imposed on the network are expanded as a result of
the variety of applications, the traffic load must be handled in an increasingly sophisticated and agile
fashion.
 The traditional internetworking approach is based on the TCP/IP protocol architecture. Three
noteworthy characteristics of this approach are as follows:

■ Two-level end system addressing

■ Routing based on destination

■ Distributed, autonomous control

Let’s look at each of these characteristics in turn.

The traditional architecture relies heavily on the network interface identity. At the physical layer
of the TCP/IP model, devices attached to networks are identified by hardware-based identifiers, such as
Ethernet MAC addresses. At the internetworking level, including both the Internet and private internets,
the architecture is a network of networks. Each attached device has a physical layer identifier recognized
within its immediate network and a logical network identifier, its IP address, which provides global
visibility.

The design of TCP/IP uses this addressing scheme to support the networking of autonomous
networks, with distributed control. This architecture provides a high level of resilience and scales well in
terms of adding new networks.

Using IP and distributed routing protocols, routes can be discovered and used throughout an
internet. Using transport-level protocols such as TCP, distributed and decentralized algorithms can be
implemented to respond to congestion.

Traditionally, routing was based on each packet’s destination address. In this datagram
approach, successive packets between a source and destination may follow different routes through the
internet, as routers constantly seek to find the minimumdelay path for each individual packet. More
recently, to satisfy QoS requirements, packets are often treated in terms of flows of packets. Packets
associated with a given flow have defined QoS characteristics, which affect the routing for the entire
flow.

However, this distributed, autonomous approach developed when networks were

predominantly static and end systems predominantly of fixed location. Based on these characteristics,
the Open Networking Foundation (ONF) cites four general limitations of traditional network
architectures [ONF12]:

■ Static, complex architecture: To respond for demands such as differing levels of QoS, high and
fluctuating traffic volumes, and security requirements, networking technology has grown more complex
and difficult to manage. This has resulted in a number of independently defined protocols each of which
addresses a portion of networking requirements. An example of the difficulty this presents is when
devices are added or moved. The network management staff must use device-level management tools
to make changes to configuration parameters in multiple switches, routers, firewalls, web
authentication portals, and so on. The updates include changes to access control lists (ACLs), virtual LAN
settings, QoS settings in numerous devices, and other protocol-related adjustments. Another example is
the adjustment of QoS parameters to meet changing user requirements and traffic patterns. Manual
procedures must be used to configure each vendor’s equipment on a per-application and even
persession basis.
 ■ Inconsistent policies: To implement a network-wide security policy, staff may have to make
configuration changes to thousands of devices and mechanisms. In a large network, when a new virtual
machine is activated, it can take hours or even days to reconfigure ACLs across the entire network.

■ Inability to scale: Demands on networks are growing rapidly, both in volume and variety.
Adding more switches and transmission capacity, involving multiple vendor equipment, is difficult
because of the complex, static nature of the network. One strategy enterprises have used is to
oversubscribe network links based on predicted traffic patterns. But with the increased use of
virtualization and the increasing variety of multimedia applications, traffic patterns are unpredictable.

■ Vendor dependence: Given the nature of today’s traffic demands on networks, enterprises
and carriers need to deploy new capabilities and services rapidly in response to changing business needs
and user demands. A lack of open interfaces for network functions leaves the enterprises limited by the
relatively slow product cycles of vendor equipment.

The SDN Approach

This section provides an overview of SDN and shows how it is designed to meet evolving network
requirements. Requirements Based on the narrative of Section 3.1, we are now in a position to detail the
principal requirements for a modern networking approach. The Open Data Center Alliance (ODCA)
provides a useful, concise list of requirements, which include the following [ODCA14]:

■ Adaptability: Networks must adjust and respond dynamically, based on application needs, business
policy, and network conditions.

■ Automation: Policy changes must be automatically propagated so that manual work and errors can be
reduced.

■ Maintainability: Introduction of new features and capabilities (software upgrades, patches) must be
seamless with minimal disruption of operations.

■ Model management: Network management software must allow management of the network at a
model level, rather than implementing conceptual changes by reconfiguring individual network
elements. ■ Mobility: Control functionality must accommodate mobility, including mobile user devices
and virtual servers.

■ Integrated security: Network applications must integrate seamless security as a core service instead
of as an add-on solution.

■ On-demand scaling: Implementations must have the ability to scale up or scale down the network and
its services to support on-demand requests.

SDN Architecture:

An analogy can be drawn between the way in which computing evolved from closed, vertically
integrated, proprietary systems into an open approach to computing and the evolution coming with SDN
(see Figure 3.1). In the early decades of computing, vendors such as IBM and DEC provided a fully
integrated product, with a proprietary processor hardware, unique assembly language, unique operating
system (OS), and the bulk if not all of the application software. In this environment, customers,
especially large customers, tended to be locked in to one vendor, dependent primarily on the
applications offered by that vendor. Migration to another vendor’s hardware platform resulted in major
upheaval at the application level.

Today, the computing environment is characterized by extreme openness and great customer
flexibility. The bulk of computing hardware consists of x86 and x86-compatible processors for
standalone systems and ARM processors for embedded systems. This makes it easy to port
operating systems implemented in C, C++, Java, and the like. Even proprietary hardware
architectures, such as IBM’s zEnterprise line, provide standardized compilers and programming
environments and so can easily run open sources operating systems such as Linux. Therefore,
applications written for Linux or other open operating systems can easily be moved from one
vendor platform to another. Even proprietary systems such as Windows and Mac OS provide
programming environments to make porting of applications an easy matter.

The networking environment today faces some of the same limitations faced in the pre-open era of
computing. Here the issue is not developing applications that can run on multiple platforms. Rather, the
difficulty is the lack of integration between applications and network infrastructure. As demonstrated in
the preceding section, traditional network architectures are inadequate to meet the demands of the
growing volume and variety of traffic. The central concept behind SDN is to enable developers and
network managers to have the same type of control over network equipment that they have had over
x86 servers. As discussed in Section 2.6 in Chapter 2, the SDN approach splits the switching function
between a data plane and a control plane that are on separate devices (see Figure 3.2). The data plane is
simply responsible for forwarding packets, whereas the control plane provides the “intelligence” in
designing routes, setting priority and routing policy parameters to meet QoS and QoE requirements and
to cope with the shifting traffic patterns. Open interfaces are defined so that the switching hardware
presents a uniform interface regardless of the details of internal implementation. Similarly, open
interfaces are defined to enable networking applications to communicate with the SDN controllers

Figure 3.3 elaborates on the structure shown in Figure 2.15, showing more detail of the SDN approach.
The data plane consists of physical switches and virtual switches. In both cases, the switches are
responsible for forwarding packets. The internal implementation of buffers, priority parameters, and
other data structures related to forwarding can be vendor dependent. However, each switch must
implement a model, or abstraction, of packet forwarding that is uniform and open to the SDN
controllers. This model is defined in terms of an open application programming interface (API) between
the control plane and the data plane (southbound API). The most prominent example of such an open
API is OpenFlow, discussed in Chapter 4, “SDN Data Plane and OpenFlow.” As Chapter 4 explains, the
OpenFlow specification defines both a protocol between the control and data planes and an API by
which the control plane can invoke the OpenFlow protocol.

SDN controllers can be implemented directly on a server or on a virtual server. OpenFlow or

some other open API is used to control the switches in the data plane. In addition, controllers use
information about capacity and demand obtained from the networking equipment through which the
traffic flows. SDN controllers also expose northbound APIs, which allow developers and network
managers to deploy a wide range of off-the-shelf and custom-built network applications, many of which
were not feasible before the advent of SDN. As yet there is no standardized northbound API nor a
consensus on an open northbound API. A number of vendors offer a REpresentational State Transfer
(REST)-based API to provide a programmable interface to their SDN controller.

Also envisioned but not yet defined are horizontal APIs (east/westbound), which would enable
communication and cooperation among groups or federations of controllers to synchronize state for
high availability. At the application plane are a variety of applications that interact with SDN controllers.
SDN applications are programs that may use an abstract view of the network for their decision-making
goals. These applications convey their network requirements and desired network behavior to the SDN
controller via a northbound API. Examples of applications are energy-efficient networking, security
monitoring, access control, and network management.