ONOS 設計目標
ONOS是一個採用OSGI技術來管理子項目的SDN控制器開源項目，在最初設計時有這麼幾個目標是明確的：
- 代碼模塊化：支持把新的功能作爲新的獨立單元引入
- 特性可配置：無論是在啓動還是運行時，支持動態加載和卸載特性
- 協議無關：應用不需要和具體的協議庫和實現綁定
模塊化的實現：ONOS項目由一組子項目組成，每個項目都有自己的源代碼樹，可以獨立構建。爲此，ONOS的源碼採用分層的方式來組織以方便利用Maven的級聯POM文件組織。每個子項目都有自己的pom.xml文件和目錄，子pom.xml文件會繼承父Pom文件的共享依賴項和配置，使它們能夠獨立於不相關的子項目構建。Root目錄包含用於建立完整的項目及其所有模塊的頂層POM文件。
特性可配置：ONOS使用Karaf作爲其OSGI框架，除了在運行時的動態模塊加載和啓動時的依賴解析，Karaf還支持以下幾個特性。
- 支持使用標準的JAX-RS API來開發安全的API接口
- 支持將特性定義爲一組Bundle來進行集中的自定義設置
- 對代碼包有嚴格的語義版本聲明，包括第三方依賴
- 有易擴展的命令行框架，支持本地和遠端的SSH控制檯登陸
- 支持不同日誌級別的記錄
協議無關，ONOS 被劃分爲以下幾個部分：
- 和網絡交互的協議感知模塊
- 協議無關的系統Core，跟蹤和服務網絡狀態信息
- 基於Core提供的系統信息來進行消費和操作的應用
上面的每一層都是分層體系結構，其中面向網絡的模塊通過一個南向（提供者）API與Core進行交互，Core與應用程序通過北向（消費者）API進行交互。南向API定義了協議中立的手段將網絡狀態信息傳遞給核心，Core通過面向網絡的模塊與網絡設備交互。北向API爲應用程序提供了描述網絡組件和屬性的抽象，以便它們可以根據策略定義其所需的動作。
系統組件
服務是一個功能單元，它由不同層的多個組件作爲軟件堆棧創建垂直切片。我們把組成服務的組件的集合稱爲子系統。
ONOS定義了不同的子系統：
- 設備子系統-管理基礎設施設備的庫存。
- 鏈路子系統-管理基礎設施鏈接的庫存。
- 主機子系統-管理終端站主機及其在網絡上的位置的庫存。
- 拓撲子系統-管理網絡圖視圖的時間順序快照。
- path子系統計算/發現基礎設施設備之間或端站的主機採用最新的拓撲圖快照之間的路徑。
- FlowRule子系統-管理安裝在基礎設備的match/action流表項和統計流量。
- Packet子系統-允許應用程序監聽從網絡設備接收到的數據包，並通過一個或多個網絡設備向網絡發送數據包。
下圖闡述了現在ONOS所包含的各個子系統：
子系統結構
每個子系統的組件駐留在其中的三個主要層次，可以由一個或多個java所實現的接口標識。
下圖概述了子系統組件之間的關係。圖中的頂部和底部虛線表示分別由北向和南向API創建的層間邊界。
Provider
該堆棧的最底層是Provider組件，Provider接口通過協議特定的庫和底層設備打交道，並通過Provider Service接口與Core交互。
協議感知Providers負責使用各種控制和配置協議與網絡環境交互，並向Core提供服務特定的感知數據。Provider也可以從其他子系統收集數據，將它們轉換成特定於服務的數據。
Provider可能還需要從Core接受控制命令應用並通過適當的網絡協議具體手段應用到網絡中。這些都是通過Provider接口將這些內容送入Provider組件。
Provider ID
一個Provider與特定的Providerid相關。providerid的主要目的是提供一個Provider族的外部身份，這可以使設備和其他實體模型保持與負責他們的存在Provider相關聯，甚至在Provider加載/卸載操作之後。
Providerid攜帶一個URI方案名稱允許鬆散的配對與從另一個供應商的家庭提供設備，而這沒有訪問提供商本身是可能的。
Multiple Providers
子系統可以與多個Provider關聯。在這種情況下，Provider被指定爲主要的或附屬的。主Provider擁有與服務相關聯的實體，輔助提供者將其信息作爲覆蓋提供信息。如果任何覆蓋導致與底層信息衝突，則此方法給予主Provider優先權。設備子系統是支持多個提供者的此類服務之一。
Manager
Manager是駐留在覈心中的組件，其接收來自Provider的信息，並將其提供給應用程序和其他服務。它暴露了幾個接口：
- Northbound Service interface 應用程序或其他核心組件可以通過該接口瞭解特定方面的網絡狀態。
- AdminService interface以管理員命令應用到網絡或系統的狀態。
- Southbound ProviderRegistry interface 通過該接口Provider可以註冊到Manager中，通過它可以和Manager進行交互。
- Southbound ProviderService interface 提供給已經註冊的Provider
Manager服務接口的消費者可以同步的查詢Service的信息，也可以異步的作爲一個事件偵聽器（例如，通過使用listenerservice接口註冊要監聽的事件並實現相關的EventListener interface）。
Store
Store的具體實現和Core裏面的Manager有很強的相關性，Store需要索引，持久化以及同步Manager收到的信息，這包括分佈式ONOS多實例間的一致性和魯棒性的保障，
Application
應用通過AdminService和Service接口來消費和操作Manager聚合的信息，應用程序具有廣泛的功能，這裏面就包括在Web瀏覽器中顯示網絡拓撲，爲網絡流量設置路徑
Application ID
每個應用都有一個唯一的Application ID，這個標識用於追蹤應用相關的上下文（任務和目標 比如Intent和FlowRule），爲了獲得一個有效的ID，應用需要註冊到CoreService，註冊他們的名字來進行反向域名解析，比如：org.onlab.onos.fwd
Events and Descriptions
兩個在ONOS中分佈的基本信息單元是事件和描述。與服務一樣，事件和描述與特定的網絡元素和概念相關聯。兩者都是一旦創建就不會改變的。
Descriptions
Descriptions用於在南向的API上傳遞關於元素的信息。例如，一個HostDescription包含一個主機的MAC和IP地址，在網絡中的位置信息（VLAN ID和設備/端口的連接點）。Descriptions通常是由一個或多個模型對象組成。
Events
Manager使用Event通知其Listener關於網絡中的變化，並通過Store通知相關的在分佈式設置中的Peer。一個事件由一個事件類型和一個由對象模型構成的主題組成。例如，一個device event可通知devicelisteners，Device（主題）已經被發現（device_added），失去了（device_removed），或某一方面改變了（device_updated）。
Event dispatch
事件是由Store基於Manager的輸入產生的。一旦產生，事件就會通過storedelegate接口被分發到感興趣的聽衆，最終調用event deliveryservice。從本質上講，Store Delegate把事件從Store中取出，event deliveryservice確保事件僅爲感興趣的聽衆接收。由於它們之間相互作用的方式，這兩個組件駐留在Manager中並由那裏的Manager提供storedelegate來做具體實現。
Event Listeners
Event Listener是實現EventListener接口的任何組件。 EventListener的子接口被按照監聽事件的類型進一步的分類。典型的Event listener實現模式是將事件偵聽器作爲Manager或應用程序的內部類，從中從接收到的事件調用相應的服務。這限制了事件處理邏輯不需要對子系統外部進行暴露。
Network representations
模型對象是ONOS 協議無關方式來表示各種網絡元素和屬性。事件將這些表示作爲它們的主體。這些表示是由Core從Description中找到的信息來構建的。