多业务流资源申请的实现方法

技术领域

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

背景技术

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

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

在有独立的承载控制层的区分服务(Dff-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在管理域内分别为各个业务流分配路径，并预留相应的资源；

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

所述的步骤A包括：

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

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

所述的步骤B包括：

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

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

所述的步骤B2包括：

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

所述的步骤B2还包括：

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

所述的步骤B还包括：

B3、为所述的各个业务流确定CM域间的路径及下一跳CM，并向下一跳 CM发送各个业务流的连接资源请求消息。

所述的步骤B3包括：

为所述的各个业务流确定不同的域间的路径，及不同的下一跳CM，并 利用所述各个业务流对应的路径分别向下一跳CM发送相应的业务流的连接资 源请求消息；

或者，为所述的各个业务流确定相同的域间路径，及相同的下一跳 CM，并向利用所述路径向下一跳CM发送包含各个业务流信息的连接资源请 求消息。

所述的步骤C还包括：

当一次业务连接包含的各个业务流的连接资源请求到达目的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的处理相对简 单，适用于中小型网络规模。

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