this is the report for My Presentation on Software Defined Network

1. 1
1. ABSTACT
Software-Defined Networking (SDN) is an approach to computer networking that
allows network administrators to manage network services through abstraction of lower level
functionality. SDN is meant to address the fact that the static architecture of traditional
networks doesn't support the dynamic, scalable computing and storage needs of more modern
computing environments such as data centers. This is done by decoupling or disassociating the
system that makes decisions about where traffic is sent (the control plane) from the underlying
systems that forward traffic to the selected destination (the data plane). SDN was commonly
associated with the OpenFlow protocol (for remote communication with network plane
elements for the purpose of determining the path of network packets across network switches)
since the latter’s emergence in 2011. Since 2012 however, many companies have moved away
from OpenFlowas a single solution, and have embraced a number of different techniques. These
include Cisco’s Open Network Environment and Nicira’s Network virtualization platform.

2. 2
2. INTRODUCING SOFTWARE DEFINED NETWORK
SDN means, Networks are controlled by software application and SDN controller. It
removes the use of traditional network management consoles and commands.The traditional
Networking requires a lot of administrative overhead which can’t be managed on large scale.So,
the software based automated control of SDN is much more flexible than old rigid management
consoles and CLIs.It’s an open technology focusing mostly on integrations and extensions.
The following figure represents the integration of different components of a n/w using
SDN solution.
(fig. 1.1:- Integrating diffetent components of network using SDN Controller)
A comparision between Process Simpification and Cost Saving in Taditional network and
Software defined network is given below:-

3. 3
(fig.1.2:- Comparision of Different factors between Before and After SDN)
3. UNDERSTANDING THE TECHNOLOGY
The picture below shows different architectural components of SDN.
(fig.2.1 Different architectural Components of SDN)
An SDN solution basically has 3 layers. Those layers are also called as “Plane”. The three
planes of SDN are:-
1. Application Plane
2. Control Plane
3. Data Plane
Different components of SDN are:
1.SDN Applications:
SDN Applications are programs that explicitly, directly, and programmatically
communicate their network requirements and desired network behavior to the SDNController
via an orthbound interface(NBI). In addition they may consume an abstracted view of the

4. 4
network for their internal decision making purposes. An SDN Application consists of one SDN
Application Logic and one or more NBI Drivers. SDN Applications may themselves expose
another layer of abstracted network control,thus offering one or more higher-level NBIs through
respective NBI agents.
2.SDN Controller
The SDNController is alogically centralized entity in charge of (i) translating the
requirements from the SDN Application layer down to the SDN Datapaths and (ii) providing the
SDN Applications with an abstract view ofthenetwork (whichmay include statisticsand events).
An SDN Controller consists of one or more NBI Agents, the SDN Control Logic,and the Control
to Data-Plane Interface (CDPI) driver. Definition as a logically centralized entity neither
prescribes nor precludes implementation details such as the federation of multiple controllers,
the hierarchical connection of controllers,communicationinterfacesbetweencontrollers, nor
virtualization or slicing of network resources.
3.SDN Datapath
TheSDN Datapath is alogical network device that exposes visibility and uncontended
control over its advertised forwarding and data processing capabilities. The logical
representation may encompass all or a subset of the physical substrate resources. An SDN
Datapath comprises a CDPI agent and a set of one or more traffic forwarding engines and zero
or more trafficprocessing functions. These enginesand functionsmay include simple forwarding
between the datapath’sexternal interfaces orinternal traffic processing or termination functions.
One or more SDN Datapaths may be contained in a single (physical) network element—an
integrated physical combination of communications resources, managed as a unit. An SDN
Datapath may also be defined across multiple physical network elements.
4.SDN Control to Data-Plane Interface(CDPI)
The SDN CDPI is the interface defined between an SDN Controller and an SDN
Datapath, which provides at least (i) programmatic control of all forwarding operations, (ii)
capabilities advertisement, (iii) statistics reporting, and(iv) event notification. One value of
SDN lies in the expectation that the CDPI is implemented in an open, vendor-neutral and inter
operable way.
5.SDN Northbound Interfaces(NBI)
SDN NBIs are interfaces between SDN Applications and SDN Controllers and typically
provide abstract network views and enable direct expression of network behavior and
requirements. This may occur at any level of abstraction (latitude) and across different sets of

5. 5
functionality (longitude) . One value of SDN lies in the expectation that these interfaces are
implemented in an open,vendor-neutral and inter operable way.
The OpenFlow protocol is the fundamental element for building an SDN solution.
According to OpenFlow an SDN Architecture needs to be:
 Directly Programmable
 Agile
 Centrally Managed
 Programmatically Configured
 Open standard-based and vendor-neutral
4. LOOKING AT THE BENEFITS AND USE CASES OF SDN
The different benefits of SDN are:
SDN Automation Leads to Business Agility
The more agile IT becomes, the more responsive it can be to changing business and
application demands, and the more IT will be aligned with business objectives, resulting in
greater revenue opportunities and competitive advantage through IT. The agility and the
alignment of IT and business objectives are largely accomplished through vastly greater
degrees of IT process and infrastructure automation.
A new approach to network policy, which is:
✓ An easier, application-focused way of expressing policy:
By creating policies that mirror application semantics, this framework provides a
simpler, self-documenting mechanism for capturing policy requirements.
✓ Improved automation:
Grouping policies together allows higher level automation tools to easily manipulate
groups of network endpoints and applications simultaneously.

6. 6
✓ Consistency:
By grouping endpoints and applying policy to application groups, the framework offers
a consistent and concise way to handle policy changes, as well as consistency across both
physical and virtual workloads, and physical and virtual application services and security
devices.
✓ Extensible policy model:
Because the policy model is open and can be extended to other vendors and other
device types, it can easily incorporate switches, routers, security, Layer 4 through 7 services,
and so on.
Some Popular Use Cases for Deploying SDN
Some common use cases for SDN beyond general cloud, data center, and IT automation
include:
✓ DevOps:
DevOps, the synergistic integration of development and operations, is a rapidly
emerging method of developing applications for IT organizations, with the goal of accelerating
IT innovation and service delivery (coincidently, some of the same objectives as SDN). Including
an SDN technology-based approach can facilitate DevOps through the automation of
application updates and deployments and the automation of IT infrastructure components as
the DevOps applications and platforms are deployed. DevOps gives developers more control
over the IT environment, which not only implies an underlying SDN capability, but also is
facilitated by an application-centric approach to policies because DevOps is very software
application oriented.
✓ Big Data and Everything-as-a-Service:
Data is routinely collected and traded in the new economy. Big Data brings with it a new
class of data and server-intensive applications that present an enormous opportunity to make
organizations more efficient and more competitive. But systems must be in place to efficiently
and effectively harness, manage, and access it. Clouds are taking many forms – private, public,
and hybrid (and many are combined into a multicloud environment). Business processes are
changing; service industries are exploring as-a-service, online, and virtual models to accelerate
business and their engagement with customers, partners, and suppliers. SDN can help automate
and deploy these new application architectures and allow the infrastructure to adapt quickly to
the changing application requirements.

7. 7
✓ Mobility apps and the Internet of Things (IoT):
Consumer technology is reshaping technology expectations at work. A demographic
shift to mobile, and more social customers and employees will require IT to integrate with social
networks and provide expanded options for flexible workspaces and collaboration technologies.
Also, more and more things are being linked (via an Internet of Things or IoT) with a view to
further expansion into linking people, process, data, and devices (the Internet of Everything or
IoE). The changing nature of these application types and the demands for flexibility that they
place on the entire network infrastructure can be addressed by SDN solutions more easily than
prior approaches.
5. KEY CONSIDERATIONS AND REQUIREMENTS
The SDN promises a new era of centrally managed, policy based automation tools that
could accelerate network management and optimization.So, to reach those goals we need to be
aware about certain considerations and requirements, like
• Focusing on Applications
• Keeping Things Open (using open protocols, Open APIs, Open Architecture and
open source technology)
6. IMPORTANT FACTS ABOUT EVALUATING SDN SOLUTION
1.Programming Rather than Managing Manually
A modern and useful definition of SDN tells you that your networking infrastructure is
now programmable via software. This programmability is a very important change compared to
the traditional method of managing the network via command line interface or management
GUI/console. SDN programmability allows for greater flexibility, more sophisticated policies,
and more agile networks overall.
SDN doesn’t necessarily require separation of the network control plane from the data plane as
many originally defined it. Today there are a number of interrelated technologies,protocols, and
architectures that lead to policy-based automation and achieve the original vision of SDN.
2.Making for Easier Policy Implementation
The SDN programs that manage and control your infrastructure are also referred to as
your policies. They can reflect your sophisticated application, IT, or business policy objectives;

8. 8
whatever you can implement in software within the SDN framework. By implementing your
policies in software, rather than the arcane language and management tools of network devices,
your policies can more easily align with business requirements, and be much easier to maintain
and deploy. This allows SDN to be the key to policy-based automation, which drives down
complexity and operational overhead by automating many of your IT tasks while also allowing
for much greater scalability for cloud networks.
3.Supporting Multivendor Ecosystems
Another important consideration to remember is that for the SDN policy model to
automate the entire application infrastructure, a large multivendor ecosystem across a large
number of infrastructure device types must be supported by the SDN platform. You should
consider what firewalls, application delivery controllers, and other security devices are
supported by the proposed SDN architecture and standards.
This consideration also includes whether you can incorporate your existing network
infrastructure into the SDN environment when it’s deployed, or to what extent you will have to
upgrade your hardware to SDN-compliant devices.
4.Understanding the Importance of the Controller
The software policy repository that is the brains of your IT automation is generally
referred to in most SDN platforms as the controller. The controller architecture is the key to
many features of the SDN platform, how it is programmed, and what devices can be controlled.
There may be a variety of controllers and platforms to consider when selecting an SDN strategy,
so make sure you choose a controller that does everything you need. A proprietary controller or
one that supports a limited SDN policy model will limit your capabilities down the road.
5.Making Use of Cloud Automation Tools
Many of the new generation of SDN applications that reside on the northbound API of
the controller are themselves cloud automation tools, and they help to manage workflows and
tasks for cloud application deployment and infrastructure management. These tools rely on the
SDN controller to communicate and control the individual infrastructure components (switches,
servers, firewalls, and so on) according to the SDN policy and the higher level automation tools.
Some examples of cloud automation platforms that can sit on top of SDN controller northbound
interfaces are OpenStack and Cisco UCS Director.
Choose an SDN platform that gives you the greatest flexibility in cloud automation tools and
platforms rather than being locked into one vendor’s cloud stack. In addition to cloud
management tools, any SDN platform should support a number of monitoring and performance

9. 9
tools that can help analyze, troubleshoot, and automate the tuning of the applications and the
network.
6.Considering an Extensible Architecture
Because the SDN controller is the operational hub of all your integration and automation
efforts, it must be an open, extensible architecture in a number of important ways (such as an
open, flexible northbound API to host multiple applications or cloud automation tools). It must
have an open way of communicating to a multivendor IT infrastructure of switches, routers,
firewalls, application delivery controllers, and more. Make sure your SDN architecture meets all
the open requirements to successfully navigate and simplify your deployments.
OpenFlow was an early example of an open way to integrate switches from multiple
vendors to a single SDN controller, but more sophisticated protocols and devices have now been
developed for modern SDN platforms. For example, the Cisco ACI platform uses OpFlex as an
open, generic way to communicate to a wide range of vendor platforms and device types.
7.Choosing an Open Source SDN Platform Carefully
Opennessand interoperability are very important to any SDN strategy, so you don’t want
to get locked into a particular controller platform, or you may want to consider an open source
controller. This choice may provide a less expensive architecture initially, but may restrict
integration to a more narrow policy that runs across multiple infrastructure components, or may
require a lot of customization and integration for any particular cloud environment and policy
requirements.
An open SDN platform should support all major server operating systems and hypervisor
platforms including VMware, Microsoft, and Linux KVM to provide maximum coverage and
flexibility.
An important requirement when considering an open source SDN controller, such as
OpenDaylight, is the size of the vendor ecosystem that supports it, key vendors that can provide
turn-key solutions for particular environments, and an open policy model that allows for the
greatest flexibility in terms of automation and programmability. Cisco ACI has, for example,
contributed its application-centric policy model to the OpenDaylight controller project. Cisco
also supports a commercial implementation of the OpenDaylight controller for enterprise
networks as well as service providers.
7. CONCLUSION
This is a new and advanced as well as very useful technology. Not much research are
done on this field. So there are vast opportunities for Research Scholars, Network
Programmers and Cloud Application developer.

10. 10
8. REFFERENCES
• “Reactive, Proactive, Predictive: SDNModels|F5DevCentral”. Devcentral.f5.com.
Retrieved2014-01-23.
• Kreutz, Diego and Ramos, Fernando and Verissimo, Paulo(2013). “Towards secure and
dependable software defined networks”. Proceedings of the second ACM SIGCOMM
workshop on Hot topics in software defined networking. pp. 50–60.
• Scott-Hayward, Sandra and O'Callaghan, Gemma and Sezer, Sakir (2013). “SDN
security: A survey”. Future Networks and Services (SDN4FNS), 2013 IEEE SDN for. pp.
1–7.
• Benton,Kevinand Camp,Ljean and Small,Chris(2013). “Openflow vulnerability
assessment”. Proceedings of the second ACM SIGCOMM workshop on Hot topics in
software defined networking. pp. 151–152.
• Giotis,Kand Argyropoulos,Christosand Androulidakis, Georgios and Kalogeras,
Dimitrios and Maglaris, Vasilis (2014). “Combining OpenFlow and sFlow for an effective
and scalable anomaly detection and mitigation mechanism on SDN environments”.
Computer Networks 62: 122–136.
• Braga,Rodrigoand Mota,Edjardand Passito,Alexandre (2010). “Lightweight DDoS
flooding attack detection using NOX/OpenFlow”. Local Computer Networks (LCN),
2010 IEEE 35th Conference on. pp. 408–415.
• Feamster, Nick(2010). “Outsourcing home network security”. Proceedings of the 2010
ACM SIGCOMM workshop on Home networks. pp. 37–42.