4.4應用層
圖4.4擴展了圖3.3中SDN架構裏的SDN application塊。
SDN原則允許應用在業務和策略允許的前提下指定需要的網絡資源和行爲。從SDN到應用程序層的接口叫做A-CPI。圖4.9顯示SDN應用自身就可以支持A-CPI代理，用來爲其他應用層次提供查詢功能，這將在4.1部分中介紹。應用層中不同層次的應用，根據器所處的層次高低會有不同程度的抽象。
注：SDN社區經常把A-CPI叫做北向接口（NBI）或北向API。參考2.3部分
一個SDN應用可能會調用其他外部服務，也可能協調多個SDN控制器來達到某個目的。OSS鏈路和coordinator功能識別除了上面的功能。與架構中其他組件一樣，SDN應用需要一定數量的前提知識作爲環境和操作角色。
*一個應用層實例可能作爲一個信息模型服務器，這種情況下，它發佈信息模型實例給其它應用所用。通常，其它應用是作爲客戶，與SDN應用服務代理交互的，如圖4.9所示。
*一個應用層實例這種情況下，它操作有其他服務器實體公佈出的信息模型實例。這個服務器實體可能是一個SDN控制器，或者是一個底層的應用
*一個應用層實例可能同時扮演着以上兩者的角色。例如，一個路徑計算引擎（PCE）可能依賴於一個SDN控制器提供的虛擬網絡拓撲信息（維護路徑管理數據庫），同時也爲SDN控制器提供路徑計算服務
應用與控制器之間的A-CPI活動，典型地包括查詢或者通知虛擬網絡狀態，並且下發命令去改變其狀態。例如，去創建或修改網絡連通性、路徑或修改數據層中節點間數據流的處理方法（指定帶寬或QoS）。A-CPI接口可能也會用於其它額外的功能，例如，作爲註冊服務的接入點來註冊服務鏈，服務鏈可以貫穿一層或者多層4-7個服務（note），或者作爲輸入來控制虛擬網絡的功能。
注- 在網絡行爲方面，服務鏈是通過一些合適的組件集合來監視網絡流量。在A-CPI增加值可能有指定一串組件功能的作用，這些功能供SDN控制器選擇，以便找出最優的功能實例，應用的相關的流轉發規則中。應用程序也支持組件屬性的編程，甚至在拓撲中產生新的虛擬網絡功能實例。
圖4.10顯示了終端用戶系統可以出現在數據層和應用層範圍的可能性。一個終端主機或網絡應用可以使用這個模型。防火牆或者DDOS檢測器可以作爲這個模型的應用案例:終端客戶可以發信號以告示它的存在或者得到期望的狀態（note）。
注– 例如，微軟的Lync客戶終端可以報告或請求某特徵的服務，然後一個集中的協調功能就會就網絡資源實例出一個迴應。
A-CPI的特徵將在下面更具體地陳述（6.8節）4.5 虛擬化
SDN的控制（control）與管理（management）部分必須設計成在抽象的、虛擬的資源上進行操作。雖然有連續的虛擬層，但是虛擬資源追根到底是對物理資源的包裝。虛擬化是通過一個共同的信息模型來表徵物理資源的特性。這部分描述了虛擬化網絡資源的可行性。
我們都記得，SDN的數據層就是一個網絡，由一些轉發流量或產生流量的節點構成，消耗，存儲，以及處理流量。這些節點被稱作網絡元素（NEs--network elements），它們被鏈路相互連接起來。NEs爲客戶端設備（clientequipment)以及其他的網絡提供外部數據層端口（port）。因爲SDN可預見的優點是基於集中式的管理，所以SDN控制器將控制不止一個NE。
下面的內容，對抽象和虛擬化的過程循序漸進地展開。首先，從一個假設的提供商環境（藍色部分）開始，然後擴展至代表着特定客戶的虛擬網絡（綠色和紅色）。
圖4.11重用了圖2.1來作爲例子網絡，這個網絡爲“藍色”所擁有。途中的矩形代表着網絡元素(NEs)。線條代表着鏈路。這些鏈路可能複合的，也可能是過度型的，傳輸着相同的或不同特徵類型的信息，而且這些信息也可能是被保護的也可能是虛擬的（例如，網絡中的客戶層：由底層網絡服務層提供服務）。開放的端點（endpoints）表明是數據層的流量接入點（handoff points）用來與外部的網絡設備相連。外部的端口（ports）被兩個客戶使用，分別是“綠色”和“紅色”.
考慮到真實網絡的規模和複雜性，圖4.11中所示的圖已經是對底層物理網絡的一個抽象。
提示：抽象是把實體中我們感興趣的特徵表現出來，同時對無關的特徵隱藏或概述。虛擬化就是針對特定客戶或應用的選擇需求進行的抽象。
圖4.11中，有選擇的特徵抽象反映出簡化真實網絡的意圖。
圖4.12顯示了同樣的底層網絡抽象，且已經被提供商“藍”爲客戶“綠”提供了抽象。這個圖中顯示“藍”爲“綠”在每一NE和連路上保留了資源。網絡拓撲因此顯示的和之前的圖一樣，但是4.11中的NEs已經被虛擬網絡所替代，成爲VNEs（note）。之前爲客戶“紅”所標註的端點也都消失了。因爲保密的原因，“藍”承諾“紅”必須從這張圖中隱藏自己的網絡細節。
VNEs在繪畫顏色上的不同。在這個例子中，VNE代表着NE資源的子集，這個子集歸客戶“綠”所管。同樣地，雖然在圖中沒有顯示，但是鏈路的容量和性能都有所削減，只爲“綠”客戶保留了它所有的資源能力。
如圖所示，底層網絡包括冗餘資源，可以明顯地容納許多可能的鏈路和節點故障。但是，假設客戶“綠”並沒有準備支付冗餘設備。然後，虛擬網絡（VN）的圖就不再是4.12的。提供商“藍”就可能分配縮減的VN資源給“綠”，只提供必要的連接，但是沒有多餘的可見路由冗餘（note）如圖4.13所示。
注 - 由於鏈路可能是內部保護，不能肯定客戶“綠”的VN沒有冗餘，但是顯然它的可用資源比之前的拓撲少了，網絡的能力也變弱了。這幅圖的作用就是用來解釋：簡單的VN是可以不受保護的。
到目前爲止，所有virtualizations在“藍”網絡提供商空間存在，並且提供商爲客戶“綠”識別屬於它的專用資源。
一個VN（子網）還可以被抽象到一個更簡單的VN。提供商“藍”需要一個分配給客戶“綠”的內部資源視圖。然而，“綠”可能並不關心看到所有的這些資源；它們與“綠”的使用並沒有關係。另外，由於策略的原因，“藍”也不願意暴露自己的網絡細節。因此，從“藍”提供給“綠”的VN的可見視圖可能是更進一步抽象過的。例如，與“藍”自己的視圖比更加不具體。圖4.14呈現了一個可能的VN，這個VN通過共同的CPI（圖4.16）由“藍”提供給“綠”。每一個VNE是一個由“藍”保留的資源集合，其表現會像圖4.13一樣，是更細粒度的模型。
總結以上內容：“藍”SDN服務提供商的控制器需要知道各個層次的抽象，但是視圖4.13只是爲其內部使用。對內部預定的資源命名是“藍”提供商自己決定的事情。被預定的資源對象實例（ports，虛擬NES）通過CPI(圖4.14)對“綠”SDN控制器可見，其命名是由“藍”“綠”協商得到的。標識符可能是預先按合約商談的，也可能是通過CPI在運行時協商的。
如圖4.15，“綠”也可以協商得到最簡單的可行VN，一個簡單的VNE，用一個矩形顯示（客戶視圖用綠色，提供商底層視圖用灰色）。客戶“綠”可能指定這個VNE叫做“Green-1”。
假設“綠”想創建一個轉發規則，例如在它的端口G1和G25之間（或者是把G1H和G25的兩個IP子網連通）。對於“綠”的SDN控制器，它看到的是視圖4.15所示的抽象NE，因此只需要發送一條轉發規則到這個“交換機”中。“藍”的SDN控制器需要翻譯“綠”的這一條指令來建立轉發規則，在視圖“4.13”的環境下重新解釋這條指令以滿足“綠”的需求。然後，將這個規則映射到藍色網絡（視圖4.11）。如果“綠”的指令是用IP表達的轉發規則，那麼“藍”就需要在底層網絡中的第三層（L3）的節點來實施這個請求，將其映射到已有的通道或者是映射到新建立的通道。下面段落進一步詳細地討論。
虛擬化的一個重要原因是“藍”提供商必須把“綠”的流量與其他的客戶隔離的流量隔離，而且這種隔離的需求是在對綠沒有任何瞭解且沒有合作的基礎上進行的。有三種情況，其中任何一個可以沿着在端至端路徑特定鏈路中使用。
（a）用例1：隔離可以通過物理途徑達到；例如，如果“綠”協商要求使用專用媒介，波長/頻譜或者直流時段。
（b）分組業務可能需要隔離，如果不能保證不同的客戶端之間不存在的地址空間重疊。地址的唯一性擔保可能需要在數據層（data plane）的轉發端口（handoffpoints）用訪問控制列表強制執行。如果還有封裝的需要，可以用以下兩種方式實施：
I. 用例2：由一個附加的封裝層的方法，例如用VLANIDs服務（S-VIDs）[10]
II. 用例3：在同樣的層，通過網絡地址轉換（NAT）的方式映射
選擇封裝方式是“藍”策略的問題；它的實現細節對“綠”是不可見的。“藍”在選擇網絡端口時，可能是選擇邊界設備（在端口G1和G25之間的資源），也可能沒有這個必要。“藍”改變來自“綠”的流量爲隔離形式，然後再逆轉這個格式到“綠”網絡所在的輸出端口。“藍”的基礎設施轉發封裝的流量，通過自己的網絡所在的地址空間。
在藍的基礎設施中，封裝的隔離可以採取隧道的形式。這些都是“藍”的服務層的子網連接，而顯示給“綠”的是簡單鏈接。爲了建立轉發關係，“綠”只需要將流量映射到正確的隧道近端和遠端連接端點。“藍”可預先配置子網連接作爲提供給“綠”VN的一部分。如果藍可以攔截綠色的轉發請求，藍色也可以動態創建隧道。在任何情況下，“藍”就伴隨着隧道的建立去提供必要的功能，例如OAM和保護。隧道設置和操作對“綠”是不可見的。
“綠”的管理人員，對如何使用他們的VN會有不同的需求。例如簡單的連接請求（像之前提到的）或者更詳細的控制。圖4.16展示了“綠”如何在自己內部對所得到的VN（如圖4.14）進行進一步的抽象，抽象到單一NE,如圖4.15所示。如圖所示，該抽象（及其隨後的解釋）可以完全在“綠”自己的空間內完成，並且完全不需要涉及到“藍”的規範等相關知識。如果“綠”只關心邊界端口（edge ports）的連接，以及其他應用程序處理的性能優化，這可能是合適的。
圖4.16也顯示了“藍”如何分配資源，以給另一個客戶“紅”提供不同的VNs
假設“綠”打算升級到一個更高的可用性服務，要求（可見的）路由冗餘。服務提供商“藍”可以重新修改底層VN，從圖4.12恢復冗餘資源的部分或全部，但就沒有必要在CPI上更新由“藍”提供給“綠”的VN。“綠”會看到改變，但能感覺到預期的可用性提升。
數據層的進一步思考
以上所示的網絡已經被嚴重抽象以突出討論的要點。一個不太抽象的視圖可能揭示出重要的附加信息，例如該子網是多層（note），這意味着端口和鏈路可能（也可能不會）支持不同的特徵信息。鏈路可能是複合的，並可能有多個端點。層之間可能需要適應。一個給定的層可能具有能力的極限，資源開銷需要加以控制的，特別是對於操作者，管理和維護（OAM）層。爲了網絡得到更好的生命力，冗餘技術可能在一個或多個層被利用。
注 - 在分層網絡中，爲每種技術將控制器分開是值得推薦的，例如在分組和光學層之間。這個架構既不指定，也不排斥技術層（technology layer）的分離。
這些方面都是重要的，但需要大量的額外規範，因此特定領域的ONF工作組（WGS）將把他們包括在架構和信息模型開發上，例如，光傳輸、無線和移動工作組（WGS）。從該文件的角度來看，可以認識到對狀態和結構的需要遠遠超出了簡單視圖所暗示的。正如第4.3節所指出的，這些狀態和結構中的一部分可以從SDN控制器中轉移到數據面（data plane）的硬件和軟件中。
4.6管理（Mangement）
管理部分負責基礎設施支持的任務，這個任務不會由應用、控制器以及數據平面本身去執行。管理部分也會根據策略或其它原因執行限制操作：對應用、控制平面（controller-）、和數據平面的行爲進行限制。或許，限制這些任務被SDN控制器組件執行的唯一原因就是SDN控制器可能處在一個客戶信任域中；而商業上的原因是任務的核心管理和支持功能在提供者的信任域內完成。雖然代理策略可以被使用，達到完全信任控制器，但透明的策略和策略執行軟件仍然必須由供應商的管理員來安裝。出於安全原因，默認情況下建議不要暴露什麼任何信息。
SDN架構的識別出經典的管理功能，如設備清單，故障隔離，軟件升級之類的，但對於它們在很大程度上超出SDN範圍。SDN其中一個好處就是允許客戶（外部信任域）來執行多數管理動作，當前這些動作還是由管理系統執行。隨着時間的推移，傳統的OSS接口預計將扮更小的角色，通過SDN控制器，作爲客戶端應用將擔負更多的責任。
在SDN的範圍內是SDN特定的管理功能，即記錄和表達提供商和客戶之間的業務關係（策略），並配置SDN實體環境和初始化參數。其中包括協調數據平面連接點（handoff points），識別約定（identification conventions），可達性和邏輯與物理實體（entity）之間的憑證。SDN架構需要把這些信息註冊到相應的SDN NEs中，控制器中，以及應用中，但是不指定OSSs的屬性和結構。
通常情況下，在每一個數據平面、控制器和應用層實體之間的客戶端-服務器對處在不同的信任域（如圖4.1）。其中，信任邊界存在於SDN層次結構中，相應的信任邊界也存在於管理域。在本文檔中，管理者即OSS系統，在不同信任域可能需要交換信息，但這種交流超越了SDN架構的範圍。
有兩個管理角色是公認的：服務器管理和客戶管理。服務器管理的責任與那些客戶機管理的責任是不一樣的。
兩個管理器共同的責任：
*爲它們的獨立實體分別配置，以便它們可以彼此通信。這些配置信息包括：一致性、協議選擇、可達性、安全策略和證書。
服務管理器的責任：
*實例化服務器環境中的代理，用來代表真實的或虛擬基礎設施中客戶指定的環境。這包括資源分配和策略的安裝，並有可能下載客戶定製的或特殊功能的模塊。客戶指定的配置可能包括協議或發行級別（例如，OpenFlow-switch1.3）的選擇。服務器自身感興趣的SDN控制功能（SDN control）是由處於服務器信任域（note）中的代理提供的。
Note – 第五部分消息描述了代理的功能
*同時更新客戶特定（或定製、指定）的資源配置和策略。這可能是由於諸如業務重新協商或有新增網絡而導致，或響應請求來釋放合同中約定的按需計費資源。一個特例是當業務協議終止時，刪除一切與指定客戶相關的資源。
*審計業務承諾的資源分配和策略的合規性的。這包括確認資源不重複預訂、單獨的客戶流量相互隔離。用於此目的工具，包括通知在內還有如安全警報或連接故障通知。
*訂閱通知服務（notification）以及爲了SLA監控、安全監控、故障管理、計費、網絡規劃，或其他目的而訂閱的收集統計數據信息的服務。這些都是現有的功能，除了可能在（實現）細節上不同外，基本保持不變。
客戶管理器的責任：
客戶管理的責任與服務管理的責任相似，只是從相反的角度出發。
*客戶端SDN控制器（或應用程序）需要的信息可能不能從服務中發現，特別是數據平面鄰接在外部網絡的端口信息。如果是這樣，客戶管理必須提供這些信息。
*雖然客戶SDN控制器可以從下一層的代理得到資源視圖，客戶管理還是希望能夠實例化出一份屬於自己的、有關合同商定的資源和策略的視圖。這可能有利於協調，或有利於客戶控制器的審計能力。相對於已經發現的資源和動作，對預期的資源和動作（actions）審計可能是一個重要的安全特性。
*操作之前和操作過程中，服務器管理要保證該客戶得到不超過合同指定的更多服務，而客戶管理要保證它得到不比合同規定少的服務。客戶管理可以查詢性能或狀態信息，或從它的服務控制器代理訂閱運行時異常和性能監控通知服務，以幫助這一評估。
管理器本省可以是一個業務或運營支撐系統（BSS/OSS），一個網絡管理系統，或者甚至是一個單元管理（element management system ）。這個文檔使用屬於OSS來包括所有的可能選擇。關於OSS更加詳細的能力以及OSS內部通信已經超出了本架構的討論範圍。
特殊的情況下，客戶和服務可以在同一信任域內存在的，這樣可能會有利於簡化架構的邊界通道（border crossings）。圖4.17顯示了在一個信任域內，一個通用的管理接口通過SDN控制器。
圖4.17中的虛線顯示了在一個信任域中，SDN控制器如何代理管理模塊，在OSS和應用之間（或NE之間）建立通信。這也展示了數據中心（DCs）中部署SDN常用的方式。雲/數據中心管理系統是一個典型的應用，它的NEs和SDN控制器（note）在同一個信任域中。SDN控制器可以直接實施需要的管理功能，代理那些其他地方已經實施的。
Note - 在這個例子中，cloud/DC管理系統將會自己負責安全相關的考慮，如隔離租戶之間的信任域。在這種情況下，只有它自己扮演着SDN控制器的角色。
4.7信息模型
在軟件定義網絡中會有種類繁多的組件來提供各種需求服務，這些組件之間又有多種多樣的通信協議。然而，減少協議的總類是合情合理的，這個架構沒有強制要求專用協議。重要的是，所有通信實體共享一個共同的信息模型。不能把它與常見的數據表現[7]（representation）混淆在一起，它是一個協議的問題。確實，當環境許可時，信息模型的元素表意可能含蓄，不像協議傳達的明確信息。
這個架構模型的SDN的操作，通過各種接口操作被管理的對象的實例（MOS）。對MO實例的操作包括大家熟悉的CRUD：創建，讀取，更新，刪除；以及對MO類中定義的方法調用和訂閱通知。因此，信息模型是架構的核心功能，會隨時間的變化而變化。
信息模型是一個描述架構的關鍵組件。此架構建議靈巧地去重用已有的信息模型。信息模型不必是來自廣泛的工業界，工業界的模型也不能直接或完全就引入到SDN信息模型。適應SDN環境需要考慮SDN特殊的特性和最佳的實踐經驗。然而，生成的SDN模型需要選擇和記錄，以便它可以被SDN之外的社團所理解和使用。這樣可以壓縮學習曲線，並促進向現有架構融合的過程。
從ONF的工作中可能出現新的信息模型，這些模型應該得到工業界團體的反饋，這樣纔是最好的趨向標準化的道路。（未完待續……請看下一篇。轉載請註明出處！）