OpenFlow 交换机规范
OpenFlow协议1.0及1.3版本分析
OpenFlow协议1.0及1.3版本分析OpenFlow是SDN控制器和交换之间交流的协议，在SDN领域有着⼗分重要的地位。
OpenFlow协议发展到现在已经经过了1.0、1.3、1.4等版本。
其中1.0和1.3版本使⽤的是最为⼴泛的。
本篇博⽂主要分析1.0版本和1.3版本OpenFLow协议在控制器和交换机之间的交互流程。
OpenFlow1.0协议交互OpenFlow协议1.0的交互过程如下：交互过程：交换机或控制器⾸先发送hello报⽂,确定openflow通信版本。
交换机或控制器收到hello报⽂之后，回复⼀个hello报⽂，协商版本。
控制器发送feature_request报⽂，查询交换机具体信息。
交换机收到feature_request报⽂之后，回复feature_reply，报告⾃⼰的详细信息给控制器。
⼯作过程中控制器会不断发送echo_request给交换机，交换机回复echo_reply消息给控制器，确认连接。
OpenFlow协议1.0版本在交换机和控制器信息交互过程中，⼀共有如下的消息类型：1. Enum ofp_type {1. /* Immutable messages. */2. OFPT_HELLO, /* Symmetric message */3. OFPT_ERROR, /* Symmetric message */4. OFPT_ECHO_REQUEST, /* Symmetric message */5. OFPT_ECHO_REPLY, /* Symmetric message */6. OFPT_VENDOR, /* Symmetric message *//* Switch configuration messages. */7. OFPT_FEATURES_REQUEST, /* Controller/switch message */8. OFPT_FEATURES_REPLY, /* Controller/switch message */9. OFPT_GET_CONFIG_REQUEST, /* Controller/switch message10. OFPT_GET_CONFIG_REPLY, /* Controller/switch message *11. OFPT_SET_CONFIG, /* Controller/switch message *//* Asynchronous messages. */12. OFPT_PACKET_IN, /* Async message */13. OFPT_FLOW_REMOVED, /* Async message */14. OFPT_PORT_STATUS, /* Async message *//* Controller command messages. */15. OFPT_PACKET_OUT, /* Controller/switch message */16. OFPT_FLOW_MOD, /* Controller/switch message */17. OFPT_PORT_MOD, /* Controller/switch message *//* Statistics messages. */18. OFPT_STATS_REQUEST, /* Controller/switch message */19. OFPT_STATS_REPLY, /* Controller/switch message *//* Barrier messages. */20. OFPT_BARRIER_REQUEST, /* Controller/switch message */21. OFPT_BARRIER_REPLY, /* Controller/switch message *//* Queue Configuration messages. */22. OFPT_QUEUE_GET_CONFIG_REQUEST, /* Controller/switch m23. OFPT_QUEUE_GET_CONFIG_REPLY /* Controller/switch mess24. };其中红⾊为常⽤消息，整理如下：HelloFeature_requestFeature_replyStats_requestStats_replyFlow_modSet_configPacket_inPacket_out下⾯分别介绍以上报⽂信息。
openflow控制器和openflow交换机之间建立信道连接的基本过程
openflow控制器和openflow交换机之间建立信道连接的基本
过程
1. OpenFlow控制器通过TCP/IP协议向OpenFlow交换机发送一个特殊的HELLO消息。
2. OpenFlow交换机接收到HELLO消息后，会发送一个特殊的HELLO消息作为响应。
3. 控制器收到交换机发送的HELLO消息后，会发送FEATURES_REQUEST消息给交换机，请求交换机的基本信息，如支持的OpenFlow版本号、流表容量等。
4. 交换机接收到FEATURES_REQUEST消息后，会发送FEATURES_REPLY消息给控制器，包含交换机的基本信息。
5. 控制器接收到交换机的FEATURES_REPLY消息后，会发送一个配置消息，如设置交换机的流表规则、端口配置等。
6. 交换机根据控制器发送的配置消息，进行相应的配置操作，并确认操作完成。
7. 控制器和交换机建立了信道连接后，可以进行OpenFlow协议定义的各种控制和管理操作，如下发流表规则、查询交换机状态等。
openflow 数据结构-无删减范文
openflow 数据结构openflow 数据结构1. 概述OpenFlow是一种网络通信协议，用于在网络交换机和控制器之间进行通信。
OpenFlow协议允许网络管理员通过控制器直接控制交换机的行为，从而实现网络资源的灵活分配和流量控制。
openflow 数据结构是OpenFlow协议中定义的数据结构，用于表示网络中的各种信息，如数据包、流表、端口等。
2. OpenFlow协议结构OpenFlow协议采用了分层的结构，由OpenFlow Switch、OpenFlow Controller和OpenFlow Protocol三个主要组成部分组成。
2.1 OpenFlow SwitchOpenFlow Switch是网络中的交换机，它负责转发数据包以及与控制器之间的通信。
OpenFlow Switch通过OpenFlow协议与控制器进行通信，接收控制器下发的指令，并根据指令的要求执行相应的操作，包括修改流表、转发数据包、发送统计信息等。
2.2 OpenFlow ControllerOpenFlow Controller是网络中的控制器，它负责对网络进行管理和控制。
Controller与Switch之间通过OpenFlow协议进行通信，Controller下发指令给Switch，根据网络的状态和需求来管理和控制网络。
Controller还负责处理从Switch传送来的统计信息和事件通知等。
2.3 OpenFlow ProtocolOpenFlow Protocol是实现OpenFlow通信的具体协议规范。
它定义了Controller与Switch之间的通信方式、消息的格式、数据结构等。
OpenFlow Protocol采用基于TCP的连接来保证通信的可靠性和稳定性。
3. OpenFlow数据结构3.1 数据包（Packet）数据包是OpenFlow协议中的基本单位，表示网络中的数据传输单元。
OpenFlow中的数据包由许多字段组成，包括源MAC地址、目标MAC地址、源IP地址、目标IP地址等。
openflow协议1.0中文版
第一章Openflow1.0第1.1节概述官方网站：。
本部分内容按照Openflow规范1.0版本撰写。
1.0之前版本都是草案，从1.0版本开始是正式版本，生产商们理论上应该都参照这个版本。
1.0版本的下载地址为http:// /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目标端口、源端口。
openflow 协议报文格式
openflow 协议报文格式（实用版）目录1.OpenFlow 协议简介2.OpenFlow 协议报文格式3.OpenFlow 协议的应用4.OpenFlow 协议的未来发展正文1.OpenFlow 协议简介OpenFlow 协议是一种用于描述控制器和交换机之间交互所用信息的标准，以及控制器和交换机的接口标准。
它的核心部分是用于 OpenFlow 协议信息结构的集合。
OpenFlow 协议旨在实现网络设备的自动化配置和管理，从而提高网络的灵活性和可编程性。
2.OpenFlow 协议报文格式OpenFlow 协议报文是在控制器和交换机之间传递的信息。
它包括以下几种类型的报文：（1）Hello 报文：用于在控制器和交换机之间建立和维护连接，以及传递双方的支持能力和状态信息。
（2）Discover 报文：用于控制器发现交换机上的流表项，从而实现对交换机端口和流表项的动态管理。
（3）Open 报文：用于建立控制器和交换机之间的会话，以便进行更高级别的通信。
（4）Update 报文：用于控制器向交换机发送流表项的更新指令，以及实现对交换机端口的动态配置。
（5）Delete 报文：用于控制器向交换机发送流表项的删除指令。
3.OpenFlow 协议的应用OpenFlow 协议主要应用于以下场景：（1）虚拟私有网络（VPN）：通过 OpenFlow 协议，可以实现对虚拟私有网络的动态配置和管理，提高网络的灵活性和可编程性。
（2）负载均衡：OpenFlow 协议可以用于实现网络设备的负载均衡，从而提高网络的性能和可靠性。
（3）流量工程：通过 OpenFlow 协议，可以实现对网络流量的动态控制和管理，从而提高网络的性能和可编程性。
4.OpenFlow 协议的未来发展随着网络技术的不断发展，OpenFlow 协议也在不断完善和扩展。
未来，OpenFlow 协议将更加关注以下几个方面的发展：（1）提高网络的可编程性：通过引入更多的编程语言和抽象层，实现对网络设备的更加灵活和可编程的管理。
OpenFlow关键技术的介绍
OpenFlow关键技术的介绍Openflow简介OpenFlow标准的名称是OpenFlow Switch Specification，因此它本身是一份设备规范，其中规定了作为SDN基础设施层转发设备的OpenFlow交换机的基本组件和功能要求，以及用于由远程控制器对交换机进行控制的OpenFlow协议。
图1-1 SDN (OpenFlow) ArchitectureOpenFlow交换机利用基于安全连接的OpenFlow协议与远程控制器相通信。
其中，流表（Flow Table）是OpenFlow交换机的关键组件，负责数据包的高速查询和转发。
流表概念在OpenFlow v1.1和v1.2中，交换机中的流表项虽然还是由三部分组成，但是相应的名称已经发生了变化。
其中，v1.0中定义的包头域（Header Fields）和动作（Actions）被分别更名为匹配域（Match Fields）和指令（Instructions）。
之所以对包头域进行改名，是因为流表项中的入端口等元组信息并不是属于数据包头的内容，因此将其改为匹配域将更为确切。
而使用指令一词替代动作，则主要是因为OpenFlow交换机中多流表的引入。
在多流表场景中，虽然数据包在前一流表中出现了匹配，但是交换机后续的操作仍旧可能是将其转到下一流表中继续进行匹配，而并非像v1.0一样马上依照流表动作对数据包做具体操作。
因此，新版本的OpenFlow将相关的动作统一更名为指令。
OpenFlow v1.1和v1.2中定义的流表结构如图1-2所示。
图1-2 OpenFlow v1.1和v1.2的流表结构而在OpenFlow v1.3之后，流表结构的内容又一次发生了变化，增加了优先级（Priority）、超时定时器（Timeouts）和Cookie等内容，从而将原来流表结构中的三部分扩展至六部分，如图1-3所示。
图1-3 OpenFlow v1.3的流表结构如图1-3所示，OpenFlow v1.3的流表结构的各个域的说明如下。
OpenFlow标准 中文版
第 2 章 Openflow...................................................................... 3
第 2.1 节 第 2.2 节 第 2.3 节
2.3.1 2.3.2 2.3.3 2.3.4 第 2.4 节 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 第 2.5 节 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 第 2.6 节
概述......................................................................................................................... 3 交换机组成............................................................................................................. 3 流表......................................................................................................................... 3 包头域..................................................................................................................... 4 计数器（counter） ................................................................................................ 5 行动（action）....................................................................................................... 6 匹配......................................................................................................................... 8 安全通道................................................................................................................. 9 of 协议 .................................................................................................................... 9 连接建立............................................................................................................... 10 连接中断............................................................................................................... 10 加密....................................................................................................................... 10 生成树................................................................................................................... 10 流表修改............................................................................................................... 11 流超时................................................................................................................... 12 of 协议 .................................................................................................................. 12 of 协议头 ............................................................................................................. 12 常用数据结构....................................................................................................... 14 Controller‐to‐Switch 消息 .................................................................................... 23 Asynchronous 消息 ............................................................................................... 35 Symmetric 消息 .................................................................................................... 40 规范 1.1 更新内容....................................................Error! Bookmark not defined.
openflow流表匹配规则
openflow流表匹配规则OpenFlow是一种用于网络交换机和路由器的开放式协议，可以实现智能化的网络控制和管理。
在OpenFlow架构中，流表是一种关键的组件，用于指定数据包的处理方式。
下面让我们来学习一下OpenFlow流表匹配规则。
OpenFlow流表由若干条规则（rule）组成，每条规则由多种字段（field）组成。
匹配规则按照优先级（priority）排序，最终匹配的规则将决定当前数据包的处理方式。
匹配规则包含以下字段：1. 交换机入端口：交换机收到数据包的物理接口编号。
2. 数据包源MAC地址（源MAC）：数据包的源物理地址。
3. 数据包目的MAC地址（目的MAC）：数据包的目标物理地址。
4. 数据包源IP地址（源IP）：数据包的源IP地址。
5. 数据包目的IP地址（目的IP）：数据包的目标IP地址。
6. IP协议类型（IP Type）：数据包所使用的IP协议，如TCP、UDP 等。
7. TCP/UDP源端口（TCP/UDP src）：数据包的源端口号。
8. TCP/UDP目的端口（TCP/UDP dst）：数据包的目的端口号。
9. VLAN ID：标识数据包所属的VLAN。
10. IPv6源地址（IPv6 src）：数据包的IPv6来源地址。
11. IPv6目的地址（IPv6 dst）：数据包的IPv6目的地址。
12. IPv6流标签（IPv6 Flow Label）：IPv6数据包中流标签字段的数值部分。
OpenFlow的流表匹配规则还包括比较运算符，如等于（EQUALS）、大于（GREATER_THAN）和小于（LESS_THAN）等。
例如，某一规则的匹配条件为：TCP源端口等于80，目的IP等于192.168.0.1，优先级为300。
那么当OpenFlow交换机收到一个TCP数据包，其源端口为80，目标IP为192.168.0.1时，该规则将优先匹配处理。
OpenFlow流表匹配规则能够为网络管理员提供更为灵活的网络管理方式，有效降低网络拥塞，提高网络的稳定性和可靠性。
openflow协议标准
OpenFlow Switch SpecificationVersion0.8.9(Wire Protocol0x97)December2,2008Current Maintainer:Brandon Heller(brandonh@)1IntroductionThis document describes the requirements of an OpenFlow Switch.We rec-ommend that you read the latest version of the OpenFlow whitepaper before reading this specification.The whitepaper is available on the OpenFlow Con-sortium website().This specification 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 defined.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 specified,all refer-ences to an OpenFlow Switch refer to Type0.Version1.0of this document will be thefirst 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 specification!”We hope to generate feedback from versions prior to Version1.0from switch designers and network researchers.2Switch ComponentsAn OpenFlow Switch consists of aflow 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.1DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!Figure1:An OpenFlow switch communicates with a controller over a secure connection using the OpenFlow protocol.Theflow table contains a set offlow entries(header values to match pack-ets against),activity counters,and a set of zero or more actions to apply to matching packets.All packets processed by the switch are compared against theflow table.If a matching entry is found,any actions for that entry are performed on the packet(e.g.,the action might be to forward a packet out a specified port).If no match is found,the packet is forwarded to the controller over the secure channel.The controller is responsible for determining how to handle packets without validflow entries,and it manages the switchflow table by adding and removingflow entries.3Flow TableThis section describes the components offlow table entries and the process by which incoming packets are matched againstflow table entries.Header Fields Counters ActionsTable1:Aflow entry consists of headerfields,counters,and actions.Eachflow table entry(see Table1)contains:•headerfields to match against packets•counters to update for matching packet•actions to apply to matching packets2DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!3.1Header FieldsIngress PortEthersourceEtherdstEthertypeVLANidIP src IPdstIPprotoTCP/UDPsrcportTCP/UDPdstport Table2:Fields from packets used to match againstflow entries.Table2shows the headerfields an incoming packet is compared against. Each entry contains a specific value,or ANY,which matches any value.If the switch supports subnet masks on the IP source and/or destinationfields,these can more precisely specify matches.Thefields in the OpenFlow10-tuple are listed in Table2and details on the properties of eachfield are described in Table 3.Field Bits When applicable NotesIngress Port(Implementationdependent)All packets Numerical represen-tation of incomingport.Ethernet source ad-dress 48All packets on en-abled portsEthernet destina-tion address 48All packets on en-abled portsEthernet type16All packets on en-abled ports A Type0switch is required to match the type in both standard Ethernet and802.2with a SNAP header and OUI of0x000000. The special value of0x05FF is used to match all802.3 packets without SNAP headers.VLAN id12All packets of Eth-ernet type0x8100IP source address32All IP packets Can be subnetmaskedIP destination ad-dress 32All IP packets Can be subnetmaskedIP protocol8All IP packetsTransport source port/ICMP Type 16All TCP,UDP,andICMP packetsOnly lower8bitsused for ICMPTypeTransport destina-tion port/ICMP Code 16All TCP,UDP,andICMP packetsOnly lower8bitsused for ICMPCodeTable3:Field lengths and the way they must be applied toflow entries.Switch designers are free to implement the internals in any way convenient provided that correct functionality is preserved.For example,while aflow3DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!may have multiple forward actions,each specifying a different port,a switch designer may choose to implement this as a single bitmask within the hardware forwarding table.3.2CountersCounters are maintained per-table,per-flow,and per-port.OpenFlow-compliant counters may be implemented in software and maintained by polling hardware counters with more limited ranges.Table4contains the required set of counters for Type0switches.Duration refers to the number of seconds aflow has been active.The Receive Errors field includes all explicitly specified errors,including frame,overrun,and CRC errors,plus any others.Counter BitsPer TableActive Entries32Packet Lookups64Packet Matches64Per FlowReceived Packets64Received Bytes64Duration32Per PortReceived Packets64Transmitted Packets64Received Bytes64Transmitted Bytes64Receive Drops64Transmit Drops64Receive Errors64Transmit Errors64Receive Frame Alignment Errors64Receive Overrun Errors64Receive CRC Errors64Collisions64Table4:Required list of counters for use in statistics messages.3.3ActionsEachflow entry is associated with zero or more actions that dictate how the switch handles matching packets.Actions need not be executed in the order in which they are specified in theflow entry.If no actions are present,the packet is dropped.A switch is not required to support all action types—just those marked“Re-quired Actions”below.When connecting to the controller,a switch indicates4DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!which of the“Optional Actions”it supports.OpenFlow-compliant switches come in two types:OpenFlow-only,and OpenFlow-enabled.OpenFlow-only switches support only the required actions below,while OpenFlow-enabled switches,routers,and access points may also support the NORMAL action.Either type of switch can also support the FLOOD action.Required Action:Forward.Type0switches must support forwarding the packet to physical ports and the following virtual ones:•ALL:Send the packet out all interfaces,not including the incoming in-terface.•CONTROLLER:Encapsulate and send the packet to the controller.•LOCAL:Send the packet to the switchs local networking stack.•TABLE:Perform actions inflow table.Only for packet-out messages.•IN PORT:Send the packet out the input port.Optional Action:Forward.The switch may optionally support the following virtual ports:•NORMAL:Process the packet using the traditional forwarding path sup-ported by the switch(i.e.,traditional L2,VLAN,and L3processing.)A Type0switch may check the VLANfield to determine whether or not to forward the packet along the normal processing route.If the switch can-not forward entries for the OpenFlow-specific VLAN back to the normal processing route,it must indicate that it does not support this action.•FLOOD:Flood the packet along the minimum spanning tree,not includ-ing the incoming interface.Ideally,a switch will supportflow-entries that can forward packets to any com-bination of the physical and virtual ports.For example,this could be expressed internally in the switch with a bitmap that includes all the physical and virtual ports.However,some switches will not be able to support any combination.There-fore,the requirement is that the switch support sending to any combination of physical ports and the Controller virtual port simultaneously.All other combi-nations are desired,but optional.The controller will only ask the switch to send to multiple physical ports simulta-neously if the switch indicates it supports this behavior in the initial handshake (see section5.3.1).Required Action:Drop.Aflow-entry with no specified action indicates that5DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!all matching packets should be dropped.Optional Action:Modify-Field.While not strictly required,the actions shown in Table5greatly increase the usefulness of an OpenFlow implementation.To aid integration with existing networks,we suggest that VLAN modification ac-tions be supported.3.4MatchingFigure2:The functions performed on a packet as it moves through an OpenFlow switch.As discussed in Section4.5,support for802.1D is optional in Type0 switches.Figure3:Aflow table showing how a packet is matched against aflow entry.On receipt of a packet,an OpenFlow Switch performs the functions shown in Figure2.6DO NOT BUILD A SWITCH FROM THIS SPECIFICATION! Action Associated Data DescriptionSet VLAN ID12bits If no VLAN is present,anew header is added withthe specified VLAN ID andpriority of zero.If a VLAN header alreadyexists,the VLAN ID is re-placed with the specifiedvalue.Set VLAN priority3bits If no VLAN is present,anew header is added withthe specified priority and aVLAN ID of zero.If a VLAN header alreadyexists,the priorityfield isreplaced with the specifiedvalue.Strip VLAN header-Strip VLAN header ifpresent.Modify Ethernet source MAC address 48bits:Value with whichto replace existing sourceMAC addressReplace the existing Eth-ernet source MAC addresswith the new valueModify Ethernet destina-tion MAC address 48bits:Value with which toreplace existing destinationMAC addressReplace the existing Eth-ernet destination MAC ad-dress with the new valueModify IPv4source address32bits:Value with which toreplace existing IPv4sourceaddress Replace the existing IP source address with new value and update the IP checksum(and TCP/UDP checksum if applicable). This action is only applica-ble to IPv4packets.Modify IPv4destination address 32bits:Value with which toreplace existing IPv4desti-nation addressReplace the existing IP des-tination address with newvalue and update the IPchecksum(and TCP/UDPchecksum if applicable).This action is only appliedto IPv4packets.Modify transport source port 16bits:Value with whichto replace existing TCP orUDP source portReplace the existingTCP/UDP source portwith new value and updatethe TCP/UDP checksum.This action is only applica-ble to TCP and UDP pack-ets.Modify transport destina-tion port 16bits:Value with whichto replace existing TCP orUDP destination portReplace the existingTCP/UDP destinationport with new value andupdate the TCP/UDPchecksumThis action is only appliedto TCP and UDP packets.Table5:Field-modify actions.7DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!Theflow table is checked for a matchingflow entry.The headerfields used for the table lookup depend on the packet type as described below(and shown in Figure3).•Rules specifying an ingress port are matched against the physical port that received the packet.•The Ethernet headers as specified in Table2are used for all packets.•If the packet is a VLAN(Ethernet type0x8100),the VLAN ID is used in the lookup.•For IP packets(Ethernet type equal to0x0800),the lookupfields also include those in the IP header.•For IP packets that are TCP or UDP(IP protocol is equal to6or17), the lookup includes the transport ports.•For IP packets that are ICMP(IP prototcol is equal to1),the lookup includes the Type and Codefields.•For IP packets with nonzero fragment offset or More Fragments bit set, the transport ports are set to zero for the lookup.A packet matches aflow table entry if the values in the headerfields used for the lookup(as defined above)match those defined in theflow table.If aflow tablefield has a value of ANY,it matches all possible values in the header.To handle the various Ethernet framing types,matching the Ethernet type is handled in a slightly different manner.If the packet is an Ethernet II frame,the Ethernet type is handled in the expected way.If the packet is an802.3frame with a SNAP header and Organizationally Unique Identifier(OUI)of0x000000, the SNAP protocol id is matched against theflows Ethernet type.Aflow entry that specifies an Ethernet type of0x05FF,matches all Ethernet802.2frames without a SNAP header and those with SNAP headers that do not have an OUI of0x000000.Packets are matched againstflow entries based on prioritization.An entry that specifies an exact match(i.e.,it has no wildcards)is always the highest priority. All wildcard entries have a priority associated with them.Higher priority entries must match before lower priority ones.If multiple entries have the same priority, the switch is free to choose any ordering.Higher numbers have higher priorities. For each packet that matches aflow entry,the associated counters for that entry are updated.If no matching entry can be found for a packet,the packet is sent to the controller over the secure channel.8DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!4Secure ChannelThe secure channel is the interface that connects each OpenFlow switch to a controller.Through this interface,the controller configures and manages the switch,receives events from the switch,and send packets out the switch. Between the datapath and the secure channel,the interface is implementation-specific,however all secure channel messages must be formatted according to the OpenFlow protocol.4.1OpenFlow Protocol OverviewThe OpenFlow protocol supports three message types,controller-to-switch,asyn-chronous,and symmetric,each with multiple sub-types.Controller-to-switch messages are initiated by the controller and used to directly manage or inspect the state of the switch.Asynchronous messages are initiated by the switch and used to update the controller of network events and changes to the switch state. Symmetric messages are initiated by either the switch or the controller and sent without solicitation.The message types used by OpenFlow are described below.4.1.1Controller-to-SwitchController/switch messages are initiated by the controller and may or may not require a response from the switch.Features:Upon SSL session establishment,the controller sends a features request message to the switch.The switch must reply with a features reply that specifies the capabilities supported by the switch.Configuration:The controller is able to set and query configuration parame-ters in the switch.The switch only responds to a query from the controller. Modify-State:Modify-State messages are sent by the controller to manage state on the switches.Their primary purpose is to add/delete and modifyflows in theflow tables and to set switch port properties.Read-State:Read-State messages are used by the controller to collect statis-tics from the switchsflow-tables,ports and the individualflow entries.Send-Packet:These are used by the controller to send packets out of a speci-fied port on the switch.4.1.2AsynchronousAsynchronous messages are sent without solicitation from the switch to the controller and denote a change in switch or network state.The four main asyn-chronous message types are described below.9DO NOT BUILD A SWITCH FROM THIS SPECIFICATION! Packet-in:For all packets that do not have a matchingflow entry,a packet-in event is sent to the controller(or if a packet matches an entry with a“send to controller”action).If the switch has sufficient memory to buffer packets that are sent to the controller,the packet-in events contain some fraction of the packet header(by default128bytes)and a buffer ID to be used by the controller when it is ready for the switch to forward the packet.Switches that do not support internal buffering(or have run out of internal buffering)must send the full packet to the controller as part of the event.Flow Expiration:When aflow entry is added to the switch,an idle time-out value is included that indicates when the entry should be removed due to a lack of activity,as well as a hard timeout value that indicates when the entry should be removed,regardless of activity.In the configuration message,the controller can indicate that it wishes to be informed when aflow expires.If this flag is set,the switch sends aflow expiration event that includes the duration of theflow and the number of packets and bytes sent.Flow expirations are only set when explicitly enabled by the controller,through the configuration message. Port-status:The switch is expected to send port-status messages to the con-troller as port configuration state changes.These events include change in port status(for example,if it was brought down directly by a user)or a change in port status as specified by802.1D(see Section4.5for a description of802.1D support requirements).Error:The switch is able to notify the controller of problems using error mes-sages.4.1.3SymmetricSymmetric messages are sent without solicitation,in either direction.Hello:Hello messages are exchanged between the switch and controller upon connection startup.Echo:Echo request/reply messages can be sent from either the switch or the controller,and must return an echo reply.They can be used to indicate the latency,bandwidth,and/or liveness of a controller-switch connection. Vendor:Vendor messages provide a standard way for OpenFlow switches to offer additional functionality within the OpenFlow message type space.This is a staging area for features meant for future OpenFlow revisions.10DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!4.2Connection SetupThe switch must be able to establish the communication at a user-configurable (but otherwisefixed)IP address,using a user-specified port.Traffic to and from the secure channel is not checked against theflow table.Therefore,the switch must identify incoming traffic as local before checking it against theflow table. Future versions of the protocol specification will describe a dynamic controller discovery protocol in which the IP address and port for communicating with the controller is determined at runtime.When an OpenFlow connection isfirst established,each side of the connection must immediately send an OFPT_HELLO message with the versionfield set to the highest OpenFlow protocol version supported by the sender.Upon receipt of this message,the recipient may calculate the OpenFlow protocol version to be used as the smaller of the version number that it sent and the one that it received.If the negotiated version is supported by the recipient,then the connection pro-ceeds.Otherwise,the recipient must reply with an OFPT_ERROR message with a typefield of OFPET_HELLO_FAILED,a codefield of OFPHFC_COMPATIBLE,and optionally an ASCII string explaining the situation in data,and then terminate the connection.4.3Connection InterruptionIn the case that the switch loses contact with the controller,the default behavior must be to do nothing-to letflows timeout naturally.Other behaviors can be implemented via vendor-specific command line interface or vendor extension OpenFlow messages.4.4EncryptionThe switch and controller communicate through an SSL connection.The SSL connection is initiated by the switch on startup to the controllers server,which is located by default on TCP port6633.The switch and controller mutually au-thenticate by exchanging certificates signed by a site-specific private key.Each switch must be user-configurable with one certificate for authenticating the con-troller(controller certificate)and the other for authenticating to the controller (switch certificate).4.5Spanning TreeType0switches may optionally support802.1D Spanning Tree Protocol.Those switches that do support it are expected to process all802.1D packets locally before performingflow lookup.A switch that implements STP must set the OFPC_STP bit in the’capabilities’field of its OFPT_FEATURES_REPLY message.A11DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!switch that implements STP must make it available on all of its physical ports, but it need not implement it on virtual ports(e.g.OFPP_LOCAL).Port status,as specified by the spanning tree protocol,is then used to limit packets forwarded to the OFP_FLOOD port to only those ports along the span-ning tree.Port changes as a result of the spanning tree are sent to the controller via port-update messages.Note that forward actions that specify the outgoing port or OFP_ALL ignore the port status set by the spanning tree protocol. Switches that do not support802.1D spanning tree must allow the controller to specify the port status for packetflooding through the port-mod messages.4.6Flow Table Modification MessagesFlow table modification messages can have the following types:enum ofp_flow_mod_command{OFPFC_ADD,/*New flow.*/OFPFC_MODIFY,/*Modify all matching flows.*/OFPFC_MODIFY_STRICT,/*Modify entry strictly matching wildcards*/OFPFC_DELETE,/*Delete all matching flows.*/OFPFC_DELETE_STRICT/*Strictly match wildcards and priority.*/};For ADD requests with set wildcardfields,the switch mustfirst check for any already-inserted entries that conflict with the incoming entry(i.e.,same prior-ity and there exists an entry that could match both).If a conflict is found,the switch should refuse the addition and may respond with an OFPEFM_ADD_OVERLAP error message.For valid(non-conflicting)ADD requests,the newflow should be added to the lowest numbered table for which the switch supports all wildcards set in the flow_match struct,and for which the priority would be observed during the matching process.If aflow entry with identical headerfields and priority already resides in any table,then that entry,including its counters, must be removed,and the newflow entry added.For MODIFY requests,if aflow entry with identical headerfields does not current reside in any table,the newflow entry must be inserted with zeroed counters.Otherwise,the actionsfield is changed on the existing entry and its counters and idle timefields are left unchanged.For DELETE requests,if noflow entry matches,no error is recorded,and no flow table modification occurs.If a switch cannotfind any table in which to add the incomingflow entry, the switch should send an OFPT_ERROR_MSG with OFPET_FLOW_MOD_FAILED type and OFPFMFC_ALL_TABLES_FULL type.MODIFY and DELETEflow mod commands have corresponding STRICT12DO NOT BUILD A SWITCH FROM THIS SPECIFICATION! versions.Without STRICT appended,the wildcards are active and allflows that match the description are modified or removed.If STRICT is appended, allfields,including the wildcards and priority,are strictly matched against the entry,and only an identicalflow is modified or removed.For example,if a mes-sage to remove entries is sent that has all the wildcardflags set,the DELETE command would delete allflows from all tables,while the DELETE STRICT command would only delete a rule that applies to all packets at the specified priority.DELETE and DELETE STRICT commands can be optionallyfiltered by out-put port.If the out_portfield contains a value other than OFPP_NONE,it intro-duces a constraint when matching.This constraint is that the rule must contain an output action directed at that port.Thisfield is ignored by ADD,MODIFY, and MODIFY STRICT messages.4.7Flow RemovalEachflow entry has an idle_timeout and a hard_timeout associated with it. If no packet has matched the rule in the last idle_timeout seconds,or it has been hard_timeout seconds since theflow was inserted,the switch removes the entry and sends aflow expiration message.In addition,the controller is able to actively remove entries by sending aflow message with the DELETE or DELETE_STRICT command.Like the message used to add the entry,a removal message contains a description,which may include wild cards.5Appendix A:The OpenFlow ProtocolThe heart of the OpenFlow spec is the set of structures used for OpenFlow Protocol messages.The structures,defines,and enumerations described below are derived from thefile include/openflow/openflow.h,which is part of the standard Open-Flow distribution.All structures are packed with padding and8-byte aligned, as checked by the assertion statements.All OpenFlow messages are sent in big-endian format.5.1OpenFlow HeaderEach OpenFlow message begins with the OpenFlow header:/*Header on all OpenFlow packets.*/struct ofp_header{uint8_t version;/*OFP_VERSION.*/uint8_t type;/*One of the OFPT_constants.*/uint16_t length;/*Length including this ofp_header.*/uint32_t xid;/*Transaction id associated with this packet.Replies use the same id as was in the request13DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!to facilitate pairing.*/};OFP_ASSERT(sizeof(struct ofp_header)==8);The version specifies the OpenFlow protocol version being used.During the current draft phase of the OpenFlow Protocol,the most significant bit will be set to indicate an experimental version and the lower bits will indicate a revision number.The current version is0x97.Thefinal version for a Type0switch will be0x00.The lengthfield indicates the total length of the message,so no additional framing is used to distinguish one frame from the next.The type can have the following values:enum ofp_type{/*Immutable messages.*/OFPT_HELLO,/*Symmetric message*/OFPT_ERROR,/*Symmetric message*/OFPT_ECHO_REQUEST,/*Symmetric message*/OFPT_ECHO_REPLY,/*Symmetric message*/OFPT_VENDOR,/*Symmetric message*//*Switch configuration messages.*/OFPT_FEATURES_REQUEST,/*Controller/switch message*/OFPT_FEATURES_REPLY,/*Controller/switch message*/OFPT_GET_CONFIG_REQUEST,/*Controller/switch message*/OFPT_GET_CONFIG_REPLY,/*Controller/switch message*/OFPT_SET_CONFIG,/*Controller/switch message*//*Asynchronous messages.*/OFPT_PACKET_IN,/*Async message*/OFPT_FLOW_EXPIRED,/*Async message*/OFPT_PORT_STATUS,/*Async message*//*Controller command messages.*/OFPT_PACKET_OUT,/*Controller/switch message*/OFPT_FLOW_MOD,/*Controller/switch message*/OFPT_PORT_MOD,/*Controller/switch message*//*Statistics messages.*/OFPT_STATS_REQUEST,/*Controller/switch message*/OFPT_STATS_REPLY/*Controller/switch message*/};5.2Common StructuresThis section describes structures used by multiple messages.5.2.1Port StructuresPhysical ports are described with the following structure:/*Description of a physical port*/struct ofp_phy_port{uint16_t port_no;uint8_t hw_addr[OFP_ETH_ALEN];14DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!uint8_t name[OFP_MAX_PORT_NAME_LEN];/*Null-terminated*/uint32_t config;/*Bitmap of OFPPC_*flags.*/uint32_t state;/*Bitmap of OFPPS_*flags.*//*Bitmaps of OFPPF_*that describe features.All bits zeroed if*unsupported or unavailable.*/uint32_t curr;/*Current features.*/uint32_t advertised;/*Features being advertised by the port.*/uint32_t supported;/*Features supported by the port.*/uint32_t peer;/*Features advertised by peer.*/};OFP_ASSERT(sizeof(struct ofp_phy_port)==48);The port_nofield is a value the datapath associates with a physical port.The hw_addrfield typically is the MAC address for the port;OFP_MAX_ETH_ALEN is 6.The namefield is a null-terminated string containing a human-readable name for the interface.The value of OFP_MAX_PORT_NAME_LEN is16.The configfield describes spanning tree and administrative settings with the following structure:/*Flags to indicate behavior of the physical port.These flags are*used in ofp_phy_port to describe the current configuration.They are*used in the ofp_port_mod message to configure the port’s behavior.*/enum ofp_port_config{OFPPC_PORT_DOWN=1<<0,/*Port is administratively down.*/OFPPC_NO_STP=1<<1,/*Disable802.1D spanning tree on port.*/OFPPC_NO_RECV=1<<2,/*Drop all packets except802.1D spanningtree packets.*/OFPPC_NO_RECV_STP=1<<3,/*Drop received802.1D STP packets.*/OFPPC_NO_FLOOD=1<<4,/*Do not include this port when flooding.*/OFPPC_NO_FWD=1<<5,/*Drop packets forwarded to port.*/OFPPC_NO_PACKET_IN=1<<6/*Do not send packet-in msgs for port.*/};The port config bits indicate whether a port has been administratively brought down,options for handling802.1D spanning tree packets,and how to handle incoming and outgoing packets.These bits,configured over multiple switches, enable an OpenFlow network to safelyflood packets along either a custom or 802.1D spanning tree.The controller may set OFPPFL_NO_STP to0to enable STP on a port or to 1to disable STP on a port.(The latter corresponds to the Disabled STP port state.)The default is switch implementation-defined;the OpenFlow reference implementation by default sets this bit to0(enabling STP).When OFPPFL_NO_STP is0,STP controls the OFPPFL_NO_FLOOD and OFPPFL_STP_* bits directly.OFPPFL_NO_FLOOD is set to0when the STP port state is Forward-ing,otherwise to1.The bits in OFPPFL_STP_MASK are set to one of the other15。
OpenFlow协议
OpenFlow协议OpenFlow是⼀种新型的⽹络协议，它是控制器和交换机之间的标准协议。
⾃2009年底发布1.0版本后，OpenFlow协议⼜经历了1.1、1.2、1.3及1.4版本的演进过程，⽬前使⽤和⽀持最多的是1.0和1.3版本。
OpenFlow1.3在1.0版的基础上进⼀步优化及升级，其中添加了很多新的特性及消息，如⽀持多个流表（flow table）、组表（group table），⽀持多控制器等。
⼀个流表中包含多个流表项，OpenFlow v1.3中流表项主要由7部分组成，分别是:匹配域（⽤来识别该条表项对应的flow）优先级（定义流表项的优先顺序）计数器（⽤于保存与条⽬相关统计信息）指令（匹配表项后需要对数据分组执⾏的动作）Timeouts、Cookie、Flags.流表项图与OpenFlow v1.0不同的是，OpenFlow v1.3协议中⼀台OF交换机会有多张流表。
具体匹配流程如下图所⽰。
当⼀个数据包到达交换机，从数据包中提取匹配字段从第⼀个流表开始查找匹配，匹配字段取决于数据包的类型。
通常包括各种数据包的头字段。
例如：以太⽹源地址或ipv4的地址等.此外，还可以对数据包关联的字段（如交换机１４的⼊端⼝等）进⾏匹配。
如果数据包和流表项匹配成功，则更新计数器并执⾏流表项中的指令。
如果该流表项使⽤ＧＯＴＯ指令指向某⼀其他流表,则执⾏完本次指令的数据包以及动作集、元数据等信息转到ＧＯＴＯ指令指向的流表进⾏下⼀步的匹配（也就是图中的跳转到Table n？）；若未指向另⼀流表则执⾏动作集，此时流⽔线处理成功。
如果在某个流表中并未匹配成功,则查找该流表中是否存在table-miss流表项（流表中的table-miss流表项指定如何处理未匹配成功的数据包）.如果存在table-miss流表项，则按该流表项中的指令执⾏,如丢弃数据包、将数据包转到另外⼀个流表或者发送给控制器（即通过Packet_In消息传递给控制器，由控制器制定数据包的转发策略⽽后通过Packet_Out消息下发流表给交换机)等；如果在流表中并未匹配成功,并且该流表项中不存在table-miss流表项，那么交换机将会丢弃该数据包。
16_OpenFlowH3C配置说明
1-2
表1-2 动作指令集定义
指令 Meter
对匹配到流表项的报文进行限速
描述
A序列中的动作
Clear-Actions
清除动作集中的所有动作
Write-Actions
更改动作集中的所有动作
Write-Metadata
2. OpenFlow接口 OpenFlow 接口有下面三类。 • 物理接口：比如交换机的以太网口等。可以作为匹配的入接口和出接口。 • 逻辑接口：比如聚合接口等。可以作为匹配的入接口和出接口。 • 保留接口：由转发动作定义的接口，实现 OpenFlow 转发功能。仅可以作为匹配的出接口。 表1-1 保留接口说明
类型
说明
ALL
报文从所有接口发送
Controller
报文上送控制器
Table
报文重新进入流表进行匹配
In Port
报文从入接口转发
Any
接口通配描述，不能作为入接口以及出接口
Local
报文上送本地CPU
Normal
报文正常转发
Flood
报文广播发送
3. OpenFlow流表 (1) 流表项组成 OpenFlow通过用户定义的流表（Flow Table）来匹配和处理报文，在同一个流表中按规则的优先级 进行先后匹配。一台OpenFlow交换机可以包含一个或者多个流表，流表项结构如 图 1-2 所示。 图1-2 流表项结构
i
1 OpenFlow
1.1 OpenFlow概述
1.1.1 OpenFlow背景
随着虚拟化技术的大规模应用，传统的网络架构和网络设备的不足越来越多的被暴露出来，如控制 平面与转发平面相集成，扩展性低，不易定制，技术更新周期长，过于依赖网络设备商。而虚拟化 技术要求设备操作简单灵活、扩展性能高、不需要用专门的芯片来进行转发控制。传统的网络设备 已经无法满足虚拟化技术以及数据中心网络的需求。而 SDN（Software Defined Network，软件定 义网络）技术可以分离控制平面和网络转发平面，解决数据中心网络中所面临的问题。
《图解OpenFlow》第一章：OpenFlow概要
《图解OpenFlow》第⼀章：OpenFlow概要1.1 OpenFlow的历史ONF：Open Networking Foundation（ONF，开放⽹络基⾦会），继承OpenFlow交换机论坛活动的形式，制定OpenFlow规范。
OpenFlow1.2之后的规范由ONF制定。
1.2 有效运⽤现有硬件，实现⾼效设计OpenFlow的初期设计思想是：⽆需设计新的硬件，⽀队现有硬件更新其软件。
因此，OpenFlow是以⽹络设备中内置了TCAM（Ternary Content-Addressable Memory）存储器为前提来实现的。
TCAM是对每个位（bit）实施0、1和don’t care三种匹配的三态电⼦器件，搭载该存储器的⽬的是在⽹络中通过硬件⾼速处理⼦⽹掩码和访问控制列表（ACL）。
1.3 所谓OpenFlow，具体是指什么传统⼆层交换机采⽤以太⽹地址和VLAN标签进⾏交换处理，⽽OpenFlow作为构建⽹络的标准规范，将各数据包（或帧）持有的以太⽹地址、VLAN标签、IP地址、TCP/UDP端⼝号等特征作为“流”来处理，在此基础上进⾏交换，并可以灵活设置路由的路径。
在构建OpenFlow⽹络时，原则上需要将控制⾯和数据⾯作为不同的⽹络，这并⾮必须要构建另外的物理⽹络。
还可以采⽤覆盖（Overlay）⽅式、使⽤VLAN等对同⼀物理⽹络进⾏逻辑分割、或者利⽤能同时⽤于数据⾯和控制⾯的“In-band控制通道”技术。
分别构建物理⽹络的优势是便于区分发⽣故障的部分。
数据⾯的构建⽅法有3种，即直接连接OpenFlow交换机的“Hop-by-Hop⽅式”、通过覆盖⽹络连接OpenFlow交换机的“覆盖⽅式”、组合以上两种⽅案的“混合⽅式”。
Hop-by-Hop⽅式就是OpenFlow交换机直接物理直连，覆盖⽅式则采⽤IP通道等技术构建⽤于数据⾯的覆盖⽹络。
覆盖⽅式具有同时使⽤现有⽹络和OpenFlow⽹络的优点，但处理性能不如Hop-by-Hop，存在MTU变⼩的缺点。
openflow协议1.3.2中文版(1-7)
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）。
OpenFlow协议（OVS）
OpenFlow协议（OVS）
⽩⽪书（版本）：
功能（OpenFlow半年升级⼀次）
FlowTable流表：由很多个流表项组成，每个流表项就是⼀个转发规则。
进⼊的通过查询流表来获得转发的⽬的端⼝。
流表项由头域、计数器和操作组成；其中头域是个⼗元组，是流表项的标识；计数器⽤来计算流表项的统计数据；操作标明了与该流表项匹配的应该执⾏的操作。
Secure Channel：安全通道是连接OpenFlow到控制器的接⼝。
控制器通过这个接⼝控制和管理，同时控制器接收来⾃交换机的事件并向交换机发送。
和控制器通过安全通道进⾏通信，⽽且所有的信息必须按照OpenFlow协议规定的格式来执⾏。
OpenFlow协议：⽤来描述控制器和交换机之间交互所⽤信息的标准，以及控制器和交换机的接⼝标准。
协议的核⼼部分是⽤于OpenFlow协议信息结构的集合。
流表项1.0版本（查看流表项：dpclt dump-flows）
Action：
流表项1.3版本
对Action的集合操作（增加⼀部分对Action的逻辑操作指令）
基本上对应1.0版本的Action内容
按顺序执⾏：
注：TTL是 Time To Live的缩写，该字段指定IP包被路由器丢弃之前允许通过的最⼤⽹段数量。
TTL是IPv4包头的⼀个8 bit字段。
总结：
TimeOuts和Cookies
流表的匹配（1.1版本）
1.3版本
如何⽣成流表的呢？
连接的流程（通过抓包画出来的图⽚）
可以⽤WireShark来抓包分析
三类包信息
还有hello包（同步信息）等等
⽹络协议的交互。
浅谈OpenFlow 技术
浅谈OpenFlow 技术OpenFlow 全称是OpenFlow Switch Specification，其字面意思就是OpenFlow 交換机规则。
在SDN 网络架构中，其基础设施层的交换机主要完成数据转发的功能，而OpenFlow 技术就是为实现这一功能的OpenFlow 交换机设置结构和功能规则，同时它也定义规范了控制平面控制器对交换机进行控制管理的OpenFlow 协议。
根据它的功能可以看出其技术核心包括了OpenFlow 交换机、OpenFlow 控制器以及OpenFlow 协议，另外通过控制器下发的流表信息也是核心技术之一。
一、OpenFlow交换机和控制器1.1 OpenFlow交换机OpenFlow 网络的核心就是OpenFlow 交换机，它是一个二层交换机，主要功能是完成数据转发处理：根据网络要求将数据层的数据信息转发到相应数据网络端口。
其实现数据转发主要依赖于OpenFlow 控制器所下发的流表，即就是OpenFlow 控制器控制交换机实现数据转发，这一方式的优势就在于OpenFlow 交换机不需要存储、记忆和学习过程，提高了数据转发的准确性和效率。
而控制器下发的流表信息是在响应网络状态、拓扑变化以及应用需求时，自行下发或通过手动下发生成，生成的流表信息需要经过SDN 控制数据平面接口发送给交换机为其提供转发机制。
OpenFlow 交换机处理数据包的过程如图1.1.1 所示，当数据包从端口传输被OpenFlow 交换机上接收后，交换机首先对接收到的数据包包头进行分析，根据分析结果按照流表的优先级高低顺序从已有流表中依次进行匹配，如果匹配到流表，则使用契合程度最高的一个流表，实施与之对应的操作，完成数据包的转发传输，然后将数据信息更新到计算机上。
如果没有匹配到与之对应的流表，就将数据包通过安全通道发送给控制器，由控制器管理数据包并做进一步处理。
OpenFlow 交换机是当前在应用范围和应用空间等方面最为普遍的Open vSwitch 软件交换机，通过开源的Open vSwitch 交换机和控制器构建实验场景和拓扑。
S5130系列交换机OpenFlow配置指导
H3C S5130-HI 系列以太网交换机OpenFlow 配置指导前言H3C S5130-HI 系列以太网交换机配置指导介绍了S5130-HI 系列交换机各软件特性的原理及其配置方法，包含原理简介、配置任务描述和配置举例。
《OpenFlow 配置指导》主要介绍了OpenFlow 相关技术的原理及配置方法。
前言部分包含如下内容：∙读者对象∙本书约定∙产品配套资料∙资料获取方式∙技术支持∙资料意见反馈读者对象本手册主要适用于如下工程师：∙网络规划人员∙现场技术支持与维护人员∙负责网络配置和维护的网络管理员本书约定1. 命令行格式约定2. 图形界面格式约定3. 各类标志本书还采用各种醒目标志来表示在操作过程中应该特别注意的地方，这些标志的意义如下：4. 图标约定本书使用的图标及其含义如下：5. 端口编号示例约定本手册中出现的端口编号仅作示例，并不代表设备上实际具有此编号的端口，实际使用中请以设备上存在的端口编号为准。
产品配套资料H3C S5130-HI 系列以太网交换机的配套资料包括如下部分：目录1 OpenFlow ···················································································································· 1-11.1 OpenFlow概述···································1-11.1.1 OpenFlow背景·································1-11.1.2 OpenFlow介绍·································1-11.1.3 OpenFlow Switch类型·····························1-11.1.4 OpenFlow接口·································1-21.1.5 OpenFlow实例·································1-21.1.6 OpenFlow流表·································1-31.1.7 Group Table ·····································································································1-51.1.8 Meter Table ······································································································1-51.1.9 OpenFlow channel ·····························································································1-61.1.10 协议规范···································1-71.2 OpenFlow配置任务简介·······························1-71.3 配置OpenFlow实例·································1-81.3.1 创建OpenFlow实例·······························1-81.3.2 配置OpenFlow实例的基本能力·························1-81.3.3 激活OpenFlow实例······························1-121.4 配置连接控制器··································1-121.4.1 配置主连接·································1-131.4.2 配置连接中断模式······························1-131.5 配置OpenFlow定时器·······························1-141.6 配置支持动态MAC地址·······························1-141.7 开启OpenFlow的无丢包模式····························1-151.8 关闭流表项变化成功后打印日志的开关························1-151.9 刷新OpenFlow实例下所有MAC-IP表的三层表项····················1-151.10 OpenFlow显示和维护·······························1-161.11 OpenFlow典型配置举例······························1-161.12 附录A 应用限制·································1-181.12.1 流表项限制·································1-181.12.2 Action List和Action Set整合的限制······················1-191.12.3 Packet Out的处理限制····························1-191.12.4 Packet in的处理限制····························1-201.12.5 匹配LLDP报文的限制····························1-201.12.6 Flow Mod的限制······························1-20 1.13 附录B MAC-IP流表································1-211.13.1 MAC-IP流表支持能力····························1-211.13.2 MAC-IP流表的限制·····························1-211.13.3 MAC-IP流表的Table Miss ················································································ 1-221.13.4 Dynamic aware ······························································································ 1-221.13.5 MAC-IP Table与Extensibility Table的配合···················1-221OpenFlow1.1 OpenFlow概述1.1.1 OpenFlow背景随着虚拟化技术的大规模应用，传统的网络架构和网络设备的不足越来越多的被暴露出来，如控制平面与转发平面相集成，扩展性低，不易定制，技术更新周期长，过于依赖网络设备商。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
OpenFlow 交换机规范(概要)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 的处理方式。
指令可以修改流水线处理，如指导包匹配另一个流表，也可以包含一系列添加到行动集的行动，还可以包含一系列立即应用到数据包的行动。
• 行动：将数据包转发到一个端口或修改数据包，如 TTL 字段减 1 操作。
行动可能是与流表项相关联的指令集或者与组表项相关联的行动存储段的一部分。
我们可以将行动积累在数据包的行动集，也可以立即将行动应用到该数据包。
行动集：与数据包相关的行动集合，在报文被每个表处理的时候这些行动可以累加，在指令集指导报文退出处理流水线的时候这些行动会被执行。
• 组：一系列的行动存储段和一些选择一个或者多个存储段应用到数据包单元的手段。
• 行动存储段：一组行动和相关参数，定义组。
• 标记：一个头，可以插入到数据包或者通过压入和弹出行动进行移除。
• 最外层的标签：一个数据包最开始出现的标签。
• 控制器：一个实体与 OpenFlow 交换机使用 OpenFlow 协议交互的实体。
• 计量：一个交换机元件，可以测量和控制数据包的速度。
当数据包速率或通过计量的字节速率超过预定义的阈值时，计量触发计量带。
如果计量带丢弃该数据包，它则被称为一个速率限制器。
4 OpenFlow 端口本节介绍了 OpenFlow 的端口的抽象概念和 OpenFlow 支持的各类端口。
4.1 OpenFlow 端口OpenFlow 的端口是 OpenFlow 处理进程和网络的其余部分之间传递数据包的网络接口。
OpenFlow 交换机之间通过 OpenFlow 端口在逻辑上相互连接。
OpenFlow 交换机使一些 OpenFlow 的端口，可用于 OpenFlow 的处理。
OpenFlow 的端口组可能与交换机硬件中提供的网络端口不完全相同，因为有些硬件网络接口可能被 OpenFlow 禁用，OpenFlow 交换机也可以定义额外的端口。
OpenFlow 的数据包从入口端口接收，经过 OpenFlow 的流水线处理（见 5.1），可将它们转发到一个输出端口。
入端口是数据包的属性，它贯穿了整个OpenFlow 流水线，并代表数据包是从哪个 OpenFlow 交换机的端口上接收的。
匹配报文的时候会用到入端口（见 5.3）。
OpenFlow 流水线可以决定数据包通过输出行动发送到输出端口（见 5.12），它定义了数据包怎样传回到网络中。
OpenFlow 交换机必须支持三种类型的 OpenFlow 的端口：物理端口，逻辑端口和保留端口。
4.2 标准端口OpenFlow 的标准端口为物理端口，逻辑端口，本地保留端口（其他保留的端口除外）。
准端口可以被用作入口和出端口，它们可用于在组（见 5.6），都有端口计数器（见 5.8）。
4.3 物理端口OpenFlow 的物理端口为交换机定义的端口，对应于一个交换机的硬件接口。
例如，以太网交换机上的物理端口与以太网接口一一对应。
在某些部署中，OpenFlow 交换机可以实现交换机的硬件虚拟化。
在这些情况下，一个 OpenFlow 物理端口可以代表一个与交换机硬件接口对应的虚拟切片。
4.4 逻辑端口OpenFlow 的逻辑端口为交换机定义的端口，并不直接对应一个交换机的硬件接口。
逻辑端口是更高层次的抽象概念，可能是交换机中不使用 OpenFlow 的端口（如链路汇聚组，隧道，环回接口）。
逻辑端口可能包括报文封装，可以映射到不同的物理端口。
这些逻辑端口的处理动作相对于 openflow 处理来说必须是透明的，而且这些端口必须通过openflow 处理起作用，像硬件接口一样。
物理端口和逻辑端口之间的唯一区别是：一个逻辑端口的数据包可能有一个叫做隧道 ID 的额外的元数据字段与它相关联；而当一个逻辑端口上接收到的分组被发送到控制器时，其逻辑端口和底层的物理端口都要报告给控制器。
4.5 保留端口本规范所定义的 OpenFlow 的保留端口。
它们指定通用的转发动作，如发送到控制器，泛洪，或使用非 OpenFlow 的方法转发，如“正常”交换机处理。
某个交换机只支持那些标记为“Required”的保留端口，至于“Optional”的端口可以根据需要可选。
• Required: ALL: 表示交换机转发特定数据包到所有端口，它仅可用于为输出端口。
在这种情况下，数据包被复制后发送到所有的标准端口，包括数据包的入端口，这些端口被配置 OFPPC_NO_FWD。
• Required: CONTROLLER: 表示的 OpenFlow 控制器的控制通道，它可以用作一个入端口或作为一个出端口。
当用作一个出端口，封装数据包中为数据包消息，并使用的 OpenFlow 协议发送（见 A.4.1）。
当用作一个入口端口，确认来自控制器的数据包。
• Require d: TABLE: 表示 openflow 流水线的开始。
这个端口仅在输出行为的时候有效，此时交换机提交报文给第一流表使数据包可以通过定期通过OpenFlow 流水线处理。
• Required: IN PORT:代表数据包进入端口。
用于输出端口时，只允许入端口发送的数据包通过。
• Required: ANY: 特别值，用在未指定端口的 OpenFlow 指令（端口通配符）。
不能使用的入口端口，也不作为一个输出端口。
• Optional: LOCAL: 表示交换机的本地网络堆栈和管理堆栈。
可以用作一个入口端口或作为一个输出端口。
本地端口使远程实体通过 OpenFlow 网络和交换机以及其网络服务互通，而不是通过一个单独的控制网络进行互通。
使用一组合适的默认流表项，本地端口可以用来实现一个带内控制器的连接。
• Optional: NORMAL: 代表传统的非 OpenFlow 流水线（见 5.1）。
仅可用于为一个输出端口，使用普通的流水线处理数据包。
如果交换机不能转发数据包从OpenFlow 流水线到普通流水线，它必须表明它不支持这一行动。
• Optional: FLOOD:表示使用普通流水线处理进行泛洪（见 5.1）。
可用于作为一个输出端口，一般可以讲数据包发往所有标准端口，但不能发往入端口或OFPPS_BLOCKED 状态的端口。
交换机也可以通过数据包的 VLAN ID 选择哪些端口泛洪。
只有OpenFlow-only 交换机不支持NORMAL 端口和FLOOD 端口，而OpenFlow-hybrid 交换机均支持上述端口（见 5.1）。
转发数据包到 FLOOD 端口依赖交换机上的实现和配置，而使用一组类型进行转发可以使控制器能够更灵活地实现泛洪（见 5.6.1）。
5 OpenFlow 表本节描述流表和组表的组件，以及与匹配和行动处理的技术。
5.1 流水线处理OpenFlow 兼容的交换机有两种类型：OpenFlow-only 和 OpenFlow-hybrid。