SDN和NFV网络部署分析

陈 冰 南福星 杨绍光 王 翔

1 中国联合网络通信有限公司 北京 100033

2 中国联通研究院 北京 100032

引言

SDN[1]和NFV[2]是近些年来网络发展较为热门的技术。经过几年的发展，SDN和NFV对网络变革产生的价值得到了清晰认识和广泛共识，这两项技术逐渐迈过炒作阶段，进入规模化部署阶段：SDN部署的急先锋Google已基本完成其数据中心网络的SDN改造，在开放网络峰会上并没有进一步展示其关于SDN的新应用场景；公有云巨头微软和阿里巴巴则分享了他们关于SDN在云服务上的实战经验；而电信运营商AT&T也宣布继续推进其网络向SDN转型的Domain 2.0计划[3]，基于SDN的“Network on Demand”解决方案衍生的“Switched Ethernet”服务已在全美100多个城市得到部署。

从宏观上说，SDN最重要的价值就是将网络从上到下自动化打通，并且提供近乎实时的按需网络路径调整能力，大大提升自动化能力，提升网络能力提供的效率。NFV则提供了基于通用服务器标准硬件的标准运行环境，使网络业务基于此标准运行环境进行开发和集成，将软硬件紧耦合系统工程转化为软件系统工程，大大缩短业务上市时间，提升业务部署效率。如同智能手机取代功能机一样，SDN和NFV所产生的效率提升是明确的，必将是未来建设网络的核心技术。

在具体部署过程中，SDN和NFV技术高度互补，但并不相互依赖。NFV可以不基于SDN技术进行实现，然而两者相融合则可能产生更大的潜在价值。利用数据中心现有的技术，NFV的目标可以基于非SDN的机制而实现。SDN所提出的控制平面和数据平面解耦的思路，可以进一步提升现有部署服务的性能并简化其互操作性，减轻运维负担。NFV能够为SDN软件提供其运行所需要的基础设施。此外，NFV与SDN的目标都是尽可能使用通用/白牌服务器/交换机来实现功能，图1展示了SDN与NFV在网络服务上协作互补的关系。SDN只有拥抱NFV，才能完善自己。没有NFV，SDN停留在网络拓扑和控制决策层面，没有灵活的资源可供调度，网络高层功能的实现会成为绊脚石；没有SDN，NFV停留在软件化和虚拟化层面，无法灵活地按需提供服务。只有两者相结合，NFV的功能才能更加丰富，SDN的控制功能才更显强大，网络才能真正“活”了，也才可能变得更有智慧，最终使网络成为服务。

图1 SDN与NFV的关系

1 SDN/NFV在数据中心的部署

考虑技术的成熟性、网络的平滑演进，SDN和NFV的部署需要一个循序渐进的过程。SDN和NFV涉及的范围非常广泛，先期的部署需要找到一些突破口。局部的、新兴的、层叠的网络是最容易实施的地方。结合云网络多租户需求，DC的虚拟化，VDC成为SDN和NFV实践的第一个理想的实验场景。不同于传统数据中心，云计算以“租用”的方式改变了数据中心内IT资源的交付手段。租户对资源“按需申请”和“按使用付费”，使得部署在云数据中心网络中的计算、存储和网络资源处于持续改变的状态。图2展示了单个租户所看到的VDC业务部署的拓扑。由于租户之间是相互隔离的，因此，其它租户的网络业务在该图中并不可见。每个租户能够独立请求一个或多个虚拟的L2网络，并在此基础上构建一个L3网络；不同租户在其L2和L3网络中可以共享使用所有可用的地址空间。所有L3网络的子网可以通过一个服务网关互联，而该网关同时也是租户云端网络接入Internet的网关；租户可以在该网关上部署子网间以及Internet接入的网络安全或服务质量策略。这些网络元素都是经过虚拟化之后与物理网络元素相分离的，能够根据租户的需求按需启动和部署。

图2 VDC租户网络拓扑

VDC里面，Overlay方式的虚拟网络又是被最先选择的方式[4]，因为Overlay方式最容易实现实际部署。用于数据中心网络虚拟化封装的协议主要有三个，即VXLAN，NVGRE和STT。它们在设计上的相同之处就是将虚拟网络由全局唯一的ID进行标识，并打标进数据平面网包的封装格式中；这三者仅在封装格式和少部分实现细节上有所区别。当前开源OpenStack已成为云网络事实管理系统，VDC内部SDN控制器通过Openflow流表模型，对上为OpenStack提供网络服务，对下对OVS和Overlay网关进行管理，构成VDC内完整解决方案，支持多租户的云应用，也支持NFV业务功能虚拟化，形成一套基础环境。图3展示了经过VXLAN封装的数据包流经网络路径时的变化。从图3可以看出，不同的虚拟网络在VXLAN协议中是通过VNID来进行标识，由UDP协议进行封装的。虚拟机发出的原始网包为标准的以太网格式，在VTEP(软件交换机或机架顶交换机)进行VXLAN封装。封装之后网包的L2和L3层地址分别为源和目的VTEP的地址，而原始网包作为UDP的载荷被封装进行传输。

图3 基于VXLAN的网络虚拟化封装

目前，主要运营商都在进行类似方案的试点，这将逐步形成云应用的模式和业务功能虚拟化的模式，对未来有较深远的影响。但这只是起点，在此基础上，云应用将得到很好的支撑，同时，NFV虚拟化使得安全、智能的工作比以前或得到更好的实现，各类安全组件以软件模块形式存在，各类智能应用以软件模块形成编写调整，通过很好的集成工作可以快速定义、上线和提供业务，并且能够支持业务快速地迭代升级。在提供很好业务的同时，SDN基础设施能力也将逐步演进，从Overlay模式开始逐步硬化转发能力，最终螺旋式演变回具有更高性能支持的Underlay原生模式，但是功能将更加丰富，并覆盖原来Overlay定义时所增加的各类功能。

2 SDN/NFV在广域网的部署

对于城域网、骨干网等广域网络，由于牵涉地域广泛，管理域复杂，实际操作起来难度要大很多。城域网、骨干网以提供连接为主，因此，牵涉到的主要是SDN的工作。在广域网场景，SDN强调更多的是面向连接的演进，在数据模型上会面向连接，而有可能并不实现流表。在南向协议上，除了Open fl ow细颗粒度接口以外，也会选择BGP-LS、PCEP、NETCONF等粗颗粒接口，这些粗颗粒接口有时在广域网上效率可能更高，使得实际操作性能得到保障。在广域网上，端到端地对某一连接属性进行控制有一定的应用价值，具体地来说，比如VPN连接、优化的流量路径[5]。

为实现对大网管理，广域网的SDN控制器需要分层[6]，最基本的层次是厂家单域控制器，其上是通用单域控制器，再其上是层次化多域控制器。为避免厂商绑定，需要在单域控制器以上定义通用接口。在产业链还没有足够成熟的时候，往往需要运营商和供应商共同协商制定通用接口。基于这样的通用接口，要进行开发和对接测试，测试通过后要进行跨域的试点，然后在小规模范围内试用。实际试点操作时，会遇到既不支持也难以升级到SDN的传统网络，这时需要使用Overlay技术，使SDN穿越这些传统网络，实现需要的端到端业务功能。广域网的规模很大，这样的试点需要做好全局协同，或者就定位为小范围的试验网。

在广域网上，即便单域和多域控制器组合得很好，离应用和部署还有很大的距离。最关键的距离就是如何将OSS/BSS系统以演进的方式与SDN控制器连接起来，中间需要一个编排层[7]，编排层进行语言的转化，把业务需求转化为SDN控制器认识的网络需求，同时，对虚拟化网元进行生命周期管理。编排层对一个大的运营商来说非常重要，它很好地解释了业务对网络的需求，并很好地进行虚拟网元和SDN连接的串联，使得智能化的业务能很好地实现。行业的一些开源工具如TOSCA，一些思维方式，如NETCONF/YANG方法值得在应用时考虑。

由于广域网的SDN化是一个巨大的系统工程，大型的运营商需要启用从上向下的设计，从OSS/BSS为起点，向下将编排器、层次化多域控制器、单域控制器、厂商单域控制器、厂商设备串起来，打通之后才能对端到端业务部署提供积极的作用。运营商和设备厂商需要通力合作，才有可能把系统定义和部署好。另外，即便在模型定义得很完善之后，实践仍是第一位的，需要在小规模试点应用中积累经验，逐步将网络应用规模扩大。对于中间无法进行SDN协同的传统网络，积极采用Overlay或打隧道方式穿越，不必等万事具备，才开展相关工作。只有SDN的网络规模不断壮大，最终才可能实现全网的SDN化。

在广域网SDN试点和建设过程中，为VDC服务始终是重点需求之一，因为VDC发展迅速，VDC之间互联对广域网有一定的需求，广域网SDN在解决VDC互联过程中，也实现自身支持功能的完善，从而实现更好地发展。在广域网SDN发展过程中，面向连接是最基本的需求，此后，针对不同的需求，还会出现其他的软件定义，如SDN SFC[8]的支持，将为NFV提供必要的更好的连接支持[9]。

下面针对SDN在广域网上的部署应用，分别选取了AT&T和Google作为运营商和互联网企业的代表，分析它们在SDN应用上所做的工作和取得的成果。

图4 随选以太网服务部署模式

图5 NetBond VPN服务部署模式

国际领先的运营商AT&T基于SDN技术推出随选网络(Network on Demand)业务[10]，通过在线自助服务门户将网络服务交付给商业客户，客户可以通过该门户实时地订购、添加和更改自己的网络服务等级和扩展带宽等，从而灵活实现服务变更，更好地适配业务并优化成本。其中，以太网服务允许用户连接两个或多个独立的以太网，形成一个单独的网络，带宽支持达1～10Gbs。图4展示了随选以太网服务的两种部署模式，即“单点-多点”和“多点-多点”两种常见的企业网络架构。此外，NetBond VPN服务面向企业客户提供MPLS VPN与各数据中心之间持续、安全的互联，使得网络和计算资源可以弹性串联，以支持系统的波动需求。图5展示了随选VPN服务的部署模式。

在流量路径优化的应用上，做的最出名也最有特色的是Google的B4。由于SDN能够实时监控并动态调整网络带宽和路径，传统通过静态带宽预留方式保证服务质量的做法显得极其低效和僵化。Google广域网的出口设备有上百条对外链路，分成很多的ECMP负载均衡组，在这些均衡组内的多条链路之间用的是基于静态Hash的负载均衡方式。由于静态Hash的方式并不能做到完全均衡，为避免很大的流量被分发到同一个链路上导致丢包，Google不得不使用过量链路，提供比实际需要多得多的带宽。这导致实际链路带宽利用率只有30%～40%，且仍不可避免有的链路很空，有的链路产生拥塞，设备必须支持很大的包缓存，成本太高，而且也无法对上文中不同的数据区别对待。从一个数据中心到另外一个数据中心，中间可以经过不同的数据中心，比如可以是 A→B→D，也可以是A→C→D，也许有的时候B很忙，C很空，路径不是最优。除此之外，增加网络可见性、稳定性，简化管理，希望靠应用程序来控制网络，都是其网络改造的动机之一。以上原因也决定了Google这个基于SDN的网络，最主要的应用是流量工程，最主要的控制手段是软件应用程序。图6展示了Google B4网络的整体架构。

图6 Google B4网络的整体架构

3 总结

总结起来，SDN和NFV是网络发展明确趋势；数据中心网络以VDC和虚拟化为核心，OpenStack、SDN和NFV技术迅速得到应用，形成未来业务系统基础；广域网络复杂度很高，不仅需要多层控制器协同，还需要OSS/BSS与编排器和控制器的协同，大型运营商需要实施自上而下的设计，并推动局部试点，以逐步形成规模应用。在SDN和NFV的部署过程中，两者需要紧密配合协同工作，才能产生良好的性能与效益提升。但是SDN与NFV架构的核心——控制器的发展仍不明朗，分别代表运营商和设备厂商的ONOS和OpenDaylight仍然在争夺主导地位；各厂商对SDN的支持程度也有差异，实现协同操作还有一定难度；NFV设备相比SDN设备，其标准更加难以建立，其实现方式也更加碎片化；同时，SDN和NFV的集中控制方式及开放性将使得网络架构的安全性成为潜在风险，这些都将是未来SDN和NFV发展中需要研究和解决的问题。

参考文献

[1] Software-Defined Networking:The New Norm for Networks[EB/OL].[2016-01-08].https://www.opennetworking org/images/stories/downloads/sdnresources/white-papers/wp-sdn-newnorm.pdf

[2] Network Functions Virtualisation[EB/OL].[2016-01-08].https://portal.etsi.org/nfv/nfv_white_paper.pdf

[3] Domain 2.0 White Paper[EB/OL].[2016-01-08].https://www.att.com/Common/about_us/pdf/AT&T%20 Domain%202.0%20Vision%20White%20Paper.pdf

[4] Koponen T,Amidon K,Balland P,et al.Network Virtualization in Multi-tenant Datacenters[EB/OL].[2016-01-08].http://www.docin.com/p-1476505232.html

[5] Jain S,Kumar A,Mandal A,et al.B4:experience with a globally-deployed software defined wan[EB/OL].[2016-01-08].http://www.medsci.cn/sci/show_paper.asp?id=9e6d4390449

[6] S Hassas Y,Ganjali Y. Kandoo:a framework for ef fi cient and scalable offloading of control applications[EB/OL].[2016-01-08].http://conferences.sigcomm.org/sigcomm/2012/paper/hotsdn/p19.pdf

[7] Berde P,Gerola M,Hart J,et al.ONOS:towards an open,distributed SDN OS[EB/OL].[2016-01-08].http://www-csstudents.stanford.edu/～rlantz/papers/onos-hotsdn.pdf

[8] Service Function Chaining[EB/OL].[2016-01-08]. https://datatracker.ietf.org/wg/sfc/documents/

[9] Qazi Z A,Tu C C,Chiang L,et al.SIMPLE-fying middlebox policy enforcement using SDN[EB/OL].[2016-01-08].http://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p27.pdf

[10] AT&T Network on Demand[EB/OL].[2016-01-08].http://about.att.com/innovation/showcase/networkondemand