ONOS. Open Network Operating System. Ali Al-Shabibi and Andrea Campanella. ON.Lab 13/09/2016 TIM Labs, Turin. #ONOSProject

Transcription

1 ONOS Open Network Operating System Ali Al-Shabibi and Andrea Campanella ON.Lab 13/09/2016 TIM Labs, Turin

2 Outline Introduction to ONOS and ON.Lab Architecture Northbound interface Southbound interface Performance Sample Applications NREN initial Deployments Use cases Conclusion 2

3 Introduction 3

4 What is ONOS? Open Network Operating System (ONOS) is an open source, Software Defined Networks, network operating system. Our mission is to enable Service Providers, Campus networks and Data center operators to build real SDN/NFV Solutions. 4

5 Service Provider Networks WAN core backbone o o Metro Networks o o Metro cores for access networks 10-50K routers, 2-3M ports Cellular Access Networks o o Multi-Protocol Label Switching (MPLS) with Traffic Engineering (TE) routers, 5-10K ports LTE for a metro area K devices, 100K-100M ports Wired access / aggregation o o Access network for homes; DSL/Cable 10-50K devices, 100K-1M ports 5

6 Architecture 6

7 Architectural Principals High-availability, scalability and performance Required to sustain demands of service provider & enterprise networks Strong abstractions and simplicity Required for development of apps and solutions Protocol and device behaviour independence Avoid contouring and deformation due to protocol specifics Separation of concerns and modularity Allow tailoring and customization without speciating the code-base 7

8 ONOS Distributed Architecture Apps Apps NB Core API Distributed Core (state management, notifications, high-availability & scale-out) SB Core API Providers Providers Providers Providers Protocols Protocols Protocols Protocols 8

9 ONOS Distributed Architecture Apps Apps NB Core API Distributed Core (state management, notifications, high-availability & scale-out) SB Core API Providers Providers Providers Providers Protocols Protocols Protocols Protocols 9

10 GUI REST API ONOS applications ONOS distributed applications platform OSGI / Apache Karaf Command Line ONOS networking core

11 ONOS Distributed Implementation Distributed Set up as a cluster of instances Symmetric Each instance runs identical software and configuration Fault-tolerant Cluster remains operational in the face of node failures Location 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 demands 11

12 ONOS Cluster ONOS 1 ONOS 2 ONOS 3 12

13 ONOS Cluster ONOS 1 Master ONOS 2 ONOS 3 Standby 13

14 ONOS Cluster ONOS 1 ONOS 2 ONOS 3 14

15 ONOS Cluster ONOS 1 ONOS 2 ONOS 3 15

16 Topology state inside a Node Notify Listeners Peer Notifications Peer Notifications Network Events 16

17 Network Topology State Eventually Consistent: Reads are monotonically consistent Low overhead reads and writes 2-3 ms latency for reacting to network events Gossip based Anti-Entropy protocol fixes divergent copies Generalized as EventuallyConsistentMap<K, V> 17

18 State Management in ONOS Core platform feature Typically one of hardest pieces to get right and it is better to solve it once Better if applications can focus on business logic ONOS exposes a set of primitives to cater to different use cases Primitives span the consistency continuum share nothing weak strong 18

19 ONOS Distributed Primitives EventuallyConsistentMap<K, V> ConsistentMap<K, V> Distributed collection of unique elements AtomicCounter Distributed FIFO queue with long poll support DistributedSet<E> Distributed Locking primitive DistributedQueue<E> Map abstraction with strong linearizable consistency LeadershipService Map abstraction with eventual consistency guarantee Distributed version of Java AtomicLong AtomicValue<V> Distributed version of Java AtomicReference 19

20 Northbound 20

21 Key Northbound Abstractions Network Graph Directed, cyclic graph comprising of infrastructure devices, infrastructure links and end-station hosts Core model extensible via a projection mechanism Flow Objective Device-centric abstraction for programming data-plane flows in table pipeline-independent manner Intent Network-centric abstraction for programming data-plane in topology-independent manner 21

22 Network Graph Directed Graph Infrastructure devices and infrastructure links are interior vertices and edges, respectively End-station hosts and implied edge links are exterior vertices and edges Flat Vertices and edges can be annotated 22

23 Flow Objective Abstraction Problem: Applications currently must be pipeline aware, effectively making applicable on specific HW. 23

24 Flow Objective Abstraction Problem: Applications currently must be pipeline aware, effectively making applicable on specific HW. Flow objectives enable developers to write applications once for all pipelines First attempt at interoperability between OF 1.3 switch 24

25 Flow Objective Summary Flow Objective Service: Abstraction for applications to be pipeline unaware while benefiting from scalable, multi-table architectures Aims to make it simple to write apps First attempt at achieving interoperability between OF 1.3 implementations 25

26 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 26

27 Intent Example Host to Host Intent 27

28 Intent Example Host to Host Intent submit() Intent Service API 28

29 Intent Example Host to Host Intent COMPILATION Path Intent Path Intent 29

30 Intent Example Host to Host Intent COMPILATION Path Intent Path Intent INSTALLATION Flow Rule Batch Flow Rule Batch Flow Rule Batch Flow Rule Batch 30

31 Intent Framework Summary Intents 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. 31

32 Network Programming Abstract to concrete Intent DC Clos Fabric Packet/Optical WAN Enterprise Campus Flow Objective OFDPA Pipeline Single Table Pipeline SpringOpen Pipeline Flow Rule OF 1.0 OF 1.3 Netconf TL1 32

33 Multiple Layers of Abstraction Virtual Network Virtual Network Virtual Network Slice Slice Network Slice Topology Device Device Device Device Link Link Link Link Host Host Host Host 33

34 Configuration Network Configuration (netcfg) Provides mechanism for any service to register and receive configuration Device Configuration Behaviors abstract the management and configuration aspects of a device 34

35 Southbound 35

36 Southbound overview Southbound protocols: OpenFlow until is in the works. OVSDB NETCONF + YANG SNMP P4 thrift api for bmv2 softswitch from barefoot networks. BGP, ISIS, OSPF interoperability with legacy network. PCEP Path computation element protocol (IETF) REST 36

37 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 Apps NB Core API ONOS Distributed Core SB Core API Protocols and Drivers 37

38 ONOS driver architecture outline Device specific driver collection of behaviors on-demand activation Abstraction via behaviors <driver name="default "manufacturer="on.lab" hwversion="0.0.1" swversion="0.0.1"> <behaviour api=interfacepath impl=impementationpath /> </driver> define capabilities offered by the device encapsulate specific logic and code App ports,controller,flowrule,power Encapsulate interaction protocol information ONOS Driver Driver Protocol Protocol 38

39 Performance 39

40 Switch Up Latency Most of the time is spent waiting for the switch to respond to a features request. (~53ms) ONOS spends under 25ms with most of it s time electing a master for the device. Which is a strongly consistent operation 40

41 Switch Down Latency Significantly faster because there is no negotiation with the switch A terminating TCP connection unequivocally indicates that the switch is gone 41

42 Link Up/Down Latency The increase from single to multi instance is being investigated Since we use LLDP to discover links, it takes longer to discover a link coming up than going down Port down event trigger immediate teardown of the link. 42

43 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 requires. 43

44 Intent Latency Results Less than 100ms to install or withdraw a batch of intents Less than 50ms to process and react to network events Slightly faster because intent objects are already replicated 44

45 Intent Throughput Results Processing clearly scales as cluster size increases 45

46 Applications 46

47 Developing ONOS applications ONOS applications: Interact with the northbound Java or REST interface Device and protocol agnostic Augment ONOS though modularity Provide GUI,REST,CLI and distributed stores. Shape the network. Easy to start with auto generated basic code via maven archetypes. 47

48 Bundles, Features & ONOS Apps Apps are delivered via ONOS App archive (.oar) files OAR is a JAR with app.xml, features.xml and bundle artifacts onos-maven-plugin generates an *.oar file as part of Maven build Apps are managed on the entire ONOS cluster via REST API: GET POST DELETE /onos/v1/applications via shell tool: onos-app {install activate deactivate uninstall} via CLI: onos:app {install activate deactivate uninstall} via GUI Applications view Back-end installation and activation is done via normal feature & bundle services 48

49 Developing ONOS apps Maven archetypes onos-api-archetype - basis for an app Java API bundle onos-bundle-archetype - basis for an ONOS bundle or an app onos-cli-archetype - overlay for apps with CLI extensions onos-ui-archetype - overlay for apps with GUI extensions onos-uitab-archetype - basis for an app Java API bundle onos-uitopo-archetype - basis for an app Java API bundle Creates a working minimal project module via onos-create-app shell tool convenience wrapper for mvn archetype:generate 49

50 Example Applications SDN-IP Peering Connect internal BGP software daemon to external BGP routers Install learned routes to forward IP traffic to appropriate egress point Multi-level (IP / Optical) Provisioning Provision optical paths/tunnels with constraints Content Acquisition / Video Streaming (DirecTV) Establish multicast forwarding from a sender to set of receivers Virtual Network Gateway (vbng) Provide connectivity between a private host and the Internet Bandwidth Calendaring Establish tunnels with bandwidth guarantees between two points at a given time 50

51 Deployment 51

52 Physical Requirements To test ONOS and Develop: Linux /Mac virtual or physical machine 8gb of RAM and 4/8 core processor. Deployment example with SDN-IP: 4 core, 4gb of ram and 50gb of SSD Hardware Requirements need to be tailored to the environment and needs. 52

53 Global SDN Deployment Powered by ONOS Q Korea announces the first ONOS deployment OF OpenFlow Q1-Q First ONOS Deployments South America, US, EU Q New connections Miami - Korea Miami - Taiwan Korea - Taiwan Q New connections Sidney Seattle - Miami Sao Paolo Amsterdam Q ONOS deployed in Korea Q NCTU / Taiwan deploys ONOS OpenFlow Q First ONOS production deployment in South America OpenFlow Q ONOS Deployment in Australia 53

54 Enabling network innovation with new apps 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 on AmLight 54

55 Insights in deployments ONOS OF Multi-table pipelines support Intent framework performance improvements Hardware Lack of carrier grade >=100G programmable hardware for WAN OF 1.3 yet not supported (enough), OF 1.0 badly supported ONOS seems too fast for the majority of the hardware devices out there Better resources isolations 55

56 Conclusion 56

57 ONOS & Approach to SDN Move with urgency, but deliberately Mind the fundamentals Keep balance between innovation, utility and stability Allow legacy devices to participate in SDN, but not to deform or diminish the SDN vision 57

58 Further reading ONOS website: Tutorials, documentation and general reading at: ONOS is on Github at: CORD website: For any further inquiry mailing lists or 58

59 Software Defined Transformation of Service Provider Networks Join the onosproject.org 59