运营商SDN云网协同架构和关键技术研究

鲁子奕　杨文斌

摘要：研究了运营商重构新一代云网协同架构所涉及的关键技术，从架构角度出发，提出了从业务编排器、软件定义网络（SDN）协同器和服务提供者接口（SPI）到云商应用程序编程接口（API）的设计要点。同时，还深入研究了分段路由隧道（SRTE）、虚拟可扩展局域网（VXLAN）、软件定义广域网（SD-WAN）和接入点（PoP）探测等前沿云网网络技术，提出了如何将这些技术进行整合以实现统一SDN的调度和管理。

关键词：云网协同;SDN编排器;SPI;SD-WAN;VXLAN;SRTE;PoP探测

Abstract： In this paper， the key technologies involved in the reconstruction of a new generation of cloud network architecture for service provider are studied， and the design points of the cloud network orchestration， software defined network （SDN） coordinator， service provider framework （SPI）， and application program interface （API） are put forward. The cloud network technologies including segmented routing tunnel （SRTE）， virtual extensible local area network （VXLAN）， software defined wide area network （SD-WAN） and point-to-point （POP） detection are also studied. To realize unified SDN scheduling and management， the way to integrate above technologies is proposed.

Key words： cloud network; SDN orchestration; SPI; SD-WAN; VXLAN; SRTE; PoP detection

云计算这一崭新的计算形态已经被大众所接受，它不依赖单个物理中央处理器（CPU）的纵向计算能力，而是通过网络横向的平台能力使逻辑资源池的使用和扩展更加方便、灵活。从某种技术意义上来看，网络抽象和延展了分布的物理计算资源，云计算的本质就是网络计算。从此，计算和网络原本2个相对独立的创新引擎，在技术能力和规模效益上得以相互借鉴、相互依存和相互激励，双引擎叠加成就了今天信息通信（IT）产业的飞速发展。

计算和网络双引擎叠加该如何实现？网络如何更好地为云计算提供服务和支撑，对于传统运营商來说，还面临巨大的挑战。中国运营商网络能力未抽象，自动化程度低，难以适应互联网业务快速调整的需求;因此，如何实现云网协同，是目前中国运营商、互联网应用服务（OTT）和云商非常关心的话题。近些年，软件定义网络（SDN）技术的出现，给传统运营商带来梦寐以求的、灵活快捷的技术架构;但如何实现在运营商内部大规模运行的骨干网络SDN部署？如何在异构和多厂商环境部署？如何与云商自动化协同对接？这些都是我们需要考虑的问题。我们将讨论运营商重构新一代云网协同架构和技术实践。

1 运营商SDN云网协同架构

的业务需求

基础运营商拥有最丰富的光纤和线路网络资源;但如何通过SDN、网络功能虚拟化（NFV）、云技术或网络新技术整合运营商现有的优势资源（骨干网、城域网、互联网以及各类云资源），加快推动向“新服务”运营商转型，重构网络基础架构，以开放姿态建设未来网络，为用户提供端到端一站式灵活的解决方案，成为了运营商研究的新课题。尤其是新型计算提供商，追求的已是资源秒级响应并按秒计费，而传统运营商还是靠手工或传统方式开通业务甚至以月为单位。如何根本性改变现有业务模式，实现面向云业务的灵活调度、快速部署，也成为运营商关注的新课题。目前，运营商面临着如以下的挑战和需求[1-3]：

（1）骨干网络需要灵活调度、快速部署;因此，运营商需要改变现有业务流程和模式，以满足用户快速灵活的上云业务需求。

（2）运营商大多采用多厂商设备，现有厂商的设备有的不支持SDN（虽可逐步替换，但代价沉重），另外，即使各厂商具备SDN能力，控制器是各厂商私有的;因此，如何实现云网协同和资源统一管理是个巨大挑战。

（3）从运营商的网络接入、骨干到云端，会用到截然不同的网络技术，如何通过云网协同技术实现更贴近用户、更适于跨域部署的云资源布局，让用户可以一点接入、多点部署、全网服务，也需要运营商重点考虑。

（4）重构云网协同架构，需要运营商建立云网一体化新生态。运营商网络资源与各家云商对接上的应用程序编程接口（API）规范和标准差别很大，需要考虑如何采用高效通用的南向接口实现对接。

2 运营商云网协同业务面临

的挑战

近几年来，全球电信业普遍认可基于SDN云网协同技术对运营商的战略意义和商用价值;但是，真正大规模骨干网络部署基于SDN云网协同编排的落地商用方案并不多见，原因在于运营商骨干网SDN的研发和工程实践技术挑战仍然很大。项目从立项到开发的过程面临许多不确定性，导致研发周期延长，从而加大项目的风险。结合大地云网科技过去3年与多种类型的服务商客户的合作及部署的实际经验，我们整理和分析运营商云网业务面临的主要挑战：

（1）异构网络SDN项目技术研发难度大，复杂度高，且无先例。运营商大型骨干网络往往是由不同厂商、不同技术路线和不同产品设备所组成的分布式异构网络系统。在由多厂商高端路由设备组成的骨干网络上完成SDN架构和技术实施仍是世界性的技术难题。SDN的控制、管理、协同和业务编排不仅涉及到不同厂商的不同网络设备和软件架构功能的分工协作，还涉及到运营商的业务、产品、运营和市场等多方面不同需求的满足。网络能力的抽象和模型化技术极其复杂，设计师必须掌握多领域最新技术的系统整合设计，并具有创新实践的能力和经验。

（2）运营商SDN研发项目沟通协调工作量巨大，资源消耗大。众所周知，运营商SDN项目将网络控制、转发和管理平面重新划分与规范，集中与分布控制的机理在运营商现网SDN改造中不仅面临接口多，接口规范不确定、不统一等现实情况，项目研发的沟通协调工作量大，难度大。针对运营商异构网络SDN架构的实施，国际上成功的案例也不多，目前的现状为：多设备竞争厂商的网络设备开发、网络操作系统、SDN的架构、技术路线、软件实现机制、API及软件数据库，以及其研发进度完全不同，常会使得SDN技术架构的设计工作的沟通和协调异常艰难。

（3）项目开发需求多，变化大，风险高，周期长，需有超前的预见性。由于云网协同和SDN项目核心软件的开发和实现会涉及运营商内部多个业务部门，针对这些业务需求，运营商的不同部门在不同时间点可能有不同的理解。SDN软件系统平台研发团队必须确保系统架构对业务的需求变化有一定超前的预见性，否则面对不同需求，SDN软件系统研发容易面临反复修订、更改，从而导致软件系统主要结构和流程的多次更改。这对于核心系统平台的质量和时效都是一种极大的考验[4]。

3 运营商云网协同架构的

设计要点

运营商云网协同架构基于SDN技术，赋能现有骨干网、互联网接入和云网络等，运用先进技术手段重构网络基础架构，与公有云优势资源整合，提供端到端的网络资源自动部署和快捷调度[5-6]，同时提供弹性带宽、自助服务、即时开通的运营服务，为企业客户提供上云服务、跨云的连接（包括数据中心、公有云、私有云）和分支组网等多重场景，包括为用户轻松解决云计算落地“最后一公里”的问题。运营商云网协同架构如何设计？如何确保业务编排、技术架构、技术规范和业务流程等众多方面的合理性和先进性？文章中，我们将针对性地介绍云网协同架构中的几个设计关键点。

3.1 统一业务编排器

统一业务编排器是全网SDN逻辑的核心。如图1所示，编排器具备运营商骨干网完备的业务逻辑，支持多种业务支撑系统接口，并且具备API外部扩展能力，可以定义完整的用户业务流程，具体包括用户业务的开通、生成、下发、计费等，如用户虚拟专用网络（VPN）、终端设备（TE）隧道业务，以及用户云专线等。

统一业务编排器管理和控制全网的设备，展现全局网络流量动态，收集全向网络拓扑，统一呈现网络及设备状态。编排器还实现全网资源统一管理、业务统筹调度与路径优化，统一编排用户上云、云间各种组网的业务流程，为用户提供云网一站式打通。

针对统一业务编排器，我们提出了2点建议：

（1）业务编排器整个系统架构按照业务和功能进行拆分，并基于现有成熟的微服务架构实现最小粒度化的服务模块。微服务可以按需组合完成各类业务场景开通，实现完全解耦的模块化系统架构设计。

（2）统一业务编排器的设计需由具备既熟悉网络的底层架构、技术和协议，又掌握新型云网络技术和软件架构的全栈技术的专业架构师来完成，同时还需要与优秀的系统软件架构师（包括客户和合作伙伴）共同合作。

3.2 优化业务流程

运营商的系统会涉及到业务、产品、运营和市场等多方面不同需求和流程，在传统运营模式下，部门多，环节多，业务周期长，难以适应云网业务的发展。优化系统业务流程在SDN架构设计中至关重要，通过SDN架构重构，抽象业务逻辑，重新定义用户权限与流程，包括运维人员、最终用户、云服务商、客户经理等不同角色账户自服务、业务便捷管理等功能，重新规范运营商的业务流程和自动化以实现运营商业务。

针对业务流程的情况，我们的具体建议为：

（1）运营商需要在需求阶段和甲方一起对流程进行梳理、确认。因流程的更改会导致软件系统主要结构的更改，甚至会导致研发和项目进展出现停顿、瓶颈甚至反复，运营商需要在需求阶段就对流程进行梳理和确认。

（2）软件设计架构尽可能实现微服务和模块化。由于云网协同和SDN项目会涉及运营商内部多个业务部门，业务需求在不同部门、不同时间点可能有不同的理解，因此设计架构上需尽可能微服务和模块化，即使将来流程调整也不至于推倒重来。

3.3 制定SDN协同器和通用服务

提供者接口（SPI）

SDN协同器负责全程全网（物理网络）的统一收集、抽象和组建，需要进行网络资源数据和拓扑的搜集，从而全面掌握服务商的网络资源，包括设备、链路、端口、拓扑等。SDN协同器能够实现网络资源和能力的抽象化、模型化，是业务平台能力和服务支持的基础组件。通过SDN协调器实现物理网络向逻辑网络的转化，并通过兼容各种异构SDN控制器系统与云商API互联，与运营商网络支撑系统对接，从而实现对服务商网络的统一、快捷和安全的控制和管理[7]。

需要指出的是，SDN协调器的能力将受限于其南向的SDN控制器、软件定义广域网（SD-WAN）控制器和运营商网络支撑系统所提供的能力。为避免受南向的SDN控制器和SD-WAN控制器能力限制可能带来的功能限制，SDN协同器应具备通用SDN控制器的基本功能，支持直接配置、控制和管理市场上主流骨干网络设备。SDN协调器模块设计的优劣直接影响业务平台的能力和其未来可持续迭代和扩展演进。

针对SDN协同器和通用服务SPI编排接口，我们的建议如下：

（1）南向面向服务商网络基础设施厂商SDN控制器、SD-WAN控制器以及第三方云平台的配置和管理，需要实现对不同厂家控制器环境业务下发及高可用（HA）机制，实现主/备控制器的高可用HA状態的监测、协商同步和故障处理等。

（2）整合异构厂商设备，实现解耦。多厂商的设备控制器是各厂商私有的，不能兼容其他厂家设备。不同厂家定义的YANG model、命令内容、配置方式，即使是设备命名规则都不相同，要建立一套公认的YANG模型，实现异厂家控制器对接，沟通和技术都要解决巨大困难。

3.4 规范API

云网协同架构为数据中心、私有云、公有云提供了端到端网络接入服务。API的接口规范不仅要满足网络资源的管理和对接，还需要和多个云平台打通并对接，适配多个云平台以及自动化类型的数据中心等可编程平台，为用户提供云网一站式打通。由于不同的云服务商提供的业务形式不同、可编程能力和API规范不同，再加上业务开通上的流程差异，要实现跨云的自动化业务流程，需要面对的挑战是巨大的。

协同编排器API包括北向API网络、南向API网络和东西向集群内网络[8]。

（1）北向API网络：通用控制器系统和统一编排器通过该网络发送和接收北向API的网络业务信息。

（2）南向API网络：通用控制器系统通过该API和南向厂商控制器（或者设备）发送和接收的网络管理信息。

（3）东西向集群API网络：通用控制器系统通过该网络备份数据库数据，发送和接收东西向业务API。

针对API规范，我们的具体建议如下：

（1）云商对接须尽早进行。大部分云商都有各自非标准的API规范，且每个云商的接入方式、路由设计以及API还是有着很大的差别，需有经验的开发人员尽早参与讨论和设计。

（2）云商和运营商的API调用流程须协调好。在资源申请中，运营商是一点登录还是允许云商和运营商多点登录，一定要协调好。如果可以让用户一点接入、多点部署、全网服务，还需要涉及跨域部署的多服务商和多站点云资源布局，这其中的技术也非常复杂。

4 运营商云网协同架构涉及

的关键技术

运营商云网协同架构至少涵盖接入、骨干网和云中心等几个层面，实现从接入到云中心端到端的网络自动化部署和租户的打通，包括端到端统一调度资源、服务等级协议（SLA）服务质量保障、路径规划和VPN安全管理等。这不仅涉及到整体架构的统一规划还涉及到许多的技术实现，如云数据中心网络技术通常以可扩展虚拟局域网（VXLAN）/以太网虚拟专用网络（EVPN）为主，还要考虑Openstack Neutron联动;运营商的骨干网通常以多协议标签交换（MPLS）/分段路由隧道（SRTE）为主，还要考虑2层虚拟专用网络（L2VPN）/3层虚拟专用网络（L3VPN）与云中心租户对接;接入侧传统的城域网或新型的SD-WAN接入和接入点（PoP）探测技术还要考虑与MPLS的混合组网实现。这几个层面须与云网协同统一管理、协同工作，才能真正实现企业客户从选择最佳PoP站点接入到骨干网，并实现上云的端到端业务快速部署，具体

如图2所示。文章中，我们将重点介绍云网协同架构中会涉及到几项关键技术。

4.1 云中心VXLAN/EVPN和云商

对接

随着公有云的真正崛起，SDN作为云网协同的必备技术，其发展经历了从基于Openflow的SDN流派到網络厂商的私有SDN流派，再到后来基于开放VXLAN/EVPN的广义SDN流派。基于VXLAN 的Overlay由于其简单、易扩展等优势已经成为数据中心网络最炙手可热的技术。

VXLAN作为一种网络虚似化技术，采用“MAC in UDP”封装形式，并且基于IP网络实现大二层技术，它是一种用于实现大型云计算和数据中心的网络二层互通技术。VXLAN作为一种数据封装技术，其本身没有控制平面，其在转发数据前的表项学习，如ARP表、VXLAN网络标识（VNI）、VXLAN隧道终端（VTEP）地址等都是通过数据包的泛洪来完成。如果网络中存在大量的泛洪流量，势必对网络的性能有所影响;因此，VXLAN数据转发前表项学习的泛洪流量一开始就是一个重要问题。边界网关协议（BGP）EVPN（RFC7432）标准的出现非常及时，促进了VXLAN的快速发展和普及，并为VXLAN和其他Overlay技术奠定了竞争基础。基于BGP EVPN控制层学习L2和L3的可达信息，通过EVPN完成在VXLAN转发数据报文前ARP表项学习、主机路由学习和VTEP自动发现，VXLAN+EVPN为云数据中心虚拟化、集群和云部署大二层网络夯实网络基础。云中心VXLAN EVPN架构示意如图3所示。

云商的按需自动对接实际上就是把某个用户在云商的虚拟私有云（VPC）网络和在运营商骨干网中开通的3层VPN连接打通。典型的云环境包括基于Host Overlay公有云和基于裸机服务器托管云。目前一般选择VXLAN/EVPN作为底层技术，运营商骨干网一侧会用到基于SD-WAN的MPLS、SRTE的网络技术。SD-WAN到云数据中心SDN网络的统一编排和租户管理，如图4所示。

运营商SD-WAN控制器通过RestAPI与云中心控制器对接。控制器通过企业用户的云平台子账号调用API获取其VPC资源，同时获取租户VPC资源信息并打通网络VPN运营商SD-WAN控制器，负责服务商边缘设备（PE）的租户和VPN对接信息的下发，具体体现为客户端设备（CE）和PE之间三层VPN业务子接口、关联的BGP-VRF会话以及服务质量（QoS）配置等。运营商SD-WAN业务编排器会自动调用云商平台开放API，通过云商SDN控制器打通云中心WAN 路由器和VR路由器的租户VRF对接信息，PE路由器与云中心的WAN 路由器通过VRF自动打通。

针对云中心VXLAN/EVPN和云商对接，我们提出如下建议：

（1）基于VXLAN 的Overlay由于其简单、易扩展等优势已成为公有云数据中心网络的技术首选，SD-WAN基于PE的逻辑子端口VRF与云商对接。虽然在具体技术上相对成熟，但每家云商VPC的结构不一样，实际对接中还是存在很多问题。

（2）针对运营商业务编排器/SD-WAN控制器，我们需要事先和云商协商好调用流程和实现逻辑。云商平台开放API，但每家云商API没有统一标准且差别很大;因此和每家云商API对接是一个挑战。

4.2 骨干网技术：MPLS还是

SRTE

目前，运营商拥有覆盖全国甚至全球的大规模骨干网资源、数据中心资源，传统的手工已经不能满足云的模式，运营商基于SD-WAN的广域网重构项目迫在眉睫。SD-WAN骨干调度核心思想是流量调度和基于多租户的服务和管理，目前主要有3类方式：第1类基于白牌机+Openflow SDN控制器。Google B4就是基于这个方案（2010—2012年），其核心是其TE调度和算法，它巧妙地避开了Openflow的众多缺陷，包括基于源和目的地址配合差分服务代码点（DSCP）作为流表的转发策;但Openflow+白牌机的方案反馈还是有些问题，包括白牌机对 SRTE 支持能力、双向转发检测（BFD）/Tunnel支持性能和数量、路由策略和VPN能力，以及交换机流表和端口缓存的大小等。运营商基本上不会大规模采用Openflow+白牌机方案。第2类基于MPLS +SDN控制器，实现全网的流量调度和VPN租户管理。MPLS TE多年前已开始部署，就目前运营商客户部署情况看，绝大部分抱怨MPLS TE的部署过于复杂;因而真正在生产网TE隧道使用并不多。由于MPLS成熟有余先进不足，运营商将来不会大规模采用。第3类方案是基于分段路由（SR）实现流量调度和管理SR+SDN控制器，该方案也是笔者更希望看到的。和MPLS的网络类似，SR基于源头组建一个完整的分层服务提供商（LSP）路径，而且可以和现有的MPLS网络兼容，只需要对现有的内部网关协议（IGP）进行简单地扩展，就可以实现TE、快速重路由（FRR）、MPLS VPN等功能。目前，基于SRTE的SDN控制器技术在业界属于非常领先的技术，其中SR的基础转发表甚至比标签分发协议（LDP）更简洁，同时还将源路由技术与SDN理念完美结合。在流量TE管理方面，SRTE比资源预留隧道（RSVP-TE）技术流量标签隧道状态的数量少很多，也不像LDP/RSVP信令那么复杂，目前各个厂商新一代的路由設备基本上都支持SRTE。推荐运营商采用SR+SDN重构新一代的骨干网实现流量调度和管理。基于SRTE SDN控制示意如图5所示。

针对骨干网技术，我们的建议如下：

（1）尽管SRTE技术优势比较明显，但目前各个硬件厂商（包括第三方控制器+SR路由器）在SRTE具体实现还是有一定差距，有几点是设计部署时需要考虑的：如何根据链路质量（load/loss/delay）动态实时调整TE路径以实现全局负载均衡、隧道快速倒换策略和逃生算法（如思科PBTS技术）、配置回滚的一致性、离线流量规划、TE路径的对称故障检测等，各商家的方案功能差别比较大，在中国能真正完整实现基于SRTE的SDN控制器更是屈指可数。

（2）对于运营商和云服务商，我们都希望能够基于标准的南向支持NetConF/YANG等协议控制和管理多厂商网络设备。在开源和开放的大趋势下，各个厂商都宣称支持SRTE和NetConF以及开放北向API等。中国运营商如联通已经成功部署基于多厂商SDN协同编排器，利用统一协同编排器实现多厂商设备的解耦，整合异构多厂商设备，开创了异构环境下多云互联的先河。

5 SD-WAN接入技术

随着企业上云和广域网按需接入的需求日益增加，传统的MSTP和MPLS等专线业务由于成本高、部署周期长等问题已难以满足云和互联网时代的需求，面向基于互联网和PoP探测选择的SD-WAN技术随之诞生。SD-WAN就是一种面向分支灵活接入的部署场景，在其设计和部署时，我们需要考虑南北运营商Internet瓶颈的问题，并会选择在各地的多个机房部署多线PoP节点。在PoP层解决了跨运营商互通提升互联品质，POP之间构建了专线骨干网，以确保SD-WAN远程传输业务品质。由于目前中国运营商MPLS VPN网络已大规模部署，运营商须要考虑把MPLS VPN的PE和租户VPN集成到SD-WAN系统中。此时，各个PoP节点的虚拟服务商边缘设备（vPE）/网关（GW）需要与运营商MPLS网PE节点对接，并通过OptionA/OptionB 或纳管等方式统一管理。这种架构能有效提高网络性能和混合组网能力，特别是各种高服务级别的实时流量，而且可方便实现SD-WAN与运营商骨干网MPLS对接。SD-WAN具体技术实现如图6所示。

针对SD-WAN技术，整合SD-WAN架构兼顾运营商MPLS/SRTE骨干网，真正实现为客户提供全国范围内集MPLS VPN、IPSEC VPN、SD-WAN等多种应用的WAN解决方案，解决运营商“最后一公里”的难题。

（1）由于打通了MPLS租户VPN与SD-WAN租户VPN（也有称之为“混合架构”能力），该架构非常适合实现骨干网、SD-WAN与主要云运营商对接，开展云联网业务

（2）运营商在部署这种架构时，建议将SD-WAN接入控制器和骨干网控制器整合。整合的控制器将MPLS 服务商PE节点统一纳管。这样在开通VPN业务时就可以实现完全的业务自动化

6 结束语

新型云服务商追求资源逻辑管理和秒级响应， 传统的运营商网络已无法支撑业务的弹性和快速增长。云网协同和SDN技术的出现，将整个物理网络抽象并简化为“单一”逻辑网络资源池，并通过软件定义用户业务的自动化流程，实现多个系统联动，完成业务端到端快速自动部署。这些年来，中国运营商已开始在大规模运行的骨干网络中进行SDN重构，拥抱多云互联的时代。个别运营商已实现多厂商异构环境SDN实践部署并取得宝贵经验。但对于中国运营商的骨干网络，在实现SDN转变时还面临巨大的挑战，如：运营商缺乏SDN技术和架构，没有标准规范，各个厂商设备实现方式非标准，多厂家异构设备管理，业界实践经验不多等。在中国，SDN网络技术作为开放软件架构，在开放性、通用标准和互操作方面还有很多路要走，但无论如何，SDN和云计算作为未来IT发展的2大最基本的创新引擎，其发展势不可挡。相信不远的将来，SDN与云计算相结合的云网协同将会给运营商、云商和客户带来一片新的天地。

參考文献

[1] NADEAU D T， GRAY K. SDN： Software Defined Networks [M].USA： OREILLY， 2014

[2] FILSFILSM C， MICHIELSEN K， TALAULIKAR K. Segment Routing Part1 [M]. Beijing：

China Industry and Information Technology Pushing&Media Group， and The People's Posts and Telecommunications Press， 2017

[3] BGP MPLS-Based Ethernet VPN-EVPN [EB/OL]. [2019-01-18].

https：//tools.ietf.org/html/rfc7432

[4] IETF. BGP MPLS-Based Ethernet VPN：RFC 7432 [S].2015

[5] Segment Routing Architecture [EB/OL]. [2019-01-18].https：//tools.ietf.org/html/rfc8402

[6] IETF. Segment Routing Architecture： RFC 8402[S].2018

[7] Virtual eXtensible Local Area Network （VXLAN）： A Frameworkfor Overlaying Virtualized Layer 2 Networks over Layer 3 Networks [EB/OL]. [2019-01-18].

https：//tools.ietf.org/html/rfc7348

[8] MAHALINGAM M， DUTT D， DUDA K， et al. Virtual eXtensible Local Area Network （VXLAN）： A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks[R]. RFC Editor， 2014