tom

Added javadocs to the overview.html file to explain the overall software structure a bit better.

1 <html> 1 <html>
2 <body> 2 <body>
3 -<img src="doc-files/onos-tiers.png" alt="ONOS architecture tiers"><br> 3 +<p>
4 -ONOS architecture is strictly segmented into protocol-agnostic system core and 4 + ONOS architecture is strictly segmented into a <em>protocol-agnostic system
5 -protocol-aware providers tiers. 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>
6 9
7 -<em>More information to come later...</em> 10 +<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>
17 +
18 +<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
31 + {@link org.onlab.onos.net.trivial.device.impl.SimpleDeviceManager DeviceManager},
32 + 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>
42 + On the south-bound side, the core {@link org.onlab.onos.net.trivial.device.impl.SimpleDeviceManager DeviceManager}
43 + 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
55 + {@link org.onlab.onos.net.trivial.device.impl.SimpleDeviceStore DeviceStore}.
56 +</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>
8 65
9 </body> 66 </body>
67 +</html>
......