本文将简要介绍OpenFlow协议的伴侣协议即补充协议OF-CONFIG，主要内容包括OF-CONFIG的简介、原理以及发展趋势。希望能让读者对OF-CONFIG有一个初步的认识。

简介

在OpenFlow协议的规范中，控制器需要和已配置的交换机进行通信。而交换机在正常工作之前需要对其特性以及资源进行配置才能正常工作。而这些配置超出了OpenFlow协议规范的范围，理应由其他的配置协议来完成。OF-Config（OpenFlow Management and Configuration Protocol）协议就是一种OpenFlow交换机配置协议。OF-CONFIG由ONF于2012年1月提出，目前已经演化到1.2版本。OF-CONFIG协议与OpenFlow协议的关系如图1所示。

作为一种交换机配置协议，OF-CONFIG的主要功能包括配置交换机连接的多个控制器信息、端口和队列等资源的配置以及端口等资源的状态修改等内容。此外，作为一个配置协议，OF-CONFIG也要求链接必须是安全可靠的。为满足实际网络运维要求，OF-CONFIG支持通过配置点对多个交换机进行配置，也支持多个配置点对同一个交换机进行配置。

为了满足OpenFlow版本更新的需求以及协议的可拓展要求，OF-CONFIG采用XML来描述其数据结构。此外，在OF-CONFIG的初始规范中也规定了采用NETCONF协议作为其传输协议。由于OF-Config协议没有和数据交换和路由等模块直接相关，所以相比于对实时性要求高的OpenFlow等南向协议而言，OF-CONFIG协议对实时性要求并不高。

原理

OF-Config协议主要分为Server和Client两部分，其中Server运行在OpenFlow交换机端，而Client运行在OpenFlow配置点上。本质上，OpenFlow配置点就是一个普通的通信节点，其可以是独立的服务器，也可以是部署了控制器的服务器。通过OpenFlow ...

年轻的人，总是梦想着乘上远航的船，去追逐远方的未来。扬帆启航之前的等待，他都在认真地等风来。

两年之前，我踏上了自己选择的路，满心充满的是欢喜和感恩，感谢世界给我的幸运和关爱。一年之前，我站在十字路口，对未来感到彷徨，却有坚定信念。一转眼，一年又过去了，我站在港口，打包行囊，望着远方等风来。

造船的日子

过去一年的时间，是按计划造船的时间。学习生活上都按照计划进行地不错。专业学习上计划进行顺利，计划之外也收获一些惊喜。

CIIP

CIIP并不是我计划上的内容，但是当它出现的时候，我知道它成为我的计划了。大三的时候，悉尼大学的网友就和我交流过这个事情，他说他要去参加CIIP。我谷歌了一下，原来是思科的国际实习生计划。当时特别想去，没想到两年之后，我也有机会。对待CIIP申请的事，我超出常态的谨慎和认真，这得益于那次失败的SDN大赛。

在SDN第二届大赛之前，我一直是一个很自信的人，做什么事都觉得肯定能行。但是不幸的是初赛的文档得分不高，仅拿到了15名左右的成绩，没有办法进入决赛。作为一个长期混迹于各个技术QQ群的我而言，我知道从此之后我再也不能随意露面，随意发言了。因为比我厉害的人还有好多，而我连决赛都进不了 ...

SDN作为一种新的网络架构，正被应用到越来越多的网络场景中。而网络的关键在于通信，如何使得SDN网络正常运行，并且能够和传统网络相互通信是SDN组网需要解决的基本问题。本文将介绍SDN组网相关解决方案中的数据平面到控制平面的组网解决方案、多SDN域组网解决方案和SDN网络与传统网络组网通信的解决方案。

SDN数据平面到控制平面组网

目前为止，在数据层面到控制到控制平面之间的组网方案主要有两大类：带外组网和带内(in-band)组网。

• 带外（out-band）组网:

  数据平面到控制平面的控制数据通过专门的控制网络，而不经过数据平面转发，从而将数据平面的数据和控制平面数据隔离运行在两张独立的网络中。在带外组网方案中，每个交换机都有连接到控制平面的专属线路，而无需通过其他数据平面交换机转发。带外组网可以减少组网的难度和运维的难度。缺点是交换机多时，链路数量较多。

• 带内（in-band）组网

  带内组网指的是控制数据和数据平面数据可以共享一个物理链路。即数据平面的有些交换机直连控制器，而其他的交换机的需要经过数据平面的链路才能到达控制器。非直交换机的控制数据需要通过数据平面的链路进行转发，并通过直连交换机转发到控制器。此种组网方式可以减少许多交换机到控制器的链路数量，但是配置带内组网比较麻烦，可靠性较低，维护成本也相对要高。

  图2. in-band组网方案

多SDN域组网方案

当网络规模过大时，需要部署多域的组网方案。其中每个SDN域都由各自的控制平面控制。多域组网方案有水平架构和垂直架构两种。水平架构形式的多域组网方案中，域控制平面之间的关系是对等的。而在垂直架构中，则划分为域控制器层和超级控制器层 ...

为了更好地管理和运行网络，非常有必要收集网络资源及其状态信息。在很多网络场景中，SDN控制器的决策都取决时延，带宽和拓扑等网络状态。在开发SDN应用的过程中，笔者总结了一些有用的网络状态测量的解决方案，可以为初学者在解决网络问题时提供一些启发。本文将主要介绍如何通过SDN控制器和OpenFlow协议来测量和收集网络中的时延、带宽以及拓扑状态等信息。

时延

时延的测试在终端会显得很容易，但是在交换机节点上测试时延就比较麻烦。在SDN中，可以通过一下步骤实现交换机之间链路的时延。

（1）控制器向交换机A下发一个Packet_out报文。报文的数据段携带了任意一个约定好的协议报文，其报文的数据段携带了控制器下发报文时的时间戳。Packet_out报文的动作指示交换机将其泛洪或者转发到某端口。

（2）交换机B收到了交换机A发送过来的数据包，无法匹配对应流表项，从而packet_in到控制器。控制器接收到这个数据包之后，和当下时间相减，得到时间差T1。其时间差约等于数据包从控制器到交换机A + 交换机A到交换机B + 交换机B到控制器的时延。

（3）同理，控制器向交换机B发送一个类似的报文。然后控制器从交换机A收到Packet_in报文，记录下时间差T2。所以T1+T2=控制器到交换机A的RTT+控制器到交换机B的RTT+交换机A到交换机B的时延RTT。

（4）控制器向交换机A和交换机B分别发送带有时间戳的Echo request。交换机收到之后即刻回复携带echo request时间戳的echo reply消息。所以控制器可以通过Echo reply的时间戳减去Echo reply携带的时间，从而得到对应交换机和控制器之间的RTT ...

Software Defined Networking是一种控制平面和数据平面分离的可编程的网络架构，目前已经有许多商业落地案例。在部署SDN时，往往会因SDN控制器性能不足而限制了SDN的可拓展性。因此SDN网络的规模往往不大。针对此问题，笔者在研究相关文献之后，总结了相关的解决方案，并通过本文来记录和分享。

解决方案

SDN分离了网络的控制平面和数据平面，而控制平面是SDN的大脑，其能力极大地影响着SDN网络的可拓展性。所以基本上，解决方案都是围绕如何给控制平面减压或者提升控制平面的能力来实现。根据控制器数目的不同，解决方案可以分为如下两类：

• 单控制器节点的性能拓展
• 部署多控制器系统

单控制器节点的性能拓展

单控制器节点的性能拓展是最常见的方式之一，包括控制器采用多线程，负载下放等解决方案。多线程等解决方案属于软件开发范畴，不属于本文讨论范围。通过负载下放（offload）等方式可以降低网络对控制平面的依赖，减少控制平面的负载和压力，从而可以管理更多的交换机，进而提升SDN网络的可拓展性。DIFANE和DoveFlow就是典型的代表。

DIFANE[1]是DIstributed Flow Architecture for Networked Enterprises的缩写。 在DIFANE架构中，其数据平面的所有数据均由数据平面完成，而控制器仅负责策略的计算，而不会直接响应Packet_in。其通过减轻控制平面的负载的方式，从而增强了SDN的可拓展性。