ONF組織的SDN架構文檔——概述(一)

1.適用範圍

        這個文檔描述了SDN架構。文檔的目的是爲ONF工作組未來的工作做詳細指導和說明,同時也可以作爲ONF對外交流的一個參考文檔。它的姊妹文檔(框架文檔)描述了ONF想要達到的設計目標。此文檔只是從一個較高的角度描述了達到此目標的一些方法。

       SDN架構從一個較高的角度出發,給控制器指定了參考點和接口。架構描述了大量SDN控制器和NEnetwork element)內部的功能。其中架構圖中所示的功能模塊並不是都要求實現。且內部的核心功能模塊的接口也並沒有指定。

        SDN控制器和NE具體指定的行爲只限定在需要互操性的部署實施上。注意,此架構並不指定接口間具體使用的通信協議。

*注:接口間備選的協議包括OpenFlow switch(OFS)[2]和OF-Config(OFC)[3]

        SDN架構允許一個SDN控制器管理大量數據層資源。大量不同數據層的存在,SDN提供一種可能性來同一、簡化不同資源的配置工作。

此架構也意識到,如果SDN成功,它必須能在現存的、有很多不同參與者的環境中能夠可實施,如包含不同組織、企業的環境。這就引起了有關策略和信息共享的安全邊界的新的需求。現實世界中有很多約束條件,如與現存的企業和業務的支持系統共存的需求,以及其他類似的管理和控制技術領域。在不太複雜環境中,例如有限規模的企業網絡,從原有的架構中借鑑並選取適當功能子集形成自己的架構。

        SND架構建議,當使用一些通用的模型和機制可能會減少標準化、集成、驗證工作時,建議使用它們,這就意味着在行得通時儘量使用現存的標準或者公認的好的做法。

        一個系統架構把一個系統分割成不同的模塊,通常用於控制複雜度,用於允許獨立運行和軟件代碼重用,或者用於滿足其他技術或商業目標。然而,沒有中性的設計。選擇使用組件劃分的方式(其中組件間的接口已經定義且組件間的協議是開放的或專有的)會對最終交付給終端用戶的服務的種類產生深遠影響。因此一個架構必須選擇並決定如何把系統分割成多個模塊,這些方式和理由都在此文介紹。架構應是基於合適的原則而不是拘泥於細節來建立的,這樣做是爲了以後在ONF工作組或應用中,當需要做大量的各種決定時能夠通過之前早已指定的、清晰闡述的原則,使得做決定更加的容易便利。與此同時,架構也認識到, SDN應對的環境十分複雜,需要進一步的擴展和說明。

 

這個文檔具體的目標包括:

a)定義一個SDN架構

b)提供信息模型開發的基礎

c)詳細的描述實體,允許函數和接口定義的派生

d)提供一些指導和一個在ONF工作組中活動的框架

e)作爲一個參考手冊,關於擴展,錯誤,遺漏,和其他合適的變化

f)作爲一個評估和比較各種聲明是符合SDN架構的各種解決方案的一個參考。

g)促進SDN技術定向於工程師、架構師、和解決方案專家

h) 在整個SDN社區提供更多可被利用的價值

 

2 定義、縮寫以及約定

2.1 定義

2.2 縮寫詞

2.3 約定

3 SDN概述

        這部分用兩種形式描述此架構,圖3.1是個從高的視角來描述架構的概況,圖3.2則儘可能簡潔的描述架構的關鍵的地方。剩下的部分講解此架構的起源,解釋此架構,及擴展引用。


3.1描述性概況

        SDN的目標是提供開放的接口,利用這些接口來開發軟件,這些軟件可以控制網絡連通性和網絡流量,同時可以實現對流量進行監測、調整。這些基本功能可能被抽象成任意的網絡服務,其中的一些目前可能不明確。



        最初的觀點認爲SDN分爲基礎結構層,控制層,應用層(在本文中將使用數據層,控制層和應用層代替)。基礎結構層包括網絡單元(NE),SDN控制層通過它的南向接口使用下層NE提供的服務。應用層通過控制層的北向接口(NBIs)發送請求。控制層作用是接受應用層的應用請求後啓動相應的底層NE完成應用響應。由於網絡資源有限,SDN會根據算法解決資源競爭問題。

        上述概念需要進一步改進,此文定義了一些 函數、接口、組件,解釋他們之間的關係,並指導信息模型的開發,但是不過分細化具體規範。

        一些概念上的修正表明,一些控制不可避免的仍然存在於各個層中,而不是全部在控制層其它層沒有。但是我們感興趣的是一個SDN控制器和它相鄰的實體。同一水平的羣組稱爲plane,而網絡中使用layer(層)術語。

        圖3.2使用修正過的術語,添加了管理功能,而一些的簡化的SDN模型沒有管理模塊儘管一些管理函數可以被應用層接口(A-CPI)而替代,但是一些管理功能是必不可少了。如在數據層,在最初建立NE、設定SDN控制部件、配置SDN控制器時是就需要管理功能,在控制層,管理模塊就需要配置一些策略,來界定對SDN應用的控制範圍,同時管理模塊還需要監視系統運行狀態。在應用層,管理模塊一般用於配置SLAs(service level agreements),在所有層,管理模塊配置SAs(security associations),使得各個分佈式模塊能安全的進行相互交流。



        上圖中在通過接口相互傳遞的信息通過建模形成一個與協議無關的實例。

        SDN預測未來客戶端應用可能會直接擁有SDN控制器的訪問權限,動態和細粒度的控制網絡資源。

        意識到供應商和客戶之間有一個商業邊界的可能性,因此通過SDN架構確定出一個SDN控制器和使用此控制器的應用之間的商業或組織機構界限,這是很重要的。因爲提供商和客戶是在不同的信任域中。

        不同顏色表示不同信任域,每信任域有自帶的管理功能。信任域在邏輯上可以擴展成其他信任域的組成部分。意思是說如下圖,綠和紅在藍色信任域中,邏輯上擴展意思是說藍色區域的管理員管理在其中的綠色和紅色信任域的代碼的安裝和管理。


        agent蘊含着共享和虛擬化底層資源的含義

        agent是指NEs的端口由SDN控制的(而不是混合或繼承的端口)或者是指面向SDN應用的虛擬網絡的細節是由SDN控制的,但是同時要使一個客戶的服務於另一個客戶的相互隔離。在SDN控制器中,不同的代理通過網絡在橫向角度從不同程度的抽象,在縱向角度不同的函數集,來顯示其控制作用。SDN控制邏輯的任務是對來自所有SDN應用的網絡請求進行映射和仲裁,然後轉化成相應的控制NE資源的命令(NE資源必須能被該代理使用)。NE和SDN控制器中的協調器安裝客戶特有的資源和來自管理器的策略。混合代理商可能同時在任意個NE和SDN控制器中存在,但是邏輯上只有一個管理器接口,因此每一NE和SDN控制器中只有一個協調器。

        Clause4中將進一步思考SDN原理的含義和應用,然後介紹一些重要的實體,他們的函數和交互包含此架構。

        因爲SDN控制器是在此架構的中間位置clause5將誇大控制層函數和接口,clause6介紹應用注意事項。

        在【4】附錄中的文章也總結了ONF SND 架構 本文的架構和引文中有矛盾地方以本架構爲先。

3.2對架構的簡明描述

        Figure介紹了SDN架構主要的構件和接口。對於構件的物理實現本架構沒有說明。


數據層(Data Plane)

數據層包含是一個包含一個或多個NE的集合,每個NE是一個流量轉發或流量處理的資源集合

資源指對底層物理實體的抽象。

控控制層(Controllerplane)

控制器的集合。每個控制器有獨佔一組資源的權利,這些資源是由數據層中一個或多個NE提供。

Clause4.3.5介紹資源如何按照盡最大努力或先來先服務的原則進行共享的。

SDN控制器可以額外的添加接口。

SDN控制器最基本的功能是響應應用的請求,同時使得各個應用相互隔離,

爲了實現此功能,一個SDN控制器可能和其他的對等的控制器、附屬控制器、或非SDN的環境等交換信息。

SDN控制器一個通用但是不是必需的功能是在一個反饋環路中擔當控制單元的,對從錯誤中恢復、對重新優化資源配置、或其他事件等網絡事件作出響應

應用層(Application plane)

應用層包含一個或多個應用。每個應用有獨佔一組資源的權利,這些資源是由控制層中一個或多個SND控制器提供。

可以有額外的應用接口

一個應用可能調用其他應用或與其他應用協作。一個應用也可能擔當SDN 控制器的角色。

Management

每個應用、SDN控制器、NE都與管理員有個基本的接口,管理員最小功能是從低層的資源池中分配一些資源給高層中特定的客戶實體,建立可達性信息,來允許低層和高層實體間相互交流

可以有額外的控制功能模塊,由於一些約束條件,應用、SDN控制器、或NE能獨佔給定的資源。

Administration

每一個manager與它所管理的資源都處在同一個管理域

ONF 協議

OF-config protocol用在management接口的功能模塊處

OF-config protocol用在D-CPI可能用在A-CPI的功能模塊處

(未完待續……請看下一篇。轉載請註明出處!)



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章