SDN/NFV关键技术问题分析和标准化进展

马军锋

摘要：着重分析SDN/NFV技术在商用部署中面临的关键技术问题，包括开放接口标准化和互操作，通用硬件和控制器的性能，与现网系统的协同、安全以及集成部署等问题，并梳理国际标准组织和开源项目在SDN/NFV技术领域的进展情况。认为SDN/NFV的部署应是一个渐进式的过程，传统网络与SDN/NFV网络将会长期共存。业界需要尽快统一架构、接口和协议标准，推动不同厂商功能组件的系统集成，从而最终实现网络即服务。

关键词： SDN/NFV ；控制器；虚拟化

当前，传统网络的演进发展正面临越来越多的挑战，既要面对OTT竞争，承受降低日目前投资成本（CAPEX）/运营成本（OPEX）的压力，提升网络差异化服务的能力，又要满足消费者体验需求的互联网化，与其他行业跨界融合及构建全连接网络的诉求，网络架构重构已成为网络可持续发展的必然要求。中国三大运营商相继发布网络转型战略（电信CTNET 2025、移动NovoNet 2020愿景、联通CUBE-NET 2.0），期望通过使用软件定义网络（SDN）/网络功能虚拟化（NFV）、云计算、网络虚拟化等新技术来构建一张“资源可全局调度，能力可全面开放，容量可弹性伸缩，架构可灵活调整”的新一代网络，更好地适应从“消费型互联网”向“产业互联网”的网络转型，支撑国家“互联网+”发展战略。而在这场技术变革中，SDN/NFV是被业界普遍看好的促进现网升级演进，未来网络技术创新的重要技术，其所倡导的控制转发分离、网络能力接口的开放、软硬件解耦以及网络功能的虚拟化，将会促进产业重心由硬向软快速调整，推动网络架构向软件化、集约化、智能化和开放化的目标网络架构演进。但是，现阶段SDN/NFV的技术远未成熟，现网演进策略尚不清晰，一些关键技术问题还有待产业界协作解决。

1 SDN/NFV关键技术问题

技术可以创新，但网络发展必须是演进的，新技术的应用必须要充分考虑现网的平滑演进，这是网络发展的一般规律。当前，运营商存量网络规模大且设备极度复杂，部署SDN/NFV技术将是一项浩大的系统工程，多数运营商对如何实现现网到SDN/NFV的平滑演进，如何解决多厂商的兼容性、互联互通和集成部署等问题尚存疑虑，很难真正推动商用化规模部署。正如SDN/NFV产业联盟理事长韦乐平先生的判断：“SDN/NFV整体处在现场试验、试商用和早期商用阶段，即整体刚从过度期望进入幻灭到成熟期，估计1～4年陆续进入发展期，4～8年陆续进入稳定发展期”。因此，在一些关键技术问题上，如果产业界没有达成共识并形成统一标准，SDN/NFV很难实现商用化规模部署。

（1）开放接口的标准化和互操作问题

SDN/NFV打破了原有封闭的网络架构，实现控制转发分离，软硬件解耦，以及向上层业务开放网络能力。为此，在SDN架构下，引入了新的接口，这些接口的标准化对实现开放网络架构至关重要，也是实现多厂商方案高效集成，摆脱厂商锁定的先决条件。

南向接口（SBI）是控制器与转发设备之间下发流表的通信接口，目前呈现多样化发展态势（业界定义了超过15种的通信协议），这增加了厂商解决方案和运维部署的复杂度，也给不同厂商解决方案的互通带来更大的挑战。SBI最终能否统一成少数几种协议（如OpenFlow或NETCONF/YANG），应是业界需要亟待解决的一个问题。

北向接口（NBI）是直接为业务应用服务的，其设计与业务应用的需求密切相关，具有多样化的特征。目前市场上已经出现了20余种不同的控制器，尽管每种控制器都宣称遵循RESTful的接口标准，但是对外提供的接口都不完全相同，充分说明NBI标准尚未统一。

东西向接口主要解决控制平面的扩展性问题，实现“组大网”。同时还要考虑与非SDN网络控制平面的互通。目前，关于SDN东西向接口的研究刚刚起步，业界还存在着比较大的争议。

上述问题带来一个直接的影响，就是跨厂商的控制器与转发设备，以及与上层业务之间不能实现完全解耦，需要逐一适配，增加了互操作的成本。

（2）性能问题

性能是运营商网络的关键指标之一。数据面的转发性能（如吞吐量、时延）直接影响到用户业务体验；控制面性能决定网络规模大小，以及业务承载容量。在SDN/NFV架构下，实现了控制与转发分离，通用硬件对专有硬件的替代，性能问题成为关注的焦点。在数据平面，芯片是主要瓶颈，三态内容寻址存储器（TCAM）表项的容量直接影响到OpenFlow流表的数量，同时OpenFlow协议定义的灵活的报文格式及操作指令，也使得专用集成电路（ASIC）芯片全面支持OpenFlow协议越来越困难。而对于通用x86实现的转发面，其吞吐量更是无法达到线速转发的相关要求（根据测试的数据，128字节，10 G物理接口吞吐量<1 G；1 518字节，吞吐量<9 G）。这就需要考虑在数据处理的灵活性和吞吐量之间寻找平衡。在控制平面，SDN集中控制架构，对于控制器的性能提出了更高要求，Pakcet-in消息的处理能力、管理交换机的最大数量、流建立速率、集群能力等都是一些关键指标。从前期测试数据来看，目前中国主流厂商在这些指标上还存在明显的差异，很难满足大规模组网的需求。

另外，在引入NFV后，一方面硬件通用化、网元功能的软件化导致网络输入/输出（I/O）能力难以匹配电信网络的需求，计算能力难以满足特殊功能（如加解密、编解码、深度报文解析等）需求；另一方面，引入NFV后给中间件带来一定性能损耗。如何降低软件的开销并通过引入软硬件加速技术满足电信网络高速转发、密集计算的性能需求成为NFV需要解决的挑战之一。目前业界也提出了一些性能加速解决方案，如单根I/O虚拟化（SR-IOV）、数据平面开发工具集（DPDK）、超线程技术和硬件加速机制等。

（3）可靠性和扩展性问题

现有网络从抗毁性的需求出发设计了分布式的控制机制，网络中的每个网元都独立地学习路由，生成转发表项，并在此基础上引入故障快速检测、快速重路由、保护倒换等机制，实现链路/节点的故障保护，提升网络可靠性。而且采用分布式的分层架构，从本质上来说分散了每个网元设备的路由运算压力，能够有效支撑网络的大规模扩展（截至2016年6月底，骨干网的IPv4路由条目>620 000条）。而SDN架构采用集中的控制机制，由控制器集中完成路由计算并下发流表到转发设备，因此它成为整个网络的中枢大脑，一旦故障就会全网瘫痪，因此控制器的可靠性对于网络而言至关重要。如何避免控制器单点故障，当链路或节点故障时，网络故障如何快速上报，并快速完成流表的更新，这些问题对于控制器的实现都具有挑战。而且对于大规模的网络部署，我们还需要考虑控制器的分层部署，以及多个控制器之间的相互协作。

在设备层面，传统的电信网络设备采用软硬一体的封闭架构，使用专有硬件，能够满足线速转发的要求，而且无论是硬件还是软件的故障都能够快速检测并启动保护机制，达到99.999%的高可靠性要求。而引入NFV之后，采用通用硬件设备目前很难达到5个9的可靠性要求（一般通用商用化设备可靠性只能达到99.9%），而且原有软硬一体化设备分成了3层，并引入管理和编排（MANO）深度介入网元的自动伸缩等流程，因此，硬件资源层、虚拟资源层、虚拟网络功能（VNF）和MANO每层如何增强，3层如何协同，VNF与MANO如何配合等都会影响到整个系统的可靠性，这需要建立一套完整的可靠性体系并对3层如何协同提出明确的要求。但是，硬件资源的池化，将有助于在设备层面根据业务的需求灵活实现扩缩容，这是传统电信网络设备无法实现的。

（4）与现有运维系统的协同问题

在SDN/NFV架构下，引入新的网元管理实体，对现有网络体系架构下的系统和设备运维都会产生影响，特别是传统网络与SDN/NFV网络共存阶段，如何处理与传统网络中运营支撑系统（OSS）/基本服务集运营支持系统（BSS）等管理、运维系统的关系，原有OSS/BSS及网管系统如何与MANO协作配合，物理网络功能（PNF）和VNF如何协同管理，控制器与原有非SDN设备如何对接等，上述问题的解决将会是一个长期复杂的过程，需要在SDN/NFV实际应用部署中不断探索和完善。SDN/NFV产业联盟理事长韦乐平给出了一个观点，他认为网管系统的演进方向应当是“纵向分割，横向协同”，新系统基于开源码和开放应用程序编程接口（API），负责虚拟资源的动态管理，而原有网管系统负责物理网元的管理，通过顶层的业务生命周期管理编排提供横跨虚拟资源和物理资源的端到端业务；而新老系统通过信息模型的转换实现横向互通，很理想，但不现实。

（5）安全问题

相比传统电信设备，软硬件分离的特点以及网络的开放性给网络带来了新的潜在安全问题：一是引入新的高危区域——虚拟化管理层；二是弹性、虚拟网络使安全边界模糊，安全策略难于随网络调整而实时、动态迁移；三是用户失去对资源的完全控制以及多租户共享计算资源，带来的数据泄漏与攻击风险。在NFV环境中，可能存在安全风险的关键组件包括VNF组件实例，绑定到VNF组件实例的本地网络资源，远程设备上对本地VNF组件实例的参考，VNF组件实例占用的本地、远程以及交换存储等。在发生安全事故的情况下，如何保证这些关键组件所涉及的硬件、内存不被非法访问，如何保证VNF上应用的现有授权不被改变，本地和远程资源彻底清除崩溃的VNF资源及授权不被滥用，是NFV安全面临的关键技术挑战。

此外，控制器开源和开放的特性，使其自身也具有潜在的安全风险，需要建立一套隔离、防护备份机制来确保其安全稳定地运行，这既包含控制器自身的安全问题，也包含控制器和应用层之间以及控制器和转发设备之间的安全问题。

（6）集成部署问题

运营商引入SDN/NFV技术，其中的一个初衷是期望通过推动硬件和软件的分离，软件功能的分层解耦，进一步细化和拉长产业链环节，从而摆脱厂商锁定。引入NFV后，原先由单一厂商提供整套软硬件一体的系统，将分解成来自不同厂商的不同组件，复杂度会大大提升。从架构上看将会是一个巨大的信息通信技术（ICT）系统集成工程，包括NFV基础设施（NFVI）的集成、VNF的集成和业务网络的集成，涉及的系统、厂商、地域和接口都非常多。现阶段，NFV相关接口的标准化进度不一，部分接口将直接采用开源软件，部分API难以完全标准化。此外，开源软件和厂商定制化软件解决方案所采用的私有协议和接口，都将成为NFV系统集成和工程联调面临的巨大挑战。

2 SDN/NFV标准化新进展

上述问题需要业界尽快达成共识并形成统一标准，包括架构、接口和协议，这样才能推动SDN/NFV商用化落地。但是，与传统计算机通信（CT）的标准化制定方式不同，在SDN/NFV领域，标准化工作更加重视从标准文档到开源代码的实现，其标准化工作分为两部分：一部分由标准组织，如开放网络基金会（ONF）、国际互联网工程任务组（IETF）、欧洲电信标准化协会（ETSI）、城域以太网论坛（MEF）等制订技术标准，定义技术架构、接口协议、信息模型等；另一部分由开源社区，如开放网络操作系统（ONOS）、OpenDaylight、网络功能虚拟化开放平台（OPNFV）等推动代码实现和系统集成，形成事实上的标准，从而加快从标准文档到解决方案的落地。

（1）ONF

ONF是推动SDN技术标准的重要国际标准组织之一，其标准化工作涵盖SDN技术的各个方面，主要包括SDN架构、南/北向接口、信息模型、转发模型、向SDN网络迁移的案例及工具等，并且高度重视开源工作，成立了19个开源项目支持各领域的技术研究和标准化。

当前，作为SDN技术架构的最早提出者，ONF在南向OpenFlow协议和NBI标准化方面具有一定的影响力。OpenFlow协议目前已经推出多个版本，1.5.1是其最新版本。但是，OpenFlow1.x协议有个特点就是需要根据不同的数据平面技术做大量的协议扩展工作，为此，ONF提出了OpenFlow 2.0的概念——协议无关的转发，不但流量转发路径可编程，而且针对特定数据平面技术的处理流程也可编程，这样就将对不同数据平面技术的支持从协议层面转移到了应用层面，从而避免了每支持一种数据技术就要扩展协议的问题。目前，ONF已发布技术白皮书，并成立OF-PIF项目推动标准化。同时，斯坦福大学也发起成立了一个相关的开源项目P4，开展相关的技术研究。

在NBI方面，ONF成立多个工作组，包括通用信息模型（CIM）、NBI、光传送工作组（OTWG）等，同时成立了BOULDER和ENGLEWOOD两个开源项目。CIM工作组继承了国际电信联盟电信标准化组织（ITU-T）、电信管理论坛（TMF）等标准组织对于电信网络的建模方法，致力于定义一个对于各种网络技术公共的信息模型。通用信息模型包含与具体网络技术无关的核心信息模型（例如拓扑、转发等对象），与特定网络技术相关的信息模型（比如光传送网（OTN）、IP等）以及应用相关模型（比如NBI工作组当前定义的一些接口）等。2015年11月，CIM工作组发布了CIM1.1版本。OTWG采纳CIM的模型，对OTN等传送技术建模。2016年6月，OTWG发布TR527版本1.0，描述了控制器间接口功能需求以及控制器和协同器/应用层间功能需求，其中包括拓扑服务、连接服务、路径计算服务、虚拟网络服务、通告服务等。NBI工作组则从两个视角定义NBI，一个是自底向上的功能型NBI，重点在网络资源抽象及控制能力的开放，包括网络拓扑、第2层虚拟专用网（L2VPN）、第3层虚拟专用网（L3VPN）、隧道等接口；另一个是自顶向下基于意图的接口，关注应用或者服务的需求，同具体的网络技术无关。目前，开源BOULDER项目提供基于意图的NBI软件。

（2）IETF

IETF作为互联网领域的重要标准组织之一，也同步开展SDN/NFV相关标准化工作，涉及2个研究组和9个工作组，其中SDN RG主要针对SDN模型进行定义和分类、网络描述语言（和相关的工具）、抽象和接口、网络或节点功能的正确操作验证等；NFV RG主要关注固定和移动网络基础设施的虚拟化、基于虚拟化网络功能的新网络架构、家庭和企业网络环境的虚拟化、虚拟化和非虚拟化基础设施与服务的并存等问题研究。9个工作组涉及Internet、路由、传输、安全4个领域，研究内容涵盖移动网络、数据中心内部网络虚拟化，用于网络安全控制和监测控制功能的新信息模型、软件接口和数据模型等。其中路由系统接口（I2RS）工作组的核心思想是在目前传统网络设备的路由及转发系统基础上开放新的接口来与外部控制层通信，外部控制层通过设备反馈的事件、拓扑变化、流量统计等信息来动态地下发路由状态、策略等到各个设备上去。选择使用IETF现有的管理协议NETCONF和YANG来实现路由系统的开放。目前I2RS工作组已经完成了大部分路由信息库（RIB）和拓扑的数据模型工作，正在开展NETCONF的协议改进讨论。SPRING单播源路由工作组，在网络中实现分段路由能力，主要针对两种数据平面技术（MPLS和IPv6）进行源路由标准开发。目前该工作组已经形成了技术方案，规程已经比较完善，在进一步确定技术细节后即可发布。而针对多播流量，支持源路由在技术上更加复杂，主要是路径的标识数量大带来的挑战，IETF的BIER工作组采用BitString的形式来解决这个问题。目前BIER的工作组技术方案基本确定，标准还在开发过程中。IETF内NFV方面主要工作是由业务功能链（SFC）工作组从事。NFV将网络业务分解成基于通用软件的功能模块，而为了实现一个完整业务套餐，需要实现功能组装，并在业务层面将用户流量按照一定的形式在不同的功能模块之间进行路由。

（3）ETSI

2001年11月，由运营商主导在ETSI成立NFV ISG工作组，成为推动NFV基础架构标准的主要国际标准组织之一，主要制订支持NFV硬件和软件的基础设施要求和架构规范，以及虚拟网络功能的指南。目前已发布架构、需求、应用案例等多个技术文稿及一系列PoC文档。目前，NFV ISG已完成第1阶段的工作（2014年下半年，发布了NFV用户案例、需求、架构和术语等V2版本，以及标准化Gap分析等新版标准文档），并进入第2阶段。第2阶段的工作重点是：发展可互操作的NFV生态系统，进一步澄清第1阶段定义参考点和需求，扩大行业的参与，澄清NFV与SDN以及相关标准组织、产业、开源社区的关系。为了适应2阶段工作，NFV ISG也进行了相应的组织架构调整，在技术指导委员会（TSC）下，设立了5个工作组，包括IFA组研究的MANO功能及接口、加速技术；REL组研究的可靠性模型、故障检测及可靠性框架；TST组研究的测试方法及开源组件等；EVE组研究的NFV网络演进及生态体系建设；SEC组研究的与安全相关的内容。第2阶段中参与最广泛，并且进展最快的是IFA工作组，IFA共计完成15个项目的立项，分别关注加速资源的抽象和接口的标准化，研究架构演进（将NFVO分解为业务编排和资源编排，将VNFM分为通用VNFM和专用VNFM、VNFD重构等），研究NFV接口、模板相关的信息模型，标准化Or-Vi/Vi-Vnfm/Or-Vnfm/Ve-Vnfm/Os-Ma-nfvo等参考点包含的接口、需求和信息元定义等。

（4）MEF

2014年9月，MEF发布了“第三张网”的愿景，提出了生命周期服务编排（LSO）的理念，指出未来网络应该包含服务编排功能、API、协议无关的网络即服务（NaaS）信息模式以及在物理和虚拟服务端点之间的服务定义等。LSO是一个平台，其能够处理从客户订单到服务交付的控制，从数据采集到性能等级的保障，从故障修复到提供业务报告，以及为客户提供各种分析报告等一系列服务。LSO的六大功能包括实施、控制、性能、保障、使用和分析，从而敏捷地部署动态服务，提高新型企业网络服务的交付速度，让客户自己就能简单地通过一个Web门户来配置和管理这些产品及服务。以MEF的LSO理念，SDN控制器通过对北向API的抽象，引入了虚拟网络，屏蔽了应用匹配不同网络技术的复杂度，从而在端到端的虚拟网络抽象层上实现端到端业务，将相关的网络实施交给控制器去做。目前，MEF开放式生命周期服务编排（OpenLSO）和开放连接服务（OpenCS）计划，为实际引进编排和连接服务层的基于开源的解决方案提供了演进路径。

（5）OpenDaylight和ONOS

SDN是对网络架构的一次重构，从分布式网络架构转向集中式控制网络架构，引入SDN控制器来实现对网络的控制，为各种网络应用提供抽象统一的网络资源访问服务。作为网络的中枢大脑，业界都力争掌握控制器的主导权，积极围绕控制器构建开放的产业生态。目前，主流的控制器平台主要包括OpenDaylight和ONOS。前者由思科发起并主导，主要定位于数据中心的应用场景，最新版本是铍（Beryllium，第4个版本）版本；后者由斯坦福大学发起，主要定位于运营商广域网场景，最新版本是Goldeneye版本（第7个版本）。经过近几年的发展，两大系统平台都已构建自身的产业生态，而且在架构和功能实现上有越来越多的相似点，都包含一系列动态可拔插的网络功能组件，SBI以插件的方式支持多种协议，通过业务抽象层对控制器平台代码提供统一的接口，屏蔽底层设备协议的差别，使网络服务与底层设备协议完全解耦；通过RESTful接口，提供网络模型、网元、拓扑等多种API供应用层调用。另外，OpenDaylight的应用场景也不再局限于数据中心，通过增强其分布式集群的能力，来适应运营商广域网组网的需求。

当前，基于两个主流控制器平台的商用部署都有一些成功案例。

（6）OPNFV

OPNFV是NFV开放平台项目，旨在提供运营商级的综合开源平台以加速新产品和服务的引入，实现由ETSI规定的NFV架构与接口，提供运营商级的高可靠、高性能、高可用的开源NFV平台。OPNFV的定位是集成上游开源社区的成果（如OpenStack、OpenDaylight、ONOS、开放虚拟交换机（OVS）、分布式的对象存储和文件系统（CEPH）等），并且推动上游社区加速接纳NFV相关需求。OPNFV将项目分为4类：需求类、集成与测试类、合作开放类、文档类。其中需求类项目的主要目标是发现NFV需求和上游社区版本间的差距，然后将需求提交到上游社区，并且推动上游社区接纳，代码相关的工作在上游社区完成。2016年3月，OPNFV发布第2个版本Brahmaputra，提供包括OpenDaylight、ONOS和Open Contrail等多个SDN控制器的集成，超过30个项目贡献了规范和社区资源。

（7）协同器开源项目

SDN协同器是运营商网络和业务相结合的核心组件，是运营商网络业务创新的使能平台，提供跨域、跨层、跨厂家的网络资源抽象和业务编排；向下对接控制器，向上对接IT系统。运营商迫切希望基于SDN/NFV加速业务创新，实现敏捷运营，因此纷纷建设ICT业务使能平台——端到端的业务协同器，通过集中的网络能力抽象，跨域资源统一编排，加速网络业务创新，进而依托网络业务的优势向上延伸整合平台即服务（PaaS）和软件即服务（SaaS）成为ICT的掌控者。目前包括中国移动Open-O和西班牙电信Open-MANO等多个开源项目，都是由运营商主导，希望构建自主可控的协同器平台，以避免被厂商锁定。

3 结束语

使用SDN/NFV、网络虚拟化等新技术重构传统网络架构是网络演进发展的必然趋势。但是，由于现网大量设备和系统的存在，不可能以“一刀切”的方式彻底革命，因此SDN/NFV的部署应是一个渐进式的过程，传统网络与SDN/NFV网络将会长期共存，这要求业界尽快统一架构、接口和协议标准，推动不同厂商功能组件的系统集成，实现真正意义上的控制转发分离，软硬分离，业务功能模块的任意组合，从而最终实现网络即服务。当然，芯片、网络操作系统、协同器等关键技术和系统的突破也是必须的。

参考文献

[1] Linux Foundation. Platform Overview[EB/OL].[2016-09-10].https：//www.opendaylight.org/platform-overview/

[2] Open Networking Lab. Introducing ONOS-A SDN Network Operating System for Service Providers [EB/OL]. [2016-09-12]. http：//onosproject.org/wp-content/uploads/2014/11/Whitepaper-ONOS-final.pdf

[3] The P4 Language Consortium. The P4 Language Specification [S/OL]. [2016-09-15].http：//p4.org/wp-content/uploads/2016/03/p4_v1.1.pdf

[4] MEF. Vision and Strategy Based on Network as a Service Princeples [EB/OL]. （2014-09-30） [2016-09-12].http：//www.mef.net/Assets/Documents/MEF_Third_Network_Vision_FINAL.pdf

[5] Linux Foundation. OPNFV Plugfest Report[R/OL]. [2016-09-15]. https：//www.opnfv.org/sites/opnfv/files/collateral/files/inaugural_opnfv_plugfest_report_0.pdf

[6] Open Source SDN. Our Projects [EB/OL]. （2015-09-13） [2016-09-16].http：//opensourcesdn.org/our-projects/

[7] IEEE Software Defined Networks. OpenSource MANO [EB/OL]. （2016-07-17） [2016-09-20]. http：//sdn.ieee.org/newsletter/july-2016/opensource-mano

[8]杨洋，张国颖. SDN北向接口标准化简介[EB/OL].（2016-07-01）[2016-09-20].http：//www.sdnlab.com/17275.html

[9] Network Functions Virtualization （NFV）. Management and Orchestration， Functional Requirements Specification[S]： ETSI GS NFV-IFA 010