UNIT 1 INTRODUCTION

How SDN Works – History and Evolution of Software Defined Networking (SDN)-Separation of
Control Plane and Data Plane, IETF Forces, Active Networking.

1. Traditional Networking

Networking has always been very traditional. We have specific network devices like routers, switches,
and firewalls that are used for specific tasks.

These network devices are sold by networking vendors like Cisco and often use proprietary hardware.
Most of these devices are primarily configured through the CLI, although there are some GUI products
like CCP (Cisco Configuration Protocol) for the routers or ASDM for the Cisco ASA firewalls.

A network device, for example, a router has different functions that it has to perform. Think for a
moment about some of the things that a router has to do in order to forward an IP packet:

 It has to check the destination IP address in the routing table in order to figure out where to
forward the IP packet to.
 Routing protocols like OSPF, EIGRP or BGP are required to learn networks that are installed in
the routing table.
 It has to use ARP to figure out the destination MAC address of the next hop or destination and
change the destination MAC address in the Ethernet frame.
 The TTL (Time to Live) in the IP packet has to be decreased by 1 and the IP header checksum
has to be recalculated.
 The Ethernet frame checksum has to be recalculated.

All these different tasks are separated by different planes. There are three planes:

 control plane
 data plane
 management plane

Let‘s take a look at the difference between these three planes…

Control Plane

2
The control plane is responsible for exchanging routing information, building the ARP table, etc. Here
are some tasks that are performed by the control plane.

 Learning MAC addresses to build a switch MAC address table.

 Running STP to create a loop-free topology.
 Building ARP tables.
 Running routing protocols like OSPF, EIGRP, and BGP and building the routing table.

Data Plane

The data plane is responsible for forwarding traffic. It relies on the information that the control plane
supplies. Here are some tasks that the data plane takes care of:

 Encapsulate and de-encapsulate packets.

 Adding or removing headers like the 802.1Q header.
 Matching MAC addresses for forwarding.
 Matching IP destinations in the routing table.
 Change source and destination addresses when using NAT.
 Dropping traffic because of access-lists.

The tasks of the data plane have to be performed as fast as possible which is why the forwarding of
traffic is performed by specialized hardware like ASICs and TCAM tables.

Management Plane

The management plane is used for access and management of our network devices. For example,
accessing our device through telnet, SSH or the console port.

When discussing SDN, the control and data plane are the most important to keep in mind. Here‘s an
illustration of the control and data plane to help you visualize the different planes as shown in figure 1.1

3
 Figure 1.1 Control and Data Plane
Above you can see the control plane where we use routing protocols like OSPF and EIGRP and some
static routing. The best routes are installed in the routing table. Another table that the router has to build
is the ARP table.

Information from the routing and ARP table is then used to build the forwarding table. When the router
receives an IP packet, it will be able to forward it quickly since the forwarding table has already been
buil

Let‘s consider some of the things we have to configure on our network to make this happen:

 The VLANs have to be created on all switches.

 We have to configure a root bridge for the new VLANs.
 We have to assign four new subnets, one for each VLAN.
 We need to create new sub-interfaces with IP addresses on the switches.
 We need to configure VRRP or HSRP on the switches for the new VLANs.
 We have to configure the firewalls to permit access to the new applications / subnets.
 We have to advertise the new subnets in a routing protocol on our switches, routers, and
firewalls.

Although there are network automation tools to help us, we often use the CLI to configure all of these
devices, one-by-one. It‘s a slow, manual process that a human has to do. While it only takes a few
minutes to spin up a new virtual machine, it might take a few hours for the network team to prepare the

4
network. Changes like these are also typically done during a maintenance window, not during business
hours.

Server virtualization is one of the reasons why businesses are looking for something that speeds up the
process described above. Before virtualization, we used to have one physical server with a single
operating system. Nowadays we have multiple physical servers with hundreds of virtual machines.

These virtual machines are able to move automatically from one physical server to another. When they
cross an L3 boundary, you don‘t want to wait for the network team to make the required changes to
routing or access-lists. It should be automatic.

The ―trend‖ nowadays is that everything should be virtual. It‘s not strange to see that this is also
happening to networking. Large companies like Cisco that used to sell only proprietary hardware are
now also offering virtual routers, ASAs, wireless LAN controllers, etc. that you can run on VMWare
servers.

1.1 SDN (Software Defined Networking)

Like the buzzword ―cloud‖ a few years ago, every organization or vendor has a different opinion about
what SDN exactly is and different products that they offer.

Traditional networking uses a distributed model for the control plane. Protocols like ARP, STP, OSPF,
EIGRP, BGP and other run separately on each network device. These network devices communicate
with each other but there is no central device that has an overview or that controls the entire network.

One exception here (for those that are familiar with wireless networking) are the wireless LAN
controllers (WLC). When you configure a wireless network, you configure everything on the WLC
which controls and configures the access points. We don‘t have to configure each access point
separately anymore, it‘s all done by the WLC.

With SDN, we use a central controller for the control plane. Depending on the vendor‘s SDN
solution, this could mean that the SDN controller takes over the control plane 100% or that it only has
insight in the control plane of all network devices in the network. The SDN controller could be a
physical hardware device or a virtual machine.

5
Here‘s an illustration to help you visualize this:

Figure 1.2 SDN Controller

Above you can see the SDN controller figure 1.2 which is responsible for the control plane. The
switches are now just ―dumb‖ devices that only have a data plane, no control plane. The SDN
controller is responsible for feeding the data plane of these switches with information from its control
plane.

There are some advantages and disadvantages of having a distributed vs a central control plane. One of
the advantages of having a central controller is that we can configure the entire network from a single
device. This controller has full access and insight of everything that is happening in our [Link]
SDN controller uses two special interfaces as shown in Figure1.3, take a look at the image below:

Figure 1.3. South and North Bound Interfaces

The interfaces are called the northbound interface (NBI) and southbound interface (SBI). Let me
explain both…

Southbound Interface

The SDN controller has to communicate with our network devices in order to program the data plane.

6
This is done through the southbound interface. This is not a physical interface but a software interface,
often an API (Application Programming Interface).

An API is a software interface that allows an application to give access to other applications by using
pre-defined functions and data structures.

Some popular southbound interfaces are:

 OpenFlow: this is probably the most popular SBI at the moment, it‘s an open source protocol
from the Open Networking Foundation. There are quite a few network devices and SDN
controllers that support OpenFlow.
 Cisco OpFlex: this is Cisco‘s answer to OpenFlow. It‘s also an open source protocol which has
been submitted to the IETF for standardization.
 CLI: Cisco offers APIC-EM which is an SDN solution for the current generation of routers and
switches. It uses protocols that are available on current generation hardware like telnet, SSH, and
SNMP.

Northbound Interface

The northbound interface is used to access the SDN controller itself. This allows a network
administrator to access the SDN to configure it or to retrieve information from it. This could be done
through a GUI but it also offers an API which allows other applications access to the SDN controller.
Here are some examples:

 List information from all network devices in your network.

 Show the status of all physical interfaces in the network.
 Add a new VLAN on all your switches.
 Show the topology of your entire network.
 Automatically configure IP addresses, routing, and access-lists when a new virtual machine is
created.

Here‘s an illustration to help you visualize this:

7
 Figure 1.4. API in multiple applications

through the API, multiple applications are able to access the SDN controller as in figure 1.4.A user that
is using a GUI to retrieve information about the network from the SDN controller. Behind the scenes,
the GUI is using the API.

 Scripts that are written in Java or Python can use the API to retrieve information from the SDN
controller or configure the network.
 Other applications are able to access the SDN controller. Perhaps an application that
automatically configures the network once a new virtual machine is created on a VMware ESXi
server.

REST API

Let‘s take a closer look at what an API is. SDN controllers typically use a REST API
(Representational State Transfer).

The REST API uses HTTP messages to send and receive information between the SDN controller and
another application. It uses the same HTTP messages that you use when you browse a webpage on the
Internet or when you enter a contact form online:

 HTTP GET: used when we want to retrieve information.

 HTTP POST/PUT: used when we want to upload or update information.

It is similar browsing a webpage, only this time, you are not requesting a webpage or picture but a
particular object from the SDN controller, for example, a list with all VLANs in the network.

8
When the SDN controller receives the HTTP GET request in figure 1.5 it will reply with an HTTP GET
response in figure 1.6 with the information that was requested. This information is delivered in a
common data format. The two most used data formats are:

 JSON (JavaScript Object Notation)

 XML (eXtensible Markup Language)

Here‘s an example to help you visualize this:

Figure 1.5 Controller receives the HTTP GET request

Above we have a python script that is using HTTP GET to fetch the following URL through the
API:[Link] URL will retrieve some of the variables that are
available, for example, information about all nodes (hosts) on the [Link] the API receives this, it
will respond with an HTTP GET response message:

Figure 1.6 Controller receives the HTTP GET response

9
3 How SDN Works

The first fundamental characteristic of SDN is the separation of the forwarding and control planes.
Forwarding functionality, including the logic and tables for choosing how to deal with incoming packets
based on characteristics such as MAC address, IP address, and VLAN ID, resides in the forwarding
plane. The fundamental actions performed by the forwarding plane can be described by the way it
dispenses with arriving packets. It may forward, drop, consume, or replicate an incoming packet. For
basic forwarding, the device determines the correct output port by performing a lookup in the address
table in the hardware ASIC.

A packet may be dropped due to buffer overflow conditions or due to specific filtering resulting from a
QoS rate-limiting function, for example. Special-case packets that require processing by the control or
management planes are consumed and passed to the appropriate plane.

Finally, a special case of forwarding pertains to multicast, where the incoming packet must be replicated
before forwarding the various copies out different output ports. The protocols, logic, and algorithms that
are used to program the forwarding plane reside in the control plane. Many of these protocols and

10
algorithms require global knowledge of the network. The control plane determines how the forwarding
tables and logic in the data plane should be programmed Software Defined Networks.

4 How SDN Works or configured

Since in a traditional network each device has its own control plane, the primary task of that control
plane is to run routing or switching protocols so that all the distributed forwarding tables on the devices
throughout the network stay synchronized. The most basic outcome of this synchronization is the
prevention of loops. Although these planes have traditionally been considered logically separate, they
co-reside in legacy Internet switches. In SDN, the control plane is moved off the switching device and
onto a centralized controller.

A Simple Device and Centralized Control Building on the idea of separation of forwarding and control
planes, the next characteristic is the simplification of devices, which are then controlled by a centralized
system running management and control software. Instead of hundreds of thousands of lines of
complicated control plane software running on the device and allowing the device to behave
autonomously, that software is removed from the device and placed in a centralized controller. This
software-based controller manages the network using higher-level policies. The controller then provides
primitive instructions to the simplified devices when appropriate in order to allow them to make fast
decisions about how to deal with incoming packets.

4.1 Network Automation and Virtualization

The centralized software-based controller in SDN provides an open interface on the controller to allow
for automated control of the network. In the context of Open SDN, the terms northbound and
southbound are often used to distinguish whether the interface is to the applications or to the devices.

The southbound API is the OpenFlow interface that the controller uses to program the network devices.
The controller offers a northbound API, allowing software applications to be plugged into the controller
and thereby allowing that software to provide the algorithms and protocols that can run the network
efficiently. These applications can quickly and dynamically make network changes as the need arises.
The northbound API of the controller is intended to provide an abstraction of the network devices and
topology. That is, the northbound API provides a generalized interface that allows the software above it
to operate without knowledge of the individual characteristics and idiosyncrasies of the network devices

11
themselves.

SDN Operation

At a conceptual level, the behavior and operation of a Software Defined Network is straightforward. In
Figure 7 we provide a graphical depiction of the operation of the basic components of SDN: the SDN
devices, the controller, and the applications. The easiest way to understand the operation is to look at it
from the bottom up, starting with the SDN device. As shown in Figure 1.7, the SDN devices contain
forwarding functionality for deciding what to do with each incoming packet. The devices also contain
the data that drives those forwarding decisions. The data itself is actually represented by the flows
defined by the controller, as depicted in the upper-left portion of each device. A flow describes a set of
packets transferred from one network endpoint (or set of endpoints) to another endpoint (or set of
endpoints). The endpoints may be defined as IP address-TCP/UDP port.

Figure 1.7 Components of SDN

pairs, VLAN endpoints, layer three tunnel endpoints, and input ports, among other things. One set of
rules describes the forwarding actions that the device should take for all packets belonging to that flow.
A flow is unidirectional in that packets flowing between the same two endpoints in the opposite
direction could each constitute a separate flow. Flows are represented on a device as a flow entry.

12
A flow table resides on the network device and consists of a series of flow entries and the actions to
perform when a packet matching that flow arrives at the device. When the SDN device receives a
packet, it consults its flow tables in search of a match. These flow tables had been constructed
previously when the controller downloaded appropriate flow rules to the device. If the SDN device finds
a match, it takes the appropriate configured action, which usually entails forwarding the packet. If it
does not find a match, the switch can either drop the packet or pass it to the controller, depending on the
version of OpenFlow and the configuration of the switch.

The controller allows the SDN application to define flows on devices and to help the application respond
to packets that are forwarded to the controller by the SDN devices. In Figure 7 we see on the right side
of the controller that it maintains a view of the entire network that it controls. This permits it to calculate
optimal forwarding solutions for the network in a deterministic, predictable manner. Since one controller
can control a large number of network devices, these calculations are normally performed on a high-
performance. Machine with an order-of-magnitude performance advantage over the CPU and memory
capacity than is typically afforded to the network devices themselves. For example, a controller might be
implemented on an eight-core, 2-GHz CPU versus the single-core, 1-GHz CPU that is more typical on a
switch.

SDN applications are built on top of the controller. These applications should not be confused with the
application layer defined in the seven-layer OSI model of computer networking. Since SDN applications
are really part of network layers two and three, this concept is orthogonal to that of applications in the
tight hierarchy of OSI protocol layers. The SDN application interfaces with the controller, using it to set
proactive flows on the devices and to receive packets that have been forwarded to the controller.
Proactive flows are established by the application; typically the application will set these flows when the
application starts up, and the flows will persist until some configuration change is made. This kind of
proactive flow is known as a static flow. Another kind of proactive flow is where the controller decides
to modify a flow based on the traffic load currently being driven through a network device.

In addition to flows defined proactively by the application, some flows are defined in response to a
packet forwarded to the controller. Upon receipt of incoming packets that have been forwarded to the
controller, the SDN application will instruct the controller as to how to respond to the packet and, if
appropriate, will establish new flows on the device in order to allow that device to respond locally the

13
next time it sees a packet belonging to that flow. Such flows are called reactive flows. In this way, it is
now possible to write software applications that implement forwarding, routing, overlay, multipath, and
access control functions, among others.

Figure 1.8 API with the Controller

An SDN device is composed of an API for communication with the controller, an abstraction layer, and
a packet-processing function. In the case of a virtual switch, this packet-processing function is packet
processing software, as shown in Figure 1.8. In the case of a physical switch, the packet-processing
function is embodied in the hardware for packet-processing logic, as shown in Figure 1.9.

Figure 1.9 packet-processing function

SDN hardware switch anatomy

The packet-processing logic consists of the mechanisms to take actions based on the results of
evaluating incoming packets and finding the highest-priority match. When a match is found, the
incoming packet is processed locally unless it is explicitly forwarded to the controller. When no match is

14
found, the packet may be copied to the controller for further processing. This process is also referred to
as the controller consuming the packet.

In the case of a software switch, these same functions are mirrored by software. Since the case of the
software switch is somewhat simpler than the hardware switch .the actual packet-forwarding logic
migrated into hardware for switches that needed to process packets arriving at ever-increasing line rates.
More recently, a role has reemerged in the data center for the pure software switch. Such a switch is
implemented as a software application usually running in conjunction with a hypervisor in a data center
rack. Like a VM, the virtual switch can be instantiated or moved under software control. It normally
serves as a virtual switch and works collectively with a set of other such virtual switches to constitute a
virtual network.

SDN Software Switches

In Figure 8 we provide a graphical depiction of a purely software-based SDN device. Implementation of

SDN devices in software is the simplest means of creating an SDN device, because the flow tables, 66
CHAPTER 4 How SDN Works flow entries, and match fields involved are easily mapped to general
software data structures, such as sorted arrays and hash tables. Consequently, it is more probable that
two software SDN devices produced by different development teams will behave consistently than will
two different hardware implementations. Conversely, implementations in software are likely to be
slower and less efficient than those implemented in hardware, since they do not benefit from any
hardware acceleration. Consequently, for network devices that must run at high speeds, such as 10 Gbps,
40 Gbps, and 100 Gbps, only hardware implementations are feasible. Due to the use of wildcards in
matching, which poses a problem for typical hash tables, the packet processing function depicted in
Figure 4.3 uses sophisticated software logic to implement efficient match field lookups. Hence, in the
early days of SDN, there was a wide variance in the performance of different software implementations,
based on the efficiency with which these lookups are accomplished. Fortunately, software SDN device
implementations have matured.

The fact that there are two widely recognized software reference implementations (see Section 4.3.4),
both of which use sophisticated and efficient methods of performing these lookups, has resulted in
greater uniformity in software SDN device performance. Software device implementations also suffer
less from resource constraints, since considerations such as processing power and memory size are not

15
an issue in typical implementations. Thus, whereas a hardware SDN device implementation will support
only a comparatively limited number of flow entries, the ceiling on the number of flow entries on a
software device may be orders of magnitude larger. As software device implementations have more
flexibility to implement more complex actions, we expect to see a richer set of actions available on
software SDN device implementations than on the hardware SDN devices that we examine in the next
section. Software SDN device implementations are most often found in software-based network devices,
such as the hypervisors of a virtualization system. These hypervisors often incorporate a software switch
implementation that connects the various virtual machines to the virtual network. The virtual switch
working with a hypervisor is a natural fit for SDN. In fact, the whole virtualization system is often
controlled by a centralized management system, which also meshes well with the centralized controller
aspect of the SDN paradigm.

Hardware SDN Devices Hardware implementations of SDN devices hold the promise of operating
much faster than their software counterparts and, thus, are more applicable to performance-sensitive
environments, such as in data centers and network cores. To understand how SDN objects such as flow
tables and flow entries can be translated into hardware, her we briefly review some of the hardware
components of today‘s networking devices.

Currently, network devices utilize specialized hardware designed to facilitate the inspection of incoming
packets and the subsequent decisions that follow based on the packet-matching [Link] hardware
includes the layer two and layer three forwarding tables, usually implemented using content-addressable
memories (CAMs) and ternary content-addressable memories (TCAMs).

The layer three forwarding table is used for making IP-level routing decisions. This is the fundamental
operation of a router. It matches the destination IP address against entries in the table takes the
appropriate routing action (e.g., forwards the packet out interface B3). The layer two forwarding table is
used for making MAC-level forwarding decisions. This is the fundamental operation of a switch. It
matches the destination MAC address against entries in the table and, based on the match, takes the
appropriate forwarding action (e.g., forwards out interface 15).

The layer two forwarding table is typically implemented using regular CAM or hardware-based hashing.
These kinds of associative memories are used when there are precise indices, such as a 48-bit MAC
address. TCAMs, however, are associated with more complex matching functions. TCAMs are used in

16
hardware to check not only for an exact match but also for a third state, which uses a mask to treat
certain parts of the match field as wildcards.

A straightforward example of this process is matching an IP destination address against networks where
a longest prefix match is performed. Depending on subnet masks, multiple table entries may match the
search key, and the goal is to determine the closest match. A more important and innovative use of
TCAMs is for potentially matching some but not all header fields of an incoming packet. These TCAMs
are thus essential for functions such as policy-based routing (PBR). This hardware functionality allows
the device to both match packets and then take actions at a very high rate. However, it also presents a
series of challenges to the SDN device developer. Specifically:

How best to translate from flow entries to hardware entries; for example, how best to utilize the CAMs,
TCAMs, or hardware-based hash tables?

Which of the flow entries to handle in hardware versus how many to fall back to using software? Most
implementations are able to use hardware to handle some of the lookups, but others are handed off to
software to be handled there. Obviously, hardware will handle the flow lookups much faster than
software, but hardware tables have limitations on the number of flow entries they can hold at any time,
and software tables could be used to handle the overflow.

How to deal with hardware action limitations that may impact whether to implement the flow in
hardware versus software? For example, certain actions such as packet modification may be limited or
not available if handled in hardware.

How to track statistics on individual flows? In using devices such as TCAMs, which may match
multiple flows, it is not possible to use those devices to count individual flows separately.

Openflow is an open standard that enables us to run experimental and innovative protocols in production
networks. Openflow is added as a feature to commercial Ethernet switches, routers, and wireless access
points. And it provides and standardize the tool to allow us to run experiments without requiring vendors
to expose the internal workings of their network devices.

Today, Openflow is a standard communication interface defined between the control and a forwarding
layer of a Software-Defined-Network (SDN) architecture. It's currently being implemented by many

17
vendors with Openflow enabled switch, now commercially available. Openflow became common in
2010. Its concept was first published in an ACM SIGCOMM 2008 paper, and its version 1.1 was
released in early 2011 as a protocol for programming forwarding plane of a network switch or router.
Based on it, Open SDN was proposed in 2011.

All the views of SDN includes SDN via API model, used by Cisco, which allows developers to
manipulate network devices using an extended API. Also, VMware use SDN might overlays. However,
for this lesson we refer to only one view: the Open SDN. In late 2012, the concept on Network Function
Virtualization, NFV, was defined, which is not our replacement for SDN, but rather both SDN and NFV
complement each other.

In a classical router or switch, the datapath and the control path occur on the same device. An Openflow
switch separates these two functions. The datapath portion still resides on the switch where high level
routing decisions are moved to a separate controller, typically a standard server. The Openflow switch
and Controller communicates via the Openflow protocol which defines messages. The Openflow
protocol is used as a communication path between the infrastructure layer, consisting of routers and
switches, and the control layer, which handles centralized intelligence for simplified provisioning,
optimized performance and granularity of policy management.

There are some general misconceptions: It is important to point out that Openflow is not an SDN and
vice versa. There have been other misconceptions such as, if SDN means standard southbound API,
centralization of control plane and a separation of control data plane. All of these misconceptions back
the question, if Software-Defined Network is a mechanism.

SDN is not a mechanism, rather it is a framework to solve a set of problems implying many solutions,
while Openflow is an open API that provides a standard interface for programming the data plane
switch. Software-Defined Network, SDN, is a new technology that was designed to make a production
network more agile and flexible. Production networks are often quite astatic, slow to change and
dedicated to single services. With software-defined networking we can create a network that handles
many different services in a dynamic fashion, allowing us to consolidate multiple services into one
common infrastructure. It does this by using a centralized network control, so separation of control logic
that enables automation and the coordination of network services via open programmatic interface
which includes the cloud, management and business applications.

18
The main advantages of SDN include efficiency, by optimizing existing applications, services and
infrastructure, scalability and innovation. Now, developers can create and deliver new types of
application, and services and new business models.

The need of SDN is driven by several factors: visualization, that remove the need to know where
network resources are physically located, resource cost, organization and so on. Orchestration that is the
need to control and manage thousands of devices with one command can be achieved. Programmability,
the ease of changing network behaviors without horrible upgrades.

Dynamic scaling that should be able to change size and quantity. Automation that requires minimal
manual involvement in operation as cushion, such as troubleshooting and resource provisioning.
Visibility, that allows resource monitoring on network connectivity. Performance, that is due to traffic
engineering, capacity optimization, load balancing and the high utilization.

Multi-tenancy, that allows administration access of address, topology, routing, security and service
integration of load of balancer, intrusion detection system and firewalls.

Network Function Virtualization is a consolidation of different network functions within a virtual server
rather than deploying different hardware for different network function. As such, it decouples functions
like a firewall or encryption from dedicated hardware and moves the function to virtual servers.

The term NFV refer to the strategy of virtualizing network function, moving from separate pieces of
hardware to software running on virtual servers using standard hardware. There are four major
innovations of Network Function Virtualization, which includes standard API between modules.
Network functions are implemented in virtual machines. Network function modules that enhance easy
programmability and a software implementation of network.

5 A brief history of SDN

SDN is about separating the control plane and the forwarding plane, enabling network control to become
programmable and centralized and the underlying network elements abstracted from the applications and
[Link] the early days of SDN, it was associated with OpenFlow, which is a protocol that can be used
to realize L2/L3 switching, firewalls, and many more by leveraging a generic table-based pipeline.
Network controllers can administer and configure the switches‘ forwarding plane, as long as the vendor

19
ecosystem implements and exposes the OpenFlow APIs. That way, based on the need or use case, the
forwarding plane could be (re)configured dynamically through remote and centralized administration.

Internet of Things (IoT) is a catalyst offering many possibilities and setting the bar for a high degree of
networking automation (else operations will not scale).Furthermore, as data has become a currency—
and as data analytics, machine learning and artificial intelligence (AI/ML) are on the rise—the network
needs to be efficient both from a capacity and a reliability perspective.

Expected outcome of SDN

The promise of SDN is to reduce the administration overhead of managing networks, making them more
agile to adapt and adjust based on demand or need, through a centralized controller.

Some other expectations of SDN could include:

 Provide visibility over the network state and enable service assurance (close/open-loop).

 Adjust the network on demand or dynamically to deliver services or meet defined SLA.

 Configure the network to enable or disable traffic patterns (i.e., traffic steering).

 Configure the network to fulfill the needs of new workloads, and automatically enable cross-
workload communication.

 Remove the service specific network configuration when it is decommissioned, and adjust
impacted network elements [Link] has indeed been very appealing to the
communication service.

Make the network programmable and reactive to event/failure, enabling close/open-loop (through more
or less advanced AI/ML), resulting in a reduction of operational expenditure.

5.1 SDN protocols

SDN was broadened with the adoption of other network programmable protocols enabling configuration
of network elements remotely, and providing additional pieces to the puzzle:

NETCONF (XML over SSH) - rfc4741 - 2006.

20
RESTCONF (XML/JSON over HTTP - REST) - rfc8040 - 2017.

gMNI/gNOI (gRPC over HTTP2) - 2018.

This is a non-exhaustive list, but these are the ones I see really driving [Link] brought
many things enabling remote network configuration; to name a few:

 Client-server connection-oriented session with SSH.

 Democratization of YANG as a data modeling language (displacing the vendor defined XML
schema-based configuration definition).

 Remote Procedure Call (RPC) based operations.

 Standardization of RPCs to query and configure a network element‘s configuration/[Link]

of state and datastore: configuration and operation datastore respectfully tracking the declarative
requested state, versus the actual runtime state.

 Network monitoring with a notification framework, subscription-based.

RESTCONF uses HTTP methods to implement the equivalent of NETCONF operations, enabling basic
CRUD operations on a hierarchy of conceptual resources. […] The HTTP POST, PUT, PATCH, and
DELETE methods are used to edit data resources represented by YANG data models. These basic edit
operations allow the running configuration to be altered by a RESTCONF client", as defined in the
RFC8040.

It basically made the interaction with network elements even more trivial for [Link] Network
Management Interface and gRPC Network Operation Interface brought a new paradigm for network
element monitoring with bulk data collection through streaming telemetry. It also provides a way more
effective underlying protocol for RPC, leveraging gRPC / HTTP2.

Another important thing to note is these three protocols heavily rely on YANG as a data modelling
language (rfc6020 – 2010), which opened the door to model-driven [Link] enabled the
open source networking communities to standardize network element configuration data model by
providing a vendor-neutral solution. For a telco striving to abstract its underlying network infrastructure,
and reaching a high level of interoperability, this has become very attractive.
21
The most adopted and mature models are the ones from OpenConfig, mostly for routers, and Open
ROADM for optical elements. But not all the vendors support them, and there is a lot of mapping to
perform between the vendor model and the OpenConfig model when trying to abstract the whole
network with them.

5.2 How SDN has evolved

Initially, there was a proliferation of SDN controllers, and most of them really focused on OpenFlow,
and its related Open vSwitch (OVS). But some of them took a different approach, and provided more of
a platform where one could turn on the protocols they would care about (ONOS, OpenDaylight).

What really made SDN a thing is its adoption in OpenStack through Open Virtual Network (OVN)
around 2016. OpenStack, created in 2010, really has proven the capabilities that SDN has to offer, and at
the same time, made open source networking a real thing (it took a few years for this to happen though).

It also streamlined Network Function Virtualization (NFV), making itself the default platform for the
telecommunication industry to run the vendor provided network functions.

Since then, a lot has happened in the open source community (and in the various standard bodies). To
name a few, The Linux Foundation Networking (LFN) and the Open Networking Foundation (ONF)
helped to bring together vendors, operators and enterprises. They both host a number of projects
important to momentum and adoption (ONOS, P4, ONAP, OpenDaylight, Open vSwitch to name a
few).

5.3 The virtualization of infrastructure

As software evolved and more systems became virtualized, telco saw the opportunity to have their
network functions virtualized. By decoupling software from hardware, it enables the consumption of
cost-effective commodity hardware, and optimization of the overall infrastructure.

For this to happen, telco had to arm wrestle again with network equipment vendors so they would make
their network functions run outside of their custom build and dedicated hardware.

Also, making network functions virtual created a whole new domain of expertise, the infrastructure on
which they run: Network Function Virtualization infrastructure (NVFi). As you virtualize, you add a

22
layer of abstraction that has a cost in terms of networking, compute and memory— the impact on the
end user is not acceptable.

The LFN and its community created projects aimed at integrating various software stacks and enabling
the validation of vendor-provided Virtual Network Function (VNF) on standardized infrastructure:
OPNFV. Cloud iNfrastructure Telco Task Force (CNTT) is another telco-centric open source initiative
that is striving for similar goals.

Are vendor-provided VNF really successful, though? They still require an important amount of
integration and customization of the underlying infrastructure to get the expected performance, defeating
the initial promise of having a shared infrastructure.

In parallel, standard bodies have been standardizing the interfaces to control and manage these network
functions and their related OSS/BSS stack (ESTI, TMForum, GSMA, etc.), but they are mostly
geographically adopted. Whether you‘re in EMEA, APAC or NA, not every telco wants the same
standard, which makes things even harder for the vendor ecosystem.

The data plane consists of physical servers where customers' Amazon EC2 instances run. The control
plane consists of a number of services that interact with the data plane, performing functions such as
these: ... Receiving metering data, logs, and metrics emitted by the servers.

6 IEFT forces

Addressable Entity (AE):

A physical device that is directly addressable given some interconnect technology. For example, on IP
networks, it is a device that can be reached using an IP address; and on a switch fabric, it is a device that
can be reached using a switch fabric port number.

Control Element (CE):

A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs on how to
process packets. CEs handle functionality such as the execution of control and signaling protocols.

CE Manager (CEM):

23
A logical entity responsible for generic CE management tasks. It is particularly used during the pre-
association phase to determine with which FE(s) a CE should communicate. This process is called FE
discovery and may involve the CE manager learning the capabilities of available FEs.

Data Path: A conceptual path taken by packets within the forwarding plane inside an FE.

Forwarding Element (FE): A logical entity that implements the ForCES protocol. FEs use the
underlying hardware to provide per-packet processing and handling as directed/controlled by one or
more CEs via the ForCES protocol.

FE Model:

A model that describes the logical processing functions of an FE. The FE model is defined using Logical
Function Blocks (LFBs).

FE Manager (FEM):

A logical entity responsible for generic FE management tasks. It is used during the pre-association
phase to determine with which CE(s) an FE should communicate. This process is called CE discovery
and may involve the FE manager learning the capabilities of available CEs. An FE manager may use
anything from a static configuration to a pre-association phase protocol (see below) to determine
which CE(s) to use. Being a logical entity, an FE manager might be physically combined with any
of the other logical entities such as FEs.

Network Element (NE):

An entity composed of one or more CEs and one or more FEs. To entities outside an NE, the NE
represents a single point of management. Similarly, an NE usually hides its internal organization from
external entities.

High Touch Capability:

This term will be used to apply to the capabilities found in some forwarders to take action on the
contents or headers of a packet based on content other than what is found in the IP header. Examples
of these capabilities include quality of service (QoS) policies,virtual private networks, firewall, and L7
content recognition.
24
 LFB (Logical Function Block):

The basic building block that is operated on by the ForCES [Link] LFB is a well-defined,
logically separable functional block that resides in an FE and is controlled by the CE via the ForCES
[Link] LFB may reside at the FE's data path and process packets or may be purely an FE control
or configuration entity that is operated on by the CE. Note that the LFB is a functionally accurate
abstraction of the FE's processing capabilities, but not a hardware-accurate representation of the FE
implementation.

FE Topology:

A representation of how the multiple FEs within a single NE are interconnected. Sometimes this is
called inter-FE topology, to be distinguished from intra-FE topology (i.e., LFB topology).

LFB Class and LFB Instance:

LFBs are categorized by LFB classes. An LFB instance represents an LFB class (or type) existence.
There may be multiple instances of the same LFB class (or type) in an FE. An LFB class is
represented by an LFB class ID, and an LFB instance is represented by an LFB instance ID. As a
result, an LFB class ID associated with an LFB instance ID uniquely specifies an LFB existence.

LFB Meta Data:

Meta data is used to communicate per-packet state from one LFB to another, but is not sent across the
network. The FE model defines how such meta data is identified, produced, and consumed by the
LFBs. It defines the functionality but not how meta data is encoded within an implementation.

7 Active networks

Network and its variance meets the scalability demands of a data center network, and it is also cost-
effective. Those two things are good. But however, the network is dependent on the fact that you have
intelligent routing decision. Because there're different communication paths between any two end
points, take different communication routes. So intelligent routing is a key to ensuring performance
between the end hosts. Now if you statically decide the routing between any two servers that would
result in congestion and hotspots in the network. Even though we've got redundant paths available in the

25
class network, you might still end up with congestion and hotspots. So what we really want is the
routing to be not static, but we want it to be dynamic, and this calls for an active network where the
routing decisions are being taken dynamically.

It turns out this requirement for wanting the network routing to be active is not new. Let's talk about
how routing works in the Internet today. Your packet consists of a destination and a payload, and what
happens in a traditional routing network is that routing decisions in the internet are static, and it is
decided by look-up-tables in the routers that are periodically updated. So if you look at this structure
here, this is the source and this is destination, let say, and there are intermediate routers that a particular
packet may take in order to go from source to destination.

What each one of these intermediate states in the packet traversal is doing, is basically doing a lookup in
the look-up-table, which is getting updated periodically. So when a packet comes in, what router is
going to do is, it's going to see the lookup-table and decide what the next hop to send the packet to is.
That's all that every one of these routers are doing. So packet arrives, you look up the lookup table, find
the next hop for the destination, given the destination field in the table entry, and then you route it. This
is static routing, so the next hop is static. Now, what does it mean to make it active? Well active means
that this routers are not looking up any tables, but they're making dynamic decisions. How can they take
the dynamic decision? This is a vision that was proposed by Tennenhouse and Weatherall in the mid
90s, and it is called Active Network.

Now if you look at the packet, it consists of three parts. There is, of course, the destination, where the
packet has to reach, the payload, but there's a new thing, which is the code. What happens is that when a
packet comes in, this router is going to execute this code and make a dynamic decision where to send
that packet, and this code has to be carried in every packet, and it can be executed in the routers between
source and destination.

That way, routers can make dynamic routing decision. So that's the idea behind active network.
Unfortunately, this was proposed in the mid 90s, but this was way ahead of its time. The principal
shortcomings of the active network vision versus the reality is the fact that the lots of vulnerabilities that
you have to be worried about. The first of all, there's the protection threats that a packet is carrying code,
and it is going to execute in a router,

26
The second is resource management threats, meaning that if a package that comes in has code that is
going to get executed in the router, what kind of resources is it going to use as a router, and how is it
affecting other flows through the network fabric? So that becomes another important issue. Perhaps a
very important issue is the fact that the router vendors are loath to opening up the network, and letting
arbitrary code to run on the routers.

Cisco is a router king, it cannot tell router, "Open up your network so that I can execute coordinate
orders" So that's not something that is going to happen really easily. Software routing, meaning that a
packet comes in, you're not just looking up a table, and then dispatching the packet immediately where
it's executing code, which is executing in software, that is going to be much slower than meeting the line
speeds at which hardware routers work.

In Cloud Computing. the service providers want to provide dynamic routing decisions to ensure
performance isolation for the network traffic when you have multi-tenancy in the network. But now
there are chipsets available for assembling your own router, so it's much easier than, I don't mean that
everybody like you and me, but technology giants like Cisco, or Facebook, if they want to build their
own router, no problem, they can build it together. Chipsets are available, makes it easy for building
your own router, skirting the need for buy in from router vendors. So these are all the factors that make
the idea of active routing once again, feasible in today's world.

A data center is a facility that centralizes an organization's IT operations and equipment, as well as
where it stores, manages, and disseminates its data. Data centers house a network's most critical
systems and are vital to the continuity of daily operations.

The term ―data center‖ can be interpreted in a few different ways. First, an organization can run an
in- house data center maintained by trained IT employees whose job it is to keep the system up and
running. Second, it can refer to an offsite storage center that consists of servers and other equipment
needed to keep the stored data accessible both virtually and physically.

Pros: Data centers come with a number of pros. Organizations able to have an in-house data storage
center are far less reliant on maintaining an Internet connection. Data will be accessible as long as

27