SDN缺失环节:五大障碍影响提供商应用SDN

日期: 2013-05-27 作者:Tom Nolle翻译:张培颖 来源:TechTarget中国 英文

软件定义网络吸引了很多云和网络提供商的兴趣,但是很多提供商却由于SDN技术的现状而感到沮丧。大多数大型提供商能够至少运行小范围的SDN小规模测试或者实验,但是都遭遇了大范围部署的问题。那么SDN中缺少了什么?提供商如何识别这些缺失的元素,以便他们能够完全的利用这项技术? 1、缺少全设备控制标准   妨碍SDN采用最显著的障碍就是缺少对于所有设备的控制标准。OpenFlow框架是现在使用的一种事实SDN标准,这是一种单项转发表升级协议,不提供确定设备状态的机制,不允许程序接口或者外线接口。

无法处理非封包流,比如波长流。有人可能会说OpenFlow的这个框架是一些受限实验的副产品,而不是一种机制,……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

软件定义网络吸引了很多云和网络提供商的兴趣,但是很多提供商却由于SDN技术的现状而感到沮丧。大多数大型提供商能够至少运行小范围的SDN小规模测试或者实验,但是都遭遇了大范围部署的问题。那么SDN中缺少了什么?提供商如何识别这些缺失的元素,以便他们能够完全的利用这项技术?

SDN缺失环节:五大障碍影响提供商应用SDN

1、缺少全设备控制标准

  妨碍SDN采用最显著的障碍就是缺少对于所有设备的控制标准。OpenFlow框架是现在使用的一种事实SDN标准,这是一种单项转发表升级协议,不提供确定设备状态的机制,不允许程序接口或者外线接口。无法处理非封包流,比如波长流。有人可能会说OpenFlow的这个框架是一些受限实验的副产品,而不是一种机制,旨在支持通用的网络服务创建。

  很多人已经指出OpenFlow并不能完成基本的设备安装,这也意味着更多传统管理标准,比如简单网络管理协议(SNMP),就必须应用来实现这个目标。这里的问题在于传统管理标准需要完全同这些设备连接。这也回到问题的实质:在每一个路由器必须单独建立时,如何使用?

2、缺少服务控制软件

  SDN技术第二大的问题在于服务控制软件,这项技术实际上在软件定义网络中构建了路由和控制流量。不管提供商考虑的SDN模型是什么,都需要软件链接应用服务到SDN基础架构中。对于云计算而言,这通常是一个和云虚拟网络控制(OpenStack的Quantum)或者DevOps工具相关关联的插件,用于分配云资源。

  即使有OpenFlow和SDN控制器,每一个SDN实现都需要服务控制软件来创建虚拟网络。这是因为SDN控制器仅将路由需求翻译成了一系列转发表变化;他们本身不能创建路由。然而,SDN控制器有时候提供北向应用程序接口,这个服务控制软件可以被连接,一些厂商甚至至少提供了这个软件的基本版本,对于没有基于OpenFlow的SDN实现,每一个网络设备厂商必须提供必要的服务控制软件。这个领域通过互联网工程任务组(IETF)的一些工作在应用层流量优化开发(ALTO)中表现。

3、多厂商网络控制成应用障碍

  上面提到的也为我们引入了SDN采用的第三个障碍:多厂商网络控制。服务控制软件可以在多个厂商网络之上执行控制,通过 OpenFlow、Border Gateway Patrol (BGP)和Multiprotocol Label Switching实现,提供了给软件,让其了解网络情况,按需调整路由的策略。

  对于集中化和分布式的SDN模型,控制软件知道所有网络设备和中继线的状态很重要,不管包含什么设备。协议和标准如SNMP和远程网络监控或者RMON,可以协助收集一些信息,IETF增强功能(BGP-LS)到BGP,还有一些举措,比如基础架构到应用信息暴露或者i2aex,可以提供替代资源。在一些案例中,网络中的示例部署并链接到中央控制软件工具可以提供更多数据。SDN网络状态的遥感测试需求已经推进了一股收购和并购浪潮,因此SDN厂商很可能在这个领域增加产品。

4、集中化网络中管理控制流量

  服务控制软件和多厂商网络遥感技术的结合也阐明了SDN的第四种缺失:在集中化网络中控制流量管理。网络云营商已经指出来自一些应用的网络探头的遥感流量快要超过实际的应用流量了。在任何SDN模型中,信息在哪里收集起来支持中央网络行为监控,就应该在这些价值和交付过多信息给中央点之间有一个平衡。

  网络运营商早就提出虚拟化网络功能,会进一步增加网络中的控制流量总量。但是网络功能虚拟化也创造了SDN的替代架构,分层分布流程的混合物,关注与没有集中化流量和失败点的决策。

5、需要边界功能

  最后的SDN缺失也许最为阴暗,因为很可能影响所有实际的SDN部署。企业和网络运营商最可能在单独的网络领域发布SDN,而不是在全球范围内。没有具体模型的服务控制软件,软件定义网络要多久才能够扩展还不明朗。如果SDN区域包围在遗留网络中,如何处理边界功能?内部SDN实现一个IP网络为例,必须提供IP网络和发现信息,必须从遗留网络中获得可到达能力和拓扑数据,从而让服务控制软件来管理SDN路由。网络如何提供这些信息?多种SND包围的区域如何互联?IETF在草案中考虑了后一个问题,旨在进行SDN互联,或者SDNi。

弥补SDN代沟

  这些缺失的内容导致了早起SDN应用受限:数据中心。如果SDN取代了数据中心以太网交换机,明确规定每一个路由变得很实际,甚至是创建一个单独的网络控制来链接设备管理链接。随着其采用逐渐扩展到数据中心之外,SDN需要支持临近的遗留网络组建和描述自己服务的架构框架。提供这种扩展需要分辨所有的SDN缺失链接。

  提供商想要修复这些缺失部分需要根据他们选择的SDN模型选出最佳的方法。对于那些对于集中化、基于OpenFlow的SDN模型感兴趣的人来说,标准的最佳信息源就是Open Networking Foundation网站和相关会议。

翻译

张培颖
张培颖

云计算网站编辑

相关推荐

  • OpenStack Neutron和Dragonflow使能SDN

    随着OpenStack社区不断地改进其软件定义网络功能,Neutron和Dragonflow将发挥怎样的作用?OpenStack云平台的网络功能继续快速演进着。

  • SDN还不是解决混合云网络瓶颈问题的答案

    虽然SDN具有为混合云优化企业网络的潜力,但是它的技术及其周围的生态系统仍处于不成熟的阶段。

  • 未完成:OpenStack自动化发展进行时

    许多企业正在转向OpenStack作为他们的下一代云计算平台。尽管不少公司已经作了前期试验性安装,但从一个试验阶段过渡到大规模的OpenStack部署对一些公司来说并非易事。

  • 青云SDN/NFV 2.0:平衡的艺术

    近日,记者获悉2016年初,青云QingCloud北京三区(PEK3)将正式开放运营,其中最大的亮点在于其网络层面的升级,并将这种新升级的网络架构称之为SDN 2.0。