blob: 1c66548926531e184d1cb9a63596c15cae2b3cb9 [file] [log] [blame]
tomcfde0622014-09-09 11:02:42 -07001<html>
2<body>
tom5717f392014-09-13 15:50:43 -07003<p>
4 ONOS architecture is strictly segmented into a <em>protocol-agnostic system
5 core</em> tier and the <em>protocol-aware providers</em> tier as shown in
6 the figure below:<br>
7 <img src="doc-files/onos-tiers.png" alt="ONOS architecture tiers">
8</p>
tomcfde0622014-09-09 11:02:42 -07009
tom5717f392014-09-13 15:50:43 -070010<p>
11 The <em>ONOS core</em> is responsible for tracking information about the
12 network environment and distributing it to the applications either
13 synchronously via query or asynchronously via listener callbacks. The
14 core is also responsible for persisting select state and synchronizing state
15 among the cluster peers.
16</p>
tomcfde0622014-09-09 11:02:42 -070017
tom5717f392014-09-13 15:50:43 -070018<p>
19 The <em>protocol-aware providers</em> are responsible for interacting with
20 the network environment using various control and configuration protocols
21 and supplying such sensory data to the core. Some providers may also need to
22 accept control edicts from the core and apply them to the environment
23 using the appropriate protocol-specific means.
24</p>
25
26<p>
27 The following diagram describes a general structure of each ONOS subsystem:
28 <br>
29 <img src="doc-files/onos-subsystem.png" alt="ONOS subsystem structure"><br>
30 For example, the device-subsystem comprises of a core
tomc104d282014-09-19 10:57:55 -070031 {@link org.onlab.onos.net.trivial.device.impl.DeviceManager},
tom5717f392014-09-13 15:50:43 -070032 which exposes a north-bound
33 {@link org.onlab.onos.net.device.DeviceService} through which applications or other core components
34 can learn about the global infrastructure device inventory and through
35 which they can also subscribe for asynchronous {@link org.onlab.onos.net.device.DeviceEvent}
36 notifications via the {@link org.onlab.onos.net.device.DeviceListener} mechanism. A set of
37 administrative actions can be performed via {@link org.onlab.onos.net.device.DeviceAdminService},
38 e.g. setting mastership role, removing a decommissioned device.
39</p>
40
41<p>
tomc104d282014-09-19 10:57:55 -070042 On the south-bound side, the core {@link org.onlab.onos.net.trivial.device.impl.DeviceManager}
tom5717f392014-09-13 15:50:43 -070043 exposes a {@link org.onlab.onos.net.device.DeviceProviderRegistry} through which any number of
44 {@link org.onlab.onos.net.device.DeviceProvider} entities can register and in turn obtain a
45 {@link org.onlab.onos.net.device.DeviceProviderService}. Device and port information can then be
46 supplied to the core by each provider through the provider service issued
47 to them. When a provider unregisters, its {@link org.onlab.onos.net.device.DeviceProviderService}
48 will be invalidated and can no longer be used for interacting with the
49 core.
50</p>
51
52<p>
53 Within the core, the tasks of indexing, persisting and synchronizing the
54 global device and port state with the cluster peers falls on the
tomc104d282014-09-19 10:57:55 -070055 {@link org.onlab.onos.net.device.DeviceStore}.
tom5717f392014-09-13 15:50:43 -070056</p>
57
58<p>
59 Similar structure applies to the link subsystem, host subsystem and others.
60</p>
61
62<p>
63 <em>More information to come later...</em>
64</p>
65
66</body>
67</html>