openflow

主要介绍SDN架构和转发模型 一：传统网络设备 （一）传统设备控制平面和数据平面 （二）数据平面的任务 数据平面对数据包的处理，主要通过查询由控制平面所生成的转发信息表来完成 （三）传统网络数据平面数据包的处理流程 （四）传统网络数据转发处理特点 比如某一设备的数据平面，只能对某几种特定协议的数据包进行解析 功能模块固定，在网络生产时就已经固定。例如： 二：SDN数据平面架构 （一）主要变化 第一：在该SDN数据平面中，包处理流程中的所有模块，包括解析、转发和调度，都是可编程、协议无关的 第二：传统网络设备中的二层或三层转发表被抽象成流表 三：OpenFlow转发模型 （一）SDN数据平面实现的一次尝试 （二）OpenFlow交换机转发模型 在该转发模型中，OpenFlow交换机将传统网络数据平面中的各种查找表抽象成一种通用的流表结构。 同时将数据转发处理，抽象成通用的匹配-动作过程（Match-Action过程） 每个流表可以实现： （三）OpenFlow交换机通用转发模型---代表性和缺点 代表性 OpenFlow交换机转发模型是现有通用可编程数据平面中的代表。目前主流SDN物理交换机和虚拟交换机都实现了对OpenFlow的支持 缺点 无法达到理想的通用可编程转发模型的要求 四：可编程协议无关交换机架构（PISA架构） （一）与OpenFlow相比

本文上周开始写的，一直没有写完，今天临时要给人讲一个逻辑，需要参考，先放出来，后续写完后，读者就不会看到这个提示了。 架构设计这种东西，只能从实例里面学。用抽象的总结描述架构设计的方法，懂的人听了没用，不懂的人听了不知道在说什么。但举真实的例子很难。因为能公开的例子，要不太旧，没有什么意义；要不太新，基本上都会有保密问题。 最近跟论文的时候看了一本书，本周刚看完，感觉完全能解决我前面说的问题，推荐给有兴趣的各位： 这完全是一份5G网络构架设计说明书，如果你需要一个参考，考虑你的架构设计怎么做，把他作为模板来学习就行了。 当然，如果你只能学习形式，不能形而上地考虑逻辑，非要形而下考虑形式。只能学习人家的章节，那当我没说过。 下面做一个阅读赏析。为了讨论的方便，我们把上面这本书，或者架构设计说明书，叫做《5G》。 在讨论前，先说说我的背景，我工作早期（二十多年前吧）做过几个无线系统的平台支持，比如GSM BSC/MSC的主控板的驱动，PDCP的OS平台提供等等，最近几年偶尔也会解决一两个相关产品的操作系统层的问题。所以充其量是对其中的名词术语和要解决的问题“有所耳闻”，对于无线产品设计的细节基本上是个外行。所以我这里并不是讨论5G系统应该如何设计，我也没有能力评判那个设计做得好不好。我是要通过这个设计考虑的逻辑Pattern，作为类比，说明构架设计是怎么建模的。 《5G

#简介# ##mininet是什么？## Stanford 大学 Nick McKeown 教授领导的研究小组基于 Linux Container 架构，开发出了这套进程虚拟化的平台。在 Mininet 的帮助下，你可以轻易的在自己的笔记本上测试一个软件定义网络 （Software-Defined Networks），对基于 Openflow、Open vSwitch 的各种协议等进行开发验证，或者验证自己的想法。 最令人振奋的是，所有的代码几乎可以无缝迁移到真实的硬件环境中。在实验室里，一行命令就可以创建一个支持 SDN 的任意拓扑的网络结构，并可以灵活的进行相关测试，验证了设计的正确后，又可以轻松部署到真实的硬件环境中。目前 Mininet 已经作为官方的演示平台对各个版本的 Openflow 协议进行演示和测试。 ##floodlight是什么？## Floodlight是Apache授权并且基于JAVA开发的企业级OpenFlow控制器，它的稳定性、易用性已经得到SDN专业人士以及爱好者们的一致好评，并因其完全开源，这让SDN网络世界变得更加有活力。控制器作为SDN网络中的重要组成部分，能集中地灵活控制SDN网络，为核心网络及应用创新提供了良好的扩展平台。 简言之，我们通过mininet对SDN网络拓扑进行模拟，在通过floodlight（SDN控制器

流表组成 每条流表规则由一些列字段组成，可以分为** 基础字段 、 匹配字段 和 动作字段 **三部分。 在打印流表时，在流表中还存在一些显示字段，如 duration , idle_age 等，此处把这些字段也暂时归之于基础字段之中. 流表组成部分字段说明 基础字段： cookie=value 流表标识字段，cookie字段有两种书写方式： cookie=value 和 cookie=value/mask 。 mask 中对应位为1时cookie中值相应的位须严格匹配，为0时cookie中值对应的位通配，当 mask 为-1时，必须严格匹配cookie值。 duration=value 流表生效时间，标识流表从下发到现在所持续的时间 table=tableid 流表所属表项，标识流表所属的表，默认为0 priority=priority 标识流表的优先级，范围为0-65535，值越大，优先级越高 n_packets 标识流表匹配包数 n_bytes 标识流表匹配字节数 idle_timeout=sec 流表空闲超时时间，流表会在空闲时间达到给定的时间时被删除。设置为0（默认值）时，流表不会因空闲时间被删除。 hard_timeout=sec 流表可存在的时间。设置此值后，流表会在到达给定时间后被删除。 idle_age=sec 流表空闲时间 hard_age=sec 流表存在时间

SDN的本质就是让用户/应用可以通过软件编程充分控制网络的行为，让网络软件化，进而敏捷化。如SDN一个具体实现技术openflow，使用设备不再仅基于MAC或IP转发数据，openflow可以基于10元组决定数据流向，控制平面解决网络路由优化、安全、策略、QoS、流量工程等问题。SDN是一种新型的可视化网络设计架构，一种网络资源管理和优化使用方式，一种节约资源降低网络成本的技术，一种体现对网络需求增速变慢的技术体现点。 Neutron为什么需要SDN Neutron有很多无法满足部署需求的网络功能场景： 场景一：基于VM网卡或IP的限速、基于路由的限速以及基于租户的限速 至今仍没有完善的解决方案，这些在实际物理网络中部署都是极其常见的功能。有人用Libvirt对虚拟机网卡的inbound average和outbound average做出入方向的限速，但这个方案不是太妥。部署该方案时是通过设置flavor的quota:vif_inbound_average和quota:vif_outbound_average来实现的，会导致对VM的所有网卡都做限制。该方案不仅限制了南北流量，还限制了东西流量。Qos功能不只是限速，还有很多诸如队列调度、流控等方面的Qos需求，当有业务需要时，Neutron却无从提供满足需求的支持。 场景二：网络节点存在的单点故障 至今依然没有完善的解决方案

OVS简介 　　OpenvSwitch ，简称 OVS 是一个虚拟交换软件，主要用于虚拟机 VM 环境，作为一个虚拟交换机，支持 Xen/XenServer, KVM, and VirtualBox 多种虚拟化技术。虽然是虚拟交换机，但是其工作原理与物理交换机类似。在虚拟交换机的实现中，其两端分别连接着物理网卡和多块虚拟网卡，同时虚拟交换机内部会维护一张映射表，根据 MAC 地址寻找对应的虚拟机链路进而完成数据转发。 　　OpenvSwitch 是实现虚拟化网络的重要基础组件，在 OpenStack 中利用 OpenvSwitch 作为底层部件来完成虚拟网络提供和租户网络管理。 OpenvSwitch 可以实现访问控制功能，通过转发规则，可以实现简单的安全行为，包括通过、禁止等。 OVS组件 ovsdb-sever: OVS 的数据库服务器，用来存储虚拟交换机的配置信息。它于 manager 和 ovs-vswitchd 交换信息使用了 OVSDB(JSON-RPC) 的方式。 ovs-vswitchd: OVS 的核心部件，实现 switch 的 daemon ，包括一个支持流交换的 Linux 内核模块；和上层 controller 通信遵从 OPENFLOW 协议，与 ovsdb-server 通信使用 OVSDB 协议，和内核模块通过 netlink 通信，支持多个独立的

流规则组成：每条流规则由一系列字段组成，分为基本字段、条件字段和动作字段三部分 一：基本字段 基本字段包括生效时间duration_sec、所属表项table_id、优先级priority、处理的数据包数n_packets，空闲超时时间idle_timeout等，空闲超时时间idle_timeout以秒为单位，超过设置的空闲超时时间后该流规则将被自动删除，空闲超时时间设置为0表示该流规则永不过期，idle_timeout将不包含于ovs-ofctl dump-flows brname的输出中。 cookie=value 流表标识字段： cookie字段有两种书写方式：cookie=value和cookie=value/mask。mask中对应位为1时cookie中值相应的位须严格匹配，为0时cookie中值对应的位通配，当mask为-1时，必须严格匹配cookie值。 duration=value： 流表生效时间，标识流表从下发到现在所持续的时间 table=tableid： 流表所属表项，标识流表所属的表，默认为0 priority=priority： 标识流表的优先级，范围为0-65535，值越大，优先级越高 n_packets： 标识流表匹配包数 n_bytes： 标识流表匹配字节数 idle_timeout=sec： 流表空闲超时时间，流表会在空闲时间达到给定的时间时被删除

一 文章名称：SDPA: Toward a Stateful Data Plane in Software-Defined Networking 发表时间：2017 期刊来源：IEEE,SIGCOMM 解决问题： 一、OpenFlow仅仅为SDN数据平面提供了单一的“匹配动作”范式，缺少带状态转发功能，这限制了支持高级网络应用的能力。过度地依赖于SDN控制器来维护状态导致两者的扩展性和性能问题。 二、OpenFlow集中在L2/L3层网络传输，控制平面对于带状态数据包处理的支持非常有限，若没有控制器参与，OpenFlow不能够对流状态进行监控。 三、由于在交换机与控制器之间相关联的处理延迟和控制渠道瓶颈,严重地依赖控制器来维持数据包的状态可能会导致两者的可扩展性和性能问题。 四、OpenFow旨在固定功能的交换机上实现预先定义的头字段和使用预先定义的动作处理数据包。头字段和动作不能够扩展灵活性以满足不同的应用需求。限制了SDN数据平面OpenFlow承诺的可编程性和可扩展性 五、P4在数据平面可编程性很强，但是不能支持带状态应用的直接的可编程，也不能为特别的高级带状态应用集中范式或者概念。另外P4缺少能够与数据平面应用相互作用，从而动态发布数据平面的配置的数据平面。 所做贡献： 一、提出一种新颖的带状态结构（SDPA），以支持SDN数据平面带状态应用的直观可编程和高性能处理

一 文章名称：Network Function Virtualization Enablement Within SDN Data Plane 发表时间：2017 期刊来源：IEEE INFOCOM 2017 - IEEE Conference on Computer Communications 解决问题： NFV借助SDN架构来实现，有以下问题： 一、流必须通过连接的NF实体，路由策略将变得不灵活，网络中将产生阻塞点，这是有害并且没有必要的。 二、控制器对于NFs没有完全的可视化，比如，有多少实例存在，实例放在哪，特定实例可以处理的流量。同样的，NFs的控制器仅能得知有限的网络信息。这样的隔离系统结构导致NFs和网络利用不是最优的。 三、NF趋向于改变数据包的状态，这样的改变对于控制器是不可见的。 所做贡献： 一、提出NEWS（NFV Enablement Within SDN Data Plane），这个方法将网络状态维护在中央控制器，同时有机地高效地可扩展地支持NF功能。NEWS扩展当前的SDN架构使NFs作为SDN的一部分。这意味着NF实体和控制协议与SDN是一体的。 实验对比： 三个带状态防火墙携带小文件（1k到9k）下端到端的性能服务。 携带大文件（10M）的三个带状态防火墙端到端的性能服务。 对比NEWS和OVS的连接跟踪实现。 对比NEWS

三、OVN入门 3.1 OVN简介 Open vSwitch（OVS）是一款开源的“虚拟交换机”，控制协议方面它不但支持OpenFlow的所有特性而且扩展了部分OpenFlow的功能；Overlay协议方面它支持GRE, VXLAN, STT, Geneve四种主流Overlay数据包。OVS已经是 数据平面 的事实标准了，很多白盒交换机都兼容它提供的接口；还有一些x86架构的交换机则直接是基于OVS和DPDK的。所以无论“上层”的ODL、ONOS、Neutron如何的翻天覆地的“闹腾”而OVS还是岿然不动（最后流表的执行者还是OVS）。 但是长期一来OVS都缺乏一个统一的网络模型（Neutron虽然花费巨大力气实现一个网络模型但是仅仅适用于OpenStack而无法用于容器更加无法单独使用），于是在2015年OVS社区宣布了一个子项目——Open Virtual Network（OVN）。它旨在为OVS提供一个控制平面，通过一个统一的网络模型为容器、虚拟机提供相同的网络服务。 虽然很多人不愿意承认但是事实上它瞄准的对象是三个——ODL、ONOS、Neutron。我们可以看一下OpenStack中networking-ovn子项目，它是基于OVN实现的“Neutron”旨在替换Neutron的L2、L3功能。对比传统的Neutron的L2、L3的实现代码它的代码量非常少