OXP：一种面向SDN移动自组网的东西向协议

杨帆，李呈，黄韬

（北京邮电大学网络与交换技术国家重点实验室，北京 100876）

OXP：一种面向SDN移动自组网的东西向协议

杨帆，李呈，黄韬

（北京邮电大学网络与交换技术国家重点实验室，北京 100876）

在SDN移动自组网络中，有限的控制平面的可拓展性限制了网络规模的发展，而目前的解决方案存在不同控制器间无法直接共存和接口协议效率低下的问题。为解决上述问题，本文设计了高效的、多模式、支持异构控制器协同工作的SDN控制平面东西向协议：开放性可变长协议。实验结果证明，OXP可显著降低通信开销，为SDN移动自组网络提供了高效的东西向协议，提高了SDN移动自组网的可拓展性。

软件定义网络； 控制平面；东西向协议；开放性可变长协议

1 简介

随着软件定义网络技术［1］的普及，基于SDN的移动自组网［2～4］成为研究热点，例如基于SDN的车载移动自组网［5］，军事移动自组网等。在SDN移动自组网中，控制器通过南向协议对数据平面移动设备进行集中管控，不仅可以简化数据层面的转发管理，而且还能提高无线资源利用率。当网络规模增大时，由于控制器的可拓展性不足，单控制器无法满足需求。为管理大规模网络，需要部署协同工作的多控制器，这就对控制器间的通信接口提出了需求。

目前解决多控制器协作问题的解决方案主要有两类：分布式控制器集群和东西向接口协议。对于第一类解决方案，目前主要有ONIX［6］、ONOS［7］等分布式控制器实现。然而分布式控制器的接口均为私有设计，所以彼此之间无法直接共存。对于第二类解决方案，目前主要有SDNi［8］、West-East Bridge［9］等几种实现。然而SDNi提交的草案中并没有详细描述其工作流程，仅定义了基础的概念。West-East Bridge可实现异构控制器之间的协同工作。在West-East Bridge中，当网络视图发生改变时，则需在所有同类节点中同步数据，导致消耗大量带宽，效率低下。然而移动状态下的控制器间的无线链路资源不充足，这对控制器东西向协议的效率提出了严格的要求，而现有的东西向协议无法满足该场景的需求。

针对上述的问题，本文提出了一种面向SDN自组网的、高效的、支持异构控制器的东西向协议：OXP（Open eXchange， 开放性可变长协议）。OXP采用分层的控制平面来解决SDN网络规模受限的问题，其将控制平面分为域间控制层和域内控制层。其中域间控制器负责域间通信，而域内控制器负责域内通信。全网跨域路径计算被划分为域内路径计算和域间路径计算两部分，进而降低了全网路径计算的复杂度。

OXP还设计了网络抽象机制，通过将域内网络抽象成一个逻辑交换机，从而隐藏了域内网络内部的细节。域内控制器仅向域间控制器同步抽象逻辑交换机的信息，而无需同步真实网络拓扑信息。通过网络抽象机制，OXP不仅减少了通信开销，更提高了网络安全性。

此外，为适应复杂多样的网络场景，OXP还设计了高级、简单、 压缩和普通等多种模式。根据不同的网络需求，可将OXP设置在合适模式，从而达到优化的部署效果。例如，对于如移动自组网等链路资源不足的网络环境，可使用OXP的压缩模式，从而减少OXP通道的通信量，使其更满足场景对资源的严格要求。

目前，OXP已经被部署到了C-LAB［10］实验网，并完成了下列两个对比实验：OXP和ONOS［7］开销对比以及基于OXP部署跨域流量工程的对比实验。实验结果证明了（1）OXP支持多控制器协作，可通过设置不同模式去适应复杂多样的网络场景；（2）OXP是ONOS开销的0.044倍，更适合于如移动自组网等链路资源不足的移动自组网络场景；（3）基于OXP可实现跨域业务流量工程部署，可将域间链路利用率提升至99.8%。

2 OXP协议

OXP是一个高效的SDN控制平面东西向协议，其支持异构控制器协同工作、支持多模式、可被部署于链路资源不足的网络环境。OXP采用分层架构，将SDN控制平面分为域间控制器和域内控制器两层。其中域内控制器管理域内网络，而域间控制器管理域间网络，图1为OXP分层架构。

出于效率、隐私性和安全性等方面考虑，在OXP架构中，每个域内网络被抽象成一个逻辑交换机。域内网络仅仅向外界暴露其边缘端口，而隐藏所有内部网络细节。对域间控制器而言，全局网络拓扑仅由抽象逻辑交换机和域间链路组成。

当跨域请求到来时，域内控制器将其发送给域间控制器。域间控制器将基于全局拓扑信息计算跨域路径，并将回复报文发送给转发路径上途径的逻辑交换机（即域内网络）。逻辑交换机收到转发回复报文之后，需将其翻译成对应南向报文并安装到数据层面设备，从而完成跨域路径通信。通过层级化管理的架构，跨域通信的路径计算被分为：域内路径计算和域间路径计算两部分。

为支持多种复杂网络场景，设计了高级、简单、压缩和普通4种主要的模式。当OXP控制通道的链路资源不充足时，可将OXP设置为简单模式，从而减少对链路资源的消耗。反之，则可以将其设置为高级模式，从而换取最佳的跨域路径计算结果。在压缩模式下，业务报文将会被简化成更简单的报文，从而进一步减少通信数据量。因此，压缩模式更适合如移动自组网等链路资源不足的网络。反之，可使用简单模式进行通信，从而保留全部的南向协议编程能力，使得可部署更复杂的跨域业务。

2.1域内控制

图1　OXP架构

在OXP架构中，域内控制器需管理域内网络。每个域内控制器均由唯一的域号来标识。建立OXP通道之后，域内控制器需完成域内网络的抽象工作。此外，域内控制器还需要根据OXP通道的设置，向域间控制器上传特定的拓扑信息和主机信息。

2.1.1网络抽象

网络抽象不仅可以减少OXP的通信开销，还可以提高域内网络的安全性。在OXP架构中，域内网络将被抽象为一个逻辑交换机。网络抽象示意图如图2所示。域内网络的边缘端口映射成逻辑交换机的虚拟端口，而边缘端口之间的域内路径映射成逻辑交换机的端口之间的内部通道。当OXP处于高级模式时，域内控制器需要上传边缘端口之间的内部通道信息，而在简单模式时，则仅需上报边缘端口的信息即可。

2.1.2链路发现

OXP架构中，链路分为域内链路和域间链路两种。域内链路指的是域内网络的边缘外向端口之间的域内路径，而域间链路则是不同域之间的链路。链路能力方面，OXP定义了跳数、带宽和时延3种参数。可基于以上3种参数，进行跨域路径计算。

域内控制器通过发送含有链路号、 端口号、 域号、跨域端口号信息的LLDP报文来发现链路。若某端口收到包含其他域号的LLDP报文，域内控制器则使用唯一的虚拟端口号标记该端口为边缘外向端口。域内控制器需将来自外向端口的LLDP报文上报给域间控制器，用于域间控制器发现域间链路。

2.2域间控制

在OXP架构中，域间控制器管理域间通信。网络管理员可通过域间控制器主动或者被动地部署全局业务。域间控制器需收集逻辑交换机和域间链路的信息，从而构建抽象的全局拓扑。此外，为完成全局业务部署，域间控制器还需收集主机的位置信息。

2.2.1拓扑抽象

为管理跨域通信，域间控制器需要收集全局的抽象拓扑信息。经过网络抽象之后，全局网络被简化为由逻辑交换机和域间链路组成的抽象拓扑。拓扑信息如表1所示，其包含了域内网络和域间网络链路的信息。域内网络包含域号， 域间链路和跨域端口等信息，而域间链路信息则包含了源域号，目的域号和域间链路容量三项数据。当OXP通道为简单模式时，域内网络拓扑信息仅包含域号和跨域端口两种信息及内容。而当OXP通道为高级模式时，则包含表1中的全部信息及其内容。

表1　拓扑抽象

2.2.2主机信息

图2　OXP网络抽象

为了定位目的主机的所属域，域间控制器需收集全部的主机信息，其包括IP地址、MAC地址、掩码和主机状态。当域内控制器发现新主机时，域内控制器不仅会记录其接入位置，还会将其信息同步给域间控制器。域间控制器将按照域号将其存储在相应的数据结构中，方便计算路径时查找。

2.3OXP通道

OXP通道是介于域间控制器和域内控制器之间的通道，其支持简单、高级、压缩和普通等模式。各模式之间的功能差异如表2所示。根据特定的网络场景，可将OXP通道设定为不同的模式。例如，当链路资源不足时，可设置为更加节省带宽的简单模式。而当资源充足时，可置于高级模式，从而换取更优的路径计算结果。

表2　OXP通道工作模式

简单： 在简单模式下，域内控制器不记录域间通路，也不会将其同步到域间控制器。在此模式中，域间控制器仅仅收集基础的网络信息，从而减少了通信数据量，简化了路径计算的流程，进而使得OXP更适用于如移动自组网等链路资源不足的网络场景。

高级： 在高级模式下，域内控制器不仅需要计算域间通路的能力，还需要将其异步上报给域间控制器。在此模式下，域间控制器收集了全局网络信息，从而可以完成最佳的跨域路径计算。但由于同步数据增多，高级模式对链路资源提出了更高的要求。

此外，OXP还为业务信息交换设计了压缩模式和普通两种模式。当链路资源不充足时，可将OXP 通道设置为压缩模式，从而使用简化的报文传递信息，进而降低了通信开销。否则，可直接使用南向协议进行信息交换，从而保留全部的编程能力。

压缩：在压缩模式下，业务报文将被简化为仅携带基本信息的简单报文。比如，转发请求将被简化为仅携带｛源IP地址、目的IP地址、端口、掩码、协议类型，QoS｝的简单报文，而不使用类似于packet_in的南向报文。域间控制器也将回复仅携带 ｛源IP地址、目的IP地址、源跨域端口、目的跨域端口、掩码、协议类型、QoS｝的简单报文。因此，在此模式下同步数据得到了明显的减少，从而显著降低了链路资源的消耗，进而使得OXP可以被部署到对带宽要求非常严格的场景。

普通：在此模式下，业务信息可直接通过南向协议的报文进行传输。出于安全性等方面考虑，域内在发送报文之前，需要将报文的相关字段重写成抽象之后的虚拟数据。由于普通模式下使用南向协议进行通信，所以保留了南向协议的全部编程能力。因此，在此模式下，可通过域间控制器部署更复杂业务。

3 仿真分析

3.1仿真部署

目前，OXP已经在SDN控制器Ryu基础上部署实现。为验证OXP的可行性，本文将OXP部署在C-LAB［10］实验网上，并进行了如下两个实验：（1）OXP与分布式控制器ONOS的通信开销对比实验；（2）基于OXP部署流量工程对比实验。实验拓扑包括由Mininet创建的4个域网络，每个域网络均由5个交换机和10个主机组成，分别由4个域内控制器管理。并部署了域间控制器1台。图3为OXP仿真部署拓扑。

3.2结果分析

3.2.1OXP与分布式控制器ONOS通信开销对比

图3　OXP仿真部署拓扑

此实验在同样网络拓扑上部署了4个ONOS实例去和OXP进行对比。实验记录了拓扑启动阶段和流量生成之阶段的通信开销数据，其实验数据结果如下：在拓扑启动阶段，ONOS的通信开销为1 355.07 kbyte，而OXP多模式平均数据为12.08 kbyte，最小开销4.89 kbyte；在流量产生阶段，ONOS的通信开销为3 937.07 kbyte，而OXP多模式平均为222.23 kbyte，最小开销89.33 kbyte。实验结果证明：在拓扑启动阶段，ONOS的开销平均是OXP的112.22倍。而在流量产生阶段，ONOS平均是OXP的17.72倍， 是OXP最小开销模式的44.07倍。在实验总体通信开销方面，ONOS是OXP平均的22.58倍。拓扑启动阶段的巨大差距主要原因是OXP采用了网络抽象机制，从而减少了大量的域内网络内部信息。而流量产生阶段的差距原因在于OXP的分层架构以及压缩模式等模块的高效设计。此外，大量的心跳包是导致ONOS开销过大的原因之一。由于分布式控制器通信开销过大，所以其无法被部署在链路资源贫乏的网络场景。相比之下，由于OXP高效的设计，更适合于部署在对通信开销要求严格的网络场景。

3.2.2基于OXP的跨域流量工程

本实验完成了基于OXP部署了流量工程，其目的是验证OXP可实现跨域流量优化功能。在实验中，域1启动了5个主机作为Iperf客户端去产生流量，并发送给域 4上的Iperf测试服务器。实验记录了流量传输过程中的跨域链路利用率，其实验结果如图4所示。当没有部署任何流量工程时，数据流仅通过1条跨域路径转发，其域间链路利用率仅为49.8%。相比之下，当部署流量工程时，两个域之间的两条跨域路径均被使用，其跨域路径的链路利用率被提高到了99.8%，从而实现了跨域流量优化。

实验的结果表明OXP不仅可以实现多控制器的协同合作，还降低了通信开销，是一种更高效的解决方案，适用于对开销敏感的网络场景；OXP的多模式设计使得OXP可以被应用于复杂多样的网络场景，甚至是极端恶劣的网络环境；基于OXP可实现跨域业务的部署，完成跨域流量优化。此外，网络管理人员可以通过域间控制器轻易地部署主动的或者被动的跨域业务，从而降低全局网络管理的难度。

图4　跨域流量优化对比

4 结论及未来工作

本文提出了面向SDN移动自组网的支持高效传输、支持异构控制器的东西向协议OXP，描述了OXP协议的设计目的、架构、实验部署和性能分析。OXP通过提供丰富网络的传输模式和网络抽象能力，从而使得OXP可适应复杂多样的网络场景，尤其适合于如移动自组网等链路资源不充裕的网络场景。实验部署和性能对比分析证明了OXP的可行性和高效性。未来计划将OXP部署到如ONOS等其他控制器上。此外，还计划将OXP部署到如CENI等更大型的网络上。

［1］ McKeown N. Keynote talk： Software-defined networking［J］. In Proc. of IEEE INFOCOM， 2009， 17（2）：30-32.

［2］ Yap K K， Kobayashi M， Sherwood R， et al. OpenRoads： Empowering research in mobile networks［J］. ACM SIGCOMM Computer Communication Review， 2010， 40（1）：125-126.

［3］ Murthy C S R， Manoj B S. Wireless networks： Architectures and protocols［M］. London： Pearson education， 2004.

［4］ Baskett P， Shang Y， Zeng W， et al. SDNAN： Software-defined networking in ad hoc networks of smartphones［C］. Las Vegas： Consumer Communications and Networking Conference （CCNC）， 2013：861-862.

［5］ Ku I， Lu Y， Gerla M， et al. Towards software-defined VANET：Architecture and services［C］. Los Angeles： Ad Hoc Networking Workshop （MED-HOC-NET）， 2014 13th Annual Mediterranean IEEE，2014： 103-110.

［6］ Koponen T， Casado M， Gude N， et al. Onix： A Distributed Control Platform for Large-scale Production Networks［C］. Vancouver：Operating Systems Design and Implementation （OSDI）， 2010：1-6.

［7］ Berde P， Gerola M， Hart J， et al. ONOS： towards an open，distributed SDN OS［C］. Chicago： Proceedings of the third workshop on hot topics in software defined networking ACM， 2014：1-6.

［8］ Yin H， Xie H， Tsou T， Lopez D， Aranda P A， Sidi R. SDNi： A message exchange protocol for software defined networks （SDNs） across multiple domains. IETF Internet-Draft， 2012.

［9］ Lin P， Bi J， Chen Z， et al. WE-bridge： West-East Bridge for SDN inter-domain network peering［C］. Toronto： IEEE Conference on Computer Communications Workshops （INFOCOM WKSHPS）， 2014：111-112.

［10］ C-lab test bed ［OL］. Available： http：//www.fnlab.org/.

OXP: An efficient west-east protocol for SDN in Ad hoc

YANG Fan， LI Cheng， HUANG Tao
（State Key Laboratory of Networking and Switching Technology， Beijing University of Posts and Telecommunications，Beijing 100876， China）

The limit scalability of control plane restrict the scale of Software-defi ned Ad Hoc. The current solutions neither coexist with different controllers nor provide hightransmission effi ciency. Thus， we propose an effi cient West-East protocol for software defi ned Ad hoc: Open eXchange protocol（OXP）， which supports heterogeneous controllers to cooperate together. We implemented OXP on the test bed to evaluate the performance. The result shows that OXP is a more effi cient protocol， which is more suitable for SDN in Ad Hoc.

software defi ned network； controller； est-east protocol； OXP

TN929.5

A

1008-5599（2016）09-0032-06

2016-08-23