基于OpenFlow 网络的路由技术研究
所谓openflow网络指的是相互连接的一组openflow交换机的集合，并且这些交换机全部置于一个openflow controller或一个openflow controller的集群的管理之下。openflow网络的路由服务指的是单纯地将一个数据包（packet）从一个主机（host）送到另一个主机，而不是三层ip路由协议1:1的实现。而主机也即是路由的目的地，可以是物理服务器或虚拟机（vm， virtual machine）。按照sdn的数据平面和控制平面相分离的模式和集中式管理的系统结构，openflow网络的路由完全是由openflow controller根据用户的路由策略（policy）生成并安装到每个openflow交换机的flow table和group table的flow entry和group entry的集合来定义的。因此，本文假设读者朋友对openflow交换机和openflow controller的基本概念有所了解，可参考onf（open network foundation）给出的“openflow switch specification”相关章节。本文的讨论也以此文献给出的定义作为基础。
总体思路 主机和openflow网络的连接方式直接影响openflow网络的路由设置，本文的讨论包括三种最一般的情况：第一，主机和openflow网络的交换机的端口直接相连，这是最简单的情况;第二，主机通过二层网络接入openflow网络;第三，主机途径多个ip子网最终通过路由器和openflow网络相连，主机接入的网络以及中间经过的网络都是传统的ip网络，使用传统的路由协议，如ospf或bgp。为了叙述的方便，第一种连接方式和第二种连接方式下的主机看做openflow网络的内部主机，而第三种连接方式下的主机看做openflow网络的外部主机。所谓“外部”，这是因为openflow网络无法直接“感知”到主机的存在。如图1所示。主机a与边缘交换机（edge switch）es1的端口3连接（第一种方式），主机b通过二层链路网络（1.1.1.0/24）和边缘交换机es2的端口2连接（第二种方式），主机 c连入外部的ip网络（3.3.3.0/24），路由器r是openflow内部主机和外部主机通信的中介（第三种方式），和边缘交换机es3的端口2连接。
实现openflow路由服务总的思路是：获取主机的信息及其接入openflow网络的信息，计算主机之间的路径，对于路径上的每个交换机，通过下发的openflow消息，改变它的flow table和group table来定义其转发行为，最终实现主机到主机的路由和通信。这些基本上都是openflow controller或在它之上的网络应用的功能。下文的讨论将不加区分的统统视为openflow controller的功能。
主机和接入 为了实现主机之间的路由与通信，openflow controller必须首先获取主机的相关信息。对于openflow网络的内部主机，需要获取的信息包括：主机的ip地址，接入openflow网络的边缘交换机及端口，以及主机的mac地址。除了人工静态配置之外，网络的orchestration系统可提供主机的ip地址和接入到openflow 网络的交换机及其端口，网络的orchestration系统管理服务器和虚拟机在网络上的部署。比如，在云计算的数据中心，网络管理员可以通过 openstack这样的orchestration系统为客户定制ip子网。这样，ip子网中每个主机的ip地址和相连接的交换机及其端口的数据通过 openstack的插件传递给controller。而主机的mac地址就需借助于arp来动态获取。假设有一个发往主机a的数据包，但不知道主机a的mac地址。此时，controller可通过packet_out消息令边缘交换机es1向端口3发送一个arp请求，交换机es1接收到主机a的回复报文后，因为它的flow table中没有和arp报文匹配的flow entry，所以，缺省地，es1将这个arp回复报文打包成packet_in消息，发送给openflow controller。openflow controller解析这个报文，即可得到主机a的mac地址。
对于openflow网络的外部主机，openflow controller必须知道：和openflow网络直接相连的路由器的ip地址和mac地址，连接路由器的openflow网络的边缘交换机和端口，外部主机所在子网的ip地址（prefix）和掩码。路由器的ip地址和mac地址，以及接入openflow网络的边缘交换机和端口可按照上文描述的方式得到。而获取外部主机的ip子网的地址和掩码的功能则是由虚拟路由器（virtual router）来完成的。如图1所示，主机c所在的子网的ip地址和掩码（3.3.3.0/24）经过传统的分布式ip路由系统最终传递给路由器r。通过 in band或out of band的方式，r和虚拟路由器事先建立了会话，如bgp会话，并交换路由可达信息。于是，虚拟路由器得到3.3.3.0/24的可达信息后，最终递交给 openflow controller。有一些开源的程序可用来实现虚拟路由器，如xorp、quagga、exabgp等。一般地，虚拟路由器和外部的路由器的会话使用 bgp协议。关于虚拟路由器的细节不是本文讨论的重点。
拓扑和路径 控制平面和数据平面的分离，形成以openflow controller为中心的集中的控制平台。openflow网络中所有的交换机都在openflow controller的监管之下，于是，openflow controller就有机会掌握全局的网络拓扑视图以及每个交换机的状态。这样，openflow controller就能够更聪明地按照用户的路由策略来及时调整每个交换机的转发行为，从而更容易的实现如流量工程（traffic engineering）和快速故障恢复（fail over）这样的高级功能。这也是sdn的优势之所在。
一般地，openflow controller借助lldp（link layer discovery protocol）协议发现openflow交换机之间的连接状态。lldp协议广泛地用于网络设备广播自己的id，能力（capabilities）和邻居。lldp具有专用的mac广播地址和ethertype，这样，openflow controller可以轻而易举的识别lldp报文。网络拓扑的发现由openflow controller发起，openflow controller推送给每个openflow交换机一个packet_out消息，指示交换机向所有的端口发出lldp报文。与此同时，收到lldp 报文的交换机也会向它的所有的端口发送lldp报文。然而，收到lldp报文的交换机的flow table中没有和lldp报文匹配的flow entry。因此，它就把收到的lldp报文封装为packet_in消息发送给openflow controller。openfow controller分析这些lldp的报文，就能够知道交换机之间谁和谁通过哪个端口连接在一起。最终，openflow controller得到网络的完整的拓扑结构。
在openflow网络的路由服务中，发现拓扑的目的是为了计算从一个边缘交换机到另一个边缘交换机之间的路径。为了讨论的方便，我们假设路由服务仅使用最短路径（shortest path）的策略。尽管这是最简单的情况，但可以举一反三地灵活运用这里给出的基本的原理和方法，实现更高级的更有价值的网络路由策略。网络的拓扑表现在数据结构上，就是一个图（graph）。众所周知，给定一个像网络拓扑的那样的图，计算两点之间的最短路径的算法就是大名鼎鼎的dijkstra’s algorithm。对于图中一个源节点，该算法可一次计算出到达所有其他节点的最短路径。算法的细节请参考wikipedia的文档：http://en.wikipedia.org/wiki/dijkstra’s_algorithm。两点之间的最短路径也许并非只有一条，可能存在多条，我对此算法稍作扩展，能够计算出两点之间的所有最短路径。我的另一篇博客给出了这一扩展算法的c++实现，可直接编译运行。得到多条最短路径，就可以实现类似于ecmp的流量均衡（traffic ba lance）的路由策略。
对应于这种的情况，openflow controller使用dijkstra’s algorithm得到主机a到主机b经过openflow网络中的路径如下，其中的数字代表入端口或出端口。
path（a， b）： （3， es1， 1） -》 （1， es2， 2）
同样地，主机a到主机c和主机c到主机b的路径如下：
path（a， c）： （3， es1， 2） -》 （2， sw0， 1） -》 （1， es3， 2）
path（c， b）：（2， es3， 1） -》 （1， sw0， 3） -》 （3， es2， 2）
当然，相反方向路径如path（b， c）、path（c， a）和path（b， a）的计算自然也不在话下。
转发和路由 有了主机和接入到边缘交换机的信息，也能够算出边缘交换机到边缘交换机的路径。实现路由服务的最后一步是openflow controller向连接主机或子网的路径上的每个openflow交换机下发flow entries，改变交换机的转发行为，以达到主机间通信的目的。如对于连接从主机a到主机b的路径path（a， b），下发到es1和es2的flow entry分别是：
switch es1：
match： src_ip = 2.2.2.2/32， dst_ip = 1.1.1.0/24， in_port = 3
action： out_port = 1 switch es2：
match：
src_ip = 2.2.2.2/32， dst_ip = 1.1.1.0/24， in_port = 1
action： out_port = 2; eth_dst = 00:00:00:00:00:01
这样，从主机a发往主机b的一个ip数据包就可以依次经过交换机es1和es2到达网络1.1.1.0/24。请注意，下发给交换机es2的flow entry的action中，将把匹配到的数据包的目的mac地址eth_dst更新为主机b的mac地址。这样，数据包才会被二层（ethernet） 网络正确地转发到主机b。否则，数据包将被丢弃。
同样地，内部主机a到外部主机c的路由可由下面的flow entry来定义：
switch es1：
match： src_ip = 2.2.2.2/32， dst_ip = 3.3.3.0/24， in_port = 3
action： out_port = 2
switch sw0：
match： src_ip = 2.2.2.2/32， dst_ip = 3.3.3.0/24， in_port = 2
action： out_port = 1
switch es3：
match： src_ip = 2.2.2.2/32， dst_ip = 3.3.3.0/24， in_port = 1
action： out_port = 2; eth_dst = 00:00:00:00:00:03
不难发现，openflow网络把发往外部主机的数据包只送到相关的路由器，如上面例子中的路由器r。剩下的路由就交给外部的网络了，因为外部网络超出了openflow controller的控制范围。
最好，再看一个相反方向的从外部主机c到内部主机b的路由的实现：
switch es3：
match： src_ip = 3.3.3.0/24， dst_ip = 1.1.1.0/24， in_port = 2
action： out_port = 1
switch sw0：
match： src_ip = 3.3.3.0/24， dst_ip = 1.1.1.0/24， in_port = 1
action： out_port = 3
switch es2：
match： src_ip = 3.3.3.0/24， dst_ip = 1.1.1.0/24， in_port = 3
action： out_port = 2; eth_dst = 00:00:00:00:00:01
需要指出的是，上文给出的下发到openflow交换机的flow entries只是openflow controller实现路由服务的一种可能的方案，这里只是用来示例。而不同的openflow controller下发的flow entries会有所不同，但基本的原理应是大同小异。
我想，openflow网络的路由服务的主要优点在于实现的灵活性，可根据实际的需求做具体的定制，而不受限于已有的路由协议标准和硬件基础设施的制约。正是有了sdn数据平面和管理平面的分隔，这种网络可编程的（programable）灵活性才可能成为现实。
通信设备自动测试系统案例
疫情期间空调到底能不能开
Xilinx XCAU15P FPGA开发板参数
全面讲解锂离子电池的的原理、配方和工艺流程
太阳能LED路灯的电源系统设计
基于OpenFlow 网络的路由技术研究
苹果神速升级更新ios10.3.1，老用户表示相当贴心
探究PC104的某型航空发动机排气温度测试系统
高工系统集成商汇第一批会员入会仪式顺利举行
锂电池外观检测机重要性的简单说明
诺基亚Nokia 3310成功复活，只支持2G网络，还是比iPhone 8受欢迎！
电子线束是什么_电子线束的重要性
CS5080(5V USB输入、双节锂电池串联应用、升压充电管理IC)
国辰机器人：打造地下管廊巡检机器人，为地下管廊“健康扫描”
Java运行时内存区域与硬件内存的关系1
高通V2X开发平台构成
韩国5G套餐价格和服务范围虽饱受诟病，但在全球5G国家中排名第二
企业物联网项目成功指南
四节干电池串联电流是多少安
Allegro又与全球领先的半导体代工厂商联华电子签署长期协议
总体思路 主机和openflow网络的连接方式直接影响openflow网络的路由设置，本文的讨论包括三种最一般的情况：第一，主机和openflow网络的交换机的端口直接相连，这是最简单的情况;第二，主机通过二层网络接入openflow网络;第三，主机途径多个ip子网最终通过路由器和openflow网络相连，主机接入的网络以及中间经过的网络都是传统的ip网络，使用传统的路由协议，如ospf或bgp。为了叙述的方便，第一种连接方式和第二种连接方式下的主机看做openflow网络的内部主机，而第三种连接方式下的主机看做openflow网络的外部主机。所谓“外部”，这是因为openflow网络无法直接“感知”到主机的存在。如图1所示。主机a与边缘交换机（edge switch）es1的端口3连接（第一种方式），主机b通过二层链路网络（1.1.1.0/24）和边缘交换机es2的端口2连接（第二种方式），主机 c连入外部的ip网络（3.3.3.0/24），路由器r是openflow内部主机和外部主机通信的中介（第三种方式），和边缘交换机es3的端口2连接。
实现openflow路由服务总的思路是：获取主机的信息及其接入openflow网络的信息，计算主机之间的路径，对于路径上的每个交换机，通过下发的openflow消息，改变它的flow table和group table来定义其转发行为，最终实现主机到主机的路由和通信。这些基本上都是openflow controller或在它之上的网络应用的功能。下文的讨论将不加区分的统统视为openflow controller的功能。
主机和接入 为了实现主机之间的路由与通信，openflow controller必须首先获取主机的相关信息。对于openflow网络的内部主机，需要获取的信息包括：主机的ip地址，接入openflow网络的边缘交换机及端口，以及主机的mac地址。除了人工静态配置之外，网络的orchestration系统可提供主机的ip地址和接入到openflow 网络的交换机及其端口，网络的orchestration系统管理服务器和虚拟机在网络上的部署。比如，在云计算的数据中心，网络管理员可以通过 openstack这样的orchestration系统为客户定制ip子网。这样，ip子网中每个主机的ip地址和相连接的交换机及其端口的数据通过 openstack的插件传递给controller。而主机的mac地址就需借助于arp来动态获取。假设有一个发往主机a的数据包，但不知道主机a的mac地址。此时，controller可通过packet_out消息令边缘交换机es1向端口3发送一个arp请求，交换机es1接收到主机a的回复报文后，因为它的flow table中没有和arp报文匹配的flow entry，所以，缺省地，es1将这个arp回复报文打包成packet_in消息，发送给openflow controller。openflow controller解析这个报文，即可得到主机a的mac地址。
对于openflow网络的外部主机，openflow controller必须知道：和openflow网络直接相连的路由器的ip地址和mac地址，连接路由器的openflow网络的边缘交换机和端口，外部主机所在子网的ip地址（prefix）和掩码。路由器的ip地址和mac地址，以及接入openflow网络的边缘交换机和端口可按照上文描述的方式得到。而获取外部主机的ip子网的地址和掩码的功能则是由虚拟路由器（virtual router）来完成的。如图1所示，主机c所在的子网的ip地址和掩码（3.3.3.0/24）经过传统的分布式ip路由系统最终传递给路由器r。通过 in band或out of band的方式，r和虚拟路由器事先建立了会话，如bgp会话，并交换路由可达信息。于是，虚拟路由器得到3.3.3.0/24的可达信息后，最终递交给 openflow controller。有一些开源的程序可用来实现虚拟路由器，如xorp、quagga、exabgp等。一般地，虚拟路由器和外部的路由器的会话使用 bgp协议。关于虚拟路由器的细节不是本文讨论的重点。
拓扑和路径 控制平面和数据平面的分离，形成以openflow controller为中心的集中的控制平台。openflow网络中所有的交换机都在openflow controller的监管之下，于是，openflow controller就有机会掌握全局的网络拓扑视图以及每个交换机的状态。这样，openflow controller就能够更聪明地按照用户的路由策略来及时调整每个交换机的转发行为，从而更容易的实现如流量工程（traffic engineering）和快速故障恢复（fail over）这样的高级功能。这也是sdn的优势之所在。
一般地，openflow controller借助lldp（link layer discovery protocol）协议发现openflow交换机之间的连接状态。lldp协议广泛地用于网络设备广播自己的id，能力（capabilities）和邻居。lldp具有专用的mac广播地址和ethertype，这样，openflow controller可以轻而易举的识别lldp报文。网络拓扑的发现由openflow controller发起，openflow controller推送给每个openflow交换机一个packet_out消息，指示交换机向所有的端口发出lldp报文。与此同时，收到lldp 报文的交换机也会向它的所有的端口发送lldp报文。然而，收到lldp报文的交换机的flow table中没有和lldp报文匹配的flow entry。因此，它就把收到的lldp报文封装为packet_in消息发送给openflow controller。openfow controller分析这些lldp的报文，就能够知道交换机之间谁和谁通过哪个端口连接在一起。最终，openflow controller得到网络的完整的拓扑结构。
在openflow网络的路由服务中，发现拓扑的目的是为了计算从一个边缘交换机到另一个边缘交换机之间的路径。为了讨论的方便，我们假设路由服务仅使用最短路径（shortest path）的策略。尽管这是最简单的情况，但可以举一反三地灵活运用这里给出的基本的原理和方法，实现更高级的更有价值的网络路由策略。网络的拓扑表现在数据结构上，就是一个图（graph）。众所周知，给定一个像网络拓扑的那样的图，计算两点之间的最短路径的算法就是大名鼎鼎的dijkstra’s algorithm。对于图中一个源节点，该算法可一次计算出到达所有其他节点的最短路径。算法的细节请参考wikipedia的文档：http://en.wikipedia.org/wiki/dijkstra’s_algorithm。两点之间的最短路径也许并非只有一条，可能存在多条，我对此算法稍作扩展，能够计算出两点之间的所有最短路径。我的另一篇博客给出了这一扩展算法的c++实现，可直接编译运行。得到多条最短路径，就可以实现类似于ecmp的流量均衡（traffic ba lance）的路由策略。
对应于这种的情况，openflow controller使用dijkstra’s algorithm得到主机a到主机b经过openflow网络中的路径如下，其中的数字代表入端口或出端口。
path（a， b）： （3， es1， 1） -》 （1， es2， 2）
同样地，主机a到主机c和主机c到主机b的路径如下：
path（a， c）： （3， es1， 2） -》 （2， sw0， 1） -》 （1， es3， 2）
path（c， b）：（2， es3， 1） -》 （1， sw0， 3） -》 （3， es2， 2）
当然，相反方向路径如path（b， c）、path（c， a）和path（b， a）的计算自然也不在话下。
转发和路由 有了主机和接入到边缘交换机的信息，也能够算出边缘交换机到边缘交换机的路径。实现路由服务的最后一步是openflow controller向连接主机或子网的路径上的每个openflow交换机下发flow entries，改变交换机的转发行为，以达到主机间通信的目的。如对于连接从主机a到主机b的路径path（a， b），下发到es1和es2的flow entry分别是：
switch es1：
match： src_ip = 2.2.2.2/32， dst_ip = 1.1.1.0/24， in_port = 3
action： out_port = 1 switch es2：
match：
src_ip = 2.2.2.2/32， dst_ip = 1.1.1.0/24， in_port = 1
action： out_port = 2; eth_dst = 00:00:00:00:00:01
这样，从主机a发往主机b的一个ip数据包就可以依次经过交换机es1和es2到达网络1.1.1.0/24。请注意，下发给交换机es2的flow entry的action中，将把匹配到的数据包的目的mac地址eth_dst更新为主机b的mac地址。这样，数据包才会被二层（ethernet） 网络正确地转发到主机b。否则，数据包将被丢弃。
同样地，内部主机a到外部主机c的路由可由下面的flow entry来定义：
switch es1：
match： src_ip = 2.2.2.2/32， dst_ip = 3.3.3.0/24， in_port = 3
action： out_port = 2
switch sw0：
match： src_ip = 2.2.2.2/32， dst_ip = 3.3.3.0/24， in_port = 2
action： out_port = 1
switch es3：
match： src_ip = 2.2.2.2/32， dst_ip = 3.3.3.0/24， in_port = 1
action： out_port = 2; eth_dst = 00:00:00:00:00:03
不难发现，openflow网络把发往外部主机的数据包只送到相关的路由器，如上面例子中的路由器r。剩下的路由就交给外部的网络了，因为外部网络超出了openflow controller的控制范围。
最好，再看一个相反方向的从外部主机c到内部主机b的路由的实现：
switch es3：
match： src_ip = 3.3.3.0/24， dst_ip = 1.1.1.0/24， in_port = 2
action： out_port = 1
switch sw0：
match： src_ip = 3.3.3.0/24， dst_ip = 1.1.1.0/24， in_port = 1
action： out_port = 3
switch es2：
match： src_ip = 3.3.3.0/24， dst_ip = 1.1.1.0/24， in_port = 3
action： out_port = 2; eth_dst = 00:00:00:00:00:01
需要指出的是，上文给出的下发到openflow交换机的flow entries只是openflow controller实现路由服务的一种可能的方案，这里只是用来示例。而不同的openflow controller下发的flow entries会有所不同，但基本的原理应是大同小异。
我想，openflow网络的路由服务的主要优点在于实现的灵活性，可根据实际的需求做具体的定制，而不受限于已有的路由协议标准和硬件基础设施的制约。正是有了sdn数据平面和管理平面的分隔，这种网络可编程的（programable）灵活性才可能成为现实。
通信设备自动测试系统案例
疫情期间空调到底能不能开
Xilinx XCAU15P FPGA开发板参数
全面讲解锂离子电池的的原理、配方和工艺流程
太阳能LED路灯的电源系统设计
基于OpenFlow 网络的路由技术研究
苹果神速升级更新ios10.3.1，老用户表示相当贴心
探究PC104的某型航空发动机排气温度测试系统
高工系统集成商汇第一批会员入会仪式顺利举行
锂电池外观检测机重要性的简单说明
诺基亚Nokia 3310成功复活，只支持2G网络，还是比iPhone 8受欢迎！
电子线束是什么_电子线束的重要性
CS5080(5V USB输入、双节锂电池串联应用、升压充电管理IC)
国辰机器人：打造地下管廊巡检机器人，为地下管廊“健康扫描”
Java运行时内存区域与硬件内存的关系1
高通V2X开发平台构成
韩国5G套餐价格和服务范围虽饱受诟病，但在全球5G国家中排名第二
企业物联网项目成功指南
四节干电池串联电流是多少安
Allegro又与全球领先的半导体代工厂商联华电子签署长期协议