中国联通SDN/NFV的思考与实践

编者按:2015中国SDN/NFV大会在北京召开,本次大会围绕SDN/NFV展开讨论,来自运营商、服务提供商等业界巨头纷纷参与此次大会。中国联通技术部技术战略处经理裴小燕发表了题为《中国联通SDN/NFV的思考与实践》的演讲。

大家中午好!我简单的介绍,汇报一下中国联通对SDN/NFV的思考。我是制订公司发展战略的工作,因此借用网络上流行的话“世界很大,我们要去看看”。我汇报的技术层面东西比较少,主要分享一下,我们去世界看看的一些结果。

关于运营商对于NFV的一些需求,我不详细说了。NFV的这个架构大家也很熟悉。那么,对于北向接口大家考虑比较多,南向接口大家也关注了,所以我们后期也会关注这个工作。关于SDN和NFV的关系,前一段时间听到一个比较有意思的比喻:整个SDN和NFV像一个公司的运营,SDN提供了底层的基础设施,NFV更多的像人力资源、劳资这些部门,有一些人提需求了,NFV就把网络计算和存储等功能对SDN提出来,那么我需求提完了之后,SDN根据这些需求把要干的活完成,这是比较有意思的比喻。

接下来分享一下国外的运营商做了哪些工作。NTAT在SDN走的比较快,它提出著名的《2020规划》,这个2.0不仅对网络动大手术,更重要的是它的运营,对运营商也是值得借鉴的方面。

另外澳大利亚的公司,它更多的是开始把移动核心网进行虚拟化,就是这个方面,更多的是从MS和EPC入手把核心网进行虚拟化,这是NFV应用的例子。另外,意大利电信,它做的工作更多一些,在接入的层面它实现了云化,在光纤改造和4G的各个领域它也有一个云化的过程,整个云用被管理起来,可以和它的管理系统实现管理的自动化、自优化。在移动核心网领域做了一些规划,接入的层面基本上不动,但是在核心网的承载层和下面的应用层都进行了虚拟化,同时对企业应用和CP的转换都放在云上面,而且实现了RT漫游方面都放在云化的上面支撑,对接入的层面可以进行透传的。它把移动核心网对于物联网新建了VEPC,这样可以部署几个节点,可以实现服务于整个欧洲的互联网,到2014年底每个节点已经有5400万的容量了。

接下来分享一下中国联通后期的工作,根据技术的标准和产业的成熟阶段,初期可能硬件可以进行持左化,但NFV还是厂家各自为政的,东西向的接口没有打通,只能达到各自圈地。远期的目标和NFV的愿景,不仅底层的还有虚拟的控制层面东向可以打开也可以有一个资源池,争取最终实现软件硬控制。

最后根据技术的成熟度来一步一步的往下走,第一步先开展比较容易操作的,像移动核心网的EMS,和EPC,开展测试,跟现有的系统进行对接,实现端到端的业务打通,后续可以把一些像CDN的系统逐渐的进行虚拟化,对接入层面暂时不考虑虚拟化,这些考虑是对于NFV初步的考虑。对于整个EPC和网元做一些工作,下一步开始验证性的测试,组织整个产品的测试,同时接接口,做一些现网的试点,同时在NFV这个领域,物联网的应用开展一些试点和验证。

对于家庭网管和企业网管的虚拟化,我们现在已经制订了相关的标准,已经开展了一个相关的测试,就是关于在家庭领域和企业网管这个IPTV机顶盒的考量。对家庭网管有两个演进的方向,一个走的更瘦一个走的更胖,对瘦的提供二层的接入就可以了,后续增加新业务的话,家庭网管的变化使它最小。另外,联通最近推的联通电视这个业务,其实它把一些业务的很多的控制功能都放在网上,对于后续再增加其他的业务也比较的方便。虽然在产品形态上家庭网管和IPTV是不同两条路,但是从网络来讲,BVS内容推送可以集中一起考虑的。

对企业网管,针对不同大小企业、不同的需求要能够快速的反应。为企业量身定制业务的话,需要把控制管理、或者是更高层面的这种能力集中起来。明年,因为在今年各种标准制订的基础上,把虚拟网管的架构和业务结构固化下来,能够让产业链的各方可以按照统一的标准开发。后续就是根据需求不断的完善,进一步的开展整个网管一系列的相关产品。

刚才提到家庭网管的虚化,它涉及路由器以及其他的一些工作,后续通过端到端的业务进一步来完善。刚才介绍了一些NFV的基本功能,后续跟大家介绍一下SDN的一些想法。在SDN领域,比NFV更成熟一些,那么一些基本的相关的应用会先做起来,对SDN的应用成立了一个云公司,未来规划了十个基地,目前建立的三个基地已经按云部署了。未来在优化的领域,还有回传的领域也会开展工作。关于IP和光协同,和传送领域SDN的领域,会根据技术的成熟度,对固网的接入还不考虑虚拟化。

对SDN领域走的比较多,它比较的成熟,后续在这个领域会加大研发,然后逐渐的把它商用。在SDN领域开始的时候,后期可能形成一个大的资源池,可以把这些不同的网元放在不同的资源池。对于整个将来DC的目标规划,有一个初步的设想,但是我们做的时候不会形成一个IDC,因为全国的网很大,有300多个本地网,将来IDC虚拟化的资源池如何组合,如何形成大的资源池,这是后续要考虑的主要问题。

后续在建网初期的定位,除了支持移动回传之外,希望对企业用户进行开放,现在提供二层开放能力是很容易实现的,但是联通的情况比较特殊,我们有两张内部的承载网,一个是IP承载网A,但是它是承载网A接在承载网B上的。那么,怎么把这两张网打通,实现三层以上的业务接入,这是我们后续考虑解决的问题。

刚才,对于一些点进行了简单的汇报。后续,就是我们也制订了一个未来的演进目标。这个时间比较长,可能需要十年的时间才能达到这个目标。在接入的领域保持独立,在接入层面形成一个云,这个云如何组合,这是后续考虑的。联通对北方的固网进行改造了,改成MPS,那么这两个机架怎么利用,把本地腾出来的机房形成一个接入的云,那么这个云是分层收敛的,如何实现控制,这是后期研究的重点,整个会聚和后续的承载网,因为有IP承载网A、B、169,我们把十个大的运载中心用承载网联合起来,用建的MS,在承载网之上,比如说固网和移动的MS怎么走,最终的目标形成一个云,但是从云的迈进过程有很多的问题需要解决。

我们除了有这些大的自己的中心之外,在169的网有BIT的数据中心,我们的数据中心和我们的数据中心联合控制,路由如何分配,我们后面还有问题向这个方向迈进,谢谢大家!

本文来源2015 SDN/NFV大会会议速记稿,不代表本站观点及立场。

时间: 2024-12-29 12:04:34

中国联通SDN/NFV的思考与实践的相关文章

万台规模下的SDN控制器集群部署实践

目前在网络世界里,云计算.虚拟化.SDN.NFV这些话题都非常热.今天借这个机会我跟大家一起来一场SDN的深度之旅,从概念一直到实践一直到一些具体的技术. 本次分享分为三个主要部分: SDN & NFV的背景介绍 SDN部署的实际案例 SDN控制器的集群部署方案 我们首先看一下SDN.其实SDN这个东西已经有好几年了,它强调的是什么?控制平面和数据平面分离,中间是由OpenFlow交换机组成的控制器,再往上就是运行在SDN之上的服务或者是应用.这里强调两个,控制器和交换机的接口——我们叫做南向接

ONOS 项目与 Linux 基金会合作开发 SDN/NFV

近日,ONOS 社区和 Linux 基金会联合宣布结成战略合作关系,双方将联手开发开源的 SDN/NFV 解决方案.ONOS 项目与 Linux 基金会的合作旨在创建颠覆性的 SDN 解决方法,重点是开源平台.白盒.一系列网络控制和管理应用程序,以及快速创建和部署创新服务的能力,以供服务供应商实现 SDN/NFV 的经济效益,同时帮助厂商和服务供应商建立新的商业模式.作为 Linux的合作项目,ONOS 将获益于基金会在管理开源项目方面的专业能力以及社区参与度,增强项目在开源进程和实践中的关键战

基于SDN,NFV的服务感知网络架构下篇

编者按:本篇文章是继<基于SDN,NFV的服务感知网络架构上篇>对DPI进行进一步的深入解析,分析了在SDN中可能出现的三种部署情况,对第4-7层的业务需求以及业务感知网络架构作了一个深入的介绍. 在SDN网络中部署DPI SDN架构包括四个或者更多的层次,包括业务流层,业务应用层,控制层和节点层.下图表示了DPI在用于流量整形.用户分析.QoE和网络安全时可能被嵌入的三个层,仅举几例.这些部署方案允许DPI信息在网络内共享,这样只要进行一次应用识别即可,从而节省了CPU和能耗.统一的DPI简

也谈OpenFlow, SDN, NFV

Copyright (2014) 郭龙仓. All Rights Reserved. OpenFlow 传统的网络环境中,仅仅有路由器/交换机之间的接口/协议是标准化的,可是在网络设备内部,数据平面和控制平面事实上是耦合在一起的,每一家厂商都有自己专有的系统来实现这两个平面,并且数据平面和控制平面不可以分开独立演化. 在 初期网络环境比較简单的时候,这样的数据平面和控制平面的耦合事实上无关紧要:可是如今的企业内部网络环境愈来愈复杂,大量异构的网络设备.复杂的组织架构. 竞争日趋激烈的市场环境--

2015中国SDN/NFV大会专题报道

2015中国SDN/NFV大会今日在北京成功揭开帷幕,本次大会由中国通信学会,中国通信标准化协会共同举办,云集了国内外SDN领域的大咖,包括学术界专家以及产业链代表.小编有幸在现场享受这场饕餮盛宴,未能到会的小伙伴也无需遗憾,小编会第一时间发布嘉宾的演讲内容,更多精彩敬请关注SDNLAB. 1. 开放.创新.协同.落地: SDN 产业联盟助力 SDN 走向成熟 中国信息通信研究院副院长.SDN产业联盟秘书长 刘多 2. 面向 PTN 网络的端到端 OpenFlow 托管虚拟客户端解决方案 博通公

腾讯IVWEB前端工程化工具feflow思考与实践

本篇文章主要介绍腾讯IVWEB团队从0到1在工程化的思考和实践.feflow的全称是Front-end flow(前端工作流),致力于提升研发效率和规范的工程化解决方案.愿景是通过feflow,可以使项目创建.开发.构建.规范检查到最终项目上线的整个过程更加自动化和标准化. 要解决的问题 项目的目录结构按约定生成 团队有一套开发规范进行约束 支持多种类型的构建,包括Fis构建和webpack构建 团队内部的代码贡献统计.离线包内置App等 为了解决上述问题,我们于17年2月底开始投入工程化fef

前后端分离的思考与实践(六)

原文出处: 淘宝UED - 筱谷 Nginx + Node.js + Java 的软件栈部署实践 起 关于前后端分享的思考,我们已经有五篇文章阐述思路与设计.本文介绍淘宝网收藏夹将 Node.js 引入传统技术栈的具体实践. 淘宝网线上应用的传统软件栈结构为 Nginx + Velocity + Java,即: 在这个体系中,Nginx 将请求转发给 Java 应用,后者处理完事务,再将数据用 Velocity 模板渲染成最终的页面. 引入 Node.js 之后,我们势必要面临以下几个问题: 技

关于后台部分业务重构的思考及实践

关于后台部分业务重构的思考及实践 作者: ljmatlight 时间: 2017-09-25 积极主动,想事谋事,敢作敢为,能做能为. 当职以来,随着对公司业务和项目的不断深入,不断梳理业务和公司技术栈. 保证在完成分配开发任务情况下,积极思考优化方案并付诸实践. 一.想法由来 由于当前我司主要针对各大银行信用卡平台展开相关业务, 故不难看出,各银行信用卡平台虽然有各自的特性, 但其业务相似程度仍然很高,除必要的重复性工作外,仍有很大提升优化空间. 例如: 各个银行平台都需要对账工作.都要安排人

关于数据库‘状态’字段设计的思考与实践

最近在做订单及支付相关的系统,在订单表的设计阶段,团队成员就‘订单状态’数据库字段设计有了一些分歧,网上也有不少关于这方面的思考和探讨,结合这些资料和项目的实际情况,拟对一些共性问题进行更深一层的思考,笔耕在此,和大家一起探讨. 问题综述 这里的分歧点即有团队内部的分歧点,也有网络上常见的一些分歧点,先将存在的分歧点抛出来: 1.订单表的‘订单状态’字段对应的字典值应当包含哪些状态值?对于‘已评论’.‘已退货’.’已退款’这类状态是放到‘订单状态’中?还是独立一个字段标识? 2.订单表的‘订单状