Architecture of OpenFlow SDNs

2,909 views
2,440 views

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
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,909
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
127
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Within a telecom network, where do these functions actually happen?
  • 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

    ×