轉載自：http://www.voidcn.com/blog/gaopeiliang/article/p-1196772.html
1 概述
1.1 使用案例
1.2 OpenContrail控制器和vRouter
1.3 虛擬網絡
1.4 Overlay Networking
1.5 Overlays based on MPLS L3VPNs and EVPNs
1.6 OpenContrail and Open Source
1.7 擴展架構和高可用性
1.8 數據模型中心規則：SDN作為編譯器存在
1.9 北向應用程序接口
1.10 GUI用戶端口
1.11 擴展平台
2 體系細節
2.2 OpenContrail轉發平面
2.3 服務鏈
2.4 控制和管理平台協議
2.5 集成
2.6 安全
2.7 層次化擴展和高可用性
3 數據模型
3.1 編程模型
3.2 配置和運維數據模型
4 OpenContrail用戶案例
4.1 數據中心域用戶案例
4.2 運營商網絡NFV
5 比較OpenContrail系統和MPLM VPN
6 縮略語表
7 參考文檔
1 Overview of OpenContrail
本章節介紹OpenContrail系統—一個SDN的擴展平台
所有主要內容在本章中都有簡略介紹，詳細內容會在后續章節中繼續描述
1.1 使用案例
OpenContrail是一個擴展系統，可以應用在不同的網絡環境中，但是，其使用的主要驅動力在於如下兩個體系結構下
- 雲計算網絡-企業和運營商的私有雲網絡提供體系即架構-IAAS服務和雲服務提供商提供的虛擬私有雲（VPCs）服務
- 在運營商網絡中的網絡功能虛擬化（NFV）–為運營商邊界網絡提供增值服務，如提供業務邊界網絡，寬帶用戶管理邊界網絡和移動邊界網絡
私有雲，虛擬私有雲（VPC）和基礎架構即服務（IAAS）的使用場景里，都需要多租戶虛擬數據中心，在這些案例中，都在一個數據中心中存在多個租戶，共享相同的物理資源（物理服務器，物理存儲和物理網絡），每個租戶被指定使用他們自己的邏輯資源（虛擬機，虛擬存儲，虛擬網絡），這些租戶的邏輯資源之間相互隔離，除非基於某些安全策略使之可以相互訪問，數據中心中的虛擬網絡一樣可以通過物理的IP VPN或者L2 VPN進行互聯網絡功能虛擬化（NFV）的使用場景中引入了協調器和網絡管理功能，例如防火牆，入侵檢測系統，深度包檢測，數據緩存，廣域網加速等等，這些功能在虛擬機中實現，從而替代了以往的傳統物理設備，這些，都驅動了網絡層面的虛擬化，使其可以走向市場，優化網絡成本
1.2 OpenContrail 控制器和虛擬路由器
OpenContrail系統由兩個主要部件組成：OpenContrail控制器和OpenContrail虛擬路由器
OpenContrail控制器是一個邏輯上集中但是物理上分布的SDN控制器，為虛擬網絡提供管理，控制和分析功能。
OpenContrail vRouter（虛擬路由器）是一個轉發平面（或者是分布部署的路由器），運行在虛擬服務器的hypervisor，將網絡從一個數據中心的網絡的物理路由器和交換機擴展成一個虛擬的基於虛擬服務器主機之間通訊的overlay網絡（關於overlay網絡的詳細介紹將會在1.4章節中,OpenContrail虛擬路由器從概念上和現在的商用和開源vSwitch（如OVS）很像，但是他會提供路由以及更高層的服務（使用vRouter替代vSwitch）
OpenContrail控制器提供了系統的邏輯集中控制平面和管理平面，並且協調管理vRouter
1.3 虛擬網絡
虛擬網絡是OpenContrail系統的重要部件，虛擬網絡是部署物理網絡頂層的邏輯架構，虛擬網絡也用於替代基於VLAN隔絕網絡的方案，為多租戶提供虛擬數據中心，每一個租戶或者應用可以擁有一個或者多個虛擬網絡，每個虛擬網絡之間相互隔絕，除非使用安全策略允許之間相互訪問
虛擬網絡通過在數據中心的邊界路由器上使用MPLS L3 VPN或者EVPN，作為物理網絡連接擴展使用（譯者注，實際上是使用這些技術實現跨數據中心的虛擬化）
虛擬網絡同樣可以使用部署在NFV環境和服務鏈上，詳細內容會在2.3中介紹
1.4 Overlay Networking
虛擬網絡也可以使用在兩個網絡中—物理underlay網絡或者虛擬overlay網絡。Overlay網絡技術已經廣泛應用在無線局域網產業十年以上，但是現在數據中心網絡為之賦予了新意，並且被不同的組織標准化，例如IETF下屬的NVO3工作組，並且通過不同廠商的開源或者商業網絡虛擬化產品進行部署
物理底層網絡的作用，就是提供的一個“IP矩陣”，他的職責是提供所有物理設備之間的單播IP可達性（服務器，存儲設備，路由器或者交換機），一個理想化的底層網絡，可以提供網絡中任意一點之間的低延遲，無阻塞和高帶寬連接
虛擬路由器運行在虛擬服務器的hypervisor層，通過在物理底層網絡的上層創建虛擬overlay網絡，使用動態的“通道”網，保證虛擬服務器之間的連通性，在OpenContrail overlay通道中，可以使用MPLS over GRE/UDP通道，或者VXLAN通道。
底層物理路由器和交換機不需要保存任何租戶的信息：他們不需要保存任何MAC地址，IP地址或者虛擬機之間的策略，在底層物理交換機和路由器的轉發表中，只會包含物理server的IP前綴或者MAC地址。網關路由器或者交換機是一個特例，因為他們需要保證虛擬網絡和物理網絡的通訊，他們需要包含租戶的MAC或者IP地址信息
從另一個方面說，虛擬路由器會包含每一個租戶的信息，他們會包含每一個虛擬網絡的獨立轉發表（或者稱為一個路由實例），這些轉發表包含虛擬機的IP前綴（在L3 overlay網絡中）或者MAC地址（在L2 overlay網絡中），並不是一個虛擬路由器需要保存整個數據中心所有虛擬機的所有IP前綴或者所有MAC地址信息，給定的虛擬路由器只需要保存本地服務器存在的路由實例的信息上（舉例說明，至少每個服務器上存在一個虛擬機）譯者注：實際上就是每個虛擬路由器會負責一個每一個物理server上的虛擬機內部，或者之間的通訊，會保存路由表，轉發表等
1.5 基於MPLS L3VPNs 和 EVPNs的overlay架構
廠商和標准化組織已經提出了真對於overlay網絡的各自不同的控制平面和數據平面協議
例如，IETF VXLAN提出了一個新的數據平面封裝，並且提出了一個和標准以太網“泛洪和學習源地址”，進而形成L2轉發表的行為類似的控制平面協議，需要在底層網絡部署一個或者多個組播組來實現泛洪
OpenContrail也受此類技術的影響，其解決方案在概念上類似於標准的MPLS L3VPNs (用於 L3 overlays)和 MPLS EVPNs (用於 L2 overlays)
在數據平面，OPENCONTRAIL支持MPLS over GRE，這種數據平面的封裝可以被目前的大部分主流廠商的現有路由器支持，OPENCONTRAIL同時支持其他數據平面封裝標准，例如MPLS over UDP (在多路徑和CPU優化上更具優勢) 和 VXLAN，其他的封裝標准例如NVGRE會非常容易添加在后續版本中
OPENCONTRAIL系統的控制平面或者物理網關路由器（或者交換機）之間的控制平面協議是BGP（以及使用Netconf用於管理），這也同MPLS L3VPN 和 MPLS EVPN使用的控制平面協議相同。
用於OPENCONTRAIL控制器和OPENCONTRAIL虛擬路由器之間的協議基於XMPP，XMPP信息的交互方式在IETF草案上已有描述，盡管語法不同，但是語意上和BGP非常相似
實際上，OPENCONTRAIL系統使用的控制和轉發平面協議與MPLS L3VPN和 EVPN協議非常類似，這樣做存在諸多好處：這些協議比較成熟，而且易於擴展，被廣泛應用在生產網絡，並被多個廠商產品支持，可以無縫互操作，而無需軟件網關（譯者注：最后一句話實際上是重點，使用老技術來保證新部署模式不需要更新硬件設備）
1.6 Source—OPENCONTRAIL和開源
OPENCONTRAIL被設計可以運行在一個開源雲網絡環境中，用於提供完整的集成端到端的解決方案
- OPENCONTRAIL系統可以和開源的hypervisor集成，例如KVM和XEN
- OPENCONTRAIL系統可以和開源的虛擬化協調協同集成，例如OpenStack和CloudStack
- OPENCONTRAIL系統可以和開源的服務器管理系統集成，例如chef, puppet, cobbler和 ganglia.
OPENCONTRAIL目前遵從Apache 2.0許可，這意味着任何人可以開發和修改OPENCONTRAIL系統代碼，不需要承擔公布或者釋放修改代碼的任何義務
Juniper網絡同時提供OPENCONTRAIL系統的商用版本，為Juniper網絡和其代理商提供整個開源棧（不僅是OPENCONTRAIL系統，還包括其他開源組件如OpenStack）的商業支持
OPENCONTRAIL系統的開源版本不是一個“戲弄者”（譯者注：不是隨便玩玩的版本），會提供和商用版本一樣的功能，以及擴展性
1.7 Scale-Out Architecture and High Availability
前文我們提到，OPENCONTRAIL控制器是一個邏輯集中化的平台
物理分布意味着OPENCONTRAIL控制器結合不同類型的節點，每一個都可以有多個實例，提供高可用性和層次化擴展，這些節點實例可以是物理服務器或者虛擬機，最小部署環境下，這些節點可以合並在一個server上，整個系統一共三個類型的節點
- 配置節點主要負責管理層，控制節點提供北向REST應用程序接口（API），可以用於配置系統，或者獲取系統的運行狀態信息，使用層次化數據庫組件表現實例服務，實例化的服務是以一個可橫向擴展的數據庫為對象，而這個數據庫通過一個正式的服務數據模型所描述（更多的數據模型在后面描述）。配置節點同時也包含一個轉換引擎（有時可以理解為編譯器），將高層級服務數據模型的組件轉換成相應的更多的低層級技術數據層面的組件。也就是說，高層級服務數據模型描述什么服務需要被部署，而低層級技術數據模型描述什么服務通過什么技術怎樣被部署，配置節點使用IF-MAP發布低層級技術數據平面的內容給控制平面。
- 控制節點部署在控制平面的邏輯集中部分，不是所有的控制平面功能全部邏輯集中—一些控制平面的的功能依然會在網絡中的物理和虛擬路由器上以當前流星的分布式的方式部署（譯者注：也就是說控制平面的功能也會向以前的組網一樣，在每一個路由器或者交換機上），控制節點使用IF-MAP協議監控底層技術數據模型的內容，並通過配置節點進行計算描述網絡的需要狀態。控制節點使用南向協議的集成來達到“使其成真”的目的，例如把網絡的實際狀態等同於網絡實際需要的狀態（譯者注：就是按需定義網絡），當前的初代版本，OpenContrail系統的南向協議包括XMPP去控制OpenContrail虛擬路由器，XMPP集成了BGP和Netconf協議去控制物理路由器，控制節點同時使用BGP去進行其他節點控制節點多個實例的狀態同步，來達到擴展和高可用性的目的。
- 分析節點的職責是收集，核對和展示分析信息，用於排除網絡故障和了解網絡的使用情況，每個OpenContrail系統的組件會產生系統中每一個顯著事件的詳細記錄，這些時間記錄會發送給分析節點一個或者多個實例（擴展目的），在一個層次化可擴展的數據庫中核對和儲存信息，提供更便於時間系列分析和查詢的優化數據格式。分析節點具有事件發生時自動觸發和收集詳細信息的機制，目標是可以獲取任何問題的故障原因，而無需重現故障。分析節點提供被北向分析查詢REST API。
OpenContrail控制器的物理分布式特性是一個特殊的功能，因為這可以使任何節點的多個冗余實例，運行在主-主模式（另一種模式是主備模式），系統可以在任意節點故障時持續工作而不會有任何中斷，當節點變得超載，節點的其他實例將會被實例化，負載可以自動重新分布，這樣可以防止單一節點成為瓶頸，使得系統可以具備極大的擴展性—支持數以萬計的服務器
邏輯集中意味着OpenContrail系統的行為是一個單一的邏輯點，盡管實際上他會部署成為集群或者多個節點
1.8 數據模型核心規則：SDN即是編譯器
數據模型扮演着OpenContrail系統中的中心角色，一個數據模型包括設置的組件，性能，和數據模型之間的關系。
數據模型允許應用可以快速宣告而不是經由某種必要行為來實現，這是實現程序高效的關鍵所在，OpenContrail架構的基本目標就是平台上的數據操作，就如同平台上維護的應用一下，也就意味着應用的處理是無狀態虛擬化的，更重要的結果是這個設計可以讓獨立的有那個用可以從復雜的網絡操作解放出來，不需要擔心其高可用性，擴展性和互聯性。（譯者注：個人理解是OpenContrail希望達到的目的是業務的快速部署，以前部署業務，除了服務器上面配置之外，還需要在網絡層進行進一步的配置，而OpenContrail里面的數據模型可以讓應用快速通告，而不擔心基礎架構網絡的調整）
有兩類數據模型：高層級數據模型和低層級數據模型，這兩個數據模型都使用格式化數據模型語言—目前使用的是IF-MAP的XML語法，YANG也會在未來的版本中被考慮作為模型化語言
高層級服務數據模型在抽象化的最高層描述網絡所需要的狀態，使用組件直接將服務對應到終端用戶上，例如，虛擬網絡，連接策略或者安全策略等
低層級技術數據模型描述在抽象層中非常底層的網絡所需要的狀態，使用組件來對應特定的網絡協議，例如BGP的路由標記（RT）或者VXLAN的網絡標識
配置節點的職責就是將高層級服務數據模型的修改轉換成低層級技術數據模型的修改，這在概念上和即時編譯（JIT）類似，借此“SDN即為編譯器”在有時用於描述OpenContrail系統的體系結構
控制節點的職責是識別網絡需要的狀態，這種狀態被使用北向協議如XMPP，BGP和Netconf這些北向協議的集合形成的低層級技術數據模型所描述。
譯者注：這段比較晦澀難懂，但是整體看來並不復雜，重點在於，我們要從數據中心應用的角度去理解，簡單來說，數據中心內部服務器上需要跑各種類型的服務，這些服務之間的通訊靠數據中心內部的交換機以及路由器實現，在以前的部署環境中，當我們開啟一個業務，或者說在數據中心中建立一個業務分區，那么我們需要做的是，在物理機或者VM上安裝服務，然后，根據服務的要求，建立和其他分區的流量轉發策略以及安全策略，這需要在不同的設備上去進行配置來實現一個業務的開局，那么在“SDN”的環境中，我們現在把數據中心想象成一個整體來考慮，其中，交換機等基礎架構的工作是只需要提供一個物理接口，接下來要做的就是有一個集成化的工具，也就是OpenContrail系統，從創建虛擬機開始，一路next，直接把服務開啟，網絡也瞬間進行調整，這樣實現“SDN”的目的，在這個思路下，上面的高層級和低層級，控制和配置模型的介紹，實際上就是事先這個思想的技術而已。
1.9 北向API接口
OpenContrail控制器中配置節點為預留或協調系統提供北向REST API接口，北向REST PAI會由格式化的高級數據模型創建。這保證北向REST API是“第一批市民”，意味着任何服務可以通過REST API進行預留
REST API采用安全通訊方式：使用HTTPS用於驗證和加密，並且提供基於策略的授權，同時具有層次化的擴展，因為API可以被多個配置節點實例讀取
1.10 圖形化用戶接口
OpenContrail系統也提供圖形化接口，GUI在使用REST API 描述前構建完成，保證不會在API內產生延遲，同時，我們預期大規模部署或者運營商OSS/BSS系統可以使用REST API集成於此
附注：我們正在進行UI 代碼級別的修改，以便未來允許我們可以使其開源
1.11 可擴展平台
OpenContrail系統的初代版本使用特定的高層級服務數據模型，特定的低層級技術數據模型，以及轉換引擎進行前者后者的映射，此外，OpenContrail系統的初代版本也是用特定的南向協議集合
高級服務數據模型在OpenContrail系統的初代版本中的模型化服務結構包括：租戶，虛擬網絡，連接策略和安全策略，選擇這些模型組件支持的基本業務環境主要是雲計算網絡和NFV（適用環境：雲計算網絡，多租戶網絡）
低層級服務數據模型在OpenContrail系統的初代版本中主要面向的服務部署模型是使用overlay networking（網絡構建模型：overlay）
配置節點的轉換引擎包括“編譯器”去實現高層級服務數據模型到低層級數據模型的轉換映射
初始版本控制節點使用的南向協議包括XMPP，BGP，Netconf
OpenContrail系統是一個擴展平台，意味着，在未來的版本中，我們可以通過組件擴展的方式去支持更多的用戶部署環境和網絡技術
- 高級服務數據模型可以擴展新的組件去支持新的服務，例如：運營商核心網絡的流量工程和流量日歷（根據日期進行流量管理）
- 低層級服務數據模型也可以基於其中一個原因進行擴展，相同的高級服務使用不同的技術去進行部署，例如，多租戶可以使用VLAN去替代overlay，新的高層級服務的引入會需要新的低層級技術，例如引入流量工程或者流量日歷作為高級服務就需要引入新的低層級組件例如TE-LSP
譯者注：這章定義了OpenContrail系統的使用環境：用於雲計算或者多租戶的數據中心，采用overlay的網絡模型，當然，作為一個可以擴展的系統，在未來版本中，可以根據業務的需要增加新的服務，但是有了新的服務，也就需要新的技術。
- 轉換引擎可以為映射現在的高級服務組件到新的低層級技術組件（實現當前業務的新的方式或者新的網絡技術），或者映射新的服務組建到新的或者現有的低層級技術組件（例如部署新服務）進行擴展。
新的南向協議可以引入到控制節點中，這主要用於支持網絡中使用不同協議的新類型的物理或者虛擬設備。例如特定廠商的網絡設備使用的CLI命令行接口可以被引入，或者可能因為需要部署新的協議，新的組件需要引入到低層級技術數據層面中。
2 OpenContrail系統結構細節
如圖1所示，OpenContrail系統包含兩個部分：一個邏輯集中但是物理分布的控制器和一個vRouter(虛擬路由器)的集合，使用軟件轉發模式部署在通用虛擬服務器的hypervisor層
控制器提供北向REST API接口供應用使用，這些API用於和雲協調系統集成，如通過neutron（以前叫做quantum）和Openstack集成，REST API也可以被其他應用以及或運營商的OSS/BSS系統使用，最終，REST API被部署在OpenContrail系統內基於網頁的GUI集成
OpenContrail系統提供三個接口：北向接口集合用於與協調系統和應用通訊，南向接口用於與虛擬網絡環境（虛擬路由器）或者物理網絡環境(網關路由器和交換機)通訊，東西向接口用於和其他控制器對等通訊，Openstack和CloudStack支持協調器，標准BGP用於東西向接口，XMPP用於虛擬路由器的北向接口，BGP和Netconf和南向接口用於網關路由器和交換機。
在內部，控制器包括三個主要組件
- 配置節點的職責是通過網絡環境的協作，為高層級數據模型到低層級數據模型提供轉換。（譯者注：把上層的應用使用底層技術進行實現）
- 控制節點的職責是在網絡環境和對等系統之間進行低層級狀態信息的轉播，保證整個環境的信息一致。（譯者注：進行信息同步，例如BGP信息，路由信息等）
- 分析節點的職責是記錄網絡環境的實時狀態，抽象化數據，並且適宜表現出來供應用進行使用（分析數據，呈現數據）
所有的節點都會在本章的后面詳細描述
虛擬路由器將通過軟件方式部署在網絡環境中，他們的責任通過服務器到服務器之間的通道進行一個虛擬機到另一個虛擬機之間的數據包轉發。這些overlay網絡的通道位於物理IP-over-Ethernet網絡的上層。每個虛擬路由器包含兩個部分：一個用戶空間代理部署控制平面，一個內核模塊部署轉發平面。
OpenContrail系統部署三個基本區塊
1.多租戶，也被理解為網絡虛擬化或者網絡分片，用於創建虛擬網絡，提供CUG（封閉用戶組）設置虛擬機
2.網關功能：通過網關路由器連接虛擬網絡到物理網絡（或者互聯網），連接非虛擬化的服務器，或者通過網關連接虛擬網絡的網絡服務。
3.服務鏈：也被理解為NFV，通過物理或者虛擬網絡服務（例如防火牆，深入包檢測，負載均衡）形成一個有序的流量服務流
2.1.1 節點
我們轉到系統的內部服務架構上，如圖2所示，系統通過通用x86服務器運行的相互協作的節點集合進行部署，每個節點可以部署在獨立的服務器上或者部署在一個虛擬機上
所有給定類型的節點使用A-A配置運行來保證單點不會形成瓶頸，這種擴展化的設計提供冗余和層次化的靈活性。
- 配置節點保留一個預計配置狀態的持續備份，並且為適應網絡環境的互操作從高層級數據模型到低層級數據模型的轉換，這些都保存在一個NoSQL的數據庫中
- 控制節點部署一個邏輯集中的控制平面，旨在維護一個短暫的網絡狀態，控制節點之間以及和網絡基礎架構設備之間互操作，在保證網絡狀態的持續一致。
- 分析節點搜集，存儲，關聯和分析虛擬和物理網絡環境中的信息，這些信息包括統計，日志，事件和錯誤。
另外一些節點類型也作為OpenContrail控制器的一部分，我們同時也在物理服務器和物理網絡環境中定義了一些另外的節點類型，來在整個OpenContrail系統中執行一些特定的規則
- 計算節點是運行虛擬機的通用物理服務器，這些虛擬機可能是租戶運行通用應用，或者這些虛擬機可以運行虛擬網絡服務，例如虛擬負載均衡或者虛擬防火牆，每一個計算節點都包含一個虛擬路由器，部署轉發平面和分布式控制平面（計算節點實際上就是物理服務器）
- 網關節點是一個物理網關路由器或者交換機，連接租戶虛擬網絡到物理網絡（互聯網，客戶VPN，另一個數據中心或者非虛擬化的服務器）中來
- 服務節點物理網絡環境提供諸如深度包檢測（DPI），入侵檢測（IDP），入侵防護（IPS），廣域網優化和負載均衡，服務鏈可以包含這些虛擬服務的匯集（例如在計算節點中的虛擬機）和物理服務器（在服務節點中）
為便於理解，圖中沒有展示在下層IP over Ethernet 網絡中的物理路由器和交換機。同事，在每個節點中和分析節點中存在一個接口，為避免混亂，這個接口在圖2中也沒有展示。
2.1.2 計算節點
計算節點是一個通用的x86架構服務器，作為VMs的承載。這些虛擬機可以是租戶的虛擬機，運行客戶的應用，例如網頁服務器，數據庫服務器，或者企業應用，或者這些虛擬機可以運行虛擬服務，用於創建服務鏈，標准的配置是使用KVM或者Xen作為hypervisor，上層運行Linux，虛擬路由器的轉發平面在Linux 的Kernel中，虛擬路由器的代理作為邏輯控制平面，其整體接口如圖3所示
其他支持的OS或者hypervisor例如VMware ESXi或者Windows Hyper-V可能會在未來支持。
計算節點部署的虛擬路由器包括兩個區塊：虛擬路由器代理和虛擬路由器轉發平面，這些將會在后續描述。
2.1.2.1虛擬路由器代理（虛擬路由器）
虛擬路由器是一個用戶空間進程，在Linux中運行，是一個本地的，輕量控制平面，主要提供如下功能
- 使用XMPP實現和控制節點的例如路由的控制狀態交換
- 使用XMPP從控制節點上接收低層級配置狀態，例如路由進程和轉發策略
- 向分析節點匯報例如日志，匯總和事件的分析狀態
- 向轉發平面安裝轉發狀態（下發轉發表）
- 查找VM的存在和屬性，和Nova代理進行交互
- 為每個新流的首包應用轉發策略，在轉發平面的流表安裝流表項
- 為DHCP，ARP和MDNS提供代理，其他代理會在未來版本中添加
每個虛擬路由器都會連接至少兩個控制節點，在A-A冗余模型中提供冗余
2.1.2.2 虛擬路由器轉發平面
虛擬路由器轉發平面運行在Linux的kernel中，主要負責如下功能
- 封裝數據包到overlay網絡中，從overlay網絡中解封裝數據包
- 分配數據包到路由實例中
- 從overlay網絡中接受數據包，並基於MPLS標簽或者虛擬網絡標識（VNI）分配到路由實例中
- 為虛擬機提供虛擬接口，並綁定在路由實例中。
- 在轉發信息表中進行對於目的地址的查表，並轉發數據包到正確目的，路由可以基於三層IP前綴或者二層MAC地址。
- 可選項—在轉發表中應用轉發策略。
- 匹配流表中的數據包，並應用流表操作
- 可選項—當安裝轉發規則在流表虛擬路由器轉發數據時，沒有找到流規則時掛起數據包（譯者注：這段不好翻譯，用防火牆的方式就好理解了，防火牆利用流表轉發數據，但是流表是根據rule規則來執行，通過首包創建流表，進而，當收到首包時，還沒有出現流表，就會根據規則創建流表，這時這個數據包是會被暫時緩存）
- 在虛擬路由器中掛起諸如DHCP，ARP，MDNS等數據包用於代理
圖四介紹了虛擬路由器轉發平面的內部結構
轉發平面在overlay網絡中支持MPLS over GRE/UDP和VXLAN封裝，轉發平面支持三層轉發，對目的地址進行最長掩碼匹配（LPM），也支持進行二層轉發，基於MAC地址。當前虛擬路由器的轉發平面支持IPv4，未來會支持IPv6
2.2會介紹更多細節
2.1.3 控制節點
圖5介紹控制節點的內部結構
控制節點和多個類型的節點進行通訊
- 控制節點使用IF-MAP從配置節點接受配置狀態
- 控制節點使用IBGP和其他控制節點交換路由，保證所有的控制節點保存相同的網絡狀態。
- 控制節點使用XMPP和在計算節點上的虛擬路由器交換路由，他們同樣也使用XMPP發送配置狀態，例如路由實例和轉發策略
- 控制節點同時代理計算節點方面的某些流量，這些代理請求同樣使用XMPP接收
- 控制節點使用BGP和網關節點（路由器和交換機）交換路由，他們使用Netconf發送配置狀態
2.1.4 配置節點
圖6展示配置節點的內部結構。配置節點通過REST接口和協調系統通訊，和其他配置節點通過分布式同步機制通訊，使用IP-MAP和配置節點通訊。
配置節點同時提供查詢服務，客戶可以用於定位本地提供服務（例如其他節點提供特定服務），例如，當計算節點的虛擬路由器想要連接一個控制節點（更准確說，一對A-A控制虛擬機的另外一個），用於服務查詢控制額節點的IP地址，客戶使用本地配置，DHCP或者DNS定位服務查詢服務器。
配置節點包含如下組件
一個REST API服務器提供北向接口到協調系統或者其他應用，這個接口用於使用高層級數據模型安裝配置狀態
一個Redis信息總線，用於內部組件中的通訊。
一個Cassandra數據庫用於持續存儲配置，Cassandra是一個可容錯並且層次化擴展的數據庫。
一個Schema轉換器，學習通過Redis信息學習高層級數據平面的修改，並且轉換（編譯）這些高層級數據模型的改變到低層級數據層面
- 一個IF-MAP服務器提供南向接口，推送計算過的低層級配置到控制節點
Zookeeper（圖中沒有現實），用於分配獨立的組件標識，並且部署
2.1.5 分析節點
圖7介紹分析節點的內部結構，分析節點使用北向REST API和應用進行通訊。使用分布式同步機制和其他分析節點同步，使用基於XML的協議與控制節點和配置節點的組件通訊（基於XML的協議叫做Sandesh，設計用來處理數據的高值）
分析節點包含如下組件
- 一個收集器，與控制節點和配置節點交換Sandesh信息，收集分析信息
- 一個NoSQL數據庫存儲這些信息
- 一個規則引擎，當特定事件發生時自動收集運行狀態
- 一個REST API服務器，提供北向接口，用於查詢分析數據庫和檢索操作狀態
- 一個查詢引擎，通過北向RESTAPI執行查詢接收，這個引擎為潛在的大型分析數據中提供靈活訪問的能力
Sandesh 攜帶兩類信息：異步信息從分析節點中接受，目的是匯報日志，事件和監控，同步信息用於分析節點向特定的操作狀態發送請求和接受響應，
所有的信息通過收集器收集並持續的保存在NoSQL數據庫中，信息源不會做任何過濾。
分析節點提供北向REST API接口允許客戶應用提交查詢。
分析節點提供分散收集邏輯，叫做“聚合”，一個單一的GET請求（一個客戶應用對應的CLI命令）可以映射到多個請求信息，並且形成組合的結果。
查詢引擎是一個簡單的Map-reduce引擎，OpenContrail最主要的查詢是時間系列。
2.2 OpenContrail系統轉發平面
轉發平面部署在一個overlay的網絡中。Overlay可以是三層IP的overlay網絡或者二層（以太）overlay網絡。對於三層overlay，目前只支持IPv4，IPv6會在后續版本中增加，三層overlay網絡支持單播和組播，代理可以避免DHCP，ARP以及其他協議的泛洪
2.2.1 包封裝
系統支持多種overlay封裝格式，每個封裝會在后續介紹
2.2.1.1 MPLS over GRE
圖8介紹了針對L3的overlay的MPLS over GRE包格式
圖9介紹了針對L2的overlay的MPLS over GRE包格式
MPLS L3VPN和EVPN都是使用MPLS over MPLS的封裝格式，但是也可以在核心網絡沒有使用MPLS的情況下使用MPLS over GRE。OpenContrail系統使用MPLS over GRE而不使用MPLS over MPLS有諸多原因：第一，數據中心的底層交換機經常不支持MPLS，第二，即便支持，運維人員也不希望數據中心因使用MPLS兒變得復雜化，第三，因為在數據中心中帶寬都足夠預期，不需要使用流量工程
2.2.1.2 VXLAN
對於L2的overlay，OpenContrail系統同樣支持VXLAN封裝，如圖10所示
使用VXLAN封裝的諸多好處之一是可以通過在外層頭部的UDP源端口注入entropy（詞庫翻譯成墒-內層包頭的哈希）的特點支持底層的多路徑
OpenContrail部署VXLAN和VLAN IETF草案標准有兩個顯著的不同，第一，僅僅遵從IETF 草案的的數據包封裝格式，沒有使用其泛洪和學習的控制平面內容，取而代之的是使用基於XMPP協議的控制平面實現（在本章中有描述），第二，出口虛擬路由器的VXLAN包頭的虛擬網絡標識為本地唯一，替代了全局唯一。
2.2.1.3 MPLS over UDP
OpenContrail支持第三種封裝—MPLS over UDP，這綜合MPLS over GRE和VXLAN封裝，支持二層或者三層的overlan，是用一個“內層”MPLS包頭作為本地MPLS標簽標識，用於識別目的路由實例（類似於MPLS over GRE），但是是用一個外層UDP包頭，便於底層網絡的多路徑傳輸（類似VXLAN）
圖11 顯示了MPLS over UDP封裝支持三層overlay
圖12 顯示了MPLS over UDP封裝支持二層overlay
2.2.2 Layer 3 Unicast 三層單播
下面介紹VM 1a到VM 2a發送一個IP 數據包的逐一流程，詳細內容可以參考 [draft-ietf-l3vpn-end-system].，這個流程描述的是IPv4，而IPv6在步驟上類似。
1.VM 1a上的應用發送一個數據包，目的地址是VM 2a
2.VM 1a有一個缺省路由指向路由實例 1a的169.254.x.x 本地地址
3.VM 1a為這個本地地址發送一個ARP請求，在路由實例 1a上的ARP 代理進行響應
4.VM 1a發送IP數據包到路由實例 1a
5.在路由實例1a上的IP FIB（IP轉發信息表）會包含相同虛擬網絡中其他所有VM的32位路由，包括VM 2a。這些路由是控制節點通過XMPP安裝。對於下一條路由會具有以下操作
a.壓入一個MPLS 標簽，該標簽為虛擬路由器2 為路由實例2a分配。
b.壓入一個GRE標簽，目的地址為計算節點2
6.虛擬路由器1 通過全局 IP FIB1 查找封裝包新的目的IP（計算節點2的IP）
7.虛擬路由器1發送封裝后的數據包到計算節點2，下一步如何發生，將根據底層網絡是使用二層交換網絡還是三層IP網絡，這部分描述會在后面介紹，現在我們先忽略這個步驟，設定封裝過的數據包已經傳送到了計算節點2
8.計算節點 2 接收封裝后的數據包，並開始在全局 IP FIB 2上進行IP查找，當外層目的IP就是本地地址時，會進行解封裝，移除GRE頭，顯示出MPLS頭
9.計算節點 2 在全局 MPLS FIB 2中執行MPLS標簽的查找，查找到表項定位在路由實例 2a上，解封裝包頭，移除MPLS標簽，並把解封裝后的數據包發送進入路由實例 2s
10.計算節點2a 在IP FIB 2a中進行解封裝后的內層IP地址的查找，定位路由指向連接VM2a的虛擬端口
11.計算節點 2 發送數據包到VM 2a
現在我們回到剛才步驟7略過的部分，如果把封裝后的數據包通過底層網絡轉發。
如果底層網絡是二層網絡，那么：
1.封裝數據包的外層源IP地址（計算節點1）和目的IP地址（計算節點2）在同一個子網
2.計算節點1 發送對於計算節點2的ARP請求，計算節點2發出ARP響應，包含計算節點2的MAC地址，注意，在底層網絡中沒有ARP代理封裝的數據包
3. 通過二層交換基於目的MAC地址從計算節點1發送到計算節點2
如果底層網絡是3層網絡，那么：
1.封裝數據包的外層源IP地址（計算節點1）和目的IP地址（計算節點2）在不同子網
2.所有包括物理路由器（S1和S2）和虛擬路由器（虛擬路由1和虛擬路由器2）底層網絡的路由都在運行某一個路由協議（如OSPF）中
3.封裝后的數據包通過三層路由基於目的IP地址從計算節點1到計算節點2，等開銷多路徑（ECMP）允許多個平行路徑可以被使用，基於這個原因，在UDP包源端口內VXLAN封裝的entropy也可以被使用。
2.2.3二層單播
二層overlay網絡的轉發和前面提到的三層overlay網絡的轉發相同，區別在於
- 路由實例里面的轉發表包含MAC地址，而不是IP前綴
- ARP並不用於overlay中（但是用在底層網絡）
2.2.4 Fallback Switching
OpenContrail支持混合模式—在虛擬網絡中混雜二層和三層的overlay。虛擬路由器中的路由實例同時包含IP FIB和MAC FIB。對於每一個數據包，虛擬路由器先查找IP FIB，如果IP FIB中匹配路由，那么將轉發數據包，如果IP FIB中不匹配路由，那么將查找MAC FIB-這就是fallback switching
注意fallback switch“先路由后交換”的行為於IRB（集成路由交換）“先交換后路有的行為”完全相反。
2.2.5 三層組播
OpenContrail支持三層overlay的IP組播，組播操作將通過overlay的組播樹和底層網絡的組播樹來實現，任何一種方式，組播樹都可以是共享樹（*.G）或者詳細源樹（S,G）
2.2.5.1 overlay 組播樹
OpenContrail支持組播部署使用overlay中的組播樹取代底層網絡的組播樹，詳細描述可在[draft-marques-l3vpn-mcast-edge]中，這里我們只匯總一些基本概念
圖15描述了在overlay中創建組播樹的基本概念。作為組播樹的root的虛擬路由器發送N個復制流量到N個下行虛擬路由器，下行路由器在發送N個復制流量給更多的虛擬路由器，進而，知道所有的接受路由器全部覆蓋，這個案例中N等於2，數字N並不等於每一個虛擬路由器
系統使用XMPP信令在每個虛擬網絡中的虛擬路由器建立FIB，創建overlay的組播樹，協議比較復雜，詳細描述請參考[draft-marques-l3vpn-mcast-edge]
入口復制，如圖16所示，通常是用於常規的overlay組播樹的一些陳舊案例中，從實踐上來說，入口復制的信令要比常見overlay組播樹要更簡單一些
2.2.5.2 底層組播復制樹
組播實現的另外一個替代方案是在底層使用組播樹，如圖17所示
這個和通常在MPLS VPN中部署組播比較接近（參見 RFC6513），同樣，VXLAN中泛洪並轉發控制平面（描述在 [draft-mahalingam-dutt-dcops-vxlan] ），也依賴於底層的組播樹
底層組播樹是使用組播地址建立GRE通道，這就暗示着底層網絡必須要支持IP組播，必須運行一個組播路由協議例如PIM協議，並且必須為每個組播樹提供一個組播租
2.2.5.3 對比
對於底層網絡的交換機使用組播樹，支持IP組播，在實踐上會出現一些問題，主要包括
- 盡管底層網絡支持組播，運維人員不希望開啟組播帶來管理和排錯的復雜性
- 基於商用芯片的交換機，往往在轉發平面支持比較相對有限的組播租，對於組播的最優部署，需要底層網絡為overlay網絡每一個租戶的每一個組提供組播地址，這就需要大量的組播租。當然，使用為每個虛擬網絡單一共享樹可以減少底層網絡的組播租，但是這又帶來可優化的開銷，並增加的復雜性，
- 在底層運行組播，數據中心交換機在控制平面上維護每一個組接受者的狀態，這些狀態信息會異常巨大。
- 組播控制平面協議會帶來CPU的密集操作，因為組播樹需要在接受者加入或離開時時刻更新。
從另一個方面來說，overlay的組播樹也會帶來產生影響，但是
- 第一個問題，組播復制同樣的數據包跨越相同的物理鏈路，尤其是靠近源端的鏈路，這樣會消耗帶寬，但是和廣域網不同，對於數據中心網絡，這並不是一個大問題，因為數據中心矩陣而言，所提供的是一個CLOS架構的矩陣，可以提供任意點無阻塞的連接。
- 第二個問題是overlay組播樹將組播實現的功能在軟件虛擬路由器上實現，也會帶來CPU的影響，底層網絡的硬件交換機通常使用硬件支持組播實現，這個問題可以如圖15所示，通過多個虛擬路由器級聯的方式實現組播復制，來得以緩解。
2.2.6 Layer 2 BUM Traffic
二層廣播，未知單播和組播流量需要在二層網絡中泛洪，在OpenContrail中，未知淡泊流量會被丟棄，而不是泛洪，因為系統並不是依賴泛洪-學習的機制來建立MAC地址表，取而代之的是，使用控制協議去建立MAC地址表，如果目的地址未知，那意味着可能是系統出現了某些故障。二層廣播也同樣避免，因為大部分二層廣播都是因為一些協議的操作出現。
對於其他已知的二層廣播和組播，系統為每一個虛擬網絡的創建一個分布樹，連接虛擬網絡中的所有路由實例，這個樹可以由overlay或者底層網絡構成。
2.2.7 代理服務
虛擬路由器代理很多類型的流量（從VM發出的），以此避免泛洪。虛擬路由器攔截特定的數據包，並把這些流量通過XMPP代理給控制節點，控制節點通過XMPP返回響應
當前系統代理如下類型的流量（其他流量代理會在后續增加）
- DHCP請求。控制節點會根據VM的配置提供DHCP的響應
- ARP響應。控制節點提供IP和MAC地址的對應
- DNS和MDNS請求，控制平面提供域名和IP地址的對應。
2.2.8 轉發策略
虛擬路由器轉發平面包含一個流表，提供多個功能—防火牆策略，負載均衡，匯總等。流表包含流表條目，包含匹配條件的關聯的操作，匹配田間可以是接收數據包N元組的匹配（可能是掩碼匹配），操作包括數據包的丟棄，允許，或者重定向到另外一個路由實例。流表條目通過虛擬路由器代理在轉發平面上形成。
當流表中沒有相應條目時，會把數據包掛起，並轉發給虛擬路由器代理，這樣可以讓虛擬路由器識別是否是一個新的流的首包，虛擬路由器代理會為每一個新流創建流表，並把首包發送到轉發平面。
2.3 服務鏈
OpenContrail支持高級策略語言，允許虛擬網絡基於策略互聯，這個策略語言類似於Snort規則語言，但是在系統上做了改變和擴展，策略規則如類似於
allow any src-vn -> dst-vn svc-1, svc-2
這個規則允許所有的流量，從虛擬網絡src-vn到虛擬網絡dst-vn，並且強制流量經由服務鏈，先經過服務svc-1，然后到svc-2，在前面的案例中，規則允許虛擬網絡src-vn的任何虛擬機發送流量到虛擬網絡dst-vn的任何虛擬機。
系統考慮流量的引導，將流量使用虛擬接口注入到正確的虛擬機中，這些（負責服務的）虛擬機可以提供諸如防火牆，DPI，IDS，IPS，緩存等網絡服務
系統為租戶虛擬機增加新的路由實例，為負責服務的虛擬機創建路由實例，流量被引導
- 通過操縱路由的route target（RT）影響從一個路由實例到另外一個路由實例的注入和導出
- 通過操縱下一條和（或者）路由的標簽，使得他們可以把路由實例的路由相互泄漏，強制流量按照正確的順序在路由實例中轉發，流量經由正確的虛擬機。
圖18描述了服務鏈中流量在路由實例中轉發的基本概念
在上面的案例中
- 通過路由實例中的RT（route target）的注入和導出，使得路由泄漏可以從ri-t2到ri-s2，然后泄漏到ri-s1，再到ri-t1
- 當負責服務的路由實例導出路由時，他們將自己指定為下一跳，並且產生一個新的label。
- 下一跳引導流量到服務器（也就是服務虛擬機所在物理服務器）
- 標簽引導流量到該物理服務器上的負責服務的虛擬機上
IETF draft[draft-rfernando-virt-topo-bgp-vpn] 描述了服務鏈的類似機制
2.4 控制和管理平面協議
2.4.1 IF-MAP
The Interface for Metadata Access Points (IF-MAP) [if-map] 是一個開放標准的客戶端/服務器協議，由Trusted Computer Group (TCG)開發，作為Trusted Network Connect (TNC)開放架構的核心協議。
原始的IF-MAP應用提供一個Metadata Access Point (MAPs)的通用接口，數據庫服務器扮演票據交易所的角色，負責TNC架構中的安全事件，組件和其他內容的信息
IF-MAP提供一個定義數據模型的擴展機制，同時也定義了一個協議，用於發布，訂閱，數據存儲的查詢。
OpenContrail使用IF-MAP協議從配置節點到控制節點分發信息。控制節點可以使用訂閱機制，僅僅接受他們感興趣的配置信息的子集。系統同時使用IF-MAP定義高層級和低層級配置數據模型。
2.4.2 XMPP
The Extensible Messaging and Presence Protocol (XMPP) [xmpp] 是一個用於信息導向的中間件，基於XML的通訊協議。XMPP原來叫Jabber，用於即時信息，出席信息和聯系列表維護，其設計具有擴展性，協議已經進化成通用的發布訂閱信息總線，可以用在多種應用中。
OpenContrail使用XMPP作為一個計算節點和控制節點之間交換大量例如路由，配置，運行狀態，統計，日志和事件的通用信息總線
IETF drafts [draft-ietf-l3vpn-end-system] 和 [draft-marques-l3vpn-mcast-edge] 描述了 XMPP 和信息格式
2.4.3 BGP
OpenContrail使用BGP在控制節點之間交換路由信息。BGP也被應用在控制節點和網關節點（大多數網絡廠商路由器和交換機）交換路由信息。
2.4.4 Sandesh
Sandesh是一個基於XML的協議，用於匯報分析信息。XML信息的結構被描述成公共語法格式。每個節點的組件都有一個Sandesh連接到分析節點之一上。Sandesh攜帶兩類信息
- 系統的所有組件發送異步協議到分析節點上，匯報日志，監控，事件等
- 分析節點可以發送請求信息和接收響應信息去收集特定的運行狀態。
2.5 Openstack Integration
圖19描述了OpenStack Nova, Neutron 和 OpenContrail之間的集成。
OpenStack的Nova模型通過計算節點中的Nove 代理創建虛擬機。Nova代理和OpenContrail Neutron插件通訊，檢索新的虛擬機的網絡屬性（如IP地址），當虛擬機創建，Nova代理通知虛擬路由器代理為新創建的虛擬機創建虛擬網絡
2.6 安全性
所有的控制平面協議使用Transport Layer Security (TLS) 和 Secure Sockets Layer (SSL)提供驗證和數據完整性，也可以用於提供數據的私密性，盡管這並不在數據中心的考慮之內。
初始化服務查找證書用於驗證，后續的通訊都是基於令牌的驗證，用以提高性能。服務查詢服務器通過證書驗證TLS連接在服務器和客戶端之間產生令牌證書的分發超出了本文檔的范圍，從實踐上說，這部分工作由服務管理系統例如puppet或者chef來負責。
所有系統內的REST API使用基於策略的授權，服務器通過TLS驗證識別客戶端，並且指派一個或者多個規則。規則定義客戶端的接口操作（只讀或者讀取）和哪些數據模型的組件客戶端可以訪問。
2.7 層次化彈性和高可用性
為使層次化彈性的高可用性更佳，控制節點，配置節點和分析節點都有多個實例，所有實例都是雙活（A-A），OpenContrail並沒有使用A-S方式
2.7.1 配置節點
目前，所有的控制都包含整個系統的運行狀態，例如，所有虛擬網絡中所有虛擬機的路由，控制狀態的總數相比較而言較少，更適合每個配置節點的內存占用。當更多的功能加入之后，控制節點之間控制狀態的匯總和分片將會在未來引入，原理類似於BGP中的RT特定路由反射。
每個虛擬路由器代理連接兩個或者多個節點，所有的節點都是A-A狀態，虛擬路由器代理從每個控制節點接受所有的狀態（路由，路由實例的配置等），從兩個或者多個節點接受到的狀態保證最終一直，但是有可能短暫的不一致。每個虛擬路由器代理執行本地選擇，選擇使用哪一個控制狀態的副本。這類似於BGP PE路由器接受到相同路由（從每一個BGP鄰居）的拷貝但是執行本地的最優路徑選擇。
當一個控制節點失效，虛擬路由器代理將會通知到這個控制節點的連接已經丟失，將會刷新所有從這個失效控制節點接收的狀態信息。因為已經有了從其他控制節點的所有信息的狀態，虛擬路由器可以本地迅速進行切換，而不需要重新同步，虛擬路由器代理將會再次聯系服務查詢服務器，和一個新的控制節點建立連接，取代失效的控制節點。
2.7.2 配置節點
配置節點保存所有配置狀態在一個可容錯，高可用性的NoSQL數據庫中，包含高層級數據模型的內容，如預留系統明確安裝的配置狀態，同時也包括低層級數據模型的內容，例如通過轉換模型從高層級數據模型導出的配置狀態
控制節點使用IF-MAP訂閱控制平面需要的低層級數據模型的部分。服務查找服務器指定每一個控制節點到特定的配置節點。如果配置服務器失效，控制節點重新聯系服務查找服務器指定另一個配置服務器、
切換之后，控制節點重新和新的配置節點同步，這類似於路由協議中平滑重啟達到的目的—保證所有狀態，完整回復並且刷新已有狀態信息。
2.7.3 分析節點
系統提供所有分析組件的完整高可用性功能，類似於配置節點，分析節點是無狀態的，分析節點的失效不會導致系統丟失信息，當一個分析節點失效，系統查找服務器將會將會把功能轉移到一個可工作的分析節點上，並且所有上行REST API同樣使用查找服務器去檢測節點的失敗和功能節點的轉移，失效的分析節點將會從可用的節點池中剔除，剩下的分析節點中的一個將會執行工作，收集數據和處理查詢。
OpenContrail提供數據庫組件的完整的高可用性，數據庫集群設置有多重備份的屬性，當數據庫節點失敗，數據本身可具備彈性，集群可以在多個數據庫節點失效時具備彈性，當數據庫節點失效，分析節點可以平滑的從失效節點到可用節點上，在這個過程中，我們將會把數據隊列清空，在轉移過程中數據的丟失將會非常小。
2.7.4 虛擬路由器代理
虛擬路由器的高可用性基於包括BGP在內的很多路由協議的平滑重啟，如果虛擬路由器代理因為任何原因重啟（崩潰，升級），虛擬路由器的轉發平面將會基於由虛擬路由器代理在重啟前安裝的轉發狀態繼續轉發數據。
當虛擬路由器代理失效，虛擬路由器的轉發平面運行在一個“無腦”模式，所有的轉發狀態都是保持原有，當虛擬路由器代理重啟，將會重新和冗余的控制節點建立通訊關系，並且從控制節點上重新學習狀態，重新在轉發平面上安裝狀態，替換原由的狀態。
當虛擬路由器代理完成從控制節點的狀態學習，完成轉發平面內的狀態重新安裝，所有轉發平面的狀態全部被刷新。
2.7.5 虛擬路由器轉發平面
如果虛擬路由器轉發平面因為任何原因（崩潰，升級）重啟，將會影響特定服務器的流量處理。
這種情況不可避免，因為我們在每一個路由器上只有一個轉發平面和轉發實例，所以，保證路由器的越簡單越好，減少崩潰和升級的可能，是非常重要的。
3 數據模型
系統所有狀態的基礎，不管是配置，運行還是分析，都是數據模型的集合。每個數據模型定義了組件的集合，語意，以及他們之間的關系。系統運行在他們的數據模型上來執行工作：創建和更新組件和關系，轉換“高層級”組件到“低層級”組件，安裝低層級組件到網絡環境中，創建所需要的連接和服務。數據模型提供確定的性能給可供操作的模塊，並且為模塊定義確定的需求。數據模型如此設計的主要結果是系統具有分布式，可靈活，高可用性，易於升級和具備彈性。
數據模型是從本質上從表層提供一個具有注釋的圖表來展現組件，和通過連接展現組件之間的關系，系統使用一個數據模型語言（DML）Data Modeling Language 去定義他們，一些組件的語意和他們之間的關系，在數據模型中直接體現，例如圖表的表層可以展示抽象或者具體的組件，並且連接可以展示一對組件之間是“父子”關系還是從屬關系。剩余的語意可以通過表層或者鏈路的注釋來描述，一對表層之間的連接鏈路可以注釋上需要的帶寬，路由實例之間的鏈路可以注釋需要的路由策略（譯者注：vertices翻譯過來時頂層，最頂的意思，實際上個人理解就是在ppt里面畫圖上的最上層的圖標）
3.1 程序模型
配置和運行狀態的數據模型使用IF-MAP定義，其自身數據保存在一個Cassandra數據庫中，這個數據庫提供持續的，可用的和可擴展的規格參數。一個使用Redis的“發布訂閱模型”總線覆蓋在頂層，作為內存關鍵值存儲。模塊和數據庫互操作，可以選擇定於制定類型的更新，當模塊發布一個更新到一個組件，更新會發布給其他訂閱該類型組建的模塊。
數據模型的所有修訂必須具有向后兼容的能力，從另一個角度說，參考數據模型的程序必須可以和以前一樣持續工作，而不需要修改。這就意味着對於數據模型的改變只能擴展現有組件，連接和注釋，但是必須不能改變現有組件的語意，或者他們之間的關系。進而，修改永遠不能和一個組件或者鏈路類型相悖。例如組件之間的關系可以向后兼容，可以修改到數據模型中的未來需求必須是增量的，注入到現有運行模塊的改變，而不需要重新編譯。
訪問數據模型是經由一個RESTful API，從模型定義自動產生，進一步，為其他語言（Python，Java等等）的綁定也會產生，允許成需要使用這些語言在模型中操作數據。
運行在這些數據模型的模塊必須是事件驅動的。這意味着兩件事：第一，一個模塊必須監聽“發布訂閱模型”總線的更新；第二，當得到特定行為所需要的所有信息時，就要執行行為。更新可能來自任何順序—發布訂閱模型總線不會保證更新的順序或者管理歸屬—這是每個模塊的責任。進一步說，模塊必須要可重啟，如果崩潰，或者強制重啟（如更新），將會重新連接數據庫，重新請求狀態並持續處理。為完成這些，一個模塊必須要通過數據模型或者“這個網絡”保持所有數據庫的非臨時狀態，模塊可以重新從對等體請求狀態信息。最后，模塊必須是有彈性的，他們必須具有分布式的工作特性。實例必須依據當前的負載決定創建或者終止。完成這一目標需要分布式數據庫保持數據模型，並且具有分布式的條目（例如為獨立的ID產生）協調服務（譯者注，這段比較晦澀，也翻譯的不是很准確）
3.2 配置和運維數據模型
數據模塊包含一個層次化的模型，呈現成一個樹狀的，帶有注釋的直連非循環圖表（DAG）。DAG的頂點展現的組件可能是管理名稱，或者是物理或者邏輯的資源。DAG之間的連接體現的是組件之間的關系。一個組件可能有0個或者多個子集但是必須有一個明確的父集（除了根之外，根不需要父集），刪除一個組件就會隱形的刪除下面的子樹。一個組件可以參考另外一個組件–用一個“參考點”作為維護。刪除參考的組件就削弱參考點。刪除顯著參考的組件是不允許的。可以不存在組件的“弱參考”，一個組件的“弱參考”可能被刪除。（譯者注：這段是描述組件之間的關系，意義不大，可以看下面的圖就會理解的多一些）
如圖20所示，DAG的根層下面顯示的是系統的多個領域的組件，例如“管理域”（AD），可能是一個數據中心集群，一個POP節點，一個辦公網中心，或者是一個廣域網。一個AD具有一個全局的管理員去進行管理，AD還有一個為內部可能使用的標識關聯的命名空間。例如，IP地址，域名和路由實例ID的標識。
一個AD中包含一個或者多個租戶或域，舉例來說，DC內的租戶可能是可口和百事。在POP或者CO的租戶可能是業務客戶或者寬帶業務的服務部門。
一個租戶可以包含多個項目，租戶中的一個部門，例如市場部將作為一個項目存在，項目包含虛擬網絡（VN），DC中的一個VN可以包含一個應用層的一系列虛擬機。POP上的VN可能是為企業客戶的VPN，使用類似策略的一組移動寬帶用戶，或者是企業網絡中的一組用戶。
一個項目包含服務實例，網關和策略。一個項目同時具有安全組，管理員可以制定“規則”到端點，這些規則可以為端點定義未來的策略。
虛擬網絡VN包含端點，在DC域，端點就是虛擬機，對於業務邊緣，端點就是客戶站點（CE），端點作為安全組中的一部分，可以參考安全組。
數據模型的其他組件是路由實例“RI”，一個VN會編譯進入一個或者多個RI，在虛擬路由器里面部署，另外其他的組件是RT,用於控制RI之間的路由泄漏。
在數據中心中的內容做了層次化的部署，但是這種部署已經足夠包含其他領域。在一些案例中，層次化的特定層級可能是冗余的，在這個案例中，一個獨立的實例可以用在這個級別去維護層級。舉例來說，如果租戶的概念不需要，那就是一個租戶作為作為部署的基本租戶層級，如果需要新的層級，那么必須向后兼容（譯者注：這部分的內容主要是介紹業務的部署模式層次化，例如，把數據中心分成多個租戶，然后每個租戶下面還可以開啟多個部門，每個部門下面在開啟project，然后在划分VR和VN，當然，如果環境比較簡單的話，就意味着數據中心只有一個租戶，這個租戶有沒有部門沒關系，開啟project，然后划分VR和VN，具體看下面的圖表會比較容易理解）
假定層次化的一個新的層級-部門—部署在租戶和項目之間，可以很簡單的添加進來，當然，這種需求可以向后兼容，這就意味着三件事
1.部門必須是層次化中的可選級別，這就意味着，必須可以直接在租戶下面創建項目並且也可以在部門下面創建項目
2.一個項目可以作為租戶的子集存在，直到這個子集被刪除。
3.一個新的項目可以作為租戶或者部門的子集，但是不同屬於兩個。
同樣，一個應用，如果請求一個租戶的子集，就必須准備接受其他類型的子集，可以簡單的忽略他們，但是一定會引發問題，或者造成失敗。（譯者注）
前面的圖表左面顯示的是做為租戶和項目之間父集-子集關系的數據模型，在項目上的虛線連接一個新的級別—部門，右面是數據模型的一個實例，有租戶t1和項目t1.p2,用橙色表示，這是原始的數據模型，同時也展示了一個部門t1.d1，並且另外一個項目t1.d1.p1，用紫色表示，這就遵循了修改后的數據模型，注意每一個項目只能屬於一個父集，橙色項目t1有自己的父集，紫色項目t1.d1也有自己的子集。
3.2.1 高層級和底層級數據模型
所有的組件和關系存在於常見的數據模型。在高層級和低層級內部的組件也有些區別。配置狀態需要考慮通過外部系統（協調系統或者應用）創建的組件，並且作為高級數據模型的一個部分，例如租戶和項目。模塊創建的組件處於運行狀態，同時也要作為低層級考慮的部分，因為他們處於內部網絡環境的抽象層中，如路由實例。一些組建需要同時被配置和創建，在高層級和底層級均有涉及，例如RT—會被創建，同時也會配置，使得系統可以和外部的BGP speaker通訊。
進一步說，一些物理設備條目也會顯示在數據模型中。舉例來說，每個服務器上的虛擬路由器的實例都會顯示，系統感興趣的每個BGP speaker（在控制節點內部，同時包括OpenContrail的對等體，例如DC網關）也會顯示。最終，物理和虛擬的平台也展示出來，這些組件用來監控BGP或者XMPP會話，以及他們之間的服務鏈接。
3.2.2 服務連接數據模型
一個服務“鏈”既是在跨越兩個VN對之間數據流的標准，從VN出來的流量可能在到達另外一個VN之前通過仲裁圖示經過一個服務節點，流量可能會基於服務選擇不同的路徑（例如，一個IDS可能指引流量到一個DPI引擎），或者為了監控的目的復制流量。
服務鏈的定義包含兩個部分：從入口VN，到設置的服務部分，在到出口VN的流量路徑和應用在每一個服務部分的服務模板。如圖所示，每一個定義都會注釋到組件上。
4 OpenContrail使用案例
OpenContrail有三個當前可用的應用案例—企業的私有雲架構即為服務（b）和運營商的虛擬私有雲，網絡功能虛擬化（c），本文並不能全面的提供完整的應用案例，但是可以提供一個應用案例的簡單描述。
4.1 數據中心領域應用案例
4.1.1 數據中心內部協調器的職責
在我們深入探討數據中心應用案例規范之前，討論數據中心內部協調器的職責是非常必要的。
在數據中心內，協調器（Openstack, CloudStack, VMware, Microsoft System Center, 等等）管理着數據中心多諸多關鍵要素。
- 計算
- 存儲
- 網絡
- 應用
SDN控制器的職責是繼續應用的需求協調網絡和網絡服務（如負載均衡和安全），並指定計算和存儲資源。
協調器使用SDN控制器的北向接口在抽象層的最高層級協調網絡，例如：
- 為租戶創建一個虛擬網絡，在數據中心內部或者是跨越數據中心。
- 為租戶虛擬網絡附加一個虛擬機
- 連接虛擬租戶虛擬網絡到一些外部網絡，例如互聯網或者VPN
- 在一組虛擬機或者租戶網絡的邊界應用一個安全策略
- 在虛擬網絡中部署網絡服務（例如負載均衡器）
SDN控制器的責任是將這些抽象層高層級的請求轉化成物理或者虛擬網絡設備上實際的操作，例如：
- 物理交換機，如架頂（TOR）交換機，匯聚交換機，或者單層交換矩陣
- 物理路由器
- 物理服務設備例如防火牆和負載均衡器
- 虛擬服務-例如虛擬防火牆
4.1.2 虛擬多租戶數據中心
虛擬多租戶數據中心使用案例允許多個租戶存在於一個數據中心，多租戶意味着租戶共享同樣的物理基礎環境（服務器，網絡，存儲）但是邏輯上彼此分割
租戶的概念着在不同的描述下可以有不同的定義
在運營商數據中心提供公有雲服務，是一個客戶或者是客戶的一類服務
- 在一個企業數據中心部署私有雲，意味着可能是一個部門或者是為用戶提供的一個服務。
- 因為一些網絡架構（特別是常見的點到點VLAN）具有每數據中心4096個租戶的限制，所以，租戶的數量很重要。
不是所有的數據中心都是多租戶，一些大型內容提供商（例如Facebook）具有私有數據中心，僅作為內部應用，目前還沒有提供雲服務。盡管這些數據中心可以支持多租戶行為，但是並不去使用多租戶的定義。
例如，早期的亞馬遜網站服務（AWS）支持多租戶，但是從網絡方面去看租戶並不是相互隔離（所有的租戶連接相同的三層網絡），直到亞馬遜引入一些高級服務（叫做虛擬私有雲-VPC），允許每個租戶可以獲得一個或者多個私有隔離網絡。
圖23介紹了在不同市場划分下虛擬化和多租戶的需求，虛擬化的使用，不同的市場分段使用不同的協調器和hypervisor。
- 在企業市場方面，商業協調器被廣泛使用，隨着雲的逐漸采用和向SDN的演進，也存在和開源（如OpenStack或者CloudStack）集成的需求
- 在架構即服務（IaaS）和公有雲市場，開源協調器（OpenStack，CloudStack）和hypervisor（如KVM，Xen）經常被使用，可以用於定制化，開銷和擴展的原因。
- 大型內容提供商（如Google和Facebook）經常建設他們自己的協調器軟件並且不使用hypervisor（因為性能和 擴展性的原因）（譯者注，這段只能贊同一點點）
通常情況，如24圖所示，每一個租戶相當於運行在物理服務器上的虛擬機的集合，hypervisor包含虛擬交換機（vSwitch）連接虛擬機到物理網絡和其他虛擬機，應用也可以直接運行在物理服務器上（不是在虛擬機中），如右側的綠色服務器（B）現實。
在圖24中，數據中心網絡可能會有多層網絡，或者在圖25中，數據中心網絡可能是單層網絡（如Fabric）
服務器使用物理數據中心網絡互聯，在圖24中，網絡分成兩層（接入和核心）網絡，也可能是三層（接入，匯聚，核心）網絡，或者一層（如Q-Fabric）網絡。對於overlay解決方案中，數據中心網絡建議是Layer 3網絡（IP或者MPLS）。
在最簡的網絡架構，如圖26所示，雲提供商為每個虛擬機指定IP地址，給定租戶的虛擬機不在同一個L2網絡中。所有的虛擬機（從同一個租戶或者不同的租戶）可以通過路由IP網絡相互通訊
例如，亞馬遜網站服務，彈性計算雲（EC2）默認給每一個虛擬機一個私有IP地址（可以在亞馬遜EC2網絡里互聯）和一個公有IP地址（通過NAT和互聯網通訊），當虛擬機建立后，亞馬遜自動生成私有和公有IP。亞馬遜EC2彈性IP地址功能指定有限的（默認五個）靜態IP（給租戶用於分配給VM）用於和互聯網連接。
在一個網絡中隔絕租戶里面的相互訪問，每一個租戶可以被指定一個私有的L2網絡，如圖27所示，租戶網絡允許虛擬機和其他同一個租戶的虛擬機相互訪問，除非是策略限制。租戶網絡相互之間隔絕，一個租戶內的虛擬機不能和其他租戶的虛擬機相互訪問，除非被特定策略允許。同樣，除非是特定策略允許，虛擬機不能實現互聯網訪問。
租戶私有網絡通常成為虛擬網絡。在給定的租戶網絡中的所有的虛擬機在一個L3子網。租戶可能允許允許使用他們自己的IP給虛擬機，或者雲提供商可以分配IP地址，任何一種方式下，在不同的租戶里IP地址可能不唯一（如相同的IP地址可能用在兩個不同租戶的兩個虛擬機中）
一個租戶可能會有多個虛擬網絡，這些虛擬網絡之間通過使用三層路由器，防火牆，NAT，負載均衡或者其他服務有可能互聯，也可能不互聯。
作為一個虛擬租戶網絡隔離的案例，亞馬遜虛擬私有雲服務（VPC）允許租戶創建一個或者多個子網，並且將他們相互連接，或者到互聯網，或者使用路由器或者服務（如NAT）到特定網絡。
使用案例包括一個邏輯集中的協調層（在前面都沒有顯示）去管理租戶網絡
- 添加和刪除租戶
- 定義租戶網絡的帶寬，QOS和安全屬性
- 其他
協調層必須覆蓋租戶網絡的所有方面（計算，存儲，網絡和存儲）和支持快速改變。
4.1.3 連接租戶到互聯網/VPN
在這個案例里，租戶連接到互聯網或者通過VPN連接到企業網絡，VPN可以是L3VPN，L2VPN，SSLVPN和IPsec VPN等等。
數據中心網關的功能是連接租戶網絡到互聯網或者VPN，網關的功能可以部署為軟件或者硬件形式（例如使用網關路由器）
4.1.4 數據中心互聯
在這個案例中，多個數據中心通過廣域網（WAN）進行互聯。
數據中心可以是在災難恢復上使用活躍/備份模式，在災難避免時使用活躍/活躍方式，或者永久的雙活，在雙活案例中，租戶可能在多個數據中心中存在虛擬機，數據中心互聯技術使得跨越所有數據中心的給定租戶的虛擬機處在同一個虛擬網絡中。
DCI必須滿足如下網絡需求
- 存儲的復制
- 允許租戶網絡使用覆蓋的IP地址跨域數據中心
- 全局的負載均衡
- 為容災實現虛擬機跨越數據中心遷移
數據中心互聯上存在很多技術，包括裸光纖，SONET/SDH, DWDM, 偽線, Layer 3 VPN, E-VPN等等，不同於數據中心網絡，在DCI的廣域網上，帶寬是一個稀缺資源，所以流量工程經常使用，保證資源的有效利用。
4.1.5 網絡監控
在數據中心網絡一直得經常需要在網絡中特定的節點復制特定的流，並且為了未來的分析需要發送到一個或者多個監控設備，這就是所謂的網絡監控或者TAP使用案例
監控可能是臨時的，舉例來說，做網絡的debug，或者監控可能是永久的，例如為了常規審計的原因
常見的監控部署，是配置交換機的端口分析（SPAN）功能在網絡中，發送復制的數據到特定的端口。遠程SPAN是更高級的功能，允許復制的流量可以通過GRE發送到遠端分析設備上
一個集中的SDN系統可以用於
- 在網絡中的監控選擇點（TAP）創建一個通道，監控設備收集和分析流量
- 要求網絡中交換機和路由器輪詢流量的特定流進入通道進行分析。
4.1.6 動態虛擬服務
在這個使用案例中，網絡服務如防火牆，入侵防護系統，入侵監測系統，負載均衡，SSL負載，緩存和廣域網優化都被部署在租戶網絡中
這些服務由服務節點提供，可以放置在圖31中的各種位置
服務可以部署在多個位置
- 在hypervisor上
- 在虛擬機內
- 在物理設備上
- 在物理或者虛擬交換機上商用ACL
- 在路由器或者交換機的服務板卡上開啟服務，或者本身在轉發ASIC上就具備支持此類服務的能力
服務可能會關聯一個或多個VM，例如使用一個安全策略到一個或多個VM上，
取而代之的是，服務可能被關聯在網絡邊界上，例如應用安全策略在網絡邊界，或者安裝負載均衡設備在網絡邊界，如圖32所示，網絡邊界可能是
- 租戶網絡和外部網絡之間的邊界（互聯網或者企業VPN）
- 租戶網絡之間的邊界
- 同一個租戶的多個網絡之間的邊界
4.2 SP環境下的NFV
4.2.1 服務注入
邊界路由器需要應用一些服務（防火牆，DPI，caching，HTTP包頭豐富）到訪問用戶的流量上。這些服務可能是由一個路由器的服務卡提供，也可能是有物理服務組件或者雲中的虛擬物理組件實現。
SDN系統用於創建和管理虛擬或者物理的服務，並且創建服務鏈，為訪問用戶的流量形成服務的流量鏈，這些可以基於本地的配置但是更多是通過一個集中的策略服務器來完成。
4.2.2 服務案例-虛擬CPE
在寬帶接入網絡中，每一個接入訪問者會被提供一個用戶前端設備（CPE）-通常是多業務服務器。運維者希望這些CPE可以提供更多的功能以便和OTT廠商競爭，但是這又面臨挑戰，因為
- CPE廠家增加新功能緩慢，硬件功能增加有限，（為實現新功能）替換設備又代價昂貴。
- 諸多不同的CPE設備在網絡中又帶來功能支持的不一致性。
在虛擬CPE使用案例中（也就是雲CPE案例）運維者可以解決這些問題
- 使用簡單的CPE僅支持基本的二層和三層功能
- 虛擬化剩下的服務，在虛擬機中運行，或者集中式的運行在通用x86硬件上，被集中的協調和預留管理
基於服務器的虛擬CPE可以部署在不同的位置
- 附着在寬帶網關上
- 在BNG的服務卡上
- 在BNG和CPE的線卡上內部支持
- 數據中心
- 綜合上面全部
5 OpenContrail系統和MPLS VPN的比較
如圖33所示，OpenContrail系統的架構在很多方向上和MPLS VPN相似（另外一個類似的地方是，比較控制VM和路由引擎，比較虛擬路由器和線卡）
兩個架構類似的地方包括
在OpenContrail系統的底層交換機類似於在MPLS VPN中的P路由器，OpenContrail系統使用MPLS over GRE 或者 VXLAN作為封裝協議，不需要底層交換機支持MPLS，唯一的對底層交換機的要求僅僅是知道如何把一個單播數據包從一個物理服務器到另外一個物理服務器。
- OpenContrail系統中的虛擬路由器相當於MPLS VPN中的PE路由器，和無力的PE路由器一樣，虛擬路由器中也包含多個路由實例
- OpenContrail系統中的VM相當於MPLS VPN中的CE路由器，在OpenContrail系統中，不需要PE和CE之間的協議，因為CE路由可以通過其他機制被查找。（譯者注，因為相當於是主機，所以靜態路由就好了）
- 在OpenContrail系統中MPLS over GRE隧道和VXLAN隧道相當於MPLS VPN中的MPLS over MPLS
- OpenContrail系統中的XMPP協議綜合了MPLS VPN中的兩個協議的功能。
- XMPP分發路由協議，類似於MPLS VPN中的IBGP
- XMPP推送特定類型的配置（如路由實例），類似於MPLS VPN中的DMI（Device Manageability Instrumentation）
- OpenContrail系統提供三個功能
- 集中控制，類似於MPLS VPN中BGP的RR
- 管理，向虛擬路由器的配置下發，類似於MPLS VPN中NMSAnalytics.分析
- OpenContrail支持包括layer 3的overlay，等同於MPLS L3 VPN，也支持Layer 2的overlay，等同於MPLS EVPN。
6 Acronyms
| Acronym |
Meaning |
| AD |
Administrative Domain |
| API |
Application Programming Interface |
| ASIC |
Application Specific Integrated Circuit |
| ARP |
Address Resolution Protocol |
| BGP |
Border Gateway Protocol |
| BNG |
Broadband Network Gateway |
| BSN |
Broadband Subscriber Network |
| BSS |
Business Support System |
| BUM |
Broadcast, Unknown unicast, Multicast |
| CE |
Customer Edge router |
| CLI |
Command Line Interface |
| COTS |
Common Off The Shelf |
| CPE |
Customer Premises Equipment |
| CSP |
Cloud Service Provider |
| CO |
Central Office |
| CPU |
Central Processing Unit |
| CUG |
Closed User Group |
| DAG |
Directed Acyclic Graph |
| DC |
Data Center |
| DCI |
Data Center Interconnect |
| DHCP |
Dynamic Host Configuration Protocol |
| DML |
Data Modeling Language |
| DNS |
Domain Name System |
| DPI |
Deep Packet Inspection |
| DWDM |
Dense Wavelength Division Multiplexing |
| EVPN |
Ethernet Virtual Private Network |
| FIB |
Forwarding Information Base |
| GLB |
Global Load Balancer |
| GRE |
Generic Route Encapsulation |
| GUI |
Graphical User Interface |
| HTTP |
Hyper Text Transfer Protocol |
| HTTPS |
Hyper Text Transfer Protocol Secure |
| IaaS |
Infrastructure as a Service |
| IBGP |
Internal Border Gateway Protocol |
| IDS |
Intrusion Detection System |
| IETF |
Internet Engineering Task Force |
| IF-MAP |
Interface for Metadata Access Points |
| IP |
Internet Protocol |
| IPS |
Intrusion Prevention System |
| IPVPN |
Internet Protocol Virtual Private Network |
| IRB |
Integrated Routing and Bridging |
| JIT |
Just In Time |
| KVM |
Kernel-Based Virtual Machines |
| LAN |
Local Area Network |
| L2VPN |
Layer 2 Virtual Private Network |
| LSP |
Label Switched Path |
| MAC |
Media Access Control |
| MAP |
Metadata Access Point |
| MDNS |
Multicast Domain Naming System |
| MPLS |
Multi-Protocol Label Switching |
| NAT |
Network Address Translation |
| Netconf |
Network Configuration |
| NFV |
Network Function Virtualization |
| NMS |
Network Management System |
| NVO3 |
Network Virtualization Overlays |
| OS |
Operating System |
| OSS |
Operations Support System |
| P |
Provider core router |
| PE |
Provider Edge router |
| PIM |
Protocol Independent Multicast |
| POP |
Point of Presence |
| QEMU |
Quick Emulator |
| REST |
Representational State Transfer |
| RI |
Routing Instance |
| RIB |
Routing Information Base |
| RSPAN |
Remote Switched Port Analyzer |
| (S,G) |
Source Group |
| SDH |
Synchronous Digital Hierarchy |
| SDN |
Software Defined Networking |
| SONET |
Synchronous Optical Network |
| SP |
Service Provider |
| SPAN |
Switched Port Analyzer |
| SQL |
Structured Query Language |
| SSL |
Secure Sockets Layer |
| TCG |
Trusted Computer Group |
| TE |
Traffic Engineering |
| TE-LSP |
Traffic Engineered Label Switched Path |
| TLS |
Transport Layer Security |
| TNC |
Trusted Network Connect |
| UDP |
Unicast Datagram Protocol |
| VAS |
Value Added Service |
| vCPE |
Virtual Customer Premises Equipment |
| VLAN |
Virtual Local Area Network |
| VM |
Virtual Machine |
| VN |
Virtual Network |
| VNI |
Virtual Network Identifier |
| VXLAN |
Virtual eXtensible Local Area Network |
| WAN |
Wide Area Network |
| XML |
Extensible Markup Language |
| XMPP |
eXtensible Messaging and Presence Protocol |