架构师：电信公司NFV商业化道路的阻碍

Saad Sheikh，沙特电信公司首席架构师顾问，主要负责CSP数字化转型的网络部署和规划，涉及NFV、SDN、Telco Cloud、5G等领域。

自2012年以来，CommSP向虚拟化的转变已经开始，但5年之后的今天，我们还没有发现在NFV/SDN上运行的大型工作负载。有明确的迹象显示，厂商正间接指出要么转向Vendor Siled NFV解决方案，要么放慢NFV商业化的速度。也有人认为，随着NFV流量的增加，性能将会降低。换句话说，开放式NFV解决方案无法大规模满足电信服务需求。

在本文中，我会从标准化/技术和业务架构两个方面列出最主要的障碍，我个人建议的方式是向SDO/社区提供反馈以解决这些问题。总而言之，Telco不能通过模仿而成为IT公司，而是需要为Telecom找到全新的IT方式，因为我们Telco有两个复杂的任务，以无缝的方式发展现有网络，并向第三方和应用提供商开放我们的网络。

1：从Play Store到ONAP的过渡

抢先固然是好的，但我们是否真正衡量了我们应该通过NFV实现的目标，即服务敏捷性和从几个月到几个小时的交付。不幸的是，目前的成熟度仍然很低。凭借多年的NFV和传统应用程序虚拟化的经验，许多厂商声称他们的VNF已经为云计算做好了准备，VNF应该是基于微服务的，并支持自动LCM，它应该以无缝的方式顺利地与传统应用程序协同工作，NFV应用程序也必须支持与移动应用程序相同的概念，这适用于所有市场。

到目前为止，VNF认证还没有实现自动化，尽管ETSI插件测试已经改变了这种情况，但CommSP仍然完全依赖厂商进行VNF认证，并根据我们与领先厂商的经验将其集成到网络中。我们仍然认为，厂商对于开放标准跟API的理解并不一致，ETSI NFV ISG已经做了很多工作来解决这些问题，但至少这部分不是PnP且缺乏自动化。总的来说，NFV解决方案组件一致性测试的结果与互操作性不同。电信服务通常对性能和可用性要求很高，通常需要5个9的可用性。因此，在软件中部署服务时，监控和验证非常重要，尤其是在出现故障、错误和人为失误时。

同样，随着越来越多的应用程序进入云，Telco和IT统一云的情况是必需的，特别是考虑管理和迁移方面。然而，隔离和安全问题仍未达成一致。即使所有厂商都声称其符合安全性，但也无法在现场试验中进行验证。

总的来说，标准化/学术界和产业界之间似乎仍然存在差距，这意味着技术实践与营销手册中描述的并不一样。

2：NFV规模中的性能问题在于VNF

我们仍在努力解决的最大挑战和问题是，NFV能否大规模运作。意思是如果我们在vEPC上放置100Gbps流量，是否与放置1Tbps相同？随着服务提供商精心策划的虚拟化，这个问题被进一步淡化。即使是作为先锋的AT&T也没有真正加快迁移的速度。基于实验室的试验，我们认为大规模的NFV不能在最佳状态下工作，它会影响客户体验。它的成本由服务提供商承担，其形式包括基础设施规模过大、服务和许可模式错误，根据RedHat的最新调查，这些成本增加了36%。

情况变得更加复杂，因为仍然没有一个成熟和开放的测试框架，服务提供商再次寻求厂商来执行和验证他们自己的解决方案。我认为除了拥有强大研发和行业实力的电信公司之外，这不是一个容易快速解决的问题，它将继续阻碍NFV网络大规模商业化的所有努力。跨NFVI实现的可移植性机制和管理可以有多种虚拟化方法，多个NFVI和多个MANO系统。如何支持跨不同平台的无缝迁移是一个挑战。

使得NFV性能在规模上难以实现的另一个方面是，来自不同厂商的特定容量的VM布局各不相同，因此部署在单个强大的VM或多个VM上不会导致相同的容量。最后，为了揭示人们在现实网络中体验到的实际性能，我们需要测试不同的网络流量，不仅使用普通虚拟流量来测试吞吐量而且还有应用感知流量，目前有一些成熟的NFR测试工具，但是不适用于FR，并且客户需要大规模的功能测试和性能验证。

我们需要了解的另一个领域是SDN，作为NFV的推动者，它不在基础设施中，而是在应用程序中，用于大规模提供NFV性能。将VNF无状态信息从应用程序(如LB)、处理层转移到交换层(如SDN)可以极大地提高性能，但是这种方法需要强大的微服务架构，对于Telco来说仍然不够成熟。

3：可编程网络真实目标

真正的目标不是可编程，而是自动化网络。但是，如何在没有正确建模的情况下对网络进行编程。目前存在的问题是程序员和电信专家之间存在差距。 ONAP正在通过引入易于使用的工具来缩小差距，这些工具允许服务提供商在不了解太多详细编程的情况下实现网络自动化。 ONAP Service Logic Interpreter Directed Graph Guide (DG)就是这样的一个例子。点击查看详情
https://wiki.onap.org/display/DW/Service+Logic+Interpreter+Directed+Graph+Guide

在网络编程过程中，我们需要考虑的另一个方面是服务功能链。目前，SFC应用于VNF间的链路或转发图，但是在微服务架构中，同一个VNF中可以有“N”个组件/模块，如何链接这些流，需要对目前正在进行标准化的intra VNF和inter VNF流进行校准。完整的端到端设计订购和并行对于整个服务链的性能和正确性至关重要。

4：与IT同行相比，NetOPS仍然不够灵活

我们所谓的NetOps仍然不够灵活。Scrum和New Service TTM仍然无法实现其承诺。在SDXcentral最新调查中，应用自动化（40%）远远超过了网络部件自动化（20%）。换句话说，大量的手动工件使得CI/CD管道的端到端解决方案难以实现。事实上，DevOps的成功更多的是与工具集的紧密集成联系在一起的，而目前电信行业尚未对其进行规范化。对于NetOps 来说，情况并非如此。借助多厂商网络架构，他们面临着尝试强制适应各种API和数据格式，以便无缝地协作从而在部署管道中部署所有组件。

“DevOps通常就是开发人员；他们非常善于为任何问题编写解决方案。另一方面，NetOps是高度熟练的网络专家。网络中的集成是关于协议的互操作性，而不是插件和API。对于大多数NetOps来说，这是一个完全陌生的世界，现有的工具和框架并不适合构建持续部署管道所需的集成类型”。从NetOps在网络自动化方面所面临的挑战中可以清楚地看出，他们自己是无法赶上与他们相对应的DevOps同行的。这意味着整个网络行业必须做的不仅仅是提供API和自动化示例，还要加强对社区、支持和培训方面的挑战，这些方面既要注重编码和持续部署的基础知识，也要关注与特定设备的接口。

5：MANO和Orchestration似乎非常复杂

如果电信公司要实现其最终的虚拟化目标，它必须是自动化的，而除非您真正地编排了您的网络，否则这一目标是无法实现的。这是一个现实，它需要太长时间才能获得一个好的商业MANO产品。事实上，在ONAP/ECOMP方面，甚至连AT&T也是从完全关闭的编排器开始的，因为目前还没有一个开源项目已经准备就绪。

Cable Labs认为，只需在您的编排器和VIM和VNF之间做一个抽象层。对于堆栈的这一部分，解决方法并不是那么糟糕。API正在成为事实上的标准。在堆栈越低的地方，就越适合开源。

编排和网络服务建模的问题仍有待解决，我们需要从ONAP和OSM演示转向现场试验。ONAP将是Telco的最终命运，这是一个共识，但由于Telefonica在OSM方面处于领先地位，而且在标准化方面(尤其是在信息模型方面)的要求是NFV运营的关键要素，我们仍然不清楚市场将如何发展。

ONAP在网络和信息模型建模方面的细致工作，是否能让我们认为ONAP会抢到NFVO的蛋糕，而OSM会走端到端的编排器这条路?

厂商不可知的网络功能和服务模型仍然是一个公开的争议，特别是考虑到许多厂商不愿意免费分享他们的VNF元模型或工件。直到最近，电信界有一个很大的争论，来自IT界的YANG是否也应该成为标准建模语言。目前得到较为广泛的认可的观点是结合TOSCA和YANG集成的能力，因为这种方法似乎是这两种标准的最佳结合—TOSCA负责服务生命周期，而YANG控制VNF的网络配置。

6：硬件加速路线图

共享存储器、片上系统和FPGA是真正能使服务器成本模型吸引NFV投资的技术趋势。然而，英特尔Virtio智能网卡的标准化有点晚了。即使截至本文撰写之日，它也不支持Off load，因此基于OVS+DPDK处理的统一NFV解决方案更难使用它。这使得业界只能选择依赖SRIOV的智能 网卡，它不是一个可扩展的解决方案，因为它需要VNF的投资和定制/支持，并最终使得很难制造出我们的目标 - Light VNF。

为了优化运营商NFV的最佳容量和CAPEX投资，将智能网卡用于数据平面VNF是非常重要的。

7：架构限制

截至目前，许多VNF都假设他们是在并置数据中心中部署的。这意味着不同的VNFC无法跨数据中心进行拆分，也就意味着难以支持高内容和延迟应用程序。3GPP CUPS架构是应对这一挑战的一个方向。必须使用各种分布式协议和一致性机制来支持完全分布式的NFV实现。一些网络功能，例如传统的3GPP和电信NF，由于它们不是模块化的，因此不易扩展。重新考虑其设计以适应新的云架构非常重要。我认为在SDN/Networking和Cloud VNF中使用VxLAN和L2 E-VPN隧道必须支持其部署是分离的数据中心。

8：开源标准化的问题

将CommSP从SDO转变为开源方式看起来很清晰，主要是因为除了顶级运营商之外，大多数运营商都没有相关的团队和支持机制，如研发、社区参与，从而使整个链能够运作。结果是，即使是开源社区也被那些投入大量资金的厂商所左右，他们的目的是让开源社区朝着有利于他们的方向发展。我认为服务提供商需要在大规模多域、多厂商部署的NFV/SDN和OpenStack、OPENFV和ONAP中实现持久的互操作性。同样，跨组织合作对于为运营商创新营造一个蓬勃发展的环境以及减少开放NFV/SDN解决方案带来的碎片化问题也至关重要。类似地，网络建模和服务编排将是运营商通过这种转换可以实现的真正价值，但到目前为止，API公开和信息模型标准化看起来似乎是阻碍大规模部署的关键。

9：服务是领导开放解决方案市场的关键

根据ABI Research的数据显示，在NFV基础设施方面的支出，包括服务器、存储设备、交换机、SDN和Cloud将随着时间的推移而下降。与此同时，软件和服务的增长率分别为55％和50％。即使在今天，标准化和多厂商参与的挑战仍然停滞不前，并且已经为大规模运营商级部署做好了准备。所有这一切的结果是，NFV并没有兑现其蚕食PNF世界产品的承诺，而是仍然在现有的传统网络上进行投资。不成熟的服务和系统集成商的问题陈述将涉及CommSPs在计划重复投资后能维持多久。

“强烈建议将服务，特别是系统集成与NFV/SDN解决方案的产品在实践中分开，将重点放在CoE和与ISG相关的内部研发能力上。”

服务与独立测试框架相结合，必将支持NFV的大规模快速商业化。

10：为什么成本是第一指标

NFV/SDN可能是行业中最好的技术，但事实上，如果一个技术不支持业务目标，那它可能不适合在商业网络中使用。根据最新的分析预测，在采用NFVI、VNF、MANO的多厂商解决方案时，运营商的成本可能会是在PNF中的5倍。目前，主流厂商仍然试图以与过去销售传统产品相同的方式销售许可证和服务，因此作为KPI的成本指标肯定无法提供有意义的信息。相反，TTM、自动化、新产品提供似乎才是分析NFV/SDN ROI的正确指标。但是这些好处很难量化，使得对新技术领域的投资有点困难。到目前为止，CSP的大部分投资将达到资本支出的80%-90%。这就偏离了云的商业模式，主要是OPEX。这是对运营商传统经营方式的转变，它可以扭曲NFV带来的货币利益，使其更难掌握。要想尽快解决这个问题，重新平衡CAPEX和OPEX之间的投资是关键，尤其是在NFV/SDN中有许多基于S&S和订阅的模型。

11：为什么NFV/SDN许可不是最佳的

五年后的今天，VNF应用程序仍然不是适合于云应用程序的最佳实践的许可证。它仍然没有标准化，我们只需要依靠Procurement谈判，看看我们是否可以从专有的VNF模式转变为诸如按使用付费、按GByte付费、按Gbit付费，按活跃用户付费（SAU）、按最高限度付费，按日付费、按月付费和按分钟付费。将多个VNF许可添加到组合中，可能会使它变得非常糟糕。

针对NFV的集中式许可管理器的问题仍未标准化，因此运营商需要服从大量的许可，每个许可证都要由它自己的厂商进行特定的管理。这导致bit运营商将其NFV/SDN程序的选择限制在2~3家厂商，从而阻碍了ISG和小型利基企业的发展。

关于在NFV中管理的许可证的主要建议可以总结如下：

总结

如果我们这个行业的目标是实现网络自动化，并获得可行的生态系统，那么我们仍然需要NFV开放性支持理念作为关键推动因素。有一些大型厂商提倡Siled解决方案，这看起来似乎很容易实现，我们应该重申这些并不是NFV解决方案，而是像ATCA的阶段2解决方案。如果我们这个行业不通过开放和协作的力量来增强我们的网络，即使十年的投资也不会使我们成为一个软件风格的公司，而这正是我们最初的目标。

因此，在我们计划虚拟化网络的过程中，我们必须确保整体数字化转型仍然是核心和焦点。我们参与Openstack、ODL、OPNFV和ONAP等关键开源项目将是实现我们等待已久的未来的关键。最终，如果NFV不允许CommSP减少其基础设施、管理和特殊许可成本，客户将无法提高他们总体拥有成本（TCO），并且采用起来也会很慢。要使多厂商NFV/SDN解决方案看起来像专有解决方案一样，并且考虑到混合云的趋势，其运营/管理统一起来仍需要时间。我们是一个处于转型阶段的行业，事实上，我们还是一个仍在等待NFV/SDN经济体能够实现几乎可与传统世界的应用相媲美的行业。只有这样，NFV才会真正形成主流解决方案。我们都知道这种情况最终会发生，但我们如何去做，才会最终决定它多久会真正发生。

最后，我只想分享我的想法，就像电信公司的IT一样，如果电信公司能够灵活地遵循NetOps方法，那么应用程序的编写方式和LCM的管理方式将是关键。不幸的是，到目前为止，业界已经开始了一场关键的转型之旅，采用自下而上的方法，从他们所知道的开始，厂商重新利用现有的编排产品，这导致了架构的崩溃。换句话说，他们使用了相同的老方法，却期望获得新的结果。这种方法需要以自动化的方式进行更改。

1. https://events.linuxfoundation.org/wp-content/uploads/2017/11/Akraino-Technical-2.Overview-OSS-Shane-Wang.pdf
2. https://slideplayer.com/slide/11834236/
3. https://www.networksasia.net/article/iot-5g-and-significance-fiber.1515370319
4. ONS2018 Summit slides - Accelerate-the-VNF-Integration
5. https://www.sdxcentral.com/articles/news/perhaps-mano-is-irrelevant-for-virtualized-carrier-networks/2018/09/
6. Towards an NFV enabled SDN Architecture
7. https://www.linkedin.com/pulse/vnf-interoperability-challenges-dave-duggal/?lipi=urn%3Ali%3Apage%3Ad_flagship3_messaging%3BmzxRR7lfSTSLAkmPWY6QGA%3D%3D

原文链接：https://www.netmanias.com/en/?m=view&id=blog&no=13968