SDN和NFV之“现状挑战”和“未来趋势”
SDN和NVF的思想和目标是利用现有网络和计算资源，基于Fabric架构实现业务和网络服务敏捷发放。SDN更加强调控制和管理有效分离，而NFV专注网元功能虚拟化。
目前SND主要包括思科(强调基础自己网络硬件)和Vmware(强调集成自己的NSX软件)两大阵营，当然还有其他SDN解决方案，下面分别详细介绍一下。
思科基于ACI(以应用为中心的基础设施)，主要讲网络数据平面和控制层面分离，北向接口实现应用对控制器策略可编程，南向接口实现不同物理交换机透明化集中管理，ACI架构基础单元。
-
1）网络策略模型，即将网络装置按容器式结构划分以及描述设备连接情况的组织原则；
-
2）APIC(应用基础设施控制器/即SDN中的控制器)，提供所有配置策略的单独管理点和信息库；
-
3）ACI架构，即组成ACI的所有物理和虚拟网络设备的抽象概念。
基于WMware的NSX主要由NSX管理器、NSX控制器、NSXEdge和NSX交换机组成。
Open Networking Foundation(ONF) 标准化OpenFlow架构是通过在某个集中部件(比如控制器)进行软件的逻辑运行，并通过使用南向协议/应用程序接口(API)对交换机(硬件商品)进行指令编程。
Open vSwitch(OVS)是OpenFlow开源实现，由Nicira Networks(被VMware收购)主导的，运行在虚拟化平台(例如 KVM，Xen)的虚拟交换机上，也得到OpenStack的支持。在虚拟化平台上，OVS 可以为动态变化的端点提供2层交换功能，很好的控制虚拟网络中的访问策略、网络隔离、流量监控等等。
Open Daylight是由思科、IBM领导的OpenFlow开源实现，隶属于Linux基金会。
开源ONOS(Open Network Operating System)是华为的SDN战略方向，ONOS含有全局网络视图功能，在集群中通过ONOS服务器管理和共享网络状态，在每个ONOS实例中发现的网络拓扑和状态，如交换机端口、链路和主机信息构成全局网络视图，并从全局网络视图中读取应用程序确定转发策略，然后将转发策略依次写到网络视图中，当视图信息发生变化时，将变化消息发送到相应的OpenFlow控制器并下发到在指定的交换机上。
IETF的SDN体系架构是基于I2RS(Interface to the Routing System)支持的SDN体系架构。I2RS主张在现有的网络层协议基础上，增加插件(Plug-in)，并在网络与应用层之间增加SDN Orchestrator进行能力开放的封装，而不是直接采用OpenFlow进行能力开放，目的是尽量保留和重用现有的各种路由协议和IP网络技术。
NFV主要是针对运营商业务，通过Hypervisor方法提供硬件虚拟化，在服务器等虚拟化的基础上实现虚拟网元vIMS、vEPC /vMSE、vFamily (vSTB /vAR /vRGW)功能，以虚拟交换机实现VMs和物理接口对接，实现管理自动化，提高资源使用率、可靠等诉求。
NFV主要的标准组织有ETSI和OPNFV。ETSI(欧洲电信标准协会)发起一个网络功能虚拟化标准工作组(VFNISG)，OPNFV由华为，思科和爱立信主导。
电信运营商和通信服务提供商(CSP)一直期待网络功能虚拟化(NFV)和软件定义网络(SDN)能够带来的优势，以帮助他们进入快速部署新服务，实现高度的网络自动化和动态重新配置的领域，从而降低资本支出/运营成本，并且易于配置和管理。
业界为实现这一目标，纷纷推出了多种开源计划。欧洲电信标准协会(ETSI)推出了开源NFV管理和编排(MANO)架构，吸引了大量的一级CSP和厂商的加入。其中一些CSP已经进行了现场试验，甚至有些一级运营商已经在现网中通过SDN和NFV部分实现虚拟化，解决方案厂商还创建了增强的NFV/SDN平台和优化的虚拟网络功能(VNF)。
然而，业界因为这些纷繁复杂的开源项目变得很分散，因为每个开源项目都有自己的优点，因此导致了CSP的混乱。而潜在的影响SDN/NFV优势的问题也没有得到解决。
现状：多个开源SDN/NFV举措导致混乱
目前在采用多个NFV/SDN开源路径时，CSP面临“选择障碍症”；有Open-O、AT&T的ECOMP(ECOMP和Open-O目前已经被Linux基金会合并为ONAP) 、ETSI的OSM，OPNFV可供选择。虽然ECOMP和Open-O合并能否取得成功还有待观察，但可以预见的是ONAP将和ETSI OSM在NFV管理和编排领域展开竞争。同时诸如MEF LSO等新举措正在受到业界的重视，包括与运营支撑系统(OSS)/业务支撑系统(BSS)更深层次的整合。在SDN方面，成熟的开源计划包括ONOS和ODL。
这些开源项目都是一些业界权威的组织、社区、厂商和几个一级CSP主导并驱动的，这使得大多数CSP难以选择一个开源项目或开源项目的组合。
CSP更希望的是通过开源的方式，避免厂商的锁定，但是CSP更希望需要看到SDN/NFV带来的更快的生产路径，并保证性能、可扩展性和长期的支持的优势。
系统集成商在CSP采用SDN和NFV的过程中并不总是有帮助，有些系统集成商将CSP作为自己学习的研发实验室。通过支持多个开源计划，系统集成商可能会尝试在多个项目中分离一级用户。
挑战：基本问题有待解决
CSP需要清楚并回答出以下问题，然后再去尝试选择SDN/NFV的道路。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、REST API规则能否与MANO接口规范保持一致性?
-
CSP能够不面临威胁地安心地运行他们的SDN/NFV系统吗? 例如，SDN控制器的集中化实际上可能暴露出了更多的安全漏洞。以此类推，NFV堆栈有不同厂商创建的OS、管理程序和VNF。CSP是否需要全面分析各个层级的安全漏洞，并且对这些漏洞加以修复?
在传统的硬件网络中，CSP在十多年中实现了网络带宽的快速增长。虽然传统的系统管理变得非常复杂，但这些传统的硬件能够很可靠的运行，CSP可以设置SLA。新的网络设备解决方案还附带了一系列网络自动化工具，便于配置和管理。NFV/SDN系统不仅要使系统更易于部署和管理，而且还能满足所有性能指标和未来网络带宽需求。
SDN/NFV未来之路
在CSP作出最终决定之前，需要对开源社区、系统集成商和解决方案提供商的开源计划的可持续发展、性能、规模等作出评估。CSP可能还需要咨询能够独立测试和验证虚拟化/混合网络的公司，同样，解决方案提供商需要构建测试架构来验证虚拟化/混合网络的性能指标。
开源的举措必须由目标驱动，目标是让大多数CSP能够将之应用于生产环境。标准组织需要继续专注于加强接口/API层，以实现各厂商组件的集成和互操作性。CSP同样也要对厂商解决方案加以重视，这些解决方案是现场测试的、可扩展的，并且已经引入了网络自动化。
在未来几年中，CSP网络将不得不跟上带宽需求的增长，需要达成硬件驱动的网络解决方案和基于NFV/SDN的虚拟化途径的平衡，基于COTS硬件的NFV/SDN可能无法扩展CSP的网络以满足不断增长的带宽需求。
相关阅读
-
软件定义和硬件重构知多少(1)
-
软件定义和硬件重构知多少(2)
-
软件定义和硬件重构知多少(3)
温馨提示：
请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号，获取更多精彩内容。
听说点赞和分享的朋友都已走上人生巅峰
