5 控制功能和交互行爲
在協調（coordination）功能的輔助下，控制（control）功能是SDN的核心。集中討論這些內容，同樣也是以迭代的方式，這部分另外增加了詳細的層次，來介紹了4單元所引入的原則和組件。總結協調（管理）功能和控制功能的區別如下：
*協調功能執行與向客戶分配資源相關的功能，以及根據策略界定這些資源。這些功能出現在單個信任域中。
*當一個資源被分配到客戶，資源就有效地屬於客戶的SDN控制器（DPCF）了，可以在合法策略範圍內任意使用。控制器所在的信任域是與它所控制的資源的控制域分開的。
爲了清晰，這部分內容被組織成四部分，其複雜程度逐漸遞增，每次功能的增加將使其能力增強。相應的，一些內容也會有所重複。這個架構支持最複雜的場景，但是要知道，一個具體實現的複雜性可能會被減少，減少多少的程度依賴於業務需要和投資人的組織情況。
四個場景如下：
1.單人的SDN提供商；
2.有客戶的、暴露底層網絡的SDN提供商；
3.提供虛擬網絡，非遞歸式的SDN提供商；
4.提供遞歸式的虛擬網絡的SDN提供商
如前，管理者“藍”被視作是架構最低層的擁有者，而“綠”和“紅”是代表着客戶。
5.1 單人的SDN提供商；
說到底，所有的網絡都是基於物理網絡元素（NEs）的集合之上的。從這個層面開始是有益的，考慮NEs的集合構成一個或多個子網，這些子網處於一個SDN控制器的控制域中。圖5.1所示的就是這樣的一個子網，被提供商“藍”所擁有和操控。NEs1到NEsn構成了SDN控制器SDNCb（b是下標）的網絡控制域（NCD）。這部分的一切都是處在“藍色”信任域中。
數字圓圈指明這個網絡在處於SDN控制下時活動的序列。
1.每一個NE被認爲包含一個協調器（coordinator）功能。但對協調器是如何出現的並沒有指明。它可以是由“藍”OSS實例化，或者也可能是NEs的軟件部分，設備啓動即裝載。
通過協調器的方式，“藍”OSS爲每個NE實例代理，圖中指定的代理實例爲agent0（note）。“藍”OSS也實例一個虛擬器（virtualizer），來支持agent0；該虛擬器的功能是映射分配給agent0的資源到NE的硬件抽象層（HAL）。
Note - 標識符並沒有什麼特殊的含義，它是由服務提供商決定的，表示服務商的選擇。
2.每一個NE被認爲有自己的主RDB，用來爲本NE中的所有資源建模（note1）。通過協調的方式，“藍”OSS把資源從主RDB分配到agent0（注2），分配出去的資源被保存爲agent-local RDB。一個代理代表着專用於特定客戶的特定的資源，並且爲該客戶表示執行上環境。在這個示例（case）中，agent0表示NE的資源歸“藍”所有。
Note1 - 沒有指定如何填充NE的主RDB，或者也沒有指定它要成爲獨立的一部分。它可能是由“藍”OSS部分下載的，也可能是由NE中的一個發現函數在初始化的時候填充的，或者也可以簡單地只是NE的硬件和狀態視圖。
Note2 - 不是所有的NE資源必須屬於SDN控制器。其中永遠禁止訪問的資源的例子就有身份、可達性和證書包，這些信息是用來讓NE聯繫OSS的。另外一個例子是由於非同步的非SDN協議造成的，這種協議出現在混雜網絡中，用來負責NE中脫離的資源。
3.“藍”OSS在一些平臺上，或平臺集合上初始化一個SDN控制器SDNCB，它的功能包括協調器和一個DPCF。“藍”也在SDNCB中初始化一個主資源數據庫RDB，並且可能部分或完全地用自己的資源計劃和可用數據庫（inventory data base）填充它。
Note - NE和拓撲發現可以是網絡自身的功能（第5步）。它可以恰當地幫助SDNCB，使先前預裝入RDB的信息和實際探測到的網絡一致。當有不一致的情況時，要發出異常。
4.“藍”爲控制器和NE的協調器提供建立通信的信息。重要的信息包括身份，可達性（IP地址，DHCP參數等），以及安全策略和憑據
5. NEs與SDN控制器建立通信。SDNCB使它的主RDB與底層的實際資源一致，例如，多個NE的agent0的並集構成RDB。SDNCB可能也需要發現和審計網絡拓撲或者其他的元信息（meta-information），這些信息通常不能被NE的agent0直接訪問。
這些資源現在就可以被SDNCB按自己的需求使用了。控制器與NE間的交互被建立成一系列基於NE中agent0-RDB的信息模型的操作行爲。
6.通過SDNCB的協調器，“藍”OSS用虛擬器爲SDNCB實例化代理，用來爲應用程序層提供它想提供的服務，並用SDNCB主RDB中的資源填充它，同時根據策略，限制提供給應用程序的執行能力。
到這裏，“藍”網絡已經準備好，可以將SDN控制的網絡服務提供給應用程序客戶了。同樣的，這個配置過程也顯示了一些部署的最終目標（note）。它與最初的SDN規範和實施有較大的兼容性，最初的規範更注重在硬件上的直接實施，而沒有去關注商業和控制器功能與網絡的可信邊界。
Note - 圖4.17和圖5.3共同呈現了一種案例（case）：配置的方式可以支持更高層次的應用，如解決多租戶問題的應用。
“藍”可能也會通過這個註冊過程，提供傳統的通信服務，即由傳統的管理模塊控制的服務，而不是由SDN應用模塊控制。“藍”可以通過SDN控制使用它的NEs，但是不會直接支持網絡識別的應用。這對於融合整網到SDN來說是很有用的一步。
5.2有客戶的、暴露底層網絡的SDN提供商
圖5.2顯示了下一步全網絡的進化範圍和能力的演變。這裏，服務商“藍”爲客戶“綠”提供了一個虛擬的網絡SDN服務，在圖中，客戶“綠”的表示符和下標是“G”。暴露給“綠”的虛擬網絡被抽象到只包含挑選的端口和供應商支持的資源，但是是直接映射到“藍”的物理網絡元素上。VN暴露給“綠”的可能因此是圖4.12或4.13，而不是圖4.14或4.15。後續的章節將會放開這個限制。
Note - 這種配置在實際的開放中是不推薦的；將會有解釋說明爲什麼。第5.3章節描述了較受歡迎的一種實現，這種實現移除了NEs的複雜性，有利於SDN控制器；移除了客戶的虛擬VEs必須由一個提供商的NEs提供的限制，並且不需要直接與不可信的客戶控制器相連以及直接和服務提供商的基礎設施相連。
在網絡服務可用之前，“藍”和“綠”必須協商一個商業和技術的協議。至於是以何種方式協商就不屬於本文檔討論的範圍。我們只需知道，“藍”和“綠”的0SS都對它們共同的技術協議有了解。與必要的資源相同，商業協議在“藍”與“綠”的網絡之間，也指定了數據平面的接入點（handoff points）。在某些情況下，這些接入點都是可以由網絡自身檢測到的，但是它們通常還是被希望通過OSS（note）預先裝入到控制器。
Note - 作爲一個策略的問題，可以想到“藍”是不會隨意暴露自己的網絡端口的，第三方服務商也不會。如果“藍”發現來自“綠”的某信號在一個不期望出現的設備端口出現，例如由於接線錯誤，“藍”就會產生一個異常，而不是去接受它，這樣做只是爲了安全別無其他用途。只有在有限的環境中——像數據中心——纔可能把端口視作無差別的開放可訪問池。
出發點是“藍”完成了第5.1章節描述的配置過程。
1.“綠”OSS在它自己控制的合適平臺上實例化一個SDN控制器SDNCG。用5.1章節的方法維護架構的一致性，SDNCG包括一個協調器，一個DPCF(數據平面控制功能)，還需要至少一個主RDB的架子。“綠”可以在此之後添加虛擬器和應用代理，如第5.1章描第6步描述的。
“綠”OSS可以預先用信息模型，也即“藍”提供給它的部分或全部資源來填充它的主RDB，同時也將對資源（note）的可操作行爲、權限等附加信息填充進去。這些動作（actions）的例子包括創建CFM MEPs或者設置性能，監控收集點的信息，並在超過閾值時發出警報通知。這些資源和冊率可以知道SDNG的執行，並且可以被用來審計資源和能力。在第5步我們將看到這些用途。
Note - “綠”OSS 也規定了訪問與安全的策略，用來管理“綠”SDN控制器和多個“藍”的NE代理的通信。
2.異步地，“藍”OSS爲“綠”實例化代理，在相關的NE上指定agent G。
3.根據商業和技術協議，“藍”OSS爲“綠”分配資源和建立策略。協調器邏輯上將資源轉交給agent G的RDB。在圖5.2中，用深藍色的條來表示避免“綠”對“藍”有非授權企圖的策略（note）。策略實施在虛擬器功能組件中。
Note - 圖中也顯示了與“藍”的策略與自己的agent的關係。提供商特殊領域的策略在接下來會討論。
4.“藍”OSS服務商提供SDNCG的身份，可達性和安全信息給每一個NE。這樣做是爲了允許讓SDNCG和“藍”NEs中的agent G可以通信。當“藍”支持除“綠”以外的其他客戶時，每一個客戶的agent-controller的關係有它們自身的通信策略和證書。
5.“綠”SDN控制器SDNCG和每一個NE中的綠agent建立共同的通信。SDNCG可能會上載或審計每一個agents G的RDB，以此來填充或調節自己的主RDB，然後SDNCG就可以隨意使用分配到的資源了。
“綠”-“藍”間的客戶端-服務端關係是多對多的。“藍”可以用上面同樣的流程，來爲多個客戶支持多個專屬的agent。“綠”SDN控制器也可以協調來自多個不同提供商的VNs，和它自己直接管理的NEs。
“綠”現在可以通過實例化出虛擬器和代理來支持自己的每一個應用客戶端，來從自己的主RDB中爲代理們分配資源。
“藍”有全部資源的信息以及對資源有完全的控制權，可以決定是否要把資源提供給某個代理。“藍”有沒有自己專用的代理並沒有強制規定（note），也可以有自己的代理，標識爲0。如果這樣一個代理存在，策略將會賦予它擴展的或特定範圍和權限。提供商代理策略可能會阻止“藍”去操作已經賦予給“綠”的資源，但是也可以強制要求不接受過這個阻止。
Note - 如果“藍”的NE不是SDN控制的（如混雜網絡）那麼這種情況下“藍”OSS將不會實例化一個專用的“藍”代理。
“藍”有義務處理屬於自己（提供商）的問題。其中這些問題可以由“藍”OOS通過NE協調器來負責；其他的問題可以由“藍”OSS來管理，其工作方式就像SDNCB的應用客戶端，因此也是通過多個agent0 在策略特權內執行操作。其他的操作就需要SDN控制器自己的邏輯去驅動了，例如，再優化資源分配。
“藍”提供商的功能，舉幾個例子：
*“藍”以服務的方式，將管理的資源隱式地或顯式地提供給“綠”。最主要的一個例子就是通道（tunnel），也即是服務層的網絡連接端口對客戶層網絡可見。“藍”也會操作自己的通道來OAM（Operations,administration, maintenance），保護或恢復，性能監控，測量或策略，等等。來作爲服務的保證。這些服務層的細節對“綠”是不可見的。
* 缺陷檢測，報警定時和聲明，失敗信息從D-CPI通過虛擬器向受影響的agents傳播。
* 基礎設施安全監控，當意外發生，向“藍”OSS報告安全警報。安全監考、安全日誌。
* 爲了維護的目的，可以將底層的資源移出服務範圍（或管理鎖定），然後通知收到影響的agents（可用狀態標記爲不可用）。
* 在一些事件發生時，重新分配和聲明資源的功能。如，當客戶的業務關係發生改變時；有瞬變（transient）要求時（即，客戶要請求預定的資源或者先來先服務資源分配方式，只要在簽訂的“保護傘”商業協議範圍內就可以滿足）；持久服務（客戶協商增加資源，不再需要給定的資源，或者業務關係終止）。資源的重分配也可能是由於網絡擴建或者全網的再優化。
* 管理幾個客戶協商的共享資源，這是爲客戶提供最好的體驗，可以用權重或者優先級的方式來分配資源。
* OSS交互能力，像前面提到的。
* 通知SDNCB代理（agent）G失敗
至少，以上一些“藍”的功能影響到的資源和狀態對“綠”是可見的。因此“藍”agent0和協調器與agent G是有輕微整體和部分的關係。“藍”agent0 或協調器可能從agent G收到資源請求和異常，並且從“藍”資源空間中交流通知和其他信息。在上面的一個例子中，“藍”管理“資源鎖定”就必須觸發至少一個通知到SDNG，如果不發送的話，NE自身就會保護“綠”的資源不被侵犯。
“藍”與agent G 的集成可能在NEs中，也可能是在SDNCB中。
策略加強是在虛擬器功能模塊中實施的。策略的特點包括：
* 允許客戶使用他們想用的任意地址空間是一件很一般的事情。在任意客戶選定的層，用封裝的方式可以隔離客戶。封裝的技術是由提供商的策略決定的；特定的參數需要在agent RDB中保存。
*封裝對於客戶是不可見的，不管是在客戶的虛擬數據平面還是在客戶的控制器平面都不可見。代理與控制器之間的指令和回覆都需要用客戶的地址空間，但是代理必須把它們翻譯成封裝的格式（note）
Note – 如果openFlow-switch被用作控制協議，packet-in/ packet-out功能和轉發表實體必須剝離它們各自的封裝標籤（或翻譯）包括在北向以及南向接口。
* 客戶希望通過他們自己的規範來識別他們的資源。虛擬器在客戶與提供商之間做身份轉換。至少，（在這種情況下）在RDB中，一些客戶的命名規範能被”藍”OSS識別和安裝。這也是作爲業務和技術在數據平面接口端的協商。
* 策略實施點必須在客戶上下文環境中翻譯事件和動作，不止翻譯名字。硬件設施錯誤或者管理鎖定，例如，可能要翻譯端口掉線信息到幾個不同的客戶控制器，並且要觸發客戶的各式各樣的保護或恢復行爲。將資源賦予給客戶agent時，要想客戶報告創建對象的通知，而刪除資源的時候也要向客戶報告刪除對象的通知。
SDNCB和SDNCG可能都需要訂閱通知，調用警報通知功能（這裏經常把功能稱作控制），更具閾值建立PM蒐集點，等等。但是“綠”只在自己可控的資源範圍內。作爲一個可以加強SLA監控能力、提升客戶與提供商環境之間的故障排除能力，SDNCB要能看見“綠”的視圖以及通知信息。（未完待續……請看下一篇。轉載請註明出處！）
