Date: Thu, 28 Mar 2024 12:35:34 +0000 (UTC) Message-ID: <1977956357.755.1711629334278@ip-10-30-146-46.us-west-2.compute.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_754_1840247168.1711629334275" ------=_Part_754_1840247168.1711629334275 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This section provides a high-level view of ONOS, and its general= design points.
ONOS is a multi-module project whose modules are managed as OSGi bundles= . ONOS is designed with a few goals in mind:
We take a succinct look at each below.
The project is comprised of a set of sub-projects, each with their own s= ource tree that can be built independently. To do this, the ONOS sourc= e tree is organized in a hierarchical fashion that takes advanta= ge of Maven's notion of a hierarchical POM file organization. Each sub-proj= ect has its own pom.xml file, and intermedi= ate directories have parent aggregate pom.xml&nb= sp;files. The latter contains shared dependencies and configurations for th= ose sub-projects, enabling them to be built independent of unrelated sub-pr= ojects. The ONOS root contains the top-level pom file used to build th= e full project and all of its modules.
ONOS is written to leverage Apache Karaf as its OSGi framework. In addit= ion to dependency resolution at startup and dynamic module loading at runti= me, Karaf provides the following:
ONOS is partitioned into :
Each of the above are tiers in a layered architecture, where network-fac= ing modules interact with the core via a southbound (provider) API= , and the core with the applications via the northbound (consumer) API<= /em>. The southbound API defines<= /span> protocol-neutral means to relay network= state information to the core, and for the core to interact with the netwo= rk via the network-facing modules. The northbound API provides ap= plications with abstractions that describe network components and prop= erties, so that they may define their desired actions in terms of poli= cy instead of mechanism.
If ONOS needs to support a new p= rotocol, it should be possible to build a new network-facing module ag= ainst the southbound API as a plugin that may be loaded into the system. = span>
The remaining sections of the Architecture Guide elaborate on the design= and implementation of the subsystems that make up the above-mentioned tier= s, and the OpenFlow provider that ships with ONOS.
Some terms and conventions used in the rest of the guide are:
It is impossible to avoid referr= ing back to the codebase when we speak of implementation. The following con= ventions are used with regards to code:
DeviceManag=
er.
emit(=
).
[org.onlab.onos.net.DeviceId]=
=
=
=
Home : Architecture Guide
Next : System Components
=
=