sdn

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却无从提供满足需求的支持。 场景二：网络节点存在的单点故障 至今依然没有完善的解决方案

2014-12-03 by muzi Docker image = Java class Docker container = Java object 前言 5月份的时候，当我还是一个大学生的时候，有个网友问我，你有研究Docker吗？当时我连Docker是什么都不知道。谷歌之后，对Docker产生兴趣，但是一直没有时间去学习。这个周终于将这个学习计划列入了Todolist。所以我花了3天时间，认真地把这 《Docker 从入门到实践》 看完并实践了一遍，收获颇丰。虽然我的导师以及我自己还是觉得我在瞎转，而且我觉得没有方向的日子很痛苦。所以只好自己做计划，学习点新知识，打打基础了。本篇内容主要介绍什么是Docker、Docker简单入门以及如何使用Docker部署SDN环境，以及docker的网络配置等内容。What is Docker和Why Docker部分摘自《Docker从入门到实践》。 What is Docker Docker 是一个开源项目，诞生于 2013 年初，最初是 dotCloud 公司内部的一个业余项目。它基于 Google 公司推出的 Go 语言实现。 项目后来加入了 Linux 基金会，遵从了 Apache 2.0 协议，项目代码在 GitHub 上进行维护。Redhat 已经在其 RHEL6.5 中集中支持 Docker；Google 也在其 PaaS

3 月，跳不动了？>>> 据分析机构最新数据，因数据中心对市场产生的带动作用影响，2019年第四季度的NAND Flash的总出货量季增近10%，市场逐渐出现供不应求现象。经历了一段降价期，NAND Flash存储器终于迎来一小段上升期。随着5G通信和AI技术的发展，数据中心将继续增长。2020年中国新增数据中心市场容量将占全球新增量的50%左右。 2020年更多创新技术及成熟技术将在数据中心中被广泛采用。服务器芯片 NAND FLASH 也出现供不应求现象。5G通信和人工智能的发展，数据中心将进一步进行加强新型服务于终端用户。在数据中心供应商已经看到了转型的必要性。2020年的5G等先进技术将首次应用于数据中心，而机器学习及其他AI技术的应用也将创造新的学习和工作方式，以此最大限度地提高员工生产力。这便意味着在新的一年中，数据中心的供应商将有更多的机会发展和增强其现有业务，尽管要充分利用这些技术优势，至少还需要几年时间。 数据中心建设也面临一些压力，对于数据中心来说联网危机是最大的压力之一。数据中心网络流量爆炸性增长，大量计算资源浪费于联网，目前80%以上的云服务器节点不提供接入，数据中心联网卸载确实很难实现。 2019年第四季度西部数据的出货量季增长24%，NAND Flash营收达18.38亿美元，较上季度增长12.6%。美光第四季度的出货量增长近15%

一 文章名称：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

安全相关论文--Security and Dependability 所参考的文献来自于Kreutz D, Ramos F M V, Esteves Verissimo P, et al. Software-Defined Networking: A Comprehensive Survey[J]. Proceedings of the IEEE, 2015, 103(1):10-13. 一些论文 安全性和可靠性： 【access control, firewalling,middleboxes as middlepipes 】27 100 326 328 337 DoS attacks detection and mitigation， traffic anomaly detection 325 336 random host mutation 326 331 flow rule prioritization, security services composition, protection against traffic overload,and protection against malicious administrators 199 201 259 322 330 使用SDN来改善网络安全： security policies enforcement [100]

问题4：流表匹配 OF1.1版本 这是OF1.1版本的操作，引入了多流表，1.0版本并没有多流表。 多流表的匹配称为 流水线处理 ：交换机从流表0开始查找，按照流表序号从小到大匹配。 每个包按照优先级去匹配流表中的表项，优先级高的先进行匹配；一旦匹配成功则刷新计数器和执行动作，倘若没有找到匹配的表项则转发给控制器。 OF1.3版本及之后版本 关键词：叠加执行 OF1.3版本的流表匹配相比OF1.1版本，改变了很多： (1)当匹配到流表项的时候，首先更新计数器，然后查看指令集(之前有提过，指令是从动作层抽象出来的层次，便于管理动作)，由指令决定动作是立即执行，或者是添加到地址集中；然后查看指令集中是否有 Goto-Table 选项，有的话继续查找下一个表，没有的话执行动作集中的动作。 (2)没有匹配到流表项的时候，查看表内是否有 Table-miss 选项，有的话也查看它的指令集，如果没有直接丢弃。 一个简单的流程：匹配到流表项 -> 看指令集，更新计数器 -> 动作马上执行/加入动作集 -> 查找下一个表/执行动作集； 没有匹配到流表项 -> 有没有 Table-miss 表项 -> 有，查看指令集，接下来和前面的内容类似 / 没有，丢弃。 1.3及之后的流表匹配，除了多流表操作之外，引入了 Table-miss 和 Action-set动作集 的处理。 之前的版本

OpenDaylight作为一款开源SDN网络控制器，依托于强大的社区支持以及功能特性，成为了目前主流的SDN网络控制器开发平台。在比较稳定的OpenDaylight Helium版本中，已经为开发者提供了大量的网络管理功能与二次开发接口。但是由于OpenDaylight架构复杂以及开发工具的多样化，造成了二次开发思路不够清晰的问题。本文旨在为读者梳理出一条比较清晰的OpenDaylight二次开发路线，降低OpenDaylight的二次开发难度。 一、 OpenDaylight架构简析 要想清晰的看到OpenDaylight为我们提供了什么，最直观的方式就是对OpenDaylight架构图进行梳理，如图1： 图1 如大家所知道的那样，OpenDaylight的结构层次从下到上依次划分为数据平面（包括物理交换设备与虚拟交换设备等）、南向接口与协议插件、控制平面（包括核心控制部分与相关服务）、上层网络应用与服务。数据平面设备的相关技术开发已经超出了OpenDaylight二次开发范畴，因此我们的目光限定在南向协议与插件、控制器服务与上层应用的开发。总体来说，OpenDaylight的二次开发可以分为以下三个层面： 基于OpenDaylight REST APIs的上层网络应用开发 基于SAL内核相关服务的控制器组件与上层网络应用开发

原文链接：https://blog.csdn.net/weixin_43265596/article/details/89787232 一、SDN概述 1.1 SDN概念 SDN是一种将网络控制功能与转发功能分离、实现控制可编程的新兴网络架构。这种架构将从控制层从网络设备转移到外部计算设备，使得底层的基础设施对于应用和网络服务而言是透明的、抽象的，网络可被视为一个逻辑的或虚拟的实体。 1.2 SDN产生的原因 传统网络及其设备的只可配置、不可编程 网络的分布式控制与管理架构带来的制约 二、SDN架构 2.1 SDN的基本架构 SDN采用了集中式的控制平面和分布式的转发平面，两个平面相互分离，控制平面利用控制—转发通信接口对转发平面上的网络设备进行集中式控制，并提供灵活的可编程能力，具备以上特点的网络架构都可以被认为是一种广义的SDN。 在 SDN 架构中，控制平面通过控制—转发通信接口对网络设备进行集中控制，这部分控制信令的流量发生在控制器与网络设备之间，独立于终端间通信产生的数据流量，网络设备通过接收控制信令生成转发表，并据此决定数据流量的处理，不再需要使用复杂的分布式网络协议来进行数据转发，如下图所示。 SDN 并不是某一种具体的网络协议，而是一种网络体系框架，这种框架中可以包含多种接口协议。如使用OpenFlow等南向接口协议实现SDN 控制器与 SDN 交换机的交互