传统网络要靠后了，新型网络来了，SDN真的来了，SDN介绍（三）

admin

前面我们说到，SDN凭借着转控分离的网络架构，解决了很多传统网络中难以解决的难题，但是问题来了，这种架构怎么实现呢？我们的控制中心如何获取实时路况，并且下发命令给各个交警呢？
我们的革命者们同时也开发了一个新的协议：openflow，该协议用于调度中心和交警之间进行沟通，并指导转发器进行转发。具体来说，openflow需要解决以下3个问题：
1：建立调度中心和交警之间的沟通通道
首先，调度中心和交警之间需要有一条顺畅并且安全的沟通通道，所以openflow协议规定了控制器和转发器之间必须要有一条三层可达的链路，通过该链路建立TCP连接，并采用了安全的算法进行加密（比如TLS）。同时，链路需要通过定时的Hello进行保活，保证链路出现问题时能及时发现。
2：从交警那里收集各个路口的路况
由于是统一管理，每个路口的性能指标需要规范化，比如路口一共有几条分叉路口（端口），每条路有多宽，能承担多少车流量（带宽），每条路是不是有事故导致通行不畅（链路故障），每条路目前的车流量大小（链路占用率）以及路口的调度能力（设备表项大小）等。这些数据必须以统一的格式上传调度中心。同时，如果哪个路口修了新的路，也需要将上述指标主动上报给调度中心。
这部分内容很好实现，只需要定义一个标准的消息格式即可。
3：告诉交警如何指挥车辆
前面我们说过，交警只需要听从调度中心的命令即可，但是如果针对每一辆车调度中心都要给交警下发一个指令未免也太效率低下了。于是革命者们想了一个法子，让调度中心给每个交警一张表，这张表的内容简单来说就是：

交警们收到这张表，就直接根据车辆信息直接进行指挥，同时记录下每种车辆的数量用于统计本路口的指标。这样一来，就不用每辆车都需要调度中心直接下命令，交警直接可以自己进行指挥。
可以看到，这张表无疑就是整个openflow协议的核心，我们称之为流表。
在openflow协议提出之初，革命者们的初衷很简单，传统网络中各种各样的转发协议太复杂了，我们就根据流量本身的属性，针对每种流量在定义一个动作，这种方式无疑会大大简化设备上的转发流程，于是在openflow1.0版本中，流表是长这样的：

在匹配域中装着车辆的各种信息，在最初的想法中，革命者是想通过一个可扩展的数据结构使流表可以匹配任何数量和种类的车辆信息（比如TLV架构）。
可是理想很丰满，现实很骨感，openflow1.0推出后，遇到了一系列的阻碍，其中最主要的两个问题就是转发效率和成本的问题，怎么回事呢？
原来现在交通指挥已经智能化了，交警们拿到这张表以后，首先会把这张表存到一个智能终端（转发芯片），指挥交通时，直接使用智能终端进行指挥，这台智能终端主要的成本就在存储流表的存储器（TCAM）上。以前，需要储存的表都比较小，如路由表仅包含目的IP、下一跳、出接口等几项。而这次的新表要求能匹配任意的车辆信息。
我们举个例子：如果交警仅关注车辆从哪里来（SIP），和到哪里去（DIP），假设车辆可能会从A、B、C三个地方来，可能会到a、b、c三个地方去。则我们需要几条表项呢？我想表应该是这样的：

我需要9条表项就可以包含所有的车辆情况（Aa、Ab、Ac、Ba、Bb、Bc、Ca、Cb、Cc），而如果现在交警还需要关注车辆所属的城市（假设车辆可能来自m城市或者n城市），那么简单算一下，我们就需要18条表项来包含所有的车辆情况（Aam、Abm、Acm、Bam、Bbm、Bcm、Cam、Cbm、Ccm、Aan、Abn、Acn、Ban、Bbn、Bcn、Can、Cbn、Ccn）
可以看到，随着需要匹配的字段数量的增加，表项数目会指数级的增加。这无疑增加了需要的存储器大小，交警查看这些表项的时间也会增加，从而导致了成本增高以及转发效率的降低。
为了解决这个问题，革命者在openflow1.1版本中，引入了多表的机制。还是以上面例子继续说，刚才我们说假设车辆可能会从A、B、C三个地方来，可能会到a、b、c三个地方去则需要9条表项，我们现在把这个表分成两个表：、

表二：

先匹配表一：车辆从哪里来，再去匹配表二：车辆要去哪里。可以看到，表一加上表二已经可以包含所有车辆的情况，但是表项的数量却减少为6条，表项数量从乘法关系变成了加法关系。
这样无疑大幅减少了流表的大小，表项数量的减少同时也降低了交警查表所需要的时间。一举解决了成本和查表效率的问题。
在后续的openflow1.2、openflow1.3和openflow1.4版本中，革命者们还做了一系列优化，包括增加了大量可以匹配的车辆信息，同时也增加了调度中心的数量，保证在一个调度中心故障的情况下交警依然可以从其他调度中心获得指令等。

声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。