• 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 APIRequirements 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 studyONF 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 7ONF 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 switchNo 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 ControllerSDN Control Software
Infrastructure Layer
Network Device
Network Device Network Device
Layer 4-7 Services 1
3Intelligent 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 devicesApplication 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 DeviceLayer 4-7
Network Device
Layer 7 Network Service Device
Northbound APIs
Southbound API
Network Services
Layer 7 Network Service Device
VoIP
P2P
Video
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 VirtualizationUsing COTS Server Architecture to Implement Network Functions
Nabil Damouny
© 2013 Open Networking FoundationETSI NFV
Network Functions Virtualization: Vision
Classical Network ApplianceApproach
BRAS
FirewallDPI
CDN
Tester/QoEmonitor
WANAccelerationMessage
Router
Radio/Fixed AccessNetwork Nodes
CarrierGrade NAT
Session BorderController
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.
IndependentSoftware Vendors
Com
petitive &
Innovative O
pen Ecosystem
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