Architecture of OpenFlow SDNs

• 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


ONF Architecture Overview ONF ArchWG (Fabian Schneider)


Arch: Express and Enforce Requirements via APIRequirements described and enforced on-line, formally, dynamically

4


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


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


NBI studyONF ArchWG (Fabian Schneider)


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


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


Spectrum of Northbound Interfaces from study

10


Enhancing OpenFlow to Support Layer 4 through 7ONF MEC L4-L7 Study Group (Nabil Damouny, Sharad Alawat)


• 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


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


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


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

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


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


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


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


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

Technology

Architecture of OpenFlow SDNs