一种时延收集的方法及装置与流程

文档序号:16063025发布日期:2018-11-24 12:23阅读:181来源:国知局

本发明涉及一种数据网络通信领域,特别涉及一种时延收集的方法及装置。

背景技术

rsvp-te(resourcereservationprotocol-trafficengineer,基于流量工程的资源预留协议)是一种基于mpls(multi-protocollabelswitching,多协议标签交换)的流量工程技术。通过信息发布、路径计算、信令交互(rsvp-te)、流量的转发四个部件实现业务流量在te(trafficengineer,流量工程)隧道中的转发。

rsvp-te隧道用于承载l2vpn(l2virtualprivatenetwork,l2虚拟专用网络)和l3vpn(l3virtualprivatenetwork,l3虚拟专用网络),同时通过静态路由、策略路由等形式参与路由计算。rsvp-te已经越来越多的服务于各个业务,提供基础的管道服务。随之而来的,对隧道路径的约束也越来越高,如基础的带宽约束,跳数约束、链路代价、亲和力、时延约束等。

随着rsvp-te管道的广泛使用,对rsvp-te建立的管道时延方面有提出了差分的要求,精细化隧道提供的服务能力,隧道路径的实际时延,有助于业务的隧道选择。例如,时延低的rsvp-te隧道管道提供给对时延敏感的业务,时延高的rsvp-te隧道管道提供给对时延不敏感的业务。要想满足精细化隧道提供的服务能力的要求,需要隧道的时延进行收集。

在ip(internetprotocol,网络之间互连的协议)光网络中,建立的uni(usernetworkinterface,用户侧接口)隧道,更多的呈现在ip网络中为一个虚拟的链路,如何反应这条虚拟链路的时延,需要借助隧道时延的收集。

然而,rsvp-te隧道如何收集实际路径的时延,反应在隧道上的总时延,业界还没有相关的技术和方法定义。



技术实现要素:

为了解决上述技术问题,本发明实施例提供了一种时延收集的方法及装置。通过时延收集请求的类型和不同节点的本地策略来收集整个路径的时延,通过收集到的不同节点的时延来标识这条隧道所产生的虚拟链路或者通道,以便虚拟链路的选择和后续业务叠加在虚拟链路上。

依据本发明实施例的一个方面,提供了一种时延收集的方法,包括:

接收上游节点发送的时延收集请求,所述时延收集请求的类型包括:强制请求和非强制请求;

根据所述时延收集请求的类型和当前节点的本地策略,判断所述当前节点是否支持时延的收集,得到判断结果,其中,所述判断结果包括:所述当前节点支持时延的收集和所述当前节点不支持时延的收集;

根据所述时延收集请求的类型和所述判断结果,向所述上游节点或所述当前节点的下游节点发送相应的信息。

可选地,根据所述时延收集请求的类型和所述判断结果,向所述上游节点或所述当前节点的下游节点发送相应的信息,包括:

如果所述时延收集请求的类型为强制请求,且所述当前节点支持时延的收集时,将所述当前节点的时延和所述时延收集请求发送给所述当前节点的下游节点;或者

如果所述时延收集请求的类型为强制请求,且所述当前节点不支持时延的收集时,向所述上游节点发送路径错误消息;或者

如果所述时延收集请求的类型为非强制请求,且所述当前节点支持时延的收集时,将所述当前节点的时延和所述时延收集请求发送给所述当前节点的下游节点;或者

如果所述时延收集请求的类型为非强制请求,且所述当前节点不支持时延的收集时,仅将所述时延收集请求发送给所述当前节点的下游节点。

可选地,所述时延设置在基于流量工程的资源预留协议rsvp-te扩展信令的类型、子域取值的长度和/或子域取值的信息中。

可选地,所述时延收集请求的类型通过扩展的rsvp-te信令表示。

可选地,使用标签交换路径需求属性lsp_required_attributes的扩展位来表示强制请求;

使用标签交换路径属性lsp_attributes的扩展位来表示非强制请求。

依据本发明实施例的另一个方面,还提供了一种时延收集装置,包括:

接收模块,用于接收上游节点发送的时延收集请求,所述时延收集请求的类型包括:强制请求和非强制请求;

判断模块,用于根据所述时延收集请求的类型和当前节点的本地策略,判断所述当前节点是否支持时延的收集,得到判断结果,所述判断结果包括:所述当前节点支持时延的收集和所述当前节点不支持时延的收集;

发送模块,用于根据所述时延收集请求的类型和所述判断结果,向所述上游节点或所述当前节点的下游节点发送相应的信息。

可选地,所述发送模块包括:

第一发送单元,用于如果所述时延收集请求的类型为强制请求,且所述当前节点支持时延的收集时,将所述当前节点的时延和所述时延收集请求发送给所述当前节点的下游节点;

第二发送单元,用于如果所述时延收集请求的类型为强制请求,且所述当前节点不支持时延的收集时,向所述上游节点发送路径错误消息;

第三发送单元,用于如果所述时延收集请求的类型为非强制请求,且所述当前节点支持时延的收集时,将所述当前节点的时延和所述时延收集请求发送给所述当前节点的下游节点;

第四发送单元,用于如果所述时延收集请求的类型为非强制请求,且所述当前节点不支持时延的收集时,仅将所述时延收集请求发送给所述当前节点的下游节点。

可选地,所述时延设置在基于流量工程的资源预留协议rsvp-te扩展信令的类型、子域取值的长度和/或子域取值的信息中。

可选地,所述时延收集请求的类型通过扩展的rsvp-te信令表示。

可选地,使用标签交换路径需求属性lsp_required_attributes的扩展位来表示强制请求;

使用标签交换路径属性lsp_attributes的扩展位来表示非强制请求。

本发明的实施例具有如下有益效果:

根据时延收集请求的类型和当前节点的本地策略向上游节点或当前节点的下游节点发送相应的信息,来完成整个路径的时延的收集。隧道作为一个虚拟链路或者虚通路存在,通过收集到的不同节点的时延来标识这条隧道所产生的虚拟链路或者通道,以便后续业务叠加在虚拟链路上和虚拟链路的选择,例如:隧道层次化、ip光网络虚通路应用在ip侧。

附图说明

图1为本发明实施例提供的一种时延收集的方法的流程图;

图2为本发明实施例提供的另一种时延收集的方法的流程图;

图3为本发明实施例的扩展的tlv信息的结构示意图;

图4为本发明实施例的ip光网络的组网场景;

图5为本发明实施例的时延收集的方法示意图;

图6为本发明实施例的时延收集的装置的结构示意图。

具体实施方式

为使本发明要解决的技术问题、技术方案和优点更加清楚,下面将结合附图及具体实施例进行详细描述。

图1是本发明实施例提供的一种时延收集的方法的流程图,参见图1,时延收集的方法包括以下步骤:

s101,接收上游节点发送的时延收集请求,所述时延收集请求的类型包括:强制请求和非强制请求(或称为建议请求);

可根据隧道的策略要求决定携带时延收集请求的类型,其中隧道的策略要求基于本地用户的配置决定。所述时延收集请求的类型可通过扩展的rsvp-te信令表示。

具体地,可以使用rfc(requestforcomments,请求评议)5420中的标签交换路径需求属性lsp_required_attributes的扩展位来表示强制请求。可以使用rfc(requestforcomments,请求评议)5420中的标签交换路径属性lsp_attributes的扩展位来表示非强制请求。

s102,根据所述时延收集请求的类型和当前节点的本地策略,判断所述当前节点是否支持时延的收集,得到判断结果,所述判断结果包括:所述当前节点支持时延的收集和所述当前节点不支持时延的收集;

s103,根据所述时延收集请求的类型和所述判断结果,向所述上游节点或所述当前节点的下游节点发送相应的信息。

根据所述时延收集请求的类型和当前节点的本地策略向所述上游节点或所述当前节点的下游节点发送相应的信息,来完成整个路径的时延的收集;隧道作为一个虚拟链路或者虚通路存在,通过收集到的不同节点的时延来标识这条隧道所产生的虚拟链路或者通道,以便后续业务叠加在虚拟链路上和虚拟链路的选择。

图2为本发明实施例提供的另一种时延收集的方法的流程图,参见图2,时延收集的方法包括以下步骤:

s201,接收上游节点发送的时延收集请求,所述时延收集请求的类型包括:强制请求和非强制请求(或称为建议请求);

可根据隧道的策略要求决定携带时延收集请求的类型,其中隧道的策略要求基于本地用户的配置决定。

可选地,所述时延收集请求的类型通过扩展的rsvp-te信令表示。

具体地,隧道头节点将所述时延收集请求的类型携带在path(路径)消息中,可以使用rfc5420中的lsp_required_attributes的扩展位来表示强制请求。可以使用rfc5420中的lsp_attributes的扩展位来表示非强制请求,当然并不见限于此。

s202,根据所述时延收集请求的类型和当前节点的本地策略,判断所述当前节点是否支持时延的收集,得到判断结果,所述判断结果包括:所述当前节点支持时延的收集和所述当前节点不支持时延的收集;

s203,如果所述时延收集请求的类型为强制请求,且判断结果为所述当前节点支持时延的收集时,将所述当前节点的时延和所述时延收集请求发送给所述当前节点的下游节点;

s204,如果所述时延收集请求的类型为强制请求,且判断结果为所述当前节点不支持时延的收集时,向所述上游节点发送路径错误消息;

s205,如果所述时延收集请求的类型为非强制请求,且判断结果为所述当前节点支持时延的收集时,将所述当前节点的时延和所述时延收集请求发送给所述当前节点的下游节点;

s206,如果所述时延收集请求的类型为非强制请求,且判断结果为所述当前节点不支持时延的收集时,仅将所述时延收集请求发送给所述当前节点的下游节点。

其中,所述时延设置在rsvp-te扩展信令的类型、子域取值的长度和/或子域取值的信息中。具体地,参见图3,扩展的tlv(t:type(类型)、l:length(子域取值长度)、v:value(子域取值))信息可携带类型、子域取值的长度、子域取值和/或保留信息。在本实施例中可将不同节点的时延设置在扩展的tlv信息中,扩展的tlv信息可以是rro(record-routeobject,记录路由子对象)的一个子对象。

下面对本发明实施方式进行举例说明。

举例一:

例如,如果所述当前节点支持时延的收集时,则将当前节点出接口的时延加入扩展的tlv信息中,作为rro的一个子对象携带给下游节点。同时将所述时延收集请求的类型发送给当前节点的下游节点。

如果所述当前节点不支持时延的收集,当所述时延收集请求的类型是强制请求时,发送path-err(patherror,路径错误)消息给上游节点;如果所述当前节点不支持时延的收集,当所述时延收集请求的类型是建议请求时,将所述时延收集请求的类型发送给当前节点的下游节点,同时rro中不添加有关于扩展的tlv信息的子对象。

尾节点接收到path消息,回应resv(reserve,预留)消息的时候,根据所述时延收集请求的类型的要求,预留消息携带设置有出接口时延的扩展的tlv信息,作为rro的一个子对象携带给上游节点。

举例二:

参见图4,tunnel(隧道或通道)1从r1节点经过r2节点和r3节点通到r4节点,其中r2节点的本地策略不支持时延的收集,剩余节点的本地策略均支持时延的收集。

tunnel1计算出来的路径为链路l1、链路l4、链路l6,同时所述时延收集请求的类型为强制请求,path消息中携带lsp_required_attributes扩展位信息,同时将携带有链路l1的时延的扩展的tlv信息设置在rro子对象中,时延值为10。

r2节点接收到该path消息之后,由于r2节点不支持时延的收集,同时所述时延收集请求的类型为强制请求,此时将回应path-err消息给r1节点,停止发送path消息给r3节点。

r1节点接收到该path-err消息之后,再次计算路径,需要绕过r2节点。

举例三:

继续参见图4,tunnel1从r1节点经过r2节点和r3节点通到r4节点,其中r2节点的本地策略不支持时延的收集,剩余节点的本地策略均支持时延的收集。

tunnel1计算出来的路径为链路l1、链路l4、链路l6,同时所述时延收集请求的类型为建议请求,path消息中携带lsp_attributes扩展位信息,同时将携带有链路l1的时延新扩展的tlv信息设置在rro子对象中,时延值为10。

r2节点接收到该path消息之后,由于r2节点不支持时延的收集,同时所述时延收集请求的类型为建议请求,r2节点需要继续往下游节点发送path消息,报文中保留建议请求的lsp_attributes扩展位信息,但rro中不携带r2节点的扩展的tlv信息。

r3节点接收到path消息之后,r3节点支持时延的收集,在rro中添加r3节点出接口时延的扩展的tlv信息,此时rro的扩展的tlv信息包括链路l1和链路l6的时延,链路l1和链路l6的时延值分别为10,10。

r4节点接收到path消息之后,可以通过rro获取到链路l1和链路l6的时延。同时r4节点也支持时延的收集,r4节点向r3节点回应的resv消息中,rro子对象中添加链路l6的时延。

r3节点接收到resv消息之后,根据r3节点的本地策略,向r2节点回应的resv消息中携带链路l4的时延。

r2节点接收到resv消息之后,由于r2节点不支持时延的收集,向r1节点发送的resv消息中不携带r2节点出接口的时延。

r1节点接收到resv消息,可以获取到链路l4和链路l6的时延。由于r2节点不支持时延收集,所以头节点(r1节点)和尾节点(r4节点)看到的时延都不是完整的信息。

举例四:

继续参见图4,tunnel1从r1节点经过r2节点和r3节点通到r4节点,其中所有节点的本地策略均支持时延的收集。

tunnel1计算出来的路径为链路l1、链路l4、链路l6,由于各个节点的本地策略都支持时延的收集,所述时延收集请求的类型是强制请求还是建议请求区别不大,以所述时延收集请求的类型是强制请求为例进行说明。path消息中携带lsp_required_attributes扩展位信息,同时将携带有链路l1的时延的扩展的tlv信息设置在rro的子对象中,链路l1的时延值为10。

r2节点接收到该path消息之后,根据r2节点的本地策略,r2节点需要继续往下游节点发送path消息,报文中保留强制请求的lsp_required_attributes扩展位信息,rro中携带r2节点的出接口的链路l4的时延,链路l4的时延值为10。

r3节点接收到path消息之后,r3节点支持时延的收集,在rro中添加r3节点出接口的链路l6的时延,此时rro中携带的时延包括链路l1、链路l4和链路l6的时延,链路l1、链路l4和链路l6的时延值分别为10,10,10。

r4接收到path消息之后,可以通过rro获取到链路l1、链路l4、链路l6的时延,也就是说尾节点可以获取到整个路径的时延。同时本地也支持时延收集,r4向r3回应的resv消息中,rro子对象中添加链路l6的时延。

r3节点接收到resv消息之后,根据r3节点的本地策略,向r2节点回应的resv消息同样在rro中添加链路l4时延。

r2节点接收到resv消息之后,根据r2节点的本地策略,向r1节点发送的resv消息携带本地出接口的链路l1的时延。

r1节点接收到resv消息,可以获取到链路l1、链路l4、链路l6的时延。同样头节点(r1节点)也可以通过以上过程获取到tunnel1整个路径的时延。

举例五:

参见图5,ip光网络分为ip层和光层,随着ip网络和光网络的融合,ip层需要通过te隧道穿越光层建立一个通路,为ip层的业务服务。

图5中所示的c1节点和c2节点之间要建立一条隧道,穿越光网络。由于ip层和光层之间是隔离的,所以路径计算模块分别需要在c1节点处计算c1-n1路径,n1节点处计算n1-n2路径,n2节点处计算n2-c2路径。

利用扩展的tlv信息结构,通过rro的携带方式,将隧道实际路径的时延tlv的信息携带给隧道的头节点和尾节点,时延的收集过程和举例四的收集过程相似,这里就不再累述。

在本实施例中,可以根据所述时延收集请求的类型和当前节点的本地策略向所述上游节点或所述当前节点的下游节点发送相应的信息,将所述时延设置在基于流量工程的资源预留协议rsvp-te扩展信令的类型、子域取值的长度和/或子域取值的信息中,能够将每段实际路径的时延逐步携带上。在头节点和尾节点通过分析扩展的类型、子域取值的长度和/或子域取值的信息,可以获取到整条路径的时延。通过收集到的不同节点的时延来标识这条隧道所产生的虚拟链路或者通道,以便后续业务叠加在虚拟链路上和虚拟链路的选择。

本发明实施例还提供了一种时延收集的装置,参见图6,所述时延收集的装置包括:接收模块601、判断模块602和发送模块603。

其中,所述接收模块601用于接收上游节点发送的时延收集请求,所述时延收集请求的类型包括:强制请求和非强制请求。

可选地,所述时延收集请求的类型通过扩展的rsvp-te信令表示。

具体地,隧道头节点将所述时延收集请求的类型携带在path(路径)消息中,可以使用rfc5420中的lsp_required_attributes的扩展位来表示强制请求。可以使用rfc5420中的lsp_attributes的扩展位来表示非强制请求,当然并不见限于此。

所述判断模块602用于根据所述时延收集请求的类型和当前节点的本地策略,判断所述当前节点是否支持时延的收集,得到判断结果,所述判断结果包括:所述当前节点支持时延的收集和所述当前节点不支持时延的收集。

所述发送模块603用于根据所述时延收集请求的类型和所述判断结果,向所述上游节点或所述当前节点的下游节点发送相应的信息。

其中,所述发送模块603包括:第一发送单元、第二发送单元、第三发送单元和第四发送单元。

其中,所述第一发送单元用于如果所述时延收集请求的类型为强制请求,且所述当前节点支持时延的收集时,将所述当前节点的时延和所述时延收集请求发送给所述当前节点的下游节点;

可选地,所述时延设置在基于流量工程的资源预留协议rsvp-te扩展信令的类型、子域取值的长度和/或子域取值的信息中。

所述第二发送单元用于如果所述时延收集请求的类型为强制请求,且所述当前节点不支持时延的收集时,向所述上游节点发送路径错误消息;

所述第三发送单元用于如果所述时延收集请求的类型为非强制请求,且所述当前节点支持时延的收集时,将所述当前节点的时延和所述时延收集请求发送给所述当前节点的下游节点;

所述第四发送单元用于如果所述时延收集请求的类型为非强制请求,且所述当前节点不支持时延的收集时,仅将所述时延收集请求发送给所述当前节点的下游节点。

本发明实施例的时延收集的装置的发送模块603根据所述时延收集请求的类型和所述判断结果,向所述上游节点或所述当前节点的下游节点发送相应的信息,通过接收模块601、判断模块602和发送模块603之间协作配合,来完成整个路径的时延的收集;隧道作为一个虚拟链路或者虚通路存在,通过收集到的不同节点的时延来标识这条隧道所产生的虚拟链路或者通道,以便后续业务叠加在虚拟链路上和虚拟链路的选择。所述时延收集的装置能够实现图1至图2的方法实施例中的各个过程,为避免重复,这里不再赘述。

在本发明的各种实施例中,应理解,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。

另外,本文中术语“系统”和“网络”在本文中常可互换使用。

应理解,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。

在本申请所提供的实施例中,应理解,“与a相应的b”表示b与a相关联,根据a可以确定b。但还应理解,根据a确定b并不意味着仅仅根据a确定b,还可以根据a和/或其它信息确定b。

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

另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理包括,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络侧设备等)执行本发明各个实施例所述收发方法的部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(read-onlymemory,简称rom)、随机存取存储器(randomaccessmemory,简称ram)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明所述原理的前提下,还可以作出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。

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