丁萬(wàn)夫,須成忠,古 亮

1(中國(guó)科學(xué)院 深圳先進(jìn)技術(shù)研究院,廣東 深圳 518000)2(深信服科技股份有限公司,廣東 深圳 518000)

1 引 言

網(wǎng)絡(luò)報(bào)文在傳輸過(guò)程中,只有依次按序經(jīng)過(guò)定制的業(yè)務(wù)功能,才能確保網(wǎng)絡(luò)可以按照設(shè)計(jì)的要求,為用戶提供更加安全、可用的網(wǎng)絡(luò)服務(wù)[1].業(yè)務(wù)鏈中的業(yè)務(wù)節(jié)點(diǎn)通常包括防火墻、入侵檢測(cè)、負(fù)載均衡等等[2,3].因此,如何保證網(wǎng)絡(luò)流量按照業(yè)務(wù)邏輯所要求的既定順序穿過(guò)這些業(yè)務(wù)節(jié)點(diǎn),以實(shí)現(xiàn)所需要的安全業(yè)務(wù),已成為學(xué)術(shù)界和工業(yè)界的研究熱點(diǎn).

業(yè)務(wù)鏈在企業(yè)場(chǎng)景和運(yùn)營(yíng)商場(chǎng)景下有大量的應(yīng)用訴求,其中應(yīng)用較多的兩大場(chǎng)景是:

1)云計(jì)算數(shù)據(jù)中心場(chǎng)景[4].業(yè)務(wù)鏈功能可以為數(shù)據(jù)中心的租戶提供多種網(wǎng)絡(luò)功能的業(yè)務(wù)鏈編排.云計(jì)算數(shù)據(jù)中心的主要特點(diǎn)是多個(gè)租戶共存,每個(gè)租戶對(duì)業(yè)務(wù)鏈編排的需求差異很大,因此業(yè)務(wù)鏈需具有易擴(kuò)展及靈活部署的特點(diǎn).

2)Gi-LAN場(chǎng)景[5].隨著網(wǎng)絡(luò)數(shù)據(jù)流量的顯著增長(zhǎng),運(yùn)營(yíng)商在Gi-LAN場(chǎng)景下需要應(yīng)對(duì)網(wǎng)絡(luò)流量的激增壓力以及用戶的個(gè)性化需求,網(wǎng)絡(luò)業(yè)務(wù)鏈不僅需要具有彈性伸縮的特點(diǎn),還需要針對(duì)用戶的網(wǎng)絡(luò)流量進(jìn)行更加精細(xì)化的流量管控.

傳統(tǒng)業(yè)務(wù)鏈部署通常采用專(zhuān)用的硬件設(shè)備,基于物理拓?fù)?通過(guò)手工配置路由策略,將安全設(shè)備部署到業(yè)務(wù)流量路徑當(dāng)中,這種部署模式存在高成本支出和高運(yùn)維費(fèi)用等一系列亟待解決的問(wèn)題[6].軟件定義網(wǎng)絡(luò)(SDN,Software Defined Network)[7,8]的概念由斯坦福大學(xué)提出.其核心思想是將轉(zhuǎn)發(fā)設(shè)備的數(shù)據(jù)平面和控制平面進(jìn)行分離,并讓控制邏輯以軟件方式運(yùn)行于邏輯上獨(dú)立的控制環(huán)境.SDN的本質(zhì)是邏輯集中控制面的可編程化[9,10].網(wǎng)絡(luò)功能虛擬化(NFV,Network Function Virtualization)[11]的概念由電信運(yùn)營(yíng)商提出.其核心思想是通過(guò)使用通用性的硬件平臺(tái)以及虛擬化平臺(tái)運(yùn)行網(wǎng)絡(luò)虛擬化單元,從而大幅降低網(wǎng)絡(luò)設(shè)備的成本.NFV的本質(zhì)是實(shí)現(xiàn)新業(yè)務(wù)的快速開(kāi)發(fā)和部署[12].

本文面向SDN和NFV的融合機(jī)制,首先提出了一種基于標(biāo)準(zhǔn)化架構(gòu)MANO[13]的業(yè)務(wù)鏈平臺(tái),然后分別對(duì)控制平面和數(shù)據(jù)轉(zhuǎn)發(fā)平面的關(guān)鍵技術(shù)進(jìn)行研究,解決了業(yè)務(wù)鏈平臺(tái)的可靠性和可擴(kuò)展性等問(wèn)題.

2 相關(guān)工作

2.1 業(yè)務(wù)鏈平臺(tái)架構(gòu)的研究

當(dāng)前網(wǎng)絡(luò)中使用的各種設(shè)備,均是基于私有平臺(tái)部署的,各種專(zhuān)有設(shè)備之間的硬件平臺(tái)無(wú)法復(fù)用,而設(shè)備擴(kuò)容需要采購(gòu)硬件,且縮容后又存在硬件平臺(tái)閑置的問(wèn)題[14].在NFV理念下,所有硬件設(shè)備轉(zhuǎn)變?yōu)閼?yīng)用程序,能夠部署在基于x86標(biāo)準(zhǔn)的物理服務(wù)器上,通過(guò)將軟硬件進(jìn)行解耦,所有應(yīng)用均能夠?qū)崿F(xiàn)快速的擴(kuò)縮容的功能,進(jìn)而顯著提升部署彈性.NFV雖然有諸多好處,但其會(huì)帶來(lái)跨廠商的協(xié)同和互通問(wèn)題,進(jìn)而提高運(yùn)維成本[15].為此,歐洲電信標(biāo)準(zhǔn)協(xié)會(huì)ETSI成立了網(wǎng)絡(luò)功能虛擬化管理和編排(NFV MANO)標(biāo)準(zhǔn)組,致力于降低NFV推廣后帶來(lái)的維護(hù)復(fù)雜性.如圖1所示,MANO系統(tǒng)架構(gòu)由三部分組成,從下至上分別為VIM(Virtual Infrastructure Management)、VNF-M(VNF-Manager)以及NFV-O(NFV-Orchestrator),分別完成NFVI的資源管理、VNF的管理以及網(wǎng)絡(luò)服務(wù)與資源的編排.其中,VIM與網(wǎng)絡(luò)功能虛擬化基礎(chǔ)設(shè)置(NFVI)交互,VMF-M與單元管理系統(tǒng)(EMS)和虛擬網(wǎng)絡(luò)功能(VNF)交互,NFV-O與運(yùn)營(yíng)支撐系統(tǒng)(OSS)和業(yè)務(wù)支撐系統(tǒng)(BSS)交互.基于這樣的編排流程,任何一個(gè)業(yè)務(wù)網(wǎng)絡(luò)均可以通過(guò)MANO自頂向下進(jìn)行分解.

圖1 NFV MANO系統(tǒng)架構(gòu)圖Fig.1 NFV MANO system architecture

2.2 業(yè)務(wù)鏈平臺(tái)控制平面的研究

雖然目前業(yè)界對(duì)業(yè)務(wù)鏈平臺(tái)的架構(gòu)沒(méi)有統(tǒng)一,但是總的來(lái)看業(yè)務(wù)鏈系統(tǒng)架構(gòu)通常包括三個(gè)層次,分別是編排層,控制層以及數(shù)據(jù)層[16,17].最上層為編排層,通常由不同功能的組件構(gòu)成,可通過(guò)Restful API的方式與對(duì)應(yīng)的控制層進(jìn)行交互,用戶可以通過(guò)可拖拽的方式對(duì)業(yè)務(wù)進(jìn)行不同的組合形成統(tǒng)一的業(yè)務(wù).中間為控制層,負(fù)責(zé)對(duì)網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備進(jìn)行統(tǒng)一的管理和控制,同時(shí)維護(hù)一致的網(wǎng)絡(luò)拓?fù)?最底層的轉(zhuǎn)發(fā)層主要包括三部分,分別是流分類(lèi)器,網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備以及業(yè)務(wù)功能組件.在典型的SDN系統(tǒng)架構(gòu)的基礎(chǔ)上,學(xué)術(shù)界設(shè)計(jì)了多種業(yè)務(wù)鏈控制面架構(gòu).總體來(lái)說(shuō),可以分為兩類(lèi).

1)單控制器架構(gòu).如圖2所示,OpenNF[18]在SIGCOMM′2014提出了一種全局統(tǒng)一的控制面架構(gòu),在OpenNF控制器內(nèi)集成了流規(guī)則管理器和網(wǎng)絡(luò)狀態(tài)管理器,分別用于管理網(wǎng)絡(luò)轉(zhuǎn)發(fā)狀態(tài)和網(wǎng)絡(luò)功能狀態(tài).

圖2 OpenNF系統(tǒng)架構(gòu)圖Fig.2 OpenNF system architecture

2)雙控制器架構(gòu).如圖3所示,Stratos[19]提出了一種雙控制器架構(gòu),其中轉(zhuǎn)發(fā)控制器用于管理和控制轉(zhuǎn)發(fā)設(shè)備,而業(yè)務(wù)功能控制器用于監(jiān)視和控制中間件設(shè)備,二者由租戶業(yè)務(wù)鏈模塊進(jìn)行統(tǒng)一調(diào)度.

圖3 Stratos系統(tǒng)架構(gòu)圖Fig.3 Stratos system architecture

2.3 業(yè)務(wù)鏈平臺(tái)轉(zhuǎn)發(fā)平面的研究

業(yè)務(wù)鏈數(shù)據(jù)平面轉(zhuǎn)發(fā)技術(shù)的演進(jìn)過(guò)程如圖4所示.傳統(tǒng)業(yè)務(wù)鏈數(shù)據(jù)面轉(zhuǎn)發(fā)技術(shù)通常采用策略路由(PBR,Policy-Based Routing)方案[20],PBR方案提供了一種比基于目的地址進(jìn)行路由轉(zhuǎn)發(fā)更加靈活的數(shù)據(jù)包路由轉(zhuǎn)發(fā)機(jī)制,可以根據(jù)IP報(bào)文源地址、目的地址、端口等內(nèi)容進(jìn)行路由選擇.PBR方案主要存在4個(gè)方面問(wèn)題:

1)靈活性問(wèn)題.匹配域類(lèi)型相對(duì)固定且有限,導(dǎo)致靈活性較差.

2)可擴(kuò)展性問(wèn)題.不具有微流匯聚能力,導(dǎo)致表項(xiàng)增多.

3)可靠性問(wèn)題.PBR表項(xiàng)需要靜態(tài)配置,導(dǎo)致拓?fù)湟蕾?lài)且不支持部署自動(dòng)化.

4)性能問(wèn)題.PBR屬于分布式DPI方案,每一跳均需與策略路由表項(xiàng)進(jìn)行匹配,影響轉(zhuǎn)發(fā)性能.

圖4 業(yè)務(wù)鏈數(shù)據(jù)平面轉(zhuǎn)發(fā)技術(shù)的演進(jìn)過(guò)程Fig.4 Evolution process of service chain forwarding technology

為解決傳統(tǒng)業(yè)務(wù)鏈存在的問(wèn)題,產(chǎn)業(yè)界和學(xué)術(shù)界開(kāi)始嘗試通過(guò)SDN架構(gòu)帶來(lái)的可編程性來(lái)解決PBR方案存在的問(wèn)題.流轉(zhuǎn)發(fā)規(guī)則方案基于SDN架構(gòu)[21,22],通過(guò)使用OpenFlow協(xié)議[23],能夠自動(dòng)生成轉(zhuǎn)發(fā)規(guī)則,解決了PBR存在的拓?fù)湟蕾?lài)和靈活性問(wèn)題,但無(wú)法解決可擴(kuò)展性和性能問(wèn)題.之后業(yè)界開(kāi)始探索引入業(yè)務(wù)鏈ID方案[24],通過(guò)部署流分類(lèi)器為流量打上相應(yīng)的業(yè)務(wù)鏈ID標(biāo)簽,進(jìn)而實(shí)現(xiàn)了轉(zhuǎn)發(fā)過(guò)程中不再依賴(lài)具體匹配域,而是依據(jù)ID字段進(jìn)行轉(zhuǎn)發(fā),能夠更好地解決PBR方案和流轉(zhuǎn)發(fā)規(guī)則方案存在的問(wèn)題.

3 面向SDN和NFV融合機(jī)制的業(yè)務(wù)鏈平臺(tái)

本文設(shè)計(jì)并實(shí)現(xiàn)了面向SDN和NFV融合機(jī)制的標(biāo)準(zhǔn)化業(yè)務(wù)鏈平臺(tái),接下來(lái)將介紹平臺(tái)的系統(tǒng)架構(gòu)以及架構(gòu)所實(shí)現(xiàn)的核心關(guān)鍵技術(shù).

3.1 平臺(tái)系統(tǒng)架構(gòu)

業(yè)務(wù)鏈平臺(tái)的系統(tǒng)架構(gòu)如圖5所示,核心功能組件主要包括業(yè)務(wù)鏈編排器、策略控制器、SDN控制器、NFV控制器以及流分類(lèi)器等.編排器可以將用戶自定義服務(wù)所需的資源和配置發(fā)給相應(yīng)的控制器,編排器由業(yè)務(wù)鏈定義、業(yè)務(wù)鏈配置以及拓?fù)涔芾淼饶K組成.策略控制器負(fù)責(zé)根據(jù)用戶的需求選擇業(yè)務(wù)鏈策略,同時(shí)將網(wǎng)絡(luò)流量的轉(zhuǎn)發(fā)策略傳給流分類(lèi)器.SDN控制器主要對(duì)網(wǎng)絡(luò)轉(zhuǎn)發(fā)單元進(jìn)行管理和控制,以及路徑計(jì)算、下發(fā)流表項(xiàng)等功能.NFV控制器負(fù)責(zé)對(duì)VNF進(jìn)行功能管理以及資源配置.流分類(lèi)器負(fù)責(zé)基于策略控制器的策略,對(duì)進(jìn)入網(wǎng)絡(luò)業(yè)務(wù)流量進(jìn)行分類(lèi)及標(biāo)識(shí).數(shù)據(jù)轉(zhuǎn)發(fā)面主要負(fù)責(zé)對(duì)網(wǎng)絡(luò)業(yè)務(wù)流量進(jìn)行轉(zhuǎn)發(fā),是由SDN交換機(jī)構(gòu)建的網(wǎng)絡(luò).VNF是各種功能的中間件,負(fù)責(zé)對(duì)業(yè)務(wù)流進(jìn)行相應(yīng)的處理.

圖5 標(biāo)準(zhǔn)化業(yè)務(wù)鏈平臺(tái)系統(tǒng)架構(gòu)圖Fig.5 General framework of standardized service chain platform

3.2 平臺(tái)關(guān)鍵技術(shù)

3.2.1 基于多控制器的控制平面

從圖6可以看出,整個(gè)業(yè)務(wù)鏈架構(gòu)自頂向下包括3層,分別是管理面、控制面和數(shù)據(jù)面.本節(jié)重點(diǎn)介紹控制平面.單控制器和雙控制器均存在可靠性問(wèn)題,因此本文采用了多控制器的控制平面.控制平面由3個(gè)控制器組成,分別是策略控制器、SDN控制器以及NFV控制器.其中,策略控制器負(fù)責(zé)根據(jù)業(yè)務(wù)鏈ID的策略生成相應(yīng)流表至流分類(lèi)器,主要模塊包括業(yè)務(wù)鏈策略控制以及業(yè)務(wù)鏈ID分配,SDN控制器負(fù)責(zé)根據(jù)網(wǎng)絡(luò)拓?fù)渖上鄳?yīng)流表至轉(zhuǎn)發(fā)單元,主要模塊包括拓?fù)涔芾硪约傲鞅砉芾?NFV控制器負(fù)責(zé)根據(jù)對(duì)VNF進(jìn)行全生命周期管理,主要模塊包括VNF管理器以及NVF拓?fù)涔芾?

圖6 標(biāo)準(zhǔn)化業(yè)務(wù)鏈平臺(tái)分層架構(gòu)圖Fig.6 Hierarchical framework of standardized service chain platform

3.2.2 基于業(yè)務(wù)鏈ID的轉(zhuǎn)發(fā)平面

傳統(tǒng)業(yè)務(wù)鏈轉(zhuǎn)發(fā)方式采用的是基于策略路由PRR的方案,由于PBR存在靈活性和可靠性等問(wèn)題,業(yè)界主流方案采用基于業(yè)務(wù)鏈ID的方案[25].如圖7所示,目前基于業(yè)務(wù)鏈ID的轉(zhuǎn)發(fā)技術(shù)可以分為3類(lèi):

1)基于已有標(biāo)簽字段的方案,如VLAN/VXLAN/MPLS字段.

2)基于數(shù)據(jù)報(bào)文已有字段的方案,如三層的TOS字段以及四層的TCP Option字段.

3)基于新增報(bào)文頭的方案,即IETF SFC工作組建議使用專(zhuān)用的網(wǎng)絡(luò)業(yè)務(wù)包頭(NSH,Network Service Header)[26].NSH格式中包含了24位的業(yè)務(wù)路徑(SPI),控制器將SPI作為匹配參數(shù)下發(fā)給網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備完成轉(zhuǎn)發(fā).

圖7 業(yè)務(wù)鏈ID方案分類(lèi)Fig.7 Classification of service chain ID solutions

本文提出一種基于源MAC的業(yè)務(wù)鏈ID方案,即通過(guò)報(bào)文的源MAC字段承載業(yè)務(wù)鏈ID.如表1所示,我們對(duì)各類(lèi)型的業(yè)務(wù)鏈ID方案進(jìn)行了比較.其中,標(biāo)簽字段與原業(yè)務(wù)有沖突,L3和L4等報(bào)文字段不滿足長(zhǎng)度需求,存在可擴(kuò)展性的問(wèn)題,新增字段需要修改交換機(jī)和中間件,所以只有源MAC方案滿足無(wú)需修改交換機(jī)、滿足長(zhǎng)度需求、與原業(yè)務(wù)無(wú)沖突以及無(wú)需修改中間件等四方面要求.此外,我們通過(guò)記錄源MAC與業(yè)務(wù)鏈ID的對(duì)應(yīng)關(guān)系,在報(bào)文出業(yè)務(wù)鏈時(shí)將業(yè)務(wù)鏈ID替換為對(duì)應(yīng)的源MAC,從而使得報(bào)文在進(jìn)出業(yè)務(wù)鏈前后的報(bào)文頭信息保持不變.

表1 業(yè)務(wù)鏈ID方案優(yōu)缺點(diǎn)比較
Table 1 Comparison of service chain ID solutions

匹配域需求標(biāo)簽字段MPLSVLANL2L3L4Src-MACToS(DS)IPv4/v6OptionTCPoption新增字段NSH是否無(wú)需修改交換機(jī)YESYESYESYESYESYESNO是否滿足長(zhǎng)度的需求YESNOYESNONONOYES是否與原業(yè)務(wù)無(wú)沖突NONOYESNONONOYES是否無(wú)需修改中間件NOYESYESYESYESYESNO

4 實(shí)驗(yàn)分析

業(yè)務(wù)鏈平臺(tái)作為企業(yè)網(wǎng)絡(luò)和運(yùn)營(yíng)商網(wǎng)絡(luò)部署的重要應(yīng)用,重要性不言而喻.因此,經(jīng)過(guò)架構(gòu)設(shè)計(jì)和系統(tǒng)編碼后,需要對(duì)業(yè)務(wù)鏈平臺(tái)進(jìn)行全面的系統(tǒng)測(cè)試,確保平臺(tái)功能的準(zhǔn)確性和完備性.為了驗(yàn)證本文所提出的標(biāo)準(zhǔn)化業(yè)務(wù)鏈平臺(tái)的可行性,我們按照?qǐng)D8拓?fù)溥M(jìn)行了平臺(tái)功能測(cè)試和性能測(cè)試.測(cè)試在商用服務(wù)器(CPU為Intel(R)Xeon(R)D1528,主頻為1.9GHz,內(nèi)存為32G),使用千兆網(wǎng)卡Intel 82575進(jìn)行.

圖8 業(yè)務(wù)鏈平臺(tái)測(cè)試拓?fù)銯ig.8 Test topology of service chain platform

功能測(cè)試:用戶通過(guò)拖拽方式可以新建兩種業(yè)務(wù),其中業(yè)務(wù)1的業(yè)務(wù)鏈編號(hào)為0001,業(yè)務(wù)2的業(yè)務(wù)鏈編號(hào)為0002.新建的兩條業(yè)務(wù)鏈通過(guò)控制層將流表項(xiàng)下發(fā)至轉(zhuǎn)發(fā)面,主機(jī)H1和H2分別對(duì)應(yīng)業(yè)務(wù)1和業(yè)務(wù)2,SDN流分類(lèi)器和SDN交換機(jī)的表項(xiàng)如圖所示.我們?cè)贖1和H2上運(yùn)行Iperf客戶端,負(fù)責(zé)發(fā)送報(bào)文,而在H3上運(yùn)行Iperf服務(wù)端,負(fù)責(zé)接收?qǐng)?bào)文.控制器采用開(kāi)源的OpenDayLight[26],流分類(lèi)器和SDN交換機(jī)運(yùn)行開(kāi)源的OVS,版本號(hào)均為2.5.0,支持最新版本的OpenFlow協(xié)議.由于OpenFlow協(xié)議支持SET-FIELD動(dòng)作,因此能夠直接將源MAC字段修改為業(yè)務(wù)鏈ID字段使用.防火墻和網(wǎng)絡(luò)地址轉(zhuǎn)換通過(guò)開(kāi)源的ClickOS[27]實(shí)現(xiàn).我們使用Iperf工具進(jìn)行了小包測(cè)試,通過(guò)Iperf客戶端發(fā)送64字節(jié)的報(bào)文,在Iperf服務(wù)端能夠成功接收到Iperf客戶端發(fā)送的報(bào)文且無(wú)丟包,因此測(cè)試結(jié)果表明,標(biāo)準(zhǔn)化業(yè)務(wù)鏈平臺(tái)功能正常.

圖9 性能測(cè)試效果對(duì)比圖Fig.9 Comparison of performance test results

性能測(cè)試:為了保證性能測(cè)試的準(zhǔn)確性,我們采用思博倫測(cè)試儀進(jìn)行發(fā)包測(cè)試.接收端接收?qǐng)?bào)文后進(jìn)行統(tǒng)計(jì),如果不丟包則增大流量,直到出現(xiàn)丟包現(xiàn)象后,則回溯到不丟包的臨界值,以此測(cè)試最大傳輸速率,測(cè)試包長(zhǎng)為64字節(jié)、128字節(jié)、256字節(jié)、512字節(jié)、1518字節(jié)5種長(zhǎng)度.圖9比較了業(yè)務(wù)鏈ID方案與傳統(tǒng)PBR方案的傳輸速率和時(shí)延,結(jié)果表明, 兩種方案的傳輸速率和時(shí)延隨著報(bào)文大小的增大均呈現(xiàn)上升趨勢(shì),且相較于PBR方案,基于源MAC的業(yè)務(wù)鏈ID方案在報(bào)文傳輸速率方面增長(zhǎng)幅度在15%～20%,報(bào)文傳輸時(shí)延降低幅度在20%～25%.

5 總 結(jié)

在新的網(wǎng)絡(luò)架構(gòu)下,如何利用新的技術(shù)將創(chuàng)新業(yè)務(wù)更好的融合進(jìn)來(lái),從而提供便捷、安全的網(wǎng)絡(luò)架構(gòu),是業(yè)界的研究重點(diǎn).為此,提出了面向SDN和NFV融合機(jī)制的標(biāo)準(zhǔn)化業(yè)務(wù)鏈平臺(tái),以應(yīng)對(duì)新形式下基于業(yè)務(wù)鏈的新需求.本文通過(guò)對(duì)傳統(tǒng)業(yè)務(wù)鏈平臺(tái)進(jìn)行深入分析,明確了當(dāng)前網(wǎng)絡(luò)業(yè)務(wù)鏈平臺(tái)所存在的主要問(wèn)題以及標(biāo)準(zhǔn)化業(yè)務(wù)鏈平臺(tái)對(duì)SDN和NFV兩大技術(shù)的訴求.然后遵循NFV MANO標(biāo)準(zhǔn)架構(gòu)設(shè)計(jì)了面向SDN和NFV融合機(jī)制的標(biāo)準(zhǔn)化業(yè)務(wù)鏈平臺(tái)的系統(tǒng)架構(gòu),并在此基礎(chǔ)上,設(shè)計(jì)實(shí)現(xiàn)了關(guān)鍵的核心技術(shù).基于標(biāo)準(zhǔn)業(yè)務(wù)鏈平臺(tái),遵循多控制器機(jī)制設(shè)計(jì)一種高可靠性架構(gòu),為底層數(shù)據(jù)轉(zhuǎn)發(fā)提供平臺(tái)支撐,以提高業(yè)務(wù)鏈控制平面的可靠性,同時(shí)研究了業(yè)務(wù)鏈數(shù)據(jù)面轉(zhuǎn)發(fā)方案,分析比較業(yè)務(wù)鏈轉(zhuǎn)發(fā)方案的優(yōu)劣,進(jìn)而創(chuàng)新性提出一種基于源MAC的業(yè)務(wù)鏈ID方案,以提高業(yè)務(wù)鏈數(shù)據(jù)平臺(tái)的可擴(kuò)展性.最后對(duì)該業(yè)務(wù)鏈平臺(tái)進(jìn)行了可行性驗(yàn)證,測(cè)試結(jié)果表明,標(biāo)準(zhǔn)化業(yè)務(wù)鏈平臺(tái)功能正常.