Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
- Code Modularity : It should be possible to introduce new functionalities as self-contained units.
- Configurability : It should be possible to load and unload various features, wether whether it be at startup or at runtime.
- Separation of Concern : There should be clear boundaries between subsystems to facilitate modularity.
- Protocol agnosticism : It, and its applications, should not be bound to specific protocol libraries or implementations.
...
| Info |
|---|
For implementation details of the source tree and POM file organization, refer to [Appendix C] of the Developer's Guide. |
...
The remaining sections of the Architecture Guide elaborate on the design and implementation of the subsystems that make up the above-mentioned tiers, and the OpenFlow provider that ships with ONOS.
Some terms and conventions used in the rest of the guide are:
- "infrastructure" refers and "network" refer to the network controlled by ONOS, and may be physical, virtual, or emulated.
- A "device" is a network node, such as a switch, router, access point, or middle box. They usually have multiple interfaces, and may be software or hardware.
- A "path" is a set of one or more links. The links must be adjacent.
- Proper nouns, such as "Network" and "Link", are ONOS's representations of the infrastructure component of the same name.
It is impossible to avoid referring back to the codebase when we speak of implementation. The following conventions are used with regards to code:
- Class, Interface, and Object names are monotype, e.g.
DeviceManager. - Method names are monotype and end in parenthesisparentheses, e.g.
emit(). - Inlined package names are surrounded by square brackets, e.g.
[org.onlab.onos.net.DeviceId]
...
Home : Architecture Guide
Next : System Components
...