Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
ONOS
Building a Distributed, Network Operating System
Madan Jampani & Brian O'Connor
BANV Meetup
3/16/2015
Outline
● A simple example as motivation
● ONOS Architecture
● Distributed primitives for managing state
● APIs and a temp...
Problem: Set up a Flow
Topology Discovery
Path Computation
Path Selection
Switch FlowEntry
S1 ...
S2 ...
S3 ...
Compute Flow Mods
Switch FlowEntry
S1 ...
S2 ...
S3 ...
Install Flow Mods
Switch FlowEntry
S1 ...
S2 ...
S3 ...
Topology Monitoring
Flow Repair
Wishlist
● Global Network View
● Path Computation
● Flow Mod Computation / Installation
● Monitor and React to network eve...
Do all this with...
● High Availability
● At Scale
Wishlist
● Global Network View
● Path Computation
● Flow Mod Computation / Installation
● Monitor and React to network eve...
Support variety of
devices and protocols
Wishlist
● Global Network View
● Path Computation
● Flow Mod Computation/Installation
● Monitor and React to events
● High...
Managing Complexity
NAT
Firewall
Wishlist
● Global Network View
● Path Computation
● Flow Mod Computation/Installation
● Monitor and React to events
● High...
ONOS Architecture Tiers
Northbound - Application Intent Framework
(policy enforcement, conflict resolution)
OpenFlow NetCo...
Distributed Core
● Distributed state management framework
○ built for high availability and scale-out
● Different types of...
Distributed Core
● Global Network View
● Scaling strong consistency
“Tell me about your slice?”
Cache
“Tell me about your slice?”
Topology
Events
Distributed
Topology
Store
Write
Topology
State
Distributed
Topology
Store
Read
Topology
State
Cache
Distributed
Topology
Store
Read
Topology
State
Cache
Distributed
Topology
Store
Read
Topology
State
Topology as a State Machine
Events are Switch/Port/Link up/down
Current
Topology
Updated
Topology
apply event
E
E E
E
E
F
F E
C1C2C1
1 2 3
Switch Mastership Terms
We track this in a strongly
consistent store
2.1 2.2 2.3 2.4 2.5 2.61.41.2 1.31.1 3.2 3.33.12.7 2.8
C1C2C1
1 2 3
Switch Event Numbers
Partial Ordering of Topology Events
Each event has a unique logical timestamp
(Switch ID, Term Number, Event Number)
E (S1, 1, 2)
E E
E
(S1, 1, 2)
(S1, 1, 2)
(S1, 1, 2)
F
(S1, 2, 1)
F
F
(S1, 2, 1)
(S1, 2, 1)
F
F
(S1, 2, 1)
(S1, 2, 1) (S1, 1, 2)
E
F
F
(S1, 2, 1)
(S1, 2, 1) (S1, 1, 2)
E
To summarize
● Each instance has a full copy of network topology
● Events are timestamped on arrival and broadcasted
● Sta...
There is one additional step...
What about dropped messages?
Anti-Entropy
Lightweight, Gossip style, peer-to-peer
Quickly bootstraps newly joined nodes
A model for state tracking
If you are the observer, Eventual Consistency is the best
option
View should be consistent with...
Hiding the complexity
EventuallyConsistentMap<K, V, T>
Plugin your own timestamp generation
Other Control Plane state...
● Switch to Controller mapping
● Resource Allocations
● Flows
● Various application generated...
Consistency => Coordination
2PC
All participants need to be available
Consensus
Only a majority need to participate
State Consistency through Consensus
LOG
LOG LOG LOG LOG LOG LOG
Scaling Consistency
Scaling Consistency
Scaling Consistency
Consistency Cost
● Atomic updates within a shard are “cheap”
● Atomic updates spanning shards use 2PC
Hiding Complexity
ConsistentMap<K, V>
Outline
● A simple example as motivation
● ONOS Architecture
● Distributed primitives for managing state
● APIs and a temp...
ONOS Architecture Tiers
Northbound - Application Intent Framework
(policy enforcement, conflict resolution)
OpenFlow NetCo...
ONOS Service APIs
"Southbound"
● Device
● Link
● Host
● Statistics
● Flow Rule
● Packet
● Resource
● Providers
"Northbound...
Manager
Component
ONOS Core Subsystem Structure
Adapter
Component
Adapter
Component
App
Component
ServiceAdminService
List...
Intent Framework
• Programming Abstraction
– Intents
– Compilers
– Installers
• Execution Framework
– Intent Service
– Int...
Intents
• Provide high-level interface that focuses on what
should be done rather than how it is specifically
programmed
•...
Intent Example
Host to Host Intent
Intent Example
Host to Host Intent
public final class HostToHostIntent extends ConnectivityIntent {
private final HostId o...
Intent Example
COMPILATION
Path IntentPath Intent
Host to Host Intent
Intent Compilers
• Produce more specific Intents given the
environment
• Works on high-level network objects, rather than
...
Intent Example
Host to Host Intent
public class HostToHostIntentCompiler extends ConnectivityIntentCompiler<HostToHostInte...
Intent Example
COMPILATION
INSTALLATION
Flow Rule Batch Flow Rule Batch
Flow Rule BatchFlow Rule Batch
Path IntentPath Int...
Intent Installers
• Transform Intents into device commands
• Allocate / deallocate network resources
• Define scheduling d...
Intent Example
COMPILATION
Path IntentPath Intent
Host to Host Intent
public class PathIntentInstaller implements IntentIn...
Intent Framework Design
Southbound
Physical Network
Host to Host
Intent Compiler
Path Intent
Installer
Path Intent
Install...
Intent Framework API
package org.onosproject.net.intent; // filepath: onos/core/api/net/intent/
public abstract class Inte...
Intent Manager
package org.onosproject.net.intent.impl; // filepath: onos/core/net/intent/impl
@Component
@Service
public ...
Intent Store
• Key to HA and Scale-Out
• Work is delegated to specific cluster nodes
through logical partitions based on I...
Intent Store
package org.onosproject.store.intent.impl; // filepath: onos/core/store/dist/intent/impl
@Component
@Service
...
Intent Subsystem Design
i
i
ii ii ii
(Batch) & Distribute
Delegate
(on key)
Batch & Process
compile & install
Update
submi...
Design Modularity
• Intents, Compilers, and Installers can be defined
and loaded dynamically
• Framework implements servic...
What's Next?
● Join ONOS mailing lists
○ https://wiki.onosproject.org/display/ONOS/ONOS+Mailing+Lists
○ Don’t hesitate to ...
Outline
● A simple example as motivation
● ONOS Architecture
● Distributed primitives for managing state
● APIs and a temp...
Live Demo
Outline
● A simple example as motivation
● ONOS Architecture
● Distributed primitives for managing state
● APIs and a temp...
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Tech Talk: ONOS- A Distributed SDN Network Operating System
Prochain SlideShare
Chargement dans…5
×

Tech Talk: ONOS- A Distributed SDN Network Operating System

2 843 vues

Publié le

This event takes us to the cusp of Distributed Software Development and SDN Controllers. We will be hosting Madan and Brian who have been involved in the architecture and development of ONOS (Open Network Operating System).

Synopsis

ONOS is a distributed SDN network operating system architected to provide performance, scale-out, resiliency, and well-defined northbound and southbound abstractions. Madan and Brian, both from ON.Lab, will start the talk with a deep-dive into ONOS architecture, including the key technical challenges that were solved to build this platform. They will also walk us through a live demo of building a SDN application on ONOS.

Details:

ONOS Architecture

ONOS Abstractions and Modularity

ONOS Distributed architecture

ONOS APIs and their usage

Live demo- Building a SDN app on ONOS

Speaker Bios

Madan Jampani, Distributed Systems Architect, ONOS

Madan is Distributed Systems Architect at ON.Lab focusing on the core distributed systems problems for ONOS. Prior to joining ON.Lab in Sep 2014, Madan worked at Amazon for around 10 years. At Amazon, Madan was instrumental in building several key technologies ranging from Amazon retail ordering systems, distributed data stores and shared compute clusters for running large-scale data processing and machine learning workloads.

Brian O’Connor, Lead Developer, ONOS

Brian is the ONOS Application Intent Framework lead and a core developer at ON.Lab, working on ONOS and Mininet. Brian O’Connor received Bachelor’s and Master’s degrees in Computer Science from Stanford University. At Stanford, he helped develop “An Introduction to Computer Networking,” one of Stanford’s first MOOCs (Massively Open Online Courses).

ABOUT ON.LAB and ONOS

Open Networking Lab (ON.Lab) is a non-profit organization founded by SDN inventors and leaders from Stanford University and UC Berkeley to foster an open source community for developing tools and platforms to realize the full potential of SDN. ON.Lab brings innovative ideas from leading edge research and delivers high quality open source platforms on which members of its ecosystem and the industry can build real products and solutions.

ONOS, a SDN network operating system for service provider and mission critical networks, was open sourced on Dec 5th, 2014. ONOS delivers a highly available, scalable SDN control plane featuring northbound and southbound abstractions and interfaces for a diversity of management, control, service applications and network devices. ONOS ecosystem comprises of ON.Lab, organizations who are funding and contributing to the ONOS initiative including AT&T, NTT Communications, SK Telecom, Ciena, Cisco, Ericsson, Fujitsu, Huawei, Intel, NEC; members who are collaborating and contributing to ONOS include ONF, Infoblox, SRI, Internet2, Happiest Minds, CNIT, Black Duck, Create-Net and the broader ONOS community. Learn how you can get involved with ONOS at onosproject.org.

Publié dans : Technologie
  • Soyez le premier à commenter

Tech Talk: ONOS- A Distributed SDN Network Operating System

  1. 1. ONOS Building a Distributed, Network Operating System Madan Jampani & Brian O'Connor BANV Meetup 3/16/2015
  2. 2. Outline ● A simple example as motivation ● ONOS Architecture ● Distributed primitives for managing state ● APIs and a template for implementation ● Intent Framework ● Live Demo ● Q/A
  3. 3. Problem: Set up a Flow
  4. 4. Topology Discovery
  5. 5. Path Computation
  6. 6. Path Selection
  7. 7. Switch FlowEntry S1 ... S2 ... S3 ... Compute Flow Mods
  8. 8. Switch FlowEntry S1 ... S2 ... S3 ... Install Flow Mods
  9. 9. Switch FlowEntry S1 ... S2 ... S3 ... Topology Monitoring
  10. 10. Flow Repair
  11. 11. Wishlist ● Global Network View ● Path Computation ● Flow Mod Computation / Installation ● Monitor and React to network events
  12. 12. Do all this with... ● High Availability ● At Scale
  13. 13. Wishlist ● Global Network View ● Path Computation ● Flow Mod Computation / Installation ● Monitor and React to network events ● High Availability and Scale
  14. 14. Support variety of devices and protocols
  15. 15. Wishlist ● Global Network View ● Path Computation ● Flow Mod Computation/Installation ● Monitor and React to events ● High Availability and Scale ● Extensible and Abstracted Southbound
  16. 16. Managing Complexity NAT Firewall
  17. 17. Wishlist ● Global Network View ● Path Computation ● Flow Mod Computation/Installation ● Monitor and React to events ● High Availability and Scale ● Pluggable Southbound ● Modularity and Customizability Note: We've also done this exercise on more complex, real-world use cases. You can read more about them in the wiki: https://wiki.onosproject.org/display/ONOS/ONOS+Use+Cases
  18. 18. ONOS Architecture Tiers Northbound - Application Intent Framework (policy enforcement, conflict resolution) OpenFlow NetConf . . . AppsApps Distributed Core (scalability, availability, performance, persistence) Southbound (discover, observe, program, configure)
  19. 19. Distributed Core ● Distributed state management framework ○ built for high availability and scale-out ● Different types of state require different handling ○ fully replicated and eventually consistent ○ partitioned and strongly consistent
  20. 20. Distributed Core ● Global Network View ● Scaling strong consistency
  21. 21. “Tell me about your slice?”
  22. 22. Cache “Tell me about your slice?”
  23. 23. Topology Events Distributed Topology Store Write Topology State
  24. 24. Distributed Topology Store Read Topology State
  25. 25. Cache Distributed Topology Store Read Topology State
  26. 26. Cache Distributed Topology Store Read Topology State
  27. 27. Topology as a State Machine Events are Switch/Port/Link up/down Current Topology Updated Topology apply event
  28. 28. E
  29. 29. E E E
  30. 30. E
  31. 31. F
  32. 32. F E
  33. 33. C1C2C1 1 2 3 Switch Mastership Terms We track this in a strongly consistent store
  34. 34. 2.1 2.2 2.3 2.4 2.5 2.61.41.2 1.31.1 3.2 3.33.12.7 2.8 C1C2C1 1 2 3 Switch Event Numbers
  35. 35. Partial Ordering of Topology Events Each event has a unique logical timestamp (Switch ID, Term Number, Event Number)
  36. 36. E (S1, 1, 2)
  37. 37. E E E (S1, 1, 2) (S1, 1, 2) (S1, 1, 2)
  38. 38. F (S1, 2, 1)
  39. 39. F F (S1, 2, 1) (S1, 2, 1)
  40. 40. F F (S1, 2, 1) (S1, 2, 1) (S1, 1, 2) E
  41. 41. F F (S1, 2, 1) (S1, 2, 1) (S1, 1, 2) E
  42. 42. To summarize ● Each instance has a full copy of network topology ● Events are timestamped on arrival and broadcasted ● Stale events are dropped on receipt
  43. 43. There is one additional step... What about dropped messages?
  44. 44. Anti-Entropy Lightweight, Gossip style, peer-to-peer Quickly bootstraps newly joined nodes
  45. 45. A model for state tracking If you are the observer, Eventual Consistency is the best option View should be consistent with the network, not with other views
  46. 46. Hiding the complexity EventuallyConsistentMap<K, V, T> Plugin your own timestamp generation
  47. 47. Other Control Plane state... ● Switch to Controller mapping ● Resource Allocations ● Flows ● Various application generated state In all case strong consistency is either required or highly desirable
  48. 48. Consistency => Coordination 2PC All participants need to be available Consensus Only a majority need to participate
  49. 49. State Consistency through Consensus LOG LOG LOG LOG LOG LOG LOG
  50. 50. Scaling Consistency
  51. 51. Scaling Consistency
  52. 52. Scaling Consistency
  53. 53. Consistency Cost ● Atomic updates within a shard are “cheap” ● Atomic updates spanning shards use 2PC
  54. 54. Hiding Complexity ConsistentMap<K, V>
  55. 55. Outline ● A simple example as motivation ● ONOS Architecture ● Distributed primitives for managing state ● APIs and a template for implementation ● Intent Framework ● Live Demo ● Q/A
  56. 56. ONOS Architecture Tiers Northbound - Application Intent Framework (policy enforcement, conflict resolution) OpenFlow NetConf . . . AppsApps Distributed Core (scalability, availability, performance, persistence) Southbound (discover, observe, program, configure) Northbound Abstraction: - network graph - application intents Core: - distributed - protocol independent Southbound Abstraction: - generalized OpenFlow - pluggable & extensible
  57. 57. ONOS Service APIs "Southbound" ● Device ● Link ● Host ● Statistics ● Flow Rule ● Packet ● Resource ● Providers "Northbound" ● Topology ● Path ● Intent "Core" ● Core ● Application ● Cluster ● Communication ● Event Delivery ● Storage ● Leadership ● Mastership ...
  58. 58. Manager Component ONOS Core Subsystem Structure Adapter Component Adapter Component App Component ServiceAdminService Listener notify command command sync & persist add & remove query & command App Component Adapter Component Manager Component AdapterRegistry Adapter AdapterService ServiceAdminService Listener notify register & unregister command command sensing add & remove query & command Store Store Protocols sync & persist Adapter Component AdapterRegistry Adapter AdapterService register & unregistersensing Protocols
  59. 59. Intent Framework • Programming Abstraction – Intents – Compilers – Installers • Execution Framework – Intent Service – Intent Store
  60. 60. Intents • Provide high-level interface that focuses on what should be done rather than how it is specifically programmed • Abstract network complexity from applications • Extend easily to produce more complex functionality through combinations of other intents
  61. 61. Intent Example Host to Host Intent
  62. 62. Intent Example Host to Host Intent public final class HostToHostIntent extends ConnectivityIntent { private final HostId one; private final HostId two; public HostToHostIntent(ApplicationId appId, HostId one, HostId two); public HostToHostIntent(ApplicationId appId, Key key, HostId one, HostId two, TrafficSelector selector, TrafficTreatment treatment, List<Constraint> constraints); }
  63. 63. Intent Example COMPILATION Path IntentPath Intent Host to Host Intent
  64. 64. Intent Compilers • Produce more specific Intents given the environment • Works on high-level network objects, rather than device specifics • “Stateless” – free from HA / distribution concerns interface IntentCompiler<T extends Intent> { List<Intent> compile(T intent); }
  65. 65. Intent Example Host to Host Intent public class HostToHostIntentCompiler extends ConnectivityIntentCompiler<HostToHostIntent> { @Override public List<Intent> compile(HostToHostIntent intent, ...) { Host one = hostService.getHost(intent.one()); Host two = hostService.getHost(intent.two()); // compute paths Set<Path> paths = pathService.getPaths(intent.one(), intent.two(), intent.constraints()); // select paths Path pathOne = bestPath(intent, paths); Path pathTwo = invertPath(pathOne); // reverse path using same links // create intents PathIntent fwdPath = createPathIntent(pathOne, one, two, intent); PathIntent revPath = createPathIntent(pathTwo, two, one, intent); return Arrays.asList(fwdPath, revPath); } }
  66. 66. Intent Example COMPILATION INSTALLATION Flow Rule Batch Flow Rule Batch Flow Rule BatchFlow Rule Batch Path IntentPath Intent Host to Host Intent
  67. 67. Intent Installers • Transform Intents into device commands • Allocate / deallocate network resources • Define scheduling dependencies for workers • “Stateless” interface IntentInstaller<T extends Intent> { List<Collection<FlowRuleOperation>> install(T intent); List<Collection<FlowRuleOperation>> uninstall(T intent); List<Collection<FlowRuleOperation>> replace(T oldIntent, T newIntent); }
  68. 68. Intent Example COMPILATION Path IntentPath Intent Host to Host Intent public class PathIntentInstaller implements IntentInstaller<PathIntent> { @Override public List<Collection<FlowRuleOperation>> install(PathIntent intent) { LinkResourceAllocations allocations = allocateResources(intent); Set<FlowRuleOperation> rules = Sets.newHashSet(); for (Link link : intent.path().links()) { FlowRule rule = createFlowRule(link, intent); rules.add(new FlowRuleOperation(rule, FlowRuleOperation.Type.ADD)); } return Lists.newArrayList(rules); @Override public List<Collection<FlowRuleOperation>> uninstall(PathIntent intent) {...} @Override public List<Collection<FlowRuleOperation>> replace(PathIntent oldIntent, PathIntent newIntent) {...} }
  69. 69. Intent Framework Design Southbound Physical Network Host to Host Intent Compiler Path Intent Installer Path Intent Installer Applications Intent Service API IntentExtension ServiceAPI Intent Manager Intent Store Intent Objective Tracker Intent Worker Core Topology API Resource API …Flow Rule Service API
  70. 70. Intent Framework API package org.onosproject.net.intent; // filepath: onos/core/api/net/intent/ public abstract class Intent { private final IntentId id; // internal, unique ID private final ApplicationId appId; // originating application private final Key key; // user define key for this "policy" private final Collection<NetworkResource> resources; // constructors and getters } public interface IntentService { void submit(Intent intent); void withdraw(Intent intent); Intent getIntent(Key key); // other methods and listener registration }
  71. 71. Intent Manager package org.onosproject.net.intent.impl; // filepath: onos/core/net/intent/impl @Component @Service public class IntentManager implements IntentService, IntentExtensionService { // Dependencies protected CoreService coreService; // used to generate blocks of unique, internal intent IDs protected IntentStore store; // stores all intents in the system; // delegates work to be be done to master protected ObjectiveTrackerService trackerService; // listens to network events and // triggers recomputation when required protected EventDeliveryService eventDispatcher; // used for managing listeners and // dispatching events protected FlowRuleService flowRuleService; // responsible for installing flow rules and // reporting success or failure // ... implementation of service methods }
  72. 72. Intent Store • Key to HA and Scale-Out • Work is delegated to specific cluster nodes through logical partitions based on Intent key • Execution steps designed to be idempotent – However, when resources are required, duplicate request will be detected and handled • Failures can be detected by store, and work can be reassigned by electing new leader for partition
  73. 73. Intent Store package org.onosproject.store.intent.impl; // filepath: onos/core/store/dist/intent/impl @Component @Service public class GossipIntentStore extends AbstractStore<IntentEvent, IntentStoreDelegate> implements IntentStore { private EventuallyConsistentMap<Key, IntentData> currentMap; private EventuallyConsistentMap<Key, IntentData> pendingMap; // Dependencies protected ClusterService clusterService; // provides information about nodes in cluster protected ClusterCommunicationService clusterCommunicator; // provides communication // mechanism for map updates protected PartitionService partitionService; // gets partition for Intent by key; // elects and maintains leader for each partition // ... implementation of IntentStore methods }
  74. 74. Intent Subsystem Design i i ii ii ii (Batch) & Distribute Delegate (on key) Batch & Process compile & install Update submit / withdraw add process Update store write store write notify i i i i App StoreManager Flow, Topology, etc. Events retry
  75. 75. Design Modularity • Intents, Compilers, and Installers can be defined and loaded dynamically • Framework implements service API, so the entire framework can be swapped out • Each component also implements an internal API, so they can be replaced as desired
  76. 76. What's Next? ● Join ONOS mailing lists ○ https://wiki.onosproject.org/display/ONOS/ONOS+Mailing+Lists ○ Don’t hesitate to engage with ONOS developers & community ● Try some of the tutorials ○ https://wiki.onosproject.org/display/ONOS/Tutorials+and+Walkthroughs ● Download the source code: ○ https://gerrit.onosproject.org/ (main developer repository) ○ https://github.com/opennetworkinglab/onos (read-only mirror) ● Check out the ONOS API Javadoc ○ http://api.onosproject.org/ ● Fix (or file) a bug ○ https://jira.onosproject.org/ ● Visit the main project page and wiki ○ http://onosproject.org/ and https://wiki.onosproject.org/
  77. 77. Outline ● A simple example as motivation ● ONOS Architecture ● Distributed primitives for managing state ● APIs and a template for implementation ● Intent Framework ● Live Demo ● Q/A
  78. 78. Live Demo
  79. 79. Outline ● A simple example as motivation ● ONOS Architecture ● Distributed primitives for managing state ● APIs and a template for implementation ● Intent Framework ● Live Demo ● Q/A

×