openflow协议1.3.0中文版

合集下载

OpenFlow协议1.0及1.3版本分析

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下⾯分别介绍以上报⽂信息。

华为 Sx700系列交换机 OpenFlow详版彩页

华为 Sx700系列交换机 OpenFlow详版彩页

华为 Sx700系列交换机OpenFlow详版彩页网络面临的挑战传统网络的架构越来越不能满足市场的需求了。

对大部分企业和组织来说,IT是成本,并不能直接带来业务,特别是这几年,经济不够景气,企业更是减少对IT的投资;与此同时,企业又想方设法提高已有IT设备和人员的利用率,用来提高公司IT支撑能力,进而增进企业的竞争力。

电信运营商也面临着同样的挑战,一方面,无休止的网络扩容以应对移动终端和接入带宽的爆炸性增长,另一方面,企业的利润又被设备投资和维护无情的吞噬,体现在净利润逐年下滑。

具体来说,现有网络架构存在下列问题:网络越来越复杂现在的网络技术很大程度上是由一个个分裂的协议组成,这些协议就是机器之间沟通的“语言”。

利用这些语言,通信设备间无论距离多远,无论什么速率的链路,都可以组成任意的网络拓扑。

为了满足业务和技术的需求,业界各大标准组织,如IEEE、IETF、3GPP等等,制定出各种各样的组网协议用以提高网络带宽、保证通信更可靠、更安全。

大部分情况下,这些协议都是为了解决特定问题的,协议之间相互独立。

日积月累,导致了现在的网络越来越复杂。

在2014年3月的ONS(Open Network Summit)大会上,与会者展示了一个统计,在一个具有16个机架的中小型数据中心,需要人工输入8万行命令,用于配置数据中心纷繁复杂的协议。

以在网络增加或移除一个设备为例,IT人员需要对交换机、路由器、防火墙、Web认证服务器做调整,需要更新ACL、VLAN和QoS等。

与此同时,IT人员所利用工具大多是针对一个个独立的网络设备,而且要充分考虑各厂家交换机的型号、软件版本和当前拓扑。

也正是由于这些复杂性,现在的网络大多是静态的,因为IT人员不想因变动网络而导致业务中断。

“树欲静而风不止”,服务器虚拟化之“风”正急剧地撼动着网络这颗静态的“树”。

一个物理的服务器可以虚拟化成数个或数十个虚拟机(Virtual Machine), 每个虚拟机都可以独立的接入到网络中。

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协议入门

传统网络设备工作方式
Hub • 工作原理:基于物理端口转发 • 策略:Flood
L2Switch • 工作原理:基于MAC地址表转发 • 策略:STP+MAC地址学习
Router • 工作原理:基于路由表转发 • 策略:静态路由+动态路由协议
共同点:分布式策略(策略的制定者为设备本身)
转发表的结构:
dst port)
数据包处理方法: • 转发 • 修改包头
Openflow1.0对数据包匹配特征的描述方法
ofp_match的wildcard
ofp_match的wildcard
22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ‐ 31
终端
终端
终端
终端
终端
终端
终端
终端
终端
终端
Step1:建设计算机网络
终端
终端
终端
终端
终端
终端
终端
终端
终端
终端
计算机网络包括网络设备(节点)和链路(边) 任意两台计算机之间有信号的物理通路
Step2:创建转发表
网络A
终端
终端
终端
终端
B
AC
AB
C
BD
D
BC
B
网络B
终端
网络C
网络D
终端
终端
终端
终端
终端
Step3:建立转发表维护机制
以上每一种操作称为一个动作(Action),流表中的数据包处理方法是一个动 作列表(Action List),动作列表由以上各种动作组合合成。
Action头,包括Type和len字段 Type为一下类型之一

OpenFlow标准 中文版

OpenFlow标准 中文版

I
第 4.2 节 第 4.3 节
4.3.1 4.3.2 4.3.3 4.3.4 第 4.4 节 4.4.1 4.4.2 4.4.3 4.4.4 第 4.5 节 4.5.1 4.5.2 4.5.3 第 4.6 节 4.6.1 4.6.2 4.6.3 第 4.7 节 4.7.1 4.7.2 第 4.8 节
第 2 章 Openflow............................................................
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 节
模型....................................................................................................................... 44 架构....................................................................................................................... 45 组件....................................................................................................................... 45 操作....................................................................................................................... 45 多粒度处理........................................................................................................... 46 开发实现............................................................................................................... 46 安装....................................................................................................................... 47 步骤....................................................................................................................... 47 依赖....................................................................................................................... 48 选项....................................................................................................................... 48 校验....................................................................................................................... 49 应用....................................................................................................................... 49 框架....................................................................................................................... 49 运行与接口........................................................................................................... 50 例程....................................................................................................................... 50 开发....................................................................................................................... 51 组件....................................................................................................................... 51 事件....................................................................................................................... 54 开发例程............................................................................................................... 57

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模拟环境。

可以搭建许多交换机,任意拓扑,搭建拓扑具体教程本博客有一篇。

性能依赖虚拟机的性能。

OPENFLOW协议介绍

OPENFLOW协议介绍

OPENFLOW协议介绍篇一:Openflow协议通信流程解读Openflow协议通信流程解读分类: openflow协议分析 2013-12-30 19:01887人阅读评论(1)收藏举报目录(?)[-] ?controller组成OFPT_FEATURES_REPLY篇二:Openflow及SDN技术简介Openflow及SDN1.网络虚拟化之SDN和OPENFLOW云计算的发展,是以虚拟化技术为基础的。

云计算服务商以按需分配为原则,为客户提供具有高可用性、高扩展性的计算、存储和网络等IT资源。

虚拟化技术将各种物理资源抽象为逻辑上的资源,隐藏了各种物理上的限制,为在更细粒度上对其进行管理和应用提供了可能性。

近些年,计算的虚拟化技术(主要指x86平台的虚拟化)取得了长足的发展;相比较而言,尽管存储和网络的虚拟化也得到了诸多发展,但是还有很多问题亟需解决,在云计算环境中尤其如此。

OpenFlow和SDN尽管不是专门为网络虚拟化而生,但是它们带来的标准化和灵活性却给网络虚拟化的发展带来无限可能。

OpenFlow起源于斯坦福大学的Clean Slate项目组 [1] 。

CleanSlate项目的最终目的是要重新发明英特网,旨在改变设计已略显不合时宜,且难以进化发展的现有网络基础架构。

在2006年,斯坦福的学生Martin Casado领导了一个关于网络安全与管理的项目Ethane[2],该项目试图通过一个集中式的控制器,让网络管理员可以方便地定义基于网络流的安全控制策略,并将这些安全策略应用到各种网络设备中,从而实现对整个网络通讯的安全控制。

受此项目(及Ethane的前续项目Sane[3])启发,Martin和他的导师Nick McKeown教授(时任Clean Slate项目的Faculty Director)发现,如果将Ethane的设计更一般化,将传统网络设备的数据转发(data plane)和路由控制(control plane)两个功能模块相分离,通过集中式的控制器(Controller)以标准化的接口对各种网络设备进行管理和配置,那么这将为网络资源的设计、管理和使用提供更多的可能性,从而更容易推动网络的革新与发展。

OpenFlow白皮书翻译

OpenFlow白皮书翻译

OpenFlow携手校园网创新译者:北邮-李呈Homepage: 摘要本白皮书提出OpenFlow:一种为研究人员提供的可以在日常网络中运行协议的方式。

OpenFlow基于拥有内部流表,并能通过标准接口添加和删除流表项的以太网交换机。

我们的目标是鼓励网络厂商将OpenFlow部署在大学校园骨干网和配线间的交换机产品上。

我们认为,OpenFlow的是一个有意义的折衷:一方面,它使研究人员能够以统一的方式在线速和高端口密度的交换机进行实验。

而另一方面,厂商不必暴露自己的交换机内部工作细节。

除了允许研究者在真实流量环境中评价他们的想法,在提出像GENI那样的大型测试平台的过程中OpenFlow还能是一个有用的校园组件。

不久的将来斯坦福的两栋大楼会在商用以太网交换机和路由器上部署OpenFlow。

我们会鼓励其他学校也部署OpenFlow,而且我们也会鼓励你考虑将OpenFlow部署到你的学校。

分类和主题描述C.2[互联网络]:路由器普通术语实验,设计关键词以太网交换机,虚拟化,流1、可编程网络的需求分析网络已经成为公司,家庭,学校的重要的基础设施。

这个成功对于网路研究者来说以一个福音也是一个诅咒。

他们的工作将更有相关性,但是做出影响的机会也越来越遥远。

在任何给定的网络中对现实世界的影响在减少的原因在于我们安装了大规模的设备和协议,而不愿对产生的流量做实验,这已经给创新设立了一个过高的门槛。

今天,在足够逼真的设置下(例如,大规模引入真实流量),几乎没有实用的方法去做网络新协议的实验(比如新的路由协议,或IP的替代协议),以获得将其广泛部署所需要的信心。

所以导致网络研究界的大部分想法都是没有尝试和测试过的,因此人们普遍认为当今的网络基础设施已经僵化。

意识到问题之后,网络研究一直在努力开发可编程网络,例如研究新的网络架构和分布式系统的全国性网络研究机构提出的GENI。

这些可编程的网络要求程控交换机和路由器(使用虚拟化技术)可以处理数据包的多个相互隔离的实验网络同时进行。

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模拟环境。

可以搭建许多交换机,任意拓扑,搭建拓扑具体教程本博客有⼀篇。

Openflow-未来网络的基础协议(全文)

Openflow-未来网络的基础协议(全文)

Openflow:未来络的基础协议(全文)2008年4月,一篇署名为NickMcKeown的论文《OpenFlow:enablinginnovationincampusnetworks》在ACMCommunicationsReview上发表。

至此,被美国斯坦福大学cleanslate研究组提出将近一年的Openflow向世人揭开了神秘面纱,一种将络转发与控制解耦的新型络交换模型逐渐浮出水面。

两年后,NickMcKeown又提出SDN(SoftwareDefineNetworks,软件定义络)的概念。

它起源于Openflow,也正是它,使Openflow引起业界重视,Openflow甚至在某种程度上成为SDN的代名词。

“SDN 是理念,Openflow是技术。

”盛科络CEO孙建勇一语道破SDN与Openflow之间的区别。

“在可以实现SDN的技术体系中,OpenFlow是相对成熟的技术之一。

”清华大学络研究院络体系结构与IPv6研究室主任毕军又指出了两者之间的关系。

虽然技术相对成熟,但是在追求标准化的IT界,尚未完全标准化的Openflow的标准化之路如何前行?这个过程会对SDN的发展起到什么样的作用?四个版本传统络架构由单独运行、封闭的设备连接构成,每台设备都有单独的操作系统,数据的转发和控制都由交换机和路由器完成,这会造成络的管控细节做得不是特别到位。

各种设备以及其相对孤立的操作系统在络中零散分布,也使络变得复杂且封闭。

此外,由于设备异构,络管理的兼容性也很难做到极致。

Openflow能够很好地解决以上问题。

与当今IT界追捧的“软硬件一体化”不同,SDN试图用软硬件分离的理念颠覆现有的络架构。

Openflow作为新一代络的核心技术,在分离软硬件方面肩负重任。

Openflow交换机以流表的方式进行数据的转发,FlowVisor负责对络进行虚拟化,控制器负责络控制,三者各司其职、分工明确而又相互配合,构成了Openflow的络架构。

SDN软件定义网络之南向协议——OpenFlow协议

SDN软件定义网络之南向协议——OpenFlow协议

SDN软件定义网络之南向协议——OpenFlow协议一、前言SDN(Software-Defined Networking)软件定义网络是一种新兴的网络架构,它将网络控制平面与数据转发平面分离,通过集中式的控制器来实现网络的灵活性和可编程性。

南向协议是SDN架构中控制器与网络设备之间的通信协议,用于控制器向网络设备下发指令,实现网络的配置和管理。

OpenFlow协议是SDN中最常用的南向协议之一,本协议旨在详细描述OpenFlow协议的标准格式和功能。

二、协议版本本协议基于OpenFlow协议的最新版本进行描述,当前版本为OpenFlow 1.5。

三、协议结构OpenFlow协议由多个消息类型组成,每个消息类型都有特定的结构和功能。

以下是OpenFlow协议的主要消息类型:1. Hello消息:用于建立控制器与网络设备之间的连接,并交换协议版本信息。

2. Echo消息:用于测试控制器与网络设备之间的连接状态。

3. Features请求/回复消息:控制器向网络设备请求设备的基本信息,包括支持的OpenFlow协议版本、端口信息等。

4. Configuration请求/回复消息:用于设置或查询网络设备的配置信息,例如流表容量、超时时间等。

5. Packet-In消息:网络设备将无法处理的数据包发送给控制器,请求控制器进行处理。

6. Flow-Removed消息:网络设备上的流表项被删除时发送给控制器,以通知流表项的删除原因。

7. Port-Status消息:网络设备上的端口状态发生变化时发送给控制器,例如端口连接或断开。

8. Barrier请求/回复消息:用于控制器与网络设备之间的同步,确保前一条消息的处理已完成。

9. Flow-Mod消息:控制器向网络设备下发流表项,用于配置数据包的转发行为。

10. Group-Mod消息:控制器向网络设备下发组表项,用于实现组播、多路径等高级功能。

11. Table-Mod消息:控制器向网络设备下发表项,用于配置流表的匹配规则和优先级。

OpenFlow1.3协议总结

OpenFlow1.3协议总结

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)ofp_action_pop_mpls (19)ofp_action_set_field (19)ofp_action_experimenter_header (19) 7.3Controller-to-Switch Messages (19) 7.3.1Handshake (19)ofp_switch_features (20)7.3.2交换机配置 (20)ofp_switch_config (20)7.3.3流表配置 (21)ofp_table_mod (21)7.3.4Modify State Messages (21)ofp_flow_mod (21)ofp_group_mod (23)ofp_bucket: (23)ofp_port_mod (24)ofp_meter_mod (24)ofp_mater_band_header (25)ofp_meter_band_drop (25)ofp_meter_band_dscp_remark (25) ofp_meter_band_experimenter (25) 7.3.5Multipart Messages (25)ofp_multipart_request (26)ofp_multipart_reply (26)ofp_flow_stats_request (27)ofp_flow_stats (28)ofp_aggregate_stats_request (28)ofp_aggregate_stats_reply (28)ofp_table_stats (29)ofp_table_feature (29)ofp_table_feature_prop_type (30)ofp_table_feature_prop_header (30)ofp_table_feature_prop_instructions (30)ofp_table_feature_prop_next_tables (30)ofp_table_feature_prop_actions (30)ofp_table_feature_prop_oxm (31)ofp_table_feature_prop_instructions (31)ofp_port_stats_request (31)ofp_port_stats (32)ofp_port (33)ofp_queue_stats_request (33)ofp_queue_stats (33)ofp_group_stats_request (34)ofp_group_stats (34)ofp_group_desc (34)ofp_group_features (34)ofp_group_feature (35)ofp_meter_multipart_stats (35)ofp_meter_band_stats (35)ofp_meter_multipart_request (35)ofp_meter_config (35)ofp_meter_features (36)ofp_experimenter_multipart_header (37)7.3.6队列配置信息 (37)ofp_queue_get_config_request (37)ofp_queue_get_config_reply (37)7.3.7Packet_Out消息 (37)ofp_packet_out (37)7.3.8Barrier Message (38)7.3.9Role Request Message (38)ofp_role_request (38)7.3.10Set Asynchronous Conguration Message (38) 7.4Asynchronous消息 (39)7.4.1Packet-In Message (39)7.4.2Flow Removed Message (39)7.4.3Port Status Message (40)7.4.4Error Message (41)7.5Symmetric消息 (45)7.5.1Hello (45)7.5.2Echo Request (45)7.5.3Echo Reply (45)7.5.4Experimenter (46)1介绍2交换机组成OpenFlow的交换机包括⼀个或多个流表和⼀组表,执⾏分组查找和转发,和到⼀个外部控制器OpenFlow的信道。

OpenFlow协议基础

OpenFlow协议基础
• OF-CONFIG用于对OpenFlow交换机进行基础配置,以使得 交换机能够与控制器建立数据信道
• OF-CONFIG V1.1.1选用NETCONF作为传输协议
19
OpenFlow的演进
OpenFlow 1.0.0(2009.12)
OpenFlow 1.2(2011.12)
OF-CONFIG 1.1(2013.3)
必选 必选 必选 可选 可选
可选 可选
Output Drop Group Set-Queue Push-Tag Pop-Tag Set-Field Change-TTL
将报文转发到特性的OpenFlow端口 当满足特定条件时报文被丢弃 将报文转由组表处理,动作由组表类型定义 为报文指定队列ID,用于实施QOS 适用于对VLAN头、MPLS头、PBB头进行操 作 识别匹配字段类型并修改字段的值 修改IPv4、IPv6、MPLS中的TTL
Group Identier Group Type Counters Action Buckets
9
Meter表
• Meter表项用于关联流表项,对匹配流表项的报文实施QOS策略
Meter Identifier Meter Bands Counters
Bands Type
Rate
Counters Type Specific arguments
• 异步消息
– 由OpenFlow交换机发起,用来通知交换机上发生的某些异步事件。消息是单向的,不 需要控制器应答。主要用于交换机向控制器通知收到报文、状态变化、出现错误等事件 信息
– 包括Packet-in、Flow-removed、Port-status、Error四种子消息
• Controller-to-switch

OpenFlow1.3协议总结

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)ofp_action_pop_mpls (19)ofp_action_set_field (19)ofp_action_experimenter_header (19)7.3Controller-to-Switch Messages (19)7.3.1Handshake (19)ofp_switch_features (20)7.3.2交换机配置 (20)ofp_switch_config (20)7.3.3流表配置 (21)ofp_table_mod (21)7.3.4Modify State Messages (21)ofp_flow_mod (21)ofp_group_mod (23)ofp_bucket: (23)ofp_port_mod (24)ofp_meter_mod (24)ofp_mater_band_header (25)ofp_meter_band_drop (25)ofp_meter_band_dscp_remark (25)ofp_meter_band_experimenter (25)7.3.5Multipart Messages (25)ofp_multipart_request (26)ofp_multipart_reply (26)ofp_flow_stats_request (27)ofp_flow_stats (28)ofp_aggregate_stats_request (28)ofp_aggregate_stats_reply (28)ofp_table_stats (29)ofp_table_feature (29)ofp_table_feature_prop_type (30)ofp_table_feature_prop_header (30)ofp_table_feature_prop_instructions (30)ofp_table_feature_prop_next_tables (30)ofp_table_feature_prop_actions (30)ofp_table_feature_prop_oxm (31)ofp_table_feature_prop_instructions (31)ofp_port_stats_request (31)ofp_port_stats (32)ofp_port (33)ofp_queue_stats_request (33)ofp_queue_stats (33)ofp_group_stats_request (34)ofp_group_stats (34)ofp_group_desc (34)ofp_group_features (34)ofp_group_feature (35)ofp_meter_multipart_stats (35)ofp_meter_band_stats (35)ofp_meter_multipart_request (35)ofp_meter_config (35)ofp_meter_features (36)ofp_experimenter_multipart_header (37)7.3.6队列配置信息 (37)ofp_queue_get_config_request (37)ofp_queue_get_config_reply (37)7.3.7Packet_Out消息 (37)ofp_packet_out (37)7.3.8Barrier Message (38)7.3.9Role Request Message (38)ofp_role_request (38)7.3.10Set Asynchronous Conguration Message (38)7.4Asynchronous消息 (39)7.4.1Packet-In Message (39)7.4.2Flow Removed Message (39)7.4.3Port Status Message (40)7.4.4Error Message (41)7.5Symmetric消息 (45)7.5.1Hello (45)7.5.2Echo Request (45)7.5.3Echo Reply (45)7.5.4Experimenter (46)1介绍2交换机组成OpenFlow的交换机包括一个或多个流表和一组表,执行分组查找和转发,和到一个外部控制器OpenFlow的信道。

openflow协议1.3.0中文版 完整版

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)。

Openflow版本间差别

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.。

openflow协议通信流程

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 交换机,但是普遍反映价格较贵!性能最好。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

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的处理方式。

指令可以修改流水线处理,如指导包匹配另一个流表,也可以包含一系列添加到行动集的行动,还可以包含一系列立即应用到数据包的行动。

•行动:将数据包转发到一个端口或修改数据包,如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)。

当用作一个入口端口,确认来自控制器的数据包。

• Required: 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。

OpenFlow-only交换机只支持OpenFlow操作,在这些交换机中的所有数据包都由OpenFlow流水线处理,否则不能被处理。

相关文档
最新文档