OpenFlow技术白皮书-V1.0

---

1.  概述

OpenFlow是由斯坦福大学的Nick McKeown教授在2008年4月ACM Communications Review上发表的一篇论文OpenFlow: enabling innovation in campus networks首先详细论述了OpenFlow的原理。由该论文课题可知OpenFlow提出的最初出发点是用于校园内网络研究人员实验其创新网络架构、协议，考虑到实际的网络创新思想需要在实际网络上才能更好地验证，而研究人员又无法修改在网的网络设备，故而提出了OpenFlow的控制转发分离架构，将控制逻辑从网络设备盒子中引出来，研究者可以对其进行任意的编程从而实现新型的网络协议、拓扑架构而无需改动网络设备本身。该想法首先在美国的GENI研究项目中得到应用，实现了一个从主机到网络的端到端创新实验平台。OpenFlow的架构见下图：

图1 OpenFlow概念架构

OpenFlow的思路很简单，网络设备（OpenFlow交换机）维护一个FlowTable并且只按照FlowTable进行转发，Flowtable本身的生成、维护、下发完全由外置的Controller来实现，注意这里的FlowTable并非是指IP五元组，事实上OpenFlow 1.0定义了包括端口号、VLAN、L2/L3/L4信息的12个关键字，但是每个字段都是可以通配的，网络的运营商可以决定使用何种粒度的流，比如运营商只需要根据目的IP进行路由，那么流表中就可以只有目的IP字段是有效的，其它全为通配。

这种控制和转发分离的架构对于L2交换设备而言，意味着MAC地址的学习由Controller来实现，V-LAN和基本的L3路由配置也由Controller下发给交换机。对于L3设备，各类IGP/EGP路由运行在Controller之上，Controller根据需要下发给相应的路由器。流表的下发可以是主动的，也可以是被动的，主动模式下，Controller将自己收集的流表信息主动下发给网络设备，随后网络设备可以直接根据流表进行转发；被动模式是指网络设备收到一个报文没有匹配的FlowTable记录时，将该报文转发给Controller，由后者进行决策该如何转发，并下发相应的流表。被动模式的好处是网络设备无需维护全部的流表，只有当实际的流量产生时才向Controller获取流表记录并存储，当老化定时器超时后可以删除相应的流表，故可以大大节省TCAM空间。

2.  缩写和术语

GRE (Generic Routing Encapsulation):通用路由封装

L2overgre(layer 2 Generic Routing Encapsulation):二层报文路由封装

OpenFlow控制端：OpenFlow实现了数据层和控制层的分离，其中OpenFlow交换机进行数据层的转发，而Controller实现了控制层的功能。Controller通过OpenFlow协议这个标准接口对OpenFlow交换机中的流表进行控制，从而实现对整个网络进行集中控制。

OpenFlow交换机：OpenFlow交换机是整个OpenFlow网络的核心部件，主要管理数据层的转发。OpenFlow交换机接收到数据包后，首先在本地的流表上查找转发目标端口，如果没有匹配，则把数据包转发给Controller，由控制层决定转发端口。

OpenFlow协议：OpenFlow协议用来描述控制器和交换机之间交互所用信息的标准，以及控制器和交换机的接口标准。

Diffserve（Differentiated Service）：差分服务。

3.  技术介绍

3.1  OpenFlow交换机架构

OpenFlow交换机是整个OpenFlow网络的核心部件，主要管理数据层的转发。OpenFlow交换机接收到数据包后，首先在本地的流表上查找转发目标端口，如果没有匹配，则把数据包转发给Controller，由控制层决定转发端口。

OpenFlow交换机由流表、安全通道和OpenFlow协议三部分组成。

图2 OpenFlow交换机的构成和分类

流表由很多个流表项组成，每个流表项就是一个转发规则。进入交换机的数据包通过查询流表来获得转发的目的端口。流表项由头域、计数器和操作组成；其中头域是个十二元组，是流表项的标识；计数器用来计数流表项的统计数据；操作标明了与该流表项匹配的数据包应该执行的操作。

OpenFlow协议用来描述控制器和交换机之间交互所用信息的标准，以及控制器和交换机的接口标准。协议的核心部分是用于OpenFlow协议信息结构的集合。OpenFlow协议支持三种信息类型：Controller-to-Switch，Asynchronous和Symmetric，每一个类型都有多个子类型。Controller-to-Switch信息由控制器发起并且直接用于检测交换机的状态。Asynchronous信息由交换机发起并通常用于更新控制器的网络事件和改变交换机的状态。Symmetric信息可以在没有请求的情况下由控制器或交换机发起。

按照对OpenFlow的支持程度，OpenFlow交换机可以分为两类：专用的OpenFlow交换机和支持OpenFlow的交换机。专用的OpenFlow交换机是专门为支持OpenFlow而设计的。它不支持现有的商用交换。机上的正常处理流程，所有经过该交换机的数据都按照OpenFlow的模式进行转发。专用的OpenFlow交换机中不再具有控制逻辑，因此专用的OpenFlow交换机是用来在端口间转发数据包的一个简单的路径部件。支持OpenFlow的交换机是在商业交换机的基础上添加流表、安全通道和OpenFlow协议来获得了OpenFlow特性的交换机。其既具有常用的商业交换机的转发模块，又具有OpenFlow的转发逻辑，因此支持OpenFlow的交换机可以采用两种不同的方式处理接收到的数据包。

3.2  OpenFlow连接维护

支持照协议规范定义的HELLO、ECHO_REQUEST、ECHO_REPLY消息, 维护交换机与OpenFlow控制端之间的连接。

3.3  OpenFlow控制vlan

（1）由于DCN目前实现支持OpenFlow的交换机，所以提供命令配置OpenFlow控制的VLAN，这样OpenFlow下发的规则等只会在OpenFlow控制的VLAN内生效，不会影响其他VLAN的流量。

（2）与OpenFlow控制器连接的交换机端口不包含在启用OpenFlow的VLAN中，由用户自行控制。

3.4  规则处理

受交换机硬件芯片的限制，交换机不能通过硬件实现OpenFlow协议定义的所有action，为此引入了多业务卡，通过软件实现硬件不能支持的这部分action。当OpenFlow控制端下发一个规则的时候，交换机上的OpenFlow任务把规则下发到主控卡和多业务卡两个地方，其中多业务卡由于支持所有的action，所以上面下发了所有规则；主控卡由于只支持部分action，所以可以成功下发部分规则，其他规则下发到主控硬件上时都把动作改为转发到多业务卡，由多业务卡对匹配规则的报文进行处理。

3.4.1  规则匹配字段

（1） 支持二层字段的匹配, 包括入端口、源MAC、目的MAC、以太网协议类型、VLAN_ID、VLAN PRIORITY六个基本字段和源MAC掩码、目的MAC掩码两个扩展字段,共8个字段。

（2） 支持三层字段的匹配, 包括源IP地址、目的IP地址、源端口、目的端口、传输层协议号、TOS六个基本字段和源IP地址掩码、目的IP地址掩码两个扩展字段, 共8个字段。

3.4.2  规则动作

（1） 支持向指定端口发包动作。

（2） 支持向启用OpenFlow的VLAN所有端口发包, 协议中定义为ALL和FLOOD动作。

（3）支持向OpenFlow控制器发包，如果报文原来没有Vlan Tag，则发给控制器的包也不带Vlan Tag， 协议中定义为CONTROLLER动作。

（4）支持向入端口发包， 协议中定义为IN_PORT动作。

（5）支持丢弃报文的动作。协议中定义为DROP动作。

（6）支持数据包入队列动作。 协议中定义为QUEUE动作。

（7）支持修改报文字段动作。.

3.4.3  规则维护

（1）OpenFlow规则的增加, 支持OFPFF_CHECK_OVERLAP标志，在加入规则时检查是否存在冲突。如果增加操作不设置OFPFF_CHECK_OVERLAP标志，规则匹配后的行为由OpenFlow控制器负责。

（2）支持规则的删除,　包括带_STRICT后缀及不带后缀两个类型.

3.4.4  规则老化

（1）提供规则的定期老化, 用户可以通过设置hard-timeout时间, 让规则在hard-timeout时间到的时候老化删除.

（2） 提供规则的不活跃老化, 用户可以通过设置idle-timeout时间, 如果规则在idle-timeout时间内没有匹配报文, 则老化删除.

3.5  报文转发

主控收到一个报文，首先进行规则匹配，如果匹配上规则，并且actions是主控支持的，则在主控进行处理，否则，主控上虽然有规则，但是action是送往多业务卡处理，则把报文转发到多业务卡上，报文到多业务卡上重新进行规则匹配，找到对应的处理action，进行处理。如果报文在主控上没有找到匹配的规则，则把报文送往OpenFlow控制端，由控制端决定报文的处理行为。

3.6  二层GRE隧道（l2overgre）

用户可以通过配置和规则下发，实现对二层报文的GRE隧道功能，包括对二层报文的l2overgre封装和l2overgre报文的解封装。这里注意隧道配置的源IP地址必须是交换机上一个有效的IP地址，并且该地址所在的VLAN必须是OpenFlow未控制的VLAN。

用户配置完隧道后，交换机根据源IP、目的IP生成L2overGRE隧道虚端口，并为该虚端口生成对应的index，name（由l2GreTunnel + index组成），创建并注册成功后，把端口以HybridTag的方式加入VLAN ID指定的VLAN，该vlan应与OpenFlow控制的vlan需要一致，用户配置时需要注意。当成功配置后，OpenFlow交换机会构建OFPT_CSTNET_GRE_TUNNEL_REPLY消息发送给控制端，该消息包含隧道配置的源IP地址、目的IP地址、VLAN ID以及隧道虚端口对应的index值，控制端可以根据这些信息来识别对应的隧道并保留该index值。配置成功后，控制端即可下发相应规则，对符合规则的报文进行隧道，比如用户通过指定报文的出端口为隧道口对应的index即可对报文进行隧道。

3.7  QoS

1) 支持队列的方式, 通过控制队列所占带宽配置及WRR队列调度算法提供服务质量保证。

2) 支持差分服务的方式提供服务质量保证。

3.8  交换机信息收集

3.8.1  端口信息

1）提供端口基本信息，包括端口索引值（index），端口的MAC地址，端口的名称。

2）提供端口配置信息，不包括STP的配置。

3）提供端口状态信息和特征信息。

4）提供扩展端口信息，如果端口是L2OverGRE隧道端口, 提供隧道的源、目的IP地址。

5) 在收到控制端发送OFPT_FEATURES_REQUEST请求消息, 或者端口up/down、端口速率发生变化时通知OpenFlow 控制端端口信息.

3.8.2  统计信息

1) 提供单个flow信息统计， 提供符合OpenFlow控制端请求的流的匹配字段，action老化时间， 优先级， 匹配报文字节数等信息。

2) 提供流聚合统计信息，提供符合匹配规则的所有流的个数, 以及总的匹配报文个数。

3) 提供端口收发包相关统计。

4) 提供队列收发包相关统计。

4.  主要特性

该功能主要的特性为：

该功能实现了OpenFlow1.0协议，并扩展实现了l2overgre和QoS的功能，能够满足用户的需求。

5.  技术特色与优势

在OpenFlow1.0协议定义的基础上，扩展实现了l2overgre和QoS的功能，这些是DCN独有的。