原文地址
http://www.ibm.com/developerworks/cn/cloud/library/1303_silei_openflow/
OpenFlow 是 Software Definded Network 的一种，由斯坦福大学的 Nick McKeown 教授在 2008 年 4 月 ACM Communications Review 上发表的一篇论文 OpenFlow: enabling innovation in campus networks 里首先提出来的。它最初的出发点是用于网络研究人员实验其创新网络架构、协议，考虑到实际的网络创新思想需要在实际网络上才能更好地验证，而研究人员又无法修改在网的网络设备，故而提出了 OpenFlow 的控制转发分离架构，将控制逻辑从网络设备盒子中引出来，研究者可以通过一组定义明确的接口对网络设备进行任意的编程从而实现新型的网络协议、拓扑架构而无需改动网络设备本身。
图 1. 基于 OpenFlow 的网络交换设备
网络交换设备，无论是交换机还是路由器，其核心信息都保存在 Flow Table 里面，这些 Flow Table 被用来实现诸如转发、防火墙、Qos、统计分析等各种功能。不同生产厂家的 Flow Table 有着不同的格式，OpenFlow 定义了一套对这些 Flow Table 进行操作的可扩展的通用标准。如图 1 所示，一个 OpenFlow 的交换设备至少由下面三个部分组成：
- Flow Table：Flow Table 里面的每个条目都会与一个动作相关联，来告诉网络交换设备来如何处理与这个条目相关联的 data Flow；
- Secure Channel：用于连接网络交换设备和远程网络控制器，在控制器和网络交换设备之间互相发送命令和数据包；
- OpenFlow Protocol：提供一个开放标准统一的接口，使得控制器和网络交换设备之间可以相互通信。
这样通过 OpenFlow 协议，网络交换设备以外的控制器就可以对网络交换设备的 Flow Table 进行编程和管理。Flow Table 对远程访问控制的支持，将 Flow Table 的配置与管理从网络交换设备本身中剥离出来，也使得对整个网络中 Flow Table 进行集中控制与管理成为可能，从而将物理网络和逻辑网络的定义有效分离，如图 2 所示。而出于性能角度考虑和为了解决单点失效问题，OpenFlow 协议还允许多个控制器同时对同一个 OpenFlow 交换设备进行配置与管理。
图 2. 对整个网络的 Flow Table 进行集中控制
多个控制器通过修改 Flow Table 定义不同的规则，对于不同的 Flow 采取不同的操作，将物理网络有效地分割成互相独立的逻辑网络，从而实现网络的虚拟化。如图 3 所示，在同一个物理网络中， Controller A 定义 Flow Table1 用于租户 A 的网络应用，Controller B 定义 Flow Table2 用于租户 B 的网络应用，Controller C 定义 Flow Table3 用于租户 C 的网络应用 , 而红线所标明的部分代表交换设备对网络流量现有的正常处理。
图 3. 物理网络被分割成不同的逻辑网络
要弄清楚什么是 Flow Table, 得先明白什么是 Flow, 某种特定的网络流量都可以认为是一个 Flow, 譬如从某个特定的 Mac 地址或 IP 地址发出的 TCP 连接可以认为是一个 Flow, 譬如所有的 UDP 数据包，或者像 Tunnels、VLANs 都可以认为是一个 Flow。通过将网络流量根据 Flow Table 划分为不同的数据流，这些数据流能被归于不同的组且相互隔离，从而能够分别按照需要来处理和控制。
Flow Table 中的每个条目由匹配字段、计数器和指令集组成（表 1）：
- 匹配字段：报文匹配的输入关键字；
- 计数器：用于对匹配报文的流量统计；
- 指令：当有报文匹配时，指令会修改匹配报文的 Action 集合，或者修改 Pipeline 的处理流程，来决定报文如何转发；
表 1. Flow Table 中的条目
| 匹配字段 | 计数器 | 指令 |
|---|
OpenFlow Pipeline 定义了报文的匹配过程。每个 Pipeline 都包含 1 个或多个 Flow Table，匹配从 Pipeline 中的第一个 Flow Table 开始，然后按照 Pipeline 中 Flow Table 的序列依次进行，如图 4 所示。如果一个报文在当前 Flow Table 中找到匹配的条目，那么这个条目对应的指令集将会被执行。指令集会修改匹配报文的 Action 集合，或者将报文的匹配过程跳转到 Pipeline 中后续某个指定的 Flow Table 中。当匹配条目的指令不再进行跳转时，报文的匹配过程结束，这时候报文的 Action 集合里面的所有 Action 将会执行。而 Action 操作通常会转发报文到某个指定的端口，或者封装改写报文，以及丢弃报文等。如图 5 所示。如果报文在当前的 Flow table 中没有找到匹配条目，称之为一个 table miss，对于 table miss 的处理取决于 flow table 的配置。默认情况下会将报文发送回控制器处理或者丢弃报文，但是 flow table 也可指定将报文发送到 pipeline 中下一个 flow table 继续处理。
图 4. OpenFlow Pipeline 处理过程
图 5. OpenFlow Pipeline 匹配过程
Pipleline 匹配的过程中还有可能跳转到 Group Table。Group Table 的条目包括：
表 2. Group Table 中的条目
| Group 标识 | Group 类型 | 计数器 | Action Buckets |
|---|
- Group 标识：一个 32 位无符号整数来唯一标示这个 Group
- Group 类型：group 类型有四种‘ all ’、“select”、“indirect”、“fast failover”。将一些 flow 指向 group table 是为了处理报文转发中的一些高级功能，譬如‘ all ’是为了处理多播或者广播。
- 计数器：对被这个 group 处理过的匹配报文进行流量统计；
- Action Buckets：一组有序的 Action 以及它们的参数。
图 6. OpenFlow Pipeline 中 Group Table 的处理过程
我们来看看几个利用 Flow table 的例子。表 3 是一个 Flow Table，其中“*”代表通配符，”Action”代表报文匹配后的 Action 集合。它对某些目标网段的 Flow，定义了一些路由规则：对于目标网段是 192.168.1.0/254 的报文，转发到端口 1；对于目标网段是 192.168.2.0/254 的报文，转发到端口 2；默认路由则转发到端口 3。表 4 则定义了一些防火墙规则：丢弃所有源地址是 192.168.2.2 目标地址是 192.168.3.5 目标端口是 80 的报文；将所有源地址是 192.168.3.4 目标地址是 192.168.5.4 目标端口是 80 的报文转发至端口 3；其它报文则默认转发至控制器。
表 3.Flow Table 定义路由
| MAC SRC | MAC DST | SRC IP | DST IP | TCP DPort | TCP SPort | Action | Count |
|---|---|---|---|---|---|---|---|
| * | * | * | 192.168.1.0/254 | * | * | Port1 | 249 |
| * | * | * | 192.168.2.0/254 | * | * | Port2 | 229 |
| * | * | * | * | * | * | Port3 | 898 |
表 4.Flow Table 定义防火墙规则
| MAC SRC | MAC DST | SRC IP | DST IP | TCP DPort | TCP SPort | Action | Count |
|---|---|---|---|---|---|---|---|
| * | * | 192.168.2.2 | 192.168.3.5 | 80 | * | Drop | 250 |
| * | * | 192.168.3.4 | 192.168.5.4 | 80 | * | Port3 | 300 |
| * | * | * | * | * | * | Controller | 9 |
控制器通过 Open Flow 协议来对 Flow table 进行编程。Open Flow 协议支持三种类型的消息。
- Controller-to-switch：它是由控制器主动发起发送给交换设备，来管理和查询交换设备状态的消息。
- Asynchronous：它是当一些网络事件发生时或者交换设备状态发生改变时，由交换设备主动发起来通知控制器，概念上有点像 SNMP 事件里的陷阱事件。
- Symmetric：还有一种对称消息，控制器和网络交换设备都可主动发送给对方，如 Hello 消息、Echo 消息等。
目前，作为专门负责 OpenFlow 标准和规范的维护及发展的开放网络基金会（Open Networking Foundation）已经拥有包括包括 Google、Facebook、Yahoo 等 6 位理事会成员和包括 IBM、HP、Cisco、Juniper 、NEC 以及国内的华为和中兴等主流网络设备制造商近 50 位成员。除了主流网络设备制造商的支持，Google 和 Facebook 也纷纷宣布在其数据中心中成功应用了 OpenFlow/SDN 的技术。IBM 始终是 Openflow 标准制定的支持者和积极推动者。2011 年在拉斯维加斯的 Interop 峰会上，IBM 联合 NEC 一起发布了基于 OpenFlow 的解决方案，这款新型 OpenFlow 交换机 - IBM 1.28 Tbps RackSwitch G8264，它具有 48 个 SFP/SFP+ 10 GbE 端口和 4 个 QSFP 40 GbE 端口，且可以划分为另外 16 个 10 GbE 端口，支持 OpenFlow 1.0.0，及最多 97,000 个流实体，支持 NEC 的 pFlow 控制器。如图 7 所示。
图 7. IBM 1.28 Tbps RackSwitch G8264
云计算时代，计算资源的虚拟化和资源调配的自动化，为用户提供了动态的计算、存储和网络资源，以及快速的业务部署。随着云计算的到来，作为互联互通的网络基础设施，如何实现网络的虚拟化，从而支持 IT 工作负载的快速变化和物理基础设施的调配，为工作负载提供端到端的网络资源响应 , 成为迫在眉睫需要解决的问题。网络虚拟化的本质是要实现底层物理网络的抽象，能够在逻辑上对网络资源进行分片或者整合，从而满足各种应用对于网络的不同需求，而 OpenFlow 的出现使得这一切成为可能。基于 OpenFlow 的 SDN，可实现控制平面和转发平面分离，极大提升网络交换速度，满足云计算高速数据交换和传输的要求。尽管从工业应用角度看，OpenFlow 尚且还不够成熟，但是我们很高兴的看到它已经越来越成为一种趋势。
学习
- 查看文章“OpenFlow: Enabling Innovation in Campus Networks”，了解 OpenFlow 如何最早被提出。
- 查看文章“openflow-spec-v1.1.0”，了解 OpenFlow 规范 1.1.0。
- 参考 OpenFlow 首页，了解有关 OpenFlow 的最新消息。
- 查看文章“OpenFlow: The Next Generation in Networking Interoperability”，了解有关 IBM 1.28 Tbps RackSwitch G8264。
- developerWorks 云计算站点 提供了有关云计算的更新资源，包括
- 云计算 简介。
- 更新的 技术文章和教程，以及网络广播，让您的开发变得轻松，专家研讨会和录制会议 帮助您成为高效的云开发人员。
- 连接转为云计算设计的 IBM 产品下载和信息。
- 关于 社区最新话题 的活动聚合。
讨论
- 加入 developerWorks 中文社区。查看开发人员推动的博客、论坛、组和维基，并与其他 developerWorks 用户交流。
866
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
