openflow协议1.0中文版

第一章Openflow1.0

第1.1节概述

官方网站：https://www.wendangku.net/doc/403176799.html,。

本部分内容按照Openflow规范1.0版本撰写。1.0之前版本都是草案，从1.0版本开始是正式版本，生产商们理论上应该都参照这个版本。1.0版本的下载地址为http:// https://www.wendangku.net/doc/403176799.html,/documents/openflow-spec-v1.0.0.pdf。

目前最新规范版本为1.3，但现有实现多以1.0版本为主。

第1.2节交换机组成

每个of交换机（switch）都有一张流表，进行包查找和转发。交换机可以通过of 协议经一个安全通道连接到外部控制器（controller），对流表进行查询和管理。图表一-1展示了这一过程。

图表一-1 of交换机通过安全通道连接到控制器

流表中包括一些流表项，每个表项包括若干个域：包头域（header fileds，匹配包头多个域）、活动计数器（counters）、0个或多个执行行动（actions）。交换机对每一个包在流表中进行查找，如果匹配则执行相关行动，否则通过安全通道将包转发到控制器，控制器来决策如何处理无匹配流表的网包，并添加或者删除流表项。

流表项可以将包转发到一个或者多个端口。一般来说，可以指定物理端口，协议并没有预先规定一些抽象集合（包括端口聚合或vlan端口）。of端口状态有限，包括up、down或是否生成树洪泛从此端口转发。端口配置可以通过of配置协议进行处理。of 虚拟端口包括洪泛和入口等。

第1.3节流表

流表是交换机进行转发策略控制的核心数据结构。交换芯片通过查找流表表项来决

策对进入交换机的网络流量采取合适的行为。

每个表项包括三个域，包头域（header field），计数器（counters），行动（actions）。如表格一-1所示。

表格一-1 流表项结构

1.3.1包头域

包头域包括12个域，如表格一-2所示，包括：进入接口，Ethernet源地址、目标地址、类型，vlan id，vlan优先级，IP源地址、目标地址、协议、IP ToS位，TCP/UD P目标端口、源端口。每一个域包括一个确定值或者任意值（ANY）。如果交换机支持ip地址子网掩码等，可以实现更为准确的指定。

交换机设计者可以自行提供合适的实现。例如，对于一条拥有多个转发行动（每个指定不同的端口）的流，交换机可以在硬件转发表中通过一个比特掩码来实现。

表格一-2 流表项的包头域

更具体的各个域的解释参见表格一-3。

表格一-3 包头域详细含义

1.3.2计数器（counter）

计数器可以针对每张表、每个流、每个端口、每个队列来分别维护。计数器可以利用软件实现，通过查询硬件计数器并实现更大的技术范围，计数器没有溢出提示。计数器用来统计流量的一些信息，例如存活时间、错误、活动表项、查找次数、发送包数等。必需的计数器在表格一-4中给出。

表格一-4 统计信息需要的计数器

1.3.3行动（action）

每个表项对应到0个或者多个行动，如果没有转发（forward）行动，则默认丢弃。多个行动的执行需要依照行动列表中优先级顺序依次进行。但在同一个端口上，对包的发送不保证顺序。例如，一个行动列表可能指定在同一个端口上发送两个网包到不同的VLAN，这两个网包的实际发出顺序可能是任意的，但包的内容必须由顺序执行的行动生成。

对于无法处理的行动列表，交换机可以拒绝流表项，并立刻返回一个不支持的错误（unspported flow error）。在同一个端口上的顺序可能因为生产商实现不同而不同。

行动可以分为两种类型：必备行动（Required Actions）和可选行动（Optional Act ions）。必备行动是默认支持的，交换机在连接到控制器时需要通知控制器它支持的可选行动。of兼容的交换机根据支持行动的不同分为两类：纯of交换机（OpenFlow-onl y）和of使能（OpenFlow-enabled）交换机。

纯of交换机仅支持必备行动，而of使能的交换机、路由器和接入点可能还支持N ORMAL行动。两者都可以支持FLOOD行动。

1.3.3.1必备行动

必备行动-转发（Forward）

除了给定的合法交换机端口外，还支持如下的特殊端口。

●ALL 转发到所有出口（不包括入口）

●CONTROLLER 封装并转发给控制器

●LOCAL 转发给本地网络栈

●TABLE 对要发出的包执行流表中的行动（仅对packet-out消息）

●IN_PORT 从入口发出

必备行动-丢弃（Drop）

没有明确指明处理行动的表项，所匹配的所有网包默认丢弃。

1.3.3.2可选行动

可选行动-转发

●NORMAL 按照传统交换机的2层或3层进行转发处理。

●FLOOD 通过最小生成树从出口泛洪发出（注意不包括入口）。

可选行动-入队（Enqueue）

将包转发到绑定到某个端口的队列中。

可选行动-修改域（Modify-field）

修改包头内容。具体的行为见表格一-5。

表格一-5 修改域行为

1.3.3.3交换机类型

通过支持的行为类型不同，兼容of的交换机分为两类，一类是“纯of交换机”（o f-only），一类是“支持of交换机”（of-enable）。前者仅需要支持必备行动，后者还可以支持NORMAL行动。同时，双方都可以支持泛洪行动（Flood Action）。

表格一-6 各种类型of交换机的支持行动

1.3.4匹配

图表一-2 整体匹配流程

每个包按照优先级依次去匹配流表中表项，匹配包的优先级最高的表项即为匹配结果。一旦匹配成功，对应的计数器将更新；如果没能找到匹配的表项，则转发给控制器。整体流程参见图表一-2，具体包头解析匹配过程见图表一-3。

图表一-3 包头解析的匹配流程

第1.4节安全通道

安全通道用来连接交换机和控制器，所有安全通道必须遵守of协议。控制器可以配置、管理交换机、接收交换机的事件信息，并通过交换机发出网包等。这一部分是交换机和控制器实现互动的基础。

1.4.1of协议

of协议支持三种消息类型：controller-to-switch，asynchronous（异步）和symmetri c（对称），每一类消息又有多个子消息类型。controller-to-switch消息由控制器发起，用来管理或获取switch状态；asynchronous消息由switch发起，用来将网络事件或交换机状态变化更新到控制器；symmetric消息可由交换机或控制器发起。

1.4.1.1controller-to-switch消息

由控制器（controller）发起，可能需要或不需要来自交换机的应答消息。包括Fea tures、Configuration、Modify-state、Read-state、Send-packet、Barrier等。

Features

在建立传输层安全会话（Transport Layer Security Session）的时候，控制器发送f eature请求消息给交换机，交换机需要应答自身支持的功能。

Configuration

控制器设置或查询交换机上的配置信息。交换机仅需要应答查询消息。

Modify-state

控制器管理交换机流表项和端口状态等。

Read-state

控制器向交换机请求一些诸如流、网包等统计信息。

Send-packet

控制器通过交换机指定端口发出网包。

Barrier

控制器用以确保消息依赖满足，或接收完成操作的通知。

1.4.1.2asynchronous消息

asynchronous消息不需要控制器请求发起，主要用于交换机向控制器通知状态变化等事件信息。主要消息包括Packet-in、Flow-removed、Port-status、Error等。

Packet-in

交换机收到一个网包，在流表中没有匹配项，则发送Packet-in消息给控制器。如果交换机缓存足够多，网包被临时放在缓存中，网包的部分内容（默认128字节）和在交换机缓存中的的序号也一同发给控制器；如果交换机缓存不足以存储网包，则将整个网包作为消息的附带内容发给控制器。

Flow-removed

交换机中的流表项因为超时或修改等原因被删除掉，会触发Flow-removed消息。

Port-status

交换机端口状态发生变化时（例如down掉），触发Port-status消息。

Error

交换机通过Error消息来通知控制器发生的问题。

1.4.1.3symmetric消息

symmetric消息也不必通过请求建立，包括Hello、Echo、Vendor等。

Hello

交换机和控制器用来建立连接。

Echo

交换机和控制器均可以向对方发出Echo消息，接收者则需要回复Echo reply。该消息用来测量延迟、是否连接保持等。

Vendor

交换机提供额外的附加信息功能。为未来版本预留。

1.4.2连接建立

通过安全通道建立连接，所有相关流量都不经过交换机流表检查。因此交换机必须将安全通道认为是本地连接。今后版本中将介绍动态发现控制器的协议。

当of连接建立起来后，两边必须先发送OFPT_HELLO消息给对方，该消息携带支持的最高协议版本号，接受方将采用双方都支持的最低协议版本进行通信。经过协商，一旦发现双方共同支持的协议版本，则连接建立；否则发送OFPT_ERROR消息（类型为OFPET_HELLO_FAILED，代码为OFPHFC_COMPATIBLE），描述失败原因，并终止连接。

1.4.3连接中断

当连接发生异常时，交换机应尝试连接备份的控制器。当多次尝试均失败后，交换机将进入紧急模式，并重置所有的TCP连接。此时，所有包将匹配指定的紧急模式表项，其他所有正常表项将从流表中删除。此外，当交换机刚启动时，默认进入紧急模式。

1.4.4加密

安全通道采用TLS（Transport Layer Security）连接加密。当交换机启动时，尝试连接到控制器的6633 TCP端口。双方通过交换证书进行认证。因此，每个交换机至少需配置两个证书，一个是用来认证控制器，一个用来向控制器发出认证。

1.4.5生成树

交换机可以选择支持802.1D生成树协议。如果支持，所有相关包在查找流表之前应该先在本地进行传统处理。支持生成树协议的交换机在OFPT_FEATURES_REPLY消息的compabilities域需要设置OFPC_STP位，并且需要在所有的物理端口均支持生成树协议，但无需在虚拟端口支持。

生成树协议会设置端口状态，来限制发到OFP_FLOOD的网包仅被转发到生成树指定的端口。需要注意指定出口的转发或OFP_ALL的网包会忽略生成树指定的端口状态，按照规则设置端口转发。

如果交换机不支持802.1D生成树协议，则必须允许控制器指定泛洪时的端口状态。

1.4.6流表修改

流表修改消息可以有以下类型：

1.4.6.1ADD

对于带有OFPFF_CHECK_OVERLAP标志的添加（ADD）消息，交换机将先检查新表项是否跟现有表项冲突（包头范围overlap，且有相同的优先级），如果发现冲突，将拒绝添加，并返回ofp_error_msg，并且指明OFPET_FLOW_MOD_FAILED类型和O FPFMFC_OVERLAP代码。

对于合法无冲突的添加，或不带OFPFF_CHECK_OVERLAP标志的添加，新表项将被添加到最低编号表中，优先级在匹配过程中获取。如果任何表中已经存在与新表项相同头部域和优先级的旧表项，该项将被新表项替代，同时计数器清零。如果交换机无法找到要添加的表，则返回ofp_error_msg，并且指明OFPET_FLOW_MOD_FAILED类型和OFPFMFC_ALL_TABLES_FULL代码。

如果添加表项使用了交换机不合法的端口，则交换机返回ofp_error_msg消息，同时带有OFPET_BAD_ACTION类型和OFPBAC_BAD_OUT_PORT代码。

1.4.6.2MODIFY

对于修改，如果所有已有表中没有与要修改表项同样头部域的表项，则等同于AD D消息，计数器置0；否则更新现有表项的行为域，同时保持计数器、空闲时间均不变。

1.4.6.3DELETE

对于删除，如果没有找到要删除表项，不发出任何消息；如果存在，则进行删除操作。如果被删除的表项带有OFPFF_SEND_FLOW_REM标志，则触发一条流删除的消息。删除紧急表项不触发消息。

此外，修改和删除还存在另一个_STRICT版本。对于非_STRICT版本，通配流表项是激活的，因此，所有匹配消息描述的流表项均受影响（包括包头范围被包含在消息表项中的流表项）。例如，一条所有域都是通配符的非_STRICT版本删除消息会清空流表，因为所有表项均包含在该表项中。

在_STRICT版本情况下，表项头跟优先级等都必须严格匹配才执行，即只有同一条表项会受影响。例如，一条所有域都是通配符的DELETE_STRICT消息仅删除指定优先级的某条规则。

此外删除消息还支持指定额外的out_port域。

如果交换机不能处理流操作消息指定的行为，则返回OFPET_FLOW_MOD_FAILE D : OFPFMFC_UNSUPPORTED，并拒绝该表项。

1.4.7流超时

每个表项均有一个idle_timeout 和一个hard_timeout，前者计算没有流量匹配的时间（单位都是秒），后者计算被插入表中的时间。一旦到达时间期限，则交换机自动删除该表项，同时发出一个流删除的消息。

第1.5节of协议

包括of协议相关消息的数据结构等。

1.5.1of 协议头

数据结构如下。

Version用来标明of协议版本。当前of协议中，version最重要的位用来标明实验版本，其他位标明修订版本。目前的版本是0x01，最终的Type 0交换机应该是0x00。

Length用来标明消息长度。

Type用来标明消息类型。可能的消息类型包括

1.5.2常用数据结构

包括端口、队列、匹配、行动等。

1.5.

2.1端口

1.5.

2.1.1端口结构

port_no标明绑定到物理接口的datapath值。

hw_addr是该物理接口的mac地址。

OFP_MAX_ETH_ALEN值为6。

name是该接口的名称字符串，以null结尾。

OFP_MAX_PORT_NAME_LEN为16。

1.5.

2.1.2Config

config描述了生成树和管理设置，数据结构为

1.5.

2.1.3State

state描述生成树状态和某个物理接口是否存在，数据结构为

1.5.

2.1.4端口号

一些特定的端口号定义如下（物理端口从1开始编号）。

curr，advertised，supported和peer 域标明链路模式（10M 到10G，全双工、半双工），链路类型（铜线/光线）和链路特性(自动协商和暂停)。链路特性（Port fe atures）数据结构如下，多个标识可以同时设置。

1.5.

2.2队列

1.5.

2.2.1队列结构

队列被绑定到某个端口，实现有限的流量控制操作。

数据结构为

1.5.

2.2.2队列特性

每一个队列都带有一些特性，数据结构为

特性头的数据结构为

目前，实现了最小速率队列，数据结构为

1.5.

2.3流匹配

1.5.

2.

3.1流表项结构

描述一个流表项的数据结构为

1.5.

2.

3.2wildcards

wildcards可以设置为如下的一些标志。

如果wildcards没有设置，则ofp_match精确的标明流表项。注意源和目的的掩码在wildcards中用6位来表示。其含义与CIDR相反，表示低位的多少位被掩掉。例如在CIDR中掩码24意味着255.255.255.0，而在of中，24意味着255.0.0.0。

1.5.

2.4行动

1.5.

2.4.1行动类型

目前，行动类型包括

1.5.

2.4.2行动结构

一个行动应该包括类型、长度和相应的数据。

1.5.

2.4.3输出行动

包括如下数据结构

openflow协议1.3.0中文版

OpenFlow 交换机规范(概要) Version 1.3.0 （June 25, 2012） 1 介绍 本文档介绍的OpenFlow 交换机的要求。规范包括交换机的组件和基本功能，和OpenFlow 的协议，通过一个远程控制器来管理一个OpenFlow 的交换机。 2 交换机组成 OpenFlow 的交换机包括一个或多个流表和一组表，执行分组查找和转发，和到一个外部控制器OpenFlow 的信道（图1）。该交换机与控制器进行通信，并通过OpenFlow 的协议控制器管理的交换机。 控制器使用OpenFlow 的协议，它可以添加、更新和删除流流表中的表项，既主动或者被动响应数据包。 在交换机中的每个流表中包含的一组流 表项;每个流表项包含匹配字段，计数器和一组指令，用来匹配数据包（见5.2）。 匹配开始于第一个流程表，并可能会继续额外的流表 (见 5.1）。 流表项匹配数据包按照优先级的顺序，从每个表的第一个匹配表项开始（见5.3）。如果找到匹配的项，那么具体流表项按照指令去执行。 如果在流表中未找到 匹配项 ，结果取决于漏表的流表项配置：（例如， 数据包可被转发到OpenFlow 的信道控制器、丢弃、或者可以继续到下一个的流表，见5.4）。 指令与每个包含行动或修改流水线处理的流表项相联系（见 5.9）。 行动描述了数据包转发，数据包的修改和组表 处理。 流水线处理的指令允许数据包被发送到后面的表进行进一步的 处理 ， 并允许信息以元数据的形式在表之间进行通信。当与一个匹配的流表项相 N.J.C.H

关联的指令集没有指向下一个表的时候，表流水线处理停止，这时该数据包通常被修改和 转发（见5.10）。 流表项可能包含数据包转发到某个端口。这通常是一个物理端口，但它也可能是由交换机 定义的一个逻辑端口或通过本规范中定义的一个保留的端口（见 4.1）。保留端口可以指 定通用的转发行为，如发送到控制器、泛洪、或使用非OpenFlow的方法转发。如 “ 普通” 交换机转发处理（见4.5）；而交换机定义的逻辑端口，可以指定链路汇聚组，隧道或环回 接口（见4.4）。 流表项相关的行动，也可直接把数据包发送到组，进行额外的处理（见 5.6）。组表示一 组泛洪的指令集，以及更复杂的转发（如多路径，快速重路由，链路聚合）。作为间接的通 用层，组也使多个流表项转发到一个单一的标识符（例如一个共同的下一跳的IP转发）。 这种抽象的行为使相同的输出行动非常有效。 组表包含组表项，每个组表项包含了一系列依赖于组类型的特定规范的行动存储段（见5.6.1）。一个或多个操作的行动用来使数据包发送到该组。 假如将正确的匹配和指令规范保护起来，交换机设计者可以任意的实现内部结构。例如， 如果需要使用一个流表项将所有的组转发到多个端口，交换机设计师可以在硬件转发表中 用一个单一的位掩码去实现。另一个例子是匹配; 如果OpenFlow交换机使用用不同数量 的硬件表物理实现，那么流水线就会被暴露出来。 3 名词解释 本节介绍了关键OpenFlow的规范条款： ?字节：一个8位字节。 ?数据包：以太网帧，包括报头和有效载荷。 ?端口：数据包进入和退出OpenFlow的流水线地方（见4.1）。可以是一个物理端口，由 交换机定义一个逻辑端口，或由OpenFlow的协议定义一个保留端口。 ?流水线：在一个openflow交换机中提供匹配、转发和数据包修改功能的流表连接集合。 ?流表：流水线的一个阶段，包含若干流表项。 ?流表项：在流表中用于匹配和处理数据包的一个元素。它包含用于匹配数据包的匹配字段、匹配次序的优先级，跟踪数据包的计数器，以及对应的的指令集。 ?匹配字段：用来匹配数据包的字段，包括包头，进入端口，元数据值。匹配字段可能会 进行通配符匹配（匹配任何值）或者在某些情况下通过位掩码进行匹配。 ?元数据：一个可屏蔽寄存器的值，用于携带信息从一个表到下一个。 ?指令：指令存在于流表项中，描述报文匹配流表项时OpenFlow的处理方式。指令可以修 改流水线处理，如指导包匹配另一个流表，也可以包含一系列添加到行动集的行动，还可

OpenFlow协议解读

OpenFlow通信流程解读 前言 接触了这么久的SDN，OpenFlow协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。现在有时间了，就写一写自己对OpenFlow协议通信流程的一些理解。SDN中Switch和controller 在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当于上帝，可以知道网络中所有的消息，可以给交换机下发指令。Switch就是一个实现Controller指令的实体，只不过这个交换机跟传统的交换机不一样，他的转发规则由流表指定，而流表由控制器发送。 switch组成与传统交换机的差异 switch组成 switch由一个Secure Channel和一个flow table组成，of1.3之后table变成多级流表，有256级。而of1.0中table只在table0中。 ?Secure Channel是与控制器通信的模块，switch和controller之间的连接时通过socket 连接实现。 ?Flow table里面存放这数据的转发规则，是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+自编简单控制器+scapy封装 建立连接 首先启动mininet，mininet会自行启动一个default拓扑，你也可以自己建立你的拓扑。sw 建立完成之后，会像controllerIP:controllerport发送数据。 controller启动之后，监听指定端口，默认6633，但是好像以后的都改了，因为该端口被其他协议占用。

Openflow协议通信流程解读

Openflow协议通信流程解读 前言 接触了这么久的SDN，Openflow协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。现在有时间了，就写一写自己对Openflow协议通信流程的一些理解。 SDN中Switch和controller 在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当于上帝，可以知道网络中所有的消息，可以给交换机下发指令。Switch就是一个实现Controller 指令的实体，只不过这个交换机跟传统的交换机不一样，他的转发规则由流表指定，而流表由控制器发送。

switch组成与传统交换机的差异 switch组成 switch由一个Secure Channel和一个flow table组成，of1.3之后table变成多级流表，有256级。而of1.0中table只在table0中。 ?Secure Channel是与控制器通信的模块，switch和controller之间的连接时通过socket连接实现。 ?Flow table里面存放这数据的转发规则，是switch的交换转发模块。数据进入switch之后，在table中寻找对应的flow进行匹配，并执行相应的action，若无匹配的flow则产生packet_in（后面有讲） of中sw与传统交换机的差异 ?匹配层次高达4层，可以匹配到端口，而传统交换机只是2层的设备。 ?运行of协议，实现许多路由器的功能，比如组播。 ?求补充！！（如果你知道，请告诉我，非常感谢！） openflow的switch可以从以下方式获得 ?实体of交换机，目前市场上有一些厂商已经制造出of交换机，但是普遍反映价格较贵！性能最好。 ?在实体机上安装OVS，OVS可以使计算机变成一个openflow交换机。性能相对稳定。

openflow协议以及协议的代码实现

openflow openflow协议

openflow协议 ?of 协议支持三种消息类型：controller-to-switch，asynchronous（异步）和symmetric（对称），每一类消息又有多个子消息类型。 ?controller-to-switch 消息由控制器发起，用来管理或获取switch 状态；?asynchronous 消息由switch 发起，用来将网络事件或交换机状态变化更新到控制器；?symmetric 消息可由交换机或控制器发起。

controller-to-switch ?Features ?在建立传输层安全会话（Transport Layer Security Session）的时候，控制器发送feature请求消息给交换机，交换机需要应答自身支持的功能。 ?Configuration ?控制器设置或查询交换机上的配置信息。交换机仅需要应答查询消息。?Modify-state ?控制器管理交换机流表项和端口状态等。 ?Read-state ?控制器向交换机请求一些诸如流、网包等统计信息。 ?Send-packet ?控制器通过交换机指定端口发出网包。 ?Barrier ?控制器确保消息依赖满足，或接收完成操作的通知

asynchronous ?Packet-in ?交换机收到一个网包，在流表中没有匹配项，则发送Packet-in 消息给控制器。如果交换机缓存足够多，网包被临时放在缓存中，网包的部分内容（默认128 字节）和在交换机缓存中的的序号也一同发给控制器；如果交换机缓存不足以存储网包，则将整个网包作为消息的附带内容发给控制器。 ?Flow-removed ?交换机中的流表项因为超时或修改等原因被删除掉，会触发Flow-removed 消息。 ?Port-status ?交换机端口状态发生变化时（例如down 掉），触发Port-status 消息。

Openflow协议通信流程解读

Openflow协议通信流程解读 分类：openflow协议分析 2013-12-30 19:01887人阅读评论(1)收藏举报 目录(?)[-] 1前言 2SDN中Switch和controller 2switch组成与传统交换机的差异 2switch组成 2of中sw与传统交换机的差异 2openflow的switch可以从以下方式获得 2controller组成 3Openflow通信流程 3建立连接 3OFPT_HELLO 3OFPT_ERROR 3OFPT_ECHO 3OFPT_FEATURES 3OFPT_FEATURES_REQUEST 3OFPT_FEATURES_REPLY 3OFPT_PACKET_IN 3OFPT_PACKET_OUT 3OFPT_FLOW_MOD 3OFP_HEADER 3WILDCARDS 3MATCH

3FLOW_MOD 3command里面的类型决定了flow_mod的操作是添加 修改还是删除等类型如下 3两个时间参数idle_timeout idle_timeout 3priority 3buffer_id 3out_port 3flags 3ACTION 3OFPT_BARRIER_REQUEST REPLY 3OFPT_FLOW_REMOVED 3OFPT_STATS_REQUEST REPLY 3OFPT_STATS_REQUEST 3OFPT_STATS_REPLY 4后续 4ERROR 4Type 4Code 前言 接触了这么久的SDN，Openflow协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。现在有时间了，就写一写自己对Openflow协议通信流程的一些理解。 SDN中Switch和controller 在SDN中很重要的两个实体是Switch跟Controller。Controller在网络中相当

openflow协议1.3.0中文版 - 完整版

OpenFlow交换机规范(概要) Version1.3.0（June25,2012） 1介绍 本文档描述了对OpenFlow交换机的要求。此规范内容包括交换机的组件和基本功能，和一个远程控制器管理一个OpenFlow交换机的协议：OpenFlow。 2交换机部件 OpenFlow的交换机包括一个或多个流表和一个组表，执行分组查找和转发，和到一个外部控制器OpenFlow的信道（图1）。该交换机与控制器进行通信，控制器通过OpenFlow协议来管理交换机。 控制器使用OpenFlow协议，可以添加、更新和删除流流表中的表项，主动或者被动响应数据包。在交换机中的每个流表中包含的一组流表项;每个流表项包含匹配字段，计数器和一组指令，用来匹配数据包（见5.2）。 匹配从第一个流表开始，并可能会继续匹配其它流表(见5.1）。流表项匹配数据包是按照优先级的顺序，从每个表的第一个匹配项开始（见5.3）。如果找到一个匹配项，那么与流表项相关的指令就会去执行。如果在流表中未找到匹配项，结果取决于漏表的流表项配置：（例如，数据包可能通过OpenFlow信道被转发到控制器、丢弃、或者可以继续到下一个的流表，见5.4）。 与流表项相关联的指令包含行动或修改流水线处理（见5.9）。行动指令描述了数据包转发，数据包的修改和组表处理。流水线处理指令允许数据包被发送到后面的表进行进一步的处理，并允许信息以元数据的形式在表之间进行通信。当与一个匹配的流表项相关联的指令集没有指向下一个表的时候，表流水线停止处理，这时该数据包通常会被修改和转发（见5.10）。 流表项可能把数据包转发到某个端口。这通常是一个物理端口，但它也可能是由交换机定义的一个逻辑端口或通过本规范中定义的一个保留的端口（见4.1）。保留端口可以指定通用的转发行为，如发送到控制器、泛洪、或使用非OpenFlow的方法转发，如“普通”交换机转发处理（见4.5）；而交换机定义的逻辑端口，可以是指定的链路汇聚组、隧道或环回接口（见4.4）。 与流表项相关的行动，也可直接把数据包发送到组，进行额外的处理（见5.6）。组表示一组泛洪的指令集，以及更复杂的转发（如多路径，快速重路由，链路聚合）。作为间接的通用层，组也使多个流表项转发到同一个标识者（例如IP转发到一个共同的下一跳）。这种抽象的行为使相同的输出行动非常有效。 组表包含若干组表项，每个组表项包含一系列依赖于组类型的特定含义行动存储段（见

openflow协议标准

OpenFlow Switch Speci?cation Version0.8.9(Wire Protocol0x97) December2,2008 Current Maintainer:Brandon Heller(brandonh@https://www.wendangku.net/doc/403176799.html,) 1Introduction This document describes the requirements of an OpenFlow Switch.We rec-ommend that you read the latest version of the OpenFlow whitepaper before reading this speci?cation.The whitepaper is available on the OpenFlow Con-sortium website(https://www.wendangku.net/doc/403176799.html,).This speci?cation covers the components and the basic functions of the switch,and the OpenFlow protocol to manage an OpenFlow switch from a remote controller. OpenFlow Switches will be of“Type0”or“Type1”,depending on their ca-pabilities.Type0represents the minimum requirements for any conforming OpenFlow Switch.Type1requirements will be a superset of Type0,and re-main to be de?ned.It is expected that commercial OpenFlow Switches will initially be of Type0,evolving to Type1;and that vendors will support addi-tional features over time.However,all switches are expected to use the same OpenFlow Protocol for communication between switch and controller.For the remainder of this version of the document,unless otherwise speci?ed,all refer-ences to an OpenFlow Switch refer to Type0. Version1.0of this document will be the?rst to specify a Type0switch suit-able for implementation.Versions before Version1.0will be marked“Draft”, and will include the header:“Do not build a switch from this speci?cation!”We hope to generate feedback from versions prior to Version1.0from switch designers and network researchers. 2Switch Components An OpenFlow Switch consists of a?ow table,which performs packet lookup and forwarding,and a secure channel to an external controller(Figure1).The con-troller manages the switch over the secure channel using the OpenFlow protocol. 1

OpenFlow1.3协议总结

OpenFlow1.3协议总结 OpenFlow1.3协议总结 (1) 1介绍 (4) 2交换机组成 (4) 3名称解释 (4) 4端口 (4) 5OpenFlow表 (5) 5.1Pipeline处理 (5) 5.2Flow Table (6) 5.3Match (6) 5.4Table-miss (6) 5.5流表项删除 (6) 5.6组表 (7) 5.7Meter Table (7) 5.8Counters (8) 5.9Instructions (8) 6OpenFlow1.3版本协议新增消息 (10) 7OpenFlow Protocol (10) 7.1OpenFlow Header (10) ofp_header (10) 7.2Common Structures (11) 7.2.1端口 (11) ofp_port (12) 7.2.2队列 (14) ofp_packet_queue (14) 7.2.3匹配域 (15) struct ofp_match (15) ofp_oxm_experimenter_header (17) 7.2.4Flow Instruction Structures (17) ofp_instruction (17) ofp_instruction_goto_table (17) ofp_instruction_write_metadata (17) ofp_instruction_actions (17) ofp_instruction_meter (18) ofp_instruction_experimenter (18) 7.2.5Action Structures (18) ofp_action_header (18) ofp_action_output (18) ofp_action_group (19) ofp_action_set_queue (19) ofp_action_mpls_ttl (19)

openflow协议通信流程

编号：_______________本资料为word版本，可以直接编辑和打印，感谢您的下载 openflow协议通信流程 甲方：___________________ 乙方：___________________ 日期：___________________

openflow协议通信流程 篇一：openflow协议通信流程解读 openflow协议通信流程解读 前言 接触了这么久的sdn , openflow协议前前后后也读过好多遍，但是一直没有时间总结一下自己的一些见解。现在有时间了，就写一写自己对openflow协议通信流程的一些理解。 sdn 中switch 和controller 在sdn中很重要的两个实体是switch 跟controller 。 controller 在网络中相当于上帝，可以知道网络中所有的消 息，可以给交换机下发指令。switch就是一个实现 controller 指令的实体，只不过这个交换机跟传统的交换机不一样，他的转发规则由流表指定，而流表由控制器发送。 switch组成与传统交换机的差异 switch 组成 switch 由一个securechannel 和一个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中目前