openflow协议1.3.0中文版 - 完整版
OpenFlow协议抓包分析
天津市东丽区八年级上学期物理期末考试试卷姓名:________ 班级:________ 成绩:________一、单选题 (共10题；共20分)1. （2分） (2016八上·鄂城期中) a、b、c三辆汽车从甲地出发沿直线运动到乙地，其中a车以速度v做匀速直线运动到乙地；b车以速度v出发，先做加速运动再做减速运动，达到乙地时速度恰好还是v；c车也以速度v 出发，先做减速运动再做加速运动，到达乙地时速度恰好也是v，三辆汽车运动时间分别为ta、tb和tc ，其大小关系正确的是（）A . ta=tb=tcB . ta＜tb＜tcC . tc＞ta＞tbD . tc＞ta=tb2. （2分）关于声现象，下列说法正确的是（）A . “闻其声而知其人”主要是根据声音的响度来判断的B . 敲锣时用力越大，声音的音调越高C . 市区内某些路段“禁鸣喇叭”，这是在声音的传播的过程中减弱噪声D . 用超声波能粉碎人体内的“小石头”，说明声波能够传递能量3. （2分）下列说法正确的是（）A . 物体吸热，温度一定升高B . 只在液体内部进行汽化的现象叫沸腾C . -10℃的酒精也能蒸发D . 固体都有一定的熔化温度4. （2分） (2017八上·盐田期末) 以下各图中成虚像的是（）A . a，dB . b，cC . a，cD . a，b5. （2分） (2017八上·福建期中) 小红同学喜欢利用复读机进行英语听力训练，如果让复读机先正常播放一段录音，然后调大音量旋钮播放同一段录音，则发出的声音（）A . 响度增大，音调不变B . 响度减小，音调不变C . 响度不变，音调升高D . 响度不变，音调降低6. （2分）(2017·南岗模拟) 晓彤同学对下列物理量进行了估测，其中不合理的是（）A . 一层普通居民楼的高约为3mB . 声音在空气中传播速度约为3×105/sC . 我国家庭用电器正常工作的电压一般是220VD . 人体的密度约为1.0×103kg/m37. （2分） (2019八上·重庆期中) 如图所示，表示晶体熔化时温度随时间变化的图象是（）A .B .C .D .8. （2分） (2019八上·麻城期中) 下列关于光现象的说法，错误的是（）A . 黑板反光，是由于光在黑板表面发生了镜面反射B . 我们能从不同角度看到同一朵花，是由于光照射在花朵上发生了漫反射C . 开凿隧道时工人用激光束引导掘进机，利用了光沿直线传播的原理D . 夜晚能看见明亮的月亮，是因为月亮能发光9. （2分）(2018·威海) 下列关于凸透镜应用的说法，正确的是（）A . 近视眼需要佩戴凸透镜来矫正B . 放大镜成正立、放大的实像C . 用手机扫描二维码时，应使二维码位于手机镜头一倍焦距之内D . 要使投影仪成像变大，应使投影仪远离屏幕，同时使镜头靠近投片10. （2分）下列是小明同学对有关光学现象的解释，他的说法正确的是A . 人眼近视是因为将像成在了视网膜的后面B . “猪八戒照镜子，表里如一”是光的反射形成的C . 人在照相机中所成的像是正立的实像D . 太阳光通过三棱镜色散后不可能有紫光二、填空题 (共8题；共19分)11. （3分） (2018八上·潮州期中) 如图图中，甲尺的分度值是________mm，物体A的长度是 ________cm。
SDN软件定义网络之南向协议——OpenFlow协议
SDN软件定义网络之南向协议——OpenFlow协议一、引言SDN（Software-Defined Networking）是一种新兴的网络架构，它通过将网络控制平面与数据平面分离，实现了网络的灵活性和可编程性。
而OpenFlow协议作为SDN架构中的南向协议，负责控制器与交换机之间的通信，实现网络流量的转发和控制。
本协议旨在规范OpenFlow协议的标准格式，以确保各厂商的OpenFlow 实现能够互相兼容和互操作。
二、范围本协议适用于所有实现OpenFlow协议的网络设备厂商和SDN控制器开发者。
三、术语定义1. OpenFlow控制器（Controller）：SDN架构中的中央控制节点，负责网络的管理和控制。
2. OpenFlow交换机（Switch）：SDN架构中的数据转发节点，通过与控制器通信，根据控制器的指令进行流量转发和控制。
3. OpenFlow通道（Channel）：控制器与交换机之间的双向通信通道，用于传输OpenFlow消息。
4. OpenFlow消息（Message）：在OpenFlow通道上传输的控制信息单元，用于交换控制器和交换机之间的命令和状态。
四、协议规范1. OpenFlow版本本协议所定义的OpenFlow协议版本为OpenFlow 1.5。
2. OpenFlow消息格式OpenFlow消息由消息头和消息体组成，其中消息头包含消息类型、消息长度等字段，消息体包含具体的命令和参数。
（1）消息头格式：- 版本号（Version）：用于指示OpenFlow协议的版本，占4个字节。
- 消息类型（Type）：用于标识消息的类型，占2个字节。
- 消息长度（Length）：用于指示消息体的长度，占2个字节。
- 事务标识（Transaction ID）：用于标识消息的事务，占4个字节。
（2）消息类型：- 控制器与交换机之间的消息类型包括控制消息、配置消息、状态消息和错误消息等。
OpenFlow协议1.0讲解
Openflow 1.0.0 报告
余显 2013年7月11日
YOUR LOGO
目录
1、SDN简介
2、openflow介绍
三、OF协议：控制器控制 流表修改的数据结构
• • • • • • • • • • • • • • • • 1、控制修改命令： 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. */ }; 2、flags域的取值： enum ofp_flow_mod_flags { OFPFF_SEND_FLOW_REM = 1 << 0, /* Send flow removed message when flow * expires or is deleted. */ OFPFF_CHECK_OVERLAP = 1 << 1, /* Check for overlapping entries first. */ OFPFF_EMERG = 1 << 2 /* Remark this is for emergency. */ };
“OpenFlow Switch Specification”协议概述
“OpenFlow Switch Specification”协议概述杭州华三通信技术有限公司H3C Technologies Co., Ltd.版权所有侵权必究All rights reserved修订记录Revision record目录Table of Contents1OpenFlow Switch (6)1.1OpenFlow端口 (6)1.2OpenFlow表项 (8)1.2.1Flow Table (8)1.2.2Group Table (9)1.2.3Meter Table (10)2OpenFlow报文的处理 (11)2.1OpenFlow管道 (11)2.2OpenFlow报文的匹配 (12)2.3Table Miss (15)2.4Instructions (15)2.5Action Set (16)2.6Action List (17)3OpenFlow信道 (18)3.1OpenFlow信道的连接 (18)3.2OpenFlow协议报文的处理 (19)3.3Multiple Controllers (19)3.4Auxiliary Connections (20)4OpenFlow协议报文 (20)4.1Symmetric消息 (21)4.1.1Hello (21)4.1.2Echo Request/Reply (21)4.1.3Experimenter (21)4.2Asynchronous消息 (21)4.2.1Packet-In Message (22)4.2.2Flow-Removed Messeage (22)4.2.3Port-Status Message (23)4.2.4Error Message (24)4.3Controller to Switch消息 (24)4.3.1Features (24)4.3.2Swtich Configuration (25)4.3.3Queue Get Configuration (25)4.3.4Modify Flow Entry Message (26)4.3.5Modify Group Entry Message (27)4.3.6Port Modification Message (28)4.3.7Meter Modification Message (28)4.3.8Multipart Messages (29)4.3.9Packet-Out Message (30)4.3.10Barrier Message (30)4.3.11Role-Request Message (31)4.3.12Set Asynchronous Configuration Message (31)4.3.13Flow Table Configuration (32)5结束语 (32)“OpenFlow Switch Specification”协议概述⏹关键词Key words：OpenFlow⏹摘要Abstract：本文具体介绍了OpenFlow协议⏹缩略语清单List of abbreviations：1 OpenFlow Switch“OpenFlow Switch Specification”主要介绍了OpenFlow交换机的基本构成、主要功能以及Controller如何远程控制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关键技术的介绍
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的流表结构的各个域的说明如下。
SDN技术介绍
dp port /icmp code
? 流表由流表项组成。 ? 流表项由其匹配域来标识。每个流表项中包括： ? 匹配域 match fields ：与包进行匹配。由输入端口和包头组成，也可以包括由前一个表确定
的元数据。 ? 计数器 counters ：发生包匹配时更新 ? 指令集 instructions ：修改动作集，或修改流水线处理
基于Table/Flow/Port/Queue的各种报文计数器
Ingress Port
Meta data
Ethernet src dst type
VLAN
MPLS
id prio. lab. t.c. src
IP
dst
Proto /A. op
ToS
TCP/UDP/SCTP ICMP
src port /icmp type
OpenFlow
一个简单的类比
应用 / 市场
系统
硬件
……
Openflow协议介绍
OpenFlow简介和架构
OpenFlow 1.0
OpenFlow 1.1
? OpenFlow 是SDN架构中定义的一个控制器与转发层之间的通信接口标准， OpenFlow 允 许直接访问和操作网络设备的转发平面
? OpenFlow 的思想是分离控制平面和数据平面，二者之间使用标准的协议通信；数据平面采 用基于流的方式进行转发。
OpenFlow 版本演进
Dec, 2009
Feb, 2011
Dec, 2011
June, 2012
Oct, 2013
OF 1.0
功能：
? 单表 ? IPv4
OF 1.1
? 多表 ? MPLS、VLAN ? group ? ECMP
OpenvSwitch+OpenFlow中文
OpenvSwitch+OpenFlow中文OpenvSwitch + OpenFlow:Let’s get start在Fedora完成OpenvSwitch+OpenFLow部署所需要的用户空间工具、必备的内核模块都应经包含在Fedora的发布版中了。
我在弄清楚这些包的时候花了很多时间，现在，这里有介绍了如何使用这些组件的信息。
*注：下文中简称OpenvSwitch为OVS1、简介：自从2.4版本以来，OVS对于内核中网桥模块来说是可选择的。
OVS比标准的网桥模块有非常大的改进。
这些改进都会在/doc/8b17051216.html,这个网站中进行了详细的阐述。
然而在这些增强的功能中，有一项便是：支持OpenFlow 协议。
从概念上来讲，交换机功能可以分成两个部分：控制层和数据层。
而控制层是交换机处理发现、路由、通路计算，与其他交换机通信等功能的核心。
控制层创建一个转发流表，数据层根据这些流表以线路速度处理进入交换机的数据包。
OpenFlow协议可以将将交换机的控制层分离到控制器中，并且用软件定义整个网络的行为（也被称为SDN）。
与这种（OpenFlow）设置相区别，现有的交换机使用专有的下层工具/协议来进行管理。
OpenFlow成为一种可以开放的标准，它可以不为下层绑定专有的工具而统一的标准管理来自不同供应商的交换机。
2、安装：在Fedora中，OVS的实现分为两个部分：OVS内核模块(数据层data pane)和用户空间工具(控制层control pane)。
由于输入的数据包要尽快处理，OVS的数据层被推送到内核空间。
为了使用OVS进行网络的虚拟化时，OVS服务必须启动，并且命令行工具必须已经正确的配置，OVS是架在网桥上的。
在Fedora中，虚拟交换机工作在两种模式下：独立主机和OpenFlow模式。
这篇文章首先会重点介绍如何在独立主机和OpenFlow两种模式下建立可以连接到OVS网桥的虚拟机。
Openflow版本间差别
Openflow版本间差别(1.0与1.1 1.2 1.3之间)1.OpenFlow version 1.1Release date : February 28, 20111 Multiple TablesPrior versions of the OpenFlow specification did expose to the controller the abstraction of a single table. The OpenFlow pipeline could internally be mapped to multiple tables, such as having a separate wildcard and exact match table, but those tables would always act logically as a single table.OpenFlow 1.1 introduces a more flexible pipeline with multiple tables. Exposing multiple tables has many advantages. The first advantage is that many hardware have multiple tables internally (for example L2 table, L3 table, multiple TCAM lookups), and the multiple table support of OpenFlow may enable to expose this hardware with greater efficiency and flexibility. The second advantage is that many network deployments combine orthogonal processing of packets (for example ACL, QoS and routing), forcing all those processing in a single table creates huge ruleset due to the cross product of individual rules, multiple table may decouple properly those processing.The new OpenFlow pipeline with multiple table is quite different from the simple pipeline of prior OpenFlow versions. The new OpenFlow pipeline expose a set of completely generic tables, supporting the full match and full set of actions. It’s difficult to build a pipeline abstraction that represent accurately all possible hardware, therefore OpenFlow 1.1 is based on a generic and flexible pipeline that may be mapped to the hardware. Some limited table capabilities are available to denote what each table is capable of supporting.Packet are processed through the pipeline, they are matched and processed in the first table, and may be matched and processed in other tables. As it goes through the pipeline, a packet is associated with an action set, accumulating action, and a generic metadata register. The action set is resolved at the end of the pipeline and applied to the packet. The metadata can be matched and written at each table and enables to carry state between tables.OpenFlow introduces a new protocol object called instruction to control pipeline processing. Actions which were directly attached to flows in previous versions are now encapsulated in instructions, instructions may apply those actions between tables or accumulate them in the packet action set. Instructions can also change the metadata, or direct packet to another table.• The switch now expose a pipeline with multiple tables.• Flow entry have instruction to control pipeline processing• Controller can choose packet traversal of tables via goto instruction• Metadata field (64 bits) can be set and match in tables• Packet actions can be merged in packet action set• Packet action set is executed at the end of pipeline• Packet actions can be applied between table stages• Table miss can send to controller, continue to next table or drop• Rudimentary table capability and configuration2 GroupsThe new group abstraction enables OpenFlow to represent a set of ports as a single entity for forwarding packets. Different types of groups are provided, to represent different abstractions such as multicasting or multipathing. Each group is composed of a set group buckets, each group bucket contains the set of actions to be applied before forwarding to the port. Groups buckets can also forward to other groups, enabling to chain groups together.• Group indirection to represent a set of ports• Group table with 4 types of groups :- All - used for multicast and flooding- Select - used for multipath- Indirect - simple indirection- Fast Failover - use first live port• Group action to direct a flow to a group• Group buckets contains actions related to the individual port3 Tags : MPLS & VLANPrior versions of the OpenFlow specification had limited VLAN support, it only supported a single level of VLAN tagging with ambiguous semantic. The new tagging support has explicit actions to add, modify and remove VLAN tags, and can support multiple level of VLAN tagging. It also adds similar support the MPLS shim headers.• Support for VLAN and QinQ, adding, modifying and removing VLAN headers• Support for MPLS, adding, modifying and removing MPLS shim headers4 Virtual portsPrior versions of the OpenFlow specification assumed that all the ports of the OpenFlow switch were physical ports. This version of the specification add support for virtual ports, which can represent complex forwarding abstractions such as LAGs or tunnels.• Make port number 32 bits, enable larger number of ports• Enable switch to provide virtual port as OpenFlow ports• Augment packet-in to report both virtual and physical ports5 Controller connection failurePrior versions of the OpenFlow specification introduced the emergency flow cache as a way to deal with the loss of connectivity with the controller. The emergency flow cache feature was removed in this version of the specification, due to the lack of adoption, the complexity to implement it and other issues with the feature semantic.This version of the specification add two simpler modes to deal with the loss of connectivity with the controller. In fail secure mode, the switch continues operating in OpenFlow mode, until it reconnects to a controller. In fail standalone mode, the switch revert to using normal processing (Ethernet switching).• Remove Emergency Flow Cache from spec• Connection interruption trigger fail secure or fail standalone mode6 Other changes• Remove 802.1d-specific text from the specification• Cookie Enhancements Proposal - cookie mask for filtering• Set queue action (unbundled from output port action)• Maskable DL and NW address match fields• Add TTL decrement, set and copy actions for IPv4 and MPLS• SCTP header matching and rewriting support• Set ECN action• Define message handling : no loss, may reorder if no barrier• Rename VENDOR APIs to EXPERIMENTER APIs• Many other bug fixes, rewording and clarifications2.OpenFlow version 1.2Release date : December 5, 2011Please refers to the bug tracking ID for more details on each change1 Extensible match supportPrior versions of the OpenFlow specification used a static fixed length structureto specify ofp_match, which prevents flexible expression of matches and prevents inclusion of new match fields. The ofp_match has been changed to a TLV structure, called OpenFlow Extensible Match (OXM), which dramatically increases flexibility.The match fields themselves have been reorganised. In the previous static structure, many fields were overloaded ; for example tcp.src_port, udp.src_port, and icmp.code were using the same field entry. Now, every logical field has its own unique type.List of features for OpenFlow Extensible Match :• Flexible and compact TLV structure called OXM (EXT-1)• Enable flexible expression of match, and flexible bitmasking (EXT-1)• Pre-requisite system to insure consistency of match (EXT-1)• Give every match field a unique type, remove overloading (EXT-1)• Modify VLAN matching to be more flexible (EXT-26)• Add vendor classes and experimenter matches (EXT-42)• Allow switches to override match requirements (EXT-56, EXT-33)2 Extensible ’set field’ packet rewriting supportPrior versions of the OpenFlow specification were using hand-crafted actions to rewrite header fields. The Extensible set_field action reuses the OXM encoding defined for matches, and enables to rewrite any header field in a single action (EXT-13). This allows any new match field, including experimenter fields, to be available for rewrite. This makes the specification cleaner and eases cost of introducing new fields.• Deprecate most header rewrite actions• Introduce generic set-field action (EXT-13)• Reuse match TLV structure (OXM) in set-field action3 Extensible context expression in ’packet-in’The packet-in message did include some of the packet context (ingress port), but not all (metadata), preventing the controller from figuring how match did happen in the table and which flow entries would match or not match. Rather than introduce a hard coded field in the packet-in message, the flexible OXM encoding is used to carry packet context.• Reuse match TLV structure (OXM) to describe metadata in packet-in (EXT-6)• Include the ’metadata’ field in packet-in• Move ingress port and physical port from static field to OXM encoding• Allow to optionally include packet header fields in TLV structure4 Extensible Error messages via experimenter error typeAn experimenter error code has been added, enabling experimenter functionality togenerate custom error messages (EXT-2). The format is identical to other experimenter APIs.5 IPv6 support addedBasic support for IPv6 match and header rewrite has been added, via the Flexible match support.• Added support for matching on IPv6 source address, destination address, protocol number, traffic class, ICMPv6 type, ICMPv6 code and IPv6 neighbor discovery header fields (EXT-1)• Added support for matching on IPv6 flow label (EXT-36)6 Simplified behaviour of flow-mod requestThe behaviour of flow-mod request has been simplified (EXT-30).• MODIFY and MODIFY STRICT commands never insert new flows in the table• New flag OFPFF RESET COUNTS to control counter reset• Remove quirky behaviour for cookie field.7 Removed packet parsing specificationThe OpenFlow specification no longer attempts to define how to parse packets (EXT-3). The match fields are only defined logically.• OpenFlow does not mandate how to parse packets• Parsing consistency acheived via OXM pre-requisite8 Controller role change mechanismThe controller role change mechanism is a simple mechanism to support multiple controllers for failover (EXT-39). This scheme is entirely driven by the controllers ; the switch only need to remember the role of each controller to help the controller election mechanism.• Simple mechanism to support multiple controllers for failover• Switches may now connect to multiple controllers in parallel• Enable each controller to change its roles to equal, master or slave9 Other changes• Per-table metadata bitmask capabilities (EXT-34)• Rudimentary group capabilities (EXT-61)• Add hard timeout info in flow-removed messages (OFP-283)• Add ability for controller to detect STP support(OFP-285)• Turn off packet buffering with OFPCML NO BUFFER (EXT-45)• Added ability to query all queues (EXT-15)• Added experimenter queue property (EXT-16)• Added max-rate queue property (EXT-21)• Enable deleting flow in all tables (EXT-10)• Enable switch to check chaining when deleting groups (EXT-12)• Enable controller to disable buffering (EXT-45)• Virtual ports renamed logical ports (EXT-78)• New error messages (EXT-1, EXT-2, EXT-12, EXT-13, EXT-39, EXT-74 and EXT-82) • Include release notes into the specification document• Many other bug fixes, rewording and clarifications3.OpenFlow version 1.3Release date : April 13, 2012Please refers to the bug tracking ID for more details on each change1 Refactor capabilities negotiationPrior versions of the OpenFlow specification included limited expression of the capabilities of an OpenFlow switch. OpenFlow 1.3 include a more flexible framework to express capabilities (EXT-123).The main change is the improved description of table capabilities. Those capabilities have been moved out of the table statistics structure in its own request/reply message, and encoded using a flexible TLV format. This enables the additions of next-table capabilities, table-miss flow entry capabilities and experimenter capabilities.Other changes include renaming the ’stats’ framework into the ’multipart’ framework to reflect the fact that it is now used for both statistics and capabilities, and the move of port descriptions into its own multipart message to enable support of a greater number of ports.List of features for Refactor capabilities negotiation :• Rename ’stats’ framework into the ’multipart’ framework.• Enable ’multipart’ requests (requests spanning multiple messages).• Move port list description to its own multipart request/reply.• Move table capabilities to its own multipart request/reply.• Create flexible property structure to express table capabilities.• Enable to express experimenter capabilities.• Add capabilities for table-miss flow entries.• Add next-table (i.e. goto) capabilities2 More flexible table miss supportPrior versions of the OpenFlow specification included table configuration flags toselect one of three 3 behaviour for handling table-misses (packet not matching any flows in the table). OpenFlow 1.3 replace those limited flags with the table-miss flow entry, a special flow entry describing the behaviour on table miss (EXT-108).The table-miss flow entry uses standard OpenFlow instructions and actions to process table-miss packets, this enables to use the full flexibility of OpenFlow in processing those packets. All previous behaviour expressed by the table-miss config flags can be expressed using the table-miss flow entry. Many new way of handling table-miss, such as processing table-miss with normal, can now trivially be described by the OpenFlow protocol.• Remove table-miss config flags (EXT-108).• Define table-miss flow entry as the all wildcard, lowest priority flow entry (EXT-108).• Mandate support of the table-miss flow entry in every table to process table-miss packets (EXT-108).• Add capabilities to describe the table-miss flow entry (EXT-123).• Change table-miss default to drop packets (EXT-119).3 IPv6 Extension Header handling supportAdd the ability of match the presence of common IPv6 extension headers, and some anomalous conditions in IPv6 extension headers (EXT-38). A new OXM pseudo header field OXM_OF_IPV6_EXTHDR enables to match the following conditions :• Hop-by-hop IPv6 extension header is present.• Router IPv6 extension header is present.• Fragmentation IPv6 extension header is present.• Destination options IPv6 extension headers is present.• Authentication IPv6 extension header is present.• Encrypted Security Payload IPv6 extension header is present.• No Next Header IPv6 extension header is present.• IPv6 extension headers out of preferred order.• Unexpected IPv6 extension header encountered.4 Per flow metersAdd support for per-flow meters (EXT-14). Per-flow meters can be attached to flow entries and can measure and control the rate of packets. One of the main applications of per-flow meters is to rate limit packets sent to the controller.The per-flow meter feature is based on a new flexible meter framework, which includes the ability to describe complex meters through the use of multiple metering bands, metering statistics and capabilities.Currently, only simple rate-limiter meters are defined over this framework. Support for color-aware meters, which support Diff-Serv style operation and are tightly integrated in the pipeline, was postponed to a later release.• Flexible meter framework based on per-flow meters and meter bands.• Meter statistics, including per band statistics.• Enable to attach meters flexibly to flow entries.• Simple rate-limiter support (drop packets).5 Per connection event filteringPrevious version of the specification introduced the ability for a switch to connect to multiple controllers for fault tolerance and load balancing. Per connection event filtering improves the multi-controller support by enabling each controller to filter events from the switch it does not want (EXT-120).A new set of OpenFlow messages enables a controller to configure an event filter on its own connection to the switch. Asynchronous messages can be filtered by type and reason. This event filter comes in addition to other existing mechanisms that enable or disable asynchronous messages, for example the generation of flow-removed events can be configured per flow. Each controller can have a separate filter for the slave role and the master/equal role.• Add asynchronous message filter for each controller connection.• Controller message to set/get the asynchronous message filter.• Set default filter value to match OpenFlow 1.2 behaviour.• Remove OFPC_INVALID_TTL_TO_CONTROLLER config flag.6 Auxiliary connectionsIn previous version of the specification, the channel between the switch and the controller is exclusively made of a single TCP connection, which does not allow to exploit the parallelism available in most switch implementations. OpenFlow 1.3 enables a switch to create auxiliary connections to supplement the main connection between the switch and the controller (EXT-114). Auxiliary connections are mostly useful to carry packet-in and packet-out messages.• Enable switch to create auxiliary connections to the controller.• Mandate that auxiliary connection can not exist when main connection is not alive. • Add auxiliary-id to the protocol to disambiguate the type of connection.• Enable auxiliary connection over UDP and DTLS.7 MPLS BoS matchingA new OXM field OXM_OF_MPLS_BOS has been added to match the Bottom of Stack bit (BoS) from the MPLS header (EXT-85). The BoS bit indicates if other MPLS shim header are in the payload of the present MPLS packet, and matching this bit can help to disambiguate case where the MPLS label is reused across levels of MPLS encapsulation.8 Provider Backbone Bridging taggingAdd support for tagging packet using Provider Backbone Bridging (PBB) encapsulation (EXT-105). This support enables OpenFlow to support various network deployment based on PBB, such as regular PBB and PBB-TE.• Push and Pop operation to add PBB header as a tag.• New OXM field to match I-SID for the PBB header.9 Rework tag orderIn previous version of the specification, the final order of tags in a packet was statically specified. For example, a MPLS shim header was always inserted after all VLAN tags in the packet. OpenFlow 1.3 removes this restriction, the final order of tags in a packet is dictated by the order of the tagging operations, each tagging operation adds its tag in the outermost position (EXT-121).• Remove defined order of tags in packet from the specification.• Tags are now always added in the outermost possible position.• Action-list can add tags in arbitrary order.• Tag order is predefined for tagging in the action-set.10 Tunnel-ID metadataThe logical port abstraction enables OpenFlow to support a wide variety of encapsulations. The tunnel-id metadata OXM_OF_TUNNEL_ID is a new OXM field that expose to the OpenFlow pipeline metadata associated with the logical port, most commonly the demultiplexing field from the encapsulation header (EXT-107).For example, if the logical port perform GRE encapsulation, the tunnel-id field would map to the GRE key field from the GRE header. After decapsulation, OpenFlow would be able to match the GRE key in the tunnel-id match field. Similarly, by setting the tunnel-id, OpenFlow would be able to set the GRE key in an encapsulated packet.11 Cookies in packet-inA cookie field was added to the packet-in message (EXT-7). This field takes its value from the flow the sends the packet to the controller. If the packet was not sent by a flow, this field is set to 0xffffffffffffffff.Having the cookie in the packet-in enables the controller to more efficiently classify packet-in, rather than having to match the packet against the full flow table.12 Duration for statsA duration field was added to most statistics, including port statistics, group statistics, queue statistics and meter statistics (EXT-102). The duration field enables to more accurately calculate packet and byte rate from the counters included in those statistics.13 On demand flow countersNew flow-mod flags have been added to disable packet and byte counters on a per-flow basis. Disabling such counters may improve flow handling performance in the switch.14 Other changes• Fix a bug describing VLAN matching (EXT-145).• Flow entry description now mention priority (EXT-115).• Flow entry description now mention timeout and cookies (EXT-147).• Unavailable counters must now be set to all 1 (EXT-130).• Correctly refer to flow entry instead of rule (EXT-132).• Many other bug fixes, rewording and clarifications.。
open_flow简介
Datapath
一个简单的OF网络实例（三）
Step 2:启用 nox 程序，监听 2525 端口，并运行 python 的 l2 交换组件。
运行NOX程序， controller和 switch连接
一个简单的OF网络实例（四）
Step3：运行交换机上的安全通道，来连接 datapath 和 nox。
包处理流程
从网络中 获取一个 包 可先依照自动 生成树协议处 理（非必须） 和流表的 包头域对 比
NO 转发给 controller处理
是否有匹 配项 YES
相应计数器加 1
按照匹配流表 项中的action 执行
Open Flow协议的消息类型
OF协议支持三种消息类型：controller-to-switch，asynchronous（异步） 和symmetric（对称），每一类消息又有多个子消息类型。 •controller-to-switch 消息由控制器发起，用来管理或获取switch 状态； •asynchronous 消息由switch 发起，用来将网络事件或交换机状态变化 更新到控制器； •symmetric 消息可由交换机或控制器发起。
symmetric 消息
symmetric 消息也不必通过请求建立，包括 Hello、Echo、Vendor 等。 Hello 交换机和控制器用来建立连接。 Echo 交换机和控制器均可以向对方发出 Echo 消息，接收者则需要回复 Echo reply。 该消息 用来测量延迟、是否连接保持等。 Vendor 交换机提供额外的附加信息功能。为未来版本预留。
asynchronous 消息
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、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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转发到一个共同的下一跳）。这种抽象的行为使相同的输出行动非常有效。
组表包含若干组表项，每个组表项包含一系列依赖于组类型的特定含义行动存储段（见5.6.1）。一个或多个行动存储段里的行动会作用到发送到该组的数据包。只要正确的匹配和指令含义保持不变，交换机设计者可以任意的实现内部结构。例如，当一个流表项使用一个所有组来转发至多个端口，交换机设计人员可以在硬件转发表中用一个单一的位掩码去实现。另一个例子是匹配；如果OpenFlow交换机是通过不同数量的硬件表进行物理实现的，那么流水线就会被暴露。
3名词解释本节介绍了关键的OpenFlow规范术语：.字节：一个8位位组。.数据包：以太网帧，包括报头和有效载荷。.端口：数据包进入和退出OpenFlow的流水线地方（见4.1）。可以是一个物理端口，由交换机定义的一个逻辑端口，或由OpenFlow的协议定义的一个保留端口。
.流水线：在一个openflow交换机中提供匹配、转发和数据包修改功能的相连流表的集合。.流表：流水线的一个阶段，包含若干流表项。.流表项：在流表中用于匹配和处理数据包的一个元素。它包含用于匹配数据包的匹配字段、匹配次序的优先级，跟踪数据包的计数器，以及应用的指令集。
.匹配字段：用来匹配数据包的字段，包括包头，进入端口，元数据值。一个匹配字段可能会进行通配符匹配（匹配任何值）或者在某些情况下通过位掩码进行匹配。
.元数据：一个可屏蔽寄存器的值，用于携带信息从一个表到下一个表。.指令：指令存在于流表项中，当数据包匹配流表项时，指令用来描述OpenFlow的处理方式。指令要么改变流水线处理，如指导包匹配另一个流表，要么包含一组添加到行动集的行动，或包含一组立即应用到数据包的行动。
.行动：是一种操作，可将数据包转发到一个端口或修改数据包，如TTL字段减1。行动可以是与流表项相关联的指令集的一部分，或者是与组表项相关联的行动存储段的一部分。我们可以将行动积累在数据包的行动集里，也可以立即将行动应用到该数据包。
行动集：与数据包相关的行动集合，在数据包被每个表处理的时候这些行动可以累加，在指令集指导数据包退出处理流水线的时候这些行动会被执行。
.组：一系列的行动存储段和选择一个或者多个存储段应用到每个数据包的手段。.行动存储段：行动和相关参数的集合，为组而定义的。.标记：一个头部，可以通过压入行动插入到数据包或者通过弹出行动进行移除。.最外层的标记：一个数据包最开始出现的标记。.控制器：与OpenFlow交换机使用OpenFlow协议交互的实体。.计量：一个交换机元件，可以测量和控制数据包的速度。当通过计量的数据包速率或字节速率超过预定义的阈值时，计量触发计量带。如果计量带丢弃该数据包，它则被称为一个限速器。
4OpenFlow端口本节介绍了OpenFlow的端口的概念和OpenFlow支持的各类端口。4.1OpenFlow端口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的额外的元数据字段与它相关联（见7.2.3.7）；而当一个逻辑端口上接收到的分组被发送到控制器时，其逻辑端口和底层的物理端口都要报告给控制器（见7.4.1）。
4.5保留端口OpenFlow的保留端口由本规范定义。它们指定通用的转发动作，如发送到控制器，泛洪，或使用非OpenFlow的方法转发，如“正常”交换机处理。
一个交换机不需支持所有的保留端口，只支持那些标记为“Required”的保留端口。.Required:ALL:表示交换机可转发指定数据包到所有端口，它仅可用作输出端口。在这种情况下，数据包被复制后发送到所有的标准端口，不包括数据包的入端口和端口被配置为OFPPC_NO_FWD。
.Required:CONTROLLER:表示OpenFlow控制器的控制通道，它可以用作一个入端口或作为一个出端口。当用作一个出端口，数据包封装进输入包消息，并使用OpenFlow协议发送（见7.4.1）。当用作一个入口端口，确认数据包来自控制器。
.Required:TABLE:表示openflow流水线的开始（见5.1）。这个端口仅在输出包消息的行动列表里的输出行为时候有效（见7.3.7），此时交换机提交报文给第一流表使数据包可以通过OpenFlow流水线处理。
.Required:INPORT:代表数据包的进入端口。当数据包通过它的入端口发送出去的话，只能用作输出端口。
.Required:ANY:特别值，用在未指定端口的OpenFlow命令（端口通配符）。既不能作为入口端口，也不能作为一个输出端口。
.Optional:LOCAL:表示交换机的本地网络堆栈和管理堆栈。可以用作一个入口端口或作为一个输出端口。远程实体通过本地端口与交换机和网络服务互通，而不是通过一个独立的控制网络。利用一组合适的默认流表项，本地端口被用来实现一个带内控制器连接。.Optional:NORMAL:代表传统的非OpenFlow流水线（见5.1）。仅可用于为一个输出端口，使用普通的流水线处理数据包。如果交换机不能转发数据包从OpenFlow流水线到普通流水线，它必须表明它不支持这一行动。
.Optional:FLOOD:表示使用普通流水线处理进行泛洪（见5.1）。只作为一个输出端口，一般可以将数据包发往所有标准端口，但不能发往入端口或OFPPS_BLOCKED状态的端口。交换机也可以通过数据包的VLANID选择哪些端口泛洪。
OpenFlow-only交换机不支持NORMAL端口和FLOOD端口，而OpenFlow-hybrid交换机均支持上述端口（见5.1）。转发数据包到FLOOD端口依赖交换机的实现和配置，若使用一组all类型进行转发，则可以使控制器能更灵活地实现泛洪（见5.6.1）。
5OpenFlow表本节描述流表和组表的组件，以及匹配和行动处理的机制。
5.1流水线处理OpenFlow兼容的交换机有两种类型：OpenFlow-only和OpenFlow-hybrid。OpenFlow-only交换机只支持OpenFlow操作，在这些交换机中的所有数据包都由OpenFlow流水线处理，否则不能被处理。
OpenFlow-hybrid交换机支持OpenFlow的操作和普通的以太网交换操作，即传统的L2以太网交换、VLAN隔离、L3路由（IPv4的路由，IPv6路由）、ACL和QoS处理。这种交换机必须提供一个OpenFlow外的分类机制，使流量路由到OpenFlow流水线或普通流水线。例如，某个交换机可以使用VLAN标记或数据包的输入端口，来决定是否使用一个流水线或其它流水线，或者它可引导所有数据包都到OpenFlow流水线进行处理。这种分类机制超出了本规范的范围。一个OpenFlow-hybrid交换机也允许数据包通过NORMAL和FLOOD保留端口从OpenFlow流水线转移到普通流水线处理（见4.5）。