SDN架构与解析

上传人:ni****g 文档编号:488408324 上传时间:2023-02-12 格式:DOCX 页数:9 大小:320KB
返回 下载 相关 举报
SDN架构与解析_第1页
第1页 / 共9页
SDN架构与解析_第2页
第2页 / 共9页
SDN架构与解析_第3页
第3页 / 共9页
SDN架构与解析_第4页
第4页 / 共9页
SDN架构与解析_第5页
第5页 / 共9页
点击查看更多>>
资源描述

《SDN架构与解析》由会员分享,可在线阅读,更多相关《SDN架构与解析(9页珍藏版)》请在金锄头文库上搜索。

1、SDN架构与解析:深度开放与融合长期以来,网络技术总是以被动方式进行演变,并且大量的技术革新都落地在网络设 备本身,如带宽不断提升,从千兆到万兆、再到40G和100G;设备体系架构变化,也是为了性能地不断提升,从交换能力几十Gbps提升到T级别以致100T级别;组网变化,网络设备的N:1集群性质的虚拟化,在一定范围内和一定规模上优化了网络架构,简化了网络设计;大二层网络技术,通过消除环路因素,支持了虚拟化条件下的虚机大范围二层扩散性计 算。新的技术商用,总会引起设备的升级换代,并且随着流量的巨大变化,网络的部署与 变更技术上越来越复杂,网络在应对流量变化上很难有良好的预期性,在当前方式下,一

2、旦完成业务部署, 服务器通过网线连入网络, 应用流量吞吐对网络的影响就难以控制、网 络的调整也就变得相当滞后。软件定义网络一一 SDN(Software Defined Network) 的出现和理念演进,开始改变网络 被动性的现状,使网络具备较大灵活程度的“定义”能力 ;这种可定义性,是网络主动“处 理”流量而不仅仅是 被动“承载”流量,并使得网络与计算之间的关系不仅仅是“对 接”,而是“交互”。SDN的思想集中体现在控制面与实体数据转发层面之间分离,这对网络交换机的工作方式产生了深远的影响。高端用户原本就不满足于使用网络预先设定好的功能,而是希望在自己的业务功能不断丰富变化的过程中,能够按

3、照自身需求快速进行调整。而在控制层 面分离出来后,或者说控制层面可以开放出来,更能实现虚拟化的灵活性,使得用户能够进行程序编制,那么基于应用与流量变化的快速响应,便不需要完全依赖于设备供应商的 长周期软硬件升级来完成。SDN的思想是将更多的控制权交给网络使用者,除了设计部署、配置变更,还可以进 行网络软件的重构,使得新的技术验证可以先于商业化。这种网络能够以抽象化的方式解 决网络的复杂性问题,解除了用户收支网络功能和特性的紧约束,能够在更高层面研究和 满足项业务需求。 当前主流SDN的概念探讨最经典的SDN架构描述是来自 ONF(Open Network Foundation) 的SDN系架构

4、图(如 图1所示)。图1 SDN体系架构图1表达了 SDN的分层解耦合概念,包括通用的基础硬件层、硬件抽象层、网络 操作 系统、上层应用。其中基础硬件与硬件抽象两层组成物理网络设备,也 就是SDNm构中的 数据转发层面;网络操作系统与上层应用组成了控制层面。数据转发层面与控制层面之间以 一种标准化的交互协议来解耦合,此协议当前为OpenFlow。这种去耦合的架构,表明网络操作系统及网络应用(如路由控制协议等)不必运行在物理设备上,而可以运行在外部系统 (如X86架构的服务 器)内,从而实现网络控制的灵活可编程性。除了解耦合控制层面与数据转发层面,SDN引入了集中控制的概念(如图2所示)。对于传

5、统的设备,因为不同的硬件、供应商私有的软件,使得网络本身相对封闭,只能通过标准的互通协议与计算设备配合运行。网络中所有设备的自身系统都是相对孤立和分散 的,网络控制分布在所有设备中,网络变更复杂、工作 量大,并且因为设备异构,管理上 兼容性很差,不同设备的功能与配置差异极大;同时网络功能的修改或演进,会涉及到全网的升级与更新。而在 SDN的开放架构 下,一定范围内的网络(或称SDN域),由集中统一的 控制逻辑单元来实施管理,由此解决了网络中大量设备分散独立运行管理的问题,使得网 络的设计、部署、运维、管理在一个控制点完成,而底层网络差异性也因为解耦合的架构得到了消除。集中控制在网络中引入了SD

6、N别于传统网络架构的角色一一SDNController ,也就是运行SDN网络操作系统并控制所有网络节点的控制单元。SDN能够提供网络应用的接口,在此基础上按照业务需求进行软件设计与编程,并且是在 SDNController 上加载,从而使得全网迅速升级新的网络功能,而不必再对每个网元节点进行 独立操作。图2封闭式网络与开放网络分层解耦合架构中采用了OpenFlow的协议来分离网络的控制与转发层,图 3是来自斯坦福的一张图表明 OpenFlow的解耦模型。网络设备(图3中OpenFlowSwitch)由标准的网络硬件和支持OpenFlow代理的软件构成。OpenFlow定义的网络硬件,不是传统

7、的交换模式,而是以一种流表的方式来进行数据的转发处理,非常类似于当前交换机使用的TCAM寸数据流的分类与控制行为,每一个网络中的流均由流表中的规则来控制处理,可以达到极精细的粒度。OpenFlow协议定义了一种通用的数据平面描述语言,设备上的OpenFlow代理软件通过与 OpenFlow Controller建立安全加密(如SSL通信机制)通信隧道来接受对设备的控制转发指令。所有的流表指令 均被定义成标准规范,通过Controller 与代理之间的加密协议可靠传递。 Controller 上运行的各种网络应用,均被转换成OpenFlow “指令集”下发,从而易于实现标准化的模式,这使得Ope

8、nFlow成为SDN构下的重要技术。OpenFlow以一种比较理想的形式定义了网络设备的供应方式,但这种定义使得网络不是一个平滑升级和演进,而是一个颠覆性的更新,现有网络不能通过OpenFlow来升级,而是需要被完全替换。同时,OpenFlow设备是一种流表转发,也需要新的体系架构来设计网络芯片,虽然现有 TCAMK术能支持OpenFlow的特性,但是功能不完备、大TCAM1项设备极其昂贵。因此,当前的 OpenFlow设备,基本是在传统网络基础上支持OpenFlow协议,规格受限的初期产品。OpenFlow的设计思路体现了 SDN构,但是,这种思路只体现了集中控制的优势,对 于网络的运维管理

9、并没有深入考虑,管理通信如何采用OpenFlow并与正常业务流的分离,是否覆盖替代还是与传统SNMP/NETCO厢管理方式,集中的 OpenFlow Controller 与分散的OpenFlow网络设备之间采取一种如何的管理方式更优,还需要 OpenFlow本身的技术不断实践来印证。OpenFlow在协议定义上还不完善,针对已有网络特性的定义还在补充变化,内容变更 会不断持续,并逐步形成不同的技术版本,这使得软件和硬件在配套兼容上存在较大的问 题,这也是OpenFlow作为SDNB议的在网络应用覆盖不全方面的严重不足。2|H3C SDNK、体架构与策略2.1 H3C SDN总体架构与策略H3

10、c在基于全网端到端的总体网络架构上,将会交付一个逐步发展丰富的SDNT品与解决方案集。(如图4所示)H3C SDN当前提供三大方案集:基于 Controller/Agent 的SDN 全套网络交彳基于 Open API的网络平台开放接口、基于OAA的自定义网络平台。在这三大方案集成基础上,构建一个标准化深度开放、用户应用可融合的NPaaS(NetworkPlatform as a Service)网络平台即服务的 SDN本系,既具备 H3c已有的优势网络技术方案,又能在各种层次融合与扩展用户自制化网络应用。2.2 基于Controller/Agent的SDN全套网络交付在上述SDN基本体系架构

11、定义的框架下,H3c提供与此一致的方案架构。如图 5所示,H3c将在同一 SDN勺架构下,除了支持标准化的OpenFlow协议,并提供基于 H3c自身成熟技术的自有协议 RIPCRIPC(Remote IPC)。opemiMk云计算接口上层应用管理监控SConlroherAPMSDKH3C ControllerQpenflow. Remote IPC图 5 Controller/Agent 的 SDN网络H3c将提供标准化的系列化 Controller 部件,能够以OpenFlow协议进行OpenFlow设 备的集中控制,对上层提供灵活的开放接口,以满足各种网络应用的调用需求。在当前网络产品逐

12、步集成 OpenFlow特性,满足初始 OpenFlow网络部署需求,并逐步丰富OpenFlow的 产品组成,如图6左图构建了整体 OpenFlow的SDN网络。针对H3c优势技术IRF的进一步强化,基于 Controller/Agent 架构,以H3C RIPCRIPC的协议实现了 VCF的技术,如图6右图所示,使用多台 S5820V2组成的IRF结构 体工作为网络的 Controller 角色,下联多台 S5120HI。图6 H3C SDN网络的两种实现VCF采用SDN架构的N:1网络虚拟化,不仅将多台同一网络层面的设备整合,也将另一层次的设备整合,整个网络运行如同一台大型框式设备,运行管

13、理各种操作均被虚拟化在一台大型设备内。所有的控制、设备管理均在S5820V2的IRF组上,其它的S5120HI运行为线卡模式。在这种 SDN构下,H3c的RIPC协议消除了 OpenFlow协议在效率与管理 上的不足,并有效继承了H3C Comware平台的原有IRF优势。2.3 基于Open API的网络平台SDN最重要的网络需求是可编程性,即用户可以在自身业务变化的情况下,根据需要自行软件开发,这种需求的核心是网络要有灵活开放的接口提供给用户的编程实现。H3C实现了多层化的 Open API方案(如图7所示)。基础设备层面可以提供深度的SDK级标准化 VCCR络应用(VCC: Virtua

14、l ComputingContainer虚拟计算容器),并提供高级XML的访问操作NETCON标准接口体系,OpenFlow 也是设备层面提供的一种标准接口模式;设备控制层面(SDN Controller),作为网络操作系统,标准化的接口依据 Controller 的不同实现,对外可提供 VCC REST/SOAP NETCONF OpenFlow等。Open API 与 H3c系统(Comware/iMC)内部集成(Integrated)API( 如 RIPC)相辅相成,构 建差另的SDNm构,并在不同层次形成自有系统及对外开放与标准化,使得不同用户的可 编程与应用变化性需求得以满足。Sol

15、uttonsNttwcrk Appll-catflort*Infra itmcturw图7 H3C多层化的 Open API在Open API接口中,REST/SOA度常规的高层协议编程接口,NETCON是网络设备上新兴的XML语言编程接口, OpenFlow是SDN的一种协 议,以上均是通用化的技术实现, VC/U是H3c在长期网络软件技术积累过程中形成的一种更为底层的标准化实现。ComwareV碌基于Linux内核实现的新一代云计算网络操作系统,当前的架构,基于类POSIX的Linux接口及扩展形成一套开放的SDK, H3c提供了含SDJ接口描述、调用库、编译环境等完备的编程环境,使得用户可以使用C/C+以几乎完全等同于 Linux系统下的环境进行自己的网络应用程序软件开发,而ComwareV7则为用户的软件运行提供了一个完整的系统环境,如图 8所示。Corn ware* V7内内态VCC设件VCC在VCC境中,用户程序包可独立加载到设备上运行,软件可以不间断业务升级。Comware V7提供接口给用户,软件设计可以一定程度上访问底层硬件,对 路由、MA%硬 件表项进行操作,或者设备的配置变更及相应状态监控等,同时还

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 办公文档 > 演讲稿/致辞

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号