CN100382540C

CN100382540C - 一种实现业务连接资源管理的方法

Info

Publication number: CN100382540C
Application number: CNB2004100864185A
Authority: CN
Inventors: 陈悦鹏; 范灵源; 吴登超; 许波
Original assignee: Huawei Technologies Co Ltd
Current assignee: Pizhou Eurasia Import And Export Trade Co ltd
Priority date: 2004-10-20
Filing date: 2004-10-20
Publication date: 2008-04-16
Anticipated expiration: 2024-10-20
Also published as: CN1764151A; WO2006042464A1

Abstract

本发明公开了一种实现业务连接资源管理的方法，该方法包括以下步骤：a.呼叫代理收到主叫用户的业务连接请求后，向源承载网资源管理器发送连接资源请求；b.收到连接资源请求的承载网资源管理器进行域内和域间选路，申请并记录域内和域间路径资源，并判断自身是否为目的承载网资源管理器，如果是，则执行步骤c；否则，当前承载网资源管理器向下一跳承载网资源管理器转发连接资源请求，返回步骤b；c.完成业务路由、路径资源分配，之后不向承载网路由设备下发QoS策略，立即向上一跳承载网资源管理器返回连接资源响应，直到将连接资源响应发至源承载网资源管理器。该方法能减轻系统资源开销和运行负荷，并且能保证整个系统每个业务流的QoS。

Description

一种实现业务连接资源管理的方法

技术领域

本发明涉及资源管理技术，尤指一种实现业务连接资源管理的方法。

背景技术

随着互联网规模的不断扩大，各种各样的网络服务争相涌现，先进的多媒体系统也层出不穷。由于实时业务对网络传输时延、延时抖动等特性较为敏感，当网络上有突发性高的文件传输(FTP)或含有图像文件的超文本传输(HTTP)等业务时，实时业务就会受到很大影响；另外，由于多媒体业务将占用大量的带宽，所以也将使得现有网络中需要得到保证的关键业务难以得到可靠的传输。于是，为保证关键业务得到可靠的传输，各种服务质量(QoS，Quality of Service)技术便应运而生。互联网工程任务组(IETF，Internet Engineering Task Force)已经提出了很多服务模型和机制，以满足QoS的需求。目前业界比较认可的是在网络的接入或边缘使用综合业务(Int-Serv，Integrated Service)模型，而在网络的核心使用区分业务(Diff-serv，Differentiated Service)模型。

由于Diff-serv模型仅通过设定优先级的方式来保障QoS，效果难以预测。因此，业界为骨干网的Diff-Serv模型引入了一个独立的承载控制层，建立了专门的Diff-Serv QoS信令机制，并利用Diff-Serv网络新增的承载控制层管理网络的拓扑资源，这种Diff-Serv被称为有独立承载控制层的Diff-Serv模型，图1为有独立承载控制层的Diff-serv模型图。如图1所示，在该模型中，承载控制层102设置于承载网络103和业务控制层101之间。在业务控制层101中的呼叫代理(CA，Call Agent)为业务服务器，比如软交换等，可实现软交换等功能；在承载控制层102中，包括一个或多个承载网资源管理器，承载网资源管理器负责配置管理规则和网络拓扑，为客户的业务带宽申请分配资源，控制和管理各个承载网资源管理器之间通过信令传递客户的业务带宽申请请求和结果、以及为业务申请分配的路由路径信息等，比如：控制和管理承载网资源管理器1、承载网资源管理器2.承载网资源管理器3之间的通信；在承载网103中，每个承载网资源管理器管理一个特定的承载网区域，这个特定的承载网区域被称为所对应的承载网资源管理器的管理域，比如：承载网资源管理器1的管理域105、承载网资源管理器2的管理域106和承载网资源管理器3的管理域107，承载网103中包括边缘路由器(ER，Edge Router)、边界路由器(BR，Border Router)以及核心路由器104，ER、BR和核心路由器都属于承载网，统称为连接节点(CN，Connection Node)。

在具有独立承载控制层的Diff-Serv模型中，承载网资源管理器配置了管理规则和网络拓扑，为客户的业务带宽申请分配资源。当承载控制层处理用户的业务带宽申请时，承载网资源管理器将确定用户业务的路径，并通知边缘路由器按指定的路径转发业务流。承载网如何根据承载控制层确定的路径实现用户业务流按指定路由转发，目前业界主要是利用MPLS技术，使用资源预留方式沿着承载控制层指定的业务流路径建立LSP，使用RSVP-TE或CR-LDP的显示路由机制建立端到端的LSP。

现有技术中，实现业务连接资源分配的具体处理流程如图2所示，包括以下步骤：

步骤201：主叫CA向与其连接的承载网资源管理器发送连接资源请求。这里，将与主叫CA连接的承载网资源管理器称为源承载网资源管理器。

步骤202～204：收到连接资源请求的承载网资源管理器判断自身是否为当前业务连接的目的承载网资源管理器，如果不是，该承载网资源管理器根据连接资源请求中的地址信息确定本域的入口路由器和出口路由器，并利用选路算法进行域内和域间选路，记录相应路径资源信息，同时，该承载网资源管理器向下游承载网资源管理器转发连接资源请求，返回步骤202；否则，执行步骤205。

这里，承载网资源管理器是根据自身保存的ER接入信息以及连接资源请求中主叫UE的标识信息进行判断的，该UE标识信息可以为IP地址，也可以为域名信息，IP地址携带于连接资源请求的五元组中。

承载网资源管理器可以通过自身所辖承载网络的LSP信息和各个CN的路由信息确定下游承载网资源管理器，还可以通过这两个信息及信令路由算法来确定下游承载网资源管理器。

步骤205：目的承载网资源管理器完成自身业务路由和LSP资源分配，并向本域内所选择路由路径对应的路由器下发QoS策略，然后，向上一跳承载网资源管理器返回连接资源响应。

步骤206～20：收到连接资源响应的承载网资源管理器完成自身业务路由和LSP资源分配，并向本域内所选择路由路径对应的路由器下发QoS策略，然后，判断自身是否为源承载网资源管理器，如果是，则结束处理流程，否则，向自身的上一跳承载网资源管理器返回连接资源响应，然后，返回步骤206。

从上述处理过程可以看出，现有资源分配流程中，承载网资源管理器确定路由路径、分配相应资源后都要将确定的QoS策略下发给承载网中的路由设备，但是，这就需要在承载控制层和承载网设备之间建立许多通信信道，用于承载网资源管理器与路由设备之间的交互，如此，不仅会加大承载网系统的资源开销，增加承载网的运行负荷，而且增大了整个系统处理的复杂度。

另外，承载控制层和承载网是两个相互独立的层面，每层中的网络设备也是相互独立的，因此，如果承载控制层所采用的网络设备与承载网设备不属于同一厂家，那么，还存在两个厂家网络设备之间功能相互支持的问题，如果有些功能如保证QoS功能相互不能支持，但又要求两层设备之间完成此功能时必须交互，这样就有可能导致整个系统中业务连接的QoS不能得到保障。

发明内容

有鉴于此，本发明的主要目的在于提供一种实现业务连接资源管理的方法，能减轻系统资源开销和运行负荷，并且能保证整个系统每个业务流的QoS。

为达到上述目的，本发明的技术方案是这样实现的：

一种实现业务连接资源管理的方法，每一个承载网资源管理器都保存有自身所管理的承载网络的拓扑信息和全部资源信息，该方法包括以下步骤：

a.呼叫代理收到主叫用户的业务连接请求后，向源承载网资源管理器发送连接资源请求；

b.收到连接资源请求的承载网资源管理器进行域内和域间选路，申请并记录域内和域间路径资源，并判断自身是否为目的承载网资源管理器，如果是，则执行步骤c；否则，当前承载网资源管理器向下一跳承载网资源管理器转发连接资源请求，返回步骤b；

c.目的承载网资源管理器完成业务路由、路径资源分配，之后不向承载网路由设备下发QoS策略，立即向上一跳承载网资源管理器返回包含自身路径资源信息的连接资源响应，接收到连接资源响应的承载网资源管理器，完成业务路由、路径资源分配之后不向承载网路由设备下发QoS策略，立即向上一跳承载网资源管理器返回包含自身和自身下一跳承载网资源管理器返回的路径资源信息的连接资源响应，直到将连接资源响应发至源承载网资源管理器；

其中，所述源承载网资源管理器为与呼叫代理连接的承载网资源管理器；所述目的承载网资源管理器为被叫用户所属的承载网资源管理器。

所述步骤c中在所述目的承载网资源管理器立即向上一跳承载网资源管理器返回包含自身路径资源信息的连接资源响应之前还包括：判断自身是否为源承载网资源管理器，如果否，则继续执行所述立即向上一跳承载网资源管理器返回包含自身路径资源的连接资源响应的步骤，如果是，则不继续执行所述立即向上一跳承载网资源管理器返回包含自身路径资源的连接资源响应的步骤，并将包含自身路径资源信息的连接资源响应直接发送给呼叫代理。

该方法还包括：所述源承载网资源管理器接收到连接资源响应后，将自身和自身下一跳承载网资源管理器返回的路径资源信息返回给所述呼叫代理。

其中，步骤b进一步包括：每个承载网资源管理器根据连接资源请求中的地址信息确定本域内的入口路由器，再根据所确定的入口路由器利用路由算法进行域内和域间的选路，并确定本域内的出口路由器。

所述承载网络的拓扑和资源信息根据网络的实际情况通过配置得到；或者，通过基于流量工程的路由协议或SNMP协议动态收集得到，或者，通过对COPS标准协议扩展得到。承载网络的拓扑和资源信息发生变化时，该方法进一步包括：将对应的承载网资源管理器上的数据信息进行同步。

上述方案中，所述承载网为IP网络、或MPLS网络、或ATM网络。相应的，所述路径资源为标签交换路径、或隧道、或永久虚电路、或交换式虚电路。所述连接资源请求为业务申请请求、或业务修改请求、或业务释放请求。

本发明所提供的实现业务连接资源管理的方法，去掉了承载网资源管理器向承载网设备发送QoS策略的步骤，目的承载网资源管理器完成业务路由和路径资源分配后，直接向上一跳承载网资源管理器返回响应，源承载网资源管理器与目的承载网资源管理器之间的承载网资源管理器也依次向上一跳返回响应，直到源承载网资源管理器。如此，就不需要在承载控制层和承载网路由设备之间为下传QoS策略等信息而建立通信信道，从而减轻了承载网系统的资源开销，降低了承载网的运行负荷，而且减小了整个系统处理的复杂度。

同时，由于承载控制层不需要与承载网路由设备相互配合，因此，即使两个层面采用不同厂家的设备也不会影响业务连接的QoS，能充分保障整个系统的QoS，解决了Differ-serv模型中不能为每个业务流提供QoS保证的问题，便于各种规模的网络进行商用。另外，本发明的方法可用于各种承载网，如包含MPLS网络的IP网络、ATM网络和其它类型的承载网，相应的，对应的路径可以是LSP、tunnel、PVC、SVC等等，因此，本发明的适用范围更广、实用性更强，使用更灵活。由于现有承载网设备已支持动态路由协议、SNMP协议等等，故此，本发明对承载网络改动很小，易于实现。

附图说明

图1为现有技术中独立的承载控制层网络模型示意图；

图2为现有技术中实现资源分配的处理流程图；

图3为本发明实现业务连接资源管理的处理流程图。

具体实施方式

本发明的核心思想是：源承载网资源管理器收到业务控制层发来的资源请求后，完成自身的业务路由和路径资源分配，并向下一跳转发连接资源请求，直至目的承载网资源管理器，每个接收到连接资源请求的承载网资源管理器均完成自身的业务路由和路径资源分配；目的承载网资源管理器完成业务路由和路径资源分配后，立即向上一跳承载网资源管理器返回连接资源响应，直至源承载网资源管理器，而无须向承载网设备发送QoS策略。其中，连接资源响应中携带有自身和自身下一跳承载网资源管理器的路径资源信息。

本发明中，每个承载网资源管理器中保存有自身所管理的承载网络的拓扑信息和全部资源信息，所保存信息的取得途径可以是根据网络的实际应用情况通过手工配置的；也可以是通过基于流量工程的现有路由协议或SNMP协议进行收集的，或是对COPS等标准协议进行扩展完成的。

当承载网的拓扑结构或资源信息发生变化时，与发生变化的承载网对应的承载网资源管理器中的数据信息要进行同步更新；如果已经承载业务连接，则进行相应的故障处理，可以直接拆除连接或通知业务控制层的呼叫代理，由呼叫代理来决定如何处理。

当业务呼叫代理在建立业务连接时，需要向承载网资源管理器发送查询资源请求，比如：查询带宽参数、其它QoS参数等等，承载网资源管理器根据自身掌握的网络具体拓扑情况和业务连接的QoS要求，进行选路和资源计算，向业务呼叫代理响应结果，如果满足所规定的QoS策略要求，则可以建立本次业务连接，否则不可以建立本次业务连接。

如果业务连接的源端和目的端在同一个承载网资源管理器的管辖范围内，则该承载网资源管理器根据资源计算结果就可以向业务控制层返回响应；否则，需要发送资源请求到其它承载网资源管理器上，每个承载网资源管理器进行相应的拓扑和资源计算，最后将结果返回给发起业务连接资源请求的呼叫代理。

对于业务连接的资源修改和资源释放，上述过程同样适用。

本发明中所述的承载网络可以是包含MPLS网络在内的IP网络、ATM网络或其它类型的承载网，因此，对应的路径可以是标签交换路径(LSP)、隧道(tunnel)、永久虚电路(PVC)、交换式虚电路(SVC)等。

本发明中所述连接资源请求可以是业务申请请求、或业务修改请求、或业务释放请求。

如图3所示，本发明的具体处理流程包括以下步骤：

步骤301：呼叫代理收到主叫用户的业务连接请求后，向与其连接的承载网资源管理器发送连接资源请求；承载网资源管理器为当前业务流保存连接信息。这里，与呼叫代理连接的承载网资源管理器称为源承载网资源管理器，被叫用户所属的承载网资源管理器称为目的承载网资源管理器，源承载网资源管理器与目的承载网资源管理器之间的承载网资源管理器称为中间承载网资源管理器。

步骤302：收到连接资源请求的承载网资源管理器根据连接资源请求中五元组的源IP地址，确定自身管理域的入口路由器。

对于源承载网资源管理器，就是根据连接资源请求中五元组的源IP地址，确定该源IP地址归属于哪个ER。

对于其它中间承载网资源管理器，则是根据连接资源请求中携带的IP地址确定本域的入口BR，例如：逐跳路由算法就是由上一跳承载网资源管理器选择好域间路径，根据该路径即可确定的本域的入口路由器和上一跳承载网资源管理器管理域的出口路由器。

步骤303：当前承载网资源管理器利用业务路由算法在自身的管理域内进行域内选路，申请域内路径资源，并记录这些路径资源信息。这里，可以采用任意已有的域内选路算法来实现域内选路，比如：采用Dijakstra算法、Bellman-Ford算法、静态配置算法、或矩阵路由表的方法。

步骤304：当前承载网资源管理器利用信令路由算法在自身与下一跳承载网资源管理器之间进行域间选路，确定本域内的出口路由器。这里，可以采用任意已有的域间选路算法来实现域间选路，比如：逐跳路由、正向约束反向路由等等。

步骤305～306：当前承载网资源管理器判断自身是否为目的承载网资源管理器，如果是，则执行步骤307；否则，当前承载网资源管理器向下一跳承载网资源管理器转发连接资源请求，返回步骤302。

步骤307：目的承载网资源管理器完成业务路由、路径资源分配，之后向上一跳承载网资源管理器返回连接资源响应。这里，承载网资源管理器不向承载网的路由设备下发QoS策略。

步骤308：收到连接资源响应的承载网资源管理器，向上一跳承载网资源管理器返回连接资源响应，重复本步骤直至源承载网资源管理器。

其中，所述连接资源响应中携带有自身的路径资源信息和下一跳承载网资源管理器返回的路径资源信息。

步骤309：源承载网资源管理器将选路和路径资源信息返回给发起请求的呼叫代理。

本发明无须承载控制层的承载网资源管理器向承载网的路由设备下发QoS策略，而是通过配置和动态收集承载网拓扑结构信息和资源信息，生成用于业务连接资源动态分配的映射信息(mapping)，并通过流量工程方式的路由选路和资源计算，来保证业务连接在承载网中的QoS。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims

1.一种实现业务连接资源管理的方法，其特征在于，每一个承载网资源管理器都保存有自身所管理的承载网络的拓扑信息和全部资源信息，该方法包括以下步骤：

c.目的承载网资源管理器完成业务路由、路径资源分配，之后不向承载网路由设备下发QoS策略，立即向上一跳承载网资源管理器返回包含自身路径资源信息的连接资源响应；接收到连接资源响应的承载网资源管理器，完成业务路由、路径资源分配之后不向承载网路由设备下发QoS策略，立即向上一跳承载网资源管理器返回包含自身和自身下一跳承载网资源管理器返回的路径资源信息的连接资源响应，直到将连接资源响应发至源承载网资源管理器；

2.根据权利要求1所述的实现业务连接资源管理的方法，其特征在于，所述步骤c中在所述目的承载网资源管理器立即向上一跳承载网资源管理器返回包含自身路径资源信息的连接资源响应之前还包括：判断自身是否为源承载网资源管理器，如果否，则继续执行所述立即向上一跳承载网资源管理器返回包含自身路径资源的连接资源响应的步骤，如果是，则不继续执行所述立即向上一跳承载网资源管理器返回包含自身路径资源的连接资源响应的步骤，并将包含自身路径资源信息的连接资源响应直接发送给呼叫代理。

3.根据权利要求1所述的实现业务连接资源管理的方法，其特征在于，该方法还包括：所述源承载网资源管理器接收到连接资源响应后，将自身和自身下一跳承载网资源管理器返回的路径资源信息返回给所述呼叫代理。

4.根据权利要求1所述的实现业务连接资源管理的方法，其特征在于，步骤b进一步包括：每个承载网资源管理器根据连接资源请求中的地址信息确定本域内的入口路由器，再根据所确定的入口路由器利用路由算法进行域内和域间的选路，并确定本域内的出口路由器。

5.根据权利要求1所述的实现业务连接资源管理的方法，其特征在于，所述承载网络的拓扑和资源信息根据网络的实际情况通过配置得到；或者，通过基于流量工程的路由协议或SNMP协议动态收集得到，或者，通过对COPS标准协议扩展得到。

6.根据权利要求1所述的实现业务连接资源管理的方法，其特征在于，所述承载网络的拓扑和资源信息发生变化时，该方法进一步包括：将对应的承载网资源管理器上的数据信息进行同步。

7.根据权利要求1至6任一项所述的实现业务连接资源管理的方法，其特征在于，所述承载网为IP网络、或MPLS网络、或ATM网络。

8.根据权利要求7所述的实现业务连接资源管理的方法，其特征在于，所述路径资源为标签交换路径、或隧道、或永久虚电路、或交换式虚电路。

9.根据权利要求1至6任一项所述的实现业务连接资源管理的方法，其特征在于，所述连接资源请求为业务申请请求、或业务修改请求、或业务释放请求。