Unit -1 SDN: INTRODUCTION

1.1 Evolving Network Requirements

Software-defined networking is an evolving network architecture beheading the traditional

network architecture focusing its disadvantages in a limited perspective. A couple of decades
before, programming and networking were viewed as different domains which today with the
lights of SDN bridging themselves together. This is to overcome the existing challenges faced by
the networking domain and an attempt to propose cost-efficient effective and feasible solutions.
Changes to the existing network architecture are inevitable considering the volume of connected
devices and the data being held together. SDN introduces a decoupled architecture and brings
customization within the network making it easy to configure, manage, and troubleshoot.

Software-defined networking, or SDN, is a strategy that splits the control plane from the forwarding
plane and pushes management and configuration to centralized consoles.

SDN is now over 10 years old. When the history of SDN began, many people thought gleaming
software-defined networks would replace tightly coupled, vertically integrated network products.
The massive data centers of Amazon, Facebook and Google all moved to SDN, but why isn't SDN
everywhere?

Well, it is, even if it's not always called SDN.

The principles of SDN are alive and well, thanks, in part, to cloud computing. All of today's major
cloud providers use SDN. As more workloads move to cloud environments, more organisations
will use SDN. Let's look at the evolution of SDN to see how it got to this point.

1.1.1 The role of vendors in the evolution of SDN

In the corporate data center, practically everything is virtualized -- from workloads to servers to
networking. VMware, the king of the virtualized data center, bought Nicira and rebranded its SDN-
style networking as VMware NSX. Hundreds of thousands of virtual machines in data centers
around the world run on NSX, which means they run on SDN.

Cisco -- the company that initially scoffed at SDN, because it threatened the status quo -- eventually
hopped on the bandwagon and introduced an SDN variant, Cisco

Application Centric Infrastructure, to the market, trying to embrace the future without letting go of
the past.
Other networking companies began to turn to SDN, as well. Juniper Networks embraced SDN in
its Contrail products, and Arista Networks integrated SDN principles into its Extensible Operating
System in an attempt to bring a new software-defined cloud networking to the market.

Smaller vendors, like Dell Technologies and Hewlett Packard Enterprise, used the SDN strategy to
open up their platforms, split tightly coupled hardware and software apart, and inject customer
choice into the process. While not necessarily SDN, this open networking strategy is an important
part of the evolution of SDN's overall viability.

1.1.2 Problems in Traditional Network Devices

● They are vendor specific

● Hardware & Software is bundled together
● Very costly
● New features can only be added at the will of the vendor.
 ● Client can only request the features, vendor will decide whether to add those features or
not & the time frame in which these features will become available is at the sole discretion
of the vendor.
● Devices are function specific. You can not make your router behave like load balancer or
make your switch behave like a firewall or vice versa.
● If your network consists of hundred of these devices, each device has to be configured
individually. There is no centralized management.
● Innovations are very rare. Last 3 decades have not seen many innovations in networking.
Whereas Compute and storage industry has seen drastic changes such as compute
virtualization & storage virtualization. Networking has not been able to keep pace with
other ingredients of Cloud Computing.

1.1.3 Advantages of SDN

● The network is programmable and hence can easily be modified via the controller rather
than individual switches.
● Switch hardware becomes cheaper since each switch only needs a data plane.
● Hardware is abstracted, hence applications can be written on top of the controller
independent of the switch vendor.
● Provides better security since the controller can monitor traffic and deploy security policies.
For example, if the controller detects suspicious activity in network traffic, it can reroute
or drop the packets.

1.1.4 Disadvantages of SDN

● The central dependency of the network means a single point of failure, i.e. if the controller
gets corrupted, the entire network will be affected.
● The use of SDN on a large scale is not properly defined and explored.

1.1.5 Why SDN is Important

● Better Network Connectivity: SDN provides very better network connectivity for sales,
services, and internal communications. SDN also helps in faster data sharing.
● Better Deployment of Applications: Deployment of new applications, services, and many
business models can be speed up using Software Defined Networking.
 ● Better Security: Software-defined network provides better visibility throughout the
network. Operators can create separate zones for devices that require different levels of
security. SDN networks give more freedom to operators.
● Better Control with High Speed: Software-defined networking provides better speed than
other networking types by applying an open standard software-based controller.

In short, it can be said that- SDN acts as a “Bigger Umbrella or a HUB” where the rest of other
networking technologies come and sit under that umbrella and get merged with another platform
to bring out the best of the best outcome by decreasing the traffic rate and by increasing the
efficiency of data flow.

1.1.6 Components of Software Defining Networking (SDN)

The three main components that make the SDN are:

1. SDN Applications: SDN Applications relay requests or networks through SDN

Controller using API.
2. SDN controller: SDN Controller collects network information from hardware and
sends this information to applications.
3. SDN networking devices: SDN Network devices help in forwarding and data
processing tasks.
1.2 The SDN Approach

In traditional networks, the control and data plane are embedded together as a single unit. The
control plane is responsible for maintaining the routing table of a switch which determines the best
path to send the network packets and the data plane is responsible for forwarding the packets based
on the instructions given by the control plane. Whereas in SDN, the control plane and data plane
are separate entities, where the control plane acts as a central controller for many data planes.
There are many approaches that lead to the development of today’s Software Defined
Networks(SDN). They are:

● Force
● 4D approach
● Ethane

1.3.1 FORCES(Forwarding and control element separation):

The idea of separation of data plane(forwarding element) and control plane was first proposed by
FORCES. It is said that hardware-based forwarding entities are controlled by a software-based
control plane.

FORCES can be implemented in two ways:

1. The forwarding element and control plane are located within the same network
device
2. The control element is taken off the device and placed in a separate system.
1.3.2 4D approach:

The 4D approach has four planes that control

● Decision
● Dissemination
● Discovery
● Data

It follows three principles:

Network-level objectives: The objectives should be stated in terms of the whole network instead
of individual devices. So that there won’t be any need to depend on proprietary devices.

Network-wide view: Decisions should be made based on the understanding of the whole
network’s traffic, topology, and events. Actions should be taken based on considering a network-
wide view.

Direct control: The control plane elements should directly be able to control the data plane
elements. It should have the ability to program the forwarding table on individual devices.
1.3.3 Ethane:

Ethane specifies network-level access of users which is defined by network

administrators. Ethane is the exact forerunner of Software Defined Networks(SDN)
1.3.3.1 Principles of Ethane

● High-level policies should inspect the network

● Routing should follow High-level policies.
● There should be a connection between packets and their origin in the network.

1.3.4 SDN Layers

The layers communicate via a set of interfaces called the north-bound APIs(between the application
and control layer) and southbound APIs(between the control and infrastructure layer).

1.3.4.1 Different Models of SDN

There are several models, which are used in SDN:

1. Open SDN
2. SDN via APIs
3. SDN via Hypervisor-based Overlay Network
4. Hybrid SDN

1. Open SDN: Open SDN is implemented using the OpenFlow switch. It is a straightforward
implementation of SDN. In Open SDN, the controller communicates with the switches using south-
bound API with the help of OpenFlow protocol.
2. SDN via APIs: In SDN via API, the functions in remote devices like switches are invoked using
conventional methods like SNMP or CLI or through newer methods like Rest API. Here, the
devices are provided with control points enabling the controller to manipulate the remote devices
using APIs.

3. SDN via Hypervisor-based Overlay Network: In SDN via the hypervisor, the configuration
of physical devices is unchanged. Instead, Hypervisor based overlay networks are created over the
physical network. Only the devices at the edge of the physical network are connected to the
virtualized networks, thereby concealing the information of other devices in the physical network.
4. Hybrid SDN: Hybrid Networking is a combination of Traditional Networking with software-
defined networking in one network to support different types of functions on a network.

Difference between SDN and Traditional Networking

Software Defined Networking Traditional Networking

Software Defined Network is a virtual A traditional network is the old conventional

networking approach. networking approach.
 Software Defined Network is centralized
Traditional Network is distributed control.
control.

This network is programmable. This network is non programmable.

Software Defined Network is the open

A traditional network is a closed interface.
interface.

In Software Defined Network data plane

In a traditional network data plane and
and control, the plane is decoupled by
control plane are mounted on the same plane.
software.

1.4 & 1.5 SDN Data Plane ,Control plane and Application Plane

1.4 SDN Data Plane

While the Control Plane supervises and directs, the Data Plane is responsible for the actual
movement of data from one system to another. It is the workhorse that delivers data to end users
from systems and vice versa.
Some examples of data planes include:
● Ethernet networks
● Wi-Fi networks
 ● Cellular networks
● Satellite communications
Data planes can also include virtualized networks, like those created using virtual private networks
(VPNs) or software-defined networks (SDNs). Additionally, data planes can include dedicated
networks, like the Internet of Things (IoT) or industrial control systems.
Data planes allow organizations to quickly and securely transfer data between systems. For
example, a data plane can enable the transfer of data between a cloud-based application and a local
system. This functionality can be beneficial for organizations that need to access data from multiple
systems or that need to quickly transfer large amounts of data.

By using dedicated networks, organizations can keep data secure through encryption, dedicated
networks, and access monitoring to prevent unauthorized access of data.

1.5 SDN Control Plane

The Control Plane is a crucial component of a network, tasked with making decisions on how data
should be managed, routed, and processed. It acts as a supervisor of data, coordinating
communication between different components and collecting data from the Data Plane.

Control Planes utilize various protocols, such as:

● Routing protocols (like BGP, OSPF, and IS-IS)
● Network management protocols (SNMP)
● Application layer protocols (HTTP and FTP)
These protocols often employ software-defined networking (SDN) to create virtual networks and
manage their traffic. Virtual networks, facilitated by SDN, are instrumental in managing data traffic
at an enterprise level. They enable organizations to:
● Segment traffic
● Prioritize important data flows
● Isolate traffic from different parts of the network

Data Plane vs. Control Plane: What Are the Key Differences?
The main differences between control and data planes are their purpose and how they communicate
between different systems. The control plane decides how data is managed, routed, and processed,
while the data plane is responsible for the actual moving of data. For example, the control plane
decides how packets should be routed, and the data plane carries out those instructions by
forwarding the packets.
Along with doing different jobs, control planes and data planes exist in different areas. While the
control plane runs in the cloud, the data plane runs in the data processing area.
They also use different functions to do their jobs. Control planes use protocols to communicate
between different systems, mostly common routing protocols like BGP, OSPF, and IS-IS or
network management protocols like SNMP. These protocols enable the control plane to make
decisions on how data should be managed, routed, and processed.
Data planes use dedicated networks to communicate between different systems. Examples of
dedicated networks used in data planes include Ethernet and Wi-Fi networks, cellular networks,
satellite communications, virtualized networks, and dedicated networks used in industrial control
systems or IoT. These networks enable the data plane to deliver data to end users from systems and
vice versa.
While both the Control Plane and Data Plane are integral to network management, they perform
distinct roles. The table below outlines some of the key differences between the two:

Control Plane Data Plane

Determines how data should be managed, Responsible for moving packets from source
routed, and processed to destination

Builds and maintains the IP routing table Forwards actual IP packets based on the
Control Plane’s logic

Packets are processed by the router to update the Forwards packets based on the built logic of
routing table the Control Plane

1.5.3 Software-Defined Networking (SDN) Application

Software-defined networking (SDN) application is a software program which is designed to
perform a task in a software-defined networking environment. It is that approach to computer
networking that not only allows network administrators to change programmatically, control,
initialize, and manage network behaviour dynamically through open interfaces but also provides
the concept of lower-level functionality. SDN applications also help in enlarging and substituting
upon functions that are accomplished in the hardware devices of a regular network through
firmware.

1.5.2.1 SDN application environment

Internal SDN Applications

Applications that are hosting the rest of the OpenDaylight controller software and are deployed
internally, run inside the container. These applications must be written in the native language which
is Java for ODL. Internal SDN applications must also adhere to the execution and design constraints
of the controller. It must also execute in the same Java Machine as the controller which means that
these types of the application must run locally with the controller. It can also access the MD-SAL
applications and Java APIs of the controller running inside the controller’s OSGi container.

External SDN Applications

Applications that are hosting the rest of the Open Daylight controller software, and are deployed
externally, run outside the container. Any language can be used for writing External SDN
applications that are scripting languages such as Bash. These applications can be run remotely
which means on a different host than the controller. These applications will also use the application
providing Restful access to their services and REST API provided by the controller.

Top Application and Service that can benefit from SDN are:

Security services
The modern virtualization ecosystem supports specific virtual service that is running within the
network layer. It means an incorporating function like NFV into SDN platforms. This type of
network security creates a genuinely proactive environment that is capable of risk reduction and
responds to the incidents very quickly. Whenever a violation occurs, every second is quite critical
to stop the attack. It is also essential to identify the attack and also to ensure that other network
components are safe from the attack. As the organization in the modern era becomes even more
digitized, and as the network layer becomes even more critical, we will see even more attacks and
more advanced sophisticated advanced persistent threats. You will be able to create a more
proactive environment that is capable of responding to the changes if you integrate potent
services into the SDN layer.

Network Monitoring and Intelligence

Modern SDN technologies help in abstracting one of the most critical layers within the data
centre that is the network. Network architectures are very much complicated and have to handle a
lot more data than ever before. This means it’s critical to know what is following through your
environment. Do you have remission issues on a port? What will happen if you are running
heterogeneous network architecture? Or, are you passing a lot of traffic and are heavily
virtualized through the network architecture? All of these challenges or issues are diminished if
you have a solid network monitoring and intelligence layer. However, you also gain benefit and
true insight if you integrate these technologies into your SDN architecture. Even optimization,
alerting, hypervisor integration, port configurations, and traffic flow can be incorporated into
network monitoring and intelligence technologies. Also, these types of agile systems will also
help you to monitor network traffic between your cloud ecosystem and your data centre.

Bandwidth Management
With the help of SDN applications, operators can use bandwidth management to ensure the end
users to receive online video watching and optimal browsing experiences. This SDN application
can also monitor the bandwidth requirements then provision user flows to match the latency and
bandwidth requirements of the layer 7 application. This type of application-aware approach to
bandwidth management will also ensure a better user experience with zero buffering through
better video playback. At this stage in the game, there is little doubt that SDN is becoming a
reality in operator networks.

However, it is the SDN applications that will really bring powerful improvements to the
operator’s business and networks, beyond the immediate impact of simpler management of the
network. And so the network infrastructure providers need to start mapping out this future to
calculate all the potential that can be provided by SDN.
By acting and thinking ahead on SDN applications now, network infrastructure operators and
providers will be able to rapidly evolve to provide flexible, customized networks that can entirely
enhance their own bottom lines and can also enhance the end user experience.

Content Availability
There will be content servers used for media delivery or caching, on a service-provider edge
network. These are installed by the content delivery network or operator service providers.
Content that is to be served to the users is distributed and preoccupied across multiple content
servers and also across various geographies in some cases.

SDN apps will be able to provision flows in the network based on the availability and types of the
content which is built to handle content availability. SDN applications can also check the
availability of the content in the content servers before routing requests to servers. A content-
routing application will provide intelligence on its availability along with enabling discovery of
content in the content servers.

This intelligence can be further used to route requests to the correct servers wherever the content
is residing. Therefore, SDN application will direct requests from those websites which are non-
cache-able and that generate active content to a server that provides active content rather than a
caching server which significantly reduces network discontinuation.

Regulation and Compliance-Bound Applications

Major cloud vendors are now providing the capability to work and store with compliance and
regulation-bound workloads. Now organizations have the option to extend architectures which
have initially been very limited because of regulation into the cloud and distributed environments.
How can you segment the traffic? How can you ensure that regulation and compliance workloads
are persistently monitored and secured? Here SDN can be a great help for you.

Network points, network traffic travelling between switches, and even hypervisors can be
controlled in SDN architecture. You should also remember that this layer abstracts virtual
hardware and functions controls. This powerful layer can then span various virtualization points,
locations, and even cloud locations.

High –Performance Applications

We are all seeing a rise in new types of application technologies. The delivery of rich apps like
graphics design software, engineering, CAD, and GIS is allowed by virtualization. Traditionally,
these workloads are required bare-metal architectures with their own connections. However, with
the help of virtualization, VDI can help in creating powerful desktop experiences and applications
are streamed. We can also see the integration of SDN into application control at the network
layer. All of these functions like segmenting heavy traffic, securing confidential data, creating
powerful QoS policies, and even creating threshold alerts around bottlenecks within SDN will
help to support rich and high-performance applications which are being delivered through
virtualization.

Distributed Application Control and Cloud Integration

The capability to extend across the entire data centre is one of the most significant benefits of
SDN. This type of agility integrates distributed cloud, locations and the organization as a whole.
SDN also allows for critical network traffic to pass between various locations irrespective of the
type of underlying network architecture. You also permit easier movement of data between cloud
locations and data centre by abstracting critical network controls. You can utilise powerful APIs
to not only integrate with a cloud provider, but you can also control specific network services as
well because SDN is a form of network virtualization. While keeping your business agile, this
allows you to manage your workloads granularly.

SDN applications are being used by organizations for a lot of the functions; however, these were
few of the main features to consider. You should understand how SDN applications can
positively impact your business and your data centre. SDN fundamentally simplifies the entire
networking layer and provides you granular control over your distributed data centre ecosystem,
services, and applications.
Also, SDN helps you to design a business capable of adjusting to changes in the industry and
market shifts. This also allows your organization to be truly productive and agile.

UNIT - 2 SDN DATA PLANE AND CONTROL PLANE

2.1 Data Plane functions and protocols

2.1.1 SDN Data Plane

The SDN data plane, referred to as the resource layer in ITU-T Y.3300 and also often referred to
as the infrastructure layer, is where network forwarding devices perform the transport and
processing of data according to decisions made by the SDN control plane. The important
characteristic of the network devices in an SDN network is that these devices perform a simple
forwarding function, without embedded software to make autonomous decisions.

2.1.2 Data Plane Functions

Figure 4.2 illustrates the functions performed by the data plane network devices (also called data
plane network elements or switches). The principal functions of the network device are the
following:
FIGURE 4.2 Data Plane Network Device

Control support function: Interacts with the SDN control layer to support programmability
via resource-control interfaces. The switch communicates with the controller and the controller
manages the switch via the OpenFlow switch protocol.

Data forwarding function: Accepts incoming data flows from other network devices and end
systems and forwards them along the data forwarding paths that have been computed and
established according to the rules defined by the SDN applications.

These forwarding rules used by the network device are embodied in forwarding tables that
indicate for given categories of packets what the next hop in the route should be. In addition to
simple forwarding of a packet, the network device can alter the packet header before forwarding,
or discard the packet. As shown, arriving packets may be placed in an input queue, awaiting
processing by the network device, and forwarded packets are generally placed in an output queue,
awaiting transmission.

The network device in Figure 4.2 is shown with three I/O ports: one providing control
communication with an SDN controller, and two for the input and output of data packets. This is
a simple example. The network device may have multiple ports to communicate with multiple
SDN controllers, and may have more than two I/O ports for packet flows into and out of the
device.
2.1.3 Data Plane Protocols

Figure 4.2 suggests the protocols supported by the network device. Data packet flows consist of
streams of IP packets. It may be necessary for the forwarding table to define entries based on
fields in upper-level protocol headers, such as TCP, UDP, or some other transport or application
protocol. The network device examines the IP header and possibly other headers in each packet
and makes a forwarding decision.

The other important flow of traffic is via the southbound application programming interface
(API), consisting of OpenFlow protocol data units (PDUs) or some similar southbound API
protocol traffic.

2.2 OpenFlow Protocol

The OpenFlow protocol describes message exchanges that take place between an OpenFlow
controller and an OpenFlow switch. Typically, the protocol is implemented on top of TLS,
providing a secure OpenFlow channel.
The OpenFlow protocol enables the controller to perform add, update, and delete actions to the
flow entries in the flow tables. It supports three types of messages (see Table 4.2):
 Controller to switch: These messages are initiated by the controller and, in some cases, require
a response from the switch. This class of messages enables the controller to manage the logical
state of the switch, including its configuration and details of flow and group table entries. Also
included in this class is the Packet-out message. This message is sent by the controller to a switch
when that switch sends a packet to the controller and the controller decides not to drop the packet
but to direct it to a switch output port.
Asynchronous: These types of messages are sent without solicitation from the controller. This
class includes various status messages to the controller. Also included is the Packet-in message,
which may be used by the switch to send a packet to the controller when there is no flow table
match.
Symmetric: These messages are sent without solicitation from either the controller or the
switch. They are simple yet helpful. Hello messages are typically sent back and forth between the
controller and switch when the connection is first established. Echo request and reply messages
can be used by either the switch or controller to measure the latency or bandwidth of a controller-
switch connection or just verify that the device is up and running. The Experimenter message is
used to stage features to be built in to future versions of OpenFlow.
In general terms, the OpenFlow protocol provides the SDN controller with three types of
information to be used in managing the network:
Event-based messages: Sent by the switch to the controller when a link or port change occurs.
Flow statistics: Generated by the switch based on traffic flow. This information enables the
controller to monitor traffic, reconfigure the network as needed, and adjust flow parameters to
meet QoS requirements.
Encapsulated packets: Sent by the switch to the controller either because there is an explicit
action to send this packet in a flow table entry or because the switch needs information for
establishing a new flow.
The OpenFlow protocol enables the controller to manage the logical structure of a switch, without
regard to the details of how the switch implements the OpenFlow logical architecture.

2.3 Flow table

In Software-Defined Networking (SDN), the "Flow Table" plays a crucial role in the data plane
of network devices, particularly in switches. The Flow Table is where rules for packet forwarding
are stored and processed. Let's delve into the specifics:

1. Functionality: The Flow Table is a fundamental component of SDN switches. It's akin to a
database where rules, known as flow entries, are stored. Each flow entry consists of match fields
and corresponding actions.

2. Match Fields: These fields define the characteristics of packets that the switch will examine to
determine whether they match a particular flow entry. Common match fields include source and
destination addresses, ports, VLAN tags, and packet header information (e.g., IP protocol,
TCP/UDP ports).

3. Actions: Once a packet matches a flow entry, the switch executes specific actions associated
with that entry. Actions can include forwarding the packet out a particular port, dropping the
packet, modifying packet headers, or sending the packet to the controller for further processing.

4. Priority and Wildcard Entries: Flow entries in the table have priorities assigned to them.
When a packet matches multiple flow entries, the entry with the highest priority is selected.
Additionally, wildcard entries can match multiple packets based on common criteria, simplifying
rule management.

5. Flow Table Lookup: When a packet arrives at the switch, it is compared against the flow
entries in the table using the match fields. This process is known as a flow table lookup. If a
match is found, the corresponding actions are executed. If no match is found (a table miss), the
packet is often forwarded to the controller for further handling.

6. Flow Table Management: The SDN controller is responsible for managing the flow table
entries. It can dynamically add, modify, or remove entries based on network conditions, policies,
or events. This dynamic control allows for flexible and programmable packet forwarding
behavior.

7. Flow Table Capacity: The capacity of the flow table varies depending on the capabilities of
the switch hardware and the SDN controller's software. Larger capacity allows for more complex
forwarding behavior and support for a greater number of concurrent flows.

8. Flow Table Aging and Eviction: Flow entries may have a limited lifetime, after which they
are removed from the table. This process, known as aging, helps manage resource usage and
ensures that the flow table remains up-to-date. Entries may also be evicted to make room for new
entries when the table reaches its capacity.

9. Performance Considerations: Efficient flow table lookup is crucial for maintaining network
performance. Switches employ various techniques, such as caching and hardware acceleration, to
optimize lookup speed and reduce latency.

10. Security and Policy Enforcement: The flow table is a central point for enforcing network
security policies. By carefully configuring flow entries, administrators can control traffic flows,
implement access control policies, and mitigate security threats.

In summary, the Flow Table is a critical component of SDN switches, facilitating flexible and
programmable packet forwarding based on predefined rules. Its management and optimization are
key considerations for achieving efficient and secure network operation in SDN environments.

2.3.2 Flow Table Structure

 Match fields: Used to select packets that match the values in the fields.

Priority: Relative priority of table entries. This is a 16-bit field with 0 corresponding to the
lowest priority. In principle, there could be 216 = 64k priority levels.
 Counters: Updated for matching packets. The OpenFlow specification defines a variety of
counters. Table 4.1 lists the counters that must be supported by an OpenFlow switch.

Instructions: Instructions to be performed if a match occurs.

Timeouts: Maximum amount of idle time before a flow is expired by the switch. Each flow
entry has an idle_timeout and a hard_timeout associated with it. A nonzero hard_timeout field
causes the flow entry to be removed after the given number of seconds, regardless of how many
packets it has matched. A nonzero idle_timeout field causes the flow entry to be removed when it
has matched no packets in the given number of seconds.
Cookie: 64-bit opaque data value chosen by the controller. May be used by the controller to
filter flow statistics, flow modification and flow deletion; not used when processing packets.
Flags: Flags alter the way flow entries are managed; for example, the flag
OFPFF_SEND_FLOW_REM triggers flow removed messages for that flow entry.
Match Fields Component
The match fields component of a table entry consists of the following required fields (see part b
of Figure 4.5):
Ingress port: The identifier of the port on this switch on which the packet arrived. This may be
a physical port or a switch-defined virtual port. Required in ingress tables.
Egress port: The identifier of the egress port from action set. Required in egress tables.
Ethernet source and destination addresses: Each entry can be an exact address, a bitmasked
value for which only some of the address bits are checked, or a wildcard value (match any value).
Ethernet type field: Indicates type of the Ethernet packet payload.
IP: Version 4 or 6.
IPv4 or IPv6 source address, and destination address: Each entry can be an exact address, a
bitmasked value, a subnet mask value, or a wildcard value.
TCP source and destination ports: Exact match or wildcard value.
UDP source and destination ports: Exact match or wildcard value.
The preceding match fields must be supported by any OpenFlow-compliant switch. The
following fields may be optionally supported.
Physical port: Used to designate underlying physical port when packet is received on a logical
port.
Metadata: Additional information that can be passed from one table to another during the
processing of a packet. Its use is discussed subsequently.
VLAN ID and VLAN user priority: Fields in the IEEE 802.1Q virtual LAN header. SDN
support for VLANs is discussed in Chapter 8, “NFV Functionality.”
IPv4 or IPv6 DS and ECN: Differentiated Services and Explicit Congestion Notification
fields.
SCTP source and destination ports: Exact match or wildcard value for Stream Transmission
Control Protocol.
ICMP type and code fields: Exact match or wildcard value.
ARP opcode: Exact match in Ethernet Type field.
Source and target IPv4 addresses in ARP payload: Can be an exact address, a bitmasked
value, a subnet mask value, or a wildcard value.
IPv6 flow label: Exact match or wildcard.
ICMPv6 type and code fields: Exact match or wildcard value.
IPv6 neighbor discovery target address: In an IPv6 Neighbor Discovery message.
IPv6 neighbor discovery source and target addresses: Link-layer address options in an IPv6
Neighbor Discovery message.
MPLS label value, traffic class, and BoS: Fields in the top label of an MPLS label stack.
Provider bridge traffic ISID: Service instance identifier.
Tunnel ID: Metadata associated with a logical port.
TCP flags: Flag bits in the TCP header. May be used to detect start and end of TCP
connections.
IPv6 extension: Extension header.
Thus, OpenFlow can be used with network traffic involving a variety of protocols and network
services. Note that at the MAC/link layer, only Ethernet is supported. Therefore, OpenFlow as
currently defined cannot control Layer 2 traffic over wireless networks.
Each of the fields in the match fields component either has a specific value or a wildcard value,
which matches any value in the corresponding packet header field. A flow table may include a
table-miss flow entry, which wildcards all match fields (every field is a match regardless of
value) and has the lowest priority.
We can now offer a more precise definition of the term flow. From the point of view of an
individual switch, a flow is a sequence of packets that matches a specific entry in a flow table.
The definition is packet oriented, in the sense that it is a function of the values of header fields of
the packets that constitute the flow, and not a function of the path they follow through the
network. A combination of flow entries on multiple switches defines a flow that is bound to a
specific path.

2.3.3 Flow Table Pipeline

A switch includes one or more flow tables. If there is more than one flow table, they are
organized as a pipeline, with the tables labeled with increasing numbers starting with zero. The
use of multiple tables in a pipeline, rather than a single flow table, provides the SDN controller
with considerable flexibility.

The OpenFlow specification defines two stages of processing:

Ingress processing: Ingress processing always happens, beginning with Table 0, and uses the
identity of the input port. Table 0 may be the only table, in which case the ingress processing is
simplified to the processing performed on that single table, and there is no egress processing.
Egress processing: Egress processing is the processing that happens after the determination of
the output port. It happens in the context of the output port. This stage is optional. If it occurs, it
may involve one or more tables. The separation of the two stages is indicated by the numerical
identifier of the first egress table. All tables with a number lower than the first egress table must
be used as ingress tables, and no table with a number higher than or equal to the first egress table
can be used as an ingress table.
Pipeline processing always starts with ingress processing at the first flow table; the packet must
be first matched against flow entries of flow Table 0. Other ingress flow tables may be used
depending on the outcome of the match in the first table. If the outcome of ingress processing is
to forward the packet to an output port, the OpenFlow switch may perform egress processing in
the context of that output port.
When a packet is presented to a table for matching, the input consists of the packet, the identity of
the ingress port, the associated metadata value, and the associated action set. For Table 0, the
metadata value is blank and the action set is null. At each table, processing proceeds as follows
(see Figure 4.6):
FIGURE 4.6 Simplified Flowchart Detailing Packet Flow Through an OpenFlow Switch

1. If there is a match on one or more entries, other than the table-miss entry, the match is defined
to be with the highest-priority matching entry. As mentioned in the preceding discussion, the
priority is a component of a table entry and is set via OpenFlow; the priority is determined by the
user or application invoking OpenFlow. The following steps may then be performed:

a. Update any counters associated with this entry.

b. Execute any instructions associated with this entry. This may include updating the action set,
updating the metadata value, and performing actions.
c. The packet is then forwarded to a flow table further down the pipeline, to the group table, to
the meter table, or directed to an output port.
2. If there is a match only on a table-miss entry, the table entry may contain instructions, as with
any other entry. In practice, the table-miss entry specifies one of three actions:
a. Send packet to controller. This will enable the controller to define a new flow for this and
similar packets, or decide to drop the packet.
b. Direct packet to another flow table farther down the pipeline.
c. Drop the packet.
3. If there is no match on any entry and there is no table-miss entry, the packet is dropped.
For the final table in the pipeline, forwarding to another flow table is not an option. If and when a
packet is finally directed to an output port, the accumulated action set is executed and then the
packet is queued for output. Figure 4.7 illustrates the overall ingress pipeline process.
FIGURE 4.7 Packet Flow Through an OpenFlow Switch: Ingress Processing

If egress processing is associated with a particular output port, then after a packet is directed to an
output port at the completion of the ingress processing, the packet is directed to the first flow
table of the egress pipeline. Egress pipeline processing proceeds in the same fashion as for
ingress processing, except that there is no group table processing at the end of the egress pipeline.
Egress processing is shown in Figure 4.8.
FIGURE 4.8 Packet Flow Through OpenFlow Switch: Egress Processing

2.4 Control Plane Functions

Figure 5.2 illustrates the functions performed by SDN controllers. The figure illustrates the
essential functions that any controller should provide, as suggested in a paper by Kreutz
[KREU15], which include the following:
FIGURE 5.2 SDN Control Plane Functions and Interfaces
Shortest path forwarding: Uses routing information collected from switches to establish
preferred routes.
Notification manager: Receives, processes, and forwards to an application events, such as
alarm notifications, security alarms, and state changes.
Security mechanisms: Provides isolation and security enforcement between applications and
services.
Topology manager: Builds and maintains switch interconnection topology information.
Statistics manager: Collects data on traffic through the switches.
Device manager: Configures switch parameters and attributes and manages flow tables.
The functionality provided by the SDN controller can be viewed as a network operating system
(NOS). As with a conventional OS, an NOS provides essential services, common application
programming interfaces (APIs), and an abstraction of lower-layer elements to developers. The
functions of an SDN NOS, such as those in the preceding list, enable developers to define
network policies and manage networks without concern for the details of the network device
characteristics, which may be heterogeneous and dynamic. The northbound interface, discussed
subsequently, provides a uniform means for application developers and network managers to
access SDN service and perform network management tasks. Further, well-defined northbound
interfaces enable developers to create software that is independent not only of data plane details
but to a great extent usable with a variety of SDN controller servers.
A number of different initiatives, both commercial and open source, have resulted in SDN
controller implementations. The following list describes a few prominent ones:
OpenDaylight: An open source platform for network programmability to enable SDN, written
in Java. OpenDaylight was founded by Cisco and IBM, and its membership is heavily weighted
toward network vendors. OpenDaylight can be implemented as a single centralized controller, but
enables controllers to be distributed where one or multiple instances may run on one or more
clustered servers in the network.

Open Network Operating System (ONOS): An open source SDN NOS, initially released in
2014. It is a nonprofit effort funded and developed by a number of carriers, such as AT&T and
NTT, and other service providers. Significantly, ONOS is supported by the Open Networking
Foundation, making it likely that ONOS will be a major factor in SDN deployment. ONOS is
designed to be used as a distributed controller and provides abstractions for partitioning and
distributing network state onto multiple distributed controllers.
POX: An open source OpenFlow controller that has been implemented by a number of SDN
developers and engineers. POX has a well written API and documentation. It also provides a
web-based graphical user interface (GUI) and is written in Python, which typically shortens its
experimental and developmental cycles compared to some other implementation languages, such
as C++.
Beacon: An open source package developed at Stanford. Written in Java and highly integrated
into the Eclipse integrated development environment (IDE). Beacon was the first controller that
made it possible for beginner programmers to work with and create a working SDN environment.
Floodlight: An open source package developed by Big Switch Networks. Although its
beginning was based on Beacon, it was built using Apache Ant, which is a very popular software
build tool that makes the development of Floodlight easier and more flexible. Floodlight has an
active community and has a large number of features that can be added to create a system that
best meets the requirements of a specific organization. Both a web-based and Java-based GUI are
available and most of its functionality is exposed through a REST API.
Ryu: An open source component-based SDN framework developed by NTT Labs. It is open
sourced and fully developed in python.
Onix: Another distributed controller, jointly developed by VMWare, Google, and NTT. Onix is
a commercially available SDN controller.

2.5 Southbound Interface

The southbound interface provides the logical connection between the SDN controller and the
data plane switches (see Figure 5.3). Some controller products and configurations support only a
single southbound protocol. A more flexible approach is the use of a southbound abstraction layer
that provides a common interface for the control plane functions while supporting multiple
southbound APIs.
FIGURE 5.3 SDN Controller Interfaces
The most commonly implemented southbound API is OpenFlow, covered in some detail in
Chapter 4, “SDN Data Plane and OpenFlow.” Other southbound interfaces include the following:
Open vSwitch Database Management Protocol (OVSDB): Open vSwitch (OVS) an open
source software project which implements virtual switching that is interoperable with almost all
popular hypervisors. OVS uses OpenFlow for message forwarding in the control plane for both
virtual and physical ports. OVSDB is the protocol used to manage and configure OVS instances.
Forwarding and Control Element Separation (ForCES): An IETF effort that standardizes
the interface between the control plane and the data plane for IP routers.
Protocol Oblivious Forwarding (POF): This is advertised as an enhancement to OpenFlow
that simplifies the logic in the data plane to a very generic forwarding element that need not
understand the protocol data unit (PDU) format in terms of fields at various protocol levels.
Rather, matching is done by means of (offset, length) blocks within a packet. Intelligence about
packet format resides at the control plane level.

2.6 Northbound Interface

The northbound interface enables applications to access control plane functions and services
without needing to know the details of the underlying network switches. The northbound
interface is more typically viewed as a software API rather than a protocol.
Unlike the southbound and eastbound/westbound interfaces, where a number of heterogeneous
interfaces have been defined, there is no widely accepted standard for the northbound interface.
The result has been that a number of unique APIs have been developed for various controllers,
complicating the effort to develop SDN applications. To address this issue the Open Networking
Foundation formed the Northbound Interface Working Group (NBI-WG) in 2013, with the
objective of defining and standardizing a number of broadly useful northbound APIs. As of this
writing, the working group has not issued any standards.
A useful insight of the NBI-WG is that even in an individual SDN controller instance, APIs are
needed at different “latitudes.” That is, some APIs may be “further north” than others, and access
to one, several, or all of these different APIs could be a requirement for a given application.
Figure 5.4, from the NBI-WG charter document (October 2013), illustrates the concept of
multiple API latitudes. For example, an application may need one or more APIs that directly
expose the functionality of the controller, to manage a network domain, and use APIs that invoke
analytic or reporting services residing on the controller.
FIGURE 5.4 Latitude of Northbound Interfaces
Figure 5.5 shows a simplified example of an architecture with multiple levels of northbound
APIs, the levels of which are described in the list that follows.
FIGURE 5.5 SDN Controller APIs

Base controller function APIs: These APIs expose the basic functions of the controller and
are used by developers to create network services.
Network service APIs: These APIs expose network services to the north.
Northbound interface application APIs: These APIs expose application-related services that
are built on top of network services.