Embed Size (px)
Citation preview
#ONOSProject
ONOS OverviewArchitecture, Northbound, Southbound APIs
Performance, Applications, Deployments & CommunityAndrea Campanella
ON.LabNovember 30, 2016
#ONOSProject
What is ONOS?
Open Network Operating System (ONOS) is an open source SDN network operating system. Our mission is to enable Service Providers to build real SDN/NFV Solutions.
2
#ONOSProject
Quarterly ReleasesAvocet (1.0.0) released 2014-12
Initial release of clean and modular code-base, protocol independence
Blackbird (1.1.0) released 2015-03Improved performance, scale-out, increased robustness
Cardinal (1.2.0) released 2015-06New use-cases, additional core features, additional SB protocols
Drake (1.3.0) released 2015-09Platform enhancements, security, UI enhancements
Emu (1.4.0) - released 2015-12CORD features, prototype of dynamic cluster scaling
Falcon (1.5.0) - released 2016-03Dynamic cluster scaling, model extensibility, intents on flow
objectivesGoldeneye (1.6.0) - released 2016-06
3
#ONOSProject
Service Provider Networks● WAN core backbone
o Multi-Protocol Label Switching (MPLS) with Traffic Engineering (TE)o 200-500 routers, 5-10K ports
● Metro Networkso Metro cores for access networkso 10-50K routers, 2-3M ports
● Cellular Access Networkso LTE for a metro areao 20-100K devices, 100K-100M ports
● Wired access / aggregationo Access network for homes; DSL/Cableo 10-50K devices, 100K-1M ports
4
#ONOSProject
Key Performance Requirements
ONOS
AppsApps
Global Network View / StateGlobal Network View / State
high throughput | low latency | consistency | high availability
High Throughput: ~500K-1M paths setups / second ~3-6M network state ops / second
High Volume:~500GB-1TB of network state data
Difficult challenge!
5
#ONOSProject
Architectural TenetsHigh-availability, scalability and performance
required to sustain demands of service provider & enterprise networks
Strong abstractions and simplicityrequired for development of apps and solutions
Protocol and device behaviour independenceavoid contouring and deformation due to protocol
specificsSeparation of concerns and modularity
allow tailoring and customization without speciating the code-base
6
#ONOSProject
ONOS Distributed Architecture
NB Core API
Distributed Core(state management, notifications, high-availability & scale-out)
SB Core API
Protocols
Providers
Protocols
Providers
Protocols
Providers
Protocols
Providers
AppsApps
Distributed Core(state management, notifications, high-availability & scale-out)
SB Core API
NB Core API
Providers Providers Providers Providers
Protocols Protocols Protocols Protocols
7
OSGI / Apache Karaf
ONOS distributed applications platform
ONOS networking core
ONOS applications
GUI REST APICom
mand Line
OSGI / Apache Karaf
ONOS distributed applications platform
ONOS networking core
ONOS applications
GUI REST APICom
mand Line
OSGI / Apache Karaf
ONOS distributed applications platform
ONOS networking core
ONOS extensions
GUI REST APICom
mand Line
applications
driversprotocols
OSGI / Apache Karaf
ONOS distributed applications platform
ONOS networking core
ONOS applications
GUI REST APICom
mand Line
#ONOSProject
Distributed Core
12
#ONOSProject
Distributed Core
13
#ONOSProject
ONOS Distributed ArchitectureDistributed
Set up as a cluster of instancesSymmetric
Each instance runs identical software and configurationFault-tolerant
Cluster remains operational in the face of node failuresLocation Transparent
A client can interact with any instance. The cluster presents the abstraction of a single logical instance
Dynamic The cluster can be scaled up/down to meet usage
demands14
#ONOSProject
ONOS 1 ONOS 2 ONOS 3
ONOS Cluster
15
#ONOSProject
ONOS 1 ONOS 2 ONOS 3
Master Standby
ONOS Cluster
16
#ONOSProject
ONOS 1 ONOS 2 ONOS 3
ONOS Cluster
17
#ONOSProject
ONOS 1 ONOS 2 ONOS 3
ONOS Cluster
18
#ONOSProject
ONOS Distributed Architecture
NB Core API
Distributed Core(state management, notifications, high-availability & scale-out)
SB Core API
Protocols
Providers
Protocols
Providers
Protocols
Providers
Protocols
Providers
AppsApps
19
#ONOSProject
ONOS Distributed PrimitivesEventuallyConsistentMap<K, V>
Map abstraction with eventual consistency guaranteeConsistentMap<K, V>
Map abstraction with strong linearizable consistencyLeadershipService
Distributed Locking primitiveDistributedQueue<E>
Distributed FIFO queue with long poll supportDistributedSet<E>
Distributed collection of unique elementsAtomicCounter
Distributed version of Java AtomicLongAtomicValue<V>
Distributed version of Java AtomicReference
20
#ONOSProject
Northbound
21
#ONOSProject
Key Northbound AbstractionsNetwork Graph
Directed, cyclic graph comprising of infrastructure devices, infrastructure links and end-station hosts
Flow ObjectiveDevice-centric abstraction for programming data-plane
flows in table pipeline-independent mannerIntent
Network-centric abstraction for programming data-plane in topology-independent manner
22
#ONOSProject
Building Network ApplicationsEach application has complex path computation and rule
installationInconsistent behavior in the face of failures
Failures may be handled in different ways (or not at all)Bugs need to fixed in multiple places (applications)Expensive to upgrade/refactor behavior across all applications;
e.g.Improve performanceSupport new types of devicesImplement better algorithms
Difficult or impossible to resolve conflicts with other applications23
#ONOSProject
Intent Framework• Provides high-level, network-centric interface that
focuses on what should be done rather than how it is specifically programmed
• Abstracts unnecessary network complexity from applications
• Maintains requested semantics as network changes
• High availability, scalability and high performance
24
#ONOSProject
Intent ExampleHost to Host Intent
25
#ONOSProject
COMPILATION
Path IntentPath Intent
Host to Host Intent
26
Intent Example
#ONOSProject
COMPILATION
INSTALLATION
Flow Rule Batch Flow Rule Batch
Flow Rule BatchFlow Rule Batch
Path IntentPath Intent
Host to Host Intent
27
Intent Example
#ONOSProject
Intent Framework SummaryIntents are a network-centric programming
abstraction that reduce application complexity.
Intents provide device-agnostic behavior with persistency and high performance across network failures.
Intent framework has moved from prototype to production deployments.
28
#ONOSProject
Network Programming
OF 1.0 OF 1.3 Netconf TL1
Flow Rule
OFDPA Pipeline
Single Table Pipeline
SpringOpen Pipeline
Flow Objective
DC Clos Fabric
Packet/Optical WAN
Enterprise Campus
Intent
29
Abstract to
concrete
#ONOSProject
Multiple Layers of Abstraction
Device Link HostDevice Link HostDevice Link HostDevice Link Host
Topology
Virtual Network SliceVirtual Network SliceVirtual Network Network Slice
30
#ONOSProject
Network Configuration (netcfg)Provides mechanism for any service to register and receive
configurationDynamic Configuration (in progress)
Enables YANG-based service models to be introduced at runtime
Allow applications to implement dynamic services
Configuration
31
Extension ApplicationIntegrations
OpenstackXoSVTN
New protocolsRPC: RabbitMQEvent streaming: KafkaMetrics: Ganglia, Graphite, InfluxDB
#ONOSProject
Southbound
33
#ONOSProject
Southbound protocols in 1.7.1:OpenFlow until 1.3 → 1.5 is in the works.OVSDBNETCONF + YANG → Yang tools and Yang management
systemSNMPP4 → thrift api for bmv2 softswitch from barefoot networks.BGP, ISIS, OSPF → interoperability with legacy network. PCEP → Path computation element protocol (IETF)REST and RESTCONFLISP
Southbound overview
34
#ONOSProject
ONOS drivers•Device specific driver
• collection of behaviors• on-demand activation
•Abstraction via behaviors• define specific capabilities
offered by the device• encapsulate specific logic and
code• ports,controller,flowrule,power…•Encapsulate single
interaction• protocol• information
Driver
Protocol
App
ONOS Driver
Protocol
<driver name="default "manufacturer="ON.Lab"
hwVersion="0.0.1" swVersion="0.0.1">
<behaviour api=InterfacePath
impl=ImpementationPath />
</driver>
35
#ONOSProject
Southbound Architecture
•Southbound abstractions, modularity• customization without changing the core
•Protocol and device model independency• avoid specifics and dependencies in the core• hidden complexity to upper layers• testability, extensibility and performance
ONOS Distributed Core
SB Core API
NB Core API
Apps
Protocols and Drivers
36
#ONOSProject
Applications
37
#ONOSProject
Developing ONOS applicationsONOS applications:
Interact with the northbound Java or REST interface
Device and protocol agnosticAugment ONOS though modularityProvide GUI,REST,CLI and distributed stores.Shape the network.Easy to start with auto generated basic code via
maven archetypes.38
#ONOSProject39
●ONOS Applications○ OSGi bundles, Karaf features, ONOS apps & OAR files○ application lifecycle - install, activate, deactivate, uninstall○ ONOS CLI & GUI
●Developing ONOS apps○ use mvn archetype:generate and onos-create-app○ archetype overlays for CLI and UI - generated & pre-
canned○ iterative and demonstrating use of onos-app tool or GUI
Outline
#ONOSProject
Example ApplicationsSDN-IP Peering
Connect internal BGP software daemon to external BGP routersInstall learned routes to forward IP traffic to appropriate egress
pointMulti-level (IP / Optical) Provisioning
Provision optical paths/tunnels with constraintsContent Acquisition / Video Streaming (DirecTV)
Establish multicast forwarding from a sender to set of receiversVirtual Network Gateway (vBNG)
Provide connectivity between a private host and the InternetBandwidth Calendaring
Establish tunnels with bandwidth guarantees between two points at a given time
40
#ONOSProject
Deployments
41
#ONOSProject42
Motivation and GoalsR&E Network Operators and Users
Create a global SDN network
Provide L0, L2 and L3 connectivity without “legacy” equipment in the network core
Enable network and services innovation
ONOS community
Demonstrate ONOS in real networks
Test High performance, HA and scalability in real networks
Learn and improve
Requirements/Learning/Bug Fixes
ONOS and Use Cases
Agilecollaboration
modelR&E Network
Operators ONOS Community
#ONOSProject43
OpenFlow
OpenFlow
OF
Q3 2015ONOS Deployment in Australia
OpenFlow
Q3 2015Korea announces the firstONOS deployment
Q4 2015ONOS deployed in Korea
Q4 2015First ONOS
production deploymentin South America
Q1-Q2 2015First ONOS DeploymentsSouth America, US, EU
Q4 2015 – New connectionsSidney – Seattle - MiamiSao Paolo – Amsterdam
Q1 2016NCTU / Taiwandeploys ONOS
Q1 2016 – New connectionsMiami - KoreaMiami - TaiwanKorea - Taiwan
Global SDN Deployment Powered by ONOS
#ONOSProject44
Castor• Provides L2/L3 connectivity for SDXs• Developed and deployed in AARNET
SDN-IP• Transforms a SDN into a transit IP network• SDN AS uses BGP to communicate with neighbors• L3 connectivity without legacy routers• Deployed by AmLight, Internet2 (upgrading), KREONET, NCTU
SDX L2/L3• Provides L2/L3 connectivity for SDXs• Developed and deployed by GEANT
VPLS• L2 broadcast overlay networks on demand• Ready to be deployed at AmLight
Enabling network innovation with new apps
#ONOSProject
Use Case: CORD
45
46
What is CORD? Central Office Re-architected as a Datacenter
SDN + NFV + Cloud
Open Source Software
Commodity Hardware(Servers, White-Box Switches, I/O Blades)
Large number of COs
Evolved over 40-50 years
300+ Types of equipmentHuge source of CAPEX/OPEX
47
What is Trellis?
Datacenter Leaf-Spine Fabric Underlay
Virtual Network Overlay
Unified SDN ControlOf Underlay & Overlay
ONOS Controller Cluster &
Apps
Trellis is the enabling Network Infrastructure for CORD
Trellis Provides Common control over underlay & overlay networks, including•Service Composition for Tenant Networks•Distributed Virtual Routing •Optimized Delivery of Multicast Traffic Streams
CORD Architecture
R,E,M-Access
Metro
Router
ONOS Controller Cluster
vRouterControl
Other App
OverlayControl
Underlay Control
Other App
XOS (Orchestrator)
vSG
vSG
vSG
VNF
VNF
VNFVNF
VNF VNFVNF
VNF VNF VNFVNF
VNF
OVS OVS OVS OVS OVS
White Box White Box
White Box
White Box
White Box White Box White Box White Box
White Box White Box White Box
White Box
White Box
White Box
Open SourceSDN-basedBare-metal
White Box
White Box
48
Residential Mobile Enterprise
Underlay
Overlay
Control
▪Underlay Fabric• L2/L3 spine-leaf fabric – bare-metal hardware + open source software• SDN control plane – no distributed protocols• Modern ASIC data plane – 1.28 Tbps switching bandwitdth for each switch
▪Virtual Network Overlay• Designed for NFV – chained VNFs using with best principles of cloud • Overlay Control – XOS and VTN implement service graph• OVS + VxLAN Data Plane
▪Unified SDN Control• Common Control – opportunity for optimized service delivery
49
ONOS for CORD
E-CORD in Metro
CORD
CORD
CORD
CORD
Central OfficeE-Line
E-LAN
Metro CORDPacket optical
ROADM ROADM
ROADM
ROADM
Firewall
WANAccelerator
WANAccelerator
IDS
50
PONOLT MACs
Leaf-Spine Fabric
DSLG.Fast
transponder
muxponder
WSS To metro
1. Programmable backplane between ROADM and transponders
2. Optical bypass within CO
To spine switches
To metroTo access
Cross connect
• 20x20 ROADM, 1U• 8x2 transponder, 1U• 320x320 fiber switch,
7U
ONOSOpenFlow,
SNMP,NETCONF, REST
Power Manageme
ntAlarm
HandlingBandwidth
On DemandOptical
Restoration
WSSX
Multiple partner
s
Open-ROADM project
51
Mobile-CORD – Internal View
Mobile Subscribers
Operator Specification (TOSCA, Yang)
Service GraphResource PolicyScaling PolicyCustomer Policy
Everything-as-a-Service (XaaS) / Micro-Services Architecture
RRH
vMME
vBBU vSGW vPGW
OpenStack Monitoring vCDNONOS
Controller
Controller Controller Controller
ControllerControllerControllerController
Controller
52
#ONOSProject 53
and
#ONOSProject
Further readingONOS website:http://onosproject.orgTutorials, documentation and general reading at:https://wiki.onosproject.org/ONOS is on Github at: https://github.com/opennetworkinglab/onosSetup Tutorialhttps://wiki.onosproject.org/display/ONOS/Installing+and+Running+ONOSScreencasts:https://wiki.onosproject.org/display/ONOS/Screencasts
54
#ONOSProject 55
Application tutorial
•Creating and deploying and ONOS App•Creating and deploying and ONOS App (video)•Template application tutorial
#ONOSProject
Contact us!
56
Community: William [email protected]
Technical: Andrea Campanella [email protected]
#ONOSProject Join the journey @ onosproject.org
Software Defined Transformation of Service Provider Networks
57
#ONOSProject
Features and modules to communicate with devices
Expose the standard set of APIs and enabled operations. I.e:
OpenFlow: FlowMods, GroupMods, etcRest: implements CRUD operations (GET,
POST, DELETE, etc...)Netconf: Open/close session,
setConfiguration, getConfigurationUsually leverage 3rd party communication
libraries → openflowj, snmp4j, thrift
ONOS Protocols
58
Provider Component
Provider Component
Protocols
Provider
#ONOSProject
ONOS ProvidersProviders are used by the core to (re)act on the network:
- Up/down of device, links - DeviceProvider, LinkProvider
- Provisioning of rules, paths, tunnels- FlowRuleProvider, TunnelProvider
- Receive notifications/alarms- AlarmProvider
→ Translate to and from Core abstractions into device specific commands.
Provider Component
Provider Component
Protocols
This is where the magic happens
#ONOSProject
Performance
60
#ONOSProject
Performance MetricsDevice & link sensing latency
measure how fast can controller react to environment changes, such as switch or port down to rebuild the network graph and notify apps
Flow rule operations throughputmeasure how many flow rule operations can be issued against the
controller and characterize relationship of throughput with cluster size
Intent operations throughputmeasure how many intent operations can be issued against
controller cluster and characterize relationship of throughput with cluster size
Intent operations latencymeasure how fast can the controller react to environment changes
and reprovision intents on the data-plane and characterize scalability
61
#ONOSProject
Link Up/Down Latency
● Since we use LLDP & BDDP to discover links, it takes longer to discover a link coming up than going down
● Port down event trigger immediate teardown of the link.
62
#ONOSProject
Flow Throughput results
● Single instance can install over 500K flows per second
● ONOS can handle 3M local and 2M non local flow installations
● With 1-3 ONOS instances, the flow setup rate remains constant no matter how many neighbours are involved
● With more than 3 instances injecting load the flow performance drops off due to extra coordination required.
63
#ONOSProject
Intent Throughput ResultsProcessing clearly scales as cluster size increases
64
#ONOSProject
Intent Latency ResultsLess than 100ms to install or withdraw a batch of intentsLess than 50ms to process and react to network events
Slightly faster because intent objects are already replicated
65
#ONOSProject66
OpenFlow
OpenFlow
OF
OpenFlow
How the testbed works?
eBGP
AS #20080 AS
#65111
over L2 dedicated circuits
