一种基于软件定义网络中数据处理的系统、方法和节点与流程

文档序号:11812013阅读:283来源:国知局
一种基于软件定义网络中数据处理的系统、方法和节点与流程

本发明涉及通信技术领域,特别涉及一种基于软件定义网络中数据处理的方法、节点和系统。



背景技术:

目前通用的接入网的设备节点组网方式基本上都是采用的分布式、自治的网络结构。在这种网络结构中,每个网络节点被单独配置,独立工作。这就存在网络节点间信息不对称,导致了不同的网络节点之间的业务能力无法共享、缺乏协作,以及业务功能执行冗余、重复等问题,使得整个网络的处理性能较差。以下是网络应用中非常普遍的几种网络节点能力分配不合理的场景:

1)如图1所示,多个客户端集群和服务器集群通过不同的网络节点接入网络,其中,客户端集群1通过节点A接入网络,服务器集群1通过节点B接入网络。在网络节点A上分配有基于HTTP(hypertext transport protocol,超文本传输协议)协议的IPS(Intrusion Prevention System,入侵防御系统)业务处理能力;在节点B上分配有URL(Uniform Resource Locator,统一资源定位器)过滤的业务处理能力。网络业务流先后经过节点A和节点B时,节点A和节点B由于业务处理的需要都会对业务流做应用层的DPI(Deep Packet Inspection,深层报文检测)识别解析处理,导致不同设备在同一条业务流上重复执行部分功能。

2)如图2所示,多个客户端集群和服务器集群通过不同的网络节点接入网络,其中,客户端集群1通过节点A接入网络,服务器集群1通过节点B接入网络。在网络节点A上分配有基于报文内容的压缩能力,但是节点B不具有解压缩的能力。当需要对网络业务流做应用层传输加速时,报文经过源端节点A时可以做内容压缩,但经过终节点B时却无法做解压缩,因此导致网络加速业务的无法实现。

由于现有网络的分布式结构和节点单独部署的方式,导致网络节点业务能力私有、缺乏统一的协作管理,造成整个网络在应用层相关业务处理上缺乏协作、处理冗余、效率降低。

如何对网络节点实现统一的资源管理,合理分配节点能力和协调业务调度,实现多节点的能力共享、分工合作,从而提升全网的处理效率是当前面临的主要问题。



技术实现要素:

本发明实施例提供了一种基于软件定义的网络(Software Defined Networ k,SDN)中数据处理的系统、方法和装置,提高了节点之间的协同合作能力从而提高了网络的业务处理效率。

本发明第一方面实施例公开了一种基于软件定义网络中的数据处理的系统,所述系统包括:源数据节点,用于接收第一数据包,并向对应的源控制节点发送所述第一数据包;源控制节点,用于接收所述源数据节点发送的第一数据包,所述第一数据包携带有第一数据包的目标地址;根据所述第一数据包的目标地址确定目标控制节点;目标控制节点,用于接收所述第一数据包,根据所述第一数据包和匹配策略规则生成第二数据包。

在本发明第一方面实施例的一种可能实现的方式中,根据所述源数据节点具体用于接收第一数据包,所述第一数据包携带有第一数据包的源IP地址,根据所述第一数据包的源IP地址或者根据数据节点与控制节点的映射关系确定与所述源数据节点对应的所述源控制节点,并向所述对应的源控制节点发送所述第一数据包。

结合上述任意之一实施例的本发明第一方面实施例的第二种可能实现的方式中,所述源控制节点具体用于接收所述源数据节点发送的第一数据包,所述第一数据包携带有第一数据包的目标地址,根据所述第一数据包的目标地址确定目标数据节点;若所述源控制节点不管理所述目标数据节点,则将管理所述源数据节点和所述目标数据节点的第一控制节点确定为所述目标控制节点。

结合上述任意之一实施例的本发明第一方面实施例的第三种可能实现的方式中,所述源控制节点或所述源数据节点还用于将所述第一数据包发送给所述目标控制节点。

结合上述任意之一实施例的本发明第一方面实施例的第四种可能实现的方式中,所述匹配策略规则包括:子元组信息与动作参数或策略参数的映射/对应关系,或者应用层信息与动作参数或策略参数的映射关系;所述目标控制节点具体用于:接收所述第一数据包,根据所述第一数据包的子元组信息或第一数据包的应用层信息从所述匹配策略规则中查找到与所述第一数据包的子元组信息或第一数据包的应用层信息对应的动作参数或策略参数;并根据所述查找到的动作参数或策略参数生成所述第二数据包。

结合上述任意之一实施例的本发明第一方面实施例的第五种可能实现的方式中,所述数据处理系统还包括一个或多个服务节点;所述匹配策略规则包括:子元组信息与动作参数或策略参数的映射/对应关系,或者应用层信息与动作参数或策略参数的映射关系;所述目标控制节点具体用于:接收所述第一数据包,根据所述第一数据包的子元组信息或第一数据包的应用层信息从所述匹配策略规则中查找到与所述第一数据包的子元组信息或第一数据包的应用层信息对应的动作参数或策略参数;并根据所述查找到的动作参数或策略参数向所述一个或多个服务节点中具有执行所述动作参数或策略参数的能力的第一服务节点发送能力请求信息;所述第一服务节点用于针对所述能力请求信息向所述目标控制节点发送相应的能力响应信息;所述目标控制节点根据所述能力响应信息生成所述第二数据包。

结合上述任意之一实施例的本发明第一方面实施例的第六种可能实现的方式中,所述目标控制节点还用于向所述源数据节点发送第二数据包,所述第二数据包携带有所述第二数据包的目标地址;所述源数据节点还用于在所述目标控制节点管理下向所述第二数据包的目标地址对应的数据节点发送所述第二数据包。

结合上述任意之一实施例的本发明第一方面实施例的第七种可能实现的方式中,所述数据处理系统还包括:至少一个中继数据节点,其中,所述目标控制节点用于管理每一个所述中继数据节点;所述中继数据节点存储有对应所述中继数据节点的流表,所述流表用于存储数据包的处理规则;所述源数据节点存储有对应所述源数据节点的流表,所述流表用于存储数据包的处理规则:所述目标控制节点还用于生成路由分配规则并向所述中继数据节点和所述源数据节点下发所述路由分配规则,所述路由分配规则用于为所述第二数据包分配路由;所述中继数据节点还用于接收所述目标控制节点发送的所述路由分配规则,并根据所述路由分配规则更新所述中继数据节点的流表;所述源数据节点还用于:根据所述更新后的流表向所述第二数据包的目标地址对应的中继数据节点发送所述第二数据包;所述中继数据节点用于:根据所述更新后的流表向所述第二数据包的目标地址对应的目标数据节点发送所述第二数据包。

结合上述任意之一实施例的本发明第一方面实施例的第八种可能实现的方式中,所述源数据节点还存储有流表,所述流表用于存储业务流数据包的子元组信息和对应所述子元组信息的处理规则;所述目标控制节点还用于在所述源数据节点的流表中添加控制节点编号字段和业务参数字段,其中,所述控制节点编号字段用于表示所述源数据节点对应的目标控制节点的索引,所述业务参数字段用于表示对应所述业务流数据包的子元组信息的处理结果的索引。

结合上述实施例的本发明第一方面实施例的第九种可能实现的方式中,所述源数据节点还用于接收第三数据包,其中,所述第三数据包和所述第一数据包均属于所述业务流数据包,且对应所述第三数据包的子元组信息的处理规则和对应所述第一数据包的子元组信息的处理规则相同。

结合上述实施例的本发明第一方面实施例的第十种可能实现的方式中,所述源数据节点还用于根据所述流表,从与所述第三数据包的子元组信息匹配的处理规则记录中确定与所述子元组信息对应的业务参数,所述业务参数用于表示对所述第三数据包所要执行的动作参数或策略参数的索引;所述源数据节点将所述业务参数携带在第三数据包中向所述目标控制节点发送;所述目标控制节点还用于根据所述业务参数和所述第三数据包的应用层信息确定对所述第三数据包执行的动作参数或策略参数,从而生成第四数据包。

结合上述任意之一实施例的本发明第一方面实施例的第十一种可能实现的方式中,所述目标控制节点还具体用于,在所述源数据节点的流表中添加控制节点编号字段和所述第一数据包对应的业务参数字段,其中,所述控制节点编号字段用于表示所述源数据节点对应的目标控制节点的索引,所述第一数据包对应的业务参数字段用于表示对应所述第一数据包的子元组信息的匹配策略规则的索引,其中,所述第三数据包对应的业务参数为所述第一数据包的子元组信息的匹配策略规则的索引;所述源数据节点还用于将所述第一数据包的子元组信息的匹配策略规则的索引携带在第三数据包中向所述目标控制节点发送,所述目标控制节点还用于根据所述第一数据包的子元组信息的匹配策略规则的索引对应的匹配策略规则和所述第三数据包的应用层信息确定对所述第三数据包执行的动作参数或策略参数,从而生成第四数据包。

根据本发明实施例的SDN网络系统,通过控制节点的分层部署方式、扩展的数据节点流表结构和根据策略规则的能力分配方法,实现了SDN网络中的对应用层业务处理和能力共享分配,提高节点的协同合作从而降低网络设备中多节点处理的冗余,解决了节点能力分配不合理、能力不对称、能力不聚合等问题,提高网络的业务处理效率;同时,分层控制节点的部署方式,既解决了控制节点处理性能瓶颈问题,又保持了网络的稳定、可靠和可扩展性。

本发明第二方面的实施例公开了一种基于软件定义网络中数据处理的方法,所述方法包括:源数据节点接收第一数据包;源数据节点向对应的源控制节点发送所述第一数据包,所述第一数据包携带有第一数据包的目标地址,以使所述源控制节点根据所述第一数据包的目标地址确定目标控制节点以及使得所述目标控制节点根据所述第一数据包生成第二数据包。

在本发明第二方面实施例的第一种可能实现的方式中,所述第二数据包携带有第二数据包的目标地址,所述方法还包括:所述源数据节点接收所述目标控制节点发送的所述第二数据包;所述源控制节点向所述第二数据包的目标地址对应的数据节点发送所述第二数据包。

结合上述任意之一实施例的本发明第二方面实施例的第二种可能实现的方式中,所述第一数据包携带有第一数据包的源IP地址,在所述源数据节点向对应的源控制节点发送所述第一数据包之前,所述方法还包括:根据所述第一数据包的源IP地址或者根据所述源数据节点与控制节点的映射关系确定对应的所述源控制节点。

结合上述任意之一实施例的本发明第二方面实施例的第三种可能实现的方式中,所述源数据节点还存储有流表,所述流表用于存储业务流数据包的子元组信息和对应所述子元组信息的处理规则;在源所述数据节点向对应的源控制节点发送所述第一数据包后,所述方法还包括:所述源数据节点接收所述目标控制节点发送的第一控制信息;所述源数据节点根据所述第一控制信息在所述源数据节点的流表中添加控制节点编号字段和业务参数字段,所述控制节点编号字段用于表示所述源数据节点对应的目标控制节点的索引,所述业务参数字段用于表示对应所述业务流数据包的子元组信息的处理结果的索引。

结合上述任意之一实施例的本发明第二方面实施例的第四种可能实现的方式中,在所述源数据节点的流表中添加控制节点编号字段和业务参数字段之后,所述方法还包括:所述源数据节点还用于接收第三数据包,其中,所述第三数据包和所述第一数据包均属于所述业务流数据包,且对应所述第三数据包的子元组信息的处理规则和对应所述第一数据包的子元组信息的处理规则相同;所述源数据节点根据所述流表,从与所述第三数据包的子元组信息匹配的处理规则记录中确定与所述子元组信息对应的业务参数,所述业务参数用于表示对所述第三数据包所要执行的动作参数或策略参数的索引;所述源数据节点将所述业务参数携带在第三数据包中向所述目标控制节点发送,以使所述目标控制节点根据所述业务参数和所述第三数据包的应用层信息确定对所述第三数据包执行的动作参数或策略参数,从而生成第四数据包。

根据本发明实施例提供的一种基于软件定义的网络中数据处理的方法,通过在控制节点处对数据节点接收的数据包进行多种处理的方式,在提高了节点之间的协同合作能力的同时可以降低网络设备中多节点处理的冗余;还增强了网络设备对业务流数据包的处理能力,提高了网络的业务处理效率。

本发明第三方面的实施例公开了一种基于软件定义网络中数据处理的方法,所述方法包括:目标控制节点接收第一数据包,所述第一数据包携带有第一数据包的目标地址,其中,所述目标控制节点是由源控制节点根据所述第一数据包的目标地址确定的,所述源控制节点对应接收第一数据包的源数据节点;所述目标控制节点根据所述第一数据包和匹配策略规则生成第二数据包,并向源数据节点发送所述第二数据包,其中,所述源数据节点接收所述第一数据包,并对应所述源控制节点。

在本发明第三方面实施例的第一种可能实现的方式中,在所述目标控制节点接收第一数据包之前,所述方法还包括:所述目标控制节点接收所述源控制节点发送的第五数据包,所述第五数据包携带有第五数据包的目标地址;根据所述第五数据包的目标地址确定目标数据节点;若所述目标控制节点不管理所述目标数据节点,则将管理所述目标数据节点和所述源数据节点的第一控制节点确定为第二目标控制节点。

结合上述实施例的本发明第三方面实施例的第二种可能实现的方式中,目标所述控制节点接收第一数据包具体包括:所述目标控制节点接收所述源控制节点或所述源数据节点发送的所述第一数据包。

结合上述任意之一实施例的本发明第三方面实施例的第三种可能实现的方式中,所述匹配策略规则包括:子元组信息与动作参数或策略参数的映射/对应关系,或者应用层信息与动作参数或策略参数的映射关系;所述目标控制节点根据所述第一数据包和匹配策略规则生成第二数据包包括:根据所述第一数据包的子元组信息或第一数据包的应用层信息从所述匹配策略规则中查找到与所述第一数据包的子元组信息或第一数据包的应用层信息对应的动作参数或策略参数;根据所述查找到的动作参数或策略参数生成所述第二数据包。

结合上述任意之一实施例的本发明第三方面实施例的第四种可能实现的方式中,所述匹配策略规则包括:子元组信息与动作参数或策略参数的映射/对应关系,或者应用层信息与动作参数或策略参数的映射关系;所述目标控制节点根据所述第一数据包和匹配策略规则生成第二数据包包括:根据所述第一数据包的子元组信息或第一数据包的应用层信息从所述匹配策略规则中查找到与所述第一数据包的子元组信息或第一数据包的应用层信息对应的动作参数或策略参数;根据所述查找到的动作参数或策略参数向一个或多个服务节点中具有执行所述动作参数或策略参数的能力的第一服务节点发送能力请求信息;所述目标控制节点接收所述第一服务节点针对所述能力请求信息发送的相应的能力响应信息;所述目标控制节点根据所述能力响应信息生成所述第二数据包。

结合上述任意之一实施例的本发明第三方面实施例的第五种可能实现的方式中,在所述源控制节点根据所述第一数据包的目标地址确定目标控制节点后,所述方法还包括:所述目标控制节点向所述源数据节点发送第一控制信息,所述第一控制信息用于在所述源数据节点的流表中添加控制节点编号字段和业务参数字段,其中,所述控制节点编号字段用于表示所述源数据节点对应的目标控制节点的索引,所述业务参数字段用于表示对应所述业务流数据包的子元组信息的处理结果的索引。

结合上述任意之一实施例的本发明第三方面实施例的第六种可能实现的方式中,在所述源数据节点的流表中添加控制节点编号字段和业务参数字段之后,所述方法还包括:所述目标控制节点接收携带有业务参数的第三数据包,其中,所述第三数据包和所述第一数据包均属于所述业务流数据包,且对应所述第三数据包的子元组信息的处理规则和对应所述第一数据包的子元组信息的处理规则相同,所述业务参数是从与所述第三数据包的子元组信息匹配的处理规则记录中确定的与所述子元组信息对应的业务参数,所述业务参数用于表示对所述第三数据包所要执行的动作参数或策略参数的索引;所述目标控制节点根据所述业务参数和所述第三数据包的应用层信息确定对所述第三数据包执行的动作参数或策略参数,生成第四数据包;所述目标控制节点向所述源数据节点发送所述第四数据包。

根据本发明实施例提供的一种基于软件定义的网络中数据处理的方法,通过在控制节点处对数据节点接收的数据包进行多种处理的方式,在提高了节点之间的协同合作能力的同时可以降低网络设备中多节点处理的冗余;还增强了网络设备对业务流数据包的处理能力,提高了网络的业务处理效率。

本发明第四方面的实施例公开了一种基于软件定义网络中数据处理的数据节点,所述数据节点包括:第一接收模块、第一发送模块,所述第一接收模块与所述第一发送模块相连;所述第一接收模块用于接收第一数据包,所述第一发送模块用于向对应的源控制节点发送所述第一接收模块接收的所述第一数据包,以使所述源控制节点根据所述第一数据包的目标地址确定目标控制节点以及使得所述目标控制节点根据所述第一数据包生成第二数据包。

在本发明第四方面实施例的一种可能实现的方式中,所述第一接收模块还用于接收所述目标控制节点发送的所述第二数据包;所述第一发送模块还用于根据所述第二数据包携带的第二数据包的目标地址,向所述目标地址对应的数据节点发送所述接收模块接收的所述第二数据包。

结合上述任意之一实施例的本发明第四方面实施例的第二种可能实现的方式中,所述数据节点还包括:存储模块,所述存储模块用于存储流表,所述流表用于存储业务流数据包的子元组信息和对应所述子元组信息的处理规则;所述第一数据包属于所述业务流数据包。

结合上述任意之一实施例的本发明第四方面实施例的第三种可能实现的方式中,所述数据节点还包括:第一处理模块,所述第一处理模块与所述第一接收模块相连;所述第一接收模块还用接收所述目标控制节点发送的第一控制信息;所述第一处理模块用于根据所述第一控制信息在所述存储模块的流表中添加控制节点编号字段和业务参数字段,所述控制节点编号字段用于表示所述源数据节点对应的目标控制节点的索引,所述业务参数字段用于表示对应所述业务流数据包的子元组信息的处理结果的索引。

结合上述任意之一实施例的本发明第四方面实施例的第四种可能实现的方式中,所述第一处理模块和所述第一发送模块相连,所述第一接收模块还用于接收第三数据包,其中,所述第三数据包和所述第一数据包均属于所述业务流数据包,且对应所述第三数据包的子元组信息的处理规则和对应所述第一数据包的子元组信息的处理规则相同;所述第一处理模块根据所述流表,从与所述第三数据包的子元组信息匹配的处理规则记录中确定与所述子元组信息对应的业务参数,所述业务参数用于表示对所述第三数据包所要执行的动作参数或策略参数的索引;所述第一发送模块将所述业务参数携带在第三数据包中向所述目标控制节点发送,以使所述目标控制节点根据所述业务参数和所述第三数据包的应用层信息确定对所述第三数据包执行的动作参数或策略参数,从而生成第四数据包。

根据本发明实施例提供的一种基于软件定义网络的数据节点,通过对数据节点接收的数据包进行多种处理的方式,在提高了节点之间的协同合作能力的同时可以降低网络设备中多节点处理的冗余;还增强了网络设备对业务流数据包的处理能力,提高了网络的业务处理效率。

本发明第五方面的实施例公开了一种软件定义网络中数据处理的目标控制节点,所述目标控制节点包括:第二接收模块,用于接收第一数据包,所述第一数据包携带有第一数据包的目标地址,其中,所述目标控制节点是由源控制节点根据所述第一数据包的目标地址确定的,所述源控制节点对应接收第一数据包的源数据节点;第二处理模块,用于根据所述第二接收模块接收的所述第二数据包和匹配策略规则生成第二数据包。

在本发明第五方面实施例的第一种可能实现的方式中,所述第二接收模块还用于接收第五数据包,所述第五数据包携带有第五数据包的目标地址;所述第二处理模块用于根据所述第五数据包的目标地址确定目标数据节点;若所述第二处理模块不管理所述目标数据节点,则将管理所述目标数据节点和所述源数据节点的第一控制节点确定为第二目标控制节点。

结合上述任意之一实施例的本发明第五方面实施例的第二种可能实现的方式中,所述第二接收模块具体用于接收所述源控制节点或所述源数据节点发送的所述第一数据包。

结合上述任意之一实施例的本发明第五方面实施例的第三种可能实现的方式中,所述匹配策略规则包括:子元组信息与动作参数或策略参数的映射/对应关系,或者应用层信息与动作参数或策略参数的映射关系;所述第二处理模块包括:策略匹配单元,用于根据所述第一数据包的子元组信息或第一数据包的应用层信息从所述匹配策略规则中查找到与所述第一数据包的子元组信息或第一数据包的应用层信息对应的动作参数或策略参数;第二数据包生成单元,用于根据所述策略匹配单元查找到的所述动作参数或策略参数生成所述第二数据包。

结合上述任意之一实施例的本发明第五方面实施例的第四种可能实现的方式中,所述匹配策略规则包括:子元组信息与动作参数或策略参数的映射/对应关系,或者应用层信息与动作参数或策略参数的映射关系;所述第二处理模块包括:策略匹配单元,第二数据包生成单元;所述策略匹配单元用于根据所述第一数据包的子元组信息或第一数据包的应用层信息从所述匹配策略规则中查找到与所述第一数据包的子元组信息或第一数据包的应用层信息对应的动作参数或策略参数;所述第二发送模块还用于根据所述策略匹配单元查找到的动作参数或策略参数向一个或多个服务节点中具有执行所述动作参数或策略参数的能力的第一服务节点发送能力请求信息;第二接收模块还用于接收所述第一服务节点针对所述能力请求信息发送的相应的能力响应信息;所述第二数据包生成单元用于根据所述第二接收模块接收的所述能力响应信息生成所述第二数据包。

结合上述任意之一实施例的本发明第五方面实施例的第五种可能实现的方式中,所述第二发送模块还用于向发送第一控制信息,所述第一控制信息用于在所述源数据节点的流表中添加控制节点编号字段和业务参数字段,其中,所述控制节点编号字段用于表示所述源数据节点对应的目标控制节点的索引,所述业务参数字段用于表示对应所述业务流数据包的子元组信息的处理结果的索引。

结合上述任意之一实施例的本发明第五方面实施例的第六种可能实现的方式中,所述第二接收模块还用于接收携带有业务参数的第三数据包,其中,所述第三数据包和所述第一数据包均属于所述业务流数据包,且对应所述第三数据包的子元组信息的处理规则和对应所述第一数据包的子元组信息的处理规则相同,所述业务参数是从与所述第三数据包的子元组信息匹配的处理规则记录中确定的与所述子元组信息对应的业务参数,所述业务参数用于表示对所述第三数据包所要执行的动作参数或策略参数的索引;所述第二处理模块还用于根据所述业务参数和所述第三数据包的应用层信息确定对所述第三数据包执行的动作参数或策略参数,生成第四数据包;所述第二发送模块还用于向所述源数据节点发送所述第四数据包。

根据本发明实施例提供的一种基于软件定义的网络中数据处理的控制节点,通过在控制节点处对数据节点接收的数据包进行多种处理的方式,在提高了节点之间的协同合作能力的同时可以降低网络设备中多节点处理的冗余;还增强了网络设备对业务流数据包的处理能力,提高了网络的业务处理效率。

附图说明

为了更清楚地说明本发明实施例的技术方案,下面将对本发明实施例中所需要使用的附图作简单地介绍,显而易见地,下面所描述的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1为现有技术中,节点能力分配不合理导致的识别解析功能被重复执行的示意图。

图2为现有技术中,节点能力不对称导致的部分业务实现困难的示意图。

图3为一种SDN网络结构和支持开放流OpenFlow协议的数据节点的流表格式的示意图。

图4为本发明第一方面实施例的一种数据处理的SDN网络系统的结构示意图。图5为本发明第一方面实施例的一种数据处理的SDN网络系统的架构图。

图6为本发明第二方面实施例的一种SDN网络中数据处理的方法的流程图。

图7为本发明第三方面实施例的一种SDN网络中数据处理的方法的流程图。

图8为本发明第四方面实施例的一种SDN网络中数据处理的装置的流程图。

图9为本发明第五方面实施例的一种SDN网络中数据处理的装置的流程图。

图10为本发明实施例中的对流表增加字段后的流表的具体结构的示意图。

图11为本发明实施例的一种控制节点分层管理的示意图。

图12为本发明实施例的SDN数据处理系统中数据面的功能实现方式的示例图。

图13为本发明实施例的根据IP地址范围确定上层控制节点的实现示意图。

图14为本发明实施例的对业务流进行业务处理的示意图。

图15为本发明实施例的一种确定目标控制节点的流程图。

图16为本发明实施例的SDN网络系统的数据流向示意图。

图17为本发明实施例的一种SDN数据处理系统具体的实现场景。

图18为本发明实施例的SDN数据处理系统第二种具体的实现场景。

图19为本发明实施例的SDN数据处理系统第三种具体的实现场景。

图20为本发明实施例的SDN数据处理系统第四种具体的实现场景。

图21为本发明实施例的SDN数据处理系统中控制节点具体执行规则匹配的示例图。

图22为本发明实施例的SDN数据处理系统中针对第一数据包和第三数据包不同的处理方式的示例图。

具体实施方式

下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,可以理解的是,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

为解决网络设备间的统一协作问题,提出了软件定义网络(Software Defi ned Network,SDN)的概念。SDN网络包括由许多交换机和路由器等数据节点组成的数据传输网络和一个对所有数据节点统一管理和控制的控制节点组成,控制节点和数据节点间通过基于开放流OpenFlow协议通信。

目前业界的SDN网络的架构如图3所示,SDN网络主要由数据面、控制面和服务面三层结构组成。数据面主要由支持OpenFlow协议的交换机或路由器设备组成,这种设备在支持数据交换分发的基本功能基础上需要具备SDN网络所需的3个要素:(1)每个数据节点设备内保存一张可供控制节点读写的流表,流表由一条条流规则组成,每条流规则包括流的传输层属性和对应的动作组成,当前Type 0的OpenFlow设备支持简单的四种动作:转发、丢弃、本地处理和上送控制节点;(2)数据节点和控制节点保持一条安全的通信链路;(3)支持基于OpenFlow的通信协议交互过程。控制面由单一控制节点组成,控制节点和每个数据节点保持一条基于OpenFlow协议的通信链路,控制节点可以通过OpenFlow协议读写每个数据节点的流表,从而既可以感知每个节点的状态,又可以控制每个节点的转发规则,调节网络路由、带宽资源分配等。在目前的SDN网络结构中,服务面是一个抽象的层次,通常是指控制节点可以实现的功能,如控制节点通过全网数据节点状态的感知实现动态的路由分配、流量负载均衡、网络状态监控和故障的快速定位分析等传输层业务功能。

下面以数据报文的首个数据包为例描述SDN网络中报文的处理流程。如图3所示:

1.客户端的请求报文首个数据包进入到SDN网络中的数据节点A。

2.节点A对报文进行流表匹配命中默认规则send to controller并上送控制节点。

3.控制节点根据网络当前状态,结合一定的带宽、路由分配策略为业务流分配一条路由,并将规则通过OpenFlow协议下发给相应的数据节点,然后在数据节点的流表中添加这条流对应的规则。

4.然后,控制节点再将报文转回给上送的数据节点。

5.各个数据节点按照流表规则依次转发报文。

下面结合图3描述支持OpenFlow协议的数据节点的流表格式,

在《openflow-spec-v1.1.0》中,如图3右上方的表所示,定义的格式为:

InPort:数据包进入数据节点的端口,如:交换机设备的某个网口;

VLANID:TCP/IP协议中介于二层三层之间的一个标签字段,源端可以打标签,目的端可以根据标签不同区分处理;

Ethernet SA:源端物理地址,源MAC(Medium Access Control,介质访问控制)地址;

Ethernet DA:目的端物理地址,目的MAC地址;

Ethernet Type:表示承载的2层报文类型,例如:0x8000表示IP报文;

IP SA:源端的IP地址;

IP DA:目的端的IP地址;

IP Proto:IP层上层承载的协议类型,例如:0x6表示承载TCP协议类型报文

TCP Src:表示源端的TCP端口;

TCP Dst:表示目的端的TCP端口。

如图3所示,(1)对于来源是端口6,VLAN(Virtual Local Area Networ k,虚拟局域网)号是2002的业务流,流表匹配的规则是转发到端口1;(2)对于来源是端口1,目标地址是1.1.1.1的业务流,流表匹配规则是drop(放弃);(3)对于来源是端口6,通信端口是80的业务流,流表匹配的规则是local(本地处理);(4)对于其它业务流,默认的流表匹配规则是controller,上传到控制节点。

SDN网络的概念和设备主要应用在校园网、实验室等小规模适合集中管理控制的网络中,而且服务面主要针对的是传输层业务问题(如:路由控制、网络流量均衡、网络故障检测和快速诊断、动态链路调整等方面)并未涉及应用层相关业务(比如:URL过滤,网络应用加速,IPS防御,报文协议分类,HTTP重定向业务等等。)的处理的解决方法,本发明正是针对SDN网络结构的局限提出的改进扩展方法,本发明在SDN网络基础上提出了一种通过控制层多节点分层部署方式实现全网共享业务能力和应用层相关业务处理的方法。

如图4所示,根据本发明实施例的一种基于软件定义网络中的数据处理系统40,所述系统40包括:源数据节点411,用于接收第一数据包,并向对应的源控制节点421发送所述第一数据包;源控制节点421,用于接收所述源数据节点411发送的第一数据包,所述第一数据包携带有第一数据包的目标地址;根据所述第一数据包的目标地址确定目标控制节点422;目标控制节点422,用于接收所述第一数据包,根据所述第一数据包和匹配策略规则生成第二数据包。

在本发明的一个实施例中,根据源数据节点411的IP地址域或者根据源数据节点411与控制节点的映射关系确定对应的源控制节点421。可以在源数据节点411处存储数据节点与控制节点的映射关系表,通过查表的方式确定源数据节点411对应的源控制节点421,也可以根据源数据节点411的IP地址域或者物理拓扑结构通过计算的方式确定对应的源控制节点421,可以理解的是,上述只是为了帮助理解本发明实施例而做出的一种举例,不能视为对本发明实施例的一种限制。根据源数据节点确定源控制节点还包括其它本领域普通技术人员无需创造性劳动即可实现的方式。

在本发明的一个实施例中,源控制节点421具体用于接收源数据节点411发送的第一数据包,所述第一数据包携带有第一数据包的目标地址;根据第一数据包的目标地址确定目标数据节点413;若源控制节点421不管理目标数据节点413,则将管理源数据节点411和所述目标数据节点413的第一控制节点确定为目标控制节点422。

如图4所示,源控制节点421既可以与目标控制节点422直接相连,也可以通过其它的控制节点423(图中只显示出一个,实际情况可能有多个控制节点)间接的与目标控制节点422相连。在另一种可能的实现方式中,源控制节点421也管理目标控制节点413,这时可以把源控制节点421确定为目标控制节点422,(图中未示出)。

在本发明的一个实施例中,源控制节点421或源数据节点411还用于将第一数据包发送给目标控制节点422。

在本发明的一个实施例中,所述匹配策略规则包括:子元组信息与动作参数或策略参数的映射/对应关系,或者应用层信息与动作参数或策略参数的映射关系;目标控制节点422具体用于:接收所述第一数据包,根据所述第一数据包的子元组信息或第一数据包的应用层信息从所述匹配策略规则中查找到与所述第一数据包的子元组信息或第一数据包的应用层信息对应的动作参数或策略参数;并根据所述查找到的动作参数或策略参数生成所述第二数据包。

所述处理规则是指数据节点根据数据包的元组信息和流表匹配结果得到的对应流表项和流表项中指定的处理动作和参数。流表匹配后得到的是数据节点的一条流表项,包括处理的动作(send to controller,local,forward。。。)和参数。

在本发明的一个实施例中,子元组信息包括:数据包的源/目的MAC地址,源/目的IP地址,源/目的TCP端口,进/出数据节点(交换机)的网口,以及数据包的VLAN标签,这些信息可以从数据包中取得。

在本发明的一个实施例中,如图21所示,1.网络管理员首先通过管理面配置策略规则集并下发给控制面的控制节点;举例:策略规则比如是:规则(1)IF tcp.port=80&&url=http://www.xxx.com THEN redirect to http://www.yyy.com;规则(2)IF tcp.port=8080&&ip.src=10.10.10.*THEN block;策略规则集是若干策略规则组成的集合;2.控制节点根据策略规则集合建立策略匹配树,举例:如上策略规则建立的策略匹配树如图21,树中内部节点为条件节点,叶子节点为动作节点,每个边代表匹配上的条件。3.控制节点对收到的数据包提取tcp/ip/url等元组信息,并进入匹配树跟节点开始规则匹配,最终到达一个叶子节点,命中相应的规则动作。

控制节点会将传输层的条件(L4层的条件)下发给数据节点,比如tcp.port=80和ip.src=10.10.10.*,并为下发的条件标记一个编号如0x0001和0x0002即数据节点流表的业务参数字段。数据节点再对数据包进行流表匹配命中流表项后上送控制节点时,再将这个业务参数字段值附加在数据包中带给控制节点如将业务参数0x0001带给控制节点,控制节点根据编号0x0001对应到已经命中条件tcp.port=80,则直接从匹配树的url节点进一步规则匹配,无需再从匹配树的根节点开始重新匹配数据包的传输层(L4层条件)。可以理解的是,上述举例只是为了帮助理解本发明实施例而做出的一种示例,而不是对本发明实施例具体方案的一种限制,预设的策略规则可以采用别的方式制定规则,控制节点也可以在命中条件之后,依赖上述实施例举出的其它应用层信息进行进一步规则匹配。

在上述举例中,应用层信息可以是数据包的URL信息,如下表所示,应用层信息可以是下表所述的信息中的之一:

在本发明的一个实施例中,数据处理系统40还包括一个或多个服务节点(如图431,432,433);所述匹配策略规则包括:子元组信息与动作参数或策略参数的映射/对应关系,或者应用层信息与动作参数或策略参数的映射关系;目标控制节点422具体用于:接收所述第一数据包,根据所述第一数据包的子元组信息或第一数据包的应用层信息从所述匹配策略规则中查找到与所述第一数据包的子元组信息或第一数据包的应用层信息对应的动作参数或策略参数;并根据所述查找到的动作参数或策略参数向所述一个或多个服务节点中具有执行所述动作参数或策略参数的能力的第一服务节点431发送能力请求信息;第一服务节点431用于针对所述能力请求信息向目标控制节点422发送相应的能力响应信息;目标控制节点422根据所述能力响应信息生成所述第二数据包。

在本发明的一个实施例中,目标控制节点422还用于向源数据节点411发送第二数据包,所述第二数据包携带有所述第二数据包的目标地址;源数据节点411还用于在目标控制节点422管理下向所述第二数据包的目标地址对应的数据节点发送所述第二数据包。

在本发明的一个实施例中,数据处理系统40还包括:至少一个中继数据节点412(图中只示出1个,实际情况可以存在多个中继数据节点),其中,目标控制节点422用于管理每一个中继数据节点412;中继数据节点412存储有对应中继数据节点412的流表,所述流表用于存储数据包的处理规则;源数据节点411存储有对应源数据节点411的流表,所述流表用于存储数据包的处理规则:目标控制节点422还用于生成路由分配规则并向中继数据节点412和源数据节点411下发所述路由分配规则,所述路由分配规则用于为所述第二数据包分配路由;中继数据节点412还用于接收目标控制节点422发送的所述路由分配规则,并根据所述路由分配规则更新中继数据节点412的流表;源数据节点411还用于:根据所述更新后的流表向所述第二数据包的目标地址对应的中继数据节点412发送所述第二数据包;中继数据节点412用于:根据所述更新后的流表向所述第二数据包的目标地址对应的目标数据节点413发送所述第二数据包。

在本发明的一个实施例中,源数据节点411还存储有流表,所述流表用于存储业务流数据包的子元组信息和对应所述子元组信息的处理规则;所述目标控制节点422还用于在源数据节点411的流表中添加控制节点编号字段和业务参数字段,其中,所述控制节点编号字段用于表示源数据节点411对应的目标控制节点422的索引,所述业务参数字段用于表示对应业务流数据包的子元组信息的处理结果的索引。

在本发明的一个实施例中,每个数据节点设备内保存一张可供控制节点读写的初始流表,流表由一条条流规则组成,每条流规则包括流的传输层属性和对应的动作组成,当前Type 0的OpenFlow设备支持简单的四种动作:转发、丢弃、本地处理和上送控制节点。如图12所示,而本发明的实施例通过在初始流表中增加添加控制节点编号Control node和业务参数Para实现对控制面多节点的功能支持。控制节点编号Control node和业务参数Para可以由源控制节点通过OpenFlow协议修改数据节点的流表规则时添加,控制节点编号Control node由源控制节点指定,表示当数据节点对当前业务流需要发送到目标控制节点时对应的上送的目标控制节点的唯一标示;业务参数Para为加快控制节点业务处理提供业务流的相关信息,通常是根据业务流的传输层信息匹配到对应的策略条件按或者策略动作,如业务流已经匹配的传输层策略条件或者业务流命中的规则等。可以理解的是,上述对数据节点保存的流表字段的修改只是为了帮助理解本发明实施例而做出的一种举例,并不能够被设为对本发明实施例的一种具体限制。对流表字段的增加可以是在数据节点预设的,也可以是由最终数据节点完成的。在某些情况下,可以只在数据节点的流表中增加添加控制节点编号Control node,而业务参数Para提供的业务流的相关信息可以由控制节点根据预设策略匹配规则和业务流数据包匹配后获得。增加业务参数Para的主要目的是为了加快控制节点处理相关业务流信息,提供网络运行的效率。扩展的OpenFlow流表结构在原有流表基础上扩展控制节点编号(Control Node)和业务参数(Para)两个字段。控制节点编号用来唯一确定上送的控制节点,业务参数可以是策略匹配的中间匹配结果或者是命中的策略规则,这两个字段由控制节点添加到数据节点的流表中,数据节点在命中这条流规则并上送控制节点时再将策略匹配参数通过TCP-options字段带给控制节点,控制节点可以根据这个参数加速规则匹配或者执行相应的业务。

就一个具体的数据业务流而言,一般情况下数据业务流的首个数据包会匹配上默认的流表规则,数据节点根据默认的流表规则将第一数据包发送给控制节点,控制节点根据第一数据包进一步进行规则匹配,然后根据规则匹配的结果会在数据节点的流表中添加流表规则,此时控制节点会在数据节点的流表中扩展控制节点编号(Control Node)和业务参数(Para)两个字段,这条数据业务流的后续数据包就可以匹配上这两个新添加的规则,然后按照新规则从数据节点转发。具体规则可以参考图21的示例。

在本发明的一个实施例中,所述源数据节点还用于接收第三数据包,其中,所述第三数据包和所述第一数据包均属于所述业务流数据包,且对应所述第三数据包的子元组信息的处理规则和对应所述第一数据包的子元组信息的处理规则相同。

在本发明的一个实施例中,所述源数据节点还用于根据所述流表,从与所述第三数据包的子元组信息匹配的处理规则记录中确定与所述子元组信息对应的业务参数,所述业务参数用于表示对所述第三数据包所要执行的动作参数或策略参数的索引;所述源数据节点将所述业务参数携带在第三数据包中向所述目标控制节点发送;所述目标控制节点还用于根据所述业务参数和所述第三数据包的应用层信息确定对所述第三数据包执行的动作参数或策略参数,从而生成第四数据包。

具体实现的方式可以如图22所示,对于第一数据包的操作,匹配的是默认的流表规则,这里不再赘述。而对于和第一数据包具有相同的子元组信息处理规则的第三数据包而言,处理规则有些不同。这里所述的第三数据包,既可以是与第一数据包来自同一个业务流的数据包,也可以是对应的流表匹配时需要使用的子元组信息相同,而其它子元组信息不一定相同的业务流数据包。子元组信息是数据包元组信息的子集,例如数据包可以由3元组,5元组,10元组组成,子元组信息则可以相应的有多种组合,例如只从3元组里选择1个子元组,或者选择2个子元组。在本发明的一个实施例中,子元组信息包括:数据包的源/目的MAC地址,源/目的IP地址,源/目的TCP端口,进/出数据节点(交换机)的网口,以及数据包的VLAN标签,这些信息可以从数据包中取得。可以理解的是,上述关于子元组信息的列举和第三数据包的说明只是为了帮助理解本发明实施例而做出的一种解释,并不能视为对本发明实施例的一种具体限制。

如图22和图21所示,控制节点会将传输层的条件(L4层的条件,在一种具体示例中可以理解为子元组信息匹配的条件)下发给数据节点,比如tcp.port=80和ip.src=10.10.10.*,并为下发的条件标记一个编号如0x0001和0x0002即数据节点流表的业务参数字段(在一种具体示例中可以理解为子元组信息匹配的结果)。数据节点再对第三数据包进行流表匹配命中流表项后,可以根据目标控制节点参数字段直接将第三数据包上送到目标控制节点,而不需要再经过源控制节点转发,第三数据包在上送到目标控制节点时携带有业务参数字段值,对应第三数据包的业务参数字段值是目标控制节点在对第一数据包进行策略匹配时写入到源控制节点的流表中去的,第三数据包将这个业务参数字段值附加在数据包中带给控制节点如将业务参数0x0001带给控制节点,控制节点根据编号0x0001对应到已经命中条件tcp.port=80,则直接从匹配树的url节点进一步规则匹配,无需再从匹配树的根节点开始重新匹配数据包的传输层(L4层条件)。这样可以加速目标控制节点的匹配运算,提高网络处理效率。

在本发明的一个实施例中,控制节点和数据节点有至少两条链路连接,其中一条是传输数据包的数据链路,一条是传输控制包的控制链路,数据节点将数据包发送给控制节点使用的是数据链路,控制节点修改数据节点的流表字段使用的是控制链路。

服务节点可以为多控制节点提供统一的应用层业务的处理能力,比如如下能力:

缓存共享能力:所有控制节点可以共享缓存信息,一个控制节点请求的数据如果可以在缓存中找到,直接取缓存数据,提高网络访问性能;

链路质量信息共享:所有控制节点可以将当前链路状态信息共享,控制节点在分配路由时可以根据链路状态优化路由选择;

P2P协议类的peer地址信息共享,可以在为P2P类协议请求时选择提供局域网内的peer地址列表,提高P2P类下载速度;

网络加速业务报文压缩解压缩能力。

各种业务处理能力通过开放的OpenAPI的接口方式提供给控制节点调用,各种能力可以以多线程、多进程、多设备的方式部署;相同能力之间可以通过共享池共享数据,共享能力池可以是全局变量、共享内存或者统一资源访问设备的形式,控制节点可以通过调用服务节点的能力对第一数据包进行处理,生成处理后的第二数据包。

根据本发明第一方面实施例的SDN网络系统40,通过控制节点的分层部署方式、扩展的数据节点流表结构和根据策略规则的能力分配方法,实现了SDN网络中的对应用层业务处理和能力共享分配,提高节点的协同合作从而降低网络设备中多节点处理的冗余,解决了节点能力分配不合理、能力不对称、能力不聚合等问题,提高网络的业务处理效率;同时,分层控制节点的部署方式,既解决了控制节点处理性能瓶颈问题,又保持了网络的稳定、可靠和可扩展性。

下面结合图5描述根据本发明第一方面实施例的一种数据处理的SDN网络系统50。如图5所示,SDN网络系统50包括:数据面51,数据面51包括至少两个的数据节点,其中,接收业务流数据包的数据节点为源数据节点;控制面52,控制面52包括至少一个的控制节点,所述控制节点用于按照预设规则管理所述数据面的数据节点,其中,源控制节点Cnode1管理源数据节点511;源数据节点511向源控制节点Cnode1发送第一请求信息,所述第一请求信息包括源数据节点511接收的第一数据包,所述第一数据包包括第一数据包的目标地址;源控制节点Cnode1根据所述第一数据包的目标地址确定目标控制节点522;目标控制节点522根据所述第一数据包和预设策略规则生成第二数据包;源数据节点511接收目标控制节点522发送的第二数据包,并在目标控制节点522管理下发送所述第二数据包。

在本发明的一个实施例中,所述控制节点用于按照预设规则管理所述数据面的数据节点包括:将数据面51的所述数据节点的分组,得到至少两个分组后的数据节点;所述控制节点采用分层管理的方式,其中,一个底层控制节点管理一组所述分组后的数据节点;一个上层控制节点管理至少一个的所述底层控制节点,即一个所述上层控制节点管理至少一组所述分组后的数据节点;顶层控制节点管理全部所述数据面51的数据节点。

在本发明的一个实施例中,如图11所示,数据面包含多个边缘数据节点,(中继数据节点未画出)并以对称扇形划分为若干个区域,图11中标记出A区域和B区域,控制面由多层的控制节点组成,控制节点node1和node2分别管理区域A和区域B中的边缘数据节点和中继数据节点(图中未示出),控制节点node1和node2的父节点node11管理区域A和区域B的所有节点,依次类推,控制节点通过分层的方式,父节点的可以管理所有子节点管理的全部区域,最上层的控制节点可以管理数据面全部的数据节点。

在本发明的一个实施例中,源控制节点Cnode1根据所述数据包的目标地址确定目标控制节点522包括:根据所述第一数据包的目标地址确定目标数据节点512;若源控制节点Cnode1管理目标数据节点512,则将源控制节点Cnode1确定为目标控制节点522。可以理解的是,为了描述简便,本实施例并未在图5中示出。

在本发明的一个实施例中,若源控制节点Cnode1不管理目标数据节点512,则将同时管理源数据节点511和目标数据节点512的第二控制节点确定为所述目标控制节点522。

在本发明的一个实施例中,目标控制节点522根据所述第一数据包和匹配策略规则生成第二数据包包括:目标控制节点522根据匹配策略规则对所述第一数据包进行策略规则匹配,得到策略匹配后的结果;若目标控制节点522能够执行所述策略匹配后的结果,则目标控制节点522根据所述策略匹配后的结果生成所述第二数据包。匹配策略规则可以是目标控制节点对数据包所要执行的对应的动作或参数,也可以是目标控制节点根据应用层业务的需要对数据包做的处理。

在本发明的一个实施例中,网络系统50还包括:服务面53,服务面53用于为控制面52提供业务处理能力;若目标控制节点522不能够执行所述策略匹配后的结果,则目标控制节点522根据所述策略匹配后的结果向服务面53发送能力请求信息;服务面53针对所述能力请求信息向目标控制节点522发送相应的能力响应信息;目标控制节点522根据所述能力响应信息生成所述第二数据包。服务面53可以为多控制节点提供统一的应用层业务的处理能力,这种能力可以对应执行数据包的策略匹配后结果,各种业务处理能力通过开放的应用程序的接口方式OpenAPI提供给控制节点调用,各种能力可以以多线程、多进程、多设备的方式部署;相同能力之间可以通过共享池共享数据,共享能力池可以是全局变量、共享内存或者统一资源访问设备的形式。

在本发明的一个实施例中,网络系统50还包括:管理面54,管理面54用于管理数据面51的网络拓扑结构、控制面52的策略规则、服务面53的业务处理能力中的至少之一。网络拓扑管理包含数据面节点间的连通路径、端口分配和每个数据节点接入的客户端IP地址段范围。策略规则管理是指用户配置的业务处理的相关规则,策略规则由传输层或者应用层策略条件和对应的业务处理动作组成。管理面可以在SDN网络系统初始设置时实现上述管理方式,也可以在SDN网络系统运行时根据SDN网络的实时情况或者用户需要对上述管理方式进行设置或修改。

根据本发明第二方面实施例的SDN网络系统50,通过控制节点的分层部署方式、扩展的数据节点流表结构和根据策略规则的能力分配方法,实现了SDN网络中的对应用层业务处理和能力共享分配,提高节点的协同合作从而降低网络设备中多节点处理的冗余,解决了节点能力分配不合理、能力不对称、能力不聚合等问题,提高网络的业务处理效率;同时,分层控制节点的部署方式,既解决了控制节点处理性能瓶颈问题,又保持了网络的稳定、可靠和可扩展性。

下面结合图6描述本发明第二方面实施例的一种基于软件定义网络的数据处理的方法:

如图6所示,所述方法包括:

S61:源数据节点接收第一数据包。

S62:源数据节点向对应的源控制节点发送所述第一数据包,所述第一数据包携带有第一数据包的目标地址,以使所述源控制节点根据所述第一数据包的目标地址确定目标控制节点以及使得所述目标控制节点根据所述第一数据包生成第二数据包。

S63:所述源数据节点接收所述目标控制节点发送的第二数据包。

根据本发明第二方面实施例提供的一种基于软件定义的网络(SDN)中数据处理的方法,通过在控制节点处对数据节点接收的数据包进行多种处理的方式,在提高了节点之间的协同合作能力的同时可以降低网络设备中多节点处理的冗余;还增强了网络设备对业务流数据包的处理能力,提高了网络的业务处理效率。

下面结合图7描述本发明第三方面实施例的一种软件定义的网络中数据处理的方法:

如图7所示,所述方法包括:

S71:目标控制节点接收第一数据包,所述第一数据包携带有第一数据包的目标地址,其中,所述目标控制节点是由源控制节点根据所述第一数据包的目标地址确定的。

S72:所述目标控制节点根据所述第一数据包和匹配策略规则生成第二数据包。

S73:并向源数据节点发送所述第二数据包。

根据本发明第三方面实施例提供的一种基于软件定义的网络(SDN)中数据处理的方法,通过在控制节点处对数据节点接收的数据包进行多种处理的方式,在提高了节点之间的协同合作能力的同时可以降低网络设备中多节点处理的冗余;还增强了网络设备对业务流数据包的处理能力,提高了网络的业务处理效率。

下面结合图8描述本发明第四方面实施例的一种基于软件定义网络的数据节点10,数据节点10包括:第一接收模块101、第一发送模块102,其中,第一接收模块101和第一发送模块102相连。第一接收模块101用于接收第一数据包,第一发送模块102用于向对应的源控制节点发送所述第一接收模块101接收的所述第一数据包,以使所述源控制节点根据所述第一数据包的目标地址确定目标控制节点以及使得所述目标控制节点根据所述第一数据包生成第二数据包;所述第一接收模块101还用于接收所述目标控制节点发送的所述第二数据包。

根据本发明第五方面实施例提供的一种基于软件定义的网络(SDN)的数据节点10,在提高了节点之间的协同合作能力的同时可以降低网络设备中多节点处理的冗余;还增强了网络设备对业务流数据包的处理能力,提高了网络的业务处理效率。

数据节点,10外部设备或控制节点通信相连,用来接收和处理外部设备或控制节点发送来的数据流,并用于向外部设备或控制节点发送相关的数据信息。

在本发明的一个实施例中,数据节点10还包括:流表103,流表用于存储数据包的元组信息和对应所述元组信息的处理规则。元组信息包括:数据包的源/目的MAC地址,源/目的IP地址,源/目的TCP端口,进/出数据节点(交换机)的网口,以及数据包的VLAN标签,这些信息可以从数据包中取得。

流表由一条条流规则组成,每条流规则包括流的传输层属性和对应的动作组成,当前Type 0的开放流OpenFlow设备支持简单的四种动作:转发、丢弃、本地处理和上送控制节点。

在本发明的一个实施例中,若所述第一数据包满足预设的所述处理规则,则第一发送模块102向所述源控制节点发送第一请求信息。

在本发明的一个实施例中,数据节点10还包括:第一处理模块104,第一处理模块104用于根据第一接收模块101接收到的所述目标控制节点信息得到目标控制节点;

第一处理模块104还用于根据所述目标控制节点信息在流表103中添加控制节点编号字段和业务参数字段,所述控制节点编号字段用于表示源数据节点对应的目标控制节点,所述业务参数字段用于表示所述源数据节点对数据包的处理规则的结果。

在本发明的一个实施例中,如图12所示,而本发明的实施例通过在初始流表中增加添加控制节点编号Control node和业务参数Para实现对控制面多节点的功能支持。控制节点编号Control node和业务参数Para可以由源控制节点通过OpenFlow协议修改数据节点的流表规则时添加,控制节点编号Control node由源控制节点指定,表示当数据节点对当前业务流需要发送到目标控制节点时对应的上送的目标控制节点的唯一标示;业务参数Para为加快控制节点业务处理提供业务流的相关信息,通常是根据业务流的传输层信息匹配到对应的策略条件按或者策略动作,如业务流已经匹配的传输层策略条件或者业务流命中的规则等。可以理解的是,上述对数据节点保存的流表字段的修改只是为了帮助理解本发明实施例而做出的一种举例,并不能够被设为对本发明实施例的一种具体限制。对流表字段的增加可以是在数据节点预设的,也可以是由最终数据节点完成的。在某些情况下,可以只在数据节点的流表中增加添加控制节点编号Control node,而业务参数Para提供的业务流的相关信息可以由控制节点根据预设策略匹配规则和业务流数据包匹配后获得。增加业务参数Para的主要目的是为了加快控制节点处理相关业务流信息,提供网络运行的效率。

在本发明的一个实施例中,在流表103中添加控制节点编号字段和业务参数字段包括:处理模块104根据流表103对接收到的数据包进行规则匹配处理,并将规则匹配处理后的结果填入流表103中;第一发送模块102通过流表103的所述业务参数字段将所述数据包规则匹配处理后的结果向所述目标控制节点发送。

在本发明的一个实施例中,控制节点编号用来唯一确定上送的控制节点,业务参数可以是策略匹配的中间匹配结果或者是命中的策略规则,这两个字段由控制节点添加到数据节点的流表中,数据节点在命中这条流规则并上送控制节点时再将策略匹配参数通过TCP-options字段带给控制节点,目标控制节点可以根据这个参数加速规则匹配或者执行相应的业务。

下面结合图9描述本发明第五方面实施例的一种基于软件定义网络中数据处理的目标控制节点11,目标控制节点11包括:第二接收模块111,第二接收模块111用于接收第一数据包,所述第一数据包携带有第一数据包的目标地址,其中,所述目标控制节点是由源控制节点根据所述第一数据包的目标地址确定的;

第二处理模块113,用于根据第二接收模块111接收的所述第二数据包和匹配策略规则生成第二数据包;

第二发送模块112,用于将所述第二处理模块113生成的所述第二数据包向源数据节点发送,其中,所述源数据节点接收所述第一数据包,并对应所述源控制节点。。

其中,第二处理模块113可以是处理器或其它具有数据处理能力的设备。

根据本发明第五方面实施例提供的一种基于软件定义的网络(SDN)中数据处理的目标数据节点11,在提高了节点之间的协同合作能力的同时可以降低网络设备中多节点处理的冗余;还增强了网络设备对业务流数据包的处理能力,提高了网络的业务处理效率。

目标控制节点11与数据节点或源控制节点通信相连,在本发明的一个实施例中,目标控制节点11也与服务节点通信相连。目标控制节点11用来接收和处理数据节点、源控制节点、服务节点发送来的数据流,并用于向数据节点、源控制节点、服务节点发送相关的数据信息。

在本发明的一个实施例中,目标控制节点11还包括第二发送模块112,第二发送模块112用于将处理模块113生成的所述第二数据包发送给所述源数据节点。

在本发明的一个实施例中,目标控制节点11还包括管理模块114,管理模块114用于管理所述源数据节点发送所述第二数据包。

在本发明的一个实施例中,第二发送模块112还用于向所述源数据节点发送响应信息,所述响应信息用于在所述源数据节点的流表中添加控制节点编号字段和业务参数字段,所述控制节点编号字段用于表示所述源数据节点对应的目标控制节点,所述业务参数字段用于表示所述源数据节点对数据包的处理规则的结果。

在本发明的一个实施例中,处理模块113根据所述第一数据包和预设策略规则生成第二数据包,包括:处理模块113根据预设策略规则对所述第一数据包进行策略规则匹配,得到策略匹配后的结果;若处理模块113能够执行所述策略匹配后的结果,则处理模块113根据所述策略匹配后的结果生成所述第二数据包。若处理模块113不能够执行所述策略匹配后的结果,则第二发送模块112根据处理模块113执行所述策略匹配后的结果向服务节点发送能力请求信息;处理模块113根据第二接收模块111从所述服务节点接收到的能力响应信息生成所述第二数据包,其中,所述能力响应信息是所述服务节点针对相应的所述能力请求信息所生成的。

以下结合具体的实现细节描述上面所述的一种基于SDN网络系统中数据处理的方法、节点和系统,需要注意的是,为了简便起见,用于系统中的某些实现方式也可以应用在方法或装置中,用于方法中的某些实现方式也可以应用在系统或装置中。可以理解的是,下述实现方式只是为了帮助理解本发明而做出的一种具体示例,而不是对本发明实施例技术方案的限制,本发明实施例的技术方案还包括其它本领域普通技术人员无需创造性劳动即可实现的其它方式。

下面结合图5描述根据本发明实施例的一种数据处理的SND系统的结构和功能。

如图5所示,数据处理的SND系统以功能划分的来看包括四个功能面:数据面、控制面、服务面和管理面;以业务数据处理角度来看包括三层,从下至上依次为数据层、控制层和服务层。

(1)数据面由数据交换节点组成,数据节点兼容现有SDN网络节点功能,并可以支持基于OpenFlow协议与控制节点之间进行通信。数据面负责根据控制面下发的流表规则完成业务流的转发处理功能。

数据面的数据节点可以分为两类:边缘数据节点,和外部设备连通并允许外部设备接入网络的节点,这种节点主要负责和外部设备进行数据交互,前述的源数据节点、目标数据节点都属于边缘数据节点;中继数据节点,只和内部其他的数据节点连通的节点,中继数据节点在SDN网络中只和中继数据节点或边缘数据节点相连,并不与外部设备直接通信相连产生数据交互,而是间接通过边缘数据节点与外部设备通信相连。

在本发明的一个实施例中,每个数据节点设备内保存一张可供控制节点读写的初始流表,流表由一条条流规则组成,每条流规则包括流的传输层属性和对应的动作组成,当前Type 0的OpenFlow设备支持简单的四种动作:转发、丢弃、本地处理和上送控制节点。如图12所示,而本发明的实施例通过在初始流表中增加添加控制节点编号Control node和业务参数Para实现对控制面多节点的功能支持。控制节点编号Control node和业务参数Para可以由源控制节点通过OpenFlow协议修改数据节点的流表规则时添加,控制节点编号Control node由源控制节点指定,表示当数据节点对当前业务流需要发送到目标控制节点时对应的上送的目标控制节点的唯一标示;业务参数Para为加快控制节点业务处理提供业务流的相关信息,通常是根据业务流的传输层信息匹配到对应的策略条件按或者策略动作,如业务流已经匹配的传输层策略条件或者业务流命中的规则等。可以理解的是,上述对数据节点保存的流表字段的修改只是为了帮助理解本发明实施例而做出的一种举例,并不能够被设为对本发明实施例的一种具体限制。对流表字段的增加可以是在数据节点预设的,也可以是由最终数据节点完成的。在某些情况下,可以只在数据节点的流表中增加添加控制节点编号Control node,而业务参数Para提供的业务流的相关信息可以由控制节点根据预设策略匹配规则和业务流数据包匹配后获得。增加业务参数Para的主要目的是为了加快控制节点处理相关业务流信息,提供网络运行的效率。

下面结合图12描述根据本发明实施例的数据面具体的功能实现方式,如图12所示,因为一个数据节点可能和控制面的多个控制节点连通,所以数据节点在流表动作send to controller即上送控制节点时,需要指明上送控制节点的唯一标记。因此,如图10所示,扩展的OpenFlow流表结构在原有流表基础上扩展控制节点编号(Control Node)和业务参数(Para)两个字段。控制节点编号用来唯一确定上送的控制节点,业务参数可以是策略匹配的中间匹配结果或者是命中的策略规则,这两个字段由控制节点添加到数据节点的流表中,数据节点在命中这条流规则并上送控制节点时再将策略匹配参数通过TCP-options字段带给控制节点,控制节点可以根据这个参数加速规则匹配或者执行相应的业务。

数据节点2针对来源于IP地址范围在1.1.*.*的业务流预设的上传的源控制节点为控制节点1。

对于从端口6进入的业务流,如果其VLAN号为2002,数据节点2默认的匹配规则是将该业务流转发到port1,此时并不涉及应用层业务的处理,在数据节点2处即可完成对应匹配规则的处理动作;

对于从端口1进入的业务流,如果其IP地址为2.2.2.2,数据节点2默认的匹配规则是丢弃该业务流的数据包,此时也不涉及应用层业务的处理,在数据节点2处即可完成对应匹配规则的处理动作;

对于从端口6进入的业务流,如果其通信端口为80,数据节点2的匹配规则是将该业务流的数据包上送控制节点,对应的控制节点编号为1,即上送到控制节点1,业务参数Para值为10,即命中对应10的策略规则,例如该策略规则可以是例如策略规则是:

IF port=80&&url=www.xxx.com THEN redirect to url=www.yyy.com

其中port=80的条件对应业务参数10。

对于其它业务流,数据节点2的匹配规则是将该业务流的数据包上送控制节点,对应的控制节点编号为1,即上送到控制节点1,业务参数Para值为0,即命中对应0的策略规则,例如该策略规则可以是该规则可以是:

IF url=www.xxx.com THEN redirect to url=www.zzz.com。

策略规则是网络管理员通过管理面的规则管理配置进来的,控制节点根据规则具体涉及传输层或者应用层的条件(策略规则的IF部分),下发流表参数给数据节点,如对应业务参数10的例子中,数据节点只匹配到数据包端口80这个信息就可以通过业务参数10带给控制节点,控制节点根据业务参数知道数据节点已经匹配了这个数据包满足条件port=80,控制节点只需要继续匹配url是否满足url=www.xxx.com的条件就可以,不需要再匹配数据包的端口号,这个例子和业务参数值为0的例子的区别在于控制节点根据业务参数0和10区分是否匹配了port=80的条件。

可以理解的是,上述实施例只是为了帮助理解本发明实施例而作出的一种示例,并不能视为对本发明实施例的一种具体限制。本发明实施例还可以包括其它本领域普通技术人员无需创造性劳动即可实现的其它方式。

(2)控制面除了兼容SDN网络已有的传输层业务功能,如流量控制、路由分配、负载均衡等之外,还负责完成应用层的业务,如协议识别、解析,策略规则的匹配并根据规则匹配结果下发动作给数据节点和调用相应的服务功能。

本发明中控制面通过多节点分层部署方式,根据数据节点的位置和业务流的IP地址信息,按照区域和流划分每个控制节点管理的业务流。并满足一条业务流始终被统一个控制节点管理的原则。

在本发明的一个实施例中,控制面以对称扇形划分数据面的区域,每个控制节点可以管理一个对称区域内的边缘数据节点和全部的中继数据节点。控制节点按区域管理的方法如图11中所示。数据面包含多个边缘数据节点,(中继数据节点未画出)并以对称扇形划分为若干个区域,图14中标记出A区域和B区域,控制面由多层的控制节点组成,控制节点node1和node2分别管理区域A和区域B中的边缘数据节点和中继数据节点,控制节点node1和node2的父节点node11管理区域A和区域B的所有节点,依次类推,控制节点通过分层的方式,父节点的可以管理所有子节点管理的全部区域,最上层的控制节点可以管理数据面全部的数据节点。

业务流确定所属管理的控制节点具体流程如图15所示,控制节点在首次收到数据节点上送的业务流时,根据业务流的目的IP地址和路由选择结果确定业务流进入网络和离开网络数据面的数据节点所在区域,如果业务流离开网络的数据节点位置和进入网络的数据节点位置不在当前控制节点的管理区域范围内,则控制节点会将业务流上送上一层控制节点处理,依次类推,业务流根据进入和离开网络的节点位置所在区域被最终确定在某一个控制节点管理。

以业务流的IP地址划分控制节点的方法允许一个数据节点同时被多个控制节点管理,数据节点可以根据业务流的IP地址范围选择对应的控制节点。

在本发明的一个实施例中,如图13所示,数据节点采取如下方式根据业务流的IP地址范围选择对应的控制节点:

控制面由多个控制节点组成,控制节点按对称扇形区域划分控制的数据节点,控制节点node1和node2同时控制区域A范围内的数据节点,数据节点根据源IP将业务流分配给不同的数据节点,IP范围在1.1.1.1~1.1.1.127的业务流在流表中对应的控制节点编号1(对应控制节点node1),而IP范围在1.1.1.128~1.1.1.254的业务流在流表中对应的控制节点编号2(对应控制节点node2)。数据节点针对不同的IP地址范围对应的控制节点编号可以预设在数据节点的流表里。可以理解的是,上述实施例只是为理解对本发明实施例而做出的一种示例,并不能视为对本发明实施例的一种具体限制。如图15所示,还可以根据不同的IP地址范围确定上层控制节点,对于IP范围在1.1.1.1~1.1.1.127的业务流,其上层控制节点为node11,而IP范围在1.1.1.128~1.1.1.254的业务流对应上层控制节点node22。

(3)服务面可以为多控制节点提供统一的应用层业务的处理能力,比如如下能力:

缓存共享能力:所有控制节点可以共享缓存信息,一个控制节点请求的数据如果可以在缓存中找到,直接取缓存数据,提高网络访问性能;

链路质量信息共享:所有控制节点可以将当前链路状态信息共享,控制节点在分配路由时可以根据链路状态优化路由选择;

P2P协议类的peer地址信息共享,可以在为P2P类协议请求时选择提供局域网内的peer地址列表,提高P2P类下载速度;

网络加速业务报文压缩解压缩能力。

各种业务处理能力通过开放的OpenAPI的接口方式提供给控制节点调用,各种能力可以以多线程、多进程、多设备的方式部署;相同能力之间可以通过共享池共享数据,共享能力池可以是全局变量、共享内存或者统一资源访问设备的形式。

在本发明的一个实施例中,服务面的能力执行过程包括:控制节点根据规则配置向服务面注册某种能力,服务面为控制节点复制能力,同时控制节点在业务处理流程中分配能力的执行点;当控制节点匹配上某个业务处理动作时,则激活处理链中的能力执行点通过开放接口调用服务面的处理业务的能力。

在本发明的一个实施例中,服务面的能力执行过程包括:(1)初始化注册阶段,控制节点启动时根据当前在控制节点的业务规则全集,如:当前控制节点上配置了缓存共享,则控制节点向服务面首先进行能力注册,服务面在收到控制节点的能力注册请求后,则分配相应的资源给控制节点,如分配数据存储空间和为当前注册节点的信息初始化操作,同时控制节点在内部处理流程中分配能力的执行点,如在命中规则后的动作执行阶段,分配能力的调度点。(2)运行阶段的能力激活,控制节点在执行业务处理过程中在能力调度点需要调度业务层的某种能力时,则控制节点向服务面发起能力执行请求,如缓存能力共享业务中控制节点向服务面发起请求缓存信息,服务面收到控制节点的执行请求后,根据控制节点请求的缓存内容索引查找共享缓存池,如果找到则返回给控制节点缓存数据,并标志找到缓存,如果服务面在共享缓存池中没有找到则返回空,并标志未找到缓存数据,控制节点根据服务面的能力执行的返回结果,继续业务处理。(3)退出取消注册阶段,控制节点在正常关闭退出时需要向服务面取消注册,由控制节点向服务面发起取消注册请求消息,服务面根据控制节点的请求消息,回收已经分配的资源,如回收分配的空间,并执行将控制节点的注册信息清理操作。

可以理解的是,上述服务面的能力执行过程只是为了帮助理解本发明实施例而作出的一种具体示例,而不是对本发明实施例的一种具体限制,服务面也可以预先设置多种处理能力和服务方式,不需要控制节点向服务面注册。服务面能力实现的方式还包括其它本领域普通技术人员无需创造性劳动即可实现的其它方式。

(4)管理面负责数据面网络拓扑结构管理、策略规则管理和服务面的资源管理。网络拓扑管理包含数据面节点间的连通路径、端口分配和每个数据节点接入的客户端IP地址段范围。策略规则管理是指用户配置的业务处理的相关规则,策略规则由传输层或者应用层策略条件和对应的业务处理动作组成。管理面可以在SDN网络系统初始设置时实现上述管理方式,也可以在SDN网络系统运行时根据SDN网络的实时情况或者用户需要对上述管理方式进行设置或修改。

在本发明的一个实施例中,管理面负责数据面网络结构的管理、数据节点和控制节点的连接拓扑管理、策略规则管理、和服务面的资源管理。管理面是提供给网络管理员的配置管理界面,在系统启动初始化阶段,网络管理员将拓扑信息通过管理面下发给各个控制节点,为后续控制节点路由分配时提供链路连接信息;策略规则信息由多条规则组成,每条策略规则由L1-4层或者应用层条件和对应的业务动作组成,如:规则1:IF(条件)IP=10.10.10.*并且url=www.abcd.com/*的业务流,THEN(动作)redirect url=www.xxxx.com/portal执行重定向动作,其中IP=10.10.10.*是传输层信息构成的条件,url=是L7层信息构成的条件;管理面提供网络管理员规则配置接口,由网络管理员配置策略规则集,并通过管理面将规则分发给控制节点,控制节点根据分配的规则集合完成初始化,包括向服务面注册能力。

如图14所示,本发明的实施例中通过管理面策略规则的集中管理,并根据用户的配置策略规则分配数据节点和控制节点的能力,具体方法是根据业务流的请求或者响应类型和进网络和出网络的位置划分六个业务处理点:①请求报文进网络的数据节点;②请求报文进入的控制节点;③请求报文出网络的数据节点;④响应报文进网络的数据节点;⑤响应报文进入的控制节点;⑥响应报文出网络的数据节点。根据策略规则的条件类型,动作类型分配业务的处理点和为节点分配相应的能力,分配方法如图所示,从物理上看,①和⑥对应同一个物理数据节点,②和⑤对应同一个物理控制节点,③和④对应同一个物理数据节点。

举例1:策略条件是依赖传输层报文信息的条件且策略动作是丢弃或者转发等非业务动作,则需要在位置①和④分配数据节点对应的传输层条件作为OpenFlow流表的元组,流表的动作为策略动作(转发或者丢弃)。

举例2:策略条件是依赖请求报文的传输层信息的条件且策略动作是某种业务处理,则需要在位置①分配数据节点对应的传输层条件作为OpenFlow流表的元组,流表动作为sendto controller上送控制节点,Control Node为位置②的控制节点编号,策略参数为对应的业务动作的索引,同时需要在位置②分配控制节点策略动作对应的业务处理能力。控制节点根据数据节点上送报文的策略参数可以直接索引到应该执行的相应业务处理。

举例3:策略条件是依赖响应报文的传输层和应用层信息的条件且策略动作是某种业务处理,则需要在位置④分配数据节点对应的传输层条件作为OpenFlow流表的元组,流表动作为sendto controller上送控制节点,Control Node为位置⑤的控制节点编号,策略参数为传输层信息的策略匹配的中间结果,同时需要在位置⑤分配控制节点7层的协议识别解析、规则匹配和相应业务处理能力。控制节点根据数据节点上送报文的策略参数获得报文传输层条件匹配的中间结果,并结合应用层处理得到的报文信息完成策略匹配,再根据策略匹配结果执行相应的业务处理。

下面结合图16描述根据本发明实施例的一种数据处理的SDN网络系统的数据流。

如图16所示,根据本发明实施例的一种数据处理的SDN网络系统,

源数据节点接收到业务流数据包后,首先在源数据节点处对数据包进行传输层的流表匹配,根据命中的规则执行相应的动作。如果命中的匹配规则是上送控制节点,则执行1。

1.源数据节点1向源控制节点1发送数据信息,该数据信息包括了源数据节点接收到的业务流的首数据包。源控制节点1根据业务流的首数据包的目标IP地址确定目标控制节点2。

2.目标控制节点2针对源数据节点1发送的数据信息通过OpenFlow协议修改源数据节点的流表规则,添加控制节点编号和业务参数字段。控制节点编号为当前业务流需要上送控制节点时对应上送的控制节点唯一标示。业务参数字段由目标控制节点2下发给源数据节点1,标记源数据节点中流表项对应的策略规则索引。

3.源数据节点1根据流表规则,对数据包进行规则匹配,并最终匹配到一条流表规则R,并根据流表规则R的动作参数转发、本地处理或者上送控制节点,如果动作是上送控制节点则根据流表规则R中上送控制节点的编号选择上送的控制节点,并将流表规则R中业务参数字段填入数据包的扩展字段中,例如通过TCP-options字段将业务参数带给控制节点,业务参数字段由目标控制节点2写入数据节点1的流表中,控制节点可以通过数据包中携带的业务参数加速业务规则匹配过程。

4.初始控制节点1将接收到的业务流的数据包发送给最终数据节点2,以便最终数据节点2处理,业务参数字段是在这里随数据包添加到扩展字段的TCP-options字段里面带给目标控制节点2的。

5.服务面可以为目标控制节点2提供统一的应用层业务的处理能力,各种业务处理能力可以通过开放的OpenAPI的接口方式提供给目标控制节点2调用,目标控制节点2根据从源控制节点1接收到的数据包向服务面发出请求信息,请求调用处理该数据包所需要的服务能力。

6.服务面将目标控制节点2调用的服务能力发送给目标控制节点2,目标控制节点2利用该服务能力对业务流的数据包进行处理,得到处理后的业务流数据包。

7.目标控制节点2将处理后的业务流的数据包发送给源数据节点1,同时目标控制节点2根据网络当前状态,结合一定的带宽、路由分配策略为业务流分配一条路由,并将规则通过OpenFlow协议下发给相应的中继数据节点,在中继数据节点的流表中添加这条流对应的规则。

8.源数据节点1将目标控制节点2处理后的业务流数据包经过一个或多个中继数据节点2向目标数据节点3发送。

可以理解的是,上述实施例只是为了帮助理解本发明实施例而做出的一种具体举例,并不能视为对本发明实施例的一种限制,上述1-8的数据编号上并不能视为对数据流向传输的步骤做出的顺序限制,其中的部分步骤可以交换顺序或按照其他本领域普通技术人员无需创造性劳动即可实现的其它方式执行。

下面结合图17–图20描述本发明实施例的几种具体实现场景。

如图17所示,客户端集群1的某一个业务流的数据报文从数据节点A处进入到SDN网络中,该数据报文经过多个中继数据节点(图中未示出)的传输,最终通过数据节点B处到达服务器集群1。

其中,数据节点A和数据节点B都由控制节点Cnode1管理,控制节点Cnode1通过OpenFlow协议维护数据节点A和数据节点B的流表。(1)客户端发送的业务流数据包首先经过数据节点A;(2)当业务流的第一个数据包(首包)达到数据节点A时,数据节点A通过对数据首包进行流表匹配,得到默认流表项对应的动作是sendto controller,默认的控制节点编号Cnode1,默认业务参数为空;(3)数据节点A根据控制节点编号将该数据包上送至默认控制节点Cnode1,控制节点Cnode1对数据包进行策略规则匹配,假设网络管理员配置了一条策略规则1:IF ip=11.11.11.*&&protocol=HTTP THEN IPS check;规则2:IF ip=11.11.11.*&&url=www.xxx.com THEN block;数据包的策略匹配结果是满足ip=11.11.11.*的编号10条件,则控制节点Cnode1下发给数据节点A增加一条流表项I,内容为元组中ip=11.11.11.*的数据流对应的业务参数10,且根据数据包的目标地址确定数据包出网络的数据节点为B,由于数据节点A和数据节点B都由控制节点Cnode1管理,因此控制节点Cnode1即确定为目标控制节点,控制节点A下发给数据节点流表项I中的控制节点编号为自身节点编号;(4)控制节点Cnode1同样通过OpenFlow协议更新数据流路由上各中继数据节点和数据节点B的流表;(5)控制节点Cnode1将数据包转发回数据节点,各个数据节点按照自己流表规则对数据包匹配转发,最终数据包首包经过数据节点B出网络达到服务器;(6)数据节点根据流表规则处理业务流上的后续数据包。

服务面的共享能力池含有针对HTTP(hypertext transport protocol,超文本传输协议)协议的数据包识别、解析能力,URL(Uniform Resource Locator,统一资源定位器)匹配能力。

控制节点Cnode1基于预设的匹配规则向服务面注册业务处理能力,当需要匹配某个业务处理动作时,则控制节点Cnode1可以通过开放接口激活服务面的业务处理能力。如果需要对业务流进行协议的识别、解析或者URL匹配处理,则控制节点Cnode1调用服务面的业务的处理能力对业务流进行处理,并将处理后的数据包发送给数据节点A。

如上例中,(7)当控制节点Cnode1对业务流的后续报文进行策略匹配如果数据节点上送数据包携带的业务参数为10,即满足ip=11.11.11.*时,则控制节点Cnode1需要进一步对数据包进行匹配是否满足条件url=www.xxx.com和条件protocol=HTTP,控制节点Cnode1向服务面首先激活协议识别、解析能力;(8)服务面在收到控制节点的能力请求时对包进行识别、解析处理,并将结果返回给控制节点;(9)控制节点判断如果识别解析结果为protocol=HTTP则进一步激活URL匹配能力,服务面继续完成对数据包的URL匹配并将结果返回给控制节点;(10)控制节点根据服务面返回结果完成策略匹配,并执行响应策略动作,如匹配上规则2执行动作block阻塞,则控制节点更新数据节点的流表项,将对应业务流在数据节点A中的动作设置为block。可以理解的是,上述实施例只是为了帮助理解本发明实施例而做出的一种具体示例,而不是对本发明实施例技术方案的一种限制。

如图18所示,客户端集群1的某一个业务流的数据报文从数据节点A处进入到SDN网络中,该数据报文经过多个中继数据节点(图中未示出)的传输,最终通过数据节点C处到达服务器集群2。其中,数据节点A和数据节点C都由节点Cnode2管理,数据节点A和数据节点C通过OpenFlow协议与节点Cnode2通信相连。

同上例,数据节点A对业务流(假设源IP为11.11.11.11)首包进行流表匹配,命中默认流表项,并将首包发送给控制节点Cnode2,控制节点Cnode2对数据包首包进行策略规则匹配确定数据包出网络的数据节点C,确定自身为目标控制节点,然后更新数据面业务流需要经过的数据节点的流表。假设网络管理员配置的策略规则:IF ip=11.11.11.*THEN block;控制节点根据报文流经SDN网络的数据节点和控制节点的路径,确定的①请求报文进网络的数据节点A;②请求报文进入的控制节点Cnode2;③请求报文出网络的数据节点C;④响应报文进网络的数据节点C;⑤响应报文进入的控制节点Cnode2;⑥响应报文出网络的数据节点A;控制节点根据规则添加元组为ip=11.11.11.*,动作为block的流表项I给数据节点A;在后续业务流数据包的处理中,当数据节点A对数据包的流表匹配命中流表项I时,则数据节点A直接丢弃数据包,在数据包入口处第一时间匹配命中策略规则,避免后续节点的数据传输和处理,这样就减少了后续节点设备的网络带宽资源,同时避免了后续节点无谓的处理资源的消耗。

可以理解的是,业务流的数据报文也可以是客户端-客户端、服务器-客户端、服务器-服务器等形式;数据节点A和数据节点C可以是在不同的节点管理,再按照前述方式确定控制节点,数据节点A和数据节点C与节点通信连接的形式也不仅局限于OpenFlow协议,还包括其它本领域普通技术人员无需创造性劳动即可采取的通信连接方式;数据节点A和数据节点C也可以不经过中继数据节点直接通信相连。若数据节点A的该业务流有多个目的地址,则只针对目标地址的流表规则为drop的网络路由线路在数据节点A或其后续中继节点处执行drop操作,并不影响其它网络路由线路的传输,网络路由线路和带宽资源分布由控制节点进行管理。可以理解的是,上述只是为了帮助理解本发明实施例的技术方案而做出的一种示例,而不是对本发明实施例的一种限制。本发明实施例的技术方案还包括本领域普通技术人员无需通过创造性劳动即可实现的其它方案。

如图19所示,客户端集群1的某一个业务流的数据报文从数据节点A处进入到SDN网络中,该数据报文经过多个中继数据节点(图中未示出)的传输,最终通过数据节点B处到达服务器。其中数据节点A由节点Cnode1管理,数据节点A通过OpenFlow协议与节点Cnode1通信相连;数据节点B由节点Cnode3管理,数据节点B通过OpenFlow协议与节点Cnode3通信相连。根据节点Cnode1和节点Cnode3确定控制节点CnodeA,确定控制节点的过程前述已经说明,在此不再赘述。

当需要对网络业务流做应用层传输加速时,此时并不需要对数据节点A赋予压缩业务流报文信息的能力。数据节点A在经过规则匹配后将业务流的报文信息上传到控制节点CnodeA,控制节点CnodeA根据业务流的能力需求从服务面获得相应的基于报文内容的压缩能力和解压缩能力,控制节点CnodeA从服务面获得上述能力可以采用开放接口调用的形式完成。在控制节点CnodeA出完成对业务流数据报文的压缩,然后将压缩后的业务流数据报文传输给数据节点A。数据节点A将压缩后的业务流数据报文传输给数据节点B,数据节点B再将该业务流数据报文上传到控制节点CnodeA解压缩,得到解压后的业务流数据报文。这样使得上述客户端集群1的业务流能够完成从数据节点A到数据节点B的应用层传输加速。可以理解的是,上述实施例只是为了帮助理解本发明实施例而做出的一种具体示例,而不是对本发明技术方案的一种限制性解释。

如图20所示,SDN网络结构中服务面含有共享能力池,相同能力之间可以通过共享能力池共享数据,共享能力池可以是全局变量、共享内存或者同一资源访问设备的形式。

客户端集群1中的客户端和客户端集群2中的客户端请求相同的一个流媒体内容,客户端集群1的客户端业务流经过数据节点A接入SDN网络系统。其中数据节点A由节点Cnode1管理,数据节点D由节点Cnode2管理。

首先确定数据节点A的目标控制节点Cnode1,数据节点D的目标控制节点Cnode2,相关过程前面给出,在此不再赘述。控制节点Cnode1和Cnode2都向服务面注册了Cache缓存能力,同时服务面为控制节点Cnode1和Cnode2都分配了Cache缓存数据的读取和写入接口;(1)数据节点A的数据流进过控制节点Cnode1时缓存了流媒体数据内容;(2)数据节点D访问和数据节点A相同的流媒体数据内容,当访问请求数据包经过数据节点D到达控制节点Cnode2时,控制节点Cnode2向服务面激活Cache缓存能力,并通过缓存数据读取接口查找是否有缓存数据,因为控制节点Cnode1已经缓存了数据节点A请求的数据内容,所以控制节点Cnode2找到缓存流媒体内容,并数据封装成响应数据包返回给数据节点D。减少了数据节点D再次从服务器获取数据的过程,提高客户端的响应速度,同时减轻了服务器的处理压力。可以理解的是,上述只是为了帮助理解本发明的技术方案而做出的一种示例,并不能视为对本发明实施例技术方案的一种限制。控制节点也可以通过建立数据节点A和数据节点D通信连接的方式使得数据节点D获得对应的流媒体内容。也可以通过本领域普通技术人员无需创造性劳动即可实现的其它方式。

所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。

另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1