通信网系列实验（四）——基于匈牙利算法的匹配与测量应用

Ryu与Mininet相关安装与配置详见：

https://blog.csdn.net/haimianxiaojie/article/details/50705288

关于本文内所有完整代码详见：

https://github.com/PPPerry/Ryu_projects中的Hungary部分

本实验所用拓扑结构同系列实验（一）。拓扑代码稍有变化，详见完整代码。

1. 假设网络中有N（N=1000）个流，每个流f都有一个权重值（代表重要性，自己随机生成），假定每个SDN交换机只有20个可用流表项（其它流表项用于转发汇聚流），假如一个流经过了两个交换机A和B，则我们只需要在A或者B处使用单独的流表项对流进行测量，即假如在A点测量则A点需要使用一个单独的流表项（比汇聚表项优先级更高）。现需要从1000个流中选择出权之和最大的流集合来进行测量，并给出每个流的测量点。
   现使用Python编程实现算法解决这个问题。
   首先，编写匈牙利算法的代码。
   根据算法思路，匈牙利算法分成三个部分：找GoodPath，增广匹配，以及确定GoodSet。
   设U,V 是两个需要匹配的点集合，
   lu,lv 分别是U，V对应的顶点代价的集合
   则
   确定GoodSet：
   
   找到GoodPath：
   
   代价关系式：
   
   增广匹配：
   
   算法完整结构：
   
   只需要将一个n*n的矩阵输入，代表边的权重即可。
   接下来，考虑实际问题。
   假设仍使用我们之前的拓扑图，有13个交换机，每个交换机能测量20个流表。
   则最多能测量260个流表，说明大部分流都测量不到。
   假定每个流都按照最短路来路由。
   可以将一个流f看成是二部图A集合中的一个点af，交换机s看成是二部图B集合里面的一个点bs。
   如果流f经过了交换机b, 则二部图af和b
   s间有就有一条边。
   构造1000*1000的权重矩阵，将每个交换机都复制20次。代入匈牙利算法中，就等同于测量20个流表。
   若某个交换机无法测量某个流，则该边权重为0.
   同时，为了保证完美匹配，还要在260个交换机的基础上补足到1000个交换机。补足的交换机的权重都为0。
   构造代码如下：
   
   u为流集合，序号从0-999
   v为交换机集合，序号从0-12（算法中为0-999，通过某种变换得到0-12）
   按照此思路，运行结果如下：（运行可能需要较长时间）
   
   
   计算结果表示；
   有260个流能够被测量；
   第一个数字代表流的序号，第二个数字代表在哪个交换机测量它。
   最终算出，匹配边的总权重为2600
   具体代码见打包中match.py

2. 用Iperf生成流（可以把流的数目变为，100，流表的容量变为5）,然后在mininet中测量选择出的流大小（用request status接口是请求交换机中的流表状态），并给出在什么地方测量
   给出在什么地方测量
   第二部分属于第一部分的拓展和延续。
   根据第一部分的匈牙利算法，我们可以将流的信息（即流的源节点和目的节点，流经过了哪些节点）传入函数，就能得到我们该在哪些交换机测量哪些流的信息。
   为了方便计算，我们将所有流的信息在代码一开始就输入进去进行计算。
   根据这些信息，我们在后续测试时，可以手动iperf这些源节点到目的节点的流，也可以通过其他更为方便的方式（后续进行详细说明）。
   下图为我们手动预置的100个流。
   
   其形式为字典。
   字典的key值是元组，代表流的起始主机和目的主机；
   字典的value值是该流的权重（人为规定）。
   这个权重只是在匈牙利算法中应用，用于计算哪些流的优先级更高，而与mininet和ryu的实际操作无关。
   接下来，向匈牙利算法函数传入相关信息。
   我们仍使用之前的具有13个交换机的拓扑图。如下所示：
   
   总共有13个交换机，每个交换机具有五个测量流表，所以我们将利用算法，算出65个流进行测量。
   除了流的源节点和目的节点之外，我们还需要的信息是，这些流都分别经过了哪些节点。
   在我们的ryu控制器中，我们利用dijkstra算法去配置任意两点之间的路径，即当输入iperf后，我们调用dijkstra()函数，在配置路径的同时，记录路径，将路径作为输入再回到匈牙利算法。
   Dijkstra算法如下：

完成信息的统计后，使用的匈牙利算法如下：

完整的代码见打包中的cal.py。
具体的算法逻辑见注释即本实验的第一部分，有GoodPath的发现与增广匹配，GoodSet的寻找及代价调整等，这里就不再赘述了。
通过这个算法，我们得到并打印了cal_switches。
运行实例如下：

这是只输入了两个流（1,2）和（3,5）的情况。
权重分别为1和2.
第三行即为我们的cal_switches，代表（1,2）在2的第四个流表测，（3,5）在3的第2个流表测。
即一个字典，告诉我们该在哪个switch测某个从src到dst的流。
根据题目要求，再我们给出在什么地方测量之后，下一步，是用Iperf生成流，然后在mininet中测量选择出的流大小。
用iperf生成流
一开始，我的想法就是在mininet的命令行界面，打开xterm，分别启动客户端和服务器，手动输入100个iperf。
但是这样工作量太大了，不太现实。
之后在网上找到了另外一种方案：iperfmulti。
可以直接将我们提前预置的100个流同时由计算机iperf进去。
参考网址如下：SDN实验—Mininet实验（模拟多数据中心带宽实验）
从该实验的第四步开始，
完成上述操作后，就能利用ipermulti进行多次iperf。
只要在net.py中进行相应修改，将我们设置好的100个流直接存入mininet中即可。
net.py中的存入操作如下：

完成配置后，重新编译mininet，输入iperfmulti，可以看到，mininet自动启动了不同流的客户端和服务器。
同时，ryu中也有相应的响应，计算出了该在什么地方测量这些流。
如图所示：

在mininet中测量选择出的流大小
在我们有了流，即测量节点之后，剩下的就是实际测量了。
我们平时所用的流表都是汇聚流表，即传统路由器进行流表汇聚，比如有两个流分别从A和B主机发送到D(10.20.3.1)主机，经过了C交换机，假设他们都采用最短路进行转发，则在C必然会将A和B的流转发到相同的端口，所以在交换机C处只需要使用一个流表项来转发两个流，这个流表项的匹配域为10.20.3.1（即D主机的地址）。所以哪怕有1万个流经过C到D的流，在C处也只需要一个流表，这个就叫做汇聚。但是汇聚以后，流表项统计的就是汇聚流的大小，而不是单个流的大小。
所以，我们需要的是测量流表。
测量流表具有自己的src和dst，并且优先级更高，与汇聚流表相区别。
在DijkstraController里加这么一个函数：

优先级为1000，对dpid的switch添加流表。
这个流表即为测量流表。
在我们的流的路径计算完成后，我们依靠路径和匈牙利算法，在正确的switch上下发流表，即调用该函数。

在正确的switch下发测量流表完成后，经过一定的测量值周期后，我们需要向交换机请求状态信息。
在github上，我找到了ryu中有关交换机请求状态信息的部分。
详细代码见网址：https://github.com/muzixing/ryu/tree/master/ryu/app/network_awareness
截图如下：

上边的图是发请求部分，下边的图是处理响应部分。
结合到我们自己的代码中来：

我们成功的获取到了测量流表的信息，
打印出来了：
1.在何处测量
2.测量的是从哪到哪的流
3.该流经过了多少个包，经过了多少字节数
4.这个测量流表存在了多长时间（以秒为单位）
该统计信息调用了hub.sleep()函数，每隔1s会统计并打印一次。
效果如图：

详细可见代码文件cal.py。