| Thomas Vachuska | 4f1a60c | 2014-10-28 13:39:07 -0700 | [diff] [blame] | 1 | <!-- |
| 2 | ~ Copyright 2014 Open Networking Laboratory |
| 3 | ~ |
| 4 | ~ Licensed under the Apache License, Version 2.0 (the "License"); |
| 5 | ~ you may not use this file except in compliance with the License. |
| 6 | ~ You may obtain a copy of the License at |
| 7 | ~ |
| 8 | ~ http://www.apache.org/licenses/LICENSE-2.0 |
| 9 | ~ |
| 10 | ~ Unless required by applicable law or agreed to in writing, software |
| 11 | ~ distributed under the License is distributed on an "AS IS" BASIS, |
| 12 | ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 13 | ~ See the License for the specific language governing permissions and |
| 14 | ~ limitations under the License. |
| 15 | --> |
| tom | cfde062 | 2014-09-09 11:02:42 -0700 | [diff] [blame] | 16 | <html> |
| 17 | <body> |
| tom | 5717f39 | 2014-09-13 15:50:43 -0700 | [diff] [blame] | 18 | <p> |
| 19 | ONOS architecture is strictly segmented into a <em>protocol-agnostic system |
| 20 | core</em> tier and the <em>protocol-aware providers</em> tier as shown in |
| 21 | the figure below:<br> |
| 22 | <img src="doc-files/onos-tiers.png" alt="ONOS architecture tiers"> |
| 23 | </p> |
| tom | cfde062 | 2014-09-09 11:02:42 -0700 | [diff] [blame] | 24 | |
| tom | 5717f39 | 2014-09-13 15:50:43 -0700 | [diff] [blame] | 25 | <p> |
| 26 | The <em>ONOS core</em> is responsible for tracking information about the |
| 27 | network environment and distributing it to the applications either |
| 28 | synchronously via query or asynchronously via listener callbacks. The |
| 29 | core is also responsible for persisting select state and synchronizing state |
| 30 | among the cluster peers. |
| 31 | </p> |
| tom | cfde062 | 2014-09-09 11:02:42 -0700 | [diff] [blame] | 32 | |
| tom | 5717f39 | 2014-09-13 15:50:43 -0700 | [diff] [blame] | 33 | <p> |
| 34 | The <em>protocol-aware providers</em> are responsible for interacting with |
| 35 | the network environment using various control and configuration protocols |
| 36 | and supplying such sensory data to the core. Some providers may also need to |
| 37 | accept control edicts from the core and apply them to the environment |
| 38 | using the appropriate protocol-specific means. |
| 39 | </p> |
| 40 | |
| 41 | <p> |
| 42 | The following diagram describes a general structure of each ONOS subsystem: |
| 43 | <br> |
| 44 | <img src="doc-files/onos-subsystem.png" alt="ONOS subsystem structure"><br> |
| 45 | For example, the device-subsystem comprises of a core |
| Brian O'Connor | abafb50 | 2014-12-02 22:26:20 -0800 | [diff] [blame^] | 46 | {@link org.onosproject.net.device.impl.DeviceManager}, |
| tom | 5717f39 | 2014-09-13 15:50:43 -0700 | [diff] [blame] | 47 | which exposes a north-bound |
| Brian O'Connor | abafb50 | 2014-12-02 22:26:20 -0800 | [diff] [blame^] | 48 | {@link org.onosproject.net.device.DeviceService} through which applications or other core components |
| tom | 5717f39 | 2014-09-13 15:50:43 -0700 | [diff] [blame] | 49 | can learn about the global infrastructure device inventory and through |
| Brian O'Connor | abafb50 | 2014-12-02 22:26:20 -0800 | [diff] [blame^] | 50 | which they can also subscribe for asynchronous {@link org.onosproject.net.device.DeviceEvent} |
| 51 | notifications via the {@link org.onosproject.net.device.DeviceListener} mechanism. A set of |
| 52 | administrative actions can be performed via {@link org.onosproject.net.device.DeviceAdminService}, |
| tom | 5717f39 | 2014-09-13 15:50:43 -0700 | [diff] [blame] | 53 | e.g. setting mastership role, removing a decommissioned device. |
| 54 | </p> |
| 55 | |
| 56 | <p> |
| Brian O'Connor | abafb50 | 2014-12-02 22:26:20 -0800 | [diff] [blame^] | 57 | On the south-bound side, the core {@link org.onosproject.net.device.impl.DeviceManager} |
| 58 | exposes a {@link org.onosproject.net.device.DeviceProviderRegistry} through which any number of |
| 59 | {@link org.onosproject.net.device.DeviceProvider} entities can register and in turn obtain a |
| 60 | {@link org.onosproject.net.device.DeviceProviderService}. Device and port information can then be |
| tom | 5717f39 | 2014-09-13 15:50:43 -0700 | [diff] [blame] | 61 | supplied to the core by each provider through the provider service issued |
| Brian O'Connor | abafb50 | 2014-12-02 22:26:20 -0800 | [diff] [blame^] | 62 | to them. When a provider unregisters, its {@link org.onosproject.net.device.DeviceProviderService} |
| tom | 5717f39 | 2014-09-13 15:50:43 -0700 | [diff] [blame] | 63 | will be invalidated and can no longer be used for interacting with the |
| 64 | core. |
| 65 | </p> |
| 66 | |
| 67 | <p> |
| 68 | Within the core, the tasks of indexing, persisting and synchronizing the |
| 69 | global device and port state with the cluster peers falls on the |
| Brian O'Connor | abafb50 | 2014-12-02 22:26:20 -0800 | [diff] [blame^] | 70 | {@link org.onosproject.net.device.DeviceStore}. |
| tom | 5717f39 | 2014-09-13 15:50:43 -0700 | [diff] [blame] | 71 | </p> |
| 72 | |
| 73 | <p> |
| 74 | Similar structure applies to the link subsystem, host subsystem and others. |
| 75 | </p> |
| 76 | |
| 77 | <p> |
| 78 | <em>More information to come later...</em> |
| 79 | </p> |
| 80 | |
| 81 | </body> |
| 82 | </html> |