SDN - A New Networking Era

Mohamed Nidhal Beyrem Jaziri, 2xCCIE #38232 (R&S , SP)
SDN : A New Networking Era

By Mohamed Nidhal Beyrem Jaziri, 2xCCIE (R&S , SP)
23 June , 2014, Tunis, Tunisia
Contents at a Glance
1 - SDN Definition
2 - SDN Benefits
2.1 - Benefits to the IT organization
2.1.1 - Flexibility and Scalability
2.1.2 - Granular Control
2.1.3 - Costs Reduction
2.2 - Benefits to the Networking industry
3 - SDN Criticism
4 - SDN Components
4.1 - SDN Controller
4.2 - SDN Application
4.3 - OpenFlow
4.3.1 - Controller-to-Switch
4.3.2 - Asynchronous
4.3.3 - Symmetric
4.4 - OpenFlow Switches
4.5 - SDN Controller Roles
4.5.1 - Equal Role
4.5.2 - Slave Role
4.5.3 - Master Role
4.5.4 - NoChange Role
5 - SDN Domains
6 - SDN Myths
7 - Conclusion

SDN : A New Networking Era
1 - SDN Defintion
Software-Defined Networking, abbreviated as SDN, is a form of

Networking in which the Control Plane of a whole Network is generated
by a single Element, called the SDN Controller, whereas the Data
plane of that same Network is executed by the other Elements.
To understand the above definition, other definitions must be made

first :
A Packet[H] is a formatted unit of data. Example of Packets : IP
Packets.
A Device is an electronic machine that sends and receives Packets.
Example of Devices : PC, Router, Switch, Firewall...
An Element[H] is a set of Devices, not necessarily interconnected,
that possess exactly the same characteristics.
A Network[H] is a set of interconnected Devices.
Networking is a set of methods used to manage a Network.
A Protocol[H] is a set of rules.
The Control Plane[H] of a Network is generated by the set of Protocols
that are running in that same Network.
The Data Plane[H] of a Network is the set of actions applied to
Packets as they pass through that same Network. The Data Plane is the
end result of the Control Plane. The Data Plane is also called the
Forwarding Plane.
Note : The terms defined above will be repeatedly emphasized with a

bold font throughout this article.
In the traditional form of Networking, each Device is running a set of

Protocols that generate what is called the "Control Plane" of that
Device. To clarify the concept of Control Plane let's consider a switch
that runs multiple Protocols at the same time, for example Spanning-
Tree Protocol (STP), Protocol Independent Multicast (PIM), and Open
Shortest Path First (OSPF). These 3 Protocols, in addition to other
probable Protocols, generate the Control Plane of that switch.
Packets that pass through, or are generated from, that switch will be
treated according to its generated Control Plane. The manner with which
these Packets are treated is called the Data Plane. Therefore, the Data

Plane can be considered as an end result of the Control Plane.
In the traditional form of Networking, or Traditional Networking, each

Device operates autonomously, which means that each Device generates
its own local Control Plane, and then executes its own local Data Plane
actions.
Figure 1 : Traditional Networking
SDN introduces a new form of Networking in which the whole Network is

managed by a single Control Plane rather than being managed by multiple
Control Planes. The mentioned single Control Plane covers the whole
Network.
To obtain Software-Defined Networking (SDN), we "delegate" the Control

Plane of all Network's Devices to a single Element called : SDN
Controller.
After being provisioned with a Control Plane, the SDN Controller

"pushes" Network-wide Data Plane actions to all Devices belonging to
the Network, to execute them (actions) on subsequent traffic. In this
form of Networking, the Network can be perceived as a single, logical
Device.
The table below summarizes the differences between Traditional

Networking and Software-Defined Networking :
Traditional Networking Software-Defined Networking

Each Device has a Yes, each Device generates No, only the SDN Controller
Control Plane ? its own local Control Plane. generates a Control Plane.
Each Device executes Yes, each Device executes its Yes, each Device executes Data
Data Plane actions ? own local Data Plane actions. Plane actions "pushed" from
the SDN Controller.

Figure 2 : Software-Defined Networking
Some authors consider that SDN "separates", or "decouples", or

"abstracts" the Networks Control Plane (Network's "brain") from the
Networks Data Plane (Network's "muscles"). They also consider that the
Network is defined by the software running on the SDN Controller, and
hence the appellation : Software-Defined Networking. However, other
authors criticize the use of the expression "Software-Defined" because
Networking has always been software defined given that hardware cannot
do anything without software.
A compromise between the 2 viewpoints may consider that "Software-

Defined" is meaning that fundamental software is centralized in a
single Element of the Network rather than being distributed over
multiple Devices, thus the expression "Software-Centralized" may be
more accurate.
Centralization is the core of SDN, in effect the continuous expansion

of today's Networks makes it challenging to be able to control
hundreds, and sometimes thousands, of different Devices. SDN permits to
centralize the Control Plane of a whole Network in a single Element :
the SDN Controller. The centralized SDN Controller is responsible for
instructing "subordinate" Devices on how to forward trafic, instead of
each Device taking its own forwarding decisions.
A Flow is a number of Packets that possess a set of similar characteristics.
The Network flows are controlled at the level of the whole Network,
rather than at the level of individual Devices. Therefore, SDN
transforms a distributed Control Plane to a centralized one.

2 - SDN Benefits
SDN brings benefits to the IT organization, and to the Networking
industry as a whole.
2.1 - Benefits to the IT organization

2.1.1 - Flexibility and Scalability
Network administrators can write SDN programs by themselves instead

of waiting for new features to be added to vendors's proprietary and
closed software. In fact, SDN architectures support a set of APIs [H]
that make it possible to add Network applications like : routing,
multicast, security, access control, bandwidth management, Traffic
Engineering, Quality of Service, processor and storage optimization,
energy usage, etc... Network administrators can customize these Network
applications to rapidly adapt to new business objectives. With SDN, IT
organizations gain vendor-independent control over the entire Network.
Scalability : SDN reduces the time needed to deploy new Devices and
applications.
Note : A distinction must be made between flexibilty and scalability.

Flexibilty is a reaction to an internal or external event, wheras
scalability is a self-motivation action.
2.1.2 - Granular Control
SDN Controller provides a Network-wide visibility for Network

administrators, which results in 2 advantages :
1 - Real-time statistics about the traffic flows that are traversing
the global Network at a given period. This permits to distinguish
between critical and non-critical flows.
2 - After building a deep understanding of the Network flows,
administrators can implement Network-wide, and consistent policies by
dynamically allocating more Network resources to higher-priority flows.
Network-wide visibility makes Networks consistent, possessing optimum
routing, programmable, dynamic, application-aware, less vulnerable to
security breaches, more compliant with regulations.
2.1.3 - Costs Reduction
SDN conserves Network resources, like CPU and memory, given that
Protocols need to run only on the SDN Controller and not in every
Device. This is especially helpful in cloud computing in which the
conservation of Network resources is an important objective.
SDN reduces Networking costs[H][H][H] thanks to 2 factors :
1 - Automation of operations.
2 - Cheaper hardware can be interconnected with a powerful SDN
Controller to create a sophisticated infrastructure that would be

costly if we used more expensive hardware instead.
SDN reduces administrative tasks because new configurations are added
to the SDN Controller rather than being added to multiple Devices
distributed over different places. This is especially helpful in a
cloud computing, multi-tenant[H] architecture.
2.2 - Benefits to the Networking industry
SDN reduces dependency on slowly evolving vendors's software. In

Fact, vendors's software evolve in a cycle of 3 years on average, which
constitutes an unacceptable long period for today's rapidly changing
Networks.
SDN expands the community that writes Networks's softwares, which was
closed to a small number of vendors in the past. In fact, SDN enables a
larger population of researchers and developers to accelerate the
enrichment of Networking sciences by bringing their ideas and
innovations to life.
3 - SDN Criticism
Compatibility issues : An SDN Controller communicates with SDN
Applications, these applications are written to a set of APIs that are
provided by the SDN controller. Generally, APIs are not standardized,
so an SDN Application that runs on a given SDN controller may have to
be modified to run on another SDN controller[H].
Figure 3 : SDN Applications
The deployment of an SDN solution is disruptive to a Network already

in production, and can engender problems if it is not correctly
implemented.
SDN requires bringing together Networking and programming skills,
which is not a common thing among IT professionals.
SDN solutions from different vendors can trigger support-related
problems.
Security : Malicious Devices introduced in the Network can
impersonate an SDN Controller, they can also eavesdrop Network traffic.
FRESCO[H][H] and FORTNOX[H][H] are platforms develped by openflowsec.org to
mitigate SDN security issues.

4 - SDN Components
4.1 - SDN Controller
An SDN Controller is a software that generates the Control Plane of a

given Network.
The SDN Controller works in 3 consecutive steps :

1 - It receives instructions from SDN Applications through Northbound
APIs.
2 - It generates a Network-wide Control Plane.
3 - It pushes Data Plane actions to Network Devices using an SDN
Protocol, like for example OpenFlow.
Figure 4 : Software-Defined Networking Architecture [H]
opennetworking.org
The SDN Controller is a programmatic interface that permits to remotely

control Network Devices. An SDN Controller can be deployed on a
commodity hardware[H]. It can be considered as the Operating System (OS)
of the Network.
SDN Controllers need an SDN Protocol to be able to communicate with

Network Devices. The most adopted SDN Protocol in today's Networks is
OpenFlow[H][H].
While it is possible to implement SDN with a single SDN Controller,

vendors such as Big Switch Networks have developed an SDN Controller,
named Big Network Controller[H], that can work in cluster to provide
high availability.
SDN Controller placement
It may be advantageous to use more than 1 SDN Controller in the same

Network to achieve redundancy and high availability. The SDN
Controller must also be placed in an appropriate position in the
Network to reduce Control Plane latency.

SDN Controllers receive instructions from SDN Applications via
Northbound APIs, and send another instructions to "below" Devices via
Southbound APIs. Southbound APIs work in parallel with SDN Protocols
(like for example OpenFlow).
Figure 5 : Northbound APIs and Southbound APIs [H]
necam.com/
Example of SDN Controllers[H] :
SDN Controller Language SDN Controller Language

POX Python Maestro Java
NOX C++ NodeFlow JavaScript
Beacon Java IRIS Java
Floodlight Java Jaxon Java
NOX[H] is the first developed SDN Controller. NOX was initially

developed by Nicira Networks, in parallel with OpenFlow [H].
POX[H] is NOX's younger sibling as described by NOXRepo.org, the
online community maintaining and expanding both NOX and POX.
Beacon[H] is one of the most popular SDN Controllers. Started in 2010,
Beacon is a Java-based SDN Controller.
Floodlight[H] is an Apache-licensed and Java-based SDN Controller.
Floodlight derived from Beacon.
OpenDaylight[H] is a Java-based SDN Controller derived from Beacon.
OpenDaylight supports advanced features such as high-availability and
clustering.
The floodlight project is created by Big Switch Networks.

The OpenDaylight project is an Open Source project created by Linux
Foundation on April 2013. The goal of the project is to accelerate
the adoption of SDN solutions and Network Functions Virtualization
(NFV).
FlowVisor[H][H], which is a Network "slicer" that allows multiple

tenants to share the same physical infrastructure. A tenant can be a
customer requiring his own isolated Network "slice", a sub-organization
that needs its own slice, or an experimenter who wants to control and
manage some specific traffic. Slices can be defined by any combination

of switch ports (Layer 1), source/destination MAC addresses (Layer 2),
source/destination IP addresses (Layer 3), and source/destination
TCP/UDP ports or ICMP codes/types (Layer 4).
Figure 6 : Network Slicing Example [H]
nexusis.com
4.2 - SDN Application
An SDN Application is a software that operates at the Layer 7 of the

OSI model, and that adds functionalities to an SDN-enabled Network.
An SDN Application can be a virtual load balancer, a virtual Intrusion

Detection System (IDS), a virtual load balancer, etc... An SDN
Application can also tap[H] into the informations collected by the SDN
Controller to take consequent actions. For example, a virtual load
balancer can distribute traffic over multiple Devices by tapping into
the SDN Controller statistics. In another example, a virtual IDS
application can instruct an SDN Controller to intercept malware traffic
and drop it. The SDN Controller will, in turn, push Data Plane actions
to its subordinate Devices to enforce the virtual IDS instructions [H].
Figure 7 : SDN Applications[H]
bigswitch.com

HP has opened the first SDN App store in the world [H]. The App Store
allows customers to browse, purchase, and download SDN Applications[H].
HP App store provides also a Java-based SDN SDK to help programmers
develop their own SDN Applications[H]. SDN Applications from HP can be
found in this page.
4.3 - OpenFlow
OpenFlow is an Open Source Protocol used by SDN Controllers to

communicate with Network Devices.
OpenFlow exploits the fact that most Ethernet switches and routers
possess Flow Tables, such as TCAM[H], that run at line-rate[H]. Although
there are differences between vendorss Flow Tables, there is at the
same time a common set of functions : OpenFlow exploits this common set
of functions.
Figure 8 : OpenFlow Logo[H]
opennetworking.org
The OpenFlow Protocol was developed at Stanford University [H]. The first
Version 1.0 was published on December 31, 2009 [H]. The current Version
is 1.4[H] (as of June 23, 2014).
In March 2011, the Open Networking Foundation (ONF) was created and the
intellectual property rights of OpenFlow were transitioned to it [H]. The
ONF was tasked at this time with the development and marketing of
OpenFlow. ONF defines itself as "a user-driven organization dedicated
to the promotion and adoption of Software-Defined Networking (SDN)
through the development of Open Standards [H]".
OpenFlow is not the only available SDN Protocol, there are other
alternatives such as : Extensible Messaging and Presence Protocol
(XMPP)[H], Network Configuration Protocol (Netcong) [H], and OpenStack[H]
from Rackspace and NASA.
A number of vendors are marketing OpenFlow-enabled products, including

Alcatel-Lucent, Brocade Communications, Cisco, Dell Force10, IBM,
Juniper Networks, Hewlett-Packard, and NEC. A comprehensive list of
products supporting OpenFlow can be found on the ONF [H] and SDN
Central[H] websites.
OpenFlow supports 3 message types : Controller-to-Switch, Asynchronous,

and Symmetric. Each of these message types has also sub-types. All
OpenFlow message types can be found in this link.

4.3.1 - Controller-to-Switch
Controller-to-Switch messages are initiated by the SDN Controller and

used to manage, or inspect, the state of an OpenFlow Switch. They may,
or may not, require a response from the OpenFlow Switch. The 6
principal Controller-to-Switch message types are described below :
1 - Features : Upon TLS session establishment, the SDN Controller
requests the identity and basic features of the OpenFlow Switch by
sending a Features Request message. The OpenFlow Switch must respond
with a Features Reply that specifies its identity and its features.
2 - Configuration : These are messages sent by the SDN Controller to
set and query configuration parameters from the OpenFlow Switch.
3 - Modify-State : These are messages sent by the SDN Controller to
manage the state of an OpenFlow Switch. Their primary purpose is to
add, delete and modify Flow Entries in the Flow Table, and to set
switch ports's properties.
4 - Read-State : These are messages sent by the SDN Controller to
collect statistics from the Flow Table and switch ports of an OpenFlow
Switch.
5 - Packet-Out : These are messages sent by the SDN Controller to the
OpenFlow Switch to instruct it to send Packets out of a specified port.
6 - Role-Request : An OpenFlow Switch can be managed by multiple SDN
Controllers at the same time, in this case each SDN Controller must
have a role relatively to the OpenFlow Switch. The Role-Request message
is sent by the SDN Controller to the OpenFlow Switch to set or query
its role. SDN Controller roles will be defined later.
4.3.2 - Asynchronous
Asynchronous messages are initiated by the OpenFlow Switch, and used to

inform the SDN Controller about changes that affected the Network as a
whole, or the OpenFlow Switch particularly. Asynchronous messages are
sent without solicitation from the SDN Controller. The 4 principal
Asynchronous message types are described below :
1 - Packet-In : These are messages sent to the SDN Controller when a
Packet enters the OpenFlow Switch and it doesn't have a matching Flow
Entry to handle it, or if a Packet matches a Flow Entry but the
correspondent Action is "send to controller". If the OpenFlow Switch
supports internal buffering, only fractions of Packet-in messages are
sent to the SDN Controller (by default 128 bytes of each message) and
the rest is internally buffered. Switches that do not support internal
buffering, or have run out of it, must send the full Packet-in messages
to the SDN Controller.
2 - Flow Removed : When a Flow Entry is added to the Flow Table by a
Modify-State message, an "idle timeout value" is included to indicate
when the entry should be removed due to inactivity, as well as a "hard
timeout value" that indicates when the entry should be removed
regardless of inactivity. The Modify-State message can also indicate
that the SDN Controller wishes to be informed when the mentioned Flow

Entry is removed. In this case, the OpenFlow Switch must send a Flow
Removed message that includes the duration of the Flow Entry, and the
number of Packets and bytes that were processed by it.
3 - Port-Status : These are messages sent to the SDN Controller when
the status, or state, of a given port changes. This includes change in
port status, for example when it is shutdown by a user, or change in
port state as specified by 802.1D STP.
4 - Error : These are messages sent to the SDN Controller to report
problems or errors that have occured.
4.3.3 - Symmetric
Symmetric messages are sent by either the SDN Controller or the

OpenFlow Switch, without solicitation from the other party. The 3
principal Symmetric message types are described below :
1 - Hello : These are messages sent by either the SDN Controller or the
OpenFlow Switch upon TLS session establishment.
2 - Echo : Echo Request messages are sent by either the SDN Controller
or the OpenFlow Switch, and must return an Echo Reply from the other
party. They can be used to verify the latency, bandwidth, and liveness
of the connection between an SDN Controller and an OpenFlow Switch.
3 - Experimenter : These are messages sent by either the SDN Controller
or the OpenFlow Switch to experiment new functionalities that aren't
covered by the current OpenFlow message types.
4.4 - OpenFlow Switches
An OpenFlow Switch is an ordinary Ethernet switch that possesses 3

notable components :
1 - A Flow Table (see figure 9) that is composed of Flow Entries :
a - A Header Fields that defines the flow.
b - An Action that defines how the flow's Packets should be processed.
c - Counters, which counts the number of Packets and bytes that were
processed for each flow, and the time since the last Packet matched the
flow, to help in the removal of inactive flows.
Figure 9 : Example of an OpenFlow Flow Table [H]
opennetworking.org

2 - The OpenFlow Protocol, which is used by both the the OpenFlow
Switch and SDN Controller to communicate with each other.
3 - A Secure Channel, which is an encryption Protocol, such as
Transport Layer Security (TLS) [H]. The Secure Channel ensures the
authenticity of the OpenFlow messages exchanged between an OpenFlow
Switch and an SDN Controller. In fact, when the OpenFlow Switch starts
up, it initiates a TCP connection to the SDN Controller through the
destination port 6653. These TCP Packets will then be "wrapped" by the
TLS Protocol so that the communication becomes secure. An OpenFlow
Switch and an SDN Controller may also communicate using plain TCP, i.e
unencrypted TCP.
Figure 10 : Secure Channel
In Version 0.8.9, OpenFlow Protocol was using Secure Sockets Layer

(SSL) Protocol in conjunction with TCP port 6633 (View this document,
Section 4.4). Since Version 1.4, OpenFlow Protocol started using TLS
Protocol in conjunction with TCP port 6653 (View this document,
Section 6.3.3). This TCP port number was reserved by IANA for the
OpenFlow Protocol on 18 July, 2013[H].
An OpenFlow Switch can be of "Type 0" or "Type 1". A basic OpenFlow

Switch is of Type 0 wheras Type 1 switches haven't yet been defined,
but they are expected to add more features to Type 0 switches.
Type 0 switches classify Packets into flows based on 10 characteristics

that are called : "10-tuple". The following 10 fields of a given Packet
constitute the 10-tuple :
Switch input port.
Source MAC address.
Destination MAC address.
Ethernet Type .
[H]
VLAN ID.
IP source address.
IP destination address.
IP protocol .
[H]
TCP/UDP source port.

TCP/UDP destination port.

The 10-tuple matched in a Type 0 OpenFlow Switch.
Ethernet IP TCP
Input VLAN ID
Port Source Destination EtherType Source Destination Protocol Source Destination
Address Addres Address Addres Port Port
A flow could be a TCP connection, or packets from a particular MAC address

or IP address, or packets with the same VLAN tag, or packets from the same
switch port etc...
When a Packet enters a Type 0 switch, it is matched against the 10-

tuple to be classified into the right Flow Entry in a first time, then
to be processed with the right Action in a second time. The Type 0
switch can take 3 possible Actions :
1 - Forward the Packet to a specified set of output ports. This permits
to move the Packet across the Network.
2 - Encapsulate the Packet and send it to the SDN Controller. This
Action is usually (but not always) applied to the first Packet of a new
flow.
3 - Drop the Packet. This action can be used for security reasons to
counter a Denial of Service (DoS) attack, or a broadcast discovery that
aims at scanning the Network etc...
Figure 11 shows the steps required for routing a traffic flow between 2
hosts across 2 OpenFlow Switches :
1 - A new Packet arrives. The Flow Tables of the 2 OpenFlow Switches
are empty.
2 - The Packet is forwarded to the SDN Controller.
3 - The SDN Controller examines the Packet, then pushes new Flow
Entries into the Flow Tables of the 2 switches. It also sends back the
original Packet to Switch 1.
4 - The original Packet is sent from Switch 1 to Switch 2 based on the
newly-pushed Flow Entry.
5 - The Packet is sent from Switch 2 to the end host.
6, 7, 8 - New Packets belonging to the same flow are routed directly,
at line-rate, since they are matching the newly added Flow Entries.
Figure 11 : Pushing of new Flow Entries by the SDN Controller [H]
stanford.edu

An SDN Controller can "manipulate" an OpenFlow Switch in other ways,
for example :
An SDN Controller may also push Flow Entries to multiple OpenFlow
Switches, across a Layer 2 domain, to ensure that a specific flow from
host X to host Y follows a specific path across the Network.
An SDN Controller can instruct OpenFlow Switches to redirect
suspicious flows to higher-layer security Devices, such as IDS/IPS
systems, firewalls, and Data Loss Prevention [H] (DLP) systems. It can
also instruct an OpenFlow Switch to filter Packets as they enter the
Network, and act as a firewall at the edge of that Network.
4.5 - SDN Controller Roles
An OpenFlow Switch cannot change the role of an SDN Controller on its

own, instead, the SDN Controller role is changed as a result of a
request from the controller itself.
4.5.1 - Equal Role
The default role of an SDN Controller is OFPCR_ROLE_EQUAL (OFPCR is an

abbreviation of : OpenFlow Protocol Controller Role). In this role, the
SDN Controller has full access to the OpenFlow Switch, and is "equal"
to other controllers with the same role. Also in this role, the SDN
Controller receives all the switch Asynchronous messages such as
Packet-in, Flow Removed..., and can send Controller-to-Switch messages
to modify the state of the switch. An OpenFlow Switch does not do any
arbitration or resource sharing between Equal SDN Controllers.
4.5.2 - Slave Role
An SDN Controller can request its role to be changed to

OFPCR_ROLE_SLAVE. In this role, the SDN Controller has read-only access
to the OpenFlow Switch : it cannot send any Controller-to-Switch
messages and does not receive any Asynchronous messages, apart from
Port-Status messages.
4.5.3 - Master Role
Any Equal controller or Slave controller can request its role to be

changed to OFPCR_ROLE_MASTER. This role is similar to OFPCR_ROLE_EQUAL
and has full access to the OpenFlow Switch, the difference is that the
OpenFlow Switch must ensure that only 1 SDN Controller holds the Master
role.
When an SDN Controller changes its role to Master, the OpenFlow Switch
must change any other SDN Controller that have the Master role to the
Slave role, but does not change SDN Controllers with the Equal role.
When an OpenFlow Switch changes the role of an SDN Controller from

Master to Slave, it must generate a Role-Status (View this link,
Section 7.4.4) message to this SDN Controller to inform it of its new
role. In many cases the mentioned SDN Controller is no longer
reachable, and the OpenFlow Switch may not be able to send this Role-
Status message.
A Master SDN Controller and all Equal SDN Controllers can fully change
the configuration of an OpenFlow Switch, there is no mechanism to
partition this configuration between those SDN Controllers. If an SDN
Controller in Master role needs to be the exclusive controller able to
bring changes to an OpenFlow Switch, then no controllers should be in
Equal role, and all other controllers should be put in Slave role.
An OpenFlow Switch may be simultaneously managed by multiple SDN

Controllers in Equal state, multiple controllers in Slave state, and at
most 1 controller in Master state.
4.5.4 - NoChange Role
An SDN Controller can request its role to remain unchanged by sending

an OFPCR_ROLE_NOCHANGE message to an OpenFlow Switch. This enables an
SDN Controller to query its current role without changing it.
An SDN Controller can control which types of switch Asynchronous

messages are sent to it. This is achieved by sending a Configuration
message to the OpenFlow Switch listing the message types that it
wants to receive. Using this feature, different SDN Controllers can
receive varied notifications, for example a Master SDN Controller can
disable some notifications it does not care about, whereas a Slave
SDN Controller can enable notifications for these same messages.
5 - SDN Domains
In large Networks, the use of a single SDN Controller can be
unrealistic, so an appropriate solution would be to divide the original
large Network into smaller manageable portions. Each portion will have
its own SDN implementation and thus, constitute an SDN domain.
Reasons for using SDN domains include the following [H] :

Scalability : The number of Devices that an SDN Controller can manage
is limited. Thus, a large Network may need to deploy multiple SDN
Controllers.
Privacy : An IT organization may choose to implement different
privacy policies in different SDN domains. For example, an SDN domain
may be dedicated to a set of customers who demand strict privacy
policies, requiring that Networking informations of that domain, such
as Network topology, not be disclosed to the outside world.

Figure 12 : SDN Domains[H]
cisco.com
The existence of multiple SDN domains creates a need for individual SDN
Controllers to communicate with each other, via a Protocol, to exchange
informations. The IETF is currently working on developing a Protocol,
called SDNi[H]. Border Gateway Protocol (BGP) can also be used to
interconnect SDN Controllers[H].
The communication between SDN Controllers can be implemented using the

vertical or the horizontal approach :
Vertical Approach : In the vertical approach, there is a Master SDN
Controller that manages other controllers. The Master SDN Controller
builds a global view of the whole Network by collecting informations
from each SDN domain. It can also control each SDN domain by
configuring its correspondent SDN Controller.
Horizontal Approach : In the horizontal approach, the SDN Controllers
establish peer-to-peer communications. Each SDN Controller can request
informations from its peers, which are SDN Controllers belonging to
other SDN domains. This is also called the SDN east-west interface.
6 - SDN Myths
Given that SDN is a new topic in the Networking industry, several myths
are surrounding it, some of them are :
In SDN, switches and routers will not run software : Switches and
routers will continue to run software but a less sophisticated one. For
example, the Secure Channel and OpenFlow Protocol require a software to
run.
SDN is Equal to virtualization : Network virtualization is just one
section of SDN.
SDN is a Hardware Killer because it promotes commodity hardware :
Sophisticated hardware will still be needed for heavy and critical
traffic.
SDN and OpenFlow are equivalent : OpenFlow is just an instantiation
of an SDN Protocol, however there are other Protocols as it was
previously mentioned in this document.

Figure 13 : OpenFlow is only a component of SDN [H]
cisco.com
The SDN Controller must be physically centralized in a single place

in the Network : Wide-area deployments of SDN may require that multiple
SDN Controllers be spread throughout the Network. In fact, SDN
centralizes the Control Plane of the Network and not the physical
position of the SDN Controller. We must remember that an SDN Controller
is an Element that can be composed of multiple Devices, it is not a
single Device.
In SDN, the first Packet of every trafc ow must go to the SDN
Controller for handling : Some early systems like Ethane[H] worked this
way, but in latest SDN models traffic flows can be treated proactively.
In Proactive Flow Setup[H], an SDN Controller could populate the Flow
Tables ahead of time for certain flows that could enter an OpenFlow
Switch.
SDN eliminates Network Engineers : Network Engineers are still needed
to develop SDN Applications, program SDN Controllers, etc...
SDN reduces complexity : There is always a certain degree of
complexity in any Network in the world.
7 - Conclusion
SDN technology and the SDN market are still in their early, evolving,
stages. Therefore, any IT organization that intends to implement SDN in
the near future should do it in a limited and incremental manner, such
as implementing SDN for a specific business requirement.
An IT organization can partition its Network traffic into production

and research flows. After that, research flows will have their own
paths and receive a special treatment, while production flows will
continue to be processed ordinarily. In this way, SDN researchers can
try new routing Protocols, security models, addressing schemes, and
other experiments. This Type of Networking is called Partial SDN.
In Partial SDN, experimental traffic (usually distinguished by its VLAN

ID) is processed by the Flow Table, while production traffic is
processed by the traditional Layer 2 and Layer 3 tables. This way, the
IT organization can continue to use its existing infrastructure, and at

the same time, benefit from the programmability aspects of SDN.
Partial SDN presents a low-risk approach for SDN implementation.
Panopticon[H] project constitutes an example of Partial SDN.
Interesting SDN Projects
Pica8 : http://www.pica8.com/
RouteFlow : https://sites.google.com/site/routeflow/
Open vSwitch : http://vswitch.org/
FlowScale : http://www.openflowhub.org/display/FlowScale/FlowScale+Home
ProgrammableFlow : http://www.nec.com/en/global/prod/pflow/pf1000.html

SDN - A New Networking Era

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SDN - A New Networking Era

Загружено:

Авторское право:

Доступные форматы

Mohamed Nidhal Beyrem Jaziri, 2xCCIE #38232 (R&S , SP)