业务数据处理方法、装置和通信传输设备
技术领域
本发明涉及通信技术领域,特别是涉及一种业务数据处理方法、装置和通信传输设备。
背景技术
随着通信技术的发展,隧道技术在通信现网中的应用已较为广泛,隧道技术具备私有性及安全性的特点,所以其主要用来承载通信收发双方的业务数据。然而随着通信技术的发展,处在隧道链路上的物理网元也需要被实际管控到,而用于对这些物理网元管控的业务数据对于通信收发双方而言是冗余的。在隧道内传输着通信现网的业务数据和可服务于物理网元本身的业务数据,因为隧道隔离的缘故,物理网元的控制模块是无法直接获取业务数据的,为此,传统的业务数据处理方式是在物理网元上为需要管控的物理网元提供一条或多条数据链路,以便实现对物理网元自身管理的业务数据的传输。然而,在实现本发明过程中,发明人发现前述传统的业务数据处理方式存在着维护成本较高的问题。
发明内容
基于此,有必要针对上述传统的业务数据处理方式存在的问题,提供一种能够有效降低维护成本的业务数据处理方法、一种业务数据处理装置、一种通信传输设备和一种计算机可读存储介质。
为了实现上述目的,本发明实施例提供以下技术方案:
一方面,本发明实施例提供一种业务数据处理方法,包括:
从数据隧道中提取与配置的业务特征相匹配的本地业务报文;
将所述本地业务报文重定向至本地;
将重定向后的本地业务报文剥离隧道特征后在本地进行业务处理;
对业务处理后产生的响应报文进行隧道特征生成;
将隧道特征生成后的响应报文重定向至本地业务报文的来源端口后插入数据隧道。
在其中一个实施例中,将重定向后的本地业务报文剥离隧道特征的过程,包括:
将重定向后的本地业务报文送入网络协议栈;
在网络协议栈中剥离重定向后的本地业务报文携带的隧道特征字段。
在其中一个实施例中,剥离重定向后的本地业务报文携带的隧道特征字段的过程,包括:
剥离重定向后的本地业务报文中对应数据隧道的VLAN报头,并重新计算报头剥离后的本地业务报文的校验和。
在其中一个实施例中,对业务处理后产生的响应报文进行隧道特征生成的步骤,包括:
将响应报文送入网络协议栈;
在网络协议栈中为响应报文重新生成隧道特征字段。
在其中一个实施例中,将本地业务报文重定向至本地的步骤,包括:
查询预设的端口地址表获取目标目的MAC地址;端口地址表为本地目的MAC地址与本地目的端口的对应关系表;
将本地业务报文的目的MAC地址修改为目标目的MAC地址。
在其中一个实施例中,将本地业务报文重定向至本地的步骤,还包括:
记录本地业务报文的目的MAC地址与本地业务报文的来源端口之间的对应关系。
在其中一个实施例中,将隧道特征生成后的响应报文重定向至本地业务报文的来源端口的过程,包括:
根据本地业务报文的目的MAC地址与本地业务报文的来源端口之间的对应关系,将响应报文的源MAC地址替换为本地业务报文的目的MAC地址。
在其中一个实施例中,业务特征包括二层隧道、三层隧道或应用层隧道的隧道协议中的业务标识。
另一方面,还提供一种业务数据处理装置,包括:
匹配提取模块,用于从数据隧道中提取与配置的业务特征相匹配的本地业务报文;
第一重定向模块,用于将本地业务报文重定向至本地;
隧道剥离模块,用于将重定向后的本地业务报文剥离隧道特征后在本地进行业务处理;
特征生成模块,用于对业务处理后产生的响应报文进行隧道特征生成;
第二重定向模块,用于将隧道特征生成后的响应报文重定向至本地业务报文的来源端口后插入数据隧道。
又一方面,还提供一种通信传输设备,包括存储器和处理器,存储器存储有计算机程序,处理器执行计算机程序时实现上述业务数据处理方法的步骤。
再一方面,还提供一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现上述业务数据处理方法的步骤。
上述各技术方案中的一个技术方案具有如下优点和有益效果:
上述业务数据处理方法、装置和通信传输设备,在通信现网内,通信传输设备的双向数据端口间的数据隧道中,传输着通信现网的用户业务数据和可服务于通信传输设备本身的本地业务数据(本申请统称本地业务报文)。通过利用配置的业务特征从数据隧道中匹配提取对通信传输设备本身有用的本地业务报文,然后利用重定向技术将提取的本地业务报文重定向到通信传输设备本地。进而将本地业务报文剥离隧道特征后进行业务处理并产生相应的响应报文;将产生的响应报文进行隧道特征生成后,利用重定向技术将响应报文重定向到本地业务报文的来源端口,即可插入数据隧道通过该来源端口回应给服务端。如此,无需再单独配置及维护物理或逻辑上的数据链路,即可实现直接获取本地业务报文并处理,以及响应报文向服务端的回应,达到了大幅降低维护成本的目的。
附图说明
图1为一种传统的企业VPN网络结构示意图;
图2为一个实施例中业务数据处理方法的流程示意图;
图3为一个实施例中本地业务报文的重定向处理流程示意图;
图4为一个实施例中隧道剥离与隧道特征生成的处理流程示意图;
图5为一个实施例中通信传输设备的内部功能模块框图;
图6为一个实施例中通信传输设备内部的业务数据处理流程示意图;
图7为一个实施例中业务数据处理装置的模块结构框图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
需要说明的是,除非另有定义,本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体地实施方式的目的,不是旨在于限制本发明。本文所使用的术语“和/或”包括一个或多个相关的所列项目的任意的和所有的组合。
隧道技术一种通过使用互联网络的基础设施,在网络之间建立一条虚拟链路以传递数据的技术,包括数据封装、传输和解包在内的全过程。根据隧道协议的不同,隧道技术可分为基于二层的隧道技术、基于三层的隧道技术以及基于应用层的隧道技术。使用隧道传递的数据可以是不同协议的PDU(即协议数据单元),隧道协议将这些其他协议的PDU重新封装后通过互联网络发送,重新封装后的新的PDU提供了路由信息,以便通过互联网络传递被封装的数据。为了建立隧道,隧道两端的通信方(发送端和接收端)须使用相同的隧道协议。由于PDU经过重新封装,使得数据的发送端和接收端就像在一条专有“隧道”中进行数据传输和通信。
二层基础隧道协议对应于OSI(即Open System Interconnection ReferenceModel,开放式系统互联通信参考模型)模型中的数据链路层,使用帧作为数据交换单位,较常见的隧道协议如PPPOE(Point-to-Point Tunneling Protocol Over Ethernet,以太网上的点对点隧道协议)、802.1Q协议(VLAN)和QINQ(802.1Q in 802.1Q)协议等。
三层基础隧道协议对应于OSI模型的网络层,使用包作为数据交换单位,常见的隧道协议如:IP-in-IP协议和GRE(即Generic Routing Encapsulation,通用路由封装)协议等。应用层对应于OSI模型的第7层,主要的隧道协议有IP安全协议(IPsec,实际是一套协议包)和L2TP(即Layer 2Tunneling Protocol,第二层隧道协议)协议等。
概括来说,隧道是在高层(或同等层)分组中携带低层数据。例如,在一个IPv4(Internet Protocol version 4,互联网协议第四版)或IPv6(Internet ProtocolVersion 6,互联网协议第六版)分组中携带IPv4数据,又例如在一个UDP(即User DatagramProtocol,用户数据报协议)、IPv4或IPv6分组中携带以太网数据。隧道转变了在头部中协议严格分层的思路,并允许形成覆盖网络(即建立的这些“链路”实际是其他协议实现的虚拟链路,而不是物理连接的网络)。通过隧道的建立,可实现将数据强制送到特定的地址、隐藏私有的网络地址、在IP网上传递非IP数据包、提供数据安全支持等功能。
虚拟局域网(VLAN)也是实际应用中一种较常见的“隧道技术”,其是一个多点对多点的技术。与一般理解的基于点对点业务的隧道技术相比,VLAN在拓扑结构上不相称,而从逻辑上说多点对多点是包含点对点的,且VLAN又先天具备互相隔离的属性。因此在运营商的通信现网应用的许多场合(如企业VPN网络)中隧道技术也是同样应用的。
例如图1所示,是一种较为常见的企业VPN组网模式。运营商在通过接入交换机103之后的数据链路增加TPID=0x88A8,VLAN=1024的S-VLAN(即Service Provider VLAN,服务商VLAN),实现物理位置处于异地的企业用户可以连接到企业网络内,而其它网外用户则无法接入进来。其中,企业VPN组网可包括企业数据服务器101(VLAN=100)、企业文件服务器102(VLAN=200)、企业文件服务用户组105(VLAN=200)、企业数据服务用户组104(VLAN=100)等组成部分。
综上可见,隧道技术具备私有性及安全性的特点,因此主要用来承载通信收发双方的业务数据。然而随着通信技术的发展,处在隧道链路上的物理网元(如图1的接入交换机及运营商网络链路上的诸网元)也需要被实际管控到,而用于对这些物理网元管控的业务数据对于通信收发双方而言是冗余的。为了解决这些业务数据传输处理的问题,传统的业务数据处理方式是:运营商网络的运维人员会为需要管控的物理网元提供一条数据链路,以便实现对物理网元自身管理的业务数据的传输,此链路可以是物理上的链路,也可以是逻辑上的链路。
物理链路因为需要占用宝贵的通信现网资源,且对物理网元的网元端口有一定要求,故实际应用中多采用逻辑链路的方式。运维人员会在通信现网的物理网元上做一些相应配置(比如划分一个特殊的管理VLAN)来实现这个逻辑链路建立目的,相应配置完成后,通信现网内的诸网元的配置基本上就不会再改变了,若有网元加入,则在新加入的网元上进行相应配置即可。然而,在实践中,发明人发现上述传统的业务数据处理方式,运维人员除了要配置通信现网的业务传输网络链路外,还需配置维护物理网元的管控链路,存在着维护成本较高的问题。为解决上述传统的业务数据处理方式存在的问题,本申请提供了以下技术方案:
以接入层、汇聚层以及核心传输层中任一层的物理网元(以下统称通信传输设备)为例:
服务端(例如但不限于网管服务器和NTP服务器)发送的用于管控通信传输设备的本地业务报文,通过通信传输设备的某一端口进入该端口与另一端口间的数据隧道时,通信传输设备将会从数据隧道中提取与配置的业务特征相匹配的本地业务报文,然后将提取的本地业务报文重定向至本地;在将本地业务报文送通信传输设备内部的管理控制模块的业务处理功能进程进行业务处理前,将重定向后的本地业务报文剥离隧道特征后即可发送给业务处理功能进程在本地进行业务处理;业务处理后会产生相应的响应报文,此时,由于管理控制模块被数据隧道隔离在外,需要先对业务处理后产生的响应报文进行隧道特征生成,再将该响应报文重定向至本地业务报文的来源端口后即可插入数据隧道,以回应给服务端。
如此,无线运维人员为通信传输设备配置传输本地业务报文的物理或逻辑链路,通信传输设备即可自由地从数据隧道中提取本地业务报文进行处理并将响应报文插入数据隧道回应给服务端,免去了维护传输本地业务报文的物理或逻辑链路的工作,显著降低了管控通信传输设备的业务数据传输处理方面上的维护成本。
请参阅图2,在一个实施例中,提供了一种业务数据处理方法,包括如下步骤S12至S20:
S12,从数据隧道中提取与配置的业务特征相匹配的本地业务报文。
可以理解,业务特征为预先配置到通信传输设备本地的特征参数,例如报文的来源标识或目的标识,又或者是各隧道协议中为本地业务报文规定的业务标识。业务特征可以由运维人员在通信传输设备刚加入通信现网时进行选择并配置,或者在对通信传输设备进行软件升级,以使其具备实现本申请所述的业务数据处理方法的能力时进行选择并配置。
具体的,在通信传输设备中,对于管理控制模块需要使用的本地业务数据,可以使用预先配置的业务特征从数据隧道的数据流中进行识别匹配。当数据流中的某一本地业务报文携带的业务特征与配置的业务特征相匹配时,即识别到所需的本地业务报文,将该本地业务报文从数据隧道中提取出来。
S14,将所述本地业务报文重定向至本地。
具体的,提取得到匹配的本地业务报文后,采用重定向技术将该本地业务报文进行重定向处理,使该本地业务报文的传输目的地变更为重新指定的本地转发端口,以将该本地业务报文从数据隧道取出后往指定的本地位置进行传输。其中,重新指定的本地转发端口可以由通信传输设备的用户(或运维人员)预先设定。例如但不限于针对不同的本地业务报文指定对应的本地转发端口,并将这些设定关系配置到通信传输设备备用,或者是配置到通信传输设备的管理端(如服务端)以供通信设备在需要时发起请求获取相应的本地转发的端口,又或者是通过配置通信传输设备,使之能够根据自身的业务处理能力结合本地业务报文的业务类型自行确定可转发的本地转发端口。
S16,将重定向后的本地业务报文剥离隧道特征后在本地进行业务处理。
可以理解,隧道特征是指本地业务数据中携带的隧道特征字段,例如数据隧道在传输业务报文之前,根据所使用的隧道协议对业务报文进行重新封装时添加的协议报头。
具体的,由于被重定向转发过来的本地业务报文还携带这数据隧道的隧道特征,这会影响管理控制模块的业务处理功能进程对该本地业务报文的正常处理。因此,在将重定向后的本地业务报文送入管理控制模块进行业务处理前,将本地业务报文携带的隧道特征进行剥离处理,去除本地业务报文携带的隧道特征后,再送管理控制模块的业务处理功能进程进行业务处理。
S18,对业务处理后产生的响应报文进行隧道特征生成。
具体的,管理控制模块的业务处理功能进程对本地业务报文进行业务处理后,会产生对应的响应报文,该响应报文需要发送出去,以回应给本地业务报文的来源端——服务端。由于管理控制模块被数据隧道隔离在外,因此,在发送响应报文前,对响应报文进行隧道特征生成处理,重新生成与本地业务报文原来的隧道特征一致的隧道特征,也即重组获得携带相应隧道特征的响应报文。携带隧道特征的响应报文即可以直接插入数据隧道进行传输,而不会再被隔离在数据隧道外。
S20,将隧道特征生成后的响应报文重定向至本地业务报文的来源端口后插入数据隧道。
具体的,隧道特征生成后的响应报文是需要发送到本地业务报文来自的服务端的,因此需要采用重定向技术将该响应报文进行重定向处理,使该响应报文直接重定向到本地业务报文的来源端口。如此,将携带隧道特征并进行重定向后的响应报文插回数据隧道进行传输时,该响应报文即可以传输给服务端,完成通行传输设备接收本地业务报文并处理后,向服务端进行回应的完整过程。
上述业务数据处理方法,通过利用配置的业务特征,从数据隧道中匹配识别对通信传输设备本身有用的本地业务报文,将匹配识别到的本地业务报文从数据隧道中提取出来,然后利用重定向技术将提取的本地业务报文重定向到通信传输设备本地。进而将本地业务报文剥离隧道特征后进行业务处理并产生相应的响应报文;将产生的响应报文进行隧道特征生成后,利用重定向技术将响应报文重定向到本地业务报文的来源端口,响应报文即可插入数据隧道通过该来源端口回应给服务端。如此,通信传输设备可从逻辑上穿透数据隧道,从而可以自由提取本地业务报文并处理,以及将响应报文插入数据隧道回应给服务端;运维人员无需再为通信传输设备单独配置物理或逻辑上的数据链路(设备管控链路),用以传输本地业务报文,只需关注传输的现网用户业务数据等主干业务,免除了对设备管控链路的配置和维护工作,达到了大幅降低维护成本的目的。
请参阅图3,在一个实施例中,关于上述处理步骤S14,具体可以包括如下处理步骤S142和S144:
S142,查询预设的端口地址表获取目标目的MAC地址;端口地址表为本地目的MAC地址与本地目的端口的对应关系表;
S144,将本地业务报文的目的MAC地址修改为目标目的MAC地址。
可以理解,用户可以预先为各类本地业务报文自主设定将要转发的本地目的端口,从而将各本地目的端口及其对应的本地目的MAC地址配置成一个端口地址表。例如根据通信传输设备中各本地目的端口的数据处理能力大小,分别为各类业务报文设定对应的本地目的端口,从而形成一个包含多种业务报文所需转发的本地目的端口及其相应本地目的MAC地址的对应关系表。端口地址表可以预存在通信传输设备中,也可以预存到服务端或者其他第三方网管设备,只要能够在通信传输设备在需要时能够查询到即可。目标目的MAC地址为端口地址表中已为当前的该本地业务报文指定的一个本地目的MAC地址。
具体的,当提取得到匹配的本地业务报文后,依据该本地业务报文查询端口地址表,确定该本地业务报文所需转发至的本地目的端口所对应的本地目的MAC地址,也即目标目的MAC地址。然后将该本地业务报文的目的MAC地址修改为查询到的目标目的MAC地址,即可实现对该本地业务报文的重定向处理。后续过程中,该重定向后的本地业务报文将会安装重定向的目的MAC地址进行转发。
通过上述处理步骤,可以快速完成对本地业务报文的重定向处理,处理过程通过查表的方式得到精简,从而可以有效提升通信传输设备的提取并处理本地业务报文的效率,节省通信传输设备的计算资源。
在一个实施例中,如图3所示,关于上述处理步骤S14,具体可以还可以包括如下处理步骤S146:
S146,记录本地业务报文的目的MAC地址与本地业务报文的来源端口之间的对应关系。
具体的,在对本地业务报文进行重定向处理时,还可以将本地业务报文原来自带的目的MAC地址,与该本地业务报文的来源端口之间的对应关系记录下来,保存在本地备用。如此,当需要向服务端发送本地业务报文对应的响应报文时,即可以通过记录的本地业务报文原来的目的MAC地址与来源端口之间的对应关系,确定响应报文所需重定向到的来源端口所对应的目的MAC地址。
通过上述的处理步骤,可以有效提高通信传输设备对响应报文的重定向处理效率。
请参阅图4,在一个实施例中,关于上述处理步骤S16中,将重定向后的本地业务报文剥离隧道特征的过程,具体可以包括如下处理步骤S162和S164:
S162,将重定向后的本地业务报文送入网络协议栈;
S164,在网络协议栈中剥离重定向后的本地业务报文携带的隧道特征字段。
可以理解,网络协议栈为管理控制模块内置的TCP/IP网络协议栈。具体的,在本实施例中,在将重定向后的本地业务报文送入管理控制模块进行业务处理前,利用网络协议栈建立相应的虚拟接口,针对封装在本地业务报文外层的隧道特征字段进行相应的剥离处理,得到无隧道特征的本地业务报文,以发送给管理控制模块的业务处理功能进程处理。
通过上述处理步骤,可以利用网络协议栈快速实现本地业务报文的隧道特征字段剥离,处理过程简约高效,无需消耗过多的计算资源。
在一个实施例中,关于上述处理步骤S164中,剥离重定向后的本地业务报文携带的隧道特征字段的过程,包括:
剥离重定向后的本地业务报文中对应数据隧道的VLAN报头,并重新计算报头剥离后的本地业务报文的校验和。
可以理解,在上述实施例中,在进行相应的剥离处理的时,可以但不限于将数据隧道对本地业务报文进行封装时添加的所有隧道字段进行剥离,或者将那些直接影响到管理控制模块的业务处理功能进程对本地业务报文处理的部分隧道字段进行剥离。在本实施例中,具体可以是将本地业务报文中的数据隧道的VLAN报头剥离,重新计算校验和。如此,通过这一隧道特征剥离处理,可以精确剥离隧道特征字段同时,确保本地业务报文携带的业务数据不受影响。
在一个实施例中,如图4所示,关于上述处理步骤S18,具体可以包括如下处理步骤S182和S184:
S182,将响应报文送入网络协议栈;
S184,在网络协议栈中为响应报文重新生成隧道特征字段。
具体的,在将响应报文进行重定向之前,需要为响应报文加入相应的隧道特征字段:将响应报文送入网络协议栈建立相应的虚拟接口,重新生成带有隧道特征字段的报文,例如为响应报文添加数据隧道对应的VLAN报头。
通过上述的处理步骤,可以为本地业务报文对应的响应报文重新带上隧道特征字段,进而确保后续能够在数据隧道中传输,以回应给服务端。
在一个实施例中,关于上述处理步骤S20中,将隧道特征生成后的响应报文重定向至本地业务报文的来源端口的过程,具体可以包括如下处理步骤:
根据本地业务报文的目的MAC地址与本地业务报文的来源端口之间的对应关系,将响应报文的源MAC地址替换为本地业务报文的目的MAC地址。
可以理解,在一些实施方式中,响应报文的重定向处理,可以通过在通信传输设备或者服务端上预先为不同本地业务报文对应的响应报文设定对应的重定向目的MAC地址,用于替换响应报文自带的源MAC地址。
具体的,在本实施例中,本地业务报文对应的响应报文是需要经由数据隧道发送给服务端的,因此,需要修改响应报文的源MAC地址。直接根据通信传输设备在对本地业务报文进行重定向时记录的本地业务报文的目的MAC地址与其来源端口之间的对应关系,将响应报文的源MAC地址修改成相应本地业务报文的目的MAC地址,则该响应报文被重定向到相应本地业务报文的在数据隧道中的来源端口。
如此,重定向后的响应报文可以直接进入数据隧道并插入数据隧道中的数据流进行传输,最终会通过重定向后确定的前述来源端口发送至服务端进行处理。
通过上述的MAC地址替换处理,可以快速且精准地将响应报文重定向至相应本地业务报文的来源端口,从而使得响应报文可以在数据隧道中准确发送至服务端。
在一个实施例中,上述处理过程中涉及的业务特征包括二层隧道、三层隧道或应用层隧道的隧道协议中的业务标识。
可以理解,在对本地业务报文进行业务特征匹配时,可以先进行常用的报文的特征匹配,如源MAC地址、目的MAC地址、源IP地址、目的IP地址和/或端口号等报文的特征匹配,在逐渐深入匹配数据隧道中业务报文的特征参数的匹配。不同的数据隧道可以利用的业务特征不同,因此,上述列举的二层隧道、三层隧道和应用层隧道,仅是以其中几种常见的隧道技术作为示例,本领域技术人员可以根据类似的设计构思,扩展到其他未列举出来的隧道技术的应用。
具体的,若数据隧道是二层的802.1q隧道或qinq隧道,则可以根据VLAN ID(虚拟局域网标识)和/或TPID(Tag Protocol Identifier,标签协议标识)等业务标识进行特征匹配。若数据隧道是二层的PPPOE隧道,则可以根据PPPOE协议中的Session ID(会话标识)和/或Code(编码)等业务标识进行特征匹配。
若数据隧道是三层的IP-in-IP隧道,则可以根据外层IP header(IP报头)中的业务特征结合内层IP header内的业务特征进行特征匹配。若数据隧道是三层的GRE隧道,则可以根据GRE协议中的Protocol Type(协议类型)结合外层IP header(IP报头)中的业务特征进行特征匹配。若数据隧道是应用层的L2TP隧道,则可以根据外层IP header(IP报头)中的业务特征结合协议Tunnel ID(隧道号)和/或Session ID(会话标识)等业务特征进行特征匹配。对应其他类型的数据隧道的特征匹配处理原理及过程同理类似,此处不再一一赘述。
在一个实施例中,为了更易于理解上述各实施例,下面从通信传输设备内部的软件功能模块的角度进行举例说明:
由于通信传输设备是用于数据传输的,因此通信传输设备基本上会设置有2个以上的双向物理网络端口。通信传输设备内部的功能组件可划分为管理控制模块和数据传输模块两大类。例如图5所示,数据传输模块上的三个双向物理网络端口1、2和3中,假设端口2和端口3之间存在一条数据隧道,数据隧道内传输着通信现网的用户业务数据,以及可服务于通信传输设备本身的本地业务数据(如上述的本地业务报文)。由于数据隧道的缘故,管理控制模块的端口是从逻辑上被数据隧道隔离的,因此管理控制模块是无法直接从数据隧道中获取其可用的本地业务数据的。
本申请的技术方案中,通过对通信传输设备进行软件升级改造,使得原本被数据隧道隔离的管理控制模块,可以从数据隧道中把对其有用的本地业务数据提取出来在本地进行处理,经过接收响应后,把应答的响应报文再次插入到数据隧道内回应给服务端(如网管服务器、NTP服务器等),从而实现通信传输设备的本地业务的正常运作。图5所示,传输数据B表示的是对通信传输设备有用的本地业务数据,例如网管类的TR069数据、CONN数据、YANG数据和SNMP数据,或者NTP报文与PTP报文等数据。传输数据A表示的是通信传输设备不可用的用户业务数据,例如加密后用户多媒体业务数据,如http、https和igmp等协议数据。
图5和图6所示,在数据传输模块中,可以设置用来进行业务特征匹配与报文提取的特征匹配模块、对匹配到的本地业务报文以及相应的响应报文分别进行重定向处理的重定向模块。而在管理控制模块中,可以设置用来对重定向后转发上来的本地业务报文进行隧道特征剥离处理,以及用于对响应报文进行隧道特征生成处理的隧道特征处理模块。
对应任一在数据隧道内传输的本地业务报文b,被特征匹配模块匹配到并提取出数据隧道后,经过重定向处理而被重定向至本地转发端口1。重定向后的本地业务报文b在送入管理控制模块的业务处理功能进程处理前,会经过隧道特征处理模块剥离携带的隧道特征字段。管理控制模块的业务处理功能进程处理本地业务报文b后产生相应的响应报文b0,该响应报文b0在插入回数据隧道进行传输前,先经过隧道特征处理模块重新生成隧道特征字段,再由重定向模块将该响应报文b0重定向到相应本地业务报文b的来源端口后,最终即可通过数据隧道发送给服务端。通过上述技术方案,通信传输设备即可自由地提取或插入本地业务数据(如上述的本地业务报文b和响应报文b0),而数据隧道内正常传输的用户业务数据A则不受影响。
如此,对于通信传输设备的运维人员而言,以往需要单独给通信传输设备配置一条物理或逻辑上的管控通路,以实现本地业务数据的传输;在使用本发明的技术方案,只需要关注传输的主干业务,不需要在再耗费精力维护通信传输设备的管控通路,大大减轻了工作负担,达到了大幅降低维护成本的目的。
应该理解的是,虽然图2至图4的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且图2至图4中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些子步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
请参阅图7,在一个实施例中,还提供一种业务数据处理装置100,包括匹配提取模块11、第一重定向模块13、隧道剥离模块15、特征生成模块17和第二重定向模块19。匹配提取模块11用于从数据隧道中提取与配置的业务特征相匹配的本地业务报文。第一重定向模块13用于将本地业务报文重定向至本地。隧道剥离模块15用于将重定向后的本地业务报文剥离隧道特征后在本地进行业务处理。特征生成模块17用于对业务处理后产生的响应报文进行隧道特征生成。第二重定向模块19用于将隧道特征生成后的响应报文重定向至本地业务报文的来源端口后插入数据隧道。
上述业务数据处理装置100,通过各模块的协作,利用配置的业务特征从数据隧道中匹配提取对通信传输设备本身有用的本地业务报文,然后利用重定向技术将提取的本地业务报文重定向到通信传输设备本地。进而将本地业务报文剥离隧道特征后进行业务处理并产生相应的响应报文;将产生的响应报文进行隧道特征生成后,利用重定向技术将响应报文重定向到本地业务报文的来源端口,即可插入数据隧道通过该来源端口回应给服务端。如此,无需再单独配置及维护物理或逻辑上的数据链路,即可实现直接获取本地业务报文并处理,以及响应报文向服务端的回应,达到了大幅降低维护成本的目的。
在一个实施例中,上述第一重定向模块13可以包括地址获取子模块和地址修改子模块。地址获取子模块用于查询预设的端口地址表获取目标目的MAC地址;端口地址表为本地目的MAC地址与本地目的端口的对应关系表。地址修改子模块用于将本地业务报文的目的MAC地址修改为目标目的MAC地址。
在一个实施例中,上述第一重定向模块13可以包括来源记录子模块,用于记录本地业务报文的目的MAC地址与本地业务报文的来源端口之间的对应关系。
在一个实施例中,上述隧道剥离模块15在将重定向后的本地业务报文剥离隧道特征的过程中,具体可以用于将重定向后的本地业务报文送入网络协议栈,以在网络协议栈中剥离重定向后的本地业务报文携带的隧道特征字段。
在一个实施例中,上述隧道剥离模块15在剥离重定向后的本地业务报文携带的隧道特征字段的过程中,具体可以用于剥离重定向后的本地业务报文中对应数据隧道的VLAN报头,并重新计算报头剥离后的本地业务报文的校验和。
在一个实施例中,上述特征生成模块17具体可以用于将响应报文送入网络协议栈,以在网络协议栈中为响应报文重新生成隧道特征字段。
在一个实施例中,上述第二重定向模块19在将隧道特征生成后的响应报文重定向至本地业务报文的来源端口的过程中,具体可以用于根据本地业务报文的目的MAC地址与本地业务报文的来源端口之间的对应关系,将响应报文的源MAC地址替换为本地业务报文的目的MAC地址。
关于业务数据处理装置100的具体限定,可以参见上文中业务数据处理方法的相应限定,在此不再赘述。上述业务数据处理装置100中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于通信传输设备中的处理器中,也可以以软件形式存储于通信传输设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作,该通信传输设备可以是通信传输设备。
在一个实施例中,还提供一种通信传输设备,该通信传输设备包括存储器和处理器,存储器存储有计算机程序,处理器执行计算机程序时实现以下步骤:从数据隧道中提取与配置的业务特征相匹配的本地业务报文;将所述本地业务报文重定向至本地;将重定向后的本地业务报文剥离隧道特征后在本地进行业务处理;对业务处理后产生的响应报文进行隧道特征生成;将隧道特征生成后的响应报文重定向至本地业务报文的来源端口后插入数据隧道。
本领域技术人员可以理解,本实施例中的通信传输设备除上述的存储器和处理器外,还可以包括其他的组成部分,具体可以根据实际应用中具体的通信传输设备的结构组成及其实现的功能确定,本说明书中不再一一展开说明。前述通信传输设备可以是接入层、汇聚层以及核心传输层的各传输设备,例如但不限于二层千兆/万兆交换机(或者同类型设备),又或者是SOHO路由器等。
在一个实施例中,处理器执行计算机程序时还可以实现上述业务数据处理方法各实施例中的增加的步骤或者子步骤。
在一个实施例中,还提供一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现以下步骤:从数据隧道中提取与配置的业务特征相匹配的本地业务报文;将所述本地业务报文重定向至本地;将重定向后的本地业务报文剥离隧道特征后在本地进行业务处理;对业务处理后产生的响应报文进行隧道特征生成;将隧道特征生成后的响应报文重定向至本地业务报文的来源端口后插入数据隧道。
在一个实施例中,计算机程序被处理器执行时,还可以实现上述业务数据处理方法各实施例中的增加的步骤或者子步骤。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限,RAM以多种形式可得,诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线式动态随机存储器(Rambus DRAM,简称RDRAM)以及接口动态随机存储器(DRDRAM)等。
以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。以上实施例仅表达了本发明的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改进,这些都属于本发明的保护范围。因此,本发明专利的保护范围应以所附权利要求为准。