Added javadocs to the overview.html file to explain the overall software structure a bit better.
Showing
2 changed files
with
62 additions
and
4 deletions
68.4 KB
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> | ... | ... |
-
Please register or login to post a comment