通用CPE（uCPE）究竟是否通用？

去年12月，IDC预测uCPE和虚拟CPE（vCPE）市场将达到数十亿美元，预计今年这个数字将保持不变，甚至可能有所上升。这些预测将再次推动SD-WAN领域的软硬件厂商，促使他们加大投资，在这个有利可图的市场上占据大部分份额。然而，在uCPE的世界中，依旧存在着许多挑战。

缺乏uCPE标准化

虽然uCPE被吹捧为可以轻松地动态加载或卸载软件的通用白盒 - 毕竟，这是它名字的一部分，但现实是，目前还没有一套一致的规范来处理它们。许多制造商声称任何运行通用x86或Arm cpu的边缘设备都是白盒，而一些服务提供商则对使用FPGA或ASIC来实现经济高效的加速持开放态度。

Verizon早在2016年就与ADVA合作，定义了一个uCPE白盒平台。AT＆T已向开放计算项目（OCP）提交了XGS-PON和G.fast的边缘设备CPE规范以及开放式CPE规范。AT&T希望通过OCP来创建一个uCPE标准。然而，OCP电信项目并不包括Verizon或其他主要电信公司提交的任何边缘标准。

英特尔还推出了针对uCPE的英特尔精选框架的自身标准，并利用Advantech和Lanner等合作伙伴将其版本推向市场。与此同时，戴尔EMC希望将服务提供商以及SD-WAN和其他网络解决方案提供商集中到其SD-WAN的标准uCPE中。

尽管如此，大多数服务提供商仍在自行解决问题，并制定自己的标准。他们的目标是降低成本并提高灵活性，确保长期不会锁定任何SD-WAN或VNF厂商。如果服务提供商有足够的容量，他们就不太关心uCPE是否标准化，因为他们可以从生产规模中获益。无论如何，通用CPE的战斗将继续下去。一方面是x86和Arm之间的争斗，它们都声称拥有更好的价格、性能和效率。另一方面，所有不同的厂商都试图平衡对标准组织（如OCP）的参与，同时在自己的平台上仍然是赢家。

uCPE and vCPE Architectural Dichotomy Plays Smaller Role

考虑部署体系结构也很重要。 SD-WAN和其他VNF功能可以驻留在各种位置。虽然客户端的uCPE当然是一种选择，但这些功能也可以通过中央办公室/存在点位置（CO/POP）或云数据中心中的容器或虚拟机（VM）托管在共享硬件上。某些功能（如WAN优化或缓存）可能需要在本地分支设备上存在，但高级安全扫描可以在分支外完成。这种方法不仅可以带来规模经济和成本节约，还可以提高可管理性。

ZScaler就是一个很好的例子。它为云端的企业构建了一个运行托管安全解决方案的良好业务，并与许多SD-WAN厂商合作。在这方面，一些VNF厂商吹嘘他们有能力在任何地方执行功能：在云中、在CO/POP以及在uCPE上。其他人则更进一步宣称能够在站点之间进行协调并根据需要动态迁移VNF。最近很少有关于正确地部署架构或者是混合方法如何有意义的讨论。解决方案通常存在于云端或uCPE中，而在CO/POP中使用VNF的轻量级CPE似乎不太受欢迎。服务提供商告诉我，这是因为企业需要在uCPE上运行得更好的功能，例如本地云突破或WAN优化。对于服务提供商而言，更容易专注于以uCPE为中心的单一架构，并通过云端服务（OTT）为高级服务进行增强。也许，uCPE在未来会成为现实，并且，CO/POP中具有聚合的、高密度VNF的轻量级CPE的替代架构将会随着时间的推移而下降。

缺少开源uCPE操作系统

从硬件转向软件，服务提供商抱怨的另一大问题是缺乏开源CPE操作系统。大多数CPE解决方案使用基于内核的VM（KVM）进行虚拟化，并添加一些容器支持。然而，底层操作系统仍然阻碍着它们。大多数人都认为它将基于Linux，但设备管理、基于云的管理和遥测的其他必要功能仍然是个挑战。

2018年3月，AT＆T将其分布式网络操作系统（dNOS）代码库（包括从博科收购Vyatta的资产）托管给Linux基金会。这导致AT＆T使用其dNOS代码来开发分布式网络操作系统（DANOS）项目，该项目还利用了其他开源项目，如Free Range Routing。 DANOS旨在成为一种面向边缘设备的开源操作系统。然而，目前Github或其他开放存储库尚未发布任何版本，尽管其已经承诺在2018年下半年提供可用代码。

2018年10月，AT＆T向OCP提交了白盒蜂窝基站网关路由器的规范。引人注目的是，在推出该平台时，它将基于Debian的Vyatta加载到其路由器上，表明Vyatta操作系统已经经过了产品硬化 - 这意味着DANOS尚未做好准备。希望我们最终不会跟DANOS玩一场“Waiting for Godot”的游戏。

一些SD-WAN厂商正在利用完全集成平台的易用性，这降低了服务提供商SD-WAN部署的复杂性。这些厂商在零接触配置、高级远程故障排除和监控以及基于云的CPE管理方面进行了投资。不幸的是，这意味着服务提供商被锁定在SD-WAN厂商的软硬件平台上。现在服务提供商RFP要求SD-WAN提供商支持服务提供商的首选uCPE平台，这是避免厂商锁定的一个步骤。但DANOS将为服务提供商提供更多的控制权；允许他们修改它以便在他们的uCPE上使用，将SD-WAN和其他VNF厂商限制在可以随意更换的软件包范围内。

臃肿的VNF导致服务提供商更加消化不良

从操作系统转移到网络功能，我们发现臃肿的VNF，特别是SD-WAN，是服务提供商中最常见的投诉之一。他们正在努力降低uCPE盒子的成本。与下一代防火墙（NGFW）等安全设备相比，它们最终需要在相同的范围内实现价格和性能。服务提供商1500美元或2000美元的uCPE与500美元至800美元的NGFW的网络性能相差无几。此外，服务提供商对于管理60到80GB的SD-WAN和其他VNF映像，以及仅为了SD-WAN/NFVI管理开销而牺牲2到4个CPU内核感到十分痛心。他们担心边缘盒上放8个x86内核是不够的，但又不想使用16个内核，因为价格太高。随着时间的推移，随着SD-WAN和VNF厂商减少他们的软件占用，情况将会有所改善，但这对于今天的uCPE部署还是造成了额外的拖累。

从长远来看，uCPE可能是许多SD-WAN部署的首选模型，但仍有许多问题需要克服，如安全、标准化遥测和可信平台模块 - 这些对于企业中的可信WAN来说可能是必要的。希望OCP、Linux基金会和其他开放标准组织能够在全行业范围内作出努力，推动市场向前发展。希望DANOS向公众发布的代码将改变现状，并为更加通用的uCPE增加动力。

原文链接：https://www.sdxcentral.com/articles/analysis/sd-wan-theres-nothing-universal-about-the-universal-cpe/2018/12/?c_action=home_analysis