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