Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

this is the report for My Presentation on Software Defined Network

Published in: Technology
  • Be the first to comment

  • Be the first to like this


  1. 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 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. 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. 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. 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. 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. 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. 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. 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. 10 8. REFFERENCES • “Reactive, Proactive, Predictive: SDNModels|F5DevCentral”. 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.