Gartner:命令行接口(CLI)将被取而代之,它不再是网络运维的主要工具

Gartner声称:到2020年,CLI的使用将日渐式微。

多年来,网络工程师依赖命令行接口;据市场研究公司Gartner的分析师们声称,但是这种使用很普遍的工具正在迅速让位于配置和运维网络的其他方法。实际上,他们预测,到2020年,只有30%的网络运维团队会使用CLI作为主要界面,这比今天的85%大幅下降。

预测CLI的角色日渐式微是Gartner最近发布的众多企业网络预测之一。

据Gartner声称,CLI沦为小角色是由于企业需要通过实现运维任务自动化,加大网络灵活性,以便支持数字化企业。企业想要远离逐个设备的CLI驱动型配置,改为基于策略的集中式运维,现在有许多替代方法并不依赖CLI。Gartner表示,这些替代方法包括以太网架构、软件定义网络(SDN)、软件定义广域网(SD-WAN)和云托管型网络;它们正在攻城略地,到2020年会取代50%以上的已安装的CLI。

据报告声称,此外,CLI常常与手动配置变更联系起来,而手动配置变更正是企业网络故障的主要根源。

由CLI转向基于策略的集中式运维是“一个必要的前兆,因为网络团队需要处理因使用微服务/容器以及物联网设备数量激增而引起的规模需求,”分析师们如是说。

话虽如此, Gartner并不认为CLI会完全消失;它在深入的故障排查或测试方面仍大有用处。然而,侧重于掌握CLI的专有网络专业认证会变得不大重要,取而代之的是“架构师级别的技能,这些技能侧重于网络自动化、API编程以及与基础设施的其他部分整合起来,”Gartner的研究主任丹尼洛·西斯卡托(Danilo Ciscato)写道。

为了顺应这种转变,Gartner建议企业在购买新的基础设施时要求网络自动化,不能任由传统的CLI技能影响采购决策。这家公司建议,企业还应该充分利用API来获得更大的网络灵活性,重新调整培训方面的投入,淡化CLI和专有认证,注重网络编程工具和借助API实现的编排。

SD-WAN和开放网络大行其道
据Gartner声称,软件定义广域网(SD-WAN)是企业逐渐不再依赖CLI时将寄予厚望的技术之一。这家公司预测,到2018年,相比传统路由器,40%以上的广域网边缘基础设施更新项目将基于SD-WAN设备及/或基于x86的虚拟化用户端设备(CPE),这与如今的不到2%相比将有惊人的提升。

Gartner的调研副总裁安德鲁·勒纳(Andrew Lerner)写道:“SD-WAN的发展势头越来越猛,因为这种技术提供了非常具体的投资回报率,相比传统的广域网方法,常常可以节省至少40%的成本。”

他表示,全球SD-WAN的采用情况已从2014年6月份的寥寥几个付费客户变成截至今年9月份的2000多个客户。

Gartner还认为开源在企业网络中扮演更重大的角色:到2020年,开源和自建这两种方案将在整个数据中心网络市场至少占到20%的比重,而现在这个数字还不到2%。

Gartner的调研主任内尔什·辛格(Naresh Singh)特别指出,开发运维(DevOps)组织往往更喜欢使用开源产品;越来越多的企业计划采用开发运维方法。他写道,如今,核心部分都有相应的开放网络社区,比如第2层及第3层交换、路由以及第4层-第7层网络服务。

辛格写道:“众多项目也吸引了用户和厂商的广泛参与,因而让它们更有可能得到主流企业的采用,比如OpenSwitch、ODL、开放网络操作系统(ONOS)、OpenNFV、Nginx和HAProxy。由于这些开源项目继续跨不同的网络部分发展,如今使用开源选项,就可以满足形形色色的网络要求。”

Gartner建议,企业应要求每个网络都要精心选择,包括评估开源软件。

基于意图的网络
这家公司的其他预测包括基于意图的网络(intent-based networking),以及在分支机构部署直接互联网接入。据Gartner声称,10%的企业将使用互联网驱动的网络设计和运维工具――而今天的比例仅为零。Gartner副总裁兼杰出分析师乔·斯科鲁帕(Joe Skorupa)解释,“意图”以业务用语描述了“对网络需要什么样的服务,而不是如何配置单个参数,它充当了配置的通用语言。”

他特别指出,基于意图的网络在部署之前验证了设计,预防配置错误,并且借助持续监控,因而减少了网络故障。

据Gartner声称,虽然基于意图的网络只是刚浮出水面,但是企业会更快速地将直接互联网接入服务部署到分支机构。到2020年年底,60%以上的企业会这么做,而现在的比例还不到30%。Gartner表示,推动这股潮流的是企业持续采用云服务,这需要重新设计分支机构的互联网接入,以便改善连接至云应用程序的性能。

本文链接:http://www.sdnlab.com

ONOS中Juniper路由器Driver开发简介

根据SDN的实现深度,可将其分为狭义SDN与广义SDN。其中,狭义SDN是指基于OpenFlow协议,将转发面和控制面完全分离的革命性SDN。广义SDN是指数据包转发依然基于现有设备上的协议,但将网络的部分控制功能上移到控制端,是一种既能利用现有网络设备,又能获取SDN部分优点的演进型SDN。

广义SDN因其高效、颠覆性,受到学术界及创业公司的关注。而对于传统设备厂商和运营商来说,不太可能短时间内,大范围地将现有设备替换为OpenFlow设备。因此,对于传统运营商来说,演进型SDN的研究部署同样迫切。

中国科技网是由中科院计算机网络中心负责运营的,学术性、非盈利性互联网基础设施。在全国部署上百个骨干、接入节点,同时拥有多条通往美国、日本和韩国等国际出口,是中国主要的互联网运营商之一。

科技网中网络设备的提供厂商较多,比如Cisco、Juniper、华为和华三。当前用独立分散的方式对网络设备进行管理,比如,当路由器执行新的防火墙或路由规则时,需要SSH登陆路由器进行手动配置。网络设备多而杂,这样的人工配置方式耗费人力,且易出错。利用广义SDN的思想,对网络设备进行统一自动管理是科技网在自动化运维方面的尝试。

目前,我们基于ONOS控制器进行二次开发,对juniper测试路由器进行集中控制,执行防火墙限速等功能。ONOS中主要通过NETCONF协议远程读取、修改网络设备配置,所以我们也基于NETCONF协议来实现对Juniper路由器的管理。主要工作分为如下几部分。

1 在ONOS中开发juniper路由器的简单driver,链接路由器。
2 进一步在driver中添加所需功能,比如实现XML文件解析,利用NETCONF协议下发相关XML文件,执行基本配置读改、设置防火墙限速等动作。
3 在命令行下发模块(cli)中,开发新的执行命令,使得用户可在命令行中执行2的动作。
4 由三台juniper测试路由器,组成测试demo,验证相关功能。

相关实现代码已开源:https://github.com/CNICCSTNET/OpenJuniperDriver
下面对上诉工作进行详细介绍。

前期准备
ONOS中基于NETCONF协议对路由器配置进行远程控制,由于之前对NETCONF协议不太熟悉,首先学习了NETCONF协议,并用分别用NETCONF协议的Python函数库(ncclient),和juniper的NETCONF Java Toolkit实现了简单读取和修改路由器配置的小程序。升级路由器,使其支持NETCONF协议。同时学习juniper路由器的配置命令,弄清实现不同命令时NETCONF协议下发的XML文件。 相关的学习链接如下:
NETCONF RFC6241:https://tools.ietf.org/html/rfc6241

ncclient:https://pypi.python.org/pypi/ncclient

NETCONF Java Toolkit:http://www.juniper.net/techpubs/en_US/junos14.2/information-products/pathway-pages/netconf-java-toolkit/netconf-java-toolkit.html#overview

一 、Driver初步实现,链接路由器
1.1 新建juniper APP
ONOS需要不同的Driver来对不同设备厂商的设备进行控制,在ONOS中开发driver的步骤跟实现一个普通APP的过程相识。具体可参见ONOS的wiki或者毛健炜同学的博客:
https://wiki.onosproject.org/display/ONOS/Creating+and+deploying+an+ONOS+application

http://maojianwei.github.io/2015/11/24/ONOS-in-Practice-for-Share-one-Project-Set-up-Debug-Hot-Deployment/

1.2 修改pom.xml等文件
建好名字为juniper的APP后,将其移动到onos/drivers/目录下,并修改onos/drivers/juniper目录下的pom.xml文件.
同时修改onos/drivers/下的pom.xml文件,添加juniper module,使得编译drivers模块时,也编译juniper的driver,在drivers/juniper/src/ 目录下,新建resources文件夹,并新建一个juniper-drivers.xml文件,用于存储juniper驱动的相关调用关系。目前是空的,在后面实现具体修改路由器配置时,可添加ONOS中api接口和具体实现的对应关系,新生成一个导入juniper-drivers.xml文件的java文件JuniperDriverLoader.java,放在onos/drivers/juniper目录下。

1.3 编译并启动drivers
在drivers目录下,执行mvn clean install编译后,重启ONOS。执行如下命令,启动相关的drivers APP,若APP启动成功,则执行drivers命令。可以看到我们的juniper 及 NETCONF的driver都启动成功。

1.4 链接路由器
在tools/test/configs目录下,生成netconf-cfg-juniper.json文件,作为链接juniper路由器时的读入文件。此文件定义了接入设备的名称,调用的driver,及用于NETCONF协议登陆的用户名和密码,路由器的IP和通信端口号。其中,830是NETCONF协议的固定通信端口号。

我们的juniper driver继承了NETCONF driver,调用NETCONF协议(onos/protocols/netconf)中的方法实现和路由器的通信。ONOS为利用NETCONF driver,链接远程路由器实现了相关命令onos-netcfg。我们也可以通过此命令,将juniper路由器和ONOS中的juniper driver相链。

ONOS中NETCONF相关的wiki链接:https://wiki.onosproject.org/display/ONOS/NETCONF
链接路由器成功后,在ONOS中执行devices命令,可查看到此路由器已经通过NETCONF协议和控制器相连。

至此,我们juniper的driver开发已初步完成,通过此driver,成功将路由器和ONOS控制器链接。下面我们将在此driver上,增加用于解析NETCONF协议中XML文件的类,并通过下发相关XML文件,实现读取并修改juniper路由器的功能。

二、Driver进一步开发
在本部分中,我们将进一步在Driver中添加相关功能 。新添加的功能可分为两大类,一是将用户输入的命令转为NETCONF命令(即XML文件), 另一个是将相关的XML文件通过NETCONF协议,下发到路由器 。

Tools文件夹中的类主要是针对用户输入的命令生成相应的NETCONF命令,以及对juniper路由器返回的命令进行解析。而在juniper文件中的类主要是完成对driver的加载以及命令的下发。

2.1 NETCONF命令生成
在juniper驱动开发的最关键的一步就是NETCONF指令的形成。NETCONF命令是XML格式的String字符串。在NETCONF中,发送的命令一般是包含在标签中。而设备返回的命令一般是包含在当中(具体命令的格式我们会在后续的文章中介绍)。

为了能够高效的形成XML形式的字符串,使用了XMLConfiguration这一工具类。

熟悉NETCONF命令的同学都知道,NETCONF命令中读取和修改的命令都具有固定的格式。为了方便使用。我们将命令的格式写进了netconfEdit.xml文件中。当有命令进来的时,只需要在固定的框架中填充一定的内容就可以了。

对于传入参数的设计,我们参考XMLConfiguration里面的命令和对实际情况进行讨论分析。我们决定用“;”进行每个路径的分割。如果输入的某个路径无法唯一被确定,可以使path1;path2[@name=”name”]的方式进行路径的指定。

2.2 NETCONF命令的发送
当用户加载完路由器的驱动以后,ONOS系统会自动与在配置文件(1.4介绍的netconf-cfg-juniper.json)中配置的路由器进行连接,并将产生的session保存在NetconfController中。当路由器需要下发命令时,首先要获得对应的session,然后调用我们上面写好的函数生成对应的Netconf,接着调用session的requestSync方法进行命令的发送,并获得返回信息。

当收到返回信息以后,利用tools中xml解析类对返回的信息进行解析,得到相应的信息,并对返回的信息进行解析。

三 、新命令开发
我们在onos/cli模块中,实现了多个新的命令,比如获取路由器详细配置、修改路由器某个参数、设置防火墙限速及执行commit使得配置生效。下面以获取路由器详细配置信息的命令为例,说明新命令的开发流程。

3.1 新建接口程序
在onos/core/api/src/main/java/org/onosproject/net/behaviour目录下,新建ConfigDetailGetter.java接口程序:

此接口程序的具体实现在juniper driver目录下的ConfigDetailGetterJuniperImpl.java中。为了使得调用此接口时,自动跳转到juniper driver的实现,需要在juniper-drivers.xml文件中添加两者的对应关系。

利用外部XML文件指定接口和实现间的关系,是ONOS中常用的处理方法。此方法可减少核心core中的代码量,将大部分实现放在第三方的接口程序中。

3.2 调用接口程序,实现命令
在 onos/cli/src/main/java/org/onosproject/cli/net/vnet目录下,新建DeviceConfigDetailGetterCommand.java文件,实现具体命令.

uri,cfgType,firstLevel等是从用户输入的命令中传递过来的,这些参数中包含了用户希望进行配置的具体信息。利用deviceId,我们找到对应的设备。再根据设备的信息,调用具体的驱动,也就是我们的juniper driver。XmlStructureParserGet用于处理用户传进来的参数,将其转化为2.1中生成XML文件所能识别的结构化字符串。因为一个接口可能拥有多个实现。所以需要通过ConfigDetailGetter.class 找到接口的具体实现类。以本系统为例,configDetailGetter接口的具体实现是ConfigDetailGetterJuniperImpl类。

四、测试Demo
完成第一到第三步的开发,并编译成功后,建立由若干路由器组成的测试网络,验证相关功能。实验网络如下图所示,一台运行ONOS的服务器,此服务器也用来测试文件上传和下发速度,三台juniper M10i路由器,操作系统升级为最新的Junos 15.1,服务器和路由器在同一网段。利用ONOS下发对某个IP进行限速的指令,然后让此IP所对应的服务器从路由器上下载、上传文件,验证限速的有效性。

根据第一步中的方法,将ONOS和路由器链接后,首先下发限速所需的防火墙规则:

其中set-speed-limit 是我们实现的专门进行限速的命令,netconf:159.226.101.32:830 是路由器设备的ID,myFirstTest是此防火墙的ID,159.226.101.80/32 是被限速的服务器IP,速度限制为2M,burst速率限制为10K。返回的ok表示设置成功。

将防火墙规则绑定到某个Interface:

其中,filter-interface 是我们实现的将某个防火墙规则绑定到Interface的命令,此命令将我们刚才生成的防火墙myFirstTest绑定到Interface fxp0中。159.226.101.80/32对应的数据流通过fxp0端口进行转发。
最后,利用commit-router命令,使得上诉配置在路由器中生效:

登陆路由器,确认相关配置在路由器中生效后,在159.226.101.80/32所对应的服务器上,利用scp 方式从路由器获取文件,或者将数据上传到路由器,确认限速成功。

五、总结及未来工作计划
目前,我们在ONOS上开发了juniper的driver,在driver中通过NETCONF协议控制路由器,成功实现了远程获取路由器配置、限速等功能。这是中科院网络中心网络研究团队在广义SDN方面做的一次尝试,证明利用现有开源控制器,可实现对现有网络设备的集中控制,为在科技网上实现SDN控制积累相关经验。

在ONOS开发过程中,我们对其NETCONF具体实现、driver相关模块、XML文件解析等有了一定了解。NETCONF协议和数据搭建模型YANG是紧密相关的,我们本来也打算用YANG对路由器配置信息进行建模,方便XML文件的生成。但后来发现目前ONOS对YANG模型的支持还不太完善,需要自己实现的东西太多,最终放弃。未来,我们团队打算在如下方面继续开展工作:

1 基于我们对NETCONF具体实现、Driver相关模块、ONOS中如何利用外部XML文件实现Driver模块的热插拔等方面的认识,写成详细文档和大家分享。

2 ONOS社区中华为的Patrick Liu团队在推进brigade-dynconfig项目,此项目将实现通用driver,并基于这个项目,完善ONOS中对YANG的支持。我们打算跟进这个项目,并最终基于这个通用driver和YANG实现我们现在的功能。
brigade-dynconfig项目链接:https://wiki.onosproject.org/display/ONOS/Dynamic+configuration+brigade

3 基于ONOS,进一步开发集中控制流量调度的模块,争取在广域网上实现SDN的流量自调度。

作者简介:
周建二,2016年博士毕业于中科院计算所,现就职于中科院网络中心,助理研究员, zhoujianer@cnic.cn
邱欣逸,2015年本科毕业于厦门大学软件工程专业,现中科院网络中心硕士研究生, qiuxinyi@cnic.cn

本文链接:http://www.sdnlab.com

ABI Research发布vEPC厂商大玩家

ABI Research预测,到2019年vEPC的支出将超过物理网络功能的支出,到2021年将达到80亿美元。

根据ABI Research发布的Mobile Packet Core VNFs and PNFs Market Data调查报告显示,vEPC的几大领先的玩家包括NEC、Affirmed Networks、ZTE、Ericsson、Huawei。

ABI Research分析师Ahmed Ali表示,以AT&T、NTT、Telefonica等为代表的运营商开始使用网络功能虚拟化(NFV)来支持更多的用户和服务,因此这些运营商将目光投向了vEPC技术。

Ahmed Ali说:“鉴于vEPC功能对连接世界的重要性,对vEPC的需求将持续增长,最终将成为核心市场的最大的比重,年复合增长率达到了54%。”除了vEPC之外,这里的“核心市场”还包括虚拟IP多媒体子系统(vIMS)、Gi-LAN以及其他一些小的组件和网关。

在已经发展完善的市场,物联网(IoT)是vEPC背后的驱动力。Ali表示,运营商对物联网市场有庞大的计划,使得虚拟化得以广泛使用,以便能够有效地降低扩展网络的成本。

在正在蓬勃发展的市场,vEPC的采用的主要驱动力不是IoT而是通过扩展网络以满足4G网络上不断增长的用户流量。

5G也推动vEPC的发展,Ali表示:“总体而言,虚拟化是5G的主要方面之一,运营商预计将逐步部署更多的虚拟功能(包括EPC),旨在实现高度虚拟的网络,以便他们能够轻送向5G网络迁移、融合。”

爱立信最近发布的一则报告表示,NFV是5G取得成功的必要条件。该报告表示,2015年NFV在核心移动网络中开始部署,首个NFV服务部署示例包括LTE语音(VoLTE)和Wi-Fi呼叫。

本文链接:http://www.sdnlab.com

Huawei Boasts Shared Spectrum Breakthrough

Huawei has unveiled a mobile spectrum management solution that could open up new possibilities for the dynamic and efficient sharing of valuable capacity.

During a presentation at the company’s Mobile Broadband Forum event near Tokyo, Edward Deng, president of Huawei’s Wireless Solution division, presented CloudAIR, which the vendor is pushing as the third leg of its mobile cloud stool.

Huawei Technologies Co. Ltd. has previously launched its CloudEdge system (for the mobile network core) and CloudRAN (for the radio access network), both of which center around the ability to unshackle and share network resources. CloudEdge is already commercially available and deployed in multiple networks while CloudRAN was launched earlier this year, is currently in proof of concept (PoC) mode and is set to become commercially available during the third quarter of 2017.

CloudAIR is focused on ways in which spectrum, channels and power can become shared resources within a mobile network, though whether simply allowing resources to be shared means it can be pinned with the “cloud” badge is debatable.

But the proposition is certainly an innovative and interesting one — so much so that Light Reading witnessed multiple network operator executives reaching for their smartphones to take pictures of the CloudAIR presentation slides.

Deng noted that, currently, spectrum needs to be refarmed if it is needed to be used for a different radio access technology (RAT). That takes spectrum away from one RAT (for example, 2G) and assigns it to another (for example, 4G) on a permanent basis. The CloudAIR proposition is that “idle” spectrum could be dynamically shared, as needed, across different RATs.

Huawei has been working on such techniques for a while. Deng said the CloudAIR development is an extension of techniques that Huawei has already been working on with Vodafone and Etisalat. (See Vodafone, Huawei Trial GSM-LTE Dynamic Spectrum Sharing.)

Deng also presented the idea of channel sharing, whereby channels in a MIMO (Multiple-Input Multiple-Output) deployment can be clustered rather than fixed. He also floated the idea of UC-MIMO (user-centric MIMO) whereby channels are shared from a pool, a step beyond clustering.

The Huawei man said CloudAIR would be demonstrated at the MWC 2017 show in Barcelona (yes folks, that’s looming in the near future…).

As mentioned, the CloudAIR presentation caused something of a stir among the audience of operators, partners and industry analysts.

“It is definitely a statement of intent. Every vendor is pursuing Cloud RAN, but I haven’t seen anyone set out something as comprehensive in terms of a long-term statement of intent for their portfolio,” noted Heavy Reading Senior Analyst Gabriel Brown. “Obviously, it’s still early days — trials are not anticipated until the first half of 2018 — and it’s something that will be phased in. This is really a long-term play,” he noted.

But the concept is certainly in line with future roadmaps already being discussed within the mobile operator community. “The CloudAIR pitch has some of the same ideas around resource management as the X-RAN initiative launched at the NGMN conference last month.”

One of the main challenges for introducing spectrum-sharing capabilities as proposed by Huawei, though, is that it goes against the industry trend of deploying multi-vendor networks that don’t tie an operator to a single supplier. “The spectrum sharing approach looked very interesting as a way for operators to manage spectrum holdings and migrate subscribers across different technology generations,” notes Brown. However, “it requires a single-vendor network, so it won’t suit everyone, but it’s interesting nevertheless.”

This article links:
http://www.lightreading.com

A10 Takes to the Cloud for App Delivery

Four months after acquiring Appcito for its cloud application delivery controller chops, A10 Networks is introducing its own cloud-based ADC. It’s A10’s first cloud service, extending the company’s ADC hardware appliance legacy.

The A10 Networks Inc. Lightning Application Delivery Service is a microservices-based, containerized ADC offering, providing application load balancing; application-level security for web applications, firewall and security, including bot protection; as well as analytics and automatic alerts based on application behavior. It’s available as a cloud service from A10, or enterprises can run the software on their own private or hybrid clouds, or service providers can offer it as a managed service.

The A10 Lightning Application Delivery Service extends A10’s existing Thunder ADC appliances to provide the flexibility needed for cloud applications, A10 said. (Lightning? Thunder? Get it?)

Lightning ADC’s container and microservices architecture provides more flexibility for hardware appliances, like ADC’s own Thunder line, and monolithic software applications. “Each component is faster and more agile, Kamal Anand, vice president of the cloud business unit and former Appcito CEO, tells Light Reading. Cloud operators can easily distribute ADC components to applications as needed, for example providing high security and protection for credit card verification in an e-commerce application, with less protection for people just browsing the catalog.

“Being service aware allows you to have different policies across services, and visibility across services,” Anand says. “Traditional ADCs are heavy appliances that can’t fit into this model.”

The Lightning ADC is available now, priced starting at $5,000 per year.

The software is priced pay-as-you-go. That should be attractive to service providers deploying NFV services but unhappy about having to pay to license software whether the service is deployed or not. “It’s a consumption-based model. If I have a bigger customer I pay, rather than paying and hoping that a customer comes,” Anand says. And enterprises can start small and pay more as they grow. (See The Virtual Business Process: A Dilemma.)

This article links:
http://www.lightreading.com

Level 3’s Scola Discusses Standards, APIs

Even as programmable networks serve current needs for service providers, significant progress in writing standards for virtualization and vendor offerings is already underway.

In the third part of this Telco Transformation Q&A, Level 3 Communications’ Claudio Scola provides an overview of the shift towards the virtualization of network functions. Scola, director of global product marketing for Core Network Services at Level 3 Communications Inc. (NYSE: LVLT), also spoke about the importance of Southbound APIs, which converse with routers, switches and the SDN controllers in the infrastructure layer of a network.

Scola discussed Lifecycle Service Orchestration and SD-WAN for network-as-a-Service in the first two Q&As. (See Scola: Lifecycle Service Orchestration Key for Level 3 and Level 3’s Scola Discusses SD-WAN for NaaS.)

Telco Transformation: What breakthroughs have been achieved in the virtualization of the network elements of WAN transportation, and their integration with SDN, that makes it a viable alternative to MPLS?

Claudio Scola: I am not against dedicated hardware — especially if they support open APIs such as NETCONF and YANG. As an industry, we are still reliant on CLI software adaptors, but at least they exist and allow us to move forward with network programmability. I think some network functions might be better on a dedicated piece of hardware for now.

[In regards to virtualized open source infrastructure] we have started to build out early deployments and proof of concepts for commodity hardware based virtualized infrastructure for SDN-based networking. We are starting to see a range of good network functions become available as virtualized network functions (VNFs). Many of the big brands that make dedicated routers, firewalls, switches and WAN optimization controllers have released virtual versions of their products.

SD-WAN is a technology that leverages SDN and NFV and wraps it into a WAN solution. Vendors like Versa, Nuage Networks and VeloCloud are making good progress with NFV-based solutions that can build into the service provider’s network. Up until recently, these solutions were mainly CPE OTT based solutions aimed at the self-managed market, but now there are carrier-grade solutions that have true flexibility built into the solution from the ground up. SD-WAN has been a key trigger for service providers to start building their NFV infrastructure.

The big challenge right now seems to be orchestrating it and service chaining the functions together.

For large-scale deployments in multi-vendor environments, we want to see solid progress on API standards for end-to-end controls.

There’re many standards within the open source community — ETSI, TM Forum and MEF and good progress is being made. The Metro Ethernet Forum’s UNITE, OpenLSO and OpenCS initiatives are useful initiatives that we are supporting. Carrier grade outputs from these allow the industry to start building NFVi MANO environments instead of using dedicated hardware.

For next-generation virtualized infrastructure, the MEF’s OpenCS Initiative is a great hub for tracking and pushing use cases based on E-CORD for virtualized DC (data centers), MANO (for NFV), OpenDaylight (for packet WAN) and SD-WAN. So we are getting closer to modernizing the infrastructure and standardizing the southbound API that is trying to talk to it.

TT: What is the experience so far with OpenFlow standards in flexible resource allocation for WANs? How does it cope with the sunk costs of legacy infrastructure?

CS: There is very little experience of OpenFlow in the WAN sector. OpenFlow traditionally lives in the DC dealing with the switching fabric. There is so much more to SDN than OpenFlow, but people often marry the two concepts together. We leverage open standards where possible at Level 3, and currently, we use several southbound control protocols.

The key thing for us is that we have standard APIs and protocols. The OpenDaylight controller is progressing well, and so maybe we will see OpenFlow featuring more on the WAN.

As for sunk cost of legacy infrastructure, we are not throwing away equipment until it is end-of-life. As long as we can create an abstracted YANG view of that infrastructure and control it within Level 3’s Adaptive Network Control, we can extend the life of this equipment and bring it into the context of dynamic and orchestrated services while we build trust in the next generation of virtualized open-source infrastructure.

East-West APIs enable service orchestration, at the control and management layer, among a network of service providers partners. Programmability of the networks enables the East-West service orchestration.

The MEF’s Presto is the interface to the Southbound APIs that extend control to the infrastructure layer. The LSO OpenCS initiative will leverage standard APIs and orchestrate virtualized network functions The following use cases become possible with Southbound APIs:
The DC (Data Center) or a PoP (Point-of-Presence), based on the E-CORD design, enables hyper-scale switch fabric with commodity hardware and open source software
NFV controls the functions customers want to run in the DC/PoP
The packet WAN utilizes OpenDaylight platform for network control
Concurrently, the optical network layer also needs to be orchestrated
SD-WAN would likely run with NFV within the DC
Cloud interconnects and 5G access for IoT are other useful use-cases
The first five use cases provide the rudiments for a virtualized hyper-scale PoP. So we appreciate the work that the MEF’s LSO initiatives, such as OpenCS, are doing to help get the standards ready for next-generation infrastructure. However, that does not stop us from using dedicated hardware in the meantime to build LSO-based dynamic, agile and assured services.

This article links:
http://www.lightreading.com

阿里云在悉尼建立数据中心,迈向云计算新蓝海

上周,阿里云宣布在悉尼建设一个新的数据中心,以像Amazon、Microsoft、Google等公司一样扩大其在全球云计算市场的足迹,阿里云还打算扩大其在悉尼和墨尔本两地的团队规模。

11月21日,阿里巴巴集团透露,在悉尼构建开放数据中心是该公司作为增加10亿美元云计算投资的一部分,位于悉尼的数据中心是该公司选定的4个地点之一。

阿里巴巴集团副总裁喻思成表示,鉴于澳大利亚中小企业在中国本土市场的实力和规模,阿里云将更容易在本土市场开展业务。在周一的新闻发布会上,阿里云表示其用户能在一个全球账户上管理其不同地区的基础设施。

喻思成表示:“我们拥有覆盖东西方的全球基础设施,我们是真正的全球云计算平台。如果澳大利亚企业想要建立一个电子商务门户,以满足其全球用户的需求,包括澳大利亚市场、中东、中国等,最常见的方式是从云供应商处获得虚拟机再加上数据中心。我们将会是最完美的供应商,因为我们在这些地区都有相应的基础设施。”

阿里巴巴声称不仅在技术上弥补东西方之间的差距,还通过其AliLaunch的商业化计划弥补差距。AliLaunch于8月份推出,帮助合作伙伴克服国际公司扩展到中国时常见的技术和商业障碍。SAP、SUSE、HERE、Hitachi Data Systems、Check Point、AppScale等国际软件服务商入驻该计划为全球用户提供领先的技术和解决方案。

与AWS相比,阿里云的全球覆盖率仍然相当有限,AWS在全球拥有35个可用区域,并且在加拿大,中国,俄亥俄州和英国都开放了新的区域。

阿里云在2009年成为一个独立的实体,在电商、游戏、物流、大数据、安全等领域提供越来越多的云计算解决方案。自成立以来,已经获得了全球超过230万用户,其中涵盖了开发商、中小企业、大型企业,拥有超过65万付费用户。

阿里云的超级计算引擎Aspara在刚刚过去的双十一购物节中投入使用,在高峰期间,它在其电子商务平台上每秒处理17.5万次交易。

从全球市场看,目前云计算行业正在建立高速增长。IDC数据显示,到2019年,全球云计算市场收入规模将达到1410亿美元,比2016年的700亿美元市场规模翻倍。云计算、大数据和人工智能技术作为全球商业变革的新基础设施,正在被越来越广泛的区域和领域采用。

有投行研报显示,亚马逊、微软和阿里云在全球云计算市场上形成了第一阵营。德意志行业报告预估,以2015年营收计算,阿里云市场规模高于Google云,并达到全球第二名微软Azure体量的1/3。

阿里巴巴通常与当地技术合作伙伴合作,在新市场中设置数据中心,以帮助降低资本投资风险,在澳大利亚的合作伙伴是埃森哲(Accenture)。该公司还将在澳大利亚设立一个专门的团队,帮助构建阿里巴巴的本地云生态系统。

目前,阿里巴巴在德国、日本、迪拜、悉尼等设立了数据中心,其阿里云服务可以在全球14个地区提供服务,包括中国大陆、香港、新加坡、美国等。

本文链接:http://www.sdnlab.com

到2022年,软件定义一切(SDx)市场年复合增长率达32%

市场调查机构MarketsandMarkets公司近期发布了一份关于软件定义一切(SDx)的市场调查报告,预测软件定义一切市场份额将从2015年的38.9亿美元增长到2022年的280.9亿美元,年复合增长率为31.72%。

软件定义一切(SDx)的定义是所有的软件定义计算技术,其中软件在控制硬件中起主要作用。这些技术包括软件定义网络(SDN)、软件定义数据中心(SDDC)、软件定义存储(SDS)。

以上技术的进步将迅速推动SDx市场的增长,其他能够推动SDx市场增长的相关技术包括网络资源的动态供应,统一的云计算资源,降低运营成本和服务质量(QoS)实现。

电信和ITES(IT支持服务)行业垂直市场占有率最大,因为它在市场发展的早期阶段采用了SDx技术。该行业一直在使用SDN、SDDC和SDS以提高数据中心资源的集中管理和控制,包括冷却设施和电源等资源。预计到2022年,它将继续占据最大的市场份额。

SDx服务包括集成和部署服务、托管服务和咨询。其中,咨询服务的年复合增长率最高。咨询服务为设置和管理数据中心提供指导,服务除了在数据中心提供最佳资源分配之外,还包括帮助数据中心通过风险最小化实现利益的最大化。

从地区增长上来看,APAC(亚太地区)的SDx市场年复合增长率最高,这得益于中国、日本、印度对SDx技术的认知、技术发展以及采用的增长。该地区也是软件定义基础设施增长最快的地区。

在SDx市场上比较活跃的一些公司包括VMware、Microsoft、Cisco、HPE、IBM、Citrix、EMC、NEC、富士通、Juniper、Western Digital等等。

本文链接:http://www.sdnlab.com

爱立信在模块化组件中提供NFVi平台

近日,爱立信发布了其声称“经过验证的”网络功能虚拟化基础设施(NFVi)平台,该公司此前已经宣布与Telstra,Swisscom,Telefonica和SoftBank在内的多家运营商签署了NFV合同。

但该公司目前公布出来的更多的是将所有的NFVi产品集中在一个模块化的产品上,所以可以将这些功能进行混合和匹配,以适应服务提供商的特定需求。

爱立信的NFVi平台包括硬件和软件,其Hyperscale Datacenter System 8000 (HDS 8000)及其刀片服务器平台(BSP8000)包含硬件元素。软件包括其云计算执行环境、云管理器、云SDN。该公司还提供咨询、系统集成和支持服务。

模块化组件可以部署在不同的场景中,从不同厂商的NFV组件完全解耦到爱立信的全栈。

该瑞典电信设备公司表示,其NFVi平台是电信运营商为5G和IoT构建基础设施的第一步。

爱立信特别推荐在NFV中使用其HDS 8000,它是爱立信与Intel联合建立的monster rack-scale计算/存储系统。

“已验证的”NFVi
当被问及谁验证的爱立信NFVi解决方案时,该公司表示是其用户与厂商合作伙伴合作验证了其解决方案,爱立信还积极参与了几个行业标准化和开源组织,该公司发言人表示:“该解决方案是基于OPNFV参考架构建立的。”

此外,爱立信还积极参与了ETSI的NFV工作组以及OpenStack社区。

原文链接:https://www.sdxcentral.com

Eurobites: BT Rivals Call for Curbs on Spectrum Ownership

Also in Yesterday’s EMEA regional roundup: in-flight connectivity program completes test flight; spectrum-sharing in Russia; Openet gets virtualized.

Five UK operators that are concerned about how much mobile spectrum BT Group plc (NYSE: BT; London: BTA) and Vodafone UK hold have joined forces in a new campaign that seeks to persuade Ofcom ‘s Chief Executive Sharon White to be a “mobile superhero” and place a cap on spectrum ownership. Make the Air Fair brings together 3 UK, TalkTalk , CityFibre , Gamma Telecom Ltd. and Relish (as well as a lobby group, the Federation of Communication Services (FCS) ) in a call for no single operator to hold more than 30% of the UK’s available spectrum. Currently BT (now the owner of EE) holds 42% and Vodafone has 29%, while 3 has 15% and Telefónica UK Ltd. (O2) 14%. Ofcom recently consulted on proposals for how the next batch of spectrum — 190MHz of spectrum in the 2.3GHz and 3.4GHz bands — should be sold, proposals in which it suggested that a cap of 255MHz per operator on “immediately useable” spectrum should appy, ruling out BT from bidding for spectrum in the 2.3GHz band in next year’s auction. However, it did not propose a cap on the amount of 3.4GHz spectrum any one operator could own. (See Eurobites: BT Frozen Out of UK’s 2.3GHz Spectrum Auction and Eurobites: 3 Sparks Rumble in UK’s Spectrum Jungle.)
Airborne connectivity has received a boost with the launch of live testing of the European Aviation Network (EAN), which brings together Nokia Corp. (NYSE: NOK), Deutsche Telekom AG (NYSE: DT), Inmarsat plc (London: ISAT) and Thales SA (Paris: TCFP.PA) in an effort to achieve better broadband for airline passengers. A test flight was conducted in the UK and a live over-the-air connection achieved in Germany, thanks to the adaptation of Nokia’s LTE basestations and remote radio heads to the frequency used for the EAN, provided by Inmarsat. During the flight, tests were performed to see if the network could successfully attach to the ground system, which it did at all four test sites located in the south west of the UK, according to Nokia.
Russian operators Mobile TeleSystems OJSC (MTS) (NYSE: MBT) and VimpelCom Ltd. (NYSE: VIP) have announced the start of their spectrum-sharing in the Cherepovetz, a town in the Vologda region, in a move which they claim will allow them to boost data transfer speeds to a maximum of 150 Mbit/s. Over the next year the pair plan to unite their LTE networks in more than 30 regions, reducing the cost of basestation construction and management.
Openet Telecom Ltd. , the Ireland-based BSS vendor, has launched a business unit dedicated to delivering virtualized services. Openet Accelerate will be based at Openet’s Dublin headquarters.

This article links:
http://www.lightreading.com