中国免费建设网站网址,高仿酒网站怎么做,营销型网站制作哪个好薇,app开发企业在选择上一般优先开发OpenFlow相关的历史、新闻#xff1a;http://blog.csdn.net/jincm13/article/details/7825754
起源与发展
【https://36kr.com/p/5035985】 OpenFlow起源于斯坦福大学的Clean Slate项目组 [1] 。CleanSlate项目的最终目的是要重新发明英特网#xff0c;旨在改变设计已略…OpenFlow相关的历史、新闻http://blog.csdn.net/jincm13/article/details/7825754
起源与发展
【https://36kr.com/p/5035985】 OpenFlow起源于斯坦福大学的Clean Slate项目组 [1] 。CleanSlate项目的最终目的是要重新发明英特网旨在改变设计已略显不合时宜且难以进化发展的现有网络基础架构。在2006年斯坦福的学生Martin Casado领导了一个关于网络安全与管理的项目Ethane[2]该项目试图通过一个集中式的控制器让网络管理员可以方便地定义基于网络流的安全控制策略并将这些安全策略应用到各种网络设备中从而实现对整个网络通讯的安全控制。受此项目及Ethane的前续项目Sane[3]启发Martin和他的导师Nick McKeown教授时任Clean Slate项目的Faculty Director发现如果将Ethane的设计更一般化将传统网络设备的数据转发data plane和路由控制control plane两个功能模块相分离通过集中式的控制器Controller以标准化的接口对各种网络设备进行管理和配置那么这将为网络资源的设计、管理和使用提供更多的可能性从而更容易推动网络的革新与发展。于是他们便提出了OpenFlow的概念并且Nick McKeown等人于2008年在ACM SIGCOMM发表了题为OpenFlow: Enabling Innovation in Campus Networks[4]的论文首次详细地介绍了OpenFlow的概念。该篇论文除了阐述OpenFlow的工作原理外还列举了### OpenFlow几大应用场景包括 1校园网络中对实验性通讯协议的支持如其标题所示 2 )网络管理和访问控制 3网络隔离和VLAN 4基于WiFi的移动网络 5非IP网络 6基于网络包的处理。当然目前关于OpenFlow的研究已经远远超出了这些领域。
基于OpenFlow为网络带来的可编程的特性Nick和他的团队包括加州大学伯克利分校的Scott Shenker教授进一步提出了SDNSoftware Defined Network, 目前国内多直译为“软件定义网络”的概念–其实SDN的概念据说最早是由KateGreene于2009年在TechnologyReview网站上评选年度十大前沿技术时提出[5]。如果将网络中所有的网络设备视为被管理的资源那么参考操作系统的原理可以抽象出一个网络操作系统Network OS的概念—这个网络操作系统一方面抽象了底层网络设备的具体细节同时还为上层应用提供了统一的管理视图和编程接口。这样基于网络操作系统这个平台用户可以开发各种应用程序通过软件来定义逻辑上的网络拓扑以满足对网络资源的不同需求而无需关心底层网络的物理拓扑结构。关于SDN的概念和原理可以参考开放网络基金会Open NetworkingFoundation于2012年4月份发表的SDN白皮书Software Defined NetworkingThe New Norm forNetworks [6] 。
从上面的描述中可以看出OpenFlow/SDN的原理其实并不复杂从严格意义上讲也很难算是具有革命性的创新。然而OpenFlow/SDN却引来了业界越来越多的关注成为近年来名副其实的热门技术。目前包括HP、IBM、Cisco、NEC以及国内的华为和中兴等传统网络设备制造商都已纷纷加入到OpenFlow的阵营同时有一些支持OpenFlow的网络硬件设备已经面世。2011年开放网络基金会Open Networking Foundation在Nick等人的推动下成立专门负责OpenFlow标准和规范的维护和发展同年第一届开放网络峰会OpenNetworking Summit召开为OpenFlow和SDN在学术界和工业界都做了很好的介绍和推广。2012年初召开的第二届峰会上来自Google的Urs Hölzle在以OpenFlowGoogle[7]为题的Keynote演讲中宣布Google已经在其全球各地的数据中心骨干网络中大规模地使用OpenFlow/SDN从而证明了OpenFlow不再仅仅是停留在学术界的一个研究模型而是已经完全具备了可以在产品环境中应用的技术成熟度。最近Facebook也宣布其数据中心中使用了OpenFlow/SDN的技术。
自2010年初发布第一个版本v1.0以来OpenFlow规范已经经历了1.1、1.2以及最近刚发布的1.3等版本。同时今年(2012)年初OpenFlow管理和配置协议也发布了第一个版本(OF-CONFIG 1.0 1.1)
OpenFlow的原理和基本架构
在这里我们将详细介绍一下OpenFlow Switch的最新规范(即OF-1.3)。下图选自Nick等人的论文OpenFlowEnablingInnovation in Campus Networks 。这张图常被用来说明OpenFlow的原理和基本架构。其实这张图还很好地表明了OpenFlow Switch规范所定义的范围—从图上可以看出OpenFlow Switch规范主要定义了Switch的功能模块以及其与Controller之间的通信信道等方面。 在进行OpenFlow原理说明前先了解一些基本情况: OpenFlow规范是什么 OpenFlow是一套软件API它允许一个“控制器”将配置信息发送给交换机。这个配置往往指的是一个“流”及其附属的某些“操作”。 “流”是一组定义的帧或者数据包类似于一个MPLS流与一组操作。例如 Source IP/Port、Destination IP/Port和Drop。 Source IP、Destination IP和QoS Action。 Source MAC、Destination MAC和L2 Path。 通过OpenFlow您可以将一组规则发送给一台“配置”设备的交换机或者路由器。然后每个设备会根据它的类型使用这些数据。交换机会更新它的MAC地址表以转发帧路由器会添加访问列表而防火墙会更新它的规则。 OpenFlow一种网络通信协议属于数据链路层能够控制网上交换器或路由器的转发平面forwarding plane借此改变网络数据包所走的网络路径。
软件定义网络是什么
当组织将网络配置从设备迁移到软件平台时交换机就变得更加简单和廉价了。但是主要的受益是网络配置可以由中央控制器管理。 控制者是一个包含算法、数学、分析和规则的软件它来自规则组并使用OpenFlow将配置下载到网络设备中。因此当控制器评估和重新平衡配置时网络就可能动态地进行重新配置。这就是所谓的软件定义网络。
SDNSoftware Defined Network
它是基于OpenFlow实现的。在SDN中交换设备的数据转发层和控制层是分离的因此网络协议和交换策略的升级只需要改动控制层。OpenFlow在OpenFlow交换机上实现数据转发而在控制器上实现数据的转发控制从而实现了数据转发层和控制层的分离。基于OpenFlow实现SDN则在网络中实现了软硬件的分离以及底层硬件的虚拟化从而为网络的发展提供了一个良好的发展平台。
OpenFlow网络由OpenFlow交换机、FlowVisor和Controller三部分组成。 OpenFlow交换机进行数据层的转发 FlowVisor对网络进行虚拟化 Controller对网络进行集中控制实现控制层的功能。 OpenFlow交换机是整个OpenFlow网络的核心部件主要管理数据层的转发。OpenFlow交换机接收到数据包后首先在本地的流表上查找转发目标端口如果没有匹配则把数据包转发给Controller由控制层决定转发端口。
Controller
OpenFlow实现了数据层和控制层的分离其中OpenFlow交换机进行数据层的转发而Controller实现了控制层的功能。Controller通过OpenFlow协议这个标准接口对OpenFlow交换机中的流表进行控制从而实现对整个网络进行集中控制。Controller的这一切功能都要通过运行NOX来实现因此NOX就像是OpenFlow网络的操作系统。此外在NOX上还可以运行Plug-n-serve、OpenRoads以及OpenPipes等应用程序。 Plug-n-Serve 通过规定数据传输路径来控制网络以及服务器上的负载从而使得负载均衡并降低响应时间。 OpenRoads 是支持OpenFlow无线网络移动性研究的框架。 OpenPipes 可以在网络系统中通过移动每个子模块来测试每个子模块并可以决定如何划分设计单元。
OpenFlow交换机的组成
OpenFlow交换机由流表、安全通道和OpenFlow协议三部分组成。 安全通道是连接OpenFlow交换机到控制器的接口。控制器通过这个接口控制和管理交换机同时控制器接收来自交换机的事件并向交换机发送数据包。交换机和控制器通过安全通道进行通信而且所有的信息必须按照OpenFlow协议规定的格式来执行。 OpenFlow协议用来描述控制器和交换机之间交互所用信息的标准以及控制器和交换机的接口标准。协议的核心部分是用于OpenFlow协议信息结构的集合。 OpenFlow协议支持三种信息类型Controller-to-SwitchAsynchronous和Symmetric每一个类型都有多个子类型。 a) Controller/Switch消息是指由Controller发起、Switch接收并处理的消息主要包括Features、Configuration、Modify-State、Read-State、Packet-out、Barrier和Role-Request等消息。这些消息主要由Controller用来对Switch进行状态查询和修改配置等操作。 b) 异步(Asynchronous)消息是由Switch发送给Controller、用来通知Switch上发生的某些异步事件的消息主要包括Packet-in、Flow-Removed、Port-status和Error等。例如当某一条规则因为超时而被删除时Switch将自动发送一条Flow-Removed消息通知Controller以方便Controller作出相应的操作如重新设置相关规则等。 c) 对称(Symmetric)消息顾名思义这些都是双向对称的消息主要用来建立连接、检测对方是否在线等包括Hello、Echo和Experimenter三种消息。 另外出于安全和高可用性等方面的考虑OpenFlow的规范还规定了如何为Controller和Switch之间的信道加密、如何建立多连接等(主连接和辅助连接)。 OpenFlow交换机的分类
按照对OpenFlow的支持程度OpenFlow交换机可以分为两类 专用的OpenFlow交换机 它是专门为支持OpenFlow而设计的。它不支持现有的商用交换机上的正常处理流程所有经过该交换机的数据都按照OpenFlow的模式进行转发。专用的OpenFlow交换机中不再具有控制逻辑因此专用的OpenFlow交换机是用来在端口间转发数据包的一个简单的路径部件。 支持OpenFlow的交换机 它是在商业交换机的基础上添加流表、安全通道和OpenFlow协议来获得了OpenFlow特性的交换机。其既具有常用的商业交换机的转发模块又具有OpenFlow的转发逻辑因此支持OpenFlow的交换机可以采用两种不同的方式处理接收到的数据包。 按照OpenFlow交换机的发展程度来分OpenFlow交换机也可以分为两类 “Type0”交换机 它仅仅支持十元组以及以下四个操作 1. 转发这个流的数据包给一个给定的端口或者几个端口 2. 压缩并转发这个流的数据包给控制器 3. 丢弃这个流的数据包 4. 通过交换机的正常处理流程来转发这个流的数据包。 “Type1”交换机 由于“Type0”交换机的这些功能是不能满足复杂试验要求的因此就定义“Type1”交换机来支持更多的功能从而支持复杂的网络试验“Type1”交换机将具有一个新的功能集合。 在一条规则中可以根据网络包在L2、L3或者L4等网络报文头的任意字段进行匹配比如以太网帧的源MAC地址IP包的协议类型和IP地址或者TCP/UDP的端口号等。目前OpenFlow的规范中还规定了Switch设备厂商可以选择性地支持通配符进行匹配。据说OpenFlow在未来还计划支持对整个数据包的任意字段进行匹配。 所有OpenFlow的规则都被组织在不同的FlowTable中在同一个FlowTable中按规则的优先级进行先后匹配。一个OpenFlow的Switch可以包含一个或者多个FlowTable从0依次编号排列。OpenFlow规范中定义了流水线式的处理流程如下图所示。当数据包进入Switch后必须从FlowTable 0开始依次匹配; FlowTable可以按次序从小到大越级跳转但不能从某一FlowTable向前跳转至编号更小的FlowTable。当数据包成功匹配一条规则后将首先更新该规则对应的统计数据(如成功匹配数据包总数目和总字节数等)然后根据规则中的指令进行相应操作–比如跳转至后续某一FlowTable继续处理修改或者立即执行该数据包对应的Action Set等。 当数据包已经处于最后一个FlowTable时其对应的Action Set中的所有Action将被执行包括转发至某一端口修改数据包某一字段丢弃数据包等。OpenFlow规范中对目前所支持的Instructions(指令)和Actions进行了完整详细的说明和定义。 另外OpenFlow规范中还定义了很多其他功能和行为比如OpenFlow对于QoS的支持(即MeterTable和Meter Bands的定义等)对于GroupTable的定义以及规则的超时处理等。
OpenFlow规范主要分为如下四大部分
1. OpenFlow的端口(Port)
OpenFlow规范将Switch上的端口分为3种类别 a) 物理端口即设备上物理可见的端口; b) 逻辑端口在物理端口基础上由Switch设备抽象出来的逻辑端口如为tunnel或者聚合等功能而实现的逻辑端口; c) OpenFlow定义的端口。OpenFlow目前总共定义了ALL、CONTROLLER、TABLE、IN_PORT、ANY、LOCAL、 NORMAL和FLOOD等8种端口其中后3种为非必需的端口只在混合型的OpenFlow Switch(OpenFlow-hybrid Switch即同时支持传统网络协议栈和OpenFlow协议的Switch设备中存在。
2. OpenFlow的FlowTable(国内有直译为“流表”的)
OpenFlow通过用户定义的或者预设的规则来匹配和处理网络包。一条OpenFlow的规则由匹配域(Match Fields)、优先级(Priority)、处理指令(Instructions)和统计数据(如Counters)等字段组成如下图所示。 Openflow的思路很简单网络设备维护一个FlowTable并且只按照FlowTable进行转发Flowtable本身的生成、维护、下发完全由外置的Controller来实现注意这里的FlowTable并非是指IP五元组事实上OpenFlow 1.0定义的了包括端口号、VLAN、L2/L3/L4信息的10个关键字但是每个字段都是可以通配的网络的运营商可以决定使用何种粒度的流比如运营商只需要根据目的IP进行路由那么流表中就可以只有目的IP字段是有效的其它全为通配。 这种控制和转发分离的架构对于L2交换设备而言意味着Controller将负责二层MAC学习VLAN划分还要负责三层路由协议的学习最后下发给路由器和交换机对于L3设备各类IGP/EGP路由运行在Controller之上Controller根据需要下发流表对于L3应该是路由表给相应的路由器。 流表的下发方式有两种模式: 主动 Controller将自己收集的流表信息主动下发给网络设备随后网络设备可以直接根据流表进行转发 被动是指网络设备收到一个报文没有匹配的FlowTable记录时将该报文转发给Controller由后者进行决策该如何转发并下发相应的流表。被动模式的好处是网络设备无需维护全部的流表只有当实际的流量产生时才向Controller获取流表记录并存储当老化定时器超时后可以删除相应的流表故可以大大节省TCAM空间。当一个Controller同时控制多个交换机/路由器设备时它们看起来就像一个大的逻辑交换机各个交换机/路由器硬件就如同这个逻辑网络设备的远程线卡类似的概念在Cisco的Nexus 1000/1000v、ASR9000/9000v和Juniper的Q-Fabric架构中可以看到影子Cisco称之为nV(Network Virtualization)技术。
OpenFlow之下的网络架构组成:
目前主要的OpenFlow解决方案包含一个三层架构第一层架构由关键的具备OpenFlow 协议许可的以太网交换机组成。通常情况下它们是具备OpenFlow功能的物理以太网交换机。我们还能看到一些具备OpenFlow功能的虚拟层/软件交换机和路由器。今后这类设备肯定会越来越多。 然后是两层服务器端软件OpenFlow控制器和OpenFlow软件应用建立在控制器顶端。 控制器是一个平台该平台向下可以直接与使用OpenFlow协议的交换机进行对话。向上控制器可为OpenFlow软件应用提供大量功能包括将交换机资源编入统一的网络视窗内为应用提供协同和通用库。 在顶层OpenFlow软件应用为网络执行实际控制功能如交换与路由。应用是写在由控制器提供的统一网络视窗和通用库顶层的简单软件。因此这些应用能够着重执行特定控制算法并能够调整其下层的OpenFlow层以实例化网络中的算法。 目前OpenFlow术语有两个意思可以指“OpenFlow协议”明确指称用于网络的x86指令集也可以指“OpenFlow架构”主要是交换机、控制器和应用层。 SDN与网络虚拟化: 参考摘录:https://www.sdnlab.com/15475.html SDN不是网络虚拟化网络虚拟化也不是SDN。 SDN是一种集中控制的网络架构可将网络划分为数据层面和控制层面。 在数据中心等场景中为实现快速部署和动态调整必须使用自动化的业务部署。SDN的出现给网络虚拟化业务部署提供了新的解决方案。通过集中控制的方式网络管理员可以通过控制器的API来编写程序从而实现自动化的业务部署大大缩短业务部署周期同时也实现随需动态调整。 网络虚拟化是一种网络技术可以在物理拓扑上创建虚拟网络。 传统的网络虚拟化部署需要手动逐跳部署其效率低下人力成本很高。
SDN实现网络虚拟化需要完成三部分工作: 物理网络管理网络资源虚拟化和网络隔离
虚拟化平台
虚拟化平台是介于数据网络拓扑和租户控制器之间的中间层。面向数据平面虚拟化平面就是控制器而面向租户控制器虚拟化平台就是数据平面。所以虚拟化平台本质上具有数据平面和控制层面两种属性。在虚拟化的核心层虚拟化平台需要完成物理网络资源到虚拟资源的虚拟化映射过程。面向租户控制器虚拟化平台充当数据平面角色将模拟出来的虚拟网络呈现给租户控制器。从租户控制器上往下看只能看到属于自己的虚拟网络而并不了解真实的物理网络。而在数据层面的角度看虚拟化平台就是控制器而交换机并不知道虚拟平面的存在。所以虚拟化平台的存在实现了面向租户和面向底层网络的透明虚拟化其管理全部的物理网络拓扑并向租户提供隔离的虚拟网络。 虚拟化平台不仅可以实现物理拓扑到虚拟拓扑“一对一”的映射也应该能实现物理拓扑“多对一”的映射。而由于租户网络无法独占物理平面的交换机所以本质上虚拟网络实现了“一虚多”和“多虚一”的虚拟化。此处的“一虚多”是指单个物理交换机可以虚拟映射成多个虚拟租户网中的逻辑交换机从而被不同的租户共享“多虚一”是指多个物理交换机和链路资源被虚拟成一个大型的逻辑交换机。即租户眼中的一个交换机可能在物理上由多个物理交换机连接而成。
网络资源虚拟化
为实现网络虚拟化虚拟化平台需要对物理网络资源进行抽象虚拟化其中包括 拓扑虚拟化节点资源虚拟化和链路资源虚拟化 • 拓扑虚拟化【核心: 将物理节点映射给一个或多个用户/租户】 拓扑虚拟化是网络虚拟化平台最基本的功能。虚拟平台需要完成租户虚网中的虚拟节点和虚拟链路到物理节点和链路的映射。其中包括“一对一”和“一对多”的映射。 “一对一”的映射中一个虚拟节点将会映射成一个物理节点同理虚拟链路也是。 “一对多”的映射中一个虚拟节点可以映射成由多个连接在一起的物理节点一条逻辑链路也可能映射成由链接在一起的多条链路。而对于物理节点而言一个物理节点可以被多个逻辑节点映射。
• 节点资源虚拟化【核心: 控制每个用户/租户能使用物理设备上多少资源】 节点资源的虚拟化包括对节点Flow tables流表、CPU等资源的抽象虚拟化。 流表资源本身是交换机节点的稀缺资源如果能对其进行虚拟化然后由虚拟化平台对其进行分配分配给不同的租户那么就可以实现不同租户对节点资源使用的分配和限制。拓扑抽象仅仅完成了虚拟节点到物理节点的映射而没有规定不同用户/租户对物理节点资源使用的分配情况。若希望进行更细粒度的网络虚拟化节点资源虚拟化非常有必要。
• 链路资源虚拟化【核心: 控制不同用户/租户能使用多少链路带宽端口队列长度】 和节点资源一样链路资源也是网络中重要的资源而拓扑抽象并没有规定某些用户可使用的链路资源的多少。所以在进行更细粒度的虚拟化时有必要对链路资源进行虚拟化从而实现链路资源的合理分配这样就能够抽象虚拟化的链路资源包括租户可使用的带宽以及端口的队列资源等等。
网络隔离
网络资源虚拟化仅仅完成了物理资源到虚拟资源的抽象过程为实现完全的网络虚拟化还需要对不同的租户提供隔离的网络资源。网络隔离需要对SDN的控制平面和数据平面进行隔离从而保证不同租户控制器之间互补干扰不同虚网之间彼此隔离。此外为了满足用户对地址空间自定义的需求虚拟化平台还需要对网络地址进行虚拟化。
控制面隔离
控制器的性能对SDN整体的性能产生极大的影响所以虚拟化平台需保证租户的控制器在运行时不受其他租户控制器的影响保证租户对虚拟化平台资源的使用。虚拟化平台在连接租户控制器时需保证该进程可以得到一定的资源保障比如CPU资源。而虚拟化平台本身所处的位置就可以轻易实现租户的控制器之间的相互隔离。
数据面隔离
数据面的资源包括节点的CPU、Flow Tables等资源以及链路的带宽端口的队列资源等。为保证各个租户的正常使用需对数据面的资源进行相应的隔离从而保证租户的资源不被其他租户所占据。若在数据面上不进行资源的隔离则会产生租户数据在数据面上的竞争从而无法保障租户对网络资源的需求所以很有必要在数据面对资源进行隔离。
地址隔离
为使租户能在自己的虚拟租户网中任意使用地址虚拟化平台需要完成地址的隔离。实现地址隔离主要通过地址映射来完成。租户可任意定制地址空间而这些地址对于虚拟化平台而言是面向租户的虚拟地址。虚拟化平台在转发租户控制器南向协议报文(即:发送的报文)时需要将虚拟地址转化成全网唯一的物理地址。租户的服务器的地址在发送到接入交换机时就会被修改成物理地址【注意: 这里不是NAT转换地址而是通过FlowTable来修改报文字段的】然后数据包的转发会基于修改之后的物理地址进行转发。当数据到达租户目的地址主机出端口控制器需将地址转换成原来租户设定的地址从而完成地址的虚拟化映射。地址的虚拟化映射使得租户可以使用完全的地址空间可以使用任意的FlowSpace流空间流表匹配项所组成的多维空间而面向物理层面则实现了地址的隔离使得不同的租户使用特定的物理地址数据之间互不干扰。
关于SDN的摘录补充 它的核心是SDN拥有一个集中或分布式智能实体它具有网络的整体视图可以根据该视图做出路由和切换决策”Capuano说。“通常网络路由器和交换机只知道它们的相邻网络设备。但是通过正确配置的SDN环境该中央实体可以控制一切从而轻松更改策略简化整个企业的配置和自动化。“
通常在SDN环境中客户可以看到他们所有的设备和TCP流这意味着他们可以从数据或管理平面切断网络以支持各种应用和配置Capuano说。因此用户可以根据需要更轻松地从生产环境中对IoT应用程序进行细分。 一些SDN控制器能够智能地“看到”网络正在变得拥挤。作为响应SDN控制器将增加带宽或做出其他处理以确保远程和边缘组件不会受到延迟影响。
网络可以分为两部分一部分可以是面向公众的低安全性网络在这部分网络中不会触及任何敏感信息。另一个细分的网络可以通过基于软件的防火墙和加密策略实现更细粒度的远程访问控制允许敏感数据在该网络上传输。“例如如果客户拥有一个物联网组但该网络在安全性方面并不是那么成熟通过SDN控制器您可以将该组从企业关键流量中分离出来”Capuano说。“SDN用户可以在网络范围内推出从数据中心到边缘的安全策略如果你在白盒子上完成所有这些工作部署可以比传统设备便宜30-60。
OpenFlow实现上面架构的核心: OpenFlow规范实际上是一整套软件应用程序接口控制网络数据如何转发可基于硬件实现OpenFlow增加了定制转发数据的控制程度减少了支撑复杂控制所需的硬件成本。OpenFlow网络控制节点可以通过规范与支持OpenFlow的交换节点沟通配置信息决定数据转发平面的转发表控制器与转发节点间通过SSL加密传输。OpenFlow支持定义的“信息流”主要是从1层到4层的关键信息包括端口号、VLAN、MAC、以太网包头、IP地址、 IP协议号、TCP端口号等。配置信息通常包括“信息流”和与之对于的动作。每个“信息流”有符合某种特征的数据包及动作组成比如源IP/源Port目的IP/目的Port5种不同转发动作。 OpenFlow架构图: OpenFlow “信息流”定义: 用户可以通过OpenFlow预设通用规则每种不同网络节点可以根据设备特点更新转发平面规则比如转发交换机更新MAC地址转发表、VLAN端口转发表、1到4层转发表路由器修改访问控制IP列表防火墙修改进出端口规则等。 这里就是OpenFlow可定义规则的10元组 OpenFlow它增加了网络灵活控制能力位于底层的分布式网络设备节点的智能性通过OpenFlow指令得以实现集中式的OpenFlow Controller节点的实时控制底层物理网络的变化并为各个分布式物理节点生成快速转发表而无须各个物理节点进行复杂智能分析计算它们就可专心执行网络转发平面的功能。当新的转发节点加入到OpenFlow网络时自动从中央控制节点得的最新网络配置信息完成网络自动化感知。而中央控制节点基于x86标准服务器架构强大计算能力和横向扩展特性保证了控制平面扩展性和经济性。 OpenFlow独立控制平面的出现TRILL或Shortest Path Bridging协议变得不是那么重要因为OpenFlow控制器可以拥有有全网视图所以动态防止环路发生。OpenFlow不但提高了传统转发平面的效率在提供高级网络服务方面还可以展现独特的价值比如多对一的网络虚拟化分布式负载均衡和分布式防火墙或入侵检测非常不同于传统模式的一对多网络虚拟化模式。每一类分布式网络资源服务与单独云租户对应每个云租户都有独立的跨物理节点的虚拟化网络比如不同虚拟网络交换机对不同租户管理员来说它所对应的物理网络端口是透明逻辑化网络派生于在物理网络资源上抽象出的虚拟网络资源池。虚拟机移动后当虚拟机相应“信息流”的第一个数据包到达移动后的本地(物理/虚拟)交换机节点如果本地交换机节点没有发现匹配的转发规则整个数据报文会被送到中央管理节点中央管理节点根据定义转发规则逻辑下发相应的转发规则并应用到本地交换机的转发表建立新的匹配项之后的“信息流”不再通过管理节点由转发节点直接完成。
OpenFlow的应用
随着OpenFlow/SDN概念的发展和推广其研究和应用领域也得到了不断拓展。目前关于OpenFlow/SDN的研究领域主要包括网络虚拟化、安全和访问控制、负载均衡、聚合网络和绿色节能等方面。另外还有关于OpenFlow和传统网络设备交互和整合等方面的研究。
下面将举几个典型的研究案例来展示OpenFlow的应用。
1. 网络虚拟化 – FlowVisor
网络虚拟化的本质是要能够抽象底层网络的物理拓扑能够在逻辑上对网络资源进行分片或者整合从而满足各种应用对于网络的不同需求。为了达到网络分片的目的FlowVisor实现了一种特殊的OpenFlow Controller可以看作其他不同用户或应用的Controllers与网络设备之间的一层代理。 因此不同用户或应用可以使用自己的Controllers来定义不同的网络拓扑同时FlowVisor又可以保证这些Controllers之间能够互相隔离而互不影响。 用计算机的虚拟化来类比则FlowVisor就是位于硬件结构元件和软件之间的网络虚拟层。FlowVisor允许多个控制同时控制一台OpenFlow交换机但是每个控制器仅仅可以控制经过这个OpenFlow交换机的某一个虚拟网络即slice。因此通过FlowVisor建立的试验平台可以在不影响商业流的转发速度的情况下允许多个网络试验在不同的虚拟网络上同时进行。FlowVisor与一般的商用交换机是兼容的而不需要使用FPGA和网络处理器等可编程硬件。
下图展示了使用FlowVisor可以在同一个物理网络上定义出不同的逻辑拓扑。FlowVisor不仅是一个典型的OpenFlow应用案例同时还是一个很好的研究平台目前已经有很多研究和应用都是基于FlowVisor做的。
2. 负载均衡 – Aster*x
传统的负载均衡方案一般需要在服务器集群的入口处通过一个gateway或者router来监测、统计服务器工作负载并据此动态分配用户请求到负载相对较轻的服务器上。既然网络中所有的网络设备都可以通过OpenFlow进行集中式的控制和管理同时应用服务器的负载可以及时地反馈到OpenFlowController那里那么OpenFlow就非常适合做负载均衡的工作。 Aster*x通过Host Manager和Net Manager来分别监测服务器和网络的工作负载然后将这些信息反馈给FlowManager这样Flow Manager就可以根据这些实时的负载信息重新定义网络设备上的OpenFlow规则从而将用户请求(即网络包)按照服务器的能力进行调整和分发。
3. 绿色节能的网络服务 – ElasticTree
在数据中心和云计算环境中如何降低运营成本是一个重要的研究课题。能够根据工作负荷按需分配、动态规划资源不仅可以提高资源的利用率还可以达到节能环保的目的。 ElasticTree创新性地使用OpenFlow在不影响性能的前提下根据网络负载动态规划路由从而可以在网络负载不高的情况下选择性地关闭或者挂起部分网络设备使其进入节电模式达到节能环保、降低运营成本的目的。
OpenFlow的面临的难题和优势【摘录片段】
OpenFlow 1.0的流表分为Match Fields、计数器和指令集三个部分Match Fields是报文匹配的输入关键字计数器是管理所需指令集是决定报文如何转发最基本的转发行为包括转发给某个端口、封装改写报文后转发以及丢弃。OpenFlow 1.1增加了对MPLS以及UDP/SCTP传输层协议的支持同时针对流表开销过大的情况设计了多级流表并增加分组策略功能。
openflow的价值到底在哪里是Open还是Flow这个问题首先可以否认”Flow”的价值原因很简单是否控制到细粒度的Flow取决于应用应用没有控制流的需求则Flow毫无价值”Flow”只是Openflow能提供的最大限度的控制能力而已目前在ONF关注的数据中心交换网中没有谁打算控制精确到n(n5)元组的流除非是应用在防火墙控制上。 那么”Open”呢的确包括Nick本人在内一直强调的都是”Open”是价值之所在Open之后研究者、运营商可以采购任意厂商的标准接口设备自己DIY网络甚至可以采用交换信息厂商提供的公版设计交换机加上OpenFlow Controller就可以组成自己所需的网络并且Controller的开放软件架构使得网络控制的实现就像Web编程一样简单采用Python、JAVA Script这样的脚本加上开源算法库、一个不需要了解太多网络协议细节的开发者几天就可以实现一个新的网络拓扑算法开发、部署。这在流量模型尤为复杂运营级数据中心确实非常有吸引力。在这样的一种场景中网络设备市场就变成了如同PC那样的市场卖网络设备硬件的就成了卖大白菜的大家最后只能比拼价格和工艺设计了。但是即使这种悲惨的场景成为事实谁又会是PC化的网络市场中提供Windows的微软呢Openflow体系的NOSNetwork OS将会谁是赢家交换网络相对简单但是L3之上各种协议散落在数十年积累的数千篇IETF RFC中谁能够有实力实现一个如此复杂的网络操作系统而又让运营商放心呢我想仍然可能是今天的网络设备巨头Cisco、Juniper们产生意外的可能极小。
Arista定义了软件定义云网络的四大“支柱云拓扑、分布式控制、网络虚拟化和管理/自动化。OpenFlow只是实现基于控制器的SDN管理/自动化支柱中的多种方法中的一种而已。其他的实现方法还有CLI、SNMP、XMPP、Netconf、OpenStack、VMware vSphere虚拟化软件等等。 在今年的VMworld大会上Arista演示了如何用虚拟机的简单预配置来构建云利用其EOS操作系统软件和CloudVision接口最多可实现5万个网络节点。XMPP是其CloudVision中的API。 “没有任何理由认为明天不会出现一个OpenFlow或者OpenStack APIUllal说。“但是现在就有一个完善定义的接口。我们今天用Netconf和XMPP就是因为它很容易实现各种规范定义完善而且我们的一些客户对此很感兴趣。
-------谨记快就是慢慢就是快
https://www.cnblogs.com/wn1m/p/11281781.html
