CN100505639C - 多业务流资源申请的处理方法 - Google Patents

Abstract

本发明涉及一种多业务流资源申请的处理方法。该方法主要包括：承载网资源管理器CM收到包含有至少两个业务流的资源申请的连接资源请求消息后，便由CM在管理域内分别为各个业务流分配路径，并预留相应的资源；之后，再由CM将为各个业务流分配的路径及预留资源信息下发给业务流接入承载网的边缘路由器。本发明的实现使得一次业务连接可以同时为多个业务流同时申请到相应的资源，从而为应用层丰富的QoS业务的开展提供了有力的支撑，极大地缩短了设备间的信令交互过程，节省了网络的流量，以及资源申请占用的时间。

Description

多业务流资源申请的处理方法

技术领域

本发明涉及网络通信技术领域，尤其涉及一种多业务流资源申请的处理方法。

背景技术

随着Internet(互联网)技术的发展，以及用户需求的快速增长，各种多媒体网络服务争相涌现。网络中出现的多媒体业务将占去网络中大量的带宽资源。因此，当网络上有突发性高的FTP(文件传输协议)或者含有图像文件的HTTP(超文本传输协议)等业务时，对网络传输时延、延时抖动等特性较为敏感的实时业务必将会受到很大影响；进而导致网络中需要保证的关键业务难以得到可靠的传输。为此，各种QoS技术应运而生。为满足QoS的需求，IETF已经建议了很多服务模型和机制。

目前业界较多应用的是在网络的接入和边缘使用综合业务模型(Int-Serv)，在网络的核心使用区分业务模型(Diff-serv)。由于区分业务模型(Diff-serv)仅设定优先等级保障QoS措施，因此，相应的QoS保障效果难以预测。为此，业界开始为骨干网区分业务Diff-Serv引入一个独立的承载控制层，建立一套专门的Diff-Serv QoS信令机制，也就是为区分服务Diff-Serv网络专门建立一个资源管理层，管理网络的拓扑资源，对于这种资源管理区分服务Diff-Serv方式称为有独立承载控制层的Diff-Serv模型。

在有独立的承载控制层的区分服务(Diff-Serv)模型中，承载网资源管理器{包括带宽代理器(Bandwidth Broker)或者QoS服务器/资源管理器}中配置了管理规则和网络拓扑，用于为客户的业务带宽申请分配资源。如图1所示，每个管理域的承载网控制服务器相互之间通过信令传递客户的业务带宽申请请求和结果，以及承载网资源管理器为业务申请分配的路径信息，等等。通常是在CM(承载网资源管理器)上为承载网的每个CN(核心设备)模拟一个路由表，实现承载控制层中各个CM的域内寻路，实现业务的路由。每个具体业务类型(即具体的业务流)的资源请求和一系列的LSP(标签交换路径)绑定，即利用相应LSP的资源，当呼叫完成时，再将LSP和其他的资源释放。

具体的处理过程为：当承载控制层处理用户的业务带宽申请时，将确定用户业务的路径。承载网资源管理器会通知边缘路由器按照指定的路径转发业务流。承载网通常利用MPLS(多协议标签交换)技术，使用资源预留方式沿着承载控制层指定的业务流路径建立LSP，使用RSVP-TE(资源预留协议-流量工程)或CR-LDP(受限标签分发协议)的显示路由机制建立端到端的LSP。

在现有技术中，另一种资源管理方案是采用QoS服务器作为网络中的QoS管理部件。具体的实现过程中还包括与QoS服务器相配套的策略服务器、目录服务器以及网管监控服务器。其中，策略服务器用于根据QoS服务器和管理接口等策略配置信息，设置相关的路由器的参数和配置；目录服务器为一个统一和集中的数据库，用于保存网络设备配置信息、用户信息和QoS信息；网管监控服务器则负责收集承载网各路由器和链路的拥塞状态等信息，供QoS服务器为业务申请选路时参考。

QoS服务器负责根据承载网络的拓扑和资源状况为业务QoS请求分配满足要求的承载路径。为此，需要在QoS服务器上预先设置好的承载网络的拓扑和带宽状况，配置好选路规则。当业务服务器向QoS服务器发出带宽请求后，QoS服务器纪录该呼叫的资源请求，并根据其QoS要求，以及承载网络的当前拓扑和当前资源状况为业务请求分配满足要求的承载路径，将分配的结果反馈业务服务器。

QoS服务器还根据业务的带宽占用情况，向策略服务器发出相应的LSP策略修改命令，策略服务器就根据QoS服务器的命令，配置相应的边缘路由器。边缘路由器将使用MPLS LSP建立的显示路由技术，根据QoS服务器指定的路径，重新建立或调整LSP。

在所述的各独立运营的网络中，通过上述各种技术方案实现了针对各业务流的QoS资源管理。这样，用户通过网络开展业务时，便可以为所述业务申请相应的QoS资源。目前，在各技术方案的具体实现过程中，所采用的QoS资源申请的方法均为针对每一种业务流建立一次业务连接，并进行QoS资源的申请；当然，如果一次通信中包含多种业务流，则需要分别建立多次业务连接，并在所述业务连接的基础上进行信令的交互，以实现各业务流的QoS资源的申请。

不难看出，上述为各个业务流申请资源的方式使得网络中的信令交互量较大，而且，导致针对一次通信的资源申请占用的时间较长。

发明内容

鉴于上述现有技术所存在的问题，本发明的目的是提供一种多业务流资源申请的处理方法，实现通过一次业务连接可以同时完成多个业务流的资源申请，从而减少了多业务流资源申请过程中需要交互的信令数目，并可以缩短资源申请占用的时间。

本发明的目的是通过以下技术方案实现的：

本发明提供了一种多业务流资源申请的实现方法，包括：

一种多业务流资源申请的处理方法，包括：

A、承载网资源管理器CM收到包含有至少两个业务流的资源申请的连接资源请求消息；

B、各个CM在管理域内分别为各个业务流分配路径，并预留相应的资源，并且，CM分别为各个业务流分配相同的域间路径和相同的下一跳CM；或者，CM分别为各个业务流分配不同的域间路径，相同或不同的下一跳CM；

C、源CM将为各个业务流分配的路径及预留资源信息下发给业务流接入承载网的边缘路由器。

所述的步骤A包括：

用户终端通过承载网中的核心设备接入网络；

承载网中的核心设备通过呼叫代理向CM发送连接资源请求消息，所述的连接资源请求中包括针对至少两个业务流的资源申请。

所述的步骤B包括：

B1、在业务流经过的CM上根据保存的地址信息确定所述业务流经过该CM域的边缘路由器或边界路由器；

B2、基于所述的边缘路由器或边界路由器在所述CM的域内为各个业务流分配相应的路径，并预留相应的资源；

B3、根据所述业务流对应的域间路径向下一跳CM发送业务流的资源请求消息，同一个所述资源请求消息对应一个或多个业务流。

所述的步骤B2包括：

基于所述的边缘路由器或边界路由器，在所述CM域内分别为各个业务流分配空闲的标签交换路径LSP，并为所述LSP预留资源。

所述的步骤B2还包括：

在CM上保存为各个业务流分配的路径，以及预留资源信息。

所述的步骤C还包括：

当一次业务连接包含的各个业务流的连接资源请求到达目的CM，并完成分配路径、预留资源操作后，向上一跳CM返回携带预留的资源信息的资源确认响应；

除了源、目的CM外的资源管理器将自己预留的资源信息和下一跳CM返回的资源信息一起通过资源确认响应发给上一跳CM，直至资源确认响应到达源CM。

所述的步骤C包括：

当一次业务连接的源CM上收到各个业务流返回的资源连接响应消息时，启动流映射命令，向边缘路由器下发各个业务流分配的路径及预留资源信息。

所述的各个业务流对应相同或不同的目的CM。

由上述本发明提供的技术方案可以看出，本发明实现通过一次业务连接可以同时完成多个业务流的资源申请，从而为应用层丰富的QoS业务的开展提供了有力的支撑，极大地缩短了设备间的信令交互过程，节省了网络的流量，以及资源申请占用的时间。本发明的实现，对于一次通信过程中有多业务流需要申请QoS资源的情况，可以大大缩短建立信令连接的时间，减少资源申请过程中的信令交互量。

附图说明

图1为独立的承载控制层网络模型示意图；

图2为业务类型与承载业务的LSP间的映射关系示意图；

图3为本发明所述的方法的流程图A；

图4为图3中一次业务连接的资源申请流程图；

图5为本发明所述的方法的流程图B；

图6为图5的一次业务连接的资源申请流程图。

具体实施方式

在承载全业务的IP电信网上，通常会有各种各样QoS要求的业务分别承载在各个LSP(标签交换路径)管道上，在承载网资源管理器需要保存有业务及承载该业务LSP的映射关系信息。如图2所示，其中audio(音频)业务、video(视频)业务、internet(互联网)业务等等，分别需要对应着不同的LSP，即分别采用不同的LSP在网络中传递，以保证分别为各业务提供不同的QoS保证。

因此，在全业务承载的IP电信网上，会出现一次通信过程需要为多业务流申请QOS资源的情况，本发明的目的便是减少这种情况下网络中信令的交互数目，缩短资源申请占用的时间。

本发明的核心正是利用一次业务连接操作处理过程，同时在各个CM上为不同的业务流分别进行相应的资源申请，在网络中，为不同的业务流对应的申请到的资源提供不同的QoS保证。

也就是说，本发明中一次资源申请可以同时完成一个或多个源地址和目的地址相同、带宽要求不同的业务流的资源申请，每一跳针对各个业务流的路径资源申请都成功时才返回资源申请成功消息。在资源申请过程中，如果需要向下一跳CM发起资源请求时，可以用一个资源请求消息向同一个CM请求这些业务流的资源或者向多个CM发送请求。

本发明中，同时可以完成资源申请的不同的业务流的数目可以根据设备的硬件性能来决定。

本发明所述的方法的具体实现方式如图3和图4所示，在图4中，不同的业务流限定为经过相同CM，即图4为一个域内允许发散，域间控制收敛的资源申请过程，便于网络规划和管理，该方案比较适用于中大型网络规模；

参见图3和图4所示，本发明具体包括以下步骤：

步骤31：CA(连接代理)向CM发出连接资源请求消息，所述的连接资源请求消息中包含针对多个业务流的资源申请；

例如，连接资源请求中可以包含针对audio业务的资源申请和video业务的资源申请，且两业务流分别对应不同的带宽资源申请量，其中，所述的audio业务申请的带宽资源为64kbps，所述的video业务申请的带宽资源384kbps；

步骤32：CM收到所述的连接资源请求消息后，则保存所述业务流的连接信息，并确定业务流的边缘路由器或边界路由器信息；

在源CM上，根据保存的五元组中的源IP地址信息确定业务流的源IP地址归属的ER(边缘路由器)；

如果在非源CM上，则确定本CM域的入口BR(边界路由器)地址序列，例如，在逐跳路由算法中是由上一跳CM选择好域间LSP后确定，即所述LSP的出口路由器即为本CM域的入口BR；

步骤33：利用业务路由算法在当前CM域内分别为各个业务流选路，即分配相应的路径，并预留相应的资源；

仍接上例，在该步骤中，首先申请第一种业务类型audio的域内LSP资源，找到能承载audio业务的空闲的LSP之后，则分配相应的带宽并进行记录；然后再申请第二种业务类型video的域内LSP资源，找到相应的LSP并进行带宽分配后，同样记录该信息；

之后，按相同的方法在本CM管辖的拓扑中逐跳进行路由和资源分配，需要说明的是，由于该业务连接的起点是相同的ER，所以在域内为不同流进行选路和分配资源时，可以走相同的CN(承载网核心设备)序列，如果CN间没有满足待申请流业务类型的LSP，此时也可以在域内走不同的CN序列；也就是说，在CM域内可以为不同的业务流选择经由不同设备的LSP；

步骤34：申请完域内资源后，再利用信令路由算法进行域间选路；

例如，使用逐跳算法向下一跳CM发起QoS资源请求，在请求中除了原有的QoS参数、业务类型外，还需要带上下一跳CM的地址以及出域LSP集对应的出口BR；

仍见上述实例中，所述的LSP集包括：audio类型的LSP#1和video类型的LSP#2，两LSP的出口BR可以相同，也可以不同，但下一跳到达的CM域是相同的；

除了目的CM之外，所有业务流经过的资源管理器CM均需要执行步骤32到步骤34的处理过程，直至连接资源请求消息到达目的CM；

步骤35：目的CM接收所述的连接资源请求消息，并完成业务路由，LSP资源分配后，向上一跳CM返回资源确认响应；

除了源CM外的资源管理器将自己和下一跳CM返回的LSP资源一起通过资源确认响应发给上一跳CM，直至响应到达源CM；

步骤36：源CM收到所述的连接资源响应消息后，启动流映射命令，向ER下发分配的路径及预留资源信息，具体包括：会话ID(标识)、多个业务流信息、QoS参数、流量描述符以及整个路径的标签栈等信息。

本发明还提供了另外一种本发明所述方式的具体的实现方式，如图5和图6所示，在这一种具体实现方法中，不再限定业务流经过相同的CM，而仅要求业务流为相同的源和目的CM；如图5和图6所示，当CA向CM发出资源请求后，相应的处理过程包括以下步骤：

步骤51：CA向CM发出连接资源请求消息，所述的连接资源请求消息中包含针对多个业务流的资源申请；

同样，所述连接资源请求中可以包含针对audio业务的资源申请和video业务的资源申请；

步骤52：CM收到所述的连接资源请求消息后，则保存所述业务流的连接信息，并确定业务流的边缘路由器或边界路由器信息；

在源CM上，根据五元组中的源IP地址信息确定业务流的源IP地址归属的ER(边缘路由器)；

在非源CM，则确定本CM域的入口BR(边界路由器)地址序列，例如，在逐跳路由算法中是由上一跳CM选择好域间LSP后确定，即所述LSP的的出口路由器即为本CM域的入口BR；

步骤53：利用业务路由算法在当前CM域内分别为各个业务流选路，即分配相应的路径，并预留相应的资源；

接上例，首先申请第一种业务类型audio的域内LSP资源，找到能承载audio业务的空闲的LSP之后，则分配相应的带宽并进行记录；然后再申请第二种业务类型video的域内LSP资源，找到相应的LSP并进行带宽分配后，同样记录该信息；

之后，按相同的方法在本CM管辖的拓扑中逐跳进行路由和资源分配，需要说明的是，由于该业务连接的起点是相同的ER，所以在域内为不同流进行选路和分配资源时，可以走相同的CN序列，如果CN间没有满足待申请流业务类型的LSP，此时也可以在域内走不同的CN序列；

步骤51至步骤53与图3所示的处理对过程相同，区别主要在于后续的处理过程中，不同的业务流对应的连接资源请求消息可以经由不同的CM到达目的CM；

步骤54：申请完域内资源后，再利用信令路由算法分别为各个业务流进行域间选路；

例如，使用逐跳算法向下一跳CM发起QoS资源请求，在请求中除了原有的QoS参数、业务类型外，还需要带上下一跳CM的地址以及出域LSP集对应的出口BR，所述出口BR可以相同，也可以不同，而且，当BR不同时，则到达对端BR可能是相同的归属CM，也可能是不同的CM，以不同的CM为例，如图6所示；

步骤55：各个业务流分别进行业务路由和路径资源计算；

除了目的CM之外的所有资源管理器CM需要重复执行步骤52到步骤54，直至所有业务流的连接资源请求均到达目的CM；

步骤56：目的CM完成业务路由，LSP资源分配后，向上一跳CM返回资源确认响应，即连接资源响应消息。

除了源CM外的资源管理器将自己和下一跳CM返回的LSP资源一起通过资源确认响应发给上一跳CM，直至连接资源响应消息到达源CM；

步骤57：当源CM收集到多个业务流的连接资源响应消息后，即源CM收到本次连接包括的所有业务流对应的连接资源响应消息后，则启动流映射命令，向ER下发分配的路径信息，及预留资源信息，具体包括：会话ID(标识)、多个业务流信息、QoS参数、流量描述符以及整个路径的标签栈等信息。

本发明中，如果一次业务连接是点到点通信，则要求多个业务流都必须走到相同的目的CM；如果是一点到多点间的通信，则允许多个业务流出现业务类型(如音频流、视频流等等)一样的情况，此时多个业务流可以到达不同的目的CM。不同业务流走相同的源头CM，中间CM允许不一样，是一个域内和域间允许发散的连接资源申请过程，网络规划和管理要求相对较高些，同时在源CM和目的CM技术实现相对复杂一些，中间CM的处理相对简单，适用于中小型网络规模。

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

Claims (7)

1、一种多业务流资源申请的处理方法，其特征在于，包括：

A、承载网资源管理器CM收到包含有至少两个业务流的资源申请的连接资源请求消息；

B、CM在管理域内分别为各个业务流分配路径，并预留相应的资源，并且，CM分别为各个业务流分配相同的域间路径和相同的下一跳CM；或者，CM分别为各个业务流分配不同的域间路径，相同或不同的下一跳CM；

C、如果CM为源CM，则所述源CM根据所述业务流对应的域间路径向下一跳CM发送所述连接资源请求消息，当接收下一跳CM返回的携带预留资源信息的资源确认响应后，将为各个业务流分配的路径及预留资源信息下发给业务流接入承载网的边缘路由器；

如果CM为非源CM且非目的CM，则所述CM根据所述业务流对应的域间路径向下一跳CM发送所述连接资源请求消息，当接收到下一跳返回的携带预留资源信息的资源确认响应后，将自己和下一跳CM返回的预留资源信息发给上一跳CM；

如果CM为目的CM，则所述目的CM向上一跳CM返回资源确认响应。

2、根据权利要求1所述的多业务流资源申请的处理方法，其特征在于，所述的步骤A包括：

用户终端通过承载网中的核心设备接入网络；

承载网中的核心设备通过呼叫代理向CM发送连接资源请求消息，所述的连接资源请求中包括针对至少两个业务流的资源申请。

3、根据权利要求1或2所述的多业务流资源申请的处理方法，其特征在于，所述的步骤B包括：

B1、在业务流经过的CM上根据保存的地址信息确定所述业务流经过该CM域的边缘路由器或边界路由器；

B2、基于所述的边缘路由器或边界路由器在所述CM的域内为各个业务流分配相应的路径，并预留相应的资源。

4、根据权利要求3所述的多业务流资源申请的处理方法，其特征在于，所述的步骤B2包括：

基于所述的边缘路由器或边界路由器，在所述CM域内分别为各个业务流分配空闲的标签交换路径LSP，并为所述LSP预留资源。

5、根据权利要求4所述的多业务流资源申请的处理方法，其特征在于，所述的步骤B2还包括：

在CM上保存为各个业务流分配的路径，以及预留资源信息。

6、根据权利要求5所述的多业务流资源申请的处理方法，其特征在于，所述的步骤C包括：

当一次业务连接的源CM上收到各个业务流返回的资源连接响应消息时，启动流映射命令，向边缘路由器下发各个业务流分配的路径及预留资源信息。

7、根据权利要求6所述的多业务流资源申请的处理方法，其特征在于，所述的各个业务流对应相同或不同的目的CM。

Images