一种基于SDN的多管理域路由机制

张 俊，沈苏彬

(南京邮电大学 计算机学院，江苏 南京 210003)

1 概 述

互联网的蓬勃发展，驱动着网络应用的不断创新与丰富，从高清视频会议到健康监测，以及一些远程控制系统，如森林防火系统等，对于网络延迟、带宽和可用性等方面都有着严格的要求。并且随着互联网规模的不断扩大，在多数情况下，应用流都需要进行跨域传输，这将会给IP骨干网带来艰巨的挑战。然而，目前针对多管理域场景，域间路由信息交互的协议大多采用BGP[1]，该协议的分布式部署，虽然满足了可扩展性和可靠性，但是由于缺乏集中控制，使得策略表达及配置相对比较困难。同时，由于在选路过程中缺乏域间协商，各管理域域内的局部最优路由算法无法保证全局最优，使得应用流的QoS需求在目前这种“尽力而为”的网络传输中难以得到保障，从而造成用户的QoE下降。

为了改善网络性能，以及保障应用的QoS约束与终端用户的QoE，学术界和工业界提出了一些解决方法。对于单个管理域，有IntServ[2]、DiffServ[3]、MPLS[4]等；对于多个管理域，有BandwidthBrokers[5]等。互联网中对于服务质量保证的问题，根据现有网络状态进行约束路径计算是一个关键组成部分，然而在当今互联网分布式体系中却难以实现。并且，现有网络协议的多样化，以及每个路由器为了保证E2E流量工程和应用业务QoS所需承载的计算量，使得当前网络中的路由器工作过于繁忙，不利于未来网络的持续发展与创新。

针对传统网络所呈现的相关问题，SDN(software defined networking)[6-7]作为一种新型网架构与技术应运而生。其突出特点包括：

(1)转控分离：解耦传统网络设备的控制平面与转发平面，转发平面只具备数据流量转发的能力，控制平面通过南向控制协议(如OpenFlow、NetConf、OVSDB等)控制转发平面的流量行为。

(2)集中管控：控制器拥有全局网络信息，如拓扑和网络资源等。网络管理员能够根据这些信息完成资源的合理分配与调度，解决负载均衡、网络资源分配不均等问题，简化网络管理。

(3)网络可编程：通过控制器北向接口(如REST API)，应用平面告知控制平面如何进行网络资源管理才能更好地满足应用约束。并且，因特网服务提供商能够调用开放的北向接口，实现网络服务的定制，加快业务的动态部署。

OpenFlow[8-9]作为SDN网络架构的一种实现方式，由斯坦福大学提出，其规范由ONF(开放网络基金会)制定。其设计理念为：无需设计新的硬件，只对现有硬件更新其软件。这在很大程度上降低了部署网络应用所需的成本。在传统网络中，二层交换机主要采用MAC地址和VLAN标签对数据包进行处理与转发，而在SDN网络中，OpenFlow作为构建网络的一种标准南向协议与规范，通过解析数据包或帧的包头域，将其MAC地址、VLAN标签、IP地址、TCP/UDP端口号等特征作为“Flow”进行处理，通过在交换机中添加流表进行匹配，就能够灵活便捷地决定应用流的转发路径。

针对大规模多管理域(SDN域)应用场景，业界提出了一些解决方案，主要是对控制平面进行了扩展，大致分为两类：分层分布式和完全分布式。

对于分层分布式控制平面(如图1(a)所示)，其域内控制器管控各个管理域域内网络，包括网络抽象、链路发现等，负责域内路由，并且向域间控制器上传特定的拓扑信息和主机信息。域间控制器通过获取来自域内控制器的信息，计算域间路由。例如，OXP[10]针对异构控制器间无法直接交互和目前接口协议效率较低的问题，设计了一种高效的、支持多种模式的东西向协议。OXP采用分层分布式的控制平面来解决SDN网络中单一控制平面遇到瓶颈的问题，域间控制器负责域间路由，域内控制器只负责域内路由。当发现应用流的目的IP地址不属于当前管理域时，域内控制器将数据包包头转发至域间控制器。域间控制器基于全局网络信息计算跨域路径，最后由各域内控制器完成流表的下发。

图1 控制平面架构

对于完全分布式控制平面(如图1(b)所示)，每个管理域的控制器同时负责其域内路由，以及到下一管理域的域间路由，各管理域控制器之间进行信息的交互与协商，从而进行路由的决策。例如，HyperFlow[11]采用WheelFS实现分布式的发布/订阅系统，该系统保证了发布事件的存储是永久的，并且保证事件的触发顺序与源控制器一致，在网络划分时具备良好的可伸缩性。但是由于所有事件的处理都需要全局信息，造成控制器间交互的信息量巨大，此外，还会造成网络状态不一致等问题。因此，这种模式只能处理一些发生率较低的事件，而不适用于大规模多管理域网络。WE-Bridge[12-13]，虽然可实现异构控制器之间的协同工作，但是当网络视图发生改变时，由于控制器间采用全连接的方式，需要在所有同类节点中同步数据，导致消耗大量带宽，效率低下。SDNi虽然作为一种控制器间信息交互的协议，但是草案中并没有对网络如何存储这些信息以及如何在多个域之间共享这些信息给出具体的描述。DISCO[14]采用基于消息导向的通信总线，提供一个分布式控制平面。DISCO将整个网络分成多个域，用多个控制器进行管理。每个控制器管理一个域，并提供唯一轻量级的可管理的控制通道，每个控制器上的代理动态嵌入通道来获取其他域的信息。代理间互相共享全网信息，因此可以为应用提供端到端的网络服务。其缺点在于全局事件的处理需要一致的全局信息，控制器之间交互的信息过多。

针对现有域间路由技术存在的相关问题及不足，文中提出一种基于SDN的多管理域路由机制(SDNMDR)，以及相关的实现和实验方案，并通过实验进行验证。

2 基于SDN的多管理域路由机制

虽然现有SDN域间路由技术在一定程度上解决了网络扩展性的问题，但是大多数方案都只是针对单一网络提供商实体而言的，并且域间交互的信息量过大，将会给网络负载带来巨大的压力。此外，当多个管理域由不同的网络提供商实体进行管控时，出于安全性考虑，大家都不愿公开其内部网络信息。因此，上文所列举的现有SDN域间路由技术将不再适用。

针对BGP分布式部署存在的诸多问题，以及现有SDN域间路由技术的不足，结合SDN网络可编程带来的优势，设计了SDNMDR机制。该机制采用完全分布式控制平面，主要通过控制器上的三个模块来实现，如图2所示。

图2 控制器功能模块

(1)域内监控模块(Intra_Monitor)。该模块根据SDN域内集中管控的思想，采用LLDP协议获取域内交换机信息，以及网络的实时情况，包括网络资源和网络流量信息等，从而分别为域间交互模块和路由模块提供协商和选路依据。

(2)域间交互模块(Inter_Negotiation)。对于网络应用流的传输，可达性是最基本的要求。首先，该模块参照BGP[15]协议交互网络可达性信息，在目的网络可达的情况下，为了满足应用流的端到端需求约束，相邻管理域再通过该模块进行应用需求的请求与协商。

(3)路由模块(Routing)。主要完成两项工作：第一，对于跨域的应用流，结合网络可达性信息和域内网络资源信息，进行域内路径以及到相邻管理域的域间路径的计算；第二，根据计算结果，通知域间交互模块与相邻管理域进行协商，协商完成后再由该模块完成流表的下发。

目前业界大多数开源控制器，如Ryu、OpenDaylight、Floodlight、ONOS等，都已经实现域内监控和域内路由。由于SDN的初衷在于单个管理域内的集中控制，所以对于SDN域间如何交互与协商的问题，即东西向接口问题，仍是当前将SDN应用于大规模网络中亟需解决的一个热点问题。以下为文中提出的一种解决方案。

实现端到端服务质量约束路由的基础是多管理域间的互联互通，在SDN网络中，为了构建跨域的流表，相邻管理域控制器间需要进行通信，交互网络层可达性信息。文中控制器之间的交互参照了BGP，在域间交互模块中实现，域间控制器的通信流程如图3中①～④所示，具体过程如下：

(1)使控制器具备BGP speaker的能力，每个BGP speaker包含状态机逻辑，并且当控制器启动时，BGP功能体触发连接事件。每个管理域的BGP信息由网络管理员进行配置，控制器与邻居控制器建立TCP连接。

(2)BGP使用TCP作为其传输层协议，当TCP连接建立后，BGP speaker将会互相发送OPEN消息，并且状态将会变成OPEN。

(3)BGP speaker在OPEN状态下协商会话能力，控制器通过OpenFlow南向协议获取其管理域网络能力信息。

(4)成为BGP Peers后，控制器进入ESTABLISHED状态，双方在这个状态下互换BGP UPDATE消息，如NLRI和带宽等。

图3 控制器建立连接及协商过程

为了给用户带来良好的网络体验，应用流在跨域传输的过程中，需要加以服务质量约束。由于各管理域只能够决定其域内路由，彼此间缺乏协商机制，使得业务的QoS约束难以得到保障。针对该问题，文中设计了一种域间协商协议，通过协商来实现应用流的端到端QoS约束路由。协商协议交互过程如图3中⑤～⑦所示。域间协商协议的消息如表1所示。

表1 域间协商消息

域间协商协议具体过程如下：

(1)控制器A发现应用流的目的地址是在域外，基于BGP信息，选择最佳下一域B，从本地数据存储中检索边界信息，并且发送一个包含端到端应用约束的协商请求给控制器B。

(2)控制器B收到这样的消息，与域内策略作比较，如果符合域内策略且有能够满足应用需求的配置路径，则更新这些路径以满足额外需求，否则将通过路由模块计算新的路径。此外，还会检查域间链路的统计，如果有可用的资源，然后会回复控制器A一个包含相应的代价ACCEPT协商响应，否则回复REJECT。

(3)如果控制器A收到一个ACCEPT，则表示协商成功。

(4)如果目的IP不在B，则重复以上步骤，采用递归的方式。

根据协商结果，各管理域中的控制器根据路由模块中计算好的路径，采用OpenFlow协议对沿路的交换机通过下发流表进行配置。

OpenFlow流表的匹配域能够匹配数据包包头的二层至四层地址信息。首先，分别对源主机和目的主机所连接的交换机配置，通过控制器中存储的MAC-PORT映射表，采用匹配源目的MAC地址的方式构建流表；对非源目主机所在管理域的边界交换机配置，采用匹配目的IP地址的方式构建流表，使得经过该交换机的应用流能够转发至协商好的下一管理域的入口交换机，如图3中⑧～⑨所示。此外，各管理域还需周期性检查域间链路状态以及相关QoS参数，确保能满足应用流的服务质量约束和管理域间所约定的SLA参数，当不满足时，重新进行协商与配置。

3 多域路由机制的实验和测试

为了满足应用流的跨域传输，首先需要实现的是多管理域的互联互通。实验选取Ryu开源控制器，通过Quagga使其具备BGP speaker的能力，采用Mininet仿真实验环境。实验拓扑如图4(a)所示，各管理域控制器采用BGP消息进行交互，获取NLRI后，通过OpenFlow配置交换机，执行pingall命令，H1～H6主机间能够互相ping通。通过测试，验证了该多SDN域实验平台的可行性。

图4 实验拓扑

当源管理域控制器收到多条关于目的地址前缀的路由通告时(即在源节点与目的节点之间存在多条物理链路)，模拟抽象网络拓扑如图4(b)所示。在该场景下，应用流需要从D1中的主机s(172.16.1.1)传输至D6中的主机t(172.16.6.1)，此时存在多条域间链路(①D1-D2-D6；②D1-D3-D4-D6；③D1-D3-D4-D5-D6)。假设该应用流的总时延约束为100 ms，为了保障端到端约束路由，控制器间需要进行协商，并且根据协商的结果下发流表，配置各自域内交换机和边界交换机。

假设域间链路时延均为10 ms，代价均为10。各管理域域内聚合链路(边界路由器之间的链路)的时延及代价如图5所示。

首先根据BGP交互的网络层可达性信息以及从域内监控模块获取的域内拓扑和资源信息，D1中控制器结合应用流服务质量约束与路由模块中的路由算法(文中采用最小代价算法)，选择可以到达目的IP地址的下一管理域，通过交互模块发送协商请求，相邻管理域根据请求消息返回请求结果和所需代价。测试结果如下：

(1)D1选择时延20 ms，D1-D2时延为10 ms，D2选择时延20 ms，D2-D6时延10 ms，D6选择时延20 ms。共80 ms，满足约束。递归返回代价70。

D110 ms(10) , 20 ms(5)10 ms(10) , 15 ms(5)D210 ms(35), 20 ms(30)D315 ms(15), 20 ms(10)D410 ms(15), 15 ms(8)10 ms(20), 30 ms(5)D520 ms(20), 30 ms(10)D610 ms(20), 20 ms(15)5 ms(20), 10 ms(15)10 ms(20), 20 ms(15)

图5 域内链路(时延(代价))

(2)D1选择时延15 ms，D1-D3时延为10 ms，D3选择时延20 ms，D3-D4时延10 ms，D4选择时延30 ms，D4-D5时延10 ms，D5选择时延30 ms和20 ms均不满足约束。

(3)D1选择时延15 ms，D1-D3时延为10 ms，D3选择时延20 ms，D3-D4时延10 ms，D4选择时延15 ms，D4-D6时延10 ms，D6时延10 ms，共90 ms，满足约束。递归返回代价68。

(4)D1中控制器的交互模块比较1和2中的代价，选择D1-D3-D4-D6这条链路，并且发送确认消息。

(5)各管理域根据协商结果，通知路由模块下发流表配置交换机。

配置完成后，通过ovs-ofctl dump-flows命令查看D1与D3相连的边界交换机流表，可以看到包含“ip, nw_dst=172.16.6.1, actions=output:4”字段信息的流表，查看D6中与主机t相连的交换机流表，可以看到包含“in_port=3, dl_dst=00:00:00:00:00:02,actions=output:3”字段信息的流表。

实验结果表明，SDNMDR能够实现多管理域间的互联互通，并且当源目的主机间存在多条可选域间路径时，以及各管理域网络资源允许的情况下，服务提供商能够根据管理域间的协商，综合考虑应用需求与传输过程中所需代价，选择满足约束的端到端路由。

4 结束语

通过扩展标准Ryu开源控制器的功能模块，结合Mininet网络仿真工具，实现了一种基于SDN的多管理域路由机制。通过模拟与测试，验证了该机制能够在满足应用需求，为用户提供良好体验的前提下，降低服务提供商的所需成本。并且该方案采用完全分布式控制平面，可缩放性较强，能够适应当前互联网快速发展的迫切需求。