大家好！首先自我介绍一下：我来自中国电信广州研究院，我和我的SDN小组是一支来自电信运营商的研发团队，主要从事一些预研性的研究和开发工作。大家可能是从最近的一本关于ODL的新书《OpenDaylight应用指南》中了解到我们在ODL方面做过一些工作，我这里想说的是，我们的工作在整个运营商的SDN/NFV研究拼图中只是很小的一部分，因为这里涉及到宽带IP网、移动网、传输网、接入网、终端、BOSS等各类专业领域的向SDN的演进问题，今天我们没法在这里展开讲，只用一张图来表明一下相关的工作基础和广域网SDN控制器的选型背景。

从图中可以看到，整个IP运营网络分为接入网、IDC、城域网、移动分组域、IP骨干网、运营支撑系统几个部分，实验和试点工作几乎覆盖了整个网络领域，既包括基于传统网络和SDN集中控制思想的骨干网、DCI和IP RAN等环境的流量优化调度，也包括接入/城域网的网元虚拟化等等，说明运营商对SDN/NFV的需求是全面的、庞大。同时，传统网络与新型SDN/NFV设备共存、新型控制平面与传统承载控制平面共存也引入了演进问题。这张图有两个关键词：网络庞大、新旧共存，这是对SDN控制器应用环境的初步需求。按我们的理解，运营商广域网SDN控制器为保证专业性和兼容性，需要提供两方面功能：

其一，专业功能。随着我们对控制器所应用的场景和专业领域的进一步细分，可以用2个维度对控制器的专业功能进行描述，一个是控制平面采用的技术，包括：基于传统路由控制平面的SDN过渡技术、NFV控制面技术和OpenFlow技术（这几种技术可以共存于同一个控制器）；另一个是功能场景维度，例如：EPC、IPRAN、***、TE、DCI等等，运营商对于SDN控制器的专业功能需求是非常丰富的。

其二，通用功能。作为一个大型运营级控制器及其控制平面，还需要提供良好的软件实现架构和扩展性，这点是以往电信产品所欠缺的，以往的电信产品只画过功能架构，没人认真考虑过一个软件的可实现性和实现架构，同时也需要从IT技术中引入HA、能力开放、接口抽象、模型化、自动化部署等大量新技术。

理解了上述问题，就不难理解为什么运营商和传统的Vendor都会不约而同地选用ODL这类大型的控制器，它绝不是 “OpenFlow控制器”或者“承载－控制相分离”所能覆盖的。我们之前也认真分析过其它一些SDN控制器，如floodlight和OpenContrail，OpenContrail中采用的技术令人印象深刻，不仅网络功能强劲，也让我们了解到如何在实现架构中引入大量IT开源新技术对复杂的网络进行配置和管理。同样，大家也知道，2013年以前大家讲控制器都是在谈OF控制器，而今floodlight等单一OF控制器正在逐步淡出运营商的视野。

举几个例子大家就容易明白：我想在传统IP网做一个流量优化调度，可以无需OF设备，只需用ODL的BGP-LS模块采集链路状态或者BGP路由，通过BGP（或者BGP改进）来下发路由策略，这个场景可以在DC出口，也可以在城域网出口或者国际网络；又如，我想在IP网络边缘部署vDPI等NFV设备，可以用ODL的业务链插件来实现主要的配置功能；再举一例，某用户擅长做IP RAN网络的业务开发，但不擅长做HA架构和PCEP/OF等接口，也不知道该如何开放出API，此时可以借用ODL的通用功能，用户只需专注于IP RAN的plug-in能力就可以迅速完成整体控制器开发，如果恰巧运营商已经使用ODL平台，该用户只需做好plug-in并与运营商控制器进行集成。

这些都是我们已经看到的和亲身感受到的ODL这类开源平台的明显优势，一种是软件架构的优势，包括：基于OSGi的可裁剪软件框架、MD-SAL的资源抽象、YANG模型与YANG tool提供的北向接口开放性（基于YANG定义文档，用户就可以在预研阶段定义出功能标准和API）、集群/LB能力；另一种是功能性优势：集成了BGP/IGP、LLDP资源发现、NETCONF/OF/SNMP等大量新老协议族，以及资源模型化、策略管理等。ODL最大的特点是，在这个平台上，用户的开发工作量明显降低，系统开放性好。据我们了解，大多数公司初次接触ODL后均能在3－6月内快速做出一个产品原型。

当然，我们自己和不少朋友也都在抱怨ODL里面“坑”不少，很多主线项目从安装调试，到代码和文档都存在问题，也有人诟病ODL对运营商网络领域的问题聚焦不够、运行性能低下等问题，但我相信，只要社区保持较高热度，通过快速迭代这些问题迟早会解决，我所在的ODL顾问组，每月都有例会，平时邮件也很频繁，主要讨论功能特性排序、开发/测试问题报告、案例分享，我们可以观察到社区已走向正轨。同时，社区的快速成长减少了未来控制器领域技术垄断的可能，也促进了可能的商业版的统一性，正如今天Openstack社区所形成的格局，而传统网络供应商依然可以通过控制器专业功能和VNF获得新市场。

ODL社区的项目从早期氢版本的十几个发展到现在70多个，初期知道ODL controller、MD-SAL和L2 Switch几个模块以及YANG Tool就能动手搭建一个系统，而今从AAA到VTN和SFC等大量模块的存在，新用户需要聚焦就非常困难。随着ODL应用场景的扩展，我相信已经很少有人能达到所谓全面掌握的程度，毕竟术业有专攻，即使是网络工程师，也有传输、宽带、移动、终端等不同的专业分工，这都会给初学者带来不少困惑。从我们的经验看，如果您只是对专业网络问题感兴趣，经过对核心模块和架构有一定了解后，就可以集中精力在ODL部署和专业功能项目上，如BGPCEP，并参与到社区项目的开发工作，更有可能是您需要自己设计一个专业场景下的ODL plug-In。对controller等通用功能的改动会面临未来ODL版本升级的风险。

下面介绍一下我们自己将ODL应用于IP广域网的开发和IP智能边缘业务链PoC，这个PoC是2014年开发的，详细的细节可以参考我们的新书，这里只概括一下。由于是一个NFV业务链，光做一个ODL控制器无法实现这个功能，需要三个层面的开发：用于资源管理和用户管理的编排器、用于物理网络和虚拟网络控制的SDN Controller以及与现网的运营支撑系统接口层、支持高性能NFV的转发层。同时，我们最终移除了Openstack组件以简化架构，直接用Qemu管理KVM虚拟机，如下图：

我们在编排层做的工作称为SCP（业务控制平台），这一块的开发难点是用户Session的管理、业务模板定制、资源监控及其可视化管理、OSS接口，这块工作的基础来自于我们以往在运营商承载控制平台方面的积累。

而在SDN控制器方面由于有ODL的支持，我们可以很快在氢版本上做出控制器功能架构，并通过YANG文件快速定义转发策略配置模块、业务链管理模块的功能，通过maven和YANG Tool将上述文件自动生成为API和模块的代码框架，将控制策略转换为OpenFlow流表或转发表。并通过OpenFlow模块控制SFC转发层流表，通过Netconf模块配置转发模块和DPDK加速环境，核心功能非常简洁清晰。缺陷是由于初次接触，花费了大量时间学习使用和修改bug。另外，我们也与Intel、华为等公司合作，加入到部分项目，学习到很多经验。

在转发层，我们做的工作主要是支持NSH封装、流分类、转发图加载，开发的难点是实现基于DPDK的NFV加速层和我们自己提出的PF可编程转发能力，通过这两方面能力共存可以实现NFV设备的高性能灵活转发能力。

目前，对ODL的通用能力方面我们已经较少关注，仅保留控制器集群、功能可裁剪性的评测，更多精力是重点关注和参与专业项目，如BGP-FS扩展、策略控制、业务链SFC、OVSDB等等。

最后，介绍一下我们的ODL新书——《OpenDaylight应用指南》。该书主要面向初学者和中级技术人员，以及一些没有时间但需要快速了解ODL社区及其项目的专业人士。ODL项目介绍的内容来自社区官方文档，大部分项目经过我们的编译调试和试用，但不是完备的测试，书的后半段是我们的开发实践，不仅仅是控制器，也包括了一些编排和转发层的开发工作，这些工作应理解为概念验证而非产品实现。

从开始有想法到最终面世，该书前后历时近9个月，作为一种新技术传播方式，在当今无疑是比较慢的。这其中的周折在于，开发用的是氢版，开发后期换成氦版，从AD-SAL到后来MD-SAL，不得不重新理解和改进核心代码，而当书开始动笔时，又经历了锂版本发布，社区项目和文档变得面目全非，陡增了数十个项目，不得不重新整理。与锂版相比，书中介绍的项目并不算多，一方面正如前面所说，无人能精通所有项目，我们只能选择我们理解的和有兴趣的项目。因此希望大家谅解。今后，我们也会加强通过网站和SDNLAB这类论坛与各位业界同仁进行交流学习，后会有期。今天就讲到这里，谢谢大家！