一种基于SDN网络的端到端业务监测的方法和装置与流程

本发明涉及通信技术领域，具体涉及一种基于sdn网络的端到端业务监测的方法。本发明同时涉及一种基于sdn网络的端到端业务监测的装置。

背景技术：

sdn网络(softwaredefinednetwork)即软件定义网络，是由美国斯坦福大学cleanslate研究组提出的一种新型网络创新架构，其核心技术openflow通过将网络设备控制面与数据面分离开来，并在网络中实现了软硬件的分离以及底层硬件的虚拟化，从而实现了网络流量的灵活控制，为核心网络及应用的创新提供了良好的发展平台。

在sdn中，交换设备的数据转发层和控制层是分离的，因此网络协议和交换策略的升级只需要改动控制层。openflow在openflow交换机上实现数据转发，而在控制器上实现数据的转发控制，从而实现了数据转发层和控制层的分离。

openflow网络由openflow交换机、flowvisor和controller三部分组成。openflow交换机进行数据层的转发；flowvisor对网络进行虚拟化；controller对网络进行集中控制，实现控制层的功能。

openflow交换机是整个openflow网络的核心部件，主要管理数据层的转发。openflow交换机接收到数据包后，首先在本地的流表上查找转发目标端口，如果没有匹配，则把数据包转发给controller，由控制层决定转发端口。openflow交换机由流表、安全通道和openflow协议三部分组成。

安全通道是连接openflow交换机到控制器的接口。控制器通过这个接口控制和管理交换机，同时控制器接收来自交换机的事件并向交换机发送数据包。交换机和控制器通过安全通道进行通信，而且所有的信息必须按照openflow协议规定的格式来执行。openflow协议用来描述控制器和交换机之间交互所用信息的标准，以及控制器和交换机的接口标准。协议的核心部分是用于openflow协议信息结构的集合。

在sdn网络中，利用sdn的特性可以很好的解决网络状态监控问题，在sdn网络特性中，用于监测业务路径状态的方式大致有以下几种：

packet_in：让业务路径上的每一个节点，将其业务流量复制一份给sdn控制器，以判断业务流量是否达到本节点以及到达本节点的延迟；

packet_in+packet_out：sdn控制器通过packet_out发送流表，在下一个节点通过流表匹配packet_in回送控制器，从而确定链路的状态，以链路的状态反馈业务路径的状态；

packetout报文：又称为packetout消息，是openflow定义的一种消息格式。

packetout流表：是在交换机里的一种流表，是特指在我们的应用场景中，为了匹配packetout报文的一个流表结构。

读取流表计数器：读取业务路径上的每一节点的流表计数器(如pps，bps)用来监测业务流是否有丢包，以及在哪丢包。以一个典型的sdn网络场景为例，如图1，包括一个交换机controller，3个openflow交换机ofs-1、ofs-2、ofs-3，业务两端为a、z。

业务路径上所有节点的a到z业务流复制一份回送到sdn控制器，sdn控制器通过业务流表的统计，以及时间来判断业务的延迟及丢包；

sdn控制器通过packet_out定制报文下发给ofs-1，在ofs-2上预先下发流表匹配定制报文回送到控制器，来判断ofs-1与ofs-2链路的可用性；

控制器读取a到z业务在ofs-1，ofs-2，ofs-3上的流表计数器，来判断业务数据流表是否有丢包。

在上述现有方案存在一定局限性。用户所有流表都会上报控制器。无论在管理通道，还是控制器的处理能力上，都将会是非常大的瓶颈，无法在实际网络中应用。链路的状态只能代表业务路径中断，无法监测端到端业务的延迟情况。当业务数据持续在sdn网络中传输时，由于a/z端控制器采集计数器的时间差，前后的流表数量无法对齐，无法判断丢包情况，同时也无法判断网络中的延迟情况。

技术实现要素：

本发明提供一种基于sdn网络的端到端业务监测的方法，以解决现有无法监测端到端业务的延迟情况和无法判断丢包情况的问题。本发明另外提供一种基于sdn网络的端到端业务监测的装置。

本发明提供一种基于sdn网络的端到端业务监测的方法，包括：

对待监测的业务进行路径查询，得到所述业务的路径上各个节点的信息；

根据所述业务的属性，封装特定的packet_out报文；所述特定的packet_out报文在匹配业务流的基础上，再匹配特定的标记位；

将所述packet_out报文下发到所述业务的首端节点，同时启动该业务的计时器；所述packet_out报文最终将被转发到所述业务的末端节点；

当接收到由所述末端节点发送的packet_in报文后，同时解析所述packet_in报文，计算所述业务的路径的时延，并重置所述业务的计时器；所述packet_in报文是所述末端节点根据收到的所述packet_out报文信息封装的。

较佳地，在所述对待监测的业务进行路径查询之前，还包括：

对网络进行初始化；

定义通用的packet_out流表；

所述定义通用的packet_out流表是基于预留的网络资源，在对网络初始化时下发预定义的通用的packet_out流表；所述packet_out流表用于监控通用业务。

较佳地，所述特定的packet_out报文在所述业务的路径上经由各个中间节点完成转发。

较佳地，所述特定的packet_out报文包括：

报文头部，用于指示特定的业务类型及出端口；和，

报文数据部分，用于指示基于区分业务的特定封装格式、特定的时间戳和业务属性。

较佳地，将所述packet_out报文下发到所述业务的首端节点，同时启动该业务的计时器之后，还包括：

定期采集路径上所有节点的流表计数器。

较佳地，在定期采集路径上所有节点的流表计数器之后，还包括：

当在一段时间内未能正常收到定制的packet_in报文，则确认判定所该业务的计时器超时，首先判断sdn控制器与首端节点的链路、sdn控制器与末端节点的链路是否正常；若不正常，则说明sdn控制器与相关节点已经失联，则进入失联处理流程；若没有失联，则统计相同时间点内所有节点的流表计数器，确定丢包的具体节点和丢包率。

较佳地，所述统计相同时间点内所有节点的流表计数器，确定丢包的具体节点和丢包率具体包括：

统计相同时间点内所有节点收到的匹配业务的流表的数量，根据所述流表的数量的大小对比，判定出产生丢包的节点，根据首端节点发送的流表数和业务中其余节点接收到流表数量的差值计算丢包率。

较佳地，所述计算业务丢包率的公式为：(n-m)/n；其中，n为所述业务首端节点发送的所述流表的总共数量；m为所述业务中除首端节点外其余任意节点接收到的流表的数量。

较佳地，所述根据时间戳来计算具体的业务时延，包括：

当发送所述packet_out报文时记录时间点为t0，同时生成计时器t’；

当收到业务的路径上末端节点发送的packet_in时记录时间点为t2；

当收到业务的路径上首端节点回应的request时记录时间点为t3；

当发送echo消息给业务路径上末端节点时记录时间点为t4；

当收到业务的路径上末端节点回应的request时记录时间点为t5；

业务的路径的延迟按照如下公式计算：t1-t0-(t3-t2)/2-(t5-t4)/2。

本发明还提供一种基于sdn网络的端到端业务监测的装置，包括：

查询单元，用于对待监测的业务进行路径查询，得到所述业务的路径上各个节点的信息；

封装单元，用于根据所述业务的属性，封装特定的packet_out报文；所述特定的packet_out报文在匹配业务流的基础上，再匹配特定的标记位；

下发单元，用于将所述packet_out报文下发到所述业务的首端节点，同时启动该业务的计时器；所述packet_out报文最终将转发到所述业务的末端节点；

接收单元，用于接收由末端节点发送的packet_in报文；

解析单元，用于解析所述packet_in报文，计算业务的路径的时延，并重置所述业务的计时器；所述packet_in报文是末端节点根据收到的所述packet_out报文封装的。

较佳地，还包括：

初始化单元，用于对网络进行初始化，定义通用的packet_out流表；

所述定义通用的packet_out流表是基于预留的网络资源，在对网络初始化时下发预定义的通用的packet_out流表；所述packet_out流表用于监控通用业务。

较佳地，所述特定的packet_out报文在所述业务的路径上经由各个中间节点完成转发。

较佳地，所述特定的packet_out报文包括：

报文头部，用于指示特定的类型及出端口；和，

报文数据部分，用于指示基于区分业务的特定封装格式、特定的时间戳和业务属性。

较佳地，还包括：

采集单元，用于定期采集路径上所有节点的流表计数器。

较佳地，还包括：

丢包检测单元，当在一段时间内未能正常收到定制的packet_in报文，则用于确认所该业务的计时器超时，具体用于首先判断sdn控制器与首端节点的链路、sdn控制器与末端节点的链路是否正常；若失联，则进入失联处理流程；若没有不正常，则说明sdn控制器与相关节点已经失联，则统计相同时间点内所有节点的流表计数器，确定丢包的具体节点和丢包率。

较佳地，还包括：

判断单元，用于统计相同时间点内所有节点收到的匹配业务的流表的数量，根据所述流表的数量的大小对比，判定出产生丢包的节点，根据首端节点、末端节点所述流表数量的差值计算丢包率。

较佳地，所述丢包率计算公式为：(n-m)/n；其中，n为所述业务首端节点发送的流表的总共数量；m为所述业务中除首端节点外其余任意节点接收到的流表的数量。

较佳地，所述解析单元根据时间戳来计算具体的业务时延，具体包括：

当发送所述packet_out报文时记录时间点为t0，同时生成计时器t’；

当收到业务路径上末端节点发送的packet_in时记录时间点为t2；

当发送echo消息给业务路径首端节点时记录时间点为t3；

当收到业务路径首端节点回应的request时记录时间点为t4；

当发送echo消息给业务路径末端节点时记录时间点为t5；

当收到业务路径末端节点回应的request时记录时间点为t6；

业务路径的延迟按照如下公式计算：t1-t0-(t4-t3)/2-(t6-t5)/2。

与现有技术相比，本发明具有以下优点：

采用本发明的方法，不基于用户流表，还是使用定制化的packet_in/packet_out方式处理；不基于链路，而是基于单个业务路径；当出现超时情况下，结合业务路径所有节点的计数器情况，来判断丢包情况。本发明实现了业务的端到端监测，计算出业务的网络转发延迟及丢包情况，并判断具体丢包的节点。不影响业务数据流量的正常转发，不增加控制器的性能要求，规则通用，并且可以适用于一张大型sdn网络(大于几十个节点，几百g的业务流量)。

附图说明

图1是一个典型的sdn网络场景的结构示意图；

图2是本发明实施例的一种基于sdn网络的端到端业务监测的方法的流程示意图；

图3是本发明实施例的一种基于sdn网络的端到端业务监测的装置的结构示意图；

图4是本发明实施例的一个整体流程示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本发明。但是本发明能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施的限制。

本发明主要应用于网络通信领域。以下为涉及到的专业术语：

sdn：softwaredefinednetworking,即软件定义网络，相对于传统网络的一种创新的新型网络架构，旨在实现使网络设备的数据平面和控制平面的彻底分离；

mplslabel：mpls是利用标记(label)进行数据转发的。当分组进入网络时，要为其分配固定长度的短标记，并将标记与分组封装在一起，在整个转发过程中，交换节点仅根据标记进行转发。

openflow：一种新的网络协议，在转发层面定义了新的网络交换模型，在控制层面定义了与转发设备通信的标准。

packet_in：openflow协议中定义的一种消息格式，用于openflow交换机将流表封装成openflow格式送到控制器。

packet_out：openflow协议中定义的一种消息格式，用于控制器将流表封装成openflow格式送到openflow交换机。

packetout报文：又称为packetout消息，是openflow定义的一种消息格式。

packetout流表：是在交换机里的一种流表，是特指在我们的应用场景中，为了匹配packetout报文的一个流表结构。

vlan：虚拟局域网，将业务隔离在一个二层网络内。

ofs：openflowswitch的简称。

本发明技术方案的目的是不基于用户流表，还是使用定制化的packet_in/packet_out方式处理；不基于链路，而是基于单个业务路径；当出现超时情况下，结合业务路径所有节点的计数器情况，来判断丢包情况。

如图1所示，是一个典型的sdn网络场景的结构示意图。以sdn网络中最流行的openflow为例，在该sdn网络中，ofs-1、ofs-2、ofs-3是支持sdn协议的openflow交换机，它们与sdn控制器(controller)共同组成一个sdn网络，业务两端a、z，业务路径path【ofs-1、ofs-2、ofs-3】。

本发明提供一种基于sdn网络的端到端业务监测的方法，图2是一种基于sdn网络的端到端业务监测的方法的流程示意图，如图2所示，该方法包括以下步骤：

步骤s101、sdn控制器对待监测的业务进行路径查询，得到所述业务的路径上各个节点的信息；

较佳地，在步骤s101之前，还包括：

sdn控制器通过一定的规则对网络进行初始化；

sdn网络控制器可以利用掌握的全局网络视图，通过对控制器及dhcp服务器进行配置，完成对网络上的每台主机进行地址和网络参数的初始化。sdn网络控制器利用流表可管控到交换机端口的特点，对接入主机的ip地址、网络参数以及其地址配置方式进行细粒度的控制与管理。

在对网络进行初始化之后，还包括：

定义通用的packet_out流表，是指基于预留的网络资源，在对网络初始化时下发预定义的通用的packet_out流表；

所述packet_out报文是openflow协议的一种消息类型。

所述openflow协议支持三种信息类型：controller-to-switch，asynchronous和symmetric，每一个类型都有多个子类型。所述packet_out报文是controller-to-switch类型的信息。所述controller-to-switch信息由控制器发起的，器主要用于直接检测交换机的状态。

packet-out消息在所有消息中是比较复杂的一种。这个消息用于控制器指定从交换机的特定端口发送数据包，或者用于转发通过packet-in消息接收到的数据包。packet-out消息中包含一个完整的数据包或者指针，以及action。所述通用的packet_out流表用于监控通用业务。所述的通用业务指的就是具有相似或相同类型的业务。所述的监控通用业务指的就是对多个相同或相似的业务进行监控。

所述通用的packet_out报文监控具体流程包括：

首先，在网络初始化时下发预定义的通用packet_out流表，在通用packet_out流表中设置预留的标志位(例如内层label的值等)；当发起监控流程时，通过获取预监控的业务的相关标志信息，并将所述业务的相关标志信息与所述通用的packet_out流表中预留的标志位进行匹配。如果匹配成功，则确认相关业务数据是否是所述通用的packet_out流表需要监控的业务，发起通用的packet_out报文监控流程。

如果所述业务的相关标志信息与所述通用的packet_out流表中预留的标志位匹配失败，则不进行通用的packet_out流表监控流程。

所述通用的packet_out流表监控方式其优点是：网络初始化时一次性下发，所以业务创建过程无感知；节省大量的流表资源，另外不需要根据每个业务进行单独定义，节省时间和资源。所述通用的packet_out流表监控方式其缺点是：为满足通用业务的需求，所以灵活性较差。主要因为，由于对多个业务进行监控，所以得到的监控数据必然是多个业务的数据，无法区分出具体某一个业务的监控数据。因此所述通用的packet_out流表监控方式导致只能适用较少场景，如采用内层label的，只能适用sdn的mpls场景。

通用packet_out报文中包含：源mac、目的mac、协议类型、源ip、目的ip、ip协议版本、报文长度信息。

步骤s102、sdn控制器根据所述业务的属性，封装特定的packet_out流表；所述特定的packet_out流表，就是对某一个具体的业务进行监控的流表。通过在特定的packet_out流表中存储具体的业务标识，完成与相关业务的匹配。其原则是在匹配业务流的基础上(如业务label，vlan，端口等)，再匹配特定的标记位(如：mpls_tc值，ip_dscp值，匹配特定的协议流表)。

所述业务流逻辑上是指相关业务的数据流，通过label，vlan，端口，可以完成定位到具体相关数据流。

所述特定的标记位，就是指通过特定的标记位，mpls_tc值，ip_dscp完成对相关数据流中的数据包的定位。

所述业务label，主要用于标识业务识别码，用来区分不同的业务。

所述vlan，端口，主要用于确认网络通道，标识所使用的网络资源。

通过业务流的匹配和标记位的匹配，可以完成对相关业务数据包的匹配。

所述特定的packet_out流表其优点是：可以满足各种不同业务的需求，根据各种不同的业务的业务流标识和特定的标记位进行。这样可以完成对每一个业务的监控，可以得到每一个业务的监控数据。其缺点是：需要对待监控的每个业务流单独定义特定的packet_out流表，这将导致占用设备流表的资源。

当拓扑中产生业务路径后，sdn控制器定时发送定制的packet_out报文到业务起始点，与用户流表的大部分的封装格式一样，除了特定的一些字段设置，比如设置了内层label的值，mpls_tc值，ip_dscp值，mac地址等。与初始化的通用packet_out流表中定义一致。

较佳地，所述特定的packet_out报文包括packet_out报文头部和packet_out报文数据部分，其中，

packet_out报文头部，用于指示特定的业务类型及出端口；和，

packet_out报文数据部分，用于指示业务的特定封装格式、特定的时间戳和业务属性。

在openflow报头中定义如下：

type：ofpt_packet_out

action：

type：ofpat_output

port：根据业务路径定义

在data中定义：

符合tcp/ip协议栈要求

与业务报文一致，若基于vlan来区分业务，则规划特定的vlan；若基于mpls来区分业务，则可以定制mpls_tc值或特殊内层标签等。

多协议标签交换(mpls)是一种用于快速数据包交换和路由的体系，它为网络数据流量提供了目标、路由地址、转发和交换等能力。更特殊的是，它具有管理各种不同形式通信流的机制。

payload：带上时间戳，业务属性等，便于控制器packet_in解析。

步骤s103、sdn控制器将所述packet_out报文下发到所述业务的首端节点，同时启动该业务的计时器；首端节点接收到所述packet_out报文后，根据所述packet_out报文中的数据，获取待监控业务信息，根据待监控业务信息，将所述packet_out报文转发到相关节点。

所述特定的packet_out报文在所述业务的路径上经由各个中间节点完成转发。

所述packet_out报文最终将被转发到所述业务的末端节点；所述业务末端节点接收到所述packet_out报文后，对packet_out报文进行解析，根据其中的数据，封装相关的packet_in报文，然后将所述packet_in报文转发给sdn控制器。

所述packet_in报文是openflow协议的一种信息类型。

所述packet_in报文是openflow协议中的asynchronous类型信息。packet_in报文信息由交换机发起并通常用于更新控制器的网络事件和改变交换机的状态。

步骤s104、当sdn控制器接收到由所述末端节点发送的packet_in报文后，计算所述业务的路径的时延，同时重置所述该业务的计时器；所述packet_in报文是所述末端节点根据收到的所述packet_out报文封装的。

sdn控制器根据发送packet_out报文给所述业务的首端节点的时间和接收到来自所述业务的末端节点packet_in报文的时间，计算出所述业务的路径时延。

定制packet_out报文在路径上的节点的转发行为与用户流表一致。到达最后一跳的节点后，会匹配预定义好的流表回送到sdn控制器。sdn控制器基于packet_in报文进行特殊处理，识别业务流和时间戳，从而计算出路径的转发延迟。

较佳地，所述根据时间戳来计算具体的业务时延，包括：

当发送所述packet_out报文时记录时间点为t0，同时生成计时器t’；

当收到业务的路径上末端节点发送的packet_in时记录时间点为t2；

当收到业务的路径上首端节点回应的request时记录时间点为t3；

当发送echo消息给业务路径上末端节点时记录时间点为t4；

当收到业务的路径上末端节点回应的request时记录时间点为t5；

业务的路径的延迟按照如下公式计算：t1-t0-(t3-t2)/2-(t5-t4)/2。

较佳地，步骤s104之后还包括：

步骤s105、定期采集路径上所有节点的业务流计时器。

如果所述sdn控制器若在一段时间内未能正常收到定制的packet_in报文，则确认所述该业务的计时器超时，所述sdn控制器首先判断sdn控制器与首端节点的链路、sdn控制器与末端节点的链路是否正常；如果不正常，则说明sdn控制器与相关节点已经失联，则进入失联处理流程，所述失联处理流程通常为异常处理流程，在此不再详细说明；

若sdn控制器与首端节点的链路、sdn控制器与末端节点的链路都正常，则所述sdn控制器判断中间链路或节点产生丢包，所述sdn控制器将定期获取的相关业务路径上所有节点的业务流计数器，通过对获取的所述相关业务路径上所有节点的业务流计数器进行计算、统计，可以获得相关业务路径上所有节点的的丢包率，通过相关业务路径上的各个节点的的丢包率来确定丢包的具体节点和相关节点间链路的稳定情况。由于采集时序的问题，丢包数量总是相对的。

所述采集时序指的就是sdn控制器，通过周期性的获取待监测业务上各个节点的流量数据。

所述采集时序问题，指的是虽然sdn控制器向相关业务路径上的各个节点发起获取监控流量数据的消息，但无法保证所有节点可以同时获取自身节点的的相关业务的流量数据。

所述丢包数量总是相对的，指的是所述相关业务路径上的各个节点在获取相关业务流量数据时，存在时间差，无法完全保证获取相关业务流量数据的完全同步性。所以说丢包数量是相对于一段时间误差而言的。

所述采集时序的周期是可以调整的。通过调整采集时序的周期，sdn控制器可以控制所述的时间误差。可以根据整体待监测业务的数量和系统的繁忙程度，扩大或者缩短采集时序的周期，以达到系统的负载和丢包率统计实时性的均衡。

所述sdn控制器对相关业务路径上所有节点的业务流计数器进行计算、统计丢包情况具体包括：

所述sdn控制器通过openflow消息，向相关业务所有节点统一发送获取待监控业务的流量请求消息；所述相关节点收到请求消息后，根据提供的待监控业务的相关标识，查询收到的所述业务的数据包计数器。然后将所述计算器的值通过openflow消息返回给sdn控制器。sdn控制对接收到所述相关业务所有节点发送的openflow消息进行解析，获取相关业务在各个节点的数据包计数器。通过对获得数据包计数器统计，可以得到相关业务在相对的一段很短的时间内的，所有节点收到的匹配业务的流表的数量，根据所述流表的数量的大小对比，可以判定出产生丢包的节点，根据首端节点、末端节点所述流表数量的差值计算丢包率。

所述丢包情况的判定，是指如果各个节点之间流表数量的差值大于一定的门限，则判定为相关节点丢包。

所述丢包率的判定，可以先计算出首端节点发出的流表数量与各个节点收到的流表数量的差值，在除以首端节点发出的流表数量。

所述业务丢包率计算公式为：(n-m)/n；其中，n为所述业务首端节点发送的所述流表的总共数量；m为所述业务中除首端节点外的任意节点接收到的流表的数量；优选的是末端节点。

所述除首端节点外的其余任意两个节点的丢包率的判定，可以先计算出两个节点收到的流表数量的差值，然后对此差值取绝对值。在用所述绝对值在除以两个节点中流表数量多的那个节点的流表数量。

所述除首端节点外的其余任意两个节点的相关业务丢包率计算公式为：abs(c-d)/max(c,d)；其中，c,d为所述两个节点接收的所述流表的总共数量；abs是指对c和d的差值取绝对值。max，是指取出c和d的最大值。

openflow获取流表流量信息是通过multipart这个消息来定期获取每个流表的bytes和packets。在multipart消息中会定义请求ofp_flow_stats的格式。控制器定期发送类型是ofp_flow_stats的multipart消息，openflow交换机收到消息后返回每个流表的bytes和packets累计值。控制器收到这些流表的累计值再根据时间间隔计算出流速，转化为bps和pps。

如图4所示，是本发明的一个详细流程图。

在上述的实施例中，提供了一种基于sdn网络的端到端业务监测的方法，与之相对应的，本申请还提供一种基于sdn网络的端到端业务监测的装置。如图3所示，其为本申请的一种基于sdn网络的端到端业务监测的装置实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例还提供了一种基于sdn网络的端到端业务监测的装置，包括：

查询单元201，用于对待监测的业务进行路径查询，得到所述业务的路径上各个节点的信息；

封装单元202，用于根据所述业务的属性，封装特定的packet_out报文；

下发单元203，用于将所述packet_out报文下发到所述业务的首端节点，同时启动该业务的计时器；所述packet_out报文最终将转发到所述业务的末端节点；

接收单元204，用于接收由末端节点发送的packet_in报文；

解析单元205，用于解析所述packet_in报文，计算业务的路径的时延，重置所述计时器；所述packet_in报文是末端节点根据收到的所述packet_out报文封装的。

优选的，还包括：

初始化单元206，用于对网络进行初始化，定义通用的packet_out流表。

优选的，所述定义通用的packet_out流表是基于预留的网络资源，在对网络初始化时下发预定义的通用的packet_out流表；所述packet_out流表用于监控通用业务。

优选的，所述特定的packet_out报文在所述业务的路径上经由各个中间节点完成转发。

优选的，所述特定的packet_out报文包括：

流表头部，用于指示特定的类型及出端口；和，

数据部分，用于指示业务的特定封装格式、特定的时间戳和业务属性。

优选的，所述解析单元205根据时间戳来计算具体的业务时延，具体包括：

当发送所述packet_out报文时记录时间点为t0，同时生成计时器t’；

当收到业务路径上末端节点发送的packet_in时记录时间点为t2；

当发送echo消息给业务路径首端节点时记录时间点为t3；

当收到业务路径首端节点回应的request时记录时间点为t4；

当发送echo消息给业务路径末端节点时记录时间点为t5；

当收到业务路径末端节点回应的request时记录时间点为t6；

业务路径的延迟按照如下公式计算：t1-t0-(t4-t3)/2-(t6-t5)/2。

优选的，还包括：

采集单元，用于定期采集路径上所有节点的流表计数器。

优选的，还包括：

丢包检测单元207，当在一段时间内未能正常收到定制的packet_in报文，则用于确认所该业务的计时器超时，具体用于首先判断sdn控制器与首端节点的链路、sdn控制器与末端节点的链路是否正常；若不正常，则说明sdn控制器与相关节点已经失联，则进入失联处理流程；若没有失联，则中间链路或节点产生丢包，将定期获取的路径上所有节点的流表计数器进行统计，确定丢包的具体节点和丢包率。

优选的，还包括：

判断单元208，用于通过对获得数据包计数器统计，得到相关业务在相对的一段时间点内的，所有节点收到的匹配业务的流表的数量，根据所述流表的数量的大小对比，判定出产生丢包的节点，根据首端节点、末端节点所述流表数量的差值计算丢包率。

优选的，所述丢包率的判定，可以先计算出首端节点发出的流表数量与各个节点收到的流表数量的差值，在除以首端节点发出的流表数量。

所述丢包率计算公式为：(n-m)/n；其中，n为所述业务首端节点发送的流表的总共数量；m为所述业务中除首端节点外其余任意节点接收到的流表的数量。优选的，m为所述业务中末端节点接收到的流表的数量。

所述除首端节点外的其余任意两个节点的丢包率的判定，可以先计算出两个节点收到的流表数量的差值，然后对此差值取绝对值。在用所述绝对值在除以两个节点中流表数量多的那个节点的流表数量。

下面以一个具体实施例为例进行举例说明，具体如下：

如图1所示的三角拓扑，采用图4的流程，采用基于mpls来区分业务，有路径标签和业务标签。预先定义预留20为特殊的内层标签。在网络初始化的情况下，会预先给所有节点设备下发一条通用的packet_out流表，具体如下：

flow1priorityhigh：

match：mpls，label＝18

action：controller

当一个业务产生a->z，对待监测的业务进行路径查询，得到所述业务的路径上各个节点的信息；路径是ofs-1,ofs-2,ofs-3。

根据所述业务的属性，封装特定的packet_out报文；所述特定的packet_out报文在匹配业务流的基础上，再匹配特定的标记位；

将业务封装到mpls流表中，具体如下：

flow1prioritynormal：

match：inport＝1，vlan＝10

action：push_mpls，set_label＝1000,push_mpls，set_label＝100，output＝18

业务路径标签为1000，内层业务标签为100

业务部署完后，控制器启用定时任务，开始向ofs-1发送packet_out报文，用来检测业务路径的可用性，同时启动该业务的计时器；流表组成如下：

openflow报头：type：ofpat_outputport：18

of内部的data：

l2头：标准二层头

mpls头：外层标签1000，内层标签20

payload：自定的业务属性和时间戳

packet_out报文在业务路径的转发如下：

ofs-1收到此流表后，解析是packet_out，并且类型是output，直接从18号口丢出。

ofs-2收到流表后，匹配外层标签1000，执行剥离标签的动作(次末跳弹出)，然后将流表丢给ofs-3.

所述packet_out报文最终将被转发到所述业务的末端节点ofs-3；

ofs-3收到流表后，根据预定义的流表，匹配上内层特殊标签20，封装成packet_in报文，回送到sdn控制器。

sdn控制器收到流表后进行解析，根据内部封装的payload标识哪个业务，同时根据时间戳来计算具体的业务时延，并重置计时器。

这里计算业务延迟的方法如下：

时间点：

t0控制器发送packet_out报文，记录的时间点，同时生成计时器t’；

t1业务路径上末跳的交换机packet_in报文送到控制器的时间点；

t2控制器发送echo消息给业务路径首端交换机的时间点；

t3业务路径首端交换机回应request给控制器的时间点；

t4控制器发送echo消息给业务路径末端交换机的时间点；

t5业务路径末端交换机回应request给控制器的时间点；

业务路径延迟＝t1-t0-(t3-t2)/2-(t5-t4)/2；

定期采集路径上所有节点的流表计数器。

当一直未收到t1的数据包，t’累计到大于一个预设值时(例如可以设定5s)，触发是否丢包判断。若t3、t5都存在则判断数据包丢失，统计相同时间点内所有节点的流表计数器。

统计相同时间点内所有节点收到的匹配业务的流表的数量，根据所述流表的数量的大小对比，判定出产生丢包的节点，根据首端节点发送的流表数和业务中其余节点接收到流表数量的差值计算丢包率。

以图1为例：

c1为ofs-1上收到的匹配业务流表数量，c2为ofs-2上收到的匹配业务流表数量，c3为ofs-3上收到的匹配业务流表数量，当c1>>c2＝c3，则判断丢包为c1与c2之间的链路上，当c1>c2>>c3时，则判断丢包为c2与c3的链路上。

丢包率的计算是根据在一端时间内检测流表是否能正常接收。例如5分钟内，总计发送流表数量n，接收到的数量为n。丢包率为：n-n/n。

该实施例只是用了mpls来举例，本发明包括不限于使用mpls的方式来封装，例如vlan，mac地址，ip_dscp，tcp等其它方式也在保护范围之内。

本发明虽然以较佳实施例公开如上，但其并不是用来限定本发明，任何本领域技术人员在不脱离本发明的精神和范围内，都可以做出可能的变动和修改，因此本发明的保护范围应当以本发明权利要求所界定的范围为准。