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.

Architecture of OpenFlow SDNs


Published on

Architecture of OpenFlow SDNs a presentation by Fabian Schneider, NEC and Nabil Damouny, Netronome at US Ignite ONF GENI workshop on October 8, 2013

Published in: Technology
  • Dating direct: ♥♥♥ ♥♥♥
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area is here: ❶❶❶ ❶❶❶
    Are you sure you want to  Yes  No
    Your message goes here

Architecture of OpenFlow SDNs

  1. 1. • Fabian Schneider, NEC • Nabil Damouny, Netronome 1 Architecture of OpenFlow SDNs
  2. 2. © 2013 Open Networking Foundation Topics • ONF Architecture overview • NBI study • L4-7 aspects • NFV 2
  3. 3. © 2013 Open Networking Foundation ONF Architecture Overview ONF ArchWG (Fabian Schneider)
  4. 4. © 2013 Open Networking Foundation Arch: Express and Enforce Requirements via API Requirements described and enforced on-line, formally, dynamically 4
  5. 5. © 2013 Open Networking Foundation Three Critical Properties of this Architecture 5 1. Applications are network aware: SDN-enabled Applications – Communicate their requirements/polices to the network – Can monitor network state and adapt accordingly 2. Network is logically centralized: SDN Network Controller – Controller translates from app requirement to low-level rules – Controller summarizes the network state for applications 3. Well-understood driver-like model for devices: SDN Datapath – Programmatic low-level control of all fwd’ing and configuration – API for Capabilities advertisement and publishing statistics – No resource contention with other entities → Controller “owns” this device, subject to capabilities advertisement/negotiation
  6. 6. © 2013 Open Networking Foundation Topics currently worked on 6 • Service chaining, L4-7 support, NFV • Controller to controller interface: Need for standard? • Network virtualization on an architectural level • Tying Arch with use-cases • Architectural split between OF-switch and OF-config • Datapath diversity: SW vs. HW • Interworking with legacy network and protocols • North-bound interface study
  7. 7. © 2013 Open Networking Foundation NBI study ONF ArchWG (Fabian Schneider)
  8. 8. © 2013 Open Networking Foundation NBI study Status • NBI study document(s) – 9 use-cases in doc; some more in the pipeline – 5 controller solutions in doc; few more in pipeline – All need more reviews – Pipeline needs to be flushed • NBI next steps – Define groups of NBI functionality to work on – For each group decide on • Standardization in ONF: yes/no, when? • Or point to other SDO or de-facto standard – Start discussing app execution framework 8
  9. 9. © 2013 Open Networking Foundation Standardizing Northbound Interfaces 9 • Not an easy task – Level of abstraction unclear (see next slide) • Varies from OpenFlow+SwitchIDs (e.g. Trema, NOX/POX) • Via network programming languages (e.g. Frenetic) • Up to Neutron/Quantum level – Scope unclear • One single NBI to rule them all • Or one per operation call • ONF’s approach (at the moment) – Start with what is needed today and what is not yet available – Standardize sets of functionality – Determine gaps in standardization/de-facto-standards space – Leave application specifics to other SDOs and focus on network specifics
  10. 10. © 2013 Open Networking Foundation Spectrum of Northbound Interfaces from study 10
  11. 11. © 2013 Open Networking Foundation Enhancing OpenFlow to Support Layer 4 through 7 ONF MEC L4-L7 Study Group (Nabil Damouny, Sharad Alawat)
  12. 12. © 2013 Open Networking Foundation • Layer 2 / Layer 3 – Switching – Routing – Packet forwarding – OpenFlow – Architectures optimized to process individual packets – Cisco, HP, Juniper etc. • Layer 4 through 7 – Security – Load balancing – WAN optimization – Architectures optimized to process flows and content – F5, Riverbed, Sourcefire etc. What Are Layer 4 through 7 Services? Categorized by depth of Layer 4 through 7 inspection • OpenFlow switch No Flow Inspection • Load balancer • Next-generation firewall • WAN optimization • Web application firewall Partial Flow Inspection • Test and measurement • Policing and metering • Quality of Service (QoS) • Traffic analysis Flow Monitoring • Anti-virus / anti-spam • Intrusion prevention system (IPS) • SSL inspection • VPN Full Flow Inspection 12
  13. 13. © 2013 Open Networking Foundation Challenges with L4-L7 Services in SDN Environment 13 • Inefficient use of network bandwidth and compute resources due to lack of L4-L7 visibility • Bottlenecks and lack of coverage due to inability to rapidly respond to new networking and application requirements • Hosting on controllers results in reduced throughput, increased latency and limited scalability of the network, due to limited compute resources • Lack of feedback from L4-L7 services which could potentially reprogram network paths based on L4-L7 analysis
  14. 14. © 2013 Open Networking Foundation Deployment Models Application Layer Applications Control Layer Network Controller SDN Control Software Infrastructure Layer Network Device Network Device Network Device Layer 4-7 Services 1 3 Intelligent Switch with Layer 4-7 Layer 4 through 7 Appliance2 1. Running as applications on the controller • Controller programs SDN switch on per-flow basis Northbound APIs Southbound API 2. Standalone network appliance • Traffic directed to appliance either based on static policy or dynamically driven by controller • Or just in-line 3. Full Layer 4-7 network services running on intelligent switch • Intelligent switch becomes Layer 2 through 7 device 14
  15. 15. © 2013 Open Networking Foundation Use Case Example: Advanced Traffic Analysis Embedded DPI feeds network intelligence to services on Layer 7 network service devices Application flows forwarded directly to specialized service processing • Requires Layer 4 through 7 intelligence embedded directly in switches Application Layer Applications Control Layer SDN Control Software Infrastructure Layer Network Device Network Device Layer 4-7 Network Device Layer 7 Network Service Device Northbound APIs Southbound API Network Services Layer 7 Network Service Device VoIP P2P Video Email Web Data Plane Traffic Layer 4-7: Protocol and Application Identification IM Other Traffic Steering Video Optimization QoS / QoE Analytics GGSN Content Filtering 15
  16. 16. © 2013 Open Networking Foundation NFV – Network Function Virtualization Using COTS Server Architecture to Implement Network Functions Nabil Damouny
  17. 17. © 2013 Open Networking Foundation ETSI NFV Network Functions Virtualization: Vision Classical Network Appliance Approach BRAS FirewallDPI CDN Tester/QoE monitor WAN Acceleration Message Router Radio/Fixed Access Network Nodes Carrier Grade NAT Session Border Controller PE RouterSGSN/GGSN • Fragmented, purpose-built hardware. • Physical install per appliance per site. • Hardware development large barrier to entry for new vendors, constraining innovation & competition. Network Functions Virtualization Approach High volume Ethernet switches High volume standard servers High volume standard storage Orchestrated, automatic & remote install. Independent Software Vendors Competitive& Innovative OpenEcosystem 17
  18. 18. © 2013 Open Networking Foundation ETSI ISG NFV Structure • ISG E-E Documents 1. Architecture Framework 2. Use Cases (9 total) 3. (Business) Requirements 4. Terminology – All are currently “stable Draft” – out for ratification – E2E documents drive Technical Working Groups • Technical Working Groups 1. Infrastructure (INF) 2. Software Architecture (SWA) 3. Management & Orchestration (MANO) 4. Reliability & Availability (REL) – Performance Expert Group – Security Expert Group E2E Documents Drives Technical WG’s 18
  19. 19. © 2013 Open Networking Foundation NFV Reference Architectural Framework 19 SDN Controller maybe one of the VNF’s. It may also be part of the Nf-Vi (Management-Infrastructure) interface
  20. 20. © 2013 Open Networking Foundation ETSI ISG NFV – Next Steps 20 • Ratify E2E ISG documents: 1. Architecture Framework 2. Use Cases 3. Requirements • Ratify PoC (Proof of Concept) proposal process – Encourage vendors to team-up with operator(s) to submit PoC proposals • Submission include at least 2 vendors + at least 1 operator • Work on technical WG requirements documents – Goal: Stable draft by mid-2014