loy的专栏

交换机与控制器如何建立连接，这个问题在一些资料上有过说明，但没有具体细节。这个也让我困惑了几天，今天通过实验验证一番。一、实验环境搭建如下：    1. 两台局域网中相连的电脑：A和B （我的环境，两台电脑在192.168.4.*网络中）    2. A电脑装好从官网下载的Ubantu虚拟系统，内含 mininet，wireshark            启动虚拟机后，查看eth

一、 介绍        这个文档描述了 OpenFlow 交换机的设计需求。我们建议你在阅读此文档之前，先阅读《OpenFlow 白皮书》。《OpenFlow 白皮书》可以通过 Open Networking Foundation website（https://www.opennetworking.org/standards/open-flow）获得。这个说明文档涵盖的内容有：

nox_main.ccApplication_list parse_application_list(int optind, int argc, char** argv) 从NOX启动命令行中获得启动程序的名字以及所带参数，返回（程序名，参数）的列表void hello(const char* program_name)打印NOX版本信息以及编译事件void usage(c

Static_component_context是专门为静态组件生成component context而设计的。Static_component_context功能主要是为component提供一个“工厂”以及回调函数构造函数：Static_component_context::Static_component_context(    const Constructor_cal

部署器包含待部署组件的context，需要的时候可以通过部署器传递给kernel。NOX支持多个部署器，其中可以有动态部署器和静态部署器以及加载Python部件的部署器。构造函数：没有显式定义接口：bool Deployer::deploy(Kernel* kernel, const Component_name& name)将部署器中包含的Component安装，通过调用此方法更

首先这个组件是用来管理网络连接的，在我们使用NOX时，常用的命令就是 “-i ptcp:127.0.0.1:6633”，也即是传到此模块中构造函数中的变量“interface”是“-i ptcp:127.0.0.1:6633”构造函数：Connection_manager::Connection_manager(const Component_context* ctxt, const st

Component_context1.构造函数：Component_context(const Component_name& name, const std::string& config_path)；Component_context对象保存着组件的注册信息，通过“组件名和组件的配置文件”这两个参数来初始化对象注册信息保存在Component_context :: properti

DSO_component_context组件的上下文类，保存组件的运行状态及组件的实例构造函数：DSO_component_context::DSO_component_context(const Component_name& name, const std::string& config_path)构造函数初始化组件的状态与状态对应触发的事件句柄；并将依赖组件列表初始化到【d

event-dispatcher.hhtypedef boost::function Callback回调函数的类型定义static Component* instantiate(const Component_context*, size_t n_threads);生成一个Event-dispatcher对象void post(const Event&);立刻发送一个事件

六、OpenFlow 安全通道（OpenFlow Channel）         OpenFlow 通道是连接每一个交换到控制器的接口。通过这个接口，控制器配置和管理交换机，从交换机接收事件，向交换机发送数据包。        在数据层与 OpenFlow 通道之间，接口是特定实现的，然而 OpenFlow 通道消息（channel messages）必须被 OpenFl

五、OpenFlow 表        这一部分描述了构成流表和组表的组件，同时也包括了流表“匹配”的机制和“动作”处理。5.1 管线处理流程        服从OpenFlow协议的交换机可以分为两大类：一类是 OpenFlow-only 的，另一类的 OpenFlow-hybrid。 OpenFlow-only交换机只支持 OpenFlow 操作，在

一、NOX简介    作为SDN控制器，NOX控制器可以说是遗老级别的了。在早期，NOX对SDN的研究起了巨大的推动作用，是SDN研究领域众人皆知的开源项目。但是后来NOX的开发团队舍弃NOX，重新成立了一个POX控制器项目，对此我有些不解，于是邮件过NOX的项目负责人，他们没有回复我原因，只是说推荐使用POX，NOX将不再维护。或许，python作为POX的开发语言，简单快捷的一大优点有利于

FRESCO：SDN安全控制器框架一、前言SDN（软件定义网络）把网络的控制层与数据层进行分离，它给网络定制提供了完全的灵活性。通过对网络中所有网络设备的集中控制，我们发现它不仅消除了设备配置带来的繁琐工，还让我们对网络体系架构得到新的认识。SDN从一个更高的角度对全网进行统筹管理，新的模式带来良好的体验效果，也催生出很多新的网络应用，成了网络创新的沃土。但是好的东西总会有缺陷，集中控

6 实施注意事项本章所将的东西不同指导现存的应用，提出了一些准则来评估现存的应用，以及在评估中要注意的方面。文章也定义了现在正进行核将要做的一些工作。6.1安全由于SDN固有的特性和实现，SDN的安全需求可能不同于传统的网络。由于它物理应用的原因，集中控制可能把一个单一高价值的资产暴露给攻击者，这和在分布式控制域中的自治的资产不同。因为逻辑上集中控制器虽然看起来像是以分布式的方

4原理和架构构件这节介绍SDN原理，形成SDN架构的功能实体和组织关系，随后详细介绍。 4.1原理ONF从一个较高的视角对SDN进行介绍[1]，一些基本的SDN原理在其中有引证，他们的应用在此有简略的总结，在后续章节中有更详细的介绍。*控制器和数据层的分离原理这个原理要求控制层和数据层可分割，但是也要知道，控制依然能在数据层中被执行。在SDN控制层和NE之间的D-CPI通过

4.4应用层图4.4扩展了图3.3中SDN架构里的SDN application块。SDN原则允许应用在业务和策略允许的前提下指定需要的网络资源和行为。从SDN到应用程序层的接口叫做A-CPI。图4.9显示SDN应用自身就可以支持A-CPI代理，用来为其他应用层次提供查询功能，这将在4.1部分中介绍。应用层中不同层次的应用，根据器所处的层次高低会有不同程度的抽象。注：SDN社区经常把A

5.3提供虚拟网络，非递归式的SDN提供商在第5.2章节，每一个NE都有一个相关的客户agent。它包含着从自身NE中虚拟出来的虚拟资源。概念上的资源是跨度多个物理NEs的，由SDN控制器对其进行扩展。这个章节与5.2章节的主要不同是：这一章节的控制器client可以约定跨越多个物理NEs的虚拟资源；这样，资源在控制器server中是可扩展的。提供商通过在SDN控制器server中定位客户环境

1.适用范围        这个文档描述了SDN架构。文档的目的是为ONF工作组未来的工作做详细指导和说明，同时也可以作为ONF对外交流的一个参考文档。它的姊妹文档（框架文档）描述了ONF想要达到的设计目标。此文档只是从一个较高的角度描述了达到此目标的一些方法。       SDN架构从一个较高的角度出发，给控制器指定了参考点和接口。架构描述了大量SDN控制器和NE（network e

5 控制功能和交互行为在协调（coordination）功能的辅助下，控制（control）功能是SDN的核心。集中讨论这些内容，同样也是以迭代的方式，这部分另外增加了详细的层次，来介绍了4单元所引入的原则和组件。总结协调（管理）功能和控制功能的区别如下：*协调功能执行与向客户分配资源相关的功能，以及根据策略界定这些资源。这些功能出现在单个信任域中。*当一个资源被分配到客户，资源就有效

Kernel是用来管理所有组件的，它可以处理组件间的依赖关系，并且记录组件的安装，以供依赖需要，所以它是全局组件的container接口：Kernel::init(info_file, argc, argv)初始化核心Kernel :: get_instance()Kernel是单例模式，全局只有一个对象存在，通过这个函数取得对象void Kernel :: attach_