其他分享
首页 > 其他分享> > SDN实战团分享(十九):OpenDaylight在电信网络中的应用

SDN实战团分享(十九):OpenDaylight在电信网络中的应用

作者:互联网

大家好!首先自我介绍一下:我来自中国电信广州研究院,我和我的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这类论坛与各位业界同仁进行交流学习,后会有期。今天就讲到这里,谢谢大家!


标签:控制器,IP,功能,NFV,ODL,SDN,十九,OpenDaylight
来源: https://blog.51cto.com/u_15127593/2749748