Barista is an event-centric network operating system (NOS) composition framework that allows for flexible instantiation of NOSs. It leverages both high parallelism and centralized control. Barista uses a component-based architecture where specialized components can be selected from a pool and composed together through dynamic event chaining. This allows operators to customize a NOS by picking components that provide needed functions like distributed scaling, security, or performance optimization. Events are used to communicate between components and can be selectively distributed based on policy. This enables capabilities like a distributed and secure NOS through composition of appropriate components.

1. Barista
An Event-centric NOS Composition Framework
for Software-Defined Networks
Jaehyun Nam1, Hyeonseong Jo1, Yeonkeun Kim1,
Phillip Porras2, and Vinod Yegneswaran2, and Seungwon Shin1
KAIST1 and SRI International2

2. Flexible Network Configurations
§ Software-defined networks (SDNs)
• Programmable control layer à increasing network agility
・Unified integration and management of diverse functions
• Deployment in various network environments
・E.g., enterprise, data center and cloud networks
§ Network operating systems (NOSs)
• The strategic control center of SDNs
・Management of network switches
and high-level applications
・Global network programmability
2

3. NOS Characteristics
§ A variety of NOSs
• Academia à Onix, Beacon, Rosemary, SE-Floodlight
• Open-source projects à
• Industry à
§ Specialized NOSs in different dimensions
• Specific purposes to design NOSs, resulting in architectural differences
• Examples
・Beacon for high performance
・ONOS and OpenDaylight for distributed scalability
・SE-Floodlight for enhanced security
3

4. Architectural Composition Challenge
§ What if we need a scalable and secure NOS?
• ONOS with scalability à high parallelism
• SE-Floodlight with security à centralized control
§ Architectural Gap between NOS design principles
• SE-Floodlight à ONOS
・Hard to inspect control flows due to direct comm. between components
• ONOS à SE-Floodlight
・Hard to achieve high performance due to centralized inspection mechanisms
・E.g., role-based authorization, flow rule conflict resolution
4

5. Barista
§ A novel architecture
• Enable flexible and customizable instantiations of NOSs
• Leverage both high parallelism and centralized control
§ Key Contributions
• Flexible component synthesis
・Accelerate rapid prototyping and integration of new NOS functionalities
• Dynamic event control
・Enable fine-grained control over events delivered to NOS components
◦ A diverse set of event types
◦ Dynamic chaining among components
◦ Policy-based event distribution
5

6. Barista System Overview
Operator
Operator’s
component
3-rd party
component
Barista
component
Barista (base framework)
Barista
Component pool
Component
management
Event
management
Command-line
interface
Admin
Network
Network
Security
Security
Network
Management
Network
Base
<Dynamic component event chaining>
Deploy
Pick-and-choose
Event
Worker
Event
Worker
Event
Worker
<Event handler>
Seq Seq
Parallel
Seq
Seq
Seq
Parallel
Event A
Event B
Event C
Centralized control
High
parallelism
6

7. Component
§ Implementation of a specific NOS function
§ Two types of components
⁃ General component
・Embedded as a part of control flows (e.g., OpenFlow engine)
⁃ Autonomous component
・Designed to take independent actions (e.g., Resource management)
§ Component pool
⁃ A set of components supporting the functionalities of contemporary NOSs
・Distributed scaling, performance improvement, security, failure isolation, etc.
7

8. Event
§ Message delivery mechanism among components
§ No direct communication between components
• All communications through the event handler
§ Enable high composability
8
Component #2
Component #5
Component #3
Component #n
Event handler
Component #1
Component #4
Event #1
Event #2
Event #3
Event #4

9. Component Portability
§ Execute the same code of a component either inside or outside
of the framework
§ Internal components
• Higher performance
• Limited flexibility
§ External components
• High flexibility and availability
• Lower performance
Barista framework
Source code
of a component
Wrapper library Source code
of a component
Event pipelines Control channel
9

10. Diverse Event Classes
§ Three types of event classes
• (i) Notification events, (ii) inter-component events, and (iii) meta events
Event queue Worker pool
C #1 C #2 C #3
Data
Push
Worker #1
Worker #2
Worker #n
Event chain
Component
Pop
(i) Notification events
(ii) Inter-component
events
Look up a receiver
Check event types
Return results
to the trigger
Triggered events Reply data
Push
Event broker
Update results
Statistics Base framework Component
(De)activate
Collect Meta events
(iii) Meta events
10

11. Dynamic Component Event Chaining
§ Two ways to deliver events to components
• Sequential vs. parallel delivery
§ Event sequence formulation
• Ordering components based on their role and permissions
• Evaluating which component can be processed in parallel or sequential
Control flow
integrity Flow mgmt OFP engine
Rule conflict
check
Security / r-x Security / r-x Mgmt / r-- Base / r--
Data
Role = {admin | security | network | management | base}
Perm = {r (read) | w (update data) | x (cut off its control flow)}
Role / Permission
Control flow
integrity Flow mgmt
OFP engine
Rule conflict
check
Should be in sequential Okay to be in parallel
11

12. Policy-based Event Distribution
§ Event handling policy for deployed components
§ Operator-defined policy (ODP)
• Datapath ID, in-port, protocol, source and dst IP addresses and ports
Event queues
pi
pj
pk
…
Pop
Add an ODP to the target component
Policy table Component
Handler
Check
DPID
Inport
Proto
Src IP
Dst IP
Sport
Dport
DPID1 DPID2
Any
IPv4
Src IP1 Src IP2
Dst IP range 1
Any
Any
Skip if not matched
12

13. Event Distribution Across Instances
§ Cluster component for event distribution
• Store triggered events into a distributed storage
• Keep polling new events in the distributed storage
§ Maintenance of logical sequence of events
• Eventual consistency support
§ Operator-defined event sharing
• Which instance listens to what kinds of events
• E.g., sharing ONLY switch and topology events with other instances
13

14. Implementation
§ Base framework and a broad set of components
• 17K lines of C code and Python script
• Maria DB, Galera Cluster for event distribution across instances
§ Open-source project
• All implementation details will be provided at
https://github.com/sdx4u/barista
14

15. Distributed and Secure NOS
§ Need a distributed and secure NOS?
• No controller that currently supports scalability and security together
§ NOS composition with the Barista component pool
• Pick and choose the following components from the Barista pool
⁃ “cluster, role-based authorization, component access control, and flow rule conflict resolution”
0
200K
400K
600K
800K
1.0M
1.2M
1 2 4 8 16 32 64 128
Throughput
(responses/s)
The number of switches
Barista ONOS SE-Floodlight
15

16. Policy-based Event Distribution
§ Selective event distribution based on ODPs
⁃ Forwarding à DPID:!2 / DPID:2; Port:1,2; Proto:LLDP
⁃ VNF manger à DPID:2
SDN controller
<Current Approach> <New Approach>
Barista NOS
Forwarding
VNF manager Forwarding
VNF manager
SW#1 SW#3
SW#2
NF
NF NF
Unified network view Per-component network view
SW#2
NF
NF NF
SW#1 SW#3
SW#2
Selectively deliver events
Deliver all events
VNF events Non-VNF events
2
1 2
1
16

17. Dynamic Component Activation
§ Monitor event statistics in the event handler
⁃ Event volume, component level statistics regarding event consumption and production
⁃ Event distribution statistics
§ Dynamically trigger meta events defined by operators
based on event statistics
SDN controller
<Current Approach> <Barista Approach>
Barista NOS
DDoS preventer
(1-2) Run it all the time
Operator
DDoS attack
happens!
Event handler DDoS preventer
(0) Define a meta event
“Activate the DDoS preventer
if # of new flows > 1,000 pec second”
(2) Activate the DDoS
preventer by itself
(1) # of new flows > 1,000 per sec
(1-1) Activate the DDoS preventer in manual
17

18. Conclusion
§ Contemporary NOSs à specialized NOSs
• Optimized controller design across one or a few dimensions
• Fundamental differences in architectural trade-offs needed
to support competing demands
§ Barista, A framework to build customized NOSs
suited for a variety of requirements from network operators
• Support flexible composition of functionalities in contemporary NOSs
• Dynamic control of associated events for deployed functionalities
18
Github: https://github.com/sdx4u/barista

19. Thank you for listening