王懷濱+王延松

摘要：認(rèn)為寬帶遠(yuǎn)程接入服務(wù)器（BRAS）與軟件定義網(wǎng)絡(luò)（SDN）、網(wǎng)絡(luò)功能虛擬化（NFV）技術(shù)的結(jié)合是未來(lái)網(wǎng)絡(luò)演進(jìn)的方向，是實(shí)現(xiàn)未來(lái)彈性網(wǎng)絡(luò)的關(guān)鍵。提出了作為電信網(wǎng)絡(luò)邊緣核心的BRAS設(shè)備在SDN&NFV技術(shù)大潮下的具體的演進(jìn)思路：BRAS與SDN&NFV技術(shù)的結(jié)合，采用控制與轉(zhuǎn)發(fā)分離、軟件與硬件解耦，實(shí)現(xiàn)彈性、可擴(kuò)展、可編程的新型的寬帶接入控制，為運(yùn)營(yíng)商提供靈活、高效、可靠的寬帶接入服務(wù)。

關(guān)鍵詞： BRAS；寬帶網(wǎng)絡(luò)網(wǎng)關(guān)（BNG）；SDN；NFV

隨著互聯(lián)網(wǎng)業(yè)務(wù)不斷豐富，特別是云計(jì)算、大數(shù)據(jù)、萬(wàn)物互聯(lián)等業(yè)務(wù)的發(fā)展，對(duì)基礎(chǔ)網(wǎng)絡(luò)設(shè)施提出了更高要求，包括大帶寬資源、高可靠性及靈活資源調(diào)度等。傳統(tǒng)的電信網(wǎng)絡(luò)在快速發(fā)展的互聯(lián)網(wǎng)業(yè)務(wù)面前顯得捉襟見(jiàn)肘。軟件定義網(wǎng)絡(luò)（SDN）和網(wǎng)絡(luò)功能虛擬化（NFV）技術(shù)的涌現(xiàn)給網(wǎng)絡(luò)演進(jìn)注入了新元素與動(dòng)力。寬帶遠(yuǎn)程接入服務(wù)器（BRAS）設(shè)備位于城域網(wǎng)邊緣，是用戶(hù)實(shí)現(xiàn)各種業(yè)務(wù)的入口及策略執(zhí)行點(diǎn)，也是整個(gè)互聯(lián)網(wǎng)業(yè)務(wù)的核心節(jié)點(diǎn)。BRAS與SDN、NFV技術(shù)的結(jié)合是未來(lái)網(wǎng)絡(luò)演進(jìn)的方向，是實(shí)現(xiàn)未來(lái)彈性網(wǎng)絡(luò)的關(guān)鍵[1-2]。

1 現(xiàn)有BRAS部署及運(yùn)營(yíng)難題

現(xiàn)階段，BRAS設(shè)備是軟硬件一體化的專(zhuān)用設(shè)備，是典型的控制與轉(zhuǎn)發(fā)緊耦合網(wǎng)絡(luò)設(shè)備。在設(shè)備規(guī)模應(yīng)用及業(yè)務(wù)運(yùn)營(yíng)過(guò)程中，一系列問(wèn)題逐漸浮現(xiàn)[3]。

（1）設(shè)備資源難以復(fù)用及共享。在單臺(tái)設(shè)備環(huán)境中，經(jīng)常出現(xiàn)轉(zhuǎn)發(fā)面與控制面資源不協(xié)調(diào)的矛盾，部分高帶寬要求節(jié)點(diǎn)，如承接光網(wǎng)城市高速接入用戶(hù)區(qū)域，轉(zhuǎn)發(fā)端口及帶寬資源消耗殆盡，而用戶(hù)會(huì)話及服務(wù)質(zhì)量（QoS）隊(duì)列、訪問(wèn)控制列表（ACL）隊(duì)列等控制面資源有余；部分節(jié)點(diǎn)承載著大量長(zhǎng)時(shí)間在線業(yè)務(wù)，如IP多媒體子系統(tǒng)（IMS）、終端綜合管理系統(tǒng)（ITMS）等，用戶(hù)會(huì)話等控制面資源耗光，而空閑端口資源卻十分豐富。此外，多臺(tái)BRAS設(shè)備之間無(wú)法形成負(fù)荷分擔(dān)，存在忙閑不均情況，導(dǎo)致投資資源未被充分利用。

（2）設(shè)備能力提升與硬件強(qiáng)相關(guān)，升級(jí)困難。而在硬件升級(jí)方面，從10 G升級(jí)到40 G，40 G再升級(jí)到100 G，100 G升級(jí)到400 G，400 G再到更高性能的硬件平臺(tái)，每次提升都需大量的投資，且低能力設(shè)備及板卡可利舊率較低。在軟件升級(jí)方面，業(yè)務(wù)功能實(shí)現(xiàn)與硬件相關(guān)，需要同時(shí)滿(mǎn)足特定的硬件及軟件升級(jí)才能達(dá)到相應(yīng)的水平，給新業(yè)務(wù)部署帶來(lái)極大的阻礙，拖延業(yè)務(wù)上線時(shí)間。

（3）設(shè)備配置與設(shè)備底層操作系統(tǒng)（OS）強(qiáng)相關(guān)，基本采用命令行界面（CLI）方式，配置效率低，且不同設(shè)備需預(yù)置大量用戶(hù)策略，運(yùn)維工作量大。每臺(tái)設(shè)備上線都需重新配置，無(wú)可重用性，對(duì)運(yùn)營(yíng)能力要求高。

（4）設(shè)備實(shí)現(xiàn)融合業(yè)務(wù)難度大，需硬軟件同時(shí)升級(jí)。業(yè)務(wù)融合包括BRAS與業(yè)務(wù)路由器（SR）的融合，與運(yùn)營(yíng)商級(jí)網(wǎng)絡(luò)地址轉(zhuǎn)換（CGN）的融合，與防火墻（FW）的融合，與深度報(bào)文檢測(cè)（DPI）的融合等，需配置相應(yīng)的專(zhuān)用功能卡。此外，軟件功能需同時(shí)進(jìn)行相應(yīng)業(yè)務(wù)模塊開(kāi)發(fā)與整合，增加軟件版本復(fù)雜度，且?guī)?lái)軟件不穩(wěn)定，軟件開(kāi)發(fā)成本急劇上升，軟件升級(jí)周期長(zhǎng)等問(wèn)題。

2 BRAS的轉(zhuǎn)型之路

電信運(yùn)營(yíng)商互聯(lián)網(wǎng)化轉(zhuǎn)型需求迫切。業(yè)務(wù)云化成為了互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展的趨勢(shì)，這對(duì)底層網(wǎng)絡(luò)提出了軟件可編程要求。上層應(yīng)用希望通過(guò)網(wǎng)絡(luò)提供的可編程接口，實(shí)現(xiàn)應(yīng)用驅(qū)動(dòng)的網(wǎng)絡(luò)資源調(diào)度與管理，促進(jìn)增值應(yīng)用的快速迭代開(kāi)發(fā)。SDN與NFV技術(shù)是實(shí)現(xiàn)網(wǎng)絡(luò)轉(zhuǎn)型的利器。SDN強(qiáng)調(diào)轉(zhuǎn)發(fā)與控制分離，實(shí)現(xiàn)集中式管理，提升網(wǎng)絡(luò)運(yùn)營(yíng)效率。NFV技術(shù)提倡采用通用x86服務(wù)器實(shí)現(xiàn)網(wǎng)絡(luò)業(yè)務(wù)功能，在降低硬件成本的同時(shí)提升軟件可編程水平，加快軟件開(kāi)發(fā)周期。

SDN、NFV與邊緣控制設(shè)備的融合（如圖1所示），是下一代智能邊緣研發(fā)方向，可解決當(dāng)前遇到的難題與滿(mǎn)足業(yè)務(wù)需求。虛擬寬帶遠(yuǎn)程接入服務(wù)器（VBRAS）具備以下優(yōu)勢(shì)。

（1）設(shè)備轉(zhuǎn)發(fā)平面與控制平面分離，打破當(dāng)前設(shè)備封閉性，實(shí)現(xiàn)網(wǎng)絡(luò)功能與硬件的松耦合，設(shè)備硬件及軟件升級(jí)簡(jiǎn)單；

（2）設(shè)備資源可虛擬化，采用云技術(shù)進(jìn)行承載，可實(shí)現(xiàn)彈性伸縮，并根據(jù)業(yè)務(wù)的具體需求，動(dòng)態(tài)地?cái)U(kuò)容或者縮減資源；

（3）設(shè)備融合業(yè)務(wù)增強(qiáng)更加簡(jiǎn)單，可采用軟件模塊實(shí)現(xiàn)專(zhuān)用的業(yè)務(wù)功能，提升增值業(yè)務(wù)能力；

（4）控制面集中管理，可實(shí)現(xiàn)整網(wǎng)業(yè)務(wù)策略的統(tǒng)一部署，提升業(yè)務(wù)上線速率，增強(qiáng)市場(chǎng)競(jìng)爭(zhēng)力；

（5）理想情況下，設(shè)備控制平面與轉(zhuǎn)發(fā)平面可形成相應(yīng)的資源池，實(shí)現(xiàn)彈性擴(kuò)展及靈活調(diào)度，提升資源利用率及高可靠性。

3 VBRAS的部署

VBRAS是運(yùn)營(yíng)商實(shí)現(xiàn)未來(lái)云網(wǎng)融合目標(biāo)架構(gòu)關(guān)鍵要素，是業(yè)界研究熱點(diǎn)。目前VBRAS主要還是在方案驗(yàn)證階段，預(yù)計(jì)2017年后才出現(xiàn)真正標(biāo)準(zhǔn)意義上的VBRAS產(chǎn)品。整體來(lái)看，VBRAS有兩條演進(jìn)路線。

第1類(lèi) VBRAS方案（如圖2所示），是傳統(tǒng)的通信技術(shù)產(chǎn)業(yè)（CT）廠商普遍采用SDN+NFV的方案，可稱(chēng)為“CT線”。該方案優(yōu)先實(shí)現(xiàn)轉(zhuǎn)發(fā)控制分離，控制平面采用通用x86服務(wù)器，轉(zhuǎn)發(fā)平面采用專(zhuān)用轉(zhuǎn)發(fā)設(shè)備。該方案下的轉(zhuǎn)發(fā)設(shè)備未來(lái)可基于白牌設(shè)備發(fā)展，逐步演進(jìn)至通用轉(zhuǎn)發(fā)設(shè)備。CT線暫不存在性能處理方面的問(wèn)題，但白牌設(shè)備的發(fā)展有待產(chǎn)業(yè)鏈進(jìn)一步推動(dòng)。該方案的典型特點(diǎn)是將傳統(tǒng)的BRAS設(shè)備控制面與轉(zhuǎn)發(fā)面分離，即控制面基于NFV架構(gòu)實(shí)現(xiàn)虛擬化；轉(zhuǎn)發(fā)面基于專(zhuān)用的物理轉(zhuǎn)發(fā)設(shè)備進(jìn)行相關(guān)的業(yè)務(wù)轉(zhuǎn)發(fā)。該方案具備以下優(yōu)勢(shì)。

（1）轉(zhuǎn)發(fā)面可以利用現(xiàn)有的BRAS設(shè)備，充分利用現(xiàn)有資源，從而保護(hù)運(yùn)營(yíng)商的現(xiàn)有投資。

（2）轉(zhuǎn)發(fā)性能強(qiáng)。因?yàn)檗D(zhuǎn)發(fā)設(shè)備采用傳統(tǒng)的物理BRAS設(shè)備轉(zhuǎn)發(fā)，轉(zhuǎn)發(fā)性能強(qiáng)?，F(xiàn)有的BRAS設(shè)備基本都是100 G及以上的平臺(tái)，支持每線卡100 G及以上的業(yè)務(wù)轉(zhuǎn)發(fā)能力，這是當(dāng)前通用服務(wù)器達(dá)不到的。

（3）多業(yè)務(wù)的疊加能力強(qiáng)。該方案實(shí)現(xiàn)控制與轉(zhuǎn)發(fā)分離，轉(zhuǎn)發(fā)實(shí)體還是傳統(tǒng)的BRAS設(shè)備，整個(gè)網(wǎng)絡(luò)架構(gòu)并沒(méi)有改變，整體業(yè)務(wù)的處理流程沒(méi)有變化。原來(lái)BRAS設(shè)備上的路由功能、運(yùn)營(yíng)商級(jí)網(wǎng)絡(luò)地址轉(zhuǎn)換（CGN）等多業(yè)務(wù)功能都很好的得到了繼承。

（4）轉(zhuǎn)發(fā)時(shí)延小。用戶(hù)的數(shù)據(jù)流量并沒(méi)有進(jìn)入數(shù)據(jù)中心，在當(dāng)前網(wǎng)絡(luò)架構(gòu)下，轉(zhuǎn)發(fā)路徑更加扁平化，用戶(hù)業(yè)務(wù)流量轉(zhuǎn)發(fā)路徑短，轉(zhuǎn)發(fā)時(shí)延小。

然而，該方案也有如下局限性。

（1）硬件平臺(tái)不通用，需要專(zhuān)用的轉(zhuǎn)發(fā)設(shè)備做轉(zhuǎn)發(fā)，系統(tǒng)封閉。

（2）轉(zhuǎn)發(fā)面虛擬化程度不高。因?yàn)槭菍?zhuān)用的硬件平臺(tái)，很難納入云平臺(tái)的統(tǒng)一控制，從而很難在NFV統(tǒng)一架構(gòu)下實(shí)現(xiàn)虛擬化。

第2類(lèi)VBRAS方案（如圖3所示），是信息技術(shù)產(chǎn)業(yè)（IT）廠商更喜歡采用SDN+NFV的方案，可稱(chēng)為“IT線”。該方案當(dāng)前主要將BRAS的業(yè)務(wù)的整體功能運(yùn)行在服務(wù)器上實(shí)現(xiàn)BRAS設(shè)備網(wǎng)元級(jí)的虛擬化，未來(lái)可基于軟件功能分集，每個(gè)功能作為單獨(dú)的虛擬機(jī)，從而實(shí)現(xiàn)BRAS業(yè)務(wù)組件級(jí)虛擬化。網(wǎng)元級(jí)虛擬化相比部署和擴(kuò)容更加靈活。該方案的典型特點(diǎn)是BRAS的控制與轉(zhuǎn)發(fā)都基于NFV架構(gòu)實(shí)現(xiàn)虛擬化，部署在數(shù)據(jù)中心。方案優(yōu)點(diǎn)是虛擬化程度高，具有彈性伸縮能力，部署更加靈活。

然而，該方案也有如下局限性。

（1）服務(wù)器轉(zhuǎn)發(fā)性能不足，小字節(jié)報(bào)文處理性能較差，多業(yè)務(wù)處理能力欠缺等。尤其是BRAS業(yè)務(wù)最關(guān)注的用戶(hù)多業(yè)務(wù)處理的QoS功能，目前服務(wù)器支持的性能和傳統(tǒng)BRAS設(shè)備相差甚遠(yuǎn)，不能滿(mǎn)足大用戶(hù)量需求。

（2）多業(yè)務(wù)疊加能力弱?，F(xiàn)在的BRAS設(shè)備實(shí)際是一個(gè)多業(yè)務(wù)融合的網(wǎng)關(guān)設(shè)備。BRAS設(shè)備上除了支持用戶(hù)接入功能外，還有路由功能、組播功能、CGN功能、防火墻功能等。本方案只是將其中的BRAS接入功能虛擬化了，其他功能還沒(méi)有虛擬化，從而導(dǎo)致多業(yè)務(wù)疊加能力差。

（3）組播支持能力弱。組播只能支持以太網(wǎng)上互聯(lián)網(wǎng)協(xié)議（IPoE）用戶(hù)的組播，不支持以太網(wǎng)上的點(diǎn)到點(diǎn)協(xié)議（PPPoE）用戶(hù)的組播。

（4）網(wǎng)絡(luò)時(shí)延長(zhǎng)。用戶(hù)的數(shù)據(jù)流量需要到數(shù)據(jù)中心處理完之后還需要重新回到城域網(wǎng)處理， 數(shù)據(jù)流量轉(zhuǎn)發(fā)經(jīng)過(guò)的跳數(shù)多，轉(zhuǎn)發(fā)時(shí)延大。在當(dāng)前各種互聯(lián)網(wǎng)業(yè)務(wù)層出不窮的時(shí)代，各種新業(yè)務(wù)對(duì)時(shí)延的要求越來(lái)越高，將所有流量全部送到數(shù)據(jù)中心的做法顯得就并不適當(dāng)了。

（5）運(yùn)營(yíng)商網(wǎng)絡(luò)部署困難，需要對(duì)現(xiàn)有網(wǎng)絡(luò)進(jìn)行大的改造。傳統(tǒng)SR/BRAS作為城域網(wǎng)邊緣的網(wǎng)絡(luò)架構(gòu)要發(fā)生大的變化是一個(gè)長(zhǎng)期過(guò)程。

4 BRAS SDN&NFV的演進(jìn)思考

隨著SDN及NFV大規(guī)模試點(diǎn)，業(yè)界表現(xiàn)出一定的理性。網(wǎng)絡(luò)演進(jìn)需同時(shí)兼顧傳統(tǒng)網(wǎng)絡(luò)部署及未來(lái)新業(yè)務(wù)需求。網(wǎng)絡(luò)邊緣設(shè)備需要同時(shí)支持豐富業(yè)務(wù)控制及流量高速轉(zhuǎn)發(fā)的節(jié)點(diǎn)，以滿(mǎn)足未來(lái)業(yè)務(wù)鏈發(fā)展。

（1）推動(dòng)BRAS設(shè)備控制與轉(zhuǎn)發(fā)分離。控制面基于服務(wù)器實(shí)現(xiàn)虛擬化，轉(zhuǎn)發(fā)面使用專(zhuān)用轉(zhuǎn)發(fā)設(shè)備，部署在城域網(wǎng)邊緣，實(shí)現(xiàn)SDN架構(gòu)的BRAS轉(zhuǎn)發(fā)。運(yùn)營(yíng)商可在現(xiàn)有網(wǎng)絡(luò)架構(gòu)之下分享SDN&NFV帶來(lái)的好處。

（2）推動(dòng)控制平面集中部署及池化，實(shí)現(xiàn)控制平面的冗余及靈活擴(kuò)展。同時(shí)推動(dòng)互聯(lián)網(wǎng)內(nèi)容提供商（IDC）網(wǎng)絡(luò)下移，在城域網(wǎng)網(wǎng)絡(luò)服務(wù)提供點(diǎn)（POP）構(gòu)建微型互聯(lián)網(wǎng)數(shù)據(jù)中心（IDC），實(shí)施云平臺(tái)在城域的延伸，并構(gòu)建云化VBRAS池。

（3）基于云化思維構(gòu)建城域虛擬網(wǎng)絡(luò)服務(wù)提供點(diǎn)（vPOP），彈性部署虛擬深度報(bào)文檢測(cè)（vDPI）等增值模塊。部署城域業(yè)務(wù)鏈平臺(tái)，提供基于用戶(hù)的增值業(yè)務(wù)，實(shí)現(xiàn)新型業(yè)務(wù)收入。與此同時(shí)，推動(dòng)通用轉(zhuǎn)發(fā)設(shè)備產(chǎn)業(yè)鏈發(fā)展，逐步實(shí)現(xiàn)轉(zhuǎn)發(fā)設(shè)備池化。

5 結(jié)束語(yǔ)

傳統(tǒng)BRAS與SDN&NFV技術(shù)的融合是大勢(shì)所趨，但大規(guī)模部署還有很長(zhǎng)的路要走。結(jié)合具體的業(yè)務(wù)與應(yīng)用場(chǎng)景，選擇合適方案，分階段部署將是未來(lái)BRAS與SDN&NFV技術(shù)結(jié)合的可行之路和長(zhǎng)期演進(jìn)過(guò)程。

參考文獻(xiàn)

[1] Broadband Forum. WT-345 Broadband Network Gateway and Network Function Virtualization [R]. USA： Broadband Forum， 2016

[2] QUINN P， NADEQU T. Problem Statement for Service Function Chaining[R/OL]. [2016-04-05]. http：//www.rfc-editor.org/info/rfc7498. DOI 10.17487/RFC7498

[3] HALPERN J， PIGNATARO C. Service Function Chaining （SFC） Architecture[R/OL]. [2016-04-08]. http：//www.rfc-editor.org/info/rfc7665. DOI 10.17487/RFC7665