SDN控制器ONOS架構—Vecloud

ONOS是一個採用OSGI技術來管理子專案的SDN控制器開源專案，在最初設計時有這麼幾個目標是明確的：
1.程式碼模組化：支援把新的功能作為新的獨立單元引入
2.特性可配置：無論是在啟動還是執行時，支援動態載入和解除安裝特性
3.協議無關：應用不需要和具體的協議庫和實現繫結
模組化的實現：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子系統-允許應用程式監聽從網路裝置接收到的資料包，並通過一個或多個網路裝置向網路傳送資料包。
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中找到的資訊來構建的。
Vecloud是一家面向企業提供雲交換網路服務為核心業務的技術創新企業，在全球的資料中心節點30個，POP節點超過200個，服務的大客戶超過300個，涉及金融、網際網路、遊戲、AI、教育、製造業、跨國企業等行業領域。http://www.vecloud.com/products/cloudconnect.html