SDN和NFV之“现状挑战”和“未来趋势”
SDN与NVF的理念与目标旨在基于现有网络与计算资源的基础上，并采用Fabric架构实现业务与网络服务的快速部署与扩展。SDN主要侧重于控制层与管理层面的有效分离性管理策略设计 ，而NFV则专注于网元功能的虚拟化部署方案的研究与优化。
如今SND主要由思科（以自身网络硬件为基础）和Vmware（并整合了自身的NSX软件）两大阵营构成。此外，还有其他类型的SDN解决方案。下面将逐一介绍这些方案。
思科采用以应用为中心的基础设施（ACI）方案，在该架构中重点阐述了网络数据平面与控制平面的分离机制。 northward interfaces实现了应用对控制器策略的可编程性, 而 southward interfaces则实现了不同物理交换机间的透明化集中管理, 这一架构的基础单元是 ACI 架构基础单元.
1）网络策略架构 ，主要是以容器化架构进行划分，并且阐述设备连接配置的组织原则；
2）API Controller（即应用级基础设施控制器，在软件定义网络(SDN)环境中作为控制器使用），作为一个单独管理点存在，并作为一个信息存储库存在。
3）ACI架构 ，即组成ACI的所有物理和虚拟网络设备的抽象概念。
基于Virtual Machine（VM）平台的Network Segment eXpression（NSX）主要包含NSXManager、 NSXCPU 与 NSXA 交换机以及 NSXE 作为关键组件
Open Networking Foundation(ONF) 规范化OpenFlow架构基于特定设备单元的支持。该规范化的架构通过 southbound protocols 和 applications APIs 来控制交换机硬件功能的具体操作指令.
Open vSwitch (OVS) 是 OpenFlow 开源项目的实际实现。
主要由 Nicira Networks 开发，并被 VMware 收购。
运行于诸如 KVM 和 Xen 这样的虚拟化平台之上。
也获得了 OpenStack 的支持。
在这些平台上运行时，在处理动态变化的端点时能够实施 2 层交换策略。
这种技术有效地实现了访问策略控制、网络隔离措施以及流量监控等功能。
Open Daylight 项目由思科与IBM共同主导其开放平台实现，并归入Linux基金会下的开源计划。
开源ONOS（Open Network Operating System）是华为SDN战略的核心技术方向
遵循基于I2RS支持的架构设计，在完成这一框架后遵循特定的技术路线以实现功能扩展性需求。该体系架构强调通过在现有网络层协议基础上添加可扩展性插件，并在网络与应用层之间引入一个专门负责能力开放封装功能的Orchestrator来实现对功能扩展性的支持。这种设计路线而非直接采用OpenFlow协议作为主要承载能力开放的技术方案，并且其核心目标在于尽可能地保留和复用现有的各种路由协议及IP网络技术基础。
NFV主要面向运营商业务，并采用Hypervisor技术实现硬件层面的虚拟化。基于上述虚拟化的前提条件，在服务器等虚拟化的基础上达成一系列关键功能模块：包括虚网元（vIMS）、虚电业务平台（vEPC）、虚媒体服务端（vMSE）、以及虚拟家庭系列（包括虚标量传输业务/可扩展性/承载网函数族）。这些功能模块将通过虚交换机将VMs与物理接口进行连接，并最终提升资源利用率的同时兼顾系统的可靠性要求。
NFV的主要标准组织包括ETSI及OPNFV。欧洲电信标准协会（ETSI）负责制定网络功能虚拟化相关的技术规范，并推动形成了一个网络功能虚拟化标准工作组（WFNISG）。另一个重要的参与者是OPNFV项目组（Open NFV Forum V1），这一项目组由华为技术有限公司、美国思科技术有限公司和瑞典爱立信公司共同参与。
电信运营商及通信服务提供商(CSP)一直关注**网络功能虚拟化(NFV)及软件定义网络(SDN)**带来的好处，并通过支持快速部署新服务来促进高度自动化与动态重排领域的扩展。这一发展不仅有助于降低资本支出与运营成本，并且同时具备易于配置与管理的特点
业内为了达成这一目标而推出了多种开源计划
然而，在面对这些错综复杂的开源项目时，业界呈现出一种分散态势。由于各个开源项目的特色各异，在这种情况下难以实现有效的协作与整合而导致CSP领域的混乱现象产生。与此同时，在潜在影响SDN/NFV优势之间的关系问题上也未得到有效解决。
**现状：**多个开源SDN/NFV举措导致混乱
当前在探索多条NFV/SDN开源路径时，CSP正面临"路径选择困难"；现有可选方案包括：由Linux基金会整合后的ONAP（取代了原先的ECOMP与Open-Order），以及来自ETSI的OSM、OPNFV等项目。尽管尚不明朗其融合能否成功……但预测ONAP将在NFV管理和编排领域与之展开竞争。此外，在运支持系统(OSS)与业务支持系统(BSS)方面也面临着更为深入整合的趋势。而在SDN领域中，则有成熟的ONOS及ODL方案可供参考。
这些开源项目主要由业界权威的组织、社区、企业以及少数一级CSP引领发展构成，并因此导致大多数CSP面临着选择单一开源项目或多种开源项目的组合困难。
CSP倾向于通过开放获取的方式防止 vendor lock-in，并期待能够看到SDN/NFV带来的更加快捷的生产流程的同时，确保系统的高性能、高扩展性和长期的技术支持。
并非所有系统集成商在采用SDN和NFV推进CSP部署时都能获得预期效果；一些企业将CSP视为技术探索与实践的前沿实验室，在这一过程中不断积累经验并提升能力水平；通过支持开源社区发展的同时，在实际项目中逐步将核心功能独立出来作为一级功能模块
**挑战：**基本问题有待解决
为了顺利进入SDN/NFV的发展道路, CSP单位必须先明确并解决相关技术难题,包括NFV/SDN虚拟化网络如何利用现有数据中心运行的COTS硬件实现带宽扩展需求这一关键问题.
CSP是否可以在短期阶段内通过成本化的方法进行资源投入和开发？
在部署SDN/NFV系统时，CSP能否访问适当的测试系统和工具来验证并量化其性能指标？CSP甚至能够制定明确的技术规范以确保NFV/SDN虚拟化网络系统的性能达标。
SDN/NFV是否与CSP的传统网络系统进行整合 ，并为用户提供统一的操作界面？传统IT解决方案与虚拟化IT基础设施之间应当如何协同整合才能实现整个企业 IT 架构的一体化展示？
CSP如何保障选用的开源项目在未来十年期间持续优化发展？由谁负责确保开源项目的持续优化与发展？包括哪些方面？
SDN/NFV虚拟化网络后期的服务支持、升级以及托管服务相较于现有传统系统的复杂性要相对而言更为简单。例如，在当前私有云数据中心的安全性管控中可以看出：NFV/SDN系统的托管管理相较于分布式网络系统要更为复杂；而混合网络相较于目前的传统网络来说其管理复杂度则略低一些呢？
SDN/NFV系统如何应对CSP在SLA、QoS、服务保障、高可用性和可靠性等方面的具体需求？是否存在能够量化表示的参数？如果这些参数无法量化表示，则新的衡量标准是什么？
不同厂商开发的单独VNF所采用的 Service mesh、容器 orchestration、DevOps practices 和 RESTful service design 是否能够确保其与MANO interface specification的一致性？
能否让CSP在没有威胁的情况下稳定运行其SDN/NFV系统？ 例如，在当前环境下，将SDN控制器进行集中管理可能会暴露出更多潜在的安全隐患。此外，在考虑NFV架构时，请问CSP是否需要从各个层级全面分析其安全缺陷并采取修复措施？
在过去的十年间，在传统的硬件网络架构中通过云计算技术（CSP）实现了显著的增长性在网络带宽上。尽管随着时代的发展传统系统的管理和优化日益复杂化，
但传统架构依然能够稳定可靠地运行。
基于这些传统技术的新一代设备解决方案整合了系列自动化工具以方便配置与管理。
而NFV/SDN体系不仅简化了当前系统的部署与管理流程更能满足当前及未来的需求。
SDN/NFV 未来之路 在此之前（CSP），需对开源社区、系统集成商及解决方案供应商提供的开源计划进行评估（包括其可持续性、性能及规模等）。在此期间（CSP），可能还需咨询那些能独立进行测试与验证（如虚拟化或混合网络）的企业（同样地，在构建用于验证虚拟化/混合网络技术性能指标的测试架构方面），解决方案供应商则需专注于建立相应的架构以实现这一目标。
开源行动必须由目标导向驱动 ，其目的是让绝大多数云计算服务提供商（CSP）能够在生产环境中应用这一方案。标准化组织应持续关注强化接口/API层 ，以促进各厂商组件间的集成与互操作性。与此同时 ，厂商提供的解决方案同样值得重视 ，这些方案需满足现场测试的要求 、具备扩展性 ，并已引入网络自动化技术。
在未来的几年期间里, CSP网络将不得不与日益增长的带宽需求相适应, 这就要求实现依赖硬件驱动与基于NFV/SDN技术的虚拟化架构之间的平衡关系. 面临挑战: 基于现有技术（如COTS硬件）构建支持广泛带宽需求的网络架构可能会遇到困难.
相关阅读
软件层面的定义与硬件架构的重构了解多少？
软件定义与硬件重构涉及哪些方面
温馨提示： 请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号，获取更多精彩内容。
温馨提示
听说点赞和分享的朋友都已走上人生巅峰
该系统具备高效的用户管理功能。
在实际应用中的效果显著。
其设计适用于多个行业。