Openflow协议通信流程解读

OPenfIoW协议通信流程解读北邮学生李呈技术分享李呈网站SDNARcomM⅛布OPenfloW协议通信流程解读■，■前言接触了这么久的SDN,OPenfIoW协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。现在有时间了，就写一写自己对OPenfIoW协议通信流程的一些理解。SDN中Switch和controller在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当于上帝，可以知道网络中所有的消息，可以给交换机下发指令。SWitCh就是一个实现Controller指令的实体，只不过这个交换机跟传统的交换机不一样，他的转发规则由流表指定，而流表由控制器发送.switch组成与传统交换机的差异switch组成switch由一Z个SecureChannel和一Z个flowtable组成，of1.3之后table变成多级流表,有256级。而of1.0中table只在table0中。, SecureChannel是与控制器通信的模块,switch和controller之间的连接时通过socket连接实现., Flowtable里面存放这数据的转发规则，是switch的交换转发模块。数据进入switch之后,在table中寻找对应的flow进行匹配,并执行相应的action，若无匹配的flow则产生PaCket_in（后面有讲）of中sw与传统交换机的差异, 匹配层次高达4层，可以匹配到端口，而传统交换机只是2层的设备。, 运行of协议，实现许多路由器的功能，比如组播。,求补充！！（如果你知道，请告诉我，非常感谢！）openflow的switch可以从以下方式获得,实体of交换机，目前市场上有一些厂商已经制造出of交换机,但是普遍反映价格较贵！性能最好。, 在实体机上安装OVS,OVS可以使计算机变成一个openflow交换机。性能相对稳定., 使用mininet模拟环境。可以搭建许多交换机，任意拓扑才搭建拓扑具体教程本博客有一篇.性能依赖虚拟机的性能。controller组成控制器有许多种，不同的语言加python写的pox,ryu，如java写的floodlight等等.从功能层面controller分为以下几个模块：■ 底层通信模块：openflow中目前controller与switch之间使用的是socket连接,所以控制器底层的通信是socket., openflow协议.socket收到的数据的处理规则需按照openflow协议去处理。, 上层应用：根据openflow协议处理后的数据，开发上层应用，比如pox中就l2_learning，l3_learning等应用。更多的应用需要用户自己去开发。Openflow通信流程以下教程环境为：mininet+自编简单控制器建立连接首先启动mininet，mininet会自行启动一个default拓扑,你也可以自己建立你的拓扑。SW建立完成之后，会像「位⑹国卬：controllerport发送数据.controller启动之后，监听指定端口，默认6633,但是好像以后的都改了,因为该端口被其他协议占用。3次握手之后，建立连接，这个是底层的通信,是整一套系统的基础设施。OFPTjHELLO创建socket之后,sw跟controller会彼此发送hello数据包。, 目的：协议协商., 内容：本方支持的最高版本的协议, 成果：使用双方都支持的最低版本协议。, 成功：建立连接• 失败：OFPTJERROR(TYPE:OFPTJHELLOJFAILED,CODE=0)，终止连接.OFPTJERROR说到OFPTJERROR,我们不妨先了解一下.ofp_error_type={: ,: ,:ILED”}错误类型如上所示。对应的type还会有对应的code。所以报错的格式为：OFPT_ERRORTYPE：CODE：[PAYLOAD]具体的错误信息。如TYPE:0CODE:0为：*OFPHFC_INCOMPATIBLE具体对应的关系，请自行查看OF协议。OFPLECHO， 分类：对称信息OFPT_ECHO_REQUEST,OFPT_ECHO_REPLY， 作用：查询连接状态,确保通信通畅.当没有其他的数据包进行交换时,controller会定期循环给Sw发送OFPT_ECHO_REQUEST.OFPLFEATURES当Sw跟controller完成连接之后，控制器会向交换机下发OFPLFEATYRES_REQUEST的数据包，目的是请求交换机的信息。， 发送时间：连接建立完成之后， 发送数据：OFPLFEATURES_REQUEST， 对称数据：OFPLFEATURES_REPLY， 目的:获取交换机的信息OFPLFEATURES_REQUEST, TYPE=5, WithoutdataOFPLFEATURES_REPLY, TYPE=6[0:8]为header[8:32]长度24byte为Sw的features[32:]长度与端口数成正比，存放port的信息。每一个port信息长度为48byteoclassofp_features_reply(Packet)：fields_desc=[BitFieldLenField('datapath_id'，None,64,length_of='Varfield'),BitFieldLenField('n_buffers',None,32,Iength_of='Varfield’),XByteField("n_tables”，0),X3BytesField(“pad”，0),#featuresBitField("NOTDEFINED”，0,24),,0,1), #1<〈7MatchIPaddressinARPpackets),#1〈〈6QueuestatisticsBitField(1<〈5CanreassembleIPfragmentsBitField( ,0,1),1〈〈4Reserved,mustbezeroBitField( ,0,1),1〈〈3802.1dspanningtree,0,1),#1<〈2PortstatisticsBitField( ),1〈〈1TablestatisticsBitField( ,0,1),1<〈0FlowstatisticsBitFieIdLenField('actions',None,32,Iength_of='Varfield’)，]bind_Iayers(ofp_header,ofp_features_reply,type=6)以上的结构是交换机的features,紧跟在后面的是端口的结构：classofp_phy_port(Packet):fields_desc=[ShortEnumField("port_no"，0,ofp_port),

MACField( ,”00:00:00：00:00:00”)，StrFixedLenFie ,length=16),

BitField( ,),

BitField("OFPPC_NO_FWD”，0,1),

,0,1),,0,1),

BitField( ,1),BitField("OFPPC_NO_STP”，0,1),

BitField(#uint32_tforstate

,0,31),

,0,1),#uint32_tforCurrentfeatures

,0,20),

BitField("OFPPF_PAUSE_ASYM"，0,1),

BitField("OFPPF_PAUSE”，0,1),

BitField("OFPPF_AUTONEG”，0,1),MNMMMBitField(,1),BitField(,0,1),),BitField("OFPPF_1,0,1),BitField(,0,1),BitField(,0,1)BitField(,0,1),BitField(,0,1),BitField("OFPPF_10,0,1),#uint32_tforfeaturesbeingadvisedbytheport,0,32)，#uint32_tforfeaturessupportedbytheport,32),#uint32_tforfeaturesadvertisedbypeerBitField( )]交换机和端口的配置信息在整一个通信过程起着至关的作用，因为所有关于的操作都需要从features里面提取相关的信息，如dpid,porLno，等在整个通信过程中多次被用到的重要数据.所以,对这两个数据结构了然于心,对于研究openflow来说，至关重要。每一次交换机连到控制器，都会收到控制器的featuresJequeSt,当Sw将自己的features回复给控制器之后，控制器就对交换机有了一个全面的了解,从而为后面的控制提供的控制信息。OFPLPACKET_IN在控制器获取完交换机的特性之后，交换机开始处理数据。对于进入交换机而没有匹配流表，不知道如何操作的数据包，交换机会将其封装在Packet_in中发给controller.包含在Packet_in中的数据可能是很多种类型，arp和icmp是最常见的类型。当然产生Packet_in的原因不止一种，产生Packet_in的原因主要有一下两种：OFPR_NO_MATCHOFPR_ACTION无法匹配的数据包会产生PackeUn,action也可以指定将数据包发给PackeUn，也就是说我们可以利用这一点，将需要的数据包发给控制器.PackeUn事件之后,一般会触发两类事件：Packet_outflow_mod如果是广播包,如arp控制器一般会将其包装起来，封装成Packetqut数据包,将其发给交换机，让其floodflood操作是将数据包往除去in_port以外的所有端口发送数据包。OFPLPACKELOUT很多人不是特别了解Packetqut的作用。, 作用：通过控制器发送交换机希望发送的数据, 例子:arp在广播的时候，在ofsw中不能直接将arp广播,而是，将其封装在Packet_out里面，交换机泛洪的是Packet_out。我个人观点，这个数据包，是一个兼容性之的数据包，为了实现信令,不得不处理arp，但是arp又不能直接处理，所以将其封装在Packetqut，从而能够在of的Sw中传播，从而在openflow里实现arp等IP网的功能。OFPLFLOW_MODOFPT_FLOW_MOD是整一个OPenfIOw协议中最重要的数据结构，没有之一.OFPT_FLOW_MOD由header+match+flow_mod+action[]组成。为了操作简单，以下的结构是将wildcards和match分开的形式，形成两个结构，在编程的时候能更方便一些。由于这个数据包很重要，所以，我将把这个数据包仔细拆分解读.flow_mod=of.ofp_header(type=14,length=72)/of.ofp_flow_wildcards(OFPFW_NW_TOS=1,OFPFW_DL_VLAN_PCP=1,OFPFW_NW_DST_MASK=0,OFPFW_NW_SRjMASK=0,OFPFW_TP_DST=1,OFPFW_TP_SRC=1,OFPFW_NW_PROTO=1,OFPFW_DL_TYPE=1,OFPFW_DL_VLAN=1,OFPFW_IN_PORT=1,OFPFW_DL_DST=1,/of.ofp_match(in_port=msg。Payload.payload.payload.in_port,dl_src=pkt_parsed。src,dl_dst=pkt_parsed.dst,dl_type=pkt_parsed。type,dl_vlan=pkt_parsed.payload,vlan,nw_tos=pkt_parsed。payload。tos,nw_proto=pkt_to,nw_src=pkt_parsed。Payload.src,nw_dst=pkt_parsed。payload。dst,tp_src=0,/of.ofp_flow_mod(Cookie=0,Command=0,idle_timeout=10,hard_timeout=30,out_port=msg.payload.payload。Payload.payload。port,buffer_id=buffer_id,flags=1)OFP_HEADERheader是所有数据包的报头，有三个参数：■ type:类型, length:整个数据包的长度, xid:数据包的编号比如ofp_flow_mod的type就是14,具体的哪一种数据的类型将在文章最后给出。length最基本长度为72，每一个action长度为8。所以长度必定为8的倍数才是一个正确的数据长度。WILDCARDS这是从match域提取出来的前32bit。在of1。0中这里的0,1意义跟我们平时接触的如子网掩码等意义相反,如OFPFW_NW_DST_MASK=0则表示全匹配目标卬。如果为63,则表示不匹配IP。为什么拿这个举例？原因就在于，他的长度是6bit，最大是63，需要将数值转变成对应2进制数值才是我们想要的匹配规则，且注意，1是忽略，0是匹配。如果WildcardS全0，则表示由match精确指定，即所有12元组都匹配.当然高兴的是，在1.3的时候，这个逻辑改成了正常的与逻辑。即1为使能匹配,0为默认不匹配。MATCH这个数据结构会出现在几乎所有重要的数据包中,因为他存的就是控制信息。如有PackeUn引发的下发流表，则match部分应对应填上对应的数据，这样下发的流表才是正确的。但是在下发的时候还需要注意许多细节，比如：, 并不是所有的数据包都有Vlanjag。如0×0800就是纯IP,并没有携带vlan_tag，所以填充式应根据PackeUn的具体情况填充。, 并不是所有的数据都有四层端口，所以四层的源端口，目的端口都不是任何时候都能由PackeUn去填充的。不去管就好了，默认的会填充一个默认值,匹配的时候不去匹配4层端口就没有问题.FLOW_MOD这里面的信息也是至关重要的。classofp_flow_mod(Packet)：fields_desc=[BitField("cookie”，0,64),#OPaquecontroller—issuedidentifierShortEnumField( ,0,ofp_flow_mod_Command),ShortField( ,60),ShortField( ),，0),),,0),#flagsareimportant,the1〈＜0bitisOFPFF_SEND_FLOW_REM,sendOFPT_FLOW_REMOVED#1〈＜1bitisOFPFF_CHECK_OVERLAP,checkingiftheentries'fieldoverlaps(amongsamepriority)#1〈〈2bitisOFPFF_EMERG,usedonlyswitchdisconnectedwithcontroller)ShortField( )]command里面的类型决定了flow_mod的操作是添加，修改还是删除等。类型如下ofp_flow_mod_command={0：1： , #Modifyallmatchingflowsentrystrictlymatchingwildcards3：allmatchingflows4： #Strictlymatchwildcardsandpriority例如：如果要添加一条新流，command=。.两个时间参数idle_timeout&idle_timeout:, idle_timeout:如值为10厕某条流在10秒之内没有被匹配，则删除，可以称之为活跃时间吧。, hard_timeout:如值为30，则30秒到达的时候,一定删除这条流,即使他还活跃，即被匹配。priorityPriOrity是流的优先级的字段，字数越大则优先级越高，存放在号数越小的table中.buffer_id由交换机指定的buffeLid准确的说是由dpid指定的.如果是手动下发的流，buffer_id应填一1，即0xffff,告诉交换机这个数据包并没有缓存在队列中.out_port指定流的出口，但是这个出口并不是直接指导流转发的，至少我是这么觉得，指导流转发的出口会在action里面添加，这个端口是为了在flow_removed的时候查询，并返回控制器的作用。（求纠正！）有一些端口是很特殊的，如flood，local等。具体分类如下：Oxfffa: ,Oxfffc：Oxfffd：Oxfffe：Oxffff:"OFPP_NONE”}如果你不知道端口是多少，最好填flood，也就是0xfffboflags在上面的注释中也说得比较清楚了。如果没有特殊用处，请将他置1，因为这样能让交换机在删除一条流的时候给交换机上报flow_removed信息.ACTIONaction是openflow里面最重要的结构。对，他也是最重要的.每一条流都必须指定必要的action,不然匹配上之后，没有指定action，交换机会默认执行drop操作。action有2种类型：必备行动：ForWardandDrop选择行动:FLOOD，NALMAL等如添加OutPut就是一个必须要添加的action.每一个action最好有一个action_header(),然后再接一个实体.如：ofp_action_header(type=0)/ofp_action_OutPut(type=0,port=Oxfffb,len=8)具体的action类型如下：ofp_action_type={0: PUT”，,"OFPAT_SET_NW_DST”，10:“OFPAT_SET_TP_DST”，action不仅仅会出现在flow_mod中，也会出现在如stats_reply中。OFPLBARRIER_REQUEST&&REPLY这个数据包可以的作用很简单，交换机在收到OFPT_BARRIER_REQUEST的时候，会回复控制器一个OFPT_BARRIER_REPLY。我们默认数据下发的顺序不会在传输中发生变化,在进入消息队列之后处理也是按照FIFO进行的,那么只要在flow_mod之后发送这个数据,当收到reply之后，交换机默认flow已经写成功。也许你会问他只是保证了flow_mod命令执行了，写入的结果如何并没有保证，如何确定确实写入流表了呢？, 如果非逻辑错误,那么交换机在处理flow_mod的时候会报错.所以我们会知道写入结果。, 如果是逻辑错误，那么会写进去，但是逻辑错误应该是人的问题，所以barrier还是有他的功能的.OFPT_FLOW_REMOVED如果flow_mod的flags填成L则该流在失效之后会回复控制器一条OFPT_FLOW_REMOVED信息。结构：header()/wildcards()∕match()/flow_removed()作用：在流失效的时候回复控制器，并携带若干统计数据。classofp_flow_removed(Packet)：fields_desc=[ ,64),，0,16),BitField("reason”,0,8),,None),，0,32),),BitField( ,ByteField( ,0),,0),BitField("packet_count”，0,64),BitField( ,64)]其实的duration_sec是流存在的时间，单位为秒，duratiOnjSec单位为纳秒.OFPLSTATS_REQUEST&&REPLY以上的数据都是通信过程中必须的部分。还有一些数据包是为了某些目的而设计的，如OFPT_STATS_REQUEST&&REPLY可以获得统计信息,我们可以利用统计信息做的事情就太多了。如：负载平衡，流量监控等基于流量的操作。OFPLSTATS_REQUESTOFPT_STATS_REQUEST类型有很多，回复的类型也很多。classofp_stats_request(Packet):name="OpenFlowStatsRequest”fields_desc=[ShortEnumField( ,0,ofp_stats_types),ShortField(]Type0:请求交换机版本信息，制造商家等信息.1：单流请求信息2:多流请求信息3:流表请求信息4端口信息请求5:队列请求信息6：vendor请求信息，有时候没有定义。msg={0:of.ofp_header(type=16,length=12)/of.ofp_stats_request(type=0),#TypeofOFPST_DESC(0)1:of.ofp_header(type=16,length=56)/of。ofp_stats_request(type=1)/ofp_flow_wildcards/ofp_match/of.ofp_flow_stats_request(out_port=ofp_flow_mod。out_port), #flowstats2:of。ofp_header(type=16,length=56)/of.ofp_stats_request(type=2)/ofp_flow_wildcards/of。OfPjmatch/of.ofp_aggregate_stats_request(),#aggregatestatsrequest• 3:of。OfPJheader(type=16,length=12)/of.ofp_stats_request(type=3),#TyPeofOFPSTJTABLE(0)• 4:of.ofp_header(type=16,length=20)/of.ofp_StatSJrequeSt(type=4)/of。OfPJPortJStatSJrequeSt(PortJno=port),#portstatsrequest» 5:of。ofp_header(type=16,length=20)/of。ofp_stats_request(type=5)/of.ofp_queue_stats_request(), ≠≠queuerequest» 6:of.ofp_header(type=16,length=12)/of。ofp_stats_request(type=0xffff)#vendorrequest}OFPLSTATS_REPLY每一种请求信息都会对应一种回复信息。我们只介绍最重要的flow_stats_reply.• 结构：header(type=17)/reply_header()/flow_stats/wildcards/match/flow_stats_data, 作用：携带流的统计信息，如通过的数据包个数，字节数。ofp_flow_stats(body[4:8])里面会有的table_id字段表明该流存放在哪一个流表里.flow_stats_data里面有Packet_count和byte_count是最有价值的字段，流量统计就是由这两个字段提供的信息。如想统计某条流的速率：前后两个reply的字节数相减除以duration_time只差就可以求得速率由速率我们可以做很多基于流量的app,如流量监控，负载均衡等等。值得注意的是，在这些数据之后，其实还有一些action，但是目前我还没有查看这些action到底是干什么用的。后续写到这里，我使用到的数据包都写了一遍，其他的报文其实道理也是一样的。如OFPT_GET_CONFIG_REQUEST和REPLY,道理应该和StatS一样，只是数据结构不一样罢了。不再多说。最后把我们用的一些比较多的信息帖出来让大家更好的学习。ERROR在调试的过程中遇到错误是再所难免的，前面也提到了error的结构。这里就贴一下type跟code吧Typeofp_error_type={0:"OFPET_HELLO_FAILED”,,2：3： ,4： ,Code:1:“OFPHFjEPERM”},1：2：”OFPBRC_BAD_STAT”，3：”OFPBRC_BAD_VENDOR”，4：”OFPBRC_BAD_SUBTYPE”,5： ,ofp_bad_action_code#PermiSSionSerrorofp_flow_mod_failedofp_port_mod_failedofp_queue_op_failed6：,,}={0:"OFPBAC_BAD_TYPE”，1:"OFPBAC_BAD_LEN”，2：”OFPBAC_BAD_VENDOR”,4：”OFPBAjBAD_OUT_PORT”,8：}code={0：,4:“Ocode={0：1：”OFPPFMC_BAD_HWcode={0：1：,,,,ADDR”}}第二章理论基础2。1软件定义网络SDN软件定义网络（英语：Software-definednetworking,缩写为SDN）,一种网络虚拟化（NetworkVirtualiZatiol）技术，由美国史丹佛大学CleanState提出。利用OPenFlOw协定，把路由器的控制平面（controlplane）从数据平面（dataplane）中分离出来，以软件方式实做。这个架构可以让网络管理员，在不更动硬件装置的前提下,以中央控制方式，用程式重新规划网络，为控制网络流量提供了新的方法，也提供了核心网络及应用创新的良好平台。2。2openflow网络架构OpenFlow网络由OPenFloW交换机、FloWViSor和Controller三部分组成。OpenFlow交换机进行数据层的转发；FlowVisor对网络进行虚拟化;Controller对网络进行集中控制，实现控制层的功能.如下图所示:2o2o1OPenfIOW交换机OpenFlow交换机由流表、安全通OpenFIowProtocol道和OPenFlOW协议三部分组成QPenFlOW交换机是整个OPenFlOW网络的核心

部件，主要管理数据层的转发。OPenFlOW交换机接收到数据包后，首先在本地的流表上查找转发目标端口,如果没有匹配，则把数据包转发给Controller由控制层决定转发端口。2。2.1.1流表流表包括包头域（headerfileds,匹配包头多个域）、活动计数器（counters）、0个或多个执行行动（actions）如图二所示.对每一个包进行查找，如果匹配则执行相关策略，否则通过安全通道将包转发到控制器，控制器来决策相关行为。流表项可以将包转发到一个或者多个接口。HeadFiledsCounterActions图二：流表包头域包括12个域，如图三所示,包括：进入接口，Ethernet源地址、目标地址、类型，Vlanid,Vlan优先级，IP源地址、目标地址、协议、IPToS位,TCP/UDP目标端口、源端口。每一个域包括一个确定值或者所有值（any）,更准确的匹配可以通过掩码实现.IngressPortEtherSourceEtherDstEtherTypeVlanidVlanPriorityIPsrCIPdstIPprotoIPTosbitsTCP/UDPsrcPortTCP/UDPDstPort图三：包头域计数器可以针对每张表、每个流、每个端口、每个队列来维护。用来统计流量的一些信息，例如活动表项、查找次数、发送包数等。统计信息所需要的计数器如图四所示:每个表项对应到0个或者多个行动，如果没有转发行动，则默认丢弃。多个行动的执行需要依照优先级顺序依次进行.但对包的发送不保证顺序.另外交换机可以对不支持的行动返回错误（UnSPPortedflowerro）。行动可以分为两种类型：必备行动（RequiredActions）和可选行动（OptionalActions），必备行动是默认支持的，交换机需要通知控制器它支持的可选行动.必备行动-转发（ForWard）ALL转发到所有出口（不包括入口）CONTROLLER封装并转发给控制器LOCAL转发给本地网络栈TABLE对要发出的包执行流表中的行动IN_PORT从入口发出必备行动一丢弃（DroP）没有明确指明处理行动的表项，所匹配的所有网包默认丢弃.可选行动—转发NORMAL按照传统交换机的2层或3层进行转发处理。FLOOD通过最小生成树从出口泛洪发出，注意不包括入口。可选行动-入队(Enqueue)将包转发到绑定到某个端口的队列中.可选行动-修改域(Modify—field)修改包头内容.CounterBitsPerTableActiveEntries32PacketLookups64PerFlowReceivedPackets64ReceivedBytes64DUrations(SeConds)32PerPortReceivedPackets64TransmittedPackets64ReceivedBytes64TransmittedBytes64ReceivedDrops64TransmitDrops64ReceivedErrors64TransmitDrops64ReceiveFrameAlignmentErrors64ReceiveOverrunErrors64ReceiveCRCErrors64Collisions64PerQueueTransmitPackets64TransmitBytes64TransmitOverrunErrors64图四：信息统计计数器2。2。1.2流表匹配每个包按照优先级依次去匹配流表中表项，匹配包的优先级最高的表项即为匹配结果。一旦匹配成功，对应的计数器将更新；如果没能找到匹配的表项，则转发给控制器。整体流程参见图五,具体包头解析匹配过程见图六。图五:整体匹配流程OxSlOOιι,⅛H?pτot□tlkιypt⅛

(MXoB1i5i3⅛]A∖[B,PCP*设置JPSrcJ>s1Irwp用结定包头传找TCT7L1DPSrcb,∣J⅛I初^⅛⅛"⅛包头tInpLttpert,Ether

SoLircepde⅛tinmi∏tlype)设置1产⅛r<?.Dst,.proto,T□sbits图六：包头解析的匹配流程2.2.2openflow控制器OPenFlow实现了数据层和控制层的分离，其中OPenFlOw交换机进行数据层的转发，而Controller实现了控制层的功能.Controller通过OpenFlow协议这个标准接口对OPenFlOw交换机中的流表进行控制,从而实现对整个网络进行集中控制。Controller的这一切功能都要通过运行NOX来实现，因此NOX就像是OpenFlow网络的操作系统.NOX主要功能包括两部分，一是针对下层的SDN交换机（例如of交换机）作为控制器，解析交换机行为和进行管理操作；一是针对上层网络管理aPP开发者，作为一个抽象层（操作系统）提供易用的开发接口.针对这两部分功能,NOX的开发模型主要包括两个部分。一是集中的编程模型。开发者不需要关心网络的实际架构，部署在单一节点上的NOX管理网络中的所有交换设备,解析后呈现给开发者。在开发者看来整个网络就好像一台单独的机器一样，有统一的资源分配和接口管理。二是抽象的开发模型。应用程序开发需要面向的是NOX提供的高层接口，而不是底层。例如，应用面向的是用户、机器名，但不面向IP地址、MAC地址等.正如计算机操作系统本身并不实现复杂的各种软件功能,NOX本身并不完成对网络管理任务，而是通过在其上运行的各种“应用"（APPlication）来实现具体的管理任务。2。2。3openflow虚拟化类比计算机的虚拟化，FlowVisor就是位于硬件结构元件和软件之间的网络虚拟层。FlowVisor允许多个控制同时控制一台OPenFlOw交换机，但是每个控制器仅仅可以控制经过这个OPenFlOw交换机的某一个虚拟网络（即SliCe）。因此通过FlowVisor建立的试验平台可以在不影响商业流的转发速度的情况下,允许多个网络试验在不同的虚拟网络上同时进行。FlowVisor与一般的商用交换机是兼容的，而不需要使用FPGA和网络处理器等可编程硬件。2。3安全通道安全通道用来连接交换机和控制器，所有安全通道必须遵守of协议。控制器可以配置、管理交换机、接收交换机的事件信息，并通过交换机发出网包等.2。3。1OF协议of协议支持三种消息类型：Controller-to—switch,asynchronous(异步)和SymmetriC对称)，每一类消息又有多个子消息类型。controller—to-sWitCh消息由控制器发起，用来管理或获取switch状态;asynchronous消息由switch发起,用来将网络事件或交换机状态变化更新到控制器；SymmetriC消息可由交换机或控制器发起。2.3.1。1controller—to—switch消息由控制器(COntrOller)发起，可能需要或不需要来自交换机的应答消息。包括Features、Configuration、Modify-state、Read-state、Send-packet、Barrier等。Features在建立传输层安全会话(TranSPortLayer