The document outlines the architecture of OpenFlow Software Defined Networks (SDN), emphasizing the need for network-aware applications and a logically centralized network controller that translates application requirements into operational rules. It discusses ongoing work related to Northbound Interface (NBI) standardization and examines challenges faced by Layer 4-7 services in SDN environments, including inefficiencies and bottlenecks. Additionally, it highlights Network Function Virtualization (NFV) approaches, positing a shift from purpose-built hardware to a more open and competitive ecosystem using standard servers and orchestration.

1. • Fabian Schneider, NEC
• Nabil Damouny, Netronome
1
Architecture of OpenFlow SDNs

2. © 2013 Open Networking Foundation
Topics
• ONF Architecture overview
• NBI study
• L4-7 aspects
• NFV
2

3. © 2013 Open Networking Foundation
ONF Architecture Overview
ONF ArchWG (Fabian Schneider)

4. © 2013 Open Networking Foundation
Arch: Express and Enforce Requirements via API
Requirements described and enforced on-line, formally, dynamically
4

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. © 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. © 2013 Open Networking Foundation
NBI study
ONF ArchWG (Fabian Schneider)

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. © 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. © 2013 Open Networking Foundation
Spectrum of Northbound Interfaces from study
10

11. © 2013 Open Networking Foundation
Enhancing OpenFlow to Support Layer 4 through 7
ONF MEC L4-L7 Study Group (Nabil Damouny, Sharad Alawat)

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. © 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. © 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. © 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. © 2013 Open Networking Foundation
NFV – Network Function Virtualization
Using COTS Server Architecture to Implement Network Functions
Nabil Damouny

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. © 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. © 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. © 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