软件定义网络：基于OpenFlow的SDN技术揭秘[图书]

2.4.1　Mininet入门 / 33
2.4.2　Mininet实验 / 36
2.5　本章总结 / 41
第3章　OpenFlow控制器 / 43
3.1　SDN控制器 / 44
3.2　已有的实现方案 / 47
3.2.1　NOX和POX / 47
3.2.2　运行一个POX应用 / 49
3.2.3　NodeFlow / 57
3.2.4　Floodlight / 60
3.3　OpenDaylight / 62
3.4　本章总结 / 64
第4章　环境的搭建 / 65
4.1　理解OpenFlow实验 / 66
4.1.1　外部控制器 / 70
4.1.2　完成OpenFlow实验 / 71
4.2　OpenDaylight / 76
4.2.1　ODL控制器 / 77
4.2.2　基于ODL的SDN实验 / 80
4.3　本章总结 / 85
第5章　网络应用开发 / 87
5.1　网络应用1——学习型以太网交换机 / 88
5.2　网络应用2——简单的防火墙 / 97
5.3　网络应用3——OpenDaylight的简单转发 / 101
5.4　本章总结 / 103
第6章　网络分片的获取 / 105
6.1　网络虚拟化 / 106
6.2　FlowVisor / 107
6.2.1　FlowVisor API / 109
6.2.2　FLOW_MATCH结构 / 111
6.2.3　分片操作结构 / 113
6.3　FlowVisor切分 / 113
6.4　本章总结 / 120
第7章　云计算中的OpenFlow / 121
7.1　OpenStack和Neutron / 122
7.2　OpenStack的组网架构 / 126
7.3　Neutron插件 / 130
7.4　本章总结 / 134
第8章　开源资源 / 137
8.1　交换机 / 138
8.1.1　Open vSwitch / 138
8.1.2　Pantou / 141
8.1.3　Indigo / 142
8.1.4　LINC / 143
8.1.5　XORPlus / 143
8.1.6　OF13SoftSwitch / 145
8.2　控制器 / 146
8.2.1　Beacon / 146
8.2.2　Floodlight / 146
8.2.3　Maestro / 148
8.2.4　Trema / 149
8.2.5　FlowER / 150
8.2.6　Ryu / 150
8.3　其他 / 151
8.3.1　FlowVisor / 151
8.3.2　Avior / 153
8.3.3　RouteFlow / 154
8.3.4　OFlops and Cbench / 155
8.3.5　OSCARS / 156
8.3.6　Twister / 157
8.3.7　FortNOX / 157
8.3.8　Nettle / 158
8.3.9　Frenetic / 158
8.3.10　OESS / 158
8.4　本章总结 / 158

.　　窍门和技巧放在这样的图标后。
　　勘误表
　　尽管我们努力确保图书内容的准确性，但是仍难免会有疏忽错误之处，若读者发现书中文字或者代码有误，欢迎不吝赐教，我们将不胜感激，因为这将有助于减少其他读者由于错误造成的困惑，同时帮助我们改进图书后续版本。若发现任何错误，请向我们报告，可以访问网站http://www.packtpub.com/submit-errata，选中该书名称，单击链接errata submission form，然后输入详细错误信息。错误一经核实，你的意见将会被采纳，所提交的勘误信息将上传到我们的网站，或者添加到该书的勘误表中。通过访问链接http://www.packtpub.com/support，就可以查看到该书已有的勘误信息。
　　

.　　1.3SDN的基本构件
　　部署SDN需要的基本构件包括：SDN交换机（如OpenFlow交换机）、SDN控制器、控制器中用于和转发设备通信的接口、通常的南向接口（OpenFlow）和网络应用接口（北向接口）。在SDN中，由于控制逻辑和算法被卸载到了控制器中，交换机一般被表示为能够通过开放接口访问的基础转发硬件。OpenFlow交换机分为两类：纯粹的OpenFlow交换机（只支持OpenFlow操作）和混合的OpenFlow交换机（可启用OpenFlow操作）。
　　纯粹的OpenFlow交换机不具有传统交换机的板级控制特性，完全依赖于控制器作转发决策。混合的OpenFlow交换机除了支持传统的操作和协议之外，还支持OpenFlow操作。目前大多数商用交换机都是混合型的。OpenFlow交换机包括一个流表，流表负责执行数据包的查表和转发，交换机的每个流表保存一组流的纪录，流记录中包括：
　　1. 首部字段或匹配字段、数据包首部中提取的信息、输入端口以及元数据信息，这些信息用于匹配输入的包。
　　2. 计数器，用于对特定的流进行统计，如统计所接收数据包的个数、字节数以及流的持续时间等。
　　3. 一组应用于所匹配的数据包的指令或具体操作，决定如何处理符合匹配条件的数据包。例如，将数据包从指定的端口转发出去。
　　SDN（以及OpenFlow）中分离的系统可以和计算机平台上的应用程序与操作系统类比，在SDN中，控制器（即网络操作系统）提供了网络的可编程接口，通过编写应用程序，可以完成控制和管理任务，实现新的功能。图1-1给出了该模型的分层视图，在该视图中，控制是集中式的，编写应用程序时，可以把网络视为一个单一的系统，这样虽然简化了策略的执行与管理任务，但控制器和网络转发单元之间的绑定关系必须随时保持着。如图1-1所示，担任网络操作系统角色的控制器必须至少实现两个接口：一个南向接口，支持控制器和交换机之间的通信；一个北向接口，为控制器和高层的策略应用及服务提供可编程的API。首部字段（匹配字段）显示在图1-1中，流表中的每条记录包含特定的值或ANY（图1-1中用*即通配符表示），后者表示能够匹配任何值。
　　如果交换机处理IP源地址和目的地址字段时支持子网掩码，则能够更精确地定义匹配。端口字段用数字表示交换机的端口（或输入端口），编号从1开始，该字段的长度取决于具体的实现。输入端口字段适用于所有的数据包。交换机有效端口的源和目的MAC（以太网）地址字段也适用于所有数据包，其长度为48比特。以太网类型字段长度为16比特，适用于所有有效端口上的数据包，OpenFlow交换机必须既能够匹配标准的以太网数据包，也能够匹配带有子网访问协议（Subnetwork Access Protocol，SNAP）首部和0x000000值的机构唯一识别符（Organizationally Unique Identifier，OUI）的IEEE 802.2数据包。特定值0x05FF用于匹配所有不带有SNAP首部的802.3数据包。VLAN ID适用于所有类型为0x8100的以太网数据包。该字段的长度为12比特（即4096个VLAN），VLAN优先级字段长度为3比特，可用于所有类型为0x8100的以太网数据包。IP源和目的地址字段长度为32比特，适用于所有IP和ARP数据包，这些字段可以与子网掩码进行掩码操作。IP报文的协议字段适用于所有IP数据包、以太网帧封装的数据包和ARP数据包。该字段的长度是8比特，如果是ARP数据包，则只使用ARP报文操作码的低8位，IP报文的ToS （Type of Service）字段长度为6比特，适用于所有IP数据包。这个字段的值是8比特，ToS取其中的高6位。源端口和目的传输端口地址（以及ICMP的类型和代码字段）长度为16比特，适用于所有的TCP、UDP和ICMP数据包。若只考虑ICMP的类型和代码，则只需考虑低8位值的匹配。
　　图1-1OpenFlow交换机、流表、OpenFlow控制器和网络应用
　　每个表、每个流、每个端口和每个队列都维持一个计数器。计数器循环计数，因此不设进位溢出位，图1-2给出了所需的计数器集合，图中以及本书中提到的字节都是指8比特的组合，持续时间表示某个流在交换机的流表中存在的时间。接收错误字段包括所有显式定义的错误：帧错误、超限、CRC错误以及其他错误。
　　图1-2用于信息统计的计数器列表
　　每个流记录都跟0个或者多个具体操作相关联，这些操作指示OpenFlow交换机如何处理与流记录匹配的数据包。如果没有具体的转发操作，该数据包就被丢弃。具体操作列表必须按照一定的顺序执行，然而，这并不确保一个端口上数据包的输出顺序。例如，两个经操作列表处理后所产生的到达同一个输出端口的数据包，很可能会以任意的顺序输出。纯粹的OpenFlow交换机只支持规定的（required）操作，而混合的OpenFlow交换机则可以同时支持常规（NORMAL）操作。两种交换机都能支持FLOOD操作。规定操作是：
　　转发：OpenFlow交换机必须能够将数据包转发到物理端口，同时支持向下列虚拟端口的转发：
　　ALL：将数据包发送到除了其输入端口以外的所有接口。
　　CONTROLLER：封装数据包并将其发送到控制器。
　　LOCAL：将数据包发送到交换机的本地网络栈。
　　TABLE（仅用于输出数据包的消息）：执行流表中的操作。
　　IN_PORT：从输入端口输出数据包。
　　丢弃：表明丢弃所有相匹配的数据包。若流记录中没有定义具体操作，则作丢弃处理。
　　可选的操作包括：
　　转发：交换机在进行转发操作时，可以选择支持以下的虚拟端口：
　　NORMAL：采用交换机所支持的常规转发途径转发数据包（即常规的第2层、VLAN，或者第3层处理）。
　　FLOOD：沿最小支撑树以洪泛的方式向除输入接口以外的端口转发数据包。
　　进入队列（Enqueue）：通过端口的队列转发数据包，转发行为由所配置的队列策略决定，通常被用来提供基本的QoS支持。
　　修改字段（Modify field）：可选的字段修改操作有：
　　设置VLAN ID：若没有定义VLAN，则增加一个新的首部，在其中定义VLAN ID（12比特的数据），并把优先级设为0；若原来已存在VLAN首部，则用新的定义值取代原来的VLAN ID。
　　设置VLAN优先级：若没有定义VLAN，则增加一个新的首部，在其中定义优先级（3比特的取值），并把VLAN ID设为0；若原来已存在VLAN首部，则用新的定义值取代原来的优先级字段值。
　　剥离VLAN首部：若存在VLAN首部，则将其剥离。
　　修改源或目的以太网MAC地址：用新的取值（48比特）替换原来的源或目的以太网MAC地址。
　　修改源或目的IPv4地址：用新的取值（32比特的数据）替换原来的源或目的IPv4地址，并更新IP报文的校验和（同样适用于TCP/UDP的校验和）。该操作只针对IPv4数据包。
　　修改IP报文的服务类型（ToS）字段值：用新的取值（6比特的数据）替换原来的ToS字段值，该操作只针对IPv4数据包。
　　修改传输层的源或目的端口号：用新的取值（16比特的数据）替换原来的源或目的端口号，并更新TCP或UDP的校验和。该操作只针对TCP或UDP数据包。
　　每当有一个数据包到达OpenFlow交换机时，数据包的首部便被提取出来，跟流记录中的匹配字段进行比对，查找匹配从流表的第一个记录开始，依次往下进行，当发现一个相匹配的记录，交换机将使用该流记录所关联的一系列操作对数据包进行处理。每当发现一个和流记录匹配的数据包，就会更新这个流记录所对应的计数器值。如果查表结果没有发现匹配记录，交换机将根据流表的失配（table-missing）记录中的指令决定采取相应操作。流表中必须包含一个失配记录，以便应对找不到匹配的情况，在这个特殊的记录中定义一组操作，用于处理找不到匹配的输入数据包，这些操作包括：丢弃该数据包、向所有的接口发送该数据包，或者通过安全的OpenFlow信道向控制器转发该数据包。查表时使用的首部字段取决于数据包的类型，具体描述如下：
　　将流的有关输入端口的规定与接收数据包的物理端口进行比对。
　　所有数据包的以太网帧首部（如图1-1中所定义的源MAC地址、目的MAC地址、以太网的类型字段等）都用于查表匹配。
　　如果是一个VLAN数据包（以太网类型字段值为0x8100），其VLAN ID和VLAN优先级（PCP）字段用于查表匹配。
　　如果是IP数据包（以太网类型字段值为0x0800），IP首部包含的字段（源IP地址、目的IP地址、协议字段、ToS等）均用于查表匹配。
　　如果IP数据包封装的是TCP或UDP（IP报文首部的协议字段值为6或17），则查表比对的信息包括传输层端口号（TCP/UDP源或目的端口）。
　　如果IP数据包封装的是ICMP报文（IP报文首部的协议字段值为1），则查表时会包括ICMP的类型和代码字段。
　　如果数据包的IP报文分片的偏移量字段是非零值，或者不是最后一个分片（more fragment 标志位为1），查表时把传输层端口号设为0。
　　对于ARP数据包（以太网类型字段值等于0x0806），可以根据情况，选择把其中的源IP和目的IP地址字段值包括到查表的字段中。
　　数据包跟流表记录的匹配按照优先级进行，精确定义了匹配规则（即没有使用通配符）的流记录总是具有最高的优先级，全部采用通配符的流记录具有与其相关联的优先级，具有高优先级的流记录总是先于具有低优先级的流记录进行匹配。如果多个流记录具有相同的优先级，则交换机可以选取任意的匹配顺序。编号越大，优先级越高。图1-3表示OpenFlow交换机中的数据包处理流程。需要注意的很重要的一点是：如果一个流表的字段值是ANY（*，通配符），则它就能够匹配首部中的任何可能取值。
　　以太网的帧有各种类型（如Ethernet II、带有或者不带有SNAP的802.3帧等），如果数据包是Ethernet II格式的帧，则以太帧的类型字段按照预期的方法处理；如果数据包是802.3格式的帧，带有SNAP首部，OUI的值等于0x000000，则用SNAP协议ID来比对流的以太网帧类型字段。如果一个流记录中规定以太帧类型为0x05FF，那它就能够匹配所有不带SNAP首部的802.2以太网帧，以及虽然带有SNAP首部，但是OUI取值不等于0x000000的以太网帧。
　　
　　图1-3OpenFlow交换机中的数据包处理流程
　　1.4OpenFlow消息
　　控制器和交换机之间的通信采用OpenFlow协议，通过安全信道在实体之间传递一组预定义的消息，安全信道是将每个交换机连接到控制器的接口。交换机开机启动后，便会向用户定义的控制器（或者固定的控制器）发起传输层安全（Transport Layer Security，TLS）连接，控制器的默认TCP端口是6633。交换机和控制器相互交换证书进行认证，证书用特定站点的私钥签名，用户必须能够对每个交换机进行配置，用其中的一个证书对控制器进行认证（控制器证书），用另一个证书向控制器提供交换机认证（交换机证书）。
　　通过安全信道传输的双向流量不用跟流表进行比对，所以，交换机在进行查表比对之前，必须把输入的流量视为本地流量。当发生交换机和控制器联系中断的情况时，通常是由echo请求超时、TLS会话超时，或者其他连接中断引起，交换机需要尝试去连接一个或者多个后备控制器。如果若干次（0次或多次）连接控制器的尝试失败，交换机必须进入紧急模式，并重置当前的TCP连接。这时，匹配过程由紧急流表记录（其emergency标志位值为1）来控制，紧急流修改消息必须将超时值设为0，否则交换机就必须拒绝更多的流并且以错误信息响应。进入紧急模式后，所有的正常记录都会被删除。与控制器重新建立连接后，紧急流记录依然保留，控制器可以根据需要选择是否将所有流记录删除。
　　交换机第一次引导启动时，可以认为是处于紧急模式。对于如何配置默认流记录的问题，OpenFlow协议中没有进行规定。
　　控制器通过安全信道这个接口对交换机进行配置和管理，接收来自交换机的事件报告，并向交换机发送数据包。利用OpenFlow协议，远程控制器能够添加、更新、删除交换机流表中的记录。这些操作既可以被动发生（用以对某个所接收的数据包做出响应），也可以主动发生。可以把OpenFlow协议视为控制器和交换机之间交互的一种可能的实现方案（南向接口），因为它定义了交换硬件和网络控制器之间的通信。出于安全的考虑，OpenFlow 1.3.x提供了可选的对加密TLS通信的支持，以及交换机和控制器之间的证书交换机制，不过目前尚未给出具体的实现方案，也没有对证书格式做出规定。此外，对于如何只给一个授权控制器赋予有限的访问许可，当前规范中也没有给出具体的方法，因此，有关多控制器应用场景的更细粒度的安全选项也未在当前规范中涉及。
　　OpenFlow协议定义了以下三种消息类型，每种又可分为若干种子类型。
　　控制器到交换机的消息。
　　对称的消息。
　　异步的消息。
　　1.4.1控制器到交换机的消息
　　控制器到交换机的消息由控制器发起，用于直接管理交换机或查看交换机的状态。这类消息既可以要求交换机响应，也可以不要求响应。这类消息可以细分为如下的子类型。
　　Features消息
　　TLS会话一经建立，控制器便向交换机发送feature请求消息，交换机必须用feature应答消息进行回复，并在其中详细说明交换机所支持的特性和功能。
　　Configuration消息
　　控制器可以设置和查询交换机中的配置参数，而交换机只对控制器所发出的查询消息做出响应。
　　Modify-State消息
　　这类消息由控制器发出，用于管理交换机的状态，通过这类消息添加、删除或者修改流表中的流记录，或者设置交换机端口的优先级。流表修改消息可以采用以下的类型：
　　ADD：对于设置了OFPFF_CHECK_OVERLAP标志的ADD请求，交换机必须首先检查有没有重叠（overlapping）的流记录。如果一个数据包同时与两个流记录匹配，且两者具有相同的优先级，则这两个流记录就是重叠的。如果ADD请求与现有的流记录之间存在重叠冲突，交换机必须拒绝这个添加操作请求，并用ofp_error_msg作为响应，设置其错误类型为OFPET _FLOW_MODE_FAILED，错误代码为OFPFMFC_OVERLAP。对于有效的ADD请求（没有重叠），或者没有设置重叠检查标志位的ADD请求，交换机必须将流记录插入到流表中最低编号的记录处，对于该记录，交换机支持其flow_match结构中的所有通配符集合，并在查找匹配的过程中查看其优先级，如果流表中已经存在了一个具有相同的首部字段和优先级的流记录，则必须将这个流记录连同其计数器删除，再把新的记录加进来。如果交换机在表中找不到添加所输入流记录的位置，则需要发送ofp_error_msg，设置其错误类型为OFPET _FLOW_MODE_FAILED，错误代码为OFPFMFC _ALL_TABLES_FULL。如果在流修改消息的操作列表中引用了一个交换机的无效端口，则交换机必须返回ofp_error_msg响应，设置错误类型为OFPET _BAD_ACTION，错误代码为OFPBAC_BAD_OUT。如果所引用的端口以后有可能会生效（例如，在交换机的某个插槽中插入了一块线路接口卡），则交换机可以选择简单地丢弃发送到这个端口的数据包，不产生错误信息；或者返回一个OFPBAC_BAD_PORT错误，并拒绝这个流修改消息。
　　MODIFY：如果当前流表中不存在具有相同首部字段的流记录，则MODIFY命令的功能就和ADD命令一样，新的流记录插入时其计数器值必须设置为0。如果当前流表中存在相同的首部字段的流记录，就修改现有流记录中的操作字段值，而计数器值和空闲超时字段的值保持不变。
　　DELETE：对于删除请求，若表中没有匹配的流记录，则不产生任何错误信息，流表也不发生任何改动。如果有匹配的流记录，则必须删除该记录，设置了OFPFF_SEND_FLOW_REM标志的普通流记录将产生一条流清除（removal）消息。删除紧急流记录不会产生流清除消息。输出端口可以选择过滤DELETE和DELETE_STRICT命令。如果out_port字段包含的值不是OFPP_NONE，则查找匹配时引入一个约束条件，这个约束条件就是：规则中必须包含一个导向这个端口的输出操作。而ADD、MODIFY和MODIFY_SRTICT消息则会忽略这个字段。
　　MODIFY和DELETE：这两个流模式命令都有相应的_STRICT版本，在非_STRICT版本中，通配符是起作用的，所有跟描述符相匹配的流都会被修改或删除。而在_STRICT版本的命令中，包括通配符和优先级在内的所有字段必须跟流记录严格匹配，只有完全相同的流才会被修改或删除。譬如，如果给交换机发送了一条删除记录的消息，在其中设置了所有的通配符标志，则DELETE命令将会从所有的流表中删除所有的流记录；而DELETE_STRICT命令则只删除适用于指定优先级上所有数据包的那条规则。对于非_STRICT的包含通配符的MODIFY和 DELETE命令，只有当与流记录精确匹配，或者比flow_mod更精确时，才被作为一个匹配看待。例如，如果一条DELETE命令要求删除所有目的端口为80的流，那么，一条包含了所有通配符的流记录将不会被删除；然而，一条包含了所有通配符的DELETE命令，将会删除一条匹配所有80端口流量的流记录。
　　Read-State消息
　　这类消息从交换机的流表、端口和单条流记录中收集统计数据。
　　Send-Packet消息
　　控制器利用这类消息从交换机的指定端口发送数据包。
　　Barrier消息
　　控制器使用Barrier请求和应答消息来确保消息的相互依存性或者接收操作完成的通知。
　　1.4.2对称消息
　　对称消息既可以由交换机主动发送，也可以由控制器主动发送，根据OpenFlow协议的定义，对称消息有以下三种类型。
　　Hello消息
　　交换机和控制器建立连接之后，交换Hello消息。
　　echo消息
　　echo请求消息既可以由交换机发出，也可以由控制器发出，另一方必须反馈echo应答消息。echo消息用于传送延时和带宽信息，以及控制器与交换机之间连接的保活（即心跳）信息。
　　Vendor消息
　　Vendor类消息旨在利用OpenFlow消息类型空间，为OpenFlow交换机的功能扩展提供一种标准化的途径，便于将来OpenFlow协议的修订更新。
　　1.4.3异步消息
　　异步消息由交换机发起，用来向控制器通告网络事件和交换机状态的变化。交换机发送异步消息以告知数据包的到达、交换机状态的改变，或者出现了错误。异步消息主要分为以下四种。
　　packet-in消息
　　对于所有没有找到相匹配的流记录的数据包，或者匹配记录所规定的操作是“发送到控制器”，交换机都会向控制器发送一个packet-in消息。如果交换机有充足的缓存空间来存储要发给控制器的数据包，packet-in消息中会包含部分数据包首部（默认为128字节）和缓存区的ID，当交换机做好准备转发该数据包时，这些信息就可以供控制器使用。如果交换机不支持内部缓存，或者内部缓存区空间耗尽了，就必须把包含全部数据包的packet-in消息发送给控制器。
　　flow-removal消息
　　当通过流修改消息向交换机添加一条流记录时（见1.4.1节），空闲超时计数器的值可以反映出何时可以把不活跃的流记录清除，也可以根据硬超时值决定何时清除一条流记录，硬超时值则与流记录的活跃与否无关。当一个流过期时，流修改消息还能够规定交换机是否应该向控制器发送一条流清除消息。用来进行删除（delete）操作的流修改（modify）消息，也会产生流清除（flow removal）消息。
　　port-status消息
　　当交换机的端口配置状态改变时，应该向控制器发送端口状态（port-status）消息，这些事件包括端口状态的改变（例如端口被用户禁用），或者根据802.1D（支撑树）所定义的端口状态改变。OpenFlow可以把支撑树协议（Spanning Tree Protocol，STP）作为可选项来支持，这些交换机在进行查表操作之前，应该先在本地处理所有的802.1D数据包，由STP定义的端口状态则被用来对数据包的转发进行约束，只能转发给那些沿着支撑树分布的端口，限制其到OFP_FLOOD端口的转发。由支撑树协议所带来的端口变化将通过端口更新消息发送给控制器。需要注意的是，规定向输出端口OFP_ALL的转发操作将忽略STP设置的端口状态，从STP所禁止的端口上接收的数据包必须按照正常的流表处理途径转发。
　　error消息
　　交换机用error消息来向控制器通报错误。
　　OpenFlow规范的核心是一组供OpenFlow协议使用的C语言结构体，对此感兴趣的读者可以通过下面的链接找到这些数据结构及其详细解释：
　　www.openflow.org/documents/openflow-spec-v1.0.0.pdf或者www.opennetworking.org/sdn-resources/onf-specifications。
　　1.5北向接口
　　外部的管理系统或者网络应用（Net App）有时需要提取下层网络的信息，或者希望对网络的行为及策略进行某种控制。此外，出于各种目的，控制器之间也可能需要彼此通信。譬如，一个内部控制应用程序可能需要跨不同的控制域进行资源预留；或者一个主控制器需要和后备控制器共享策略信息。与提供控制器和交换机之间通信的南向接口不同，目前尚不存在被广泛接受的北向接口标准，不同的应用系统大都采用自己的一套。其深层原因之一就是北向接口是完全在软件中定义的，而控制器和交换机之间的通信交互则离不开硬件实现方案。如果我们把控制器视为网络操作系统，那么就必须有一个明确定义的接口，使得应用程序能够通过它访问底层硬件（交换机）、与其他共存的应用程序进行交互、使用系统提供的服务（如拓扑发现、转发等），而不必要求应用开发人员了解控制器（即网络操作系统）的实现细节。由于存在多种控制器，其应用接口的开发尚处于早期阶段，它们相互独立，彼此互不兼容。在明确定义的北向接口标准问世之前，SDN应用开发将会继续处于各自为战的局面，实现灵活的、可移植的网络应用的理念还有待时日。
　　1.6本章总结
　　在OpenFlow问世之前，已有很多人致力于将网络设备的控制与数据转发分离，而OpenFlow就是这一努力的延续。本章针对这方面的背景作了介绍，描述了部署SDN的关键构件，重点介绍了OpenFlow协议及其基本操作，了解了OpenFlow之后，我们将在下一章展示一个OpenFlow交换机的软硬件参考实现方案，同时介绍Mininet的实验环境。