标签:
最近做实验,发现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的类似):
三. 存在的问题与改进空间
现在的ryu发现拓扑是对整个数据平面的所有交换机的所有端口发送PacketOut数据包,对于Fattree等网络来说,端口的数量是交换机数量的k倍,因此导致了很多资源的消耗,我用小服务器跑单纯的拓扑链路发现功能,会经常宕机或者发现的拓扑不完全,同时如果消息太多会引起broken pipe的问题,所以是否可以对这个拓扑发现的机制进行改进,让发送的PacketOut消息和交换机的数量相同?
四. 改进后的ryu拓扑发现机理
为了实现在三中所提到的逻辑改进,需要将LLDP负载中的Port ID TLV进行改进,或者有其他的域和Port ID TLV一一映射也可以,这里提供一种解决办法,在LLDP数据包从交换机端口转发出去的时候,将这个以太网数据包的源MAC地址替换成为这个端口的MAC地址,而控制器在早先的配置阶段已经获得了关于交换机的端口的所有信息,所以对控制器来说,MAC地址和交换机的端口号是一一对应的,下面详细讲述改进方案。
添加的主要变量和类做一简介
修改了源switches.py文件,修改后的见github:https://github.com/cotyb/enhancement-ryu/tree/master/ryu%20topology%20enhancement,经过实验发现拓扑发现能力有所增强,但是性能什么的还是有待继续提高,以后有时间了继续改进
参考:Ef?cient Topology Discovery in SDN
标签:
原文地址:http://www.cnblogs.com/cotyb/p/5024183.html