目录
写在前面的话
论文：
Nick McKeown, Thomas E. Anderson, Hari Balakrishnan, Guru M. Parulkar, Larry L. Peterson, Jennifer Rexford, Scott Shenker, Jonathan S. Turner:
OpenFlow: enabling innovation in campus networks. Comput. Commun. Rev. 38(2): 69-74 (2008)
【文中数据包与分组等同】
OpenFlow交换机
理想的OpenFlow交换机。流表由控制器通过安全通道控制，如图1所示。
基本思想与工作原理
OpenFlow提供了一个开放协议来对不同交换机和路由器中的流表进行编程。网络管理员可以将流量划分为生产流和研究流。研究人员可以控制他们自己的流量，通过选择他们的数据包遵循的路线和他们接收的处理。通过这种方式，研究人员可以尝试新的路由协议、安全模型、寻址方案，甚至可以替代IP。在同一网络上，生产流量被隔离并以与今天相同的方式进行处理。
OpenFlow交换机的数据路径由流表和与每个流条目相关联的操作组成。OpenFlow交换机支持的操作集是可扩展的，但下面我们将描述对所有交换机的最低要求。为了高性能和低成本，数据路径必须具有仔细规定的灵活性程度，这意味着放弃指定每个数据包的任意处理的能力，而寻求更有限但仍然有用的操作范围。
OpenFlow交换机至少包括三个部分：
(1)流表，其具有与每个流条目相关联的动作，以告诉交换机如何处理流；
(2)安全通道（SecureChannel），其将交换机连接到远程控制进程(称为控制器)
(3)OpenFlow协议在控制器和交换机之间发送命令和数据包，该协议为控制器与交换机通信提供了开放和标准的方式。通过指定可以外部定义流表中的条目的标准接口(OpenFlow协议)，OpenFlow交换机无需研究人员对交换机进行编程。
将交换机分类为不支持正常第2层和第3层处理的专用OpenFlow交换机和启用OpenFlow的通用商用以太网交换机和路由器是有用的，Open-Flow协议和接口已作为新功能添加到这些交换机和路由器中。
专用OpenFlow交换机（Dedicated OpenFlow switches）
专用OpenFlowSwitch是一个哑巴数据路径元素（dumb datapath element），它按照远程控制进程的定义在端口之间转发数据包。图1显示了OpenFlow交换机的一个示例。
流被广泛定义，并且仅受流表的特定实现的功能的限制。例如，流可以是TCP连接，或者来自特定MAC地址ORIP地址的所有数据包，或者具有相同VLAN标签的所有数据包，或者来自相同交换机端口的所有数据包。对于涉及非IPv4数据包的实验，流可以被定义为匹配特定(但非标准)报头的所有数据包。
每个流条目都有一个与其关联的简单操作；三个基本操作(所有专用OpenFlow交换机都必须支持)是：
1、将此数据流的数据包转发到给定的端口(或多个端口)。这允许通过网络路由数据包。在大多数交换机中，这都是以线速进行的。
2、封装此流的数据包并将其转发给控制器。数据包被传送到安全通道，在那里它被封装并发送到控制器。通常用于新流中的第一个数据包，因此控制器可以决定是否应将流添加到流表。或者在一些实验中，它可以用来将所有数据包转发到控制器进行处理。
3、丢弃此流的数据包。可用于安全保护、遏制拒绝服务攻击或减少来自终端主机的可疑广播发现流量。
流表中的条目有三个字段：
(1)定义流的数据包头；
(2)定义应如何处理数据包的动作
(3)统计信息，其跟踪每个流之前的数据包和字节数，以及自最后一个数据包与流匹配以来的时间(以帮助移除不活动的流)。
“Type 0”OpenFlow交换机中的标头字段匹配。
OpenFlow交换机规范[1]定义了OpenFlow交换机的详细要求。
在第一代“0型”交换机中，流报头是表1所示的10元组。TCP流可以由所有10个字段来规范，而IP流可能不包括其定义中的传输端口。每个报头字段可以是通配符，以允许流聚合，例如仅定义VLANID的流将应用于特定VLAN上的所有流量。
启用OpenFlow的交换机（OpenFlow-enabled switches）
启用OpenFlow的商用交换机和路由器网络示例。
一些商用交换机、路由器和接入点将通过添加流表、SecureChannel和OpenFlow协议来增强OpenFlow功能。通常，流表将重用现有硬件，如TCAM；安全通道和协议将移植到交换机的操作系统上运行。图2显示了启用OpenFlow的商用交换机和接入点的网络。在此示例中，所有FlowTable由同一控制器管理；OpenFlowProtocol允许由两个或更多控制器控制交换机，以提高性能或健壮性。
我们的目标是使实验能够在现有的生产网络中进行，同时进行常规的流量和应用。因此，为了赢得网络管理员的信任，启用OpenFlow的交换机必须将实验流量(由流表处理)与要由交换机的正常第2层和第3层管道处理的生产流量隔离。有两种方法可以实现这种分离。一个是添加第四个操作：
4.通过交换机的正常处理管道转发该流的数据包。
另一种方法是为实验流量和生产流量定义不同的VLAN集合。这两种方法都允许交换机以常规方式处理不属于实验一部分的正常生产流量。所有启用OpenFlow的交换机都需要支持一种或另一种方法；有些交换机将同时支持这两种方法。
其他功能（Additional features）
如果交换机支持报头Formats和上面提到的四个基本操作(并在OpenFlow交换机规范中详细说明)，则我们称其为“0类”交换机。我们预计许多交换机将支持额外的操作，例如重写分组报头的部分(例如，用于NAT，或者在中间链路上模糊地址)，以及将分组映射到优先级类别。同样，一些流表将能够匹配数据包报头中的任意字段，从而实现对新的非IP协议的实验。当一组特定的功能出现时，我们将定义一个“类型1”交换机。
控制器（Controllers）
控制器代表实验在流表中添加和删除流量条目。例如，静态控制器可能是一个在PC上运行的简单应用程序，用于在实验期间静态地建立流以互连一组测试计算机。在这种情况下，流量类似于当前网络中的VLAN-提供了一种将实验流量与生产网络隔离的简单机制。从这个角度来看，OpenFlow是VLAN的泛化。
人们还可以想象更复杂的控制器，其随着实验的进展动态地添加/移除流。在一种使用模型中，研究人员可以控制完整的OpenFlow交换机网络，并可以*决定如何处理所有流。一个更复杂的控制器可以支持多个研究人员，每个研究人员都有不同的帐户和权限，使他们能够在不同的流集合上运行多个独立的实验。在特定研究者(例如，通过在控制器中运行的策略表)的控制下被识别为的流可以被传送到研究者的用户级控制程序，然后该控制程序决定是否应该将新的流条目添加到交换机网络。
使用OpenFlow
作为如何使用OpenFlow交换机的一个简单示例，假设Amy(一名研究人员)发明了Amy-OSPF作为取代OSPF的新路由协议。她想在OpenFlow交换机网络中尝试她的协议，而无需更改任何终端主机软件。Amy-ospf将在控制器中运行；每次启动新的应用流时，Amy-OSPF都会选择一条通过一系列OpenFlow交换机的路由，并在路径沿线的每个交换机中添加一个流条目。在她的实验中，Amy决定使用Amy-OSPF来处理从她自己的台式PC进入OpenFlow网络的流量-这样她就不会中断其他人的网络。为此，她将一个流定义为通过其PC连接到的交换机端口进入Open-Flow交换机的所有流量，并使用“封装并将所有数据包转发到控制器”操作添加一个流条目。当她的分组到达控制器时，她的新协议选择一条路由，并将新的流条目(用于应用流)添加到沿所选路径的每台交换机。当后续数据包到达交换机时，流表会快速(并以线速)处理它们。
以下是关于性能的合理问题：
随着实验的进展动态添加和删除流的控制器的监测、可靠性和可扩展性：这样的集中式控制器能足够快地处理新的流并对流开关进行编程吗？
当控制器发生故障时会发生什么情况？
在某种程度上，这些问题是在以太网原型的背景下解决的，该原型使用了简单的流量交换机和*控制器[2]。预审结果表明，基于低成本台式PC的以太网控制器每秒可以处理超过1万个新流量-足够一个大型大学校园使用。当然，可以处理新流的速率将取决于重新搜索者的实验所需的处理的复杂性。但它给了我们信心，让我们相信有意义的实验是可以进行的。通过使控制器(和实验)无状态，允许在多个独立设备上进行简单的负载平衡，可以实现可伸缩性和冗余性。
生产网络中的实验
很有可能，Amy正在很多其他人使用的网络中测试她的新协议。因此，我们希望网络具有两个附加属性：
1.属于Amy以外的用户的数据包应使用标准且经过测试的路由协议进行路由，该协议在交换机或路由器上运行，来自“名牌”供应商。
2.Amy应该只能为她的流量或她的网络管理员允许她控制的任何流量添加流条目。
属性1是通过启用OpenFlow的交换机实现的。在Amy的实验中，对于不是来自Amy的PC的所有数据包，默认操作可能是通过正常的处理管道转发它们。Am自己的数据包将被直接转发到传出端口，而不需要经过正常管道的处理。
属性2取决于控制器。控制器应该被看作是一个使研究人员能够实施各种实验的平台，并且可以通过适当地使用权限或其他方式来限制单个搜索者控制流量条目的能力来实现属性2的限制。这些类似许可的机制的确切性质将取决于控制器是如何实现的。我们预计会出现各种各样的控制者。作为控制器的具体实现的一个例子，一些作者正在研究一种称为NOX的控制器，作为以太网工作的后续[3]。通过将GENI管理软件扩展到OpenFlow网络，可能会产生完全不同的控制器。
更多例子
与任何实验平台一样，实验的集合将超过我们能想到的那些–OpenFlow网络中的大多数实验还没有被考虑到。这里，为了说明起见，我们提供了一些示例，说明如何使用启用OpenFlow的网络来试验新的网络应用程序和体系结构。
示例1：网络管理和访问控制。我们将使用以太网作为我们的第一个例子[2]，因为正是这项研究启发了OpenFlow。事实上，OpenFlow交换机可以看作是以太网数据路径交换机的推广。以太网使用控制器的特定实现，适用于网络管理和控制，用于管理流的准入和路由。以太网的基本思想是允许网络管理人员在*控制器中定义网络范围的策略，这是通过在每个新的流之前做出准入控制决策来直接实施的。控制器对照一组规则检查新的流，例如“访客可以使用HTTP通信，但只能通过Web代理”或“VoIP电话不允许与笔记本电脑通信”。控制器通过管理名称和地址之间的所有绑定将数据包与其发送方相关联-它实质上接管DNS、DHCP，并在所有用户加入时对其进行身份验证，跟踪用户连接到哪个交换机端口(或接入点)。可以设想以太网的扩展，其中策略规定将特定的流发送到控制器中的用户进程，从而允许在网络中执行研究人员特定的处理。
示例2：VLAN。OpenFlow可以很容易地为用户提供他们自己的隔离网络，就像VLAN一样。最简单的方法是静态声明一组流，这些流指定给定VLAN ID上的流量可以访问的端口。流量被识别为来自单个用户(例如，来自特定的交换机端口或MAC地址)，由交换机(通过操作)使用适当的VLAN ID进行标记。更动态的方法可能是使用控制器来管理用户身份验证，并使用用户位置的知识在运行时标记流量。
示例3：移动无线VOIP客户端。在这个例子中，考虑一种新的呼叫切换机制的实验，该机制适用于支持WiFi的电话。在实验中，VOIP客户端通过启用OpenFlow的网络建立新连接。实现了一个控制器来跟踪客户端的位置，当用户在网络中移动时，通过在流表中重新编程来重新路由连接，从而允许从一个接入点到另一个接入点的无缝切换。
示例4：非IP网络。到目前为止，我们的示例假设是IP网络，但OpenFlow不要求数据包采用任何一种格式-只要FlowTable能够匹配数据包报头。这将允许使用新的命名、寻址和路由方案进行实验。启用OpenFlow的交换机可以通过多种方式支持非IP流量。例如，流可以使用其以太网头(MAC src和dstaddress)、新的EtherType值或在IP级别通过新的IP版本号进行标识。更广泛地说，我们希望未来的交换机将允许控制器创建通用掩码(偏移量+值+掩码)，从而允许以研究人员指定的方式处理数据包。
示例5：处理数据包而不是流。上面的示例是针对涉及流的实验-其中控制器在流开始时做出决定。当然，还有一些有趣的实验需要执行，这些实验需要处理每个数据包。例如，一个入侵检测系统，它检查每个数据包，一种显式的拥塞控制机制，或者在修改数据包的内容时，例如在将数据包从一种协议格式转换为另一种协议格式时。
在启用OpenFlow的网络中处理数据包有两种基本方式。首先，也是最简单的，是强制流的所有数据包通过控制器。为此，控制器不会将新的流条目添加到FlowSwitch中-它只允许交换机默认将每个数据包转发到控制器。这具有灵活性的优势，但代价是性能。它可能为测试新协议的功能提供了一种有用的方法，但在大型网络中部署不太可能引起太大兴趣。
处理数据包的第二种方法是将它们路由到执行数据包处理的可编程交换机-例如，基于NetFPGA的可编程路由器。优点是可以以用户定义的方式以线速处理分组；图3显示了如何做到这一点的示例，其中启用OpenFlow的交换机实质上作为配线面板来操作以允许分组到达NetFPGA。在某些情况下，NetFPGA板(插入Linux PC的PCI板)可能放在支持OpenFlow的交换机旁边的配线柜中，或者(更有可能的)放在实验室里。
总结
OpenFlow是一种务实的折衷方案，它允许研究人员以统一的方式在异构交换机和路由器上运行实验，而不需要供应商暴露其产品的内部工作原理，也不需要研究人员编写供应商特定的控制软件。如果我们成功地在我们的校园中部署了OpenFlow网络，我们希望OpenFlow将逐渐在其他大学流行起来，增加支持实验的网络数量。我们希望出现新一代的控制软件，允许研究人员重用控制器和实验，并在前人工作的基础上再接再厉。随着时间的推移，我们希望不同大学的OpenFlow网络孤岛将通过隧道和覆盖网络相互连接，也许还会通过在连接大学彼此的骨干网络中运行的新的Open-flow网络来相互连接。
参考文献
[1] The OpenFlow Switch Specification. Available athttp://OpenFlowSwitch.org.
[2] Martin Casado, Michael J. Freedman, Justin Pettit,Jianying Luo, Nick McKeown, Scott Shenker. “Ethane:Taking Control of the Enterprise,” ACM SIGCOMM’07, August 2007, Kyoto, Japan.
[3] Natasha Gude, Teemu Koponen, Justin Pettit, BenPfaff, Martin Casadao, Nick McKeown, Scott Shenker,“NOX: Towards an Operating System for Networks,”In submission. Also:http://nicira.com/docs/nox-nodis.pdf.