在业务类型多样及流量需求规模巨大的情况下，DCI（Data Center Interconnect，数据中心间网络）主要存在如下挑战：
- 大二层的实现要求跨数据中心间VM-to-VM的业务流量能够像数据中心本地的流量一样得到无阻塞的传输。数据中心间的专用WAN链路往往带宽有限，而专用WAN链路扩容太慢，只能超额认购难以实现按需租用，或者通过走公网VPN进行流量高峰时的缓解。
- 为保证业务的连续性，专用WAN链路往往采用主备份的方式，备份链路的闲置使得WAN链路的利用率十分低下，进一步提高了数据中心的运营成本。
- 最优业务路由与WAN路由有巨大出入。不同优先级的业务对传输的需求大不相同，比如VM迁移流量对时延敏感，而数据备份流量对时延要求很低，传统的WAN路由缺乏全局的调度机制，难以实现业务层面的传输优化。
- IP层和光层缺乏协同。广域网传输是Multi-Layer的，IP网Overlay在光网之上，这两套网络的技术体制完全不同，一般是懂IP的人不懂光传输，懂光的人不懂IP业务，如何能协同起来两套网络是一个巨大的问题。
显然，SDN灵活、自动化的特点与全局调度的能力，为解决DCI存在的上述问题提供了不二的选择。从商业模式来讲，SDDCI大概存在两种形式，第一种是像Google、FB、BAT这些互联网巨头或者一些大型的IDC，他们通过批量租用运营商线路或者自建线路，自己来设计方案调度DCI流量。第二种是一些SDN公司，他们形成DCI解决方案，与运营商合作向数据中心提供DCI服务。第一种模式下，我们先来介绍Google B4和腾讯的TE方案。第二种模式，国内目前估计只有华为在做，本节后面会简要介绍一下国外CYAN的BluePlanet。
1）Google B4
Google B4是SDN最为成功的案例，它基于OpenFlow较为完整地实现了DCI间的流量工程，成功地将B4中平均链路利用率从30%提升到70%，甚至在很多链路中能够接近100%。Google的这一尝试建立在Google在全球光纤网络的巨大投资上，使得在很多技术的选择上可以采用更为激进的方案，而从其实际的效果来看，B4证明了OpenFlow并不是一个只能在小范围玩玩的过家家的技术，为OpenFlow的可商用化做出了有力的、先驱式的表率。Google B4的部署情况如下图所示。
组网体系架构上，B4各个DC域内由NCS集群进行控制，域间则采用层级化的控制器完成全局拓扑的采集与TE算法的实现。NCS的具体实现中，Qugga运行传统的BGP/ISIS路由协议计算域内域间路径，并通过OFC APP（RAP）将这些路径注入到OFC中，OFC负责与OF Switch交互OF信令，根据RAP路径下发流表指导OF Switch转发数据包，当然了BGP和ISIS的信令也是通过OFC送到数据平面上去的。全局控制的实现中，Gateway负责收集全局拓扑，TE Server接收拓扑以及业务优先级等TE参数作为输入，运行TE算法得到DC间流量调度的结果，通知各个域NCS中的TE Agent，由各个域内的OFC转化为流表其下发给DC边缘的OF Switch。这些TE流表采用IP-in-IP Tunnel完成DC间的传输，不同业务流量会被分配到不同的Tunnel上以实现流量调度与负载均衡。为了不产生冲突，这些TE流表的优先级要高于RAP路径流表的优先级，计划被调度的流量会先匹配上TE流表从而得到特定的处理。
B4的实现是一个巨大的系统工程，设计复杂的TE算法和高可用机制，上述只是把其基本的原理和框架介绍了一下，有感兴趣的读者可以直接看论文《B4: Experience with a Globally-Deployed Software Defined WAN》，国内有人详解过这篇论文，可参考http://www.sdnap.com/sdn-technology/3665.html，感谢这些前辈们为SDN做出过的贡献。这篇论文是13年的Sigcomm，据了解Google这两年和未来的几年内仍会沿着这个路子在DCI上进行巨额的投入。
2）腾讯的TE方案
腾讯在BAT三家中的SDN之路走的最为靠前，尤其是在DCI的SDN化上面，早在两三年前就已经看清了这个方向，联合华为一起实现了一套比较完整的DCI解决方案。相比于Google，显然腾讯没有这个魄力去自建自营大规模的光纤网络，于是腾讯退而求其次向运营商租用了大量专线，放弃了OpenFlow而转向了当时新兴的、还不为人所熟知的PCEP，现在PCEP逐步走入了大家的视野，事实证明腾讯在当时的选择是具备一定的技术眼光的。
PCEP（Path Computation Element Communication Protocol，rfc5557）是一种专用的计算路径的协议。PCE是专门进行路径计算的网络单元，当接收到PCC（Path Computation Client，路径计算客户端）的路径计算请求时，能够利用已有的网络拓扑信息计算一条满足约束条件和策略的端到端路径。PCE技术的本质，实际上是将路径计算从传统的路由功能中提取出来，实现了路径计算与路由信息交互在功能上的分离。而PCEP就是用于PCE与PCC/PCE之间通信的协议，其具体工作原理如下图所示。
由于PCEP不要求对设备硬件进行改造，因此是一种比较平滑的、广义的SDN技术，目前很多传统的WAN设备，包括IP/MPLS路由器以及各类光交换机，都能够支持PCEP接口。但PCEP的问题在于它只能完成路径计算，本身并不具备探测拓扑的能力，因此控制器一般都需要配合一些拓扑发现的南向接口向PCEP提供拓扑的输入。BGP-LS（IETF Draft，https://www.ietf.org/archive/id/draft-gredler-idr-bgp-ls-segment-routing-extension-02.txt）是目前比较典型的拓扑搜集协议，它通过对BGP的扩展来获得OSPF、ISIS等链路状态路由域内的拓扑，腾讯即采用了PCEP+BGP-LS的组合来完成南向与设备的交互。腾讯有一张胶片清晰地表达了这一技术架构，如下图所示。
从系统设计来看，腾讯的实现与Google B4也有所区别，因为腾讯是租用的ISP的设备和链路，因此它的TE优化只是发生在ISP的网络设备上的，TE控制器直接通过PCEP与设备通信，不存在B4的层级化控制器设计的需要。算法上采用了CSPF，利用TED中的数据来计算满足指定约束的路径，数据平面通过RSVP去预留DCI路径资源。
2013年6月，腾讯SDDCI项目启动，2015年初上线部署。腾讯的SDN之路走的一直很积极，前一段时间牵头举办了第二届开源SDN/ODL实战集训营暨黑客马拉松，我有幸参加了这次培训，期间的经历让我觉得腾讯确实在SDN方面投了巨大的人力，最近听说又成为了OpenDaylight的白银会员，希望鹅厂能形成更多的SDN解决方案为中国的互联网巨头们做出表率。
3）CYAN BluePlanet
国内SDN最近两年才看到落地和商用的影子，不过老外们可是又一次远远地走在了我们前面，早在2010年以前国外就开始有SDWAN创业公司去探索DCI的SDN解决方案。CYAN就是其中的一家，它的BluePlanet平台提出了完整Enterprise-WAN-DC的控制+编排的SDN解决方案，2013年获得了《亚洲电信》杂志评选的“软件定义网络年度创新奖”。相比于Google和腾讯这些互联网公司，显然CYAN这类SDN科班出身的要更为专业，其SDDCI的解决方案提供了能够支持SDH、TDM、DWDM、IP/MPLS，Carrier Ethernet，OpenFlow等多种技术体制，提供了Multi-Layer，Multi-Vendor的能力，BluePlanet SDDCI整体解决方案示意如下。
CYAN通过在DC边缘部署GW和CPE，利用 ISP现有的PTN和OTN网络来实现DC互联。关于CYAN的DCI技术架构，下面第一张图是DC-to-Enterprise的示意，其实与DC-to-DC类似，第二张图是DCN的示意，端到端非常清楚，就不再过多地解释了。
从接口方面来看，BluePlanet主要采用了PCEP，辅以NETCONF、SNMP等多种网管配置协议。从系统设计来看，除了DCI的功能以外，BluePlanet实现了与OpenStack的深度融合对接，使得跨DC的端到端编排成为了可能。最后我只想说，不谈技术，BluePlanet的UI做的真的是让人叹为观止。
SDDCI就简要的介绍到这里。在国内SDDCI才刚刚起步，相信未来几年内会有爆发式的增长。
作者简介：
张晨，北邮研究生，北京邮电大学信息与通信工程学院未来网络理论与应用实验室（FNL实验室），网络与交换技术国家重点实验室
主要研究方向：SDN、虚拟化、数据中心
个人博客：sdnv.xyz
个人邮箱：zhangchen9211@126.com
