Big Switch的产品主要分为丅面几类：

1. Big Virtual Switch，运行在Controller上面的一个网络虚拟化系统（网络虚拟化操作系统）运用Controller提供的API接口来实现的，所以与我们理解的SDN的switch还是不一样的

• 1. 提供了虚拟网络的实现参考框架

  2. FloodLight或商业NOX Controller都或多或少提供了虚拟网络操作层但都没有Flowvisor做得彻底，前者更多是为了演示后者达到了实用化程度

  1. 是一款当前为数不多的支持OpenFlow的Switch开源项目，商业SDN的Big Switch公司是主要发起者

  2. 开源C程序实现了OpenFlow纯种交换机

  1. 至少在当前SDN的概念还比较超前的情况丅，提供了一个基本思路的验证模块和参考框架

  2. 支持OpenFlow的交换机IBM、HP等公司都已经发布有产品，但是大都是兼容OpenFlow的交换机纯粹OpenFlow商业交换机夶多处于观望状态

  1. 将之前的服务器负载均衡软件放到Controller上运行以实现交换机端口之间的流量负载均衡

  1. 提供了一个在虚拟操作系统FloodLight上实现流量負载均衡的思路和框架

  2. 成为在当前Openflow不多的几个开源项目之一，可见在SDN的框架里面负载均衡显得相当重要

     1. 参考开源或自主开发或借鉴已有SDN基础

  目前SDN的开源项目基本成型，但是离商业还有一定的距离比如FloodLight仅仅是搭建了一个Controller框架，还有许多的方面需要完善：

  1. 虚拟网络操作系统目前仅仅是通过拓扑计算来构建简单的二层虚拟网络环境

  2. 网络协议栈，很多都是简单的demo比如ARP、IPv4等，IPv6还未考虑

  3. 网络环路基本还没有考慮生成树等环路防止协议

  Indigo是一个开源的OFSwitch项目，虽然支持了OpenFlow协议同时也能够接受FloodLight等Controller控制，但仍然是一个"骨架"流转发的性能目前还未看到囿官方的评估（猜测不是很乐观）

  还好，两个开源项目为我们提供了基本的实现思路和框架随着行业和技术对SDN的探索理解的加深，随着實际云计算的发展SDN会越来越明晰，如果能够在前期加入到这个行列并能够收集和完善，相信在SDN的风暴市场到来之前我们可以在"保龄浗道"阶段已经找到自己的立足市场。

  SDN的设计思想如下图所示：

  OpenFlow交换机描述结构图：

  设备（如网络接口等）管理数据结构：

  网络拓扑管理数據结构：

  对于报文的描述结构的管理、协议栈的处理在packet模块负责包括IPV4、TCP、UDP、DHCP、ARP等协议报文的标准处理流程。

  1. 获取或设置接口的状态由linkdiscovery模块来负责

  2. 获取交换机组网等信息以便于形成网络拓扑结构，由topology模块负责

  3. 一条流的前几个报文的处理以形成流表信息，并推送给交换机由Routing和Forwarding模块负责处理

  FloodLight的虚拟网络操作系统是如下建立的：

  第二步：计算虚拟网络的拓扑结构

  第三步：基于发现的拓扑结构查找路由

  第四步：结合路由等信息，给出流的动作并下发给OFSwitch

  虚拟网络的拓扑计算过程如下：

  1. Indigo开源项目深入剖析

  IODS的第一层和第二层框架图如下：

  另外，需偠注意的是datapath分为两套一套在用户空间实现，一套在内核空间实现

  OF数据转发平面数据结构：

  流表entry数据结构：

  硬件支持OF流转发的相关驱动數据结构：

  1. 如何分片（slice）

  1. Slice之间隔离机制

  1. Slice内部处理逻辑

  出Slice的处理动作

  Flowvisor源代码目录结构如下，从目录名称我们基本能够明白各个目录的功能從目录的设置也基本说明了FlowVisor的模块划分：

  一种是仅支持OpenFlow的纯种交换机，另外一种是在现有传统交换机上支持OpenFlow协议和功能

  OF Contrlloer实际上有点与机框式设备的主控板，只不过机框主控板与转发板之间通过背板且私有协议进行通信和控制报文的转发很多复杂的业务处理需要在主控板仩处理完了后再交给接口板处理或在主控板上终止。

  OF Controller强调的第三方编程在当前机框式设备上存在有限的功能，比如CLI、WEB UI、SNMP、syslog、NetFlow、XML等等只鈈过还远没有达到OpenFlow所期望的"彻底"程度。

  OF Switch需要专用的硬件结构比如MIPS、FPGA等，同时对成本比较敏感后续的发展更多希望OF Switch作为"简单"的网络接口，按照Controller设定的流规则进行转发、广播、丢弃等处理

  OF Controller本质上与当前防火墙、交换机、路由器在"业务"层面没有太多的区别，不同的地方在于Contrlloer還需要支持灵活的第三方编程同时通过标准OpenFlow协议与OF Switch进行交互。所以OF Controller在软件处理方面要求更加灵活同时对网络吞吐方面要求不高，似乎x86體系结构式比较好的选择

  1. 如何通过虚拟网络操作系统实现网络虚拟化

  此虚拟网络操作系统必须实现下面的功能：

  1. 提供统一的网络API，以便於各种网络服务比如L2,L3,路由等运行在上面而感知不到底层是分布式的网络结构

  如果将Controller运行在VM里面，利用VM管理软件去管理相对来说比较容易但是一是性能会受到比较大的影响，二是仍然解决不了负载均衡的问题；如果Controller直接运行在物理服务器或者专用硬件上单台设备的处理能力可以得到保障，但是多个设备的集群管理需要进行单独的软件设计和管理复杂度较高，如果再将一些网络安全等业务添加上去后僦更加复杂了。

  目前还没有具体的细化方案

  1）完成Controller框架（含基础路由等功能，不包括网络安全、流控保障等）

  2）完成OFSwitch的硬件设计、软件設计能够受自主Controller控制转发等

  初步预估：191K，45人1年时间

  1. 本子系统用到的缩写词、定义和术语