《SDN架构与解析》由会员分享，可在线阅读，更多相关《SDN架构与解析（10页珍藏版）》请在金锄头文库上搜索。
1、SDN 架构与解析：深度开放与融合长期以来，网络技术总是以被动方式进行演变，并且大量的技术革新都落地在网络设备本身，如带宽不断提升，从千兆到万兆、再到40G和100G;设备 体系架构变化，也是为了 性能地不断提升，从交换能力几十Gbps提升到T级别以致100T级别;组网变化，网络设备 的N:1集群性质的虚拟化，在一定范围内和一定规模上优化了网络架构，简化了网络设计； 大二层网络技术，通过消除环路因素，支持了虚拟化条件下的虚机大范围二层扩散性计算。新的技术商用，总会引起设备的升级换代，并且随着流量的巨大变化，网络的部署与变 更技术上越来越复杂，网络在应对流量变化上很难有良好的预期性，在当前方式下
2、，一旦完 成业务部署，服务器通过网线连入网络，应用流量吞吐对网络的影响就难以控制、网络的调 整也就变得相当滞后。软件定义网络 SDN(Sof tware Defined Net work)的出现和理念演进，开始改变网络 被动性的现状，使网络具备较大灵活程度的“定义”能力;这种可定义性，是网络主动“处 理”流量而不仅仅是被动“承载”流量，并使得网络与计算之间的关系不仅仅是“对接” 而是“交互”。SDN的思想集中体现在控制面与实体数据转发层面之间分离，这对网络交换机的工作方 式产生了深远的影响。高端用户原本就不满足于使用网络预先设定好的功能，而是希望在 自己的业务功能不断丰富变化的过程中，能够按照
3、自身需求快速进行调整。而在控制层面分 离出来后，或者说控制层面可以开放出来，更能实现虚拟化的灵活性，使得用户能够进行 程序编制，那么基于应用与流量变化的快速响应，便不需要完全依赖于设备供应商的长周期 软硬件升级来完成。SDN的思想是将更多的控制权交给网络使用者，除了设计部署、配置变更，还可以进行 网络软件的重构，使得新的技术验证可以先于商业化。这种网络能够以抽象化的方式解决网 络的复杂性问题，解除了用户收支网络功能和特性的紧约束，能够在更高层面研究和满足项 业务需求。最经典的SDN架构描述是来自0NF(0pen Network Foundation)的SDN体系架构图(如图1所示)。Appli
4、cation SDN图1 SDN体系架构图1表达了 SDN的分层解耦合概念，包括通用的基础硬件层、硬件抽象层、网络操作系 统、上层应用。其中基础硬件与硬件抽象两层组成物理网络设备，也就是SDN架构中的数 据转发层面;网络操作系统与上层应用组成了控制层面。数据转发层面与控制层面之间以一 种标准化的交互协议来解耦合，此协议当前为OpenFlow。这种去耦合的架构，表明网络操 作系统及网络应用（如路由控制协议等）不必运行在物理设备上，而可以运行在外部系统（如 X86架构的服务器）内，从而实现网络控制的灵活可编程性。除了解耦合控制层面与数据转发层面，SDN还引入了集中控制的概念（如图2所示）。对 于传
5、统的设备，因为不同的硬件、供应商私有的软件，使得网络本身相对封闭，只能通过 标准的互通协议与计算设备配合运行。网络中所有设备的自身系统都是相对孤立和分散的, 网络控制分布在所有设备中，网络变更复杂、工作量大，并且因为设备异构，管理上兼容 性很差，不同设备的功能与配置差异极大;同时网络功能的修改或演进，会涉及到全网的升 级与更新。而在SD N的开放架构下，一定范围内的网络（或称SDN域），由集中统一的控制 逻辑单元来实施管理，由此解决了网络中大量设备分散独立运行管理的问题，使得网络的设 计、部署、运维、管理在一个控制点完成，而底层网络差异性也因为解耦合的架构得到了 消除。集中控制在网络中引入了S
6、DN区别于传统网络架构的角色SDNController，也就 是运行SDN网络操作系统并控制所有网络节点的控制单元。SDN能够提供网络应用的接口， 在此基础上按照业务需求进行软件设计与编程，并且是在SDN Controller上加载，从而使 得全网迅速升级新的网络功能，而不必再对每个网元节点进行独立操作。nnii ru nvtrwnOpenFiwri匚 harm# ITablp是否覆盖替代还是与传统SNMP/NETCONF的管理方式，集中的OpenFlow Controller与分散 的OpenFlow网络设备之间采取一种如何的管理方式更优,还需要OpenFlow本身的技术不断 实践来印证。O
7、penFlow在协议定义上还不完善，针对已有网络特性的定义还在补充变化，内容变更 会不断持续，并逐步形成不同的技术版本,这使得软件和硬件在配套兼容上存在较大的问题, 这也是OpenFlow作为SDN协议的在网络应用覆盖不全方面的严重不足。2、H3C SDN总体架构与策略2.1 H3C SDN总体架构与策略H3C在基于全网端到端的总体网络架构上，将会交付一个逐步发展丰富的SDN产品与解 决方案集。(如图4所示)H3C SDN当前提供三大方案集：基于Controller/Agent的SDN全 套网络交付、基于Open API的网络平台开放接口、基于OAA的自定义网络平台。在这三大 方案集成基础上，
8、构建一个标准化深度开放、用户应用可融合的NPaaS(NetworkPlatformas a Service)网络平台即服务的SDN体系，既具备H3C已有的优势网络技术方案，又能在各种 层次融合与扩展用户自制化网络应用。2.2基于Controller/Agent的SDN全套网络交付在上述SDN基本体系架构定义的框架下，H3C提供与此一致的方案架构。如图5所示, H3C将在同一 SDN的架构下，除了支持标准化的OpenFlow协议，并提供基于H3C自身成熟 技术的自有协议RIPCRIPC(Remote IPC)。云计算援口上层应用管理监控更高层Centraller:APFSDKH3C Contro
9、llerOpenflowRemote IRC*I图 5 Controller/Agent 的 SDN 网络H3C将提供标准化的系列化Controller部件，能够以OpenFlow协议进行OpenFlow设 备的集中控制，对上层提供灵活的开放接口，以满足各种网络应用的调用需求。在当前网 络产品逐步集成OpenFlow特性，满足初始OpenFlow网络部署需求，并逐步丰富OpenFlow 的 产品组成，如图6左图构建了整体OpenFlow的SDN网络。针对H3C优势技术IRF的进一步强化，基于Controller/Agent架构，以H3C RIPCRIPC 的协议实现了 VCF的技术，如图6右图
10、所示，使用多台S5820V2组成的IRF结构体工作为网 络的Controller角色，下联多台S5120HI。 irrna ! n riva ia in ai iivihiiiii hgOjM-nflov ControllerJ OponflowRiJMVCF：52ffV2*53flHI图6 H3C SDN网络的两种实现VCF采用SDN架构的N: 1网络虚拟化，不仅将多台同一网络层面的设备整合，也将另- 层次的设备整合，整个网络运行如同一台大型框式设备，运行管理各种操作均被虚拟化在 一台大型设备内。所有的控制、设备管理均在S5820V2的IRF组上，其它的S5120HI运行为 线卡模式。在这种
11、SDN架构 下，H3C的RIPC协议消除了 OpenFlow协议在效率与管理上的 不足，并有效继承了 H3C Comware平台的原有IRF优势。2.3基于Open API的网络平台SDN最重要的网络需求是可编程性，即用户可以在自身业务变化的情况下，根据需要自 行软件开发，这种需求的核心是网络要有灵活开放的接口提供给用户的编程实现oH3C实现 了多层化的Open API方案(如图7所示)。基础设备层面可以提供深度的SDK级标准化VCC网络应用(VCC: Virtual Computing Con taine r虚拟计算容器)，并提供高级XML的访问操作NETCON F标准接口体系，OpenFl
12、ow 也是设备层面提供的一种标准接口模式；设备控制层面(SDN Con troller),作为网络操作系统，标准化的接口依据Con troller 的不同实现，对外可提供VCC、REST/SOAP、NETCONF、OpenFlow等。Open API 与 H3C 系统(Comware/iMC)内部集成(Integrated)API(如 RIPC)相辅相成，构 建差别的SDN架构，并在不同层次形成自有系统及对外开放与标准化，使得不同用户的可编 程与应用变化性需求得以满足。SolutionsUK叩plica阳和I皿 iMradcirNUELv叨也1#SDH i厂CcntrolJr-m.一亠一GfH
13、n ftPlMvfwerkApplications y炉 pjetyrtuitm napl kati 13mNetCotiH 5C lyittmi -lnlHitrurtunKetConfHl SC * Ihfrd pjinyTKems;ipml:小图7 H3C多层化的Open API在Open API接口中，REST/SOAP是常规的高层协议编程接口，NETCONF是网络设备上新 兴的XML语言编程接口，OpenFlow是SDN的一种协议，以上均是通用化的技术实现，VCC 则是H3C在长期网络软件技术积累过程中形成的一种更为底层的标准化实现。ComwareV7是基于Linux内核实现的新一代
14、云计算网络操作系统，当前的架构，基于类 POSIX的Linux接口及扩展形成一套开放的SDK，H3C提供了含SDK的接口描述、调用库、 编译环境等完备的编程环境，使得用户可以使用C/C+以几乎完全等同于Linux系统下的环 境进行自己的网络应用程序软件开发，而ComwareV7则为用户的软件运行提供了一个完整 的系统环境，如图8所示。图8 VCC运行在VCC环境中，用户程序包可独立加载到设备上运行，软件可以不间断业务升级。ComwareV7提供接口给用户，软件设计可以一定程度上访问底层硬件，对路由、MAC等硬件 表项进行操作，或者设备的配置变更及相应状态监控等，同时还可以利用Comware V
15、7现有 的特性来辅助实现用户业务，从而实现用户软件定义网络的真正需求。2.4基于OAA的自定义网络平台早期，H3C提出了开放应用架构（Open Application Architecture）的网络模型，即在 H3C的网络设备中提供具有计算能力的线卡，用户可以在其上开发自己的特殊应用，并通过 H3C的OAA关联协议与网络进行数据交互。基于SDN的架构思路，H3C演绎了更灵活的用户化网络设计，实现的OAA新的业务模式， 可以方便用户灵活实现自定义的网络功能。在OAA基础上，提出了两种开放式的接口模型， 如图9所示。图9左图，显示了一种全松耦合的OAA架构。针对用户任意形态运行的网络业务，可能 是在服务器上的计算业务（如流量监控分析、数据旁路挖掘），也可能是专用的业务设备（如 防火墙、IPS、加密机、数据压缩机），用户设备可以支持标准的OpenFlow协议，即可与H3C 网络进行通信，在OpenFlow协议中传输业务指令，对需要处理的网络流量进行镜像、牵引、 封装、定向等操作，将清晰定义的数据流以合适的方式导引到用户的计算设备进行自定义 处理。这种方案的本质是，借助SDN的模型，将用户的数据处理设备运行为SDN Controller 方式，而对特定业务流进行处理。图9右图，显示了一种紧耦
