基于Openflow协议实现路径探测的方法、 网络系统和Openflow交换机

摘要

本发明涉及基于Openflow协议实现路径探测的方法、网络系统和Openflow交换机。第一Openflow交换机生成TraceBack消息并将其发送到控制器，控制器将TraceBack消息发送到第二Openflow交换机。第二Openflow交换机基于TraceBack消息发起回程路径探测，生成包含回程路径探测结果的TraceResult消息，并将TraceResult消息发送到控制器。控制器将包含回程路径探测结果的TraceResult消息发送到第一Openflow交换机。

说明书

技术领域

本发明涉及软件定义网络(SDN)和网络功能虚拟化(NFV)领域，更具体而言，本发明涉及在集中式的网络环境下，基于Openflow协议来实现数据包传输路径的双向路径探测。

背景技术

近年来，业界已经提出了被称为SDN的新型网络创新架构。SDN将网络的控制平面和数据平面分离开来，通过控制器中的软件平台去直接控制底层网络设备(如，交换机)，从而使网络作为管道变得更加智能化。Openflow协议是SDN控制器和交换机之间的主要交互协议，控制器基于Openflow协议实现对交换机上的数据流转发的集中控制。

Openflow协议支持三种消息：控制器至交换机消息、异步消息和对称消息，其中绝大多数消息由控制器发起，但是也支持交换机主动上报相关信息，诸如PortStatus、Error、TableStatus等。

同时，为了了解端到端通信中的网络传输情况，需要对数据包的传输路径进行探测，甚至需要双向的路径探测以了解前向路径(从源端点到目的端点)和回程路径(从目的端点到源端点)这两者的网络状况。在传统的网络环境下，路径探测一般通过TraceRoute或Tracert命令实现，但是这只能实现单向的路径探测。回程路径探测一般需要通过带外的方式来通知对端发起。

然而，在当前的基于Openflow协议的网络架构中，还没有由交换机主动发起以请求对端设备执行回程路径探测的机制和消息。而这种机制和消息，是基于Openflow协议实现端到端双向路径探测的关键环节。

发明内容

针对上面提到的问题，本发明提出了一种在SDN架构下，基于扩展的Openflow消息来实现双向传输路径的自动探测，为面向服务的双向质量保障提供基础数据。

根据本发明的一个方面，提供了一种基于Openflow协议实现路径探测的方法，用于获取从第二Openflow交换机到第一Openflow交换机的回程路径探测的信息，该方法包括：由第一Openflow交换机生成第一Openflow消息并将其发送到控制器，其中第一Openflow消息包括第一Openflow交换机和第二Openflow交换机的地址信息、以及指示发起所述回程路径探测的信息；由控制器将第一Openflow消息发送到第二Openflow交换机；响应于接收到第一Openflow消息，第二Openflow交换机发起到第一Openflow交换机的回程路径探测；由第二Openflow交换机生成第二Openflow消息并将其发送到控制器，其中第二Openflow消息包含所述回程路径探测的结果；由控制器将第二Openflow消息发送到第一Openflow交换机。

优选地，第一Openflow消息包含type字段，该type字段指示请求第二Openflow交换机发起所述回程路径探测。

优选地，第二Openflow消息包含type字段，该type字段指示包含所述回程路径探测的结果。

优选地，第二Openflow交换机在接收第一Openflow消息之后，响应于检测到所述指示发起所述回程路径探测的信息而发起到第一Openflow交换机的回程路径探测。

优选地，通过Traceroute或Tracert命令来实现回程路径探测。

优选地，所述地址信息是IP地址。

优选地，关于所述回程路径探测的结果的信息包括以下中的一项或多项：跳数；每一跳的时延、抖动；每一跳到达的地址。

根据本发明的另一方面，提供了一种基于Openflow协议的网络系统，该网络系统包括第一Openflow交换机、第二Openflow交换机、以及控制器，其中，第一Openflow交换机被配置为生成第一Openflow消息并将其发送到控制器，其中第一Openflow消息包含第一Openflow交换机和第二Openflow交换机的地址信息、以及指示发起从第二Openflow交换机到第一Openflow交换机的回程路径探测的信息；第二Openflow交换机被配置为：从控制器接收第一Openflow消息；响应于接收到第一Openflow消息，发起到第一Openflow交换机的回程路径探测；生成第二Openflow消息并将其发送到控制器，其中第二Openflow消息包含所述回程路径探测的结果；并且控制器被配置为将第一Openflow消息发送到第二Openflow交换机并将第二Openflow消息发送到第一Openflow交换机。

根据本发明的另一方面，提供了一种Openflow交换机，该Openflow交换机包括：处理器；存储器，其上存储有可执行指令，所述可执行指令当被处理器执行时使处理器执行以下步骤：生成第一Openflow消息并将其发送到控制器，其中第一Openflow消息包含该Openflow交换机和另一Openflow交换机的地址信息以及指示发起从所述另一Openflow交换机到该Openflow交换机的回程路径探测的信息。

根据本发明的另一方面，提供了一种Openflow交换机，该Openflow交换机包括：处理器；存储器，其上存储有可执行指令，所述可执行指令当被处理器执行时使处理器执行以下步骤：从控制器接收第一Openflow消息，其中第一Openflow消息包含另一Openflow交换机和该Openflow交换机的地址信息以及指示发起从该Openflow交换机到所述另一Openflow交换机的回程路径探测的信息；响应于接收到第一Openflow消息，发起到所述另一Openflow交换机的回程路径探测；生成第二Openflow消息并将其发送到控制器，其中第二Openflow消息包含所述回程路径探测的结果。

附图说明

图1例示了基于Openflow协议的网络架构；

图2例示了Openflow消息的封装方式；

图3例示了根据实施例的回程路径探测的消息交互流程；

图4例示了根据实施例的TraceBack消息和TraceResult消息的type字段；

图5例示了根据实施例的TraceBack消息的封装示例；以及

图6例示了根据实施例的TraceResult消息的封装示例。

具体实施方式

下面将参照附图描述根据本发明的实施例。

图1例示了基于Openflow协议的网络的基本架构。如图1中所示，基于Openflow协议的网络主要由控制器和Openflow交换机组成。Openflow协议实现了数据平面和控制平面的分离，其中Openflow交换机执行数据平面的转发功能，而控制器执行控制平面的控制功能。Openflow交换机和控制器之间按照Openflow协议进行交互。

Openflow交换机是整个网络的核心部件。需要注意的是，本文所用的术语“Openflow交换机”是指Openflow协议中定义的交换机，其可以是专用Openflow交换机，也可以是支持Openflow协议的通用交换机。专用Openflow交换机通常可以不支持二层和三层的处理，是按照控制器的控制在端口之间转发数据包的“哑”数据通路元件。某些通用的以太网交换机和路由器也可以通过增加流表、安全通道和Openflow协议(下面将详细描述)而获得Openflow特征。

Openflow交换机由至少三个部分组成：

1、流表，由许多个流表项，每个流表项实质上是一个转发规则，用于告诉Openflow交换机如何处理进入交换机的数据包，Openflow交换机只按照流表进行数据转发；

2、安全通道，连接Openflow交换机和控制器，允许按照Openflow协议在Openflow交换机和控制器之间发送命令和消息包；

3、Openflow协议，用于描述Openflow交换机和控制器之间的交互消息标准和接口标准。

控制器通过Openflow协议这个标准接口来对Openflow交换机中的流表进行控制(例如，增加、移除或修改流表项)，从而实现对Openflow交换机的集中控制。

Openflow协议定义了控制器和Openflow交换机之间的交互消息的封装方式。

如图2中所示，Openflow消息以Openflow头部开始。Openflow头部包含以下字段：

版本(version)：Openflow协议的版本；

类型(type)：由8bit的常数指示，表明Openflow消息的类型,诸如“HELLO”、“FLOW_MOD”等；

长度(length)：表明包含头部的整个消息包的长度；

xid：与该消息包相关联的事务id(Transaction id)。

Openflow消息还包括有效载荷部分。有效载荷部分的结构与具体的消息类型有关。

如下面将描述的，本发明的一个方面在于扩展Openflow消息，并利用经扩展的Openflow消息来实现便捷的、可靠的双向传输路径探测。

常规地，如果特定端点(下面称为源端点)想要获知与另一端点(下面称为目的端点)之间的双向传输路径的网络状况，一方面，源端点可以直接发起从源端点到目的端点的单向的路径探测(前向路径探测)，另一方面，源端点需要通过带外的方式通知目的端点发起从目的端点到源端点的单向的路径探测(回程路径探测)，由此实现双向路径探测。由于本领域已经存在关于前向路径探测的许多实现方式，本文将着重描述回程路径探测的实现方式，尤其是在基于Openflow协议的网络架构下。

下面将参照图3来描述利用经扩展的Openflow消息实现回程路径探测的流程。在本发明的实施例中，为了方面描述，假设源端点是Openflow交换机A，目的端点是Openflow交换机B。然而，取决于本发明应用的场景，路径探测的源端点和/或目的端点也可以是网络中的其他设备，例如，与Openflow交换机连接的端点设备。

如图3中所述，在S1步骤，Openflow交换机A生成TraceBack消息，并将该消息发送到相关联的控制器。

TraceBack消息是经扩展的Openflow消息，其包含源端点的源地址信息、目的端点的目的地址信息、以及指示发起回程路径探测的信息。

在实施例中，TraceBack消息在其有效载荷部分包含Openflow交换机A和Openflow交换机B的地址信息，例如，Openflow交换机A和Openflow交换机B的IP地址。然而，源地址信息和目的地址信息也可以是能够用于对源端点和目的端点进行寻址的管理地址或其他类型的地址信息。

除地址信息以外，TraceBack消息还包含与回程路径探测的发起有关的信息，基于这些信息，控制器可以在接收到TraceBack消息之后将其发送给Openflow交换机B，并且Openflow交换机B可以发起到Openflow交换机A的回程路径探测。在实施例中，与回程路径探测的发起有关的信息被包含在TraceBack消息的头部中。例如，TraceBack消息的type字段被定义为具有特定值Vtb，以标识该消息的类型。

在S2步骤中，控制器接收来自Openflow交换机A的TraceBack消息，并将其发送到Openflow交换机B。

控制器对所接收的TraceBack消息进行解析。控制器检测到TraceBack消息的头部中的type字段为特定值Vtb，并且响应于该检测，控制器确定将转发该消息。控制器还可以检测TraceBack消息的有效载荷部分中所包含的目的地址信息。通常，控制器中储存有到交换机的路由信息或者通过检索获取到交换机的路由信息。由此，控制器可以将TraceBack消息发送到Openflow交换机B。

可能存在控制Openflow交换机A的控制器和控制Openflow交换机B的控制器不同的情况。在这种情况下，可以出现消息在控制器之间的传输。例如，收到TraceBack消息的控制器可以根据Openflow交换机B的地址信息来将该消息路由到控制Openflow交换机B的另一控制器，并由该控制器将TraceBack消息发送到Openflow交换机B。

在S3步骤中，Openflow交换机B响应于接收到TraceBack消息，发起回程路径探测。

Openflow交换机B从控制器接收TraceBack消息，并对所接收到的消息进行解析。交换机B检测到TraceBack消息的头部中的type字段为特定值Vtb。响应于该检测，Openflow交换机B将确定发起回程路径探测。Openflow交换机B还可以检测TraceBack消息的有效载荷部分中所包含的源地址信息，并且基于该源地址信息，发起到源端点(Openflow交换机A)的回程路径探测。

路径探测可以以各种方式进行。例如，在Linux环境下，可以运用Traceroute命令来实现。例如，在Windows环境下，可以运用Tracert命令来实现。需要注意是，在本发明中，可以应用各种路径探测方式，只要能够获取关于从目的端点到源端点的传输路径的网络状况。通过路径探测获得的结果包括但不限于：从Openflow交换机B到Openflow交换机A的总跳数、每一跳的时延和抖动、所经过的交换机地址。

在S4步骤中，Openflow交换机B生成TraceResult消息，并将该消息发送到控制器。

Openflow交换机B利用TraceResult消息来传送回程路径探测的结果。除了回程路径探测的结果之外，TraceResult消息还可以包括地址信息，尤其是源地址信息，以便于将该消息发送到期望获取回程路径探测结果的源端点——Openflow交换机A。交换机B将所生成的TraceResult消息发送到控制器。

最后，在S5步骤中，控制器将TraceResult消息发送到Openflow交换机A。

控制器对所接收到的TraceResult消息进行解析。控制器检测到TraceResult消息的头部中的type字段为特定值Vtr。响应于该检测，控制器确定将转发此消息。控制器还可以识别TraceResult消息的有效载荷部分中包含的源地址信息。根据所识别出的源地址信息，控制器将TraceResult消息发送到Openflow交换机A。

Openflow交换机A接收到来自控制器的TraceResult消息之后，可以获取从Openflow交换机B到Openflow交换机A的回程路径探测的结果。

Openflow交换机A还可以执行到Openflow交换机B的前向路径探测。由此，在Openflow交换机A处可以获得Openflow交换机A和Openflow交换机B之间的双向传输路径的网络状况。基于双向传输路径的探测情况，例如，可以生成相应的QoS报告，为面向业务的双向传输质量保障提供有用的信息。

以上参照图3的消息交互流程描述了实现回程路径探测的过程。需要注意的是，以上仅描述了与本发明最紧密相关的内容，某些技术细节在本文中未详细描述。例如，消息在Openflow交换机和控制器之间的传输还可能涉及消息包的打包和解包，等等。

下面将参照图4至图6来描述本实施例中使用的TraceBack消息和TraceResult消息。

如图4所示，本发明的TraceBack消息和TraceResult消息对Openflow消息进行了扩展。在实施例中，通过对Openflow消息的type字段进行定义/赋值，来定义TraceBack消息和TraceResult消息。例如，通过将type字段赋值为特定值Vtb，来定义TraceBack消息。又例如，通过将type字段赋值为特定值Vtr，来定义TraceResult消息。其中Vtb和Vtr均为含义明确的常数。

图5和图6分别例示了TraceBack消息和TraceResult消息的封装示例。

如图5中所示，TraceBack消息的有效载荷部分包含如下字段：

字段AT：表明源地址和目的地址所属地址族，如IPv4或IPv6；

字段SA：表明源地址，4字节或16字节；

字段DA：表明目的地址，4字节或16字节。

除了以上字段之外，TraceBack消息还可以包含与源端点和/或目的端点有关的其他信息。

如图6中所示，TraceResult消息的有效载荷部分包含如下字段：

字段AT：表明源地址和目的地址所属地址族，如IPv4或IPv6；

字段Hop Num：表明探测路径所走过的总跳数；

字段SA：表明源地址，4字节或16字节；

字段DA：表明目的地址，4字节或16字节；

字段Hop No.：表明跳数序号；

字段Delay：表明当前跳的时延；

字段Jitter：表明当前跳的抖动；

字段HA：表明当前跳到达的地址(例如，IP地址)。

在上述字段中，Hop Num、Hop No.、Delay、Jitter、HA表示回程路径探测的结果。但是，回程路径探测的结果还可以包含其他信息，诸如带宽、丢包率等。

上面已经参照实施例描述了本发明。根据本发明的实施例，可以基于Openflow协议实现源端点与目的端点之间的双向传输路径探测。尤其是对于回程路径探测，利用经扩展的Openflow消息，可以容易地通知对端发起回程路径探测并且传回回程路径探测结果。这可以方便地获取面向服务的双向传输路径的网络质量，从而提供面向特定业务的端到端路径质量保障。这提升了运营商或服务提供商对于网络中流量的调度和优化能力。

在本发明的优选实施例中，提出了通过定义Openflow消息头部的type字段来扩展出两种信令消息。因此，现有的基于Openflow协议的网络可以仅仅做出微小的扩展即可应用本发明，从而具有良好的兼容性。另外，本发明仅需要边缘网络设备(例如，Openflow交换机A和B)支持Openflow协议的扩展，而中间网络设备仅需要支持传统的诸如TraceRoute、Tracert之类的路径探测命令，这使得本发明可以适应多种网络部署环境。

本发明的实施例可以通过软件、硬件或其结合来实现。例如，控制器、Openflow交换机可以通过处理器读取并执行存储在计算机可读存储介质上的程序指令来执行如上面实施例中所述的动作。例如，本发明的实施例也可以在被适当地编程的硬件(例如，FPGA、ASII)中实现。

已经描述了本发明的实施例，但是应注意，在不脱离本发明的范围的情况下，可以进行各种修改。所附权利要求书的范围应被赋予宽泛的解释，以便涵盖所有修改和等同的结构及功能。