BRAS SDN&NFV的演進思路

王懷濱+王延松

摘要：認為寬帶遠程接入服務器（BRAS）與軟件定義網絡（SDN）、網絡功能虛擬化（NFV）技術的結合是未來網絡演進的方向，是實現未來彈性網絡的關鍵。提出了作為電信網絡邊緣核心的BRAS設備在SDN&NFV技術大潮下的具體的演進思路：BRAS與SDN&NFV技術的結合，采用控制與轉發分離、軟件與硬件解耦，實現彈性、可擴展、可編程的新型的寬帶接入控制，為運營商提供靈活、高效、可靠的寬帶接入服務。

關鍵詞： BRAS；寬帶網絡網關（BNG）；SDN；NFV

隨著互聯網業務不斷豐富，特別是云計算、大數據、萬物互聯等業務的發展，對基礎網絡設施提出了更高要求，包括大帶寬資源、高可靠性及靈活資源調度等。傳統的電信網絡在快速發展的互聯網業務面前顯得捉襟見肘。軟件定義網絡（SDN）和網絡功能虛擬化（NFV）技術的涌現給網絡演進注入了新元素與動力。寬帶遠程接入服務器（BRAS）設備位于城域網邊緣，是用戶實現各種業務的入口及策略執行點，也是整個互聯網業務的核心節點。BRAS與SDN、NFV技術的結合是未來網絡演進的方向，是實現未來彈性網絡的關鍵[1-2]。

1 現有BRAS部署及運營難題

現階段，BRAS設備是軟硬件一體化的專用設備，是典型的控制與轉發緊耦合網絡設備。在設備規模應用及業務運營過程中，一系列問題逐漸浮現[3]。

（1）設備資源難以復用及共享。在單臺設備環境中，經常出現轉發面與控制面資源不協調的矛盾，部分高帶寬要求節點，如承接光網城市高速接入用戶區域，轉發端口及帶寬資源消耗殆盡，而用戶會話及服務質量（QoS）隊列、訪問控制列表（ACL）隊列等控制面資源有余；部分節點承載著大量長時間在線業務，如IP多媒體子系統（IMS）、終端綜合管理系統（ITMS）等，用戶會話等控制面資源耗光，而空閑端口資源卻十分豐富。此外，多臺BRAS設備之間無法形成負荷分擔，存在忙閑不均情況，導致投資資源未被充分利用。

（2）設備能力提升與硬件強相關，升級困難。而在硬件升級方面，從10 G升級到40 G，40 G再升級到100 G，100 G升級到400 G，400 G再到更高性能的硬件平臺，每次提升都需大量的投資，且低能力設備及板卡可利舊率較低。在軟件升級方面，業務功能實現與硬件相關，需要同時滿足特定的硬件及軟件升級才能達到相應的水平，給新業務部署帶來極大的阻礙，拖延業務上線時間。

（3）設備配置與設備底層操作系統（OS）強相關，基本采用命令行界面（CLI）方式，配置效率低，且不同設備需預置大量用戶策略，運維工作量大。每臺設備上線都需重新配置，無可重用性，對運營能力要求高。

（4）設備實現融合業務難度大，需硬軟件同時升級。業務融合包括BRAS與業務路由器（SR）的融合，與運營商級網絡地址轉換（CGN）的融合，與防火墻（FW）的融合，與深度報文檢測（DPI）的融合等，需配置相應的專用功能卡。此外，軟件功能需同時進行相應業務模塊開發與整合，增加軟件版本復雜度，且帶來軟件不穩定，軟件開發成本急劇上升，軟件升級周期長等問題。

2 BRAS的轉型之路

電信運營商互聯網化轉型需求迫切。業務云化成為了互聯網業務發展的趨勢，這對底層網絡提出了軟件可編程要求。上層應用希望通過網絡提供的可編程接口，實現應用驅動的網絡資源調度與管理，促進增值應用的快速迭代開發。SDN與NFV技術是實現網絡轉型的利器。SDN強調轉發與控制分離，實現集中式管理，提升網絡運營效率。NFV技術提倡采用通用x86服務器實現網絡業務功能，在降低硬件成本的同時提升軟件可編程水平，加快軟件開發周期。

SDN、NFV與邊緣控制設備的融合（如圖1所示），是下一代智能邊緣研發方向，可解決當前遇到的難題與滿足業務需求。虛擬寬帶遠程接入服務器（VBRAS）具備以下優勢。

（1）設備轉發平面與控制平面分離，打破當前設備封閉性，實現網絡功能與硬件的松耦合，設備硬件及軟件升級簡單；

（2）設備資源可虛擬化，采用云技術進行承載，可實現彈性伸縮，并根據業務的具體需求，動態地擴容或者縮減資源；

（3）設備融合業務增強更加簡單，可采用軟件模塊實現專用的業務功能，提升增值業務能力；

（4）控制面集中管理，可實現整網業務策略的統一部署，提升業務上線速率，增強市場競爭力；

（5）理想情況下，設備控制平面與轉發平面可形成相應的資源池，實現彈性擴展及靈活調度，提升資源利用率及高可靠性。

3 VBRAS的部署

VBRAS是運營商實現未來云網融合目標架構關鍵要素，是業界研究熱點。目前VBRAS主要還是在方案驗證階段，預計2017年后才出現真正標準意義上的VBRAS產品。整體來看，VBRAS有兩條演進路線。

第1類 VBRAS方案（如圖2所示），是傳統的通信技術產業（CT）廠商普遍采用SDN+NFV的方案，可稱為“CT線”。該方案優先實現轉發控制分離，控制平面采用通用x86服務器，轉發平面采用專用轉發設備。該方案下的轉發設備未來可基于白牌設備發展，逐步演進至通用轉發設備。CT線暫不存在性能處理方面的問題，但白牌設備的發展有待產業鏈進一步推動。該方案的典型特點是將傳統的BRAS設備控制面與轉發面分離，即控制面基于NFV架構實現虛擬化；轉發面基于專用的物理轉發設備進行相關的業務轉發。該方案具備以下優勢。

（1）轉發面可以利用現有的BRAS設備，充分利用現有資源，從而保護運營商的現有投資。

（2）轉發性能強。因為轉發設備采用傳統的物理BRAS設備轉發，轉發性能強。現有的BRAS設備基本都是100 G及以上的平臺，支持每線卡100 G及以上的業務轉發能力，這是當前通用服務器達不到的。

（3）多業務的疊加能力強。該方案實現控制與轉發分離，轉發實體還是傳統的BRAS設備，整個網絡架構并沒有改變，整體業務的處理流程沒有變化。原來BRAS設備上的路由功能、運營商級網絡地址轉換（CGN）等多業務功能都很好的得到了繼承。

（4）轉發時延小。用戶的數據流量并沒有進入數據中心，在當前網絡架構下，轉發路徑更加扁平化，用戶業務流量轉發路徑短，轉發時延小。

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

（1）硬件平臺不通用，需要專用的轉發設備做轉發，系統封閉。

（2）轉發面虛擬化程度不高。因為是專用的硬件平臺，很難納入云平臺的統一控制，從而很難在NFV統一架構下實現虛擬化。

第2類VBRAS方案（如圖3所示），是信息技術產業（IT）廠商更喜歡采用SDN+NFV的方案，可稱為“IT線”。該方案當前主要將BRAS的業務的整體功能運行在服務器上實現BRAS設備網元級的虛擬化，未來可基于軟件功能分集，每個功能作為單獨的虛擬機，從而實現BRAS業務組件級虛擬化。網元級虛擬化相比部署和擴容更加靈活。該方案的典型特點是BRAS的控制與轉發都基于NFV架構實現虛擬化，部署在數據中心。方案優點是虛擬化程度高，具有彈性伸縮能力，部署更加靈活。

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

（1）服務器轉發性能不足，小字節報文處理性能較差，多業務處理能力欠缺等。尤其是BRAS業務最關注的用戶多業務處理的QoS功能，目前服務器支持的性能和傳統BRAS設備相差甚遠，不能滿足大用戶量需求。

（2）多業務疊加能力弱。現在的BRAS設備實際是一個多業務融合的網關設備。BRAS設備上除了支持用戶接入功能外，還有路由功能、組播功能、CGN功能、防火墻功能等。本方案只是將其中的BRAS接入功能虛擬化了，其他功能還沒有虛擬化，從而導致多業務疊加能力差。

（3）組播支持能力弱。組播只能支持以太網上互聯網協議（IPoE）用戶的組播，不支持以太網上的點到點協議（PPPoE）用戶的組播。

（4）網絡時延長。用戶的數據流量需要到數據中心處理完之后還需要重新回到城域網處理， 數據流量轉發經過的跳數多，轉發時延大。在當前各種互聯網業務層出不窮的時代，各種新業務對時延的要求越來越高，將所有流量全部送到數據中心的做法顯得就并不適當了。

（5）運營商網絡部署困難，需要對現有網絡進行大的改造。傳統SR/BRAS作為城域網邊緣的網絡架構要發生大的變化是一個長期過程。

4 BRAS SDN&NFV的演進思考

隨著SDN及NFV大規模試點，業界表現出一定的理性。網絡演進需同時兼顧傳統網絡部署及未來新業務需求。網絡邊緣設備需要同時支持豐富業務控制及流量高速轉發的節點，以滿足未來業務鏈發展。

（1）推動BRAS設備控制與轉發分離。控制面基于服務器實現虛擬化，轉發面使用專用轉發設備，部署在城域網邊緣，實現SDN架構的BRAS轉發。運營商可在現有網絡架構之下分享SDN&NFV帶來的好處。

（2）推動控制平面集中部署及池化，實現控制平面的冗余及靈活擴展。同時推動互聯網內容提供商（IDC）網絡下移，在城域網網絡服務提供點（POP）構建微型互聯網數據中心（IDC），實施云平臺在城域的延伸，并構建云化VBRAS池。

（3）基于云化思維構建城域虛擬網絡服務提供點（vPOP），彈性部署虛擬深度報文檢測（vDPI）等增值模塊。部署城域業務鏈平臺，提供基于用戶的增值業務，實現新型業務收入。與此同時，推動通用轉發設備產業鏈發展，逐步實現轉發設備池化。

5 結束語

傳統BRAS與SDN&NFV技術的融合是大勢所趨，但大規模部署還有很長的路要走。結合具體的業務與應用場景，選擇合適方案，分階段部署將是未來BRAS與SDN&NFV技術結合的可行之路和長期演進過程。

參考文獻

[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