一种IP网络中服务质量的资源申请方法

技术领域

本发明涉及IP网络的QoS(服务质量)实现，尤其涉及一种在DiffServ(差 分服务)网络中QoS的资源申请方法。

背景技术

由于IP网络设计缺陷，其先期设计目标就是提供一种单一的尽力而为 型数据传输服务。对于如何确保数据传输的正确性和可靠性，完全由上层协 议来完成。但是，完全基于路由协议的QoS资源申请会导致网络负载不均 衡，引起局部网络拥塞现象。

为了能够在现有IP网络上提供多种QoS保证的业务能力，人们提出了 对现有IP网络进行QoS改造。对于现有网络的QoS改造模型，有两种模式： InterServ(综合服务)和DiffServ(差分服务)。

目前，在DiffServ框架下，当一个DS域(差分服务域：DS region)与 多个DS域互连，或者一个DS域内部的多个DS区域(DS domain)之间， QoS管理实体之间还是仅仅依靠静态配置来解决业务流QoS资源预留和DS 域(或DS区域)的选路问题，不能实时动态地基于对端DS域资源使用情 况来完成业务流的QoS资源预留和网络选路。

发明内容

本发明要解决的问题是提供一种IP网络中服务质量的资源申请方法， 应用于DiffServ网络中，使得资源管理实体可以基于对端的资源使用情况完 成该业务流的QoS资源申请。

为了解决上述技术问题，本发明提出了一种IP网络中服务质量的资源 申请方法，包括以下步骤：

(a)资源请求实体收到业务流的资源请求后，向被选定的网络资源管 理实体发送资源预留申请报文，并打开等待响应定时器，该申请报文中包含 该资源请求实体和该业务流的标识及该业务所需要的服务质量资源；

(b)各网络资源管理实体收到请求报文后，根据本网络资源情况、所 述业务流的标识及其需要的资源进行接纳判断，如果可以接纳，则向所述资 源请求实体发送资源预留响应报文，并打开等待确认定时器，响应报文中包 含本网络资源管理实体标识，确认的服务质量资源和所述业务流的标识；

(c)所述资源请求实体在等待响应定时器到时前如果收到返回的资源 预留响应报文，则选取一个确认的服务质量资源满足业务要求的网络资源管 理实体，向其发送资源预留确认报文，否则，本次资源请求失败，结束；

(d)发送了资源预留响应报文地网络资源管理实体如果在收到等待确 认定时器到时前收到资源预留确认报文，则将预留的服务质量资源正式分配 给所述业务流，否则将预留的服务质量资源释放。

进一步地，上述方法可具有以下特点：所述资源请求实体为策略执行点。

进一步地，上述方法可具有以下特点：所述被选定的网络资源管理实体 为其他差分服务域的网络资源管理实体和/或为同一差分服务域内不同区域 的网络资源管理实体。

进一步地，上述方法可具有以下特点：所述步骤(a)中，资源请求实 体是以组播方式向一个组播组内的所有网络资源管理实体发送所述资源预 留申请报文，加入该组播组的所有网络资源管理实体所在网络都可以传送该 业务流。

进一步地，上述方法可具有以下特点：所述资源请求实体和网络资源管 理实体标识都是用其IP地址来表示的。

进一步地，上述方法可具有以下特点：所述步骤(b)中，资源预留响 应报文中还包括提供被选资源的网络的标识。

进一步地，上述方法可具有以下特点：所述步骤(c)中，如果所述资 源请求实体收到两个以上的资源预留响应报文且报文中确认的服务质量资 源都满足业务要求时，则根据配置的竞争算法从中选出一个最优的网络资源 管理实体。

进一步地，上述方法可具有以下特点：所述资源请示实体预先设有一个 预期值，所述步骤(c)中，如果在等待响应定时器到时前，所述资源请示 实体判断收到的响应报文个数超过了该预期值，即可直接开始选取网络资源 管理实体的操作。

进一步地，上述方法可具有以下特点：所述步骤(b)中，如果网络资 源管理实体收到请求报文后，判断不能接纳，则该网络资源管理实体不做后 续处理。

由上可知，利用本发明方法，使得一个业务流面对多个可选的DS域或 者DS区域时，能够根据对端资源管理实体提供的QoS资源情况进行业务流 QoS资源预留和QoS选路，很好地解决了在DiffServ框架下，一个DS域 与多个DS域互连时，或者一个DS域内部多个DS区域之间业务流的QoS 资源预留和QoS选路问题。

附图说明

图1是差分服务网络的结构示意图。

图2是本发明实施例资源请求实体与网络资源管理实体(BCF)之间进 行资源预留交互的信令流程图。

图3是本发明实施例资源请求实体与网络资源管理实体之间交互的详 细流程图。

图4是图3中资源请求实体进行资源请求和确认的流程图。

图5是图3中网络资源管理实体进行资源分配的流程图。

具体实施方式

图1所示差分服务网络的组网示意图，图中DS域是由多个DS区域组 成。每个DS区域应该在网络内部之后一个唯一标识号码，DS区域标识作 用范围只在DS域内部。每个DS区域对应一个BCF，而一个DS域也会对 应一个DS域范围内的BCF。在本实施例的系统中，资源请求实体是策略执 行点(PEP)，但是本发明不局限于此，也可以是策略决策层或者其它完成 该功能的实体。

本实施例中，将多个DS域或/及DS区域的资源管理实体(BCF)加入 到一个组播组中。这样，当PEP收到业务流的资源请求信令，就可以通过 组播方式向这些DS域或/及DS区域的BCF发送资源预申请报文，从对端 返回的资源预留响应报文得知其资源使用情况，完成该业务流的QoS资源 申请和QoS选路，然后向选定的BCF发送资源预留确认报文。如图2所示。

图3示出了该资源申请方法的详细流程，包括以下步骤：

步骤210，PEP收到业务流的资源请求后，向被选定网络的BCF(本实 施例是加入一个组播组的所有BCF，组播组内所有BCF所在网络都可以作 为传送该业务流的网络)发送资源预留申请组播报文，然后打开一个等待响 应定时器，该报文携带的信息包括：PEPID、FlowID和QoS Proflie等；

PEPID：PEP标识，用来标识是由哪个PEP发送的资源申请流程，可以 用PEP的IP地址来标识。

FlowID：业务流标识，用来表示此次申请的资源是为哪个业务流服务， 可以用业务流的五元组来表示。

QoS Profile：用来表示业务流所需要的网络QoS资源，由PEP根据业 务申请资源信令中的要求以及本地对该业务流的资源分配策略确定。

这里，不排除PEP采用单播方式向选定的BCF发送申请报文。

步骤220，各BCF收到组播报文后，根据组播报文中FlowID和QoS Proflie参数以及本网络资源使用情况，采用配置的接入控制算法，对QoS 请求接入进行接纳判断，如果当时网络可以接受PEP上报的业务流的QoS 请求，执行下一步；否则该BCF不做任何处理，结束该BCF上的处理流程；

步骤230，允许接纳的BCF给此次请求资源的业务流预留资源，并向对 应的PEP发送单播QoS资源预留响应报文，然后打开等待确认定时器，该 报文包括以下信息：

BCF标识：，用来表示是哪个BCF，可以用BCF的IP地址来标识。

QoS Profile Ack：表示对请求的QoS资源，BCF给予确认的资源情况。

NetID：表示提供被选资源的网络的标识。

FlowID：表示业务流标识。

步骤240，PEP等待接收返回的资源预留响应报文，如果定时器到时前 没有收到资源预留响应报文，执行下一步，否则，执行步骤260；PEP可以 先设一个预期值该步骤中，如果定时器到时前PEP收到的响应报文个数超 过该预期值，可以直接执行步骤260，以加速处理。

步骤250，说明当前被选网络都处于网络拥塞状态，没有资源进行新业 务QoS接入，本次资源请求失败，结束；

步骤260，PEP从接收到的BCF响应中选取一个BCF，然后向选定的 BCF发送单播QoS资源预留确认报文，该报文包括：FlowID、QoS Profile、 PEP标识等参数；

选取时，PEP先判断BCF返回的分配给业务的Qos资源是否可以被业 务接受，如果不能满足业务要求，丢弃这个BCF响应，在可以满足业务要 求的情况下，如果PEP收到一个BCF的资源预留响应报文，那么这个网络 就被选出来。如果PEP收到两个以上BCF的资源预留响应报文，需要根据 竞争算法选出一个最优网络。

在域间选路情况下，可以综合考虑Qos资源和路由情况，选择一个最优 的网络。

步骤270，返回了资源预留响应报文的BCF判断在等待确认定时器超时 前是否收到PEP发送来的QoS资源预留确认报文，如果收到，执行下一步， 如果没有收到，执行步骤290；

步骤280，BCF把预留的QoS资源正式分配给相应的业务流，业务流可 以发起向该BCF所在网络的数据流通信，结束。

步骤290，将预留的QoS资源释放，本次资源申请结束；

图4和图5中分别单独示出本发明实施例PEP进行资源请求和确认的 流程和BCF进行资源接纳和分配的流程，与上述流程是一致的，在此不再 赘述。

在3G网络建设中，GGSN内部逻辑实体PEP在接收到一个业务流的 QoS请求时，为了保证业务在外部网络运行情况下服务质量要求，GGSN要 向外部网络ExtNet进行资源预留请求。其资源请求流程就可以采用本文中 提及的申请流程。当然，在实际DiffServ模式的QoS资源申请时，不同 DiffServ区域资源管理实体之间就业务进行的资源预留方式也可以采用本文 所提方式进行。