vCPE 2.0——开放vCPE架构的业务用例

目前已经有大量的文章在描述虚拟CPE(vCPE)的优势,简化企业广域网(WAN)的复杂性激发了许多网络工程师和企业IT管理员的想象力。能够通过自助服务门户和自动化来消费、配置和管理WAN及其服务的愿景使得vCPE成为最常见的网络功能虚拟化(NFV)用例。

另一个主要驱动因素是通过使用低成本CPE设备和网络服务节省成本。对于通信服务提供商(CSP)来说,它能够创建灵活的服务。自动化服务创建并实现资产的虚拟化。

看起来这个计划非常完美,然而当我们开始部署这些解决方案时,我们意识到现实更加复杂。此外,vCPE服务在某些情况下无法实现成本节省,甚至会更昂贵,且质量更差。

在本文中,我将尝试揭开vCPE的成本模式,并提供一种替代方法来构建一个更具成本效益和创新的vCPE解决方案,并提供CSP为保持相关性所需的灵活性和适应性。

为了更好地理解CPE成本模型并向vCPE演进,我们看一下传统WAN服务是如何交付的。WAN服务围绕三个要素构建:CPE、网络和提供服务的电信公司。价格是基于CPE设备中内置的服务功能、价值和可靠性以及相关的网络连接、带宽和服务而定。因此,可靠的服务的企业必须投资昂贵的CPE设备和可靠的网络服务(MPLS)。

这是模式:服务(CPE+网络)x站点数=每个站点每月的总成本,网络指类型(如MPLS)、带宽和服务(如MPLS VPN)。

架构如下:

Photo Source: Gigaspaces

回顾2012年,NFV的出现并向vCPE演进,当时想法非常简单:转移功能、价值和成本……

  • ……从网络边缘到云端
  • ……从硬件到基于软件的功能
  • ……从MPLS到OTT网络和网络接入
  • ……从劳动密集型交付到自助服务和自动化

新架构如下:

Photo Source: Gigaspaces

为什么我们没有获得预期的成果?

我们将探讨在这个演变过程中三个主要解决方案的元素发生了什么变化。

CPE

价格下跌且市场商品化正在进行。然而,我们还不能通过50美元的白盒机提供类似于传统CPE的功能,主要网络厂商不支持这种演进,事实上通过将服务与特定的专有CPE设备绑定很困难。

网络

大多数vCPE解决方案利用OTT网络,例如软件定义广域网(SD-WAN),理论上是降低了带宽成本。随着企业提供来自非传统服务提供商和网络厂商的OTT网络解决方案,传统的CSP将被迫采用这种技术并占据现有的广域网收入。

云计算/VNF

这是一个极具挑战和误解的问题,在提供积极的服务体验的同时运行虚拟网络功能(VNF)既昂贵又复杂。

构建企业WAN服务需要提供以下网络功能:

  • 路由堆栈
  • 安全和统一的威胁管理
  • 服务质量
  • 应用程序可视化
  • 内容管理
  • 等等

在专用硬件上构建其解决方案的窗台网络供应商被迫快速采用软件模式。大多数供应商通过简单的提供“虚拟设备”采取了简单的方法,这与硬件解决方案有相同的代码库,并在管理程序上的软件中运行。这些虚拟设备中的大多数与硬件具有相同的特性:

  • 封闭或专有管理接口
  • 缺乏服务和弹性性能
  • 传统的成本模式和许可
  • 重虚拟化足迹

我们再次将这些元素放入我们的成本公式:服务(CPE+网络+VNF)x站点数=每个站点每月的总成本。

将VNF元素添加到成本公式是极具挑战性的,并且在很大程度上被曲解。要了解VNF的实际成本,我们需要考虑以下内容:

  • VNF许可
  • 虚拟基础设施(CPU、RAM、存储)
  • 管理和编排

第一代vCPE解决方案由传统网络供应商推动turnkey解决方案,他们的解决方案为COE提供网络设备、VNF和业务流程架构,这些解决方案具备如下优势:

  • 更快的上市时间
  • 降低前期成本
  • 开放的API
  • Turnkey集成

Turnkey=Lock-in

第一代vCPE解决方案都有不好的一面:锁定(Lock-in)。Turnkey vCPE解决方案只是一种封闭且昂贵并且严格锁定厂商收入模式的网络盒子。我们最终得到了一个CPE商品化和OTT网络节省超过传统VNF成本增加和运行它们所需的基础设施的解决方案。

Photo Source: Gigaspaces

前瞻性思考

正如Nati Shalom在之前的SDxCentral文章中所写的,开放是发展的方向,我仍然相信集中网络功能和价值是建立vCPE模式和成本节省模式的正确方法。但是,实现这一目标的唯一方式是使用创新的云原生功能,下一代vCPE将建立在以下网络功能的基础上:

  • 基于标准和模型驱动
  • 服务和弹性容量
  • API驱动
  • 开放和可扩展
  • 使用成本节省的云模型

早期的开源选择

vCPE架构是由开源的cloudify支撑的,是一个开放的NFV编排平台,使得CSP能够根据这些原则提供下一代vCPE解决方案。CSP可以利用任何CPE设备,使用任何网络服务,利用搭载的VNF构建vCPE解决方案。下一代云原生网络功能市场正在快速增长,我们在传统基础设施和许可下使用的功能已经能够提供部分增强的服务,容器技术也逐渐广泛应用于网络功能。

Photo Source: Gigaspaces

未来的vCPE模式

开放的vCPE架构强调编排和模型驱动的服务设计。这与设计成为自下而上的Turnkey解决方案截然不同,后者从堆栈组件开始,并构建一个仅与这些组件一起使用的编排架构。Cloudify模式驱动的拓扑和编排规范的云应用程序(TOSCA)的编排采用自上而下的方法。它假定服务的组件将随时间而改变,但服务和编排的方式不会改变。

有以下几个有点:

  • 轻松采用新技术(VNF)
  • 服务敏捷性
  • CSP服务差异化
  • 增强用户体验
  • CSP解决方案所有权

为什么运营商需要开放的vCPE架构

在商业上,成功的模式必须采用一个能够驱动所有解决方案元素(包括CPE、网络和VNF)的架构,实现成本降低。他们必须快速拥抱创新,以抓住CSP从中获益的新机会、能力和模式。构建未来网络的唯一方法就是保持开放。

原文链接:https://www.sdxcentral.com/articles/contributed/vcpe-2-0-business-case-open-vcpe-framework/2017/01/


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/18511.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于17-02-03
0