电信运营商和通信服务提供商（CSP）一直期待网络功能虚拟化（NFV）和软件定义网络（SDN）能够带来的优势，帮助他们进入快速部署新服务，实现高度的网络自动化和域的动态重新配置，从而降低CAPEX/OPEX并简化配置和管理。为实现这一目标，业界发起了各种开源计划。欧洲电信标准协会（ETSI）推出开源NFV管理与编排（MANO）架构，吸引了大量Tier1CSP和厂商加入。其中一些CSP已经进行了现场试验，甚至一些Tier1运营商已经在其现有网络中通过SDN和NFV实现了部分虚拟化，解决方案供应商也创建了增强的NFV/SDN平台和优化的虚拟网络功能（VNF）。然而，由于这些复杂的开源项目，行业变得非常碎片化，因为每个开源项目都有自己的优势，这导致了CSP的混乱。影响SDN/NFV优势的潜在问题也没有得到解决。状态：多个开源SDN/NFV计划导致混乱。当前，在采用多种NFV/SDN开源路径时，CSP面临“选择障碍”。会合并到ONAP的OSM）ETSI，可以选择OPNFV。虽然ECOMP和Open-O的合并是否会成功还有待观察，但可以预见的是，ONAP将在NFV管理和编排领域与ETSIOSM展开竞争。与此同时，MEFLSO等新举措正在受到业界的关注，包括与运营支撑系统（OSS）/业务支撑系统（BSS）的深度集成。在SDN方面，成熟的开源倡议包括ONOS和ODL。这些开源项目由权威组织、社区、供应商和几家一线CSP主导和推动，这使得大多数CSP难以选择一个开源项目或多个开源项目的组合。CSP更希望通过开源避免厂商锁定，但CSP也希望看到SDN/NFV带来的更快的生产路径，保证性能、可扩展性和长期支持的优势。系统集成商并不总是对CSP采用SDN和NFV有帮助，一些系统集成商将CSP作为自己学习的研发实验室。通过支持多个开源计划，系统集成商可能会尝试在多个项目中分离第1层用户。挑战：需要解决的基本问题在尝试选择SDN/NFV路径之前，CSP需要澄清并回答以下问题：NFV/SDN虚拟化网络能否通过在数据中运行的COTS硬件满足和扩展网络带宽需求的增长中心？CSP能否采用一个或多个开源项目并在短期内以经济高效的方式将其投入生产？在部署SDN/NFV系统时，CSP是否可以访问适当的测试系统和工具来验证和量化性能指标？CSP是否可以为NFV/SDN虚拟化网络系统制定明确的规范以满足性能要求。SDN/NFV是否与CSP的传统网络系统集成，提供统一的仪表盘和监控视图？传统网络工具和虚拟化网络工具如何融合，提供全网统一视图？CSP如何确保选定的开源项目在未来得到使用？十年左右能不能不断升级进步？谁来保证开源项目的不断升级和进步？系统集成商、组件供应商、开源社区或相关开源组织？SDN/NFV虚拟化网络后期支持、升级、托管服务的复杂度真的低于现有的传统系统吗？比如目前管理私有云数据中心的安全，其中NFV/SDN系统的托管管理比管理分布式网络系统复杂很多，管理混合网络比管理现在的传统网络更复杂，是不是不够灵活？SDN/NFV系统如何满足CSP在SLA、QoS、服务保障、高可用性和可靠性方面的需求？能否在虚拟化/混合系统中量化相关参数？如果不是，新标准是什么？不同厂商开发的个体VNF使用的微服务、容器、DevOps、RESTAPI规则能否与MANO接口规范一致？CSP能否在不面临威胁的情况下安全地运行其SDN/NFV系统？例如，SDN控制器的集中化实际上可能会暴露出更多的安全漏洞。以此类推，NFV堆栈具有由不同供应商创建的操作系统、管理程序和VNF。CSP是否需要全面分析各个层面的安全漏洞并进行修复？在传统的硬件网络中，CSP已经实现了十多年的网络带宽快速增长。虽然传统的系统管理变得非常复杂，但是这些传统的硬件可以非常可靠的运行，CSP可以设置SLA。新的网络设备解决方案还配备了一系列网络自动化工具，便于配置和管理。NFV/SDN系统不仅要让系统更易于部署和管理，还要满足各项性能指标和未来网络带宽需求。前进方向CSP在做出最终决定之前，需要评估开源社区、系统集成商和解决方案提供商的开源计划的可持续性、性能、规模等。CSP可能还需要咨询可以独立测试和验证虚拟化/混合网络的公司，同样，解决方案提供商需要构建测试架构来验证虚拟化/混合网络性能指标。开源计划必须由目标驱动，目标是大多数CSP可以在生产中使用它。标准组织需要继续关注加强接口/API层，以实现来自不同供应商的组件的集成和互操作性。CSP还应关注经过现场测试、可扩展且已引入网络自动化的供应商解决方案。未来几年，CSP网络必须跟上带宽需求的增长，需要在硬件驱动的网络解决方案和基于NFV/SDN的虚拟化方法之间取得平衡。基于COTS硬件的NFV/SDN可能无法扩展CSP的能力。网络以满足不断增长的带宽需求。
