數(shù)據(jù)驅(qū)動的網(wǎng)絡(luò)
從數(shù)據(jù)驅(qū)動的角度來看網(wǎng)絡(luò)，會發(fā)現(xiàn)一張現(xiàn)實中的網(wǎng)絡(luò)存在著各種數(shù)據(jù)。設(shè)計和管理一張網(wǎng)絡(luò)，主要是設(shè)計數(shù)據(jù)，存儲數(shù)據(jù)，管理數(shù)據(jù)和分析數(shù)據(jù)。網(wǎng)絡(luò)數(shù)據(jù)的規(guī)模、復(fù)雜度和變化速度，這3方面決定了數(shù)據(jù)處理的難度。對照下圖的SDN網(wǎng)絡(luò)結(jié)構(gòu)，網(wǎng)絡(luò)數(shù)據(jù)按照用途可以分成下面幾類。
一個SDN VPC控制器，通常要管理成千上萬個虛擬交換機節(jié)點，其作用是存儲、計算和傳輸網(wǎng)絡(luò)數(shù)據(jù)。其中轉(zhuǎn)發(fā)數(shù)據(jù)是最重要的一類數(shù)據(jù)，直接決定了報文在網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)行為。本文主要分析SDN控制器將轉(zhuǎn)發(fā)數(shù)據(jù)傳輸?shù)教摂M機交換機的一些方法，希望從這個角度能介紹一下SDN網(wǎng)絡(luò)遇到的主要問題，以及如何設(shè)計一個SDN網(wǎng)絡(luò)控制器。
為了簡要描述，下文中的交換機，路由器和 偶爾會交替使用，他們都代表了具有路由功能的虛擬網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備。
VPC 網(wǎng)絡(luò)轉(zhuǎn)發(fā)數(shù)據(jù)
云網(wǎng)絡(luò)內(nèi)部根據(jù)數(shù)據(jù)面功能也分成多塊，本文主要介紹VPC網(wǎng)絡(luò)。下圖是一個VPC內(nèi)的轉(zhuǎn)發(fā)數(shù)據(jù)。分別從控制器和虛擬交換機的視角來看，控制器內(nèi)的轉(zhuǎn)發(fā)數(shù)據(jù)，和虛擬交換機內(nèi)的轉(zhuǎn)發(fā)數(shù)據(jù)并不相同。控制器上是整個VPC1的轉(zhuǎn)發(fā)數(shù)據(jù)，而每個虛擬交換機內(nèi)是本節(jié)點網(wǎng)卡相關(guān)的VPC轉(zhuǎn)發(fā)數(shù)據(jù)。
從控制器的視角看VPC1的轉(zhuǎn)發(fā)數(shù)據(jù)：VPC 1內(nèi)有2個子網(wǎng)，子網(wǎng)1內(nèi)有網(wǎng)卡1/2，子網(wǎng)2內(nèi)有網(wǎng)卡3/4。
從虛擬交換機1的視角看VPC1內(nèi)的轉(zhuǎn)發(fā)數(shù)據(jù)：
根據(jù)上面的例子，可以羅列一下VPC網(wǎng)轉(zhuǎn)發(fā)數(shù)據(jù)的幾個特點：
一個SDN VPC控制器，管理著成千上萬個虛擬交換機，以上面的例子為例，控制器需要將VPC1內(nèi)的轉(zhuǎn)發(fā)數(shù)據(jù)，轉(zhuǎn)換成虛擬交換機期望的數(shù)據(jù)，并正確的傳輸?shù)奖姸嗵摂M交換機上。下面介紹控制器將轉(zhuǎn)發(fā)數(shù)據(jù)傳輸?shù)教摂M交換機的3種方式，以及這3種方式下的數(shù)據(jù)一致性。
傳輸轉(zhuǎn)發(fā)數(shù)據(jù)
分布式系統(tǒng)，是通過分布式算法讓一群機器對外像一臺機器在工作。云網(wǎng)絡(luò)的特點，是通過分布式系統(tǒng)和網(wǎng)絡(luò)技術(shù)讓一群虛擬交換機邏輯上像一臺虛擬交換機在工作。
數(shù)據(jù)模型和格式
數(shù)據(jù)模型和格式，就是控制器將轉(zhuǎn)發(fā)數(shù)據(jù)以什么格式發(fā)送給虛擬交換機，例如json/xml/。
虛擬交換機的實現(xiàn)大多參考開源的，以協(xié)議和控制面交互轉(zhuǎn)發(fā)數(shù)據(jù)，以O(shè)VSDB和控制面交互管理信息。轉(zhuǎn)發(fā)數(shù)據(jù)以 Rule格式表示， Rule存儲在 Table中?？刂泼嫱ㄟ^協(xié)議讀寫 Table，接收數(shù)據(jù)面上送的協(xié)議報文。協(xié)議支持數(shù)據(jù)面將一些流表更新事件和端口事件上報給控制面，類似于中斷通知。
如果控制面直接以協(xié)議傳輸轉(zhuǎn)發(fā)數(shù)據(jù)， Rule的表達是偏向轉(zhuǎn)發(fā)面的，沒法直接表示子網(wǎng)和路由表的關(guān)聯(lián)關(guān)系，以及網(wǎng)卡和安全組之間的關(guān)聯(lián)關(guān)系。另外為了表示控制面的一條路由，需要在rule中指定匹配條件和vxlan 的信息。當有多條路由數(shù)據(jù)指向同一條vxlan 時，會導(dǎo)致重復(fù)的vxlan 數(shù)據(jù)。例如下面，如果再新增一條路由，=192.168.1.30，=10.33.0.12，=1，那么這條數(shù)據(jù)會在轉(zhuǎn)發(fā)面重復(fù)存在。
ovs-ofctl add-flow br-tun "nw_dst=192.168.1.11 actions=set_field:10.33.0.12->tun_dst, set_field:1->tun_id, output:1
ovs-ofctl add-flow br-tun "nw_dst=192.168.1.12 actions=set_field:10.33.0.13->tun_dst, set_field:1->tun_id, output:1
ovs-ofctl add-flow br-tun "nw_dst=192.168.1.20 actions=set_field:10.44.0.24->tun_dst, set_field:1->tun_id, output:1解決的辦法是，進一步對Open 的Table做拆分，獨立復(fù)用的數(shù)據(jù)。另外一些解決方案是控制器不直接對接虛擬交換機，不再直接發(fā)送原始的數(shù)據(jù)面轉(zhuǎn)發(fā)規(guī)則，而是引入一層proxy?？刂破骱蚿roxy之間傳輸自定義格式的轉(zhuǎn)發(fā)數(shù)據(jù)，使用json或者，由proxy再翻譯成寫入虛擬交換機。
自定義的數(shù)據(jù)格式，對比表達上偏向控制器，可以減少控制器和虛擬交換機之間傳輸時的大量重復(fù)數(shù)據(jù)，也可以方便的自定義擴展。如下所示，如果使用自定義格式，只需要指定列出虛擬機和宿主機的IP地址列表，那么虛擬交換機可以將此翻譯成上面的 Rule，不存在重復(fù)的vxlan 。
hosts = vpcHosts {
vpcID = vpcxxxx,
vni = 1,
subnetID = subnetxxxx,
{
vmIP = "192.168.1.10/24",
hostIP = "10.22.0.16"
},
{
vmIP = "192.168.1.11/24",
hostIP = "10.33.0.12"
},
{
vmIP = "192.168.1.12/24"
hostIP = "10.33.0.13"
},
{
vmIP = "192.168.1.20/24"
hostIP = "10.44.0.24"
},
}
數(shù)據(jù)流
數(shù)據(jù)流是指控制器通過什么方式將轉(zhuǎn)發(fā)數(shù)據(jù)傳輸給虛擬交換機。目前有以下3種方式：
我們來具體分析使用上述3種方式實現(xiàn)控制面和數(shù)據(jù)面的數(shù)據(jù)同步。
via
使用數(shù)據(jù)庫來傳輸數(shù)據(jù)，需要清晰的定義數(shù)據(jù)在數(shù)據(jù)庫中的存儲的格式。一般是控制器來寫數(shù)據(jù)庫，虛擬交換機Agent來讀數(shù)據(jù)庫。數(shù)據(jù)庫的數(shù)據(jù)檢測到基于一致性的邏輯錯誤，表示的是轉(zhuǎn)發(fā)數(shù)據(jù)最新的狀態(tài)，沒有數(shù)據(jù)的歷史狀態(tài)。如果控制器出現(xiàn)錯誤，導(dǎo)致數(shù)據(jù)被篡改，一般要通過同時留存日志的方式，追溯出篡改的時間點和原始數(shù)據(jù)。同時要注意數(shù)據(jù)庫的事務(wù)，防止出現(xiàn)臟數(shù)據(jù)。
控制器需要和虛擬交換機Agent定義清楚數(shù)據(jù)庫轉(zhuǎn)發(fā)數(shù)據(jù)的版本，以及雙方軟件的版本，不然可能導(dǎo)致轉(zhuǎn)發(fā)面讀取數(shù)據(jù)庫出錯。一般這種情況是控制器在數(shù)據(jù)庫中添加了新字段，但是虛擬交換機Agent的版本還是舊的，此時無法提取新的字段，導(dǎo)致出現(xiàn)錯誤。
數(shù)據(jù)庫中的數(shù)據(jù)一般是持久化的，只要數(shù)據(jù)的寫入者不主動刪除數(shù)據(jù)，轉(zhuǎn)發(fā)數(shù)據(jù)就不會丟失，這樣即使數(shù)據(jù)面節(jié)點重啟了，還可以從數(shù)據(jù)庫中恢復(fù)出轉(zhuǎn)發(fā)面的狀態(tài)。
使用數(shù)據(jù)庫來傳輸數(shù)據(jù)，控制器和數(shù)據(jù)面是異步的，控制器寫入新數(shù)據(jù)到數(shù)據(jù)庫之后，數(shù)據(jù)庫無法通知數(shù)據(jù)面及時來讀取數(shù)據(jù)，導(dǎo)致新的轉(zhuǎn)發(fā)規(guī)則不能及時生效。但是現(xiàn)在出現(xiàn)了一些數(shù)據(jù)庫具備類似消息隊列的消息通知功能，數(shù)據(jù)面可以訂閱數(shù)據(jù)庫的某些消息來實現(xiàn)異步的通知，例如redis/etcd。但是使用數(shù)據(jù)庫模式，由于一般數(shù)據(jù)面Agent數(shù)目特別多，所以數(shù)據(jù)庫的讀性能以及并發(fā)連接數(shù)會是這個方案的一個瓶頸。
另外一種方式，是虛擬機交換機自帶數(shù)據(jù)庫，例如Open 自帶Open Flow Table，作用類似數(shù)據(jù)庫，報文轉(zhuǎn)發(fā)查找時會使用Table?？刂泼嬷苯訉慜pen Flow Table，這種方式的好處在于轉(zhuǎn)發(fā)規(guī)則可以長久化，并且能立即生效，但是弊端在上一節(jié)已經(jīng)提到，控制器需要關(guān)心Open Flow 規(guī)則的格式，維護的負擔過重，理解起來也比較困難，數(shù)據(jù)傳輸效率也不高。OVN控制器使用的就是這種方式。
via rpc
基于RPC的方式，控制器和每個數(shù)據(jù)面節(jié)點建立一對一的RPC連接。RPC通信模式下，一般有個服務(wù)端和客戶端，控制器和數(shù)據(jù)面都可以作為服務(wù)端。一般在數(shù)據(jù)面節(jié)點上會部署一個agent，用于和控制器之間建立RPC連接，由agent接收數(shù)據(jù)之后再寫入虛擬交換機中。
使用RPC，控制器和數(shù)據(jù)面agent之間的通信是同步的，控制器可以實時推送數(shù)據(jù)到數(shù)據(jù)面agent并確認數(shù)據(jù)面已經(jīng)接收到數(shù)據(jù)。RPC的實現(xiàn)較為方便，只要定義好服務(wù)的接口和通信協(xié)議，控制器和數(shù)據(jù)面之間容易實現(xiàn)解耦，方便雙方獨立升級維護。
RPC一般是有通信方向的，例如客戶端主動訪問服務(wù)器端的服務(wù)，此時如果服務(wù)器想主動推送數(shù)據(jù)給客戶端，就很麻煩。grpc支持模式，但是也需要客戶端主動連接上來之后，以的形式再推送數(shù)據(jù)給客戶端，導(dǎo)致此時控制器無法基于具體的接口提供服務(wù)。
使用RPC的方式，Agent沒法很好的持久化保存轉(zhuǎn)發(fā)數(shù)據(jù)，因為控制器和數(shù)據(jù)面agent是通過網(wǎng)絡(luò)通信的，所以在一些數(shù)據(jù)消息丟失的情況下，Agent的狀態(tài)比較難排查。而且數(shù)據(jù)面agent重啟之后，為了快速恢復(fù)轉(zhuǎn)發(fā)狀態(tài)，必須做一次全量的數(shù)據(jù)同步。如果大量的agent在同一時刻重啟會對控制器會造成服務(wù)攻擊。解決辦法是可以在本地存儲對應(yīng)的消息。但是這個消息需要有分布式算法來保證一致性。
agent需要負責轉(zhuǎn)發(fā)面Table中的數(shù)據(jù)正確性，必須確保所有數(shù)據(jù)正確的寫入轉(zhuǎn)發(fā)面的Table中。如果出現(xiàn)異常將導(dǎo)致網(wǎng)絡(luò)流量的中斷這對agent的設(shè)計要求比較高，盡量簡單和穩(wěn)定，最好做到無狀態(tài)的。
via
控制器和數(shù)據(jù)面節(jié)點之間，可以使用消息隊列作為轉(zhuǎn)發(fā)數(shù)據(jù)的傳輸通道。消息隊列有生產(chǎn)者和消費者的角色。控制器作為生產(chǎn)者，往一個topic寫數(shù)據(jù)，數(shù)據(jù)面節(jié)點上的agent訂閱該topic，消息隊列會負責往所有訂閱該topic的數(shù)據(jù)面節(jié)點推送數(shù)據(jù)。控制器需要將轉(zhuǎn)發(fā)數(shù)據(jù)的類型劃分成不同的topic，并按照topic去發(fā)送數(shù)據(jù)。
消息隊列具備一對一和一對多通信的能力，容易實現(xiàn)控制器和數(shù)據(jù)面之間的解耦。控制器只需要將轉(zhuǎn)發(fā)數(shù)據(jù)寫入消息隊列后就不用管了，消息隊列自己會完成數(shù)據(jù)的傳輸工作。控制器可以方便的實現(xiàn)將同一份轉(zhuǎn)發(fā)數(shù)據(jù)，多播給多個數(shù)據(jù)面節(jié)點。
有些消息隊列支持消息的按序發(fā)送，但是轉(zhuǎn)發(fā)數(shù)據(jù)的順序只能在一個topic上保證，多個topic之間無法保證。消息隊列還支持消息的重傳。有些消息隊列支持消息的持久化保存，但是不能和數(shù)據(jù)庫比較，只是實現(xiàn)了有限的持久化功能。消息隊列支持消息的削峰功能，當轉(zhuǎn)發(fā)數(shù)據(jù)太多時，可以臨時緩存下來，避免系統(tǒng)過載。
消息隊列支持異步通信，消息隊列主動將消息或者事件及時的推送給數(shù)據(jù)轉(zhuǎn)發(fā)面。但是有一個問題，控制器將轉(zhuǎn)發(fā)數(shù)據(jù)寫入消息隊列之后，無法知道什么時候數(shù)據(jù)面收到了數(shù)據(jù)。解決辦法之一是數(shù)據(jù)面agent可以注冊一個topic，作為生產(chǎn)者將結(jié)果作為消息寫入消息隊列，控制器作為消費者來讀取結(jié)果。
消息總線是一種增量通信的機制，也就是說新轉(zhuǎn)發(fā)數(shù)據(jù)，總是以新消息的形式被追加到系統(tǒng)的消息流中，消息流也可以解讀為事件流。
目前VPC控制器一般以VPC和ENI作為topic，這樣每個虛擬交換機只需要訂閱自己關(guān)心的VPC topic，每次這個VPC的數(shù)據(jù)有更新，它都會收到新的消息，而不用關(guān)心別的VPC數(shù)據(jù)是否有更新，這樣可以減少重復(fù)數(shù)據(jù)的傳輸，減輕虛擬交換機的負擔。
via log
基于log的方式，結(jié)合了基于數(shù)據(jù)庫的數(shù)據(jù)可持久化功能，和rpc機制的實現(xiàn)。其實現(xiàn)方式可以抽象為，控制器將數(shù)據(jù)以遞增的方式追加log文件中，并附帶編號和數(shù)據(jù)的動作指令，例如是添加還是刪除一條數(shù)據(jù)。控制器負責將log文件同步到所有的數(shù)據(jù)面節(jié)點，并記錄每個數(shù)據(jù)面節(jié)點當前同步的位置，根據(jù)這個位置決定下一次同步的數(shù)據(jù)。如果數(shù)據(jù)面節(jié)點崩潰了，數(shù)據(jù)面節(jié)點可以使用本地快照恢復(fù)狀態(tài)，再根據(jù)log文件更新到最新狀態(tài)，并且再通過RPC和控制器同步自己最新數(shù)據(jù)的位置?？刂破髟偻阶钚碌臄?shù)據(jù)到數(shù)據(jù)面節(jié)點。所以控制器還需要定期和數(shù)據(jù)面節(jié)點sync本地快照。
轉(zhuǎn)發(fā)數(shù)據(jù)一致性
前面介紹了轉(zhuǎn)發(fā)數(shù)據(jù)的傳輸格式和傳輸方式，不同傳輸方式下實現(xiàn)數(shù)據(jù)一致性的方式和難度不一樣。
基于數(shù)據(jù)庫的實現(xiàn)方式，因為控制器將轉(zhuǎn)發(fā)數(shù)據(jù)直接寫入了數(shù)據(jù)庫中，所以數(shù)據(jù)轉(zhuǎn)發(fā)面節(jié)點可以直接讀取同樣最新的數(shù)據(jù)，這個數(shù)據(jù)一致性是由數(shù)據(jù)庫來保證的。關(guān)系型數(shù)據(jù)庫可以實現(xiàn)強一致性。這個場景下需要解決的問題主要是，控制器需要及時通知數(shù)據(jù)面節(jié)點來讀取數(shù)據(jù)，另外就是數(shù)據(jù)庫要承擔所有節(jié)點的讀寫請求，需要評估其性能。OVN控制器，使用基于數(shù)據(jù)庫的方式。
基于RPC的方式，控制器和數(shù)據(jù)面節(jié)點之間的狀態(tài)同步難以保證。需要依賴一些機制來實現(xiàn)數(shù)據(jù)的一致性。這個時候可以使用分布式共識算法，來保障控制器和數(shù)據(jù)面節(jié)點的狀態(tài)一致性，如下圖所示?？刂破髯鳛?，agent作為?？刂破骺刂票４婷總€數(shù)據(jù)面節(jié)點的同步狀態(tài)，控制數(shù)據(jù)面節(jié)點的同步，這個有點類似于via log的方式，每次同步的數(shù)據(jù)都有對應(yīng)的編號。另外一種較為簡單的方式是使用版本號，但是這一般用于控制器和數(shù)據(jù)面節(jié)點之間同步全量數(shù)據(jù)。
基于消息隊列的方式，控制器和數(shù)據(jù)面節(jié)點之間的狀態(tài)同步依賴于消息隊列的消息持久化和重傳機制。這種事件驅(qū)動機制下，數(shù)據(jù)節(jié)點接收到的是增量數(shù)據(jù)，控制器無法直接知道數(shù)據(jù)面節(jié)點是否接收到數(shù)據(jù)。所以還依賴額外的機制來確保數(shù)據(jù)面節(jié)點和控制器之間數(shù)據(jù)的最終一致性，例如建立旁路的對賬檢測機制，定期檢查每個數(shù)據(jù)面節(jié)點的轉(zhuǎn)發(fā)數(shù)據(jù)是否和控制器的數(shù)據(jù)一致。為了做到數(shù)據(jù)面節(jié)點重啟快速恢復(fù)，數(shù)據(jù)面節(jié)點必須保存全量的轉(zhuǎn)發(fā)數(shù)據(jù)，否則重啟之后就只能接收新數(shù)據(jù)了。
解決方案探討
一個解決方案，是基于數(shù)據(jù)庫的改進模式，直接將一個虛擬交換機當成一個轉(zhuǎn)發(fā)設(shè)備，在控制器中對應(yīng)每個轉(zhuǎn)發(fā)設(shè)備都有一個映射?？刂破鞲鶕?jù)轉(zhuǎn)發(fā)數(shù)據(jù)模型和網(wǎng)絡(luò)事件，分別計算出每個轉(zhuǎn)發(fā)設(shè)備當前最新狀態(tài)檢測到基于一致性的邏輯錯誤，以及與歷史狀態(tài)比較的變更，然后再將變更增量寫入轉(zhuǎn)發(fā)設(shè)備的轉(zhuǎn)發(fā)表中。如果類比傳統(tǒng)路由器，控制器中的轉(zhuǎn)發(fā)設(shè)備數(shù)據(jù)可以類比CPU中的RIB和ARP Cache，而虛擬軟件交換機中的轉(zhuǎn)發(fā)設(shè)備數(shù)據(jù)，可以類比硬件交換芯片的轉(zhuǎn)發(fā)表項，在CPU中存在單獨的進程和交換芯片SDK來處理RIB和硬件交換芯片轉(zhuǎn)發(fā)表之間的同步。交換芯片SDK提供讀寫交換芯片的接口和通道，將CPU的讀寫格式翻譯成硬件交換芯片支持的格式，在各家交換芯片SDK之上通常還會有一個SDK適配層用來屏蔽各家SDK的差異。在SDN網(wǎng)絡(luò)中，協(xié)議起到的作用和交換芯片SDK類似，各種軟件交換機需要自己對協(xié)議做兼容。P4 是通過RPC的方式直接讀寫虛擬軟件交換機的轉(zhuǎn)發(fā)表，作用類似，區(qū)別在于P4的重點是想隨時可以改變交換機的解析和轉(zhuǎn)發(fā)行為，真正做到自定義交換機。傳輸通道和協(xié)議有了，控制器中的轉(zhuǎn)發(fā)設(shè)備數(shù)據(jù)有了，那么現(xiàn)在需要的就是在控制器這一側(cè)為每個轉(zhuǎn)發(fā)設(shè)備起一個單獨的線程，通過傳輸通道和協(xié)議將轉(zhuǎn)發(fā)數(shù)據(jù)寫入虛擬交換機的轉(zhuǎn)發(fā)表中。為了避免控制器維護過多連接，可以引入proxy。
在控制器中為每個虛擬交換機創(chuàng)建單獨的實例，該實例使用傳輸通道和傳輸協(xié)議和虛擬軟件交換機通信。虛擬交換機會發(fā)送一些網(wǎng)絡(luò)事件給控制器實例，例如虛擬交換機連接、添加一個虛擬機端口等?？刂破骶C合這些虛擬交換機上報的事件，以及來自上層的網(wǎng)絡(luò)配置信息，計算出每個虛擬交換機的當前轉(zhuǎn)發(fā)數(shù)據(jù)，然后和歷史數(shù)據(jù)比較得出差異數(shù)據(jù)。這個差異數(shù)據(jù)格式是控制器能夠識別的，再通過傳輸通道以及等傳輸協(xié)議轉(zhuǎn)換成虛擬機交換機支持的格式，寫入到虛擬交換機的轉(zhuǎn)發(fā)表中。由控制器實例來確認每次傳輸是否成功，如果失敗，需要重試來確保兩邊的一致性。為了支持控制器失聯(lián)時虛擬交換機仍然保持正常轉(zhuǎn)發(fā)，虛擬交換機支持fail-模式。
另一個解決方案，是基于rpc的改進模式。在控制器中對應(yīng)每個轉(zhuǎn)發(fā)設(shè)備都有一個邏輯映射，控制器維護一份該轉(zhuǎn)發(fā)設(shè)備的邏輯數(shù)據(jù)。和上述模式的差別在于，控制器不再寫虛擬交換機的轉(zhuǎn)發(fā)表，而是在控制器和數(shù)據(jù)面Agent之間通過rpc同步邏輯數(shù)據(jù)，然后由Agent將邏輯數(shù)據(jù)翻譯成虛擬交換機支持的格式寫入轉(zhuǎn)發(fā)表中。在控制器和數(shù)據(jù)面Agent之間需要依賴分布式共識算法，來保證邏輯數(shù)據(jù)的同步。為了避免控制器維護過多連接，也可以引入proxy。這種方式和上面的方式對比，主要在于增加了一層Agent的緩存，相對復(fù)雜一些，帶來的好處是控制器不再關(guān)心底層虛擬交換機具體支持的格式。
