最近做实验，发现ryu的拓扑发现性能不高，因此阅读了ryu拓扑发现源码，查阅了相关论文，改进了ryu的拓扑发现性能，改写了代码，并且重新做了实验，发现改进的拓扑发现模块能力有所增强，但是还是有局限性，现在先对前面的工作做个总结，以后有时间了继续改进。
一.LLDP拓扑发现原理
传统网络中的链路发现协议为LLDP（Link Layer Discovery Protocol），LLDP允许局域网中的结点告诉其他结点他自己的capabilities和neighbours。在传统以太网交换机中，交换机从自己的每个端口发送LLDP数据包，他不会被其他交换机转发，寿命只有一跳，LLDP负载被封装在以太网帧中，结构如下图，其中深灰色的即为LLDP负载，Chassis ID TLV, Port ID TLV和Time to live TLV三个是强制字段，分别代表交换机标识符（在局域网中是独一无二的），端口号和TTL。这个数据发出并被邻居结点收到之后进行解析，就可以知道这条链路的源目的交换机以及源目的接口。
二. ryu拓扑发现原理
OpenFlow的官方没有规定标准的拓扑发现方法，现在的OFDP（OpenFlow Discovery Protocol）利用的仍然是传统网络中的链路发现协议LLDP，接下来介绍ryu如何利用LLDP发现拓扑，假设现在有两个OpenFlow交换机连接在控制器上，如下图，简述拓扑发现步骤（以S1作为主体，S2的类似）：
- SDN控制器构造PacketOut消息向S1的三个端口分别发送上图所示的LLDP数据包，其中将Chassis ID TLV和Port ID TLV分别置为S1的dpid和端口号
- 控制器向交换机S1中下发流表，流表规则为：将从Controller端口收到的LLDP数据包从他的对应端口发送出去
- 控制器向交换机S2中下发流表，流表规则为：将从非Controller接收到LLDP数据包发送给控制器
- 控制器通过解析LLDP数据包，得到链路的源交换机，源接口，通过收到的PacketIn消息知道目的交换机和目的接口
三. 存在的问题与改进空间
现在的ryu发现拓扑是对整个数据平面的所有交换机的所有端口发送PacketOut数据包，对于Fattree等网络来说，端口的数量是交换机数量的k倍，因此导致了很多资源的消耗，我用小服务器跑单纯的拓扑链路发现功能，会经常宕机或者发现的拓扑不完全，同时如果消息太多会引起broken pipe的问题，所以是否可以对这个拓扑发现的机制进行改进，让发送的PacketOut消息和交换机的数量相同？
四. 改进后的ryu拓扑发现机理
为了实现在三中所提到的逻辑改进，需要将LLDP负载中的Port ID TLV进行改进，或者有其他的域和Port ID TLV一一映射也可以，这里提供一种解决办法，在LLDP数据包从交换机端口转发出去的时候，将这个以太网数据包的源MAC地址替换成为这个端口的MAC地址，而控制器在早先的配置阶段已经获得了关于交换机的端口的所有信息，所以对控制器来说，MAC地址和交换机的端口号是一一对应的，下面详细讲述改进方案。
- 更新控制器的LLDP PacketOut消息数量，由一个端口一个，改为一个交换机一个PacketOut消息，LLDP数据包负载中的域Port ID TLV值置为零
- 控制器向流表下发一条规则：所有从端口Controller接收到的LLDP消息被Flood到除了控制器所有的其他端口，同时将以太网数据帧的源MAC地址设置为对应的端口的MAC地址
- 更新控制器的PacketIn消息处理机制，根据LLDP数据包的来源，可以得到目的交换机，目的端口，通过解析LLDP数据包，得到源MAC和源交换机，通过源MAC地址查找对应的端口号
- 由于是修改的代码，所以不要忘了删除原来的以端口主导的相关代码
添加的主要变量和类做一简介
- self.switches：是个字典，存储dpid到SwithData的映射
- SwitchData类：包含了时间戳以及交换机所包含的LLDP数据
- SwitchDataState：类似于PortDataState类，继承自字典，保存从Switch类到SwitchData类的映射，维护了一个类似双向链表的数据结构
修改了源switches.py文件，修改后的见github:https://github.com/cotyb/enhancement-ryu/tree/master/ryu%20topology%20enhancement，经过实验发现拓扑发现能力有所增强，但是性能什么的还是有待继续提高，以后有时间了继续改进
参考：Ef?cient Topology Discovery in SDN