Architecture of OpenFlow SDNs
Upcoming SlideShare
Loading in...5
×
 

Architecture of OpenFlow SDNs

on

  • 1,265 views

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

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

Statistics

Views

Total Views
1,265
Views on SlideShare
1,265
Embed Views
0

Actions

Likes
0
Downloads
64
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Within a telecom network, where do these functions actually happen?

Architecture of OpenFlow SDNs Architecture of OpenFlow SDNs Presentation Transcript

  • • Fabian Schneider, NEC • Nabil Damouny, Netronome 1 Architecture of OpenFlow SDNs
  • © 2013 Open Networking Foundation Topics • ONF Architecture overview • NBI study • L4-7 aspects • NFV 2
  • © 2013 Open Networking Foundation ONF Architecture Overview ONF ArchWG (Fabian Schneider)
  • © 2013 Open Networking Foundation Arch: Express and Enforce Requirements via API Requirements described and enforced on-line, formally, dynamically 4
  • © 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
  • © 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
  • © 2013 Open Networking Foundation NBI study ONF ArchWG (Fabian Schneider)
  • © 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
  • © 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
  • © 2013 Open Networking Foundation Spectrum of Northbound Interfaces from study 10
  • © 2013 Open Networking Foundation Enhancing OpenFlow to Support Layer 4 through 7 ONF MEC L4-L7 Study Group (Nabil Damouny, Sharad Alawat)
  • © 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
  • © 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
  • © 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
  • © 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
  • © 2013 Open Networking Foundation NFV – Network Function Virtualization Using COTS Server Architecture to Implement Network Functions Nabil Damouny
  • © 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
  • © 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
  • © 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
  • © 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