专利名称：数据网络中路由器之间每类资源的基于策略的同步的制作方法
技术领域：
本发明涉及通信网，具体地说，涉及为网络中选定的业务流提供增强的服务质量(QoS)。
背景技术：
对于网络服务提供商，在网络设计和管理方面的一项关键考虑是在自网络服务客户发起的业务量和自服务提供商网络之外(如自因特网)发起的业务量之间适当地分配接入容量和网络资源。这种考虑对于某些网络客户的业务量特别重要，这些网络客户的预约内容包括请求网络服务提供商为某些流提供最小通信带宽或保证特定服务质量(QoS)的服务等级协定(SLA)。这种服务提供方式要求网络服务提供商实现一种网络体系结构和协议，这种网络体系结构和协议可取得规定的QoS并强制执行接纳控制，以确保有足够的接入容量和网络资源可供客户利用。
在因特网协议(IP)网络中，一种取得QoS并实现接纳控制，且所得QoS和接纳控制可与面向连接的网络业务(如语音或异步传输模式(ATM))相比拟的简单方法是，为请求QoS的IP分组流仿真同样的通过发信令表示资源预留的逐跳交换模式。实际上，因特网工程任务组(IETF)针对集成服务(Intserv或IS)而开发的IP信令标准正是采用了这一方法。如IETF RFC 1633[R.Branden等人1994年6月出版的“因特网体系结构中集成服务概述”]中所述，Intserv是一种基于流的(per-flow)IP QoS体系结构，这种体系结构使应用能够在多种供它们的数据分组使用的受控传送服务等级之间作出选择。为了支持这种能力，Intserv允许分组流发送器处的应用采用由IETF RFC 2205[Branden等人的“资源预留协议(RSVP)-第一版功能规格”，1997年9月]所定义的周知的资源预留协议(RSVP)来发起接收沿通往分组流接收器的路径上网元所提供的增强QoS的流。
RSVP是在网络设备的控制面上的一种QoS信令协议，它被用于为单向流请求资源(即RSVP为单向流请求资源)。RSVP不具有路由功能，相反，它被设计为配合单播和多播协议一起工作，以确保为那些根据路由表转发的分组提供QoS(即，RSVP参照转发表(即通过路由选择而填充的转发表))以决定对哪一个下游接口施加QoS的策略和接纳控制。
图1是根据RFC 2205利用RSVP来取得QoS的Intserv节点处理模型的框图。如图所示，发送主机100执行应用104，应用104发送诸如视频分配或IP电话(VoIP)之类的数据，这些数据所要求的QoS高于通常给予因特网业务的“尽力而为”QoS。连接在发送主机100和接收主机118之间的是一个或多个其他节点，例如实现路由进程116的路由器102。
在控制面中，每个网络节点包括支持RSVP消息的节点间通信的RSVP进程106、确定用户是否具有为增强QoS流预留资源的管理许可的策略控制块108、以及确定节点是否具有足够的输出带宽用于提供所要求的QoS的接纳控制块110。在数据面中，每个节点还包括标识某个流的分组并为每个分组确定QoS类的分组分类器112和按照分组分类器112所执行的分组分类实际取得每个流所要求的QoS的分组调度器114。
为了发起RSVP会话，应用104发送PATH(路径)消息，此消息顺序传送给发送主机100和接收主机118之间的各个节点处的RSVP进程106。尽管发送主机100发起RSVP会话，但接收主机118通过向接收主机118和发送主机100之间反向路径上的各个网络节点发送包含QoS请求的RESV消息，这样来负责请求指定的QoS。响应收到的RESV消息，每个RSVP进程106将该预留请求传送给其本地策略控制模块108和接纳控制块110。如上所述，策略控制块108确定用户是否具有进行预留的管理许可，而接纳控制块110则确定该节点是否具有足够的可用资源(即下游链路带宽)以提供所请求的QoS。如果这两种检查在发送主机110和接收主机118之间的所有节点都获得肯定答案，则每个RSVP进程106设置(install)本地分组分类器112和分组调度器114中的参数，以获得预期的QoS，而且发送主机100处的RSVP进程106通知应用104所请求的QoS的已获得批准。另一方面，如果路径上的任一节点处的任一检查结果是否定的，则发送主机100处的RSVP进程向应用104返回出错通知。
尽管概念上非常简单，Intserv Qos提供具有有限的扩展能力，这是因为在每个网络节点处需要计算密集型的RSVP处理。尤其是，RSVP需要基于流的RSVP信令、基于流的分类、基于流的管制/整形、基于流的资源管理和周期性刷新基于流的的软状态信息。所以，Intserv RSVP信令所要求的处理可与电话或ATM信令所要求的处理相比拟并要求每个IP路由器中的高性能(即昂贵的)处理器部件处理这种信令所要求的大量处理。
在认识到与利用传统的Intserv RSVP信令来实现IP QoS相关的可扩展性问题和其他问题之后，IETF公布了在RFC 2475中定义的区分服务(Diffserv或DS)协议。Diffserv是一种IP QoS体系结构，它通过在每个IP层分组首部中的DS字段(例如，IPv4的服务类型(TOS)字节或IPv6的服务类字节)传递聚合服务分类(aggregateservice分类)从而取得可扩展性。DS字段的前6位对Diffserv编码点(DSCP)编码，用于为Diffserv域内分组路径上每个节点处的分组请求特定的服务类别或每一跳行为(PHB)。
在Difserv域内，根据服务提供策略将网络资源被分配给各分组流，服务提供策略控制进入Diffserv域时的DSCP标记和业务量调节以及Diffserv内的业务量转发。仅需要在Diffserv网络边缘实现标记和调节操作。因此，无需发送端和接收端之间的端到端信令来设置具有指定QoS的流，Diffserv就简单地通过检查每个IP分组的首部和/或为该首部打标记而使得入边界路由器能够向聚合流提供QoS。
如IETF RFC 2998[Y.Bernet等人的“区分服务网络上的集成服务操作运行框架”，2000年11月]，以及如图2所示，集成服务可以实现于区分服务域之上。在图2所示的网络模型中，边缘路由器(ER)120、128将具有可感知集成服务的客户LAN(未示出)连接到区分服务网络124的边界路由器(BR)122、126。为了反映从LAN-TX(发送端)到LAN-RX(接收端)的单向业务流，在发送端或输入厕，边缘路由器120和边界路由器122被分别标记为ER-TX和BR-TX，而在接收端或输出侧，边缘路由器128和边界路由器126被分别标记为ER-RX和BR-RX。
从逻辑上看，路由器120、122、126和128中的每个路由器均具有控制面和数据面，分别如每个路由器中的上半部分和下半部分所示。数据面包括路由器转发路径上的所有常规硬件部件(例如接口卡和交换结构)，而控制面包括支持并控制数据面操作的控制硬件(如控制处理器)和控制软件(如路由、信令和协议栈软件)。
在数据面中，ER-TX 120的数据面120b用适当的DSCP(例如，基于Intserv 5元组源地址、目的地址、协议标识、源端口和目的端口)将分组打上标记并将其转发至Diffserv网络124。然后只使用区分服务转发分组，使之通过Diffserv网络124到达ER-RX 128的数据面128b。在控制面中，边缘路由器120、128和边界路由器122、126中的每个路由器均具有参照实现于策略决定点(PDP)130a、130b中的策略来执行Intserv(IS)处理的控制面。在ER-TX 120中，控制面120a执行基于流的分类和基于流的管制。在边界路由器122和126中，朝向边缘路由器120、128的Intserv接口管理RSVP信令，执行Intserv策略和接纳控制功能并维护路径状态块和预留状态块的基于流的状态。ER-RX 128的控制面128a在将输出分组转发至LAN-RX之前执行Intserv基于流的整形。
如上所述，在发送业务流之前，LAN-TX中的发送主机发起RSVP路径消息。当LAN-RX中的接收主机接收到路径消息时，接收主机沿反向数据路径返回RESV消息用于请求预留资源以提供预期的QoS。在接收到RESV消息之后，具有Intserv控制面的每一个中间路由器仅为其下游链路执行接纳控制。因此，ER-RX 128为LAN-RX执行接纳控制，BR-RX 126为其本身与ER-RX 128之间的链路执行接纳控制，BR-TX 122为穿过Diffserv网络124到BR-RX 126的路径执行接纳控制，以及ER-TX 120为其本身和BR-TX 122之间的链路执行接纳控制。RSVP接纳控制进程验证每条链路上的资源可用性并相应地调整该链路的剩余资源计数。
尽管Intserv基于流的接纳控制是在控制面上执行的，业务流的实际的QoS传递是在数据面上完成的。ER-TX 120对从其Intserv输入接口(IS IN)接收到的数据分组执行Intserv操作(即，基于流的分类、基于流的管制、和基于流的DSCP标记)。在ER-TX 120的Diffserv输出接口(DS OUT)上，仅根据数据分组的DSCP值标识数据分组并将其按类排队。然后，BR-TX 122在其输入接口(DS IN)对每个客户执行每一类管制，而在其输出接口(DSOUT)执行按类排队。在BR-RX 126，在其输入接口(DS IN)不执行任何操作，而在输出接口则对每个客户端口执行按类排队和可选的每一类整形。ER-RX 128转发在其输入接口(DS IN)处收到的分组并可在其Intserv输出接口(IS OUT)执行基于流的调度或整形。
尽管Diffserv标准通过用简单的基于类的处理来替代Intserv的处理密集型信令而改善了Intserv的可扩展性，但实现Diffserv协议带来了不同的问题。尤其是，由于Diffserv允许主机标记业务类，Diffserv网络客户链路(如BR-TX 126的输出链路)可能遭受拒绝服务(DoS)攻击(如果若干主机向该链路发送DS字段设为高优先级的分组)，如以上交叉引用的申请No.10/023331中所述。
此外，尽管对Diffserv域内可扩展性有所改善，但利用RSVP的Intserv接纳控制仍然需要在服务提供商网络的每个边缘和边界路由器上进行基于流的状态设置、基于流的状态刷新、基于流的业务量管理以及资源预留。因为边界路由器作为网络汇聚点要处理成千上万的业务流，许多厂商的边界路由器不能为如此众多的流设置流状态。因此，RSVP基于流的接纳控制很少被路由器厂商实现并支持。这样，采用RSVP的常规Intserv基于流的接纳控制因其缺乏可扩展性而仍然不理想。
发明概述本发明通过引入一种用于执行接纳控制的改进方法、装置和系统来解决现有技术中的前述和其他缺点。
根据本发明的一个实施例，策略服务器包括处理资源、与处理资源通信的通信接口以及存储可由处理资源执行的配置管理器的数据存储器。配置管理器对上游路由器的数据处理队列进行配置，以向多个数据流业务类中的一个或多个数据流业务类提供选定的带宽。此外，配置管理器向下游路由器发送一个或多个虚拟池容量，每个虚拟池容量对应于上游路由器处用于多个业务类中一个或多个相关业务类的带宽。在一个实施例中，配置管理器仅响应于对发送给下游路由器的一个或多个虚拟池容量已被成功设置的确认，而对上游路由器上的数据处理队列进行配置。
从以下详细书面说明可明白本发明的其他目的、特征和优点。
附图简述据信是本发明特征的创新特征在所附权利要求书中给出。但是，本发明本身及其最佳利用模式、其他目的和优点，将通过结合附图阅读如下对说明性实施例的详细说明而获得最佳理解，附图中图1显示常规的集成服务(Intserv)节点处理模型，其中，基于流的QoS是利用根据RFC 2205的RSVP信令取得的；图2显示一种常规的网络模型，其中，集成服务(Intserv)根据RFC 2998在区分服务(Diffserv)域上实现。
图3显示根据本发明最佳实施例的高级网络模型，它在区分服务(Diffserv)域上实现Intserv，同时取消区分服务(Diffserv)的边界路由器中的Intserv处理。
图4说明一种方法，通过此方法，可以在图3所示网络模型中识别业务流的接收边缘路由器。
图5显示根据本发明的最佳实施例的发送边缘路由器的更为详细的框图。
图6显示根据本发明的最佳实施例的接收边界路由器和接收边缘路由器的更为详细的框图。
图7显示根据本发明的最佳实施例的可用于实现策略决定点(PDP)的示范性服务器计算机系统的框图。
图8A说明一种在服务初始化期间在接收边界路由器和接收边缘路由器上设置策略的最佳方法；图8B说明一种响应服务更新而在接收边界路由器和接收边缘路由器上设置策略的最佳方法；以及图8C说明一种在对接收边界路由器进行直接服务更新之后进行策略同步的最佳方法。
最佳实施例的详细说明I.网络模型概述再次参照附图，尤其是参照图3，它显示了一种可扩展网络模型的高级框图，这种可扩展网络模型根据本发明在区分服务(Diffserv)域上实现基于边缘的Intserv，从而向选定的业务量提供增强的QoS。具体说，如下详述，所示网络模型采用一种将基于流的带宽需求映射到基于类的资源池以进行资源预留和管理的机制，从Diffserv内的网络设备中取消了Intserv基于流的接纳控制，从而改善了网络可扩展性。为了便于理解，图3采用与图2相同的接收端/发送端和数据面/控制面符号。
在图3中，可包含一个或多个主机的可感知集成服务(IntegratedServices-aware)的LAN-TX和LAN-RX连接到客户驻地设备(CPE)边缘路由器(ER)150、158。边缘路由器150、158通过接入网(例如L2接入网)分别连接到Diffserv网络124的边界路由器(BR)152、156上。网络服务提供商利用一个或多个PDP 160对路由器150、152、156和158进行配置并在150、152、156和158上设置接纳控制和其他策略。
利用这种配置，图3的网络模型支持从LAN-TX中的发送主机到LAN-RX中的接收主机的单向业务流。这种通信最好利用分层协议结构来进行，在分层协议结构中，每个协议层独立于高层协议和低层协议。在一个最佳实施例中，通信在网络层利用熟知的因特网协议(IP)，所述网络级对应于ISO/OSI(国际标准化/开放系统互联组织)参考模型的第3层。在网络层之上，通信可能在对应于OSI/ISO参考模型第4层的传输层中采用TCP(传输控制协议)或UDP(用户数据报协议)。
在传输层之上，通信可采用任意数量的不同的协议，这由所需QoS和流的其他需求来部分地确定。例如，国际电信联盟(ITU)H.323协议和IETF会话发起协议(SIP)通常用于提供基于IP网的语音、视频、多媒体和其他类型的增强QoS会话的信令。作为端到端协议，SIP有利地允许端点具有利用各种呼叫功能(例如寻我/跟踪功能)来控制呼叫处理的能力。
图2所示的现有技术网络模型至少在每个边缘路由器和Diffserv边界路由器中需要执行Intserv处理的Intserv控制面，与现有技术相反，图3所示的网络模型仅在网络的最终边缘，即受网络管理的CPE边缘路由器150、158上采用Intserv处理。因此，对于所示单向分组流，边缘路由器150、158利用RSVP信令执行Intserv接纳控制，以便为从LAN-TX到LAN-RX的流提供增强的QoS。因为边缘路由器150、158为Diffserv网络154执行Intserv接纳控制(并假定Diffserv网络154已经实施了良好的流量工程)，则Diffserv网络154无需实现任何其他的接纳控制。所以，根据本发明，不要求Diffserv网络154中的任一路由器(包括边界路由器152、156和未示出的核心路由器)具有Intserv控制面，正如标号152a和156a处所示。所以，边界路由器152和156可以大大简化，从而有助于服务提供商网络增强可扩展性。
为了在边界路由器152、156中取得这种有利的简化，图3所示的网络模型对常规的Intserv RSVP信令模型进行修改，如上所述，常规的Intserv RSVP信令模型总是在每个节点处执行对称处理以便为下游链路执行接纳控制。在图3所示的网络模型中，由接收主机返回的RSVP RESV消息仅由边缘路由器150、158的Intserv控制面150a、158a进行处理，该控制面150a、158a验证所请求的资源的可用性并相应地调整资源计数。具体地说，ER-TX 150的Intserv控制面150a为其本身与BR-TX 152之间的链路执行下游接纳控制。但是，ER-RX 158的Intserv控制面158a不仅为其下游链路(即LAN-RX)执行接纳控制，而且为其上游链路和BR-RX 156执行接纳控制，这是因为边界路由器152、156不可感知RSVP。
尽管概念上很简洁，图3所示的这种网络模型具有若干并非不重要的难题，这些难题必须予以解决以便得到可行的网络实现方案。例如，因为常规的Intserv RSVP信令在每个节点处是对称的，故没有提供常规机制用于通知ER-RX 156它就是“接收”边缘路由器且它因此必须为其上游链路执行接纳控制。此外，常规Intserv RSVP信令没有向ER-RX 156提供任何有关上游链路的资源容量和资源可用性的信息，所述上游链路是必须为其执行接纳控制的上游链路。而且，RFC 2998(以及现有技术一般)没有提供有关如何在ER-TX 150处实现Diffserv/Intserv互通功能的任何指南，尤其是没有揭示如何将Intserv类映射到Diffserv类。对涉及图3所示网络模型实现的这些和其他问题的最佳答案如下详述。
II.接收边缘路由器识别现参照图4，它说明一种最佳方法，通过这种方法，例如ER-RX158的边缘路由器就可确定它是接收边缘路由器。在所示操作方案中，客户LAN、边缘路由器150、158和边界路由器152、156中每一个均具有不同的IP地址，与ER-RX 158相连的每个客户LAN均被分配IP地址，该IP地址是分配给ER-RX 158的IP地址的子网。
如上所述，LAN-TX中的发送主机通过发送RSVP PATH消息与LAN-RX中的接收主机开始进行增强QoS会话。基于PATH消息中指定的目的地址(DestAddress)，该地址在所示实例中为a.b.p.d，将PATH消息经Diffserv网络154路由到LAN-RX。接收主机响应此PATH消息而发送包含指定目的地址的SESSION(会话)对象的RSVP RESV消息。一收到RESV消息，ER-RX 158的Intsev控制面158a中的RSVP进程就可通过将目的地址与每个相连的客户LAN的IP子网地址作比较从而判定ER-RX 158是否是接收边缘路由器。如果且仅当如果目的地址属于ER-RX 158的相连客户子网之一，则ER-RX 158“知道”它就是业务流的接收边缘路由器。例如，当ER-RX 158收到具有包含目的地址a.b.p.d的SESSION对象的RESV消息时，则ER-RX 158就知道它是接收边缘路由器，因为LAN-RX的IP地址(例如a.b.p.d)是a.b.p.0/24的一个IP子网地址。因此，ER-TX 158为增强QoS流所用的它的上游链路执行Intserv接纳控制。
尽管识别接收边缘路由器的这种方法具有简单的优点，但它要求每个目的地址指定接收边缘路由器的IP地址的子网。在不希望这种限制的实现中，可以采用识别接收边缘路由器的其他方法。例如，如以下参照图6的详述，接收边缘路由器还可通过由PDP 160在边缘路由器150、158上配置的边缘点标识表来加以识别。这些策略数据结构指定了IP地址的一个或多个范围，对应这些地址的路由器是接收边缘路由器。
III.资源管理为了跟踪资源可用性(包括用于执行上游接纳控制的资源可用性)，每个具有可感知Intserv服务的边缘路由器在其控制面中为每个Intserv类维护独立或共享的虚拟池，其中，每个虚拟池表示某条链路上相关Intserv类的资源可用性，所述链路是路由器为其执行接纳控制的链路。只要边缘路由器接收到RSVP RESV消息，边缘路由器就将所请求的带宽与合适的虚拟池进行对照检查，以确定所请求Intserv类中的资源可用性，从而为该链路执行接纳控制。如果虚拟池指示所请求的带宽小于可用带宽，就批准预留请求并从虚拟池中可预留资源中减去所要预留的带宽量。但是，如果所请求的带宽超过虚拟池的可用带宽，则拒绝QoS请求。
通过将用于执行Intserv接纳控制的虚拟池与数据面上由Diffserv用于传递基于类的QoS的逻辑队列相关联，从而取得Intserv接纳控制和Diffserv数据面功能之间的互通。具体地说，每个Intserv类唯一地与一个且只与一个Diffserv逻辑队列相关联。但是，正如用于执行Intserv接纳控制的虚拟池一样，可以为一个或多个Intserv类中的每一个类实现一个独立的队列，而一个或多个逻辑队列可以实现为与多个Intserv类相关的共享队列。
下表I概括了可在服务提供商网络的边界路由器和边缘路由器内实现的逻辑队列和虚拟池的可能的组合形式。
表I
如表I所示，有三种可能的情况独立的虚拟池与独立的逻辑队列、共享的虚拟池与共享的逻辑队列以及独立的虚拟池与共享的逻辑队列。由多个Intserv类共享一个虚拟池的情况不适用于每个Intserv类有相应独立逻辑队列的实现方式，因为可能没有可用的基于单个类的虚拟池信息。重要的是，只要正确地执行标记操作，则可将同一网络中的边界和边缘路由器配置为同时实现不同的情况。
现在来参照图5和图6，它们显示图3所示网络模型的边缘路由器和边界路由器的更加详细的框图，其中，根据表I中的情况1在控制面中为每个Intserv业务类中的业务量分配了独立的虚拟池，而在数据面中为每个Intserv业务类中的业务量分配了独立的逻辑队列。首先参照图5，它显示ER-TX 150的更为详细的框图。如上所述，ER-TX 150具有Intserv控制面150a和数据面150b，控制面150a管理RSVP信令并实现Intserv策略和接纳控制，控数据面150b提供链路级的Diffserv基于类的QoS的传递。控制面150a包括RSVP进程180、具有相关虚拟池184的接纳控制块182、策略控制块188、IS-DS互通功能(IWF)配置块186以及策略配置接口(PCI)190，EF-TX 150通过该策略配置接口190与PDP 160a进行策略信息通信。数据面150b具有输入端口200、转发功能208以及具有若干队列212的输出端口210，队列212中每个队列对应某个Diffserv类。
如上所述，控制面150a中的RSVP进程180处理为增强QoS流预留(和释放)资源的RSVP信令(例如PATH和RESV消息)。响应于收到的为增强QoS流请求资源的RESV消息，RSVP进程180查询接纳控制块182和策略控制块188以验证请求者是否具有设置QoS流的管理许可权以及下游接口是否具有足够的资源用于支持所请求的QoS。除了确定管理许可权以外，策略控制块188还可执行其他策略，例如基于证书或签名的认证、对授权请求者中带宽分配的管理以及为某个挂起的较高优先级的流抢占已分配的资源。
在所示实施例中，每个所支持的Intserv类(例如，保证服务(GS)和控制负载(CL))均具有独立的虚拟池184a、184b。接纳控制块182监测使用虚拟池184的每个Intserv类的下游链路上的资源可用性。因此，当与被请求Intserv类相关的虚拟池中有足够的可供利用的带宽时，接纳控制块182就批准预留请求，否则就拒绝该预留请求。接纳控制块182从虚拟池中减去每次成功预留所需的可用资源量，并在虚拟池中增加流终止时所释放资源量那么多的可预留资源。重要的是，虚拟池的数量、分配给各虚拟池184的带宽以及虚拟池和Diffserv类之间的映射关系不是固定的，相反，它们可以表示为由PDP 160在ER-TX 150(和其他网元)处设置的策略。利用公共开放策略服务(COPS)或其他协议，PDP 160可将这些策略推向网元，或者，由网元在例如响应收到的RSVP RESV消息时从PDP 160拉取这些策略。
PDP 160a对IS-DS IWF配置块186中Intserv类和Diffserv类(和DSCP)之间的映射关系进行配置(例如GS至DSCP 100011、CL至DSCP 010011)。IS-DS IWF配置块186还可从RSVP进程180接收配置。根据这些配置，IS-DS IWF配置块186在输入端口200上针对每个Intserv流动态地配置分组分类器202、策略器204和标记器206。(在一些实现方式中，分组分类器202、策略器204和标记器206可以实现为单一集成模块，如现场可编程门阵列(FPGA)或专用集成电路(ASIC))。
根据这种配置，分组分类器202对每个Intserv流内的分组(这种分组的业务类由5元组指示)进行分类，而标记器206则用聚合Diffserv类的适当DSCP(例如，用保留供调试或局部使用的16个编码点(池2 xxxx11)之一)对这些分组进行标记。这样，具有增强QoS的Intserv流被汇聚成具有优先权的Diffserv类。因为图5所示的实施例反映了表I中的情况1，故除了分配给其他Diffserv类(例如，加速转发(EF)、保证转发(AF)和缺省的尽力传送(BE)类)的逻辑队列以外，还在端口210上为每个所支持的Intserv类(GS和CL)设置独立的逻辑队列212。然后，调度器214根据由PDP 160a分配给每个逻辑队列212的调度权重对从逻辑队列212的发送进行调度，从而为每个逻辑队列212中的分组提供适当的QoS。
因为所示的ER-TX 150实施例由网络服务提供商管理，故网络服务提供商可以靠ER-TX 150来正确地用DSCP来对分组进行标记，以便不会出现“窃取”QoS。但在ER-TX 150未由网络服务提供商管理的备选实施例中，PDP服务器160a可将Diffserv分类策略提供给BR-TX 152而非ER-TX 150。应注意，Diffserv网络154的核心路由器不需要为各Intserv流实现各自独立的Diffserv队列，即使独立的队列已在边缘路由器和边界路由器上实现。
现在参照图6，它显示根据表I中情况1的最佳实现方案的BR-RX 156和ER-RX 158更为详细的框图。如上所述，BR-RX 156和ER-RX 158分别具有各自的控制面156a、158a和数据面156b、158b。ER-RX 158的控制面158a是增强的Intserv控制面，它包括PCI 190、具有相关接纳控制块182和策略控制块188的RSVP进程180和边缘点标识表252和上游虚拟池250，接纳控制块182通过边缘点标识表252和上游虚拟池250执行上游接纳控制。相反，BR-RX 156a不具有Intserv控制面，而是只包括PCI 190，PDP 160b通过PCI 190对数据面156b的部件进行配置。
在ER-RX 158的控制面158a内，PDP 160b设置策略，通过这些策略本地策略控制188可确定哪些客户具有为增强QoS流请求资源预留的管理许可权。此外，PDP 160b设置边缘点标识表252，此表指定一个或多个目的IP地址范围，属于这些IP地址范围的ER-RX158就是接收边缘路由器。因此，在接收到请求增强QoS流(策略控制188已准予客户请求该增强QoS流的管理许可权)的RESV消息后，接纳控制182就查询边缘点标识表252，以确定ER-RX 158是否是所请求的流的接收边缘路由器。如果不是，则ER-RX 158仅执行常规的下游接纳控制。但是，如果边缘点标识表252指示ER-RX158是所请求的流的接收边缘路由器，则接纳控制块182通过参照PDP160b在虚拟池250内为每个Intserv类分配的上游虚拟池容量执行上游接纳控制。如前所作的概述，各虚拟池250a、250b分别由接纳控制块182用于证实在ER-RX 158和BR-TX 152之间的上行链路上是否有足够的带宽可用于所请求的特定Intserv类的流。如标号252所示，PDP 160b获取有关ER-RX 158上虚拟池使用情况的定期的或请求的反馈并通过更新数据面中实现的逻辑队列和调度权重，动态地协调任何操作者发起的(operator-initiated)对虚拟池容量的调整，以确保实际被利用的Intserv带宽少于操作者指定的容量。
现在参照数据面，ER-RX 158的数据面158b可采用常规的分类、转发和Intserv排队来实现，其细节在此予以省略以突出本发明。BR-RX 156的数据面156b包括具有分类器222的输入端口220、具有多个Diffserv物理队列242和调度器244的输出端口240、以及根据分类器222所作的分类将分组从输入端口交换至输出端口240上适当的物理队列242中的转发功能230。如图所示，分类器222和物理队列242由PDP 160b以一致的方式进行配置，以反映ER-RX 158的控制面158a上的上游Intserv虚拟池的配置。具体地说，在所示实施例中，对分类器222进行配置使之识别属于各Intserv业务量所汇聚到的不同Diffserv类的分组，以便将每个代表Intserv业务量类型的Diffserv类中的分组转发至对应输出端口240上对应Intserv GS和CL类的各独立物理队列242中。PDP 160b还对调度器244赋予每个队列242的调度权重进行配置。此外，PDP 160对ER-RX 158上的虚拟池容量的总和与BR-RX 156的数据面156b中队列容量和权重所决定的资源池容量进行协调，以确保虚拟池容量没有超过实际的资源池容量。因此，本质上，ER-RX作为BR-RX的代理执行上游接纳控制。
如图5和图6所示，与将所有Intserv类映射到单一Diffserv队列相比，将不同的Intserv类映射到各个独立的虚拟池和Diffserv队列则可进行更好的业务量管理。以这种方式在Diffserv网络上保持各Intserv类之间的区别，从而可以为不同的业务量类型(例如，IP电话、视频IP和文件传输)提供最优的处理，并且简化了企业资源规划。然而，如上所述，服务提供商网络中的一些或所有路由器还可能按照情况2和情况3来实现。为了实现情况2而非情况1，分别为ER-TX 150和ER-RX 158配置一个供多个Intserv类共享的池，并且分别为ER-TX 150和ER-RX 156配置一个供多个Intserv类共享的队列。或者，为了实现情况3，分别为ER-TX 150和ER-RX 158配置若干各自独立的虚拟池，并且分别为ER-TX 150和ER-RX 156配置一个供多个Intserv类共享的队列。
应注意，为了向特定流提供增强的QoS，并不要求BR-TX 152的控制面152a或数据面152b具有特定于流的网络配置。这是因为由下游ER-RX 158提供的接纳控制确保BR-TX 152的下游链路具有足够的带宽用于支持每个被接纳的增强QoS流，以及Intserv流到特定Diffserv类的映射确保数据面152b取得所请求的QoS。
IV.PDP现参照图7，它显示根据本发明的最佳实施例的可作为PDP 160使用的服务器计算机系统的高级框图。PDP 160包括一个或多个通过互连264连接到存储子系统268的处理器262，存储子系统268可包括随机存取存储器(RAM)、只读存储器(ROM)、磁盘、光盘和/或其他存储技术。存储子系统268存储由处理器262处理的数据(例如表格280-290)和指令(例如配置管理器292)，以对网元进行配置以及设置并确定网络策略。与互连264相连的还可能有一个或多个输入设备(例如，键盘和/或图形定点设备)270和一个或多个输出设备(例如显示器)272以及通信接口274，计算机系统260通过通信接口274与网络设备，如路由器150、152、156和160通信。
为了以上述方式在路由器150、156、160上配置并设定策略，每个PDP 160最好在存储子系统268内实现若干策略规则类(PRC)表。在一个最佳实施例中，这些PRC表至少包括接纳控制虚拟池表280、Intserv容量表282、Intserv与Diffserv互通功能表284、边缘点识别表286、池使用反馈表288以及边界资源池表290。
接纳控制虚拟池表280确定边缘路由器150、158上的虚拟池容量，它们被用于执行针对各种Intserv类的接纳控制。在接纳控制虚拟池表280中，分配给与所有Intserv类相关的虚拟池的容量总和被设置为小于相关边缘路由器的数据面队列的容量，以确保可以取得每个被接纳的流所要求的QoS。该表还规定接纳控制是否会接受预留以及与边缘路由器相关的边界路由器的逻辑接口名。在示范性实施例中，接纳控制虚拟池表280可以如下定义为接纳控制虚拟池表LogicalInterfaceName(逻辑接口名)说明此SNMP字符串标识与接纳控制虚拟池表表项(entry)相关的逻辑接口。
对象类型SNMP字符串。
Direction(方向)说明此属性将业务流与接口的关系表示为(1)输入或(2)输出。此属性与BoundaryLogicalInterfaceName属性配合使用，用于区分ER-RX虚拟资源池和ER-TX虚拟资源池。ER-RX上游虚拟资源池具有输入方向和非空BoundaryLogicalInterfaceName属性。ER-TX下游虚拟资源池具有输出方向和非空BoundaryLogicalInterfaceName属性。ER-RX下游虚拟资源池具有输出方向和为空的BoundaryLo gicalInterfaceName属性。
IntSrvClass说明此位串表示Intserv类或具有由接纳控制从虚拟池中分配的资源的类。
对象类型比特控制负载服务(1)保证服务(2)无服务(3)其他(4)VirtualPoolMaxAbsRate说明本池可以分配给接纳控制IntSrvClass所定义的Intserv会话的以千比特计的最大绝对速率。ER-RX上游虚拟资源池的总和不会超过相关BoundaryInterfaceName的ResourcePoolMaxAbsRate。
对象类型无符号32位数。
BoundaryLogicalInteffaceName说明标识决定此表所定义的本地虚拟池的容量的相邻边界路由器和资源池。此属性为空时表示针对此表的LogicalInterfaceName而定义的本地ResourcePoolMaxAbsRate决定VirtualPoolMaxAbsRate。
此属性非空则表示针对此BoundaryLogicalInterfaceName而定义的远程虚拟池容量决定此表的VirtualPoolMaxAbsRate的值。
对象类型SNMP字符串。
AcceptReservations说明此值表示接纳控制是否将试图处理RSVP RESV请求。其值为0表示不会处理预留请求。而其值为1则表示将会处理预留请求。
对象类型无符号32位数。
Intserv容量表282从Diffserv队列权重和整形器参数这两个角度定义分配给Intserv类的数据面数据率容量。此表还将这些速率容量与一个或多个边缘路由器虚拟池相关联。根据一个最佳实施例，策略规则类包含在区分服务策略信息库(PIB)中。
Intserv到Diffserv IWF表284定义用于控制面中RSVP进程与数据面中Diffserv之间互通的属性。这些属性由ER-TX 150的输入端口200上的分类器202、策略器204和标记器206用于对Intserv业务流进行分类、管制和标记，以便Diffserv为每个流取得合适的QoS。此外，此表规定将特定的调度器实例用于具有特殊Intserv类别的流。Intserv到Diffserv IWF表284的一个例示性实施例如下Intserv到Diffserv互通功能表IwfPrid说明这是PktIwfTable表项的唯一标识符。
对象类型实例ID(无符号32位数)。
IwfIntSrvClass说明与此特定互通功能表的属性相关的Intserv类的值。
(AdmCtlIntSrvClass中必须设置相应的比特位)。
对象类型无符号32位数。
IwfDSCP说明DSCP值，用于为会话的数据流分配与PktIwfIntSrvClass的值相匹配的Intserv类类型。
对象类型0-63的整数值。
IwfOutOfProfile说明此值指示当数据流超出业务描述(profile)时的管制行为。业务描述可由相关的MeterTableEntry(计量表项)定义。其值为1表示超出业务描述的分组将被丢弃。
其值为2表示将用IwfRemarkValue中定义的DSCP对超出业务描述的分组重新标记。
对象类型无符号32位数。
IwfRemarkValue说明DSCP值，用于重新标记超出业务描述的分组。此值仅当IwfOutOfProfile设为2时才被使用。
对象类型值在0-63之间的无符号32位数。
IwfSchedulerPrid说明由会话数据流使用的特定调度器的实例ID值，其中所述的会话数据流具有与属性IwflntSrvClass的值相匹配的Intserv类。
对象类型无符号32位数。
边缘点标识表286定义若干定址范围，属于这些地址范围的边缘路由器就是接收边缘路由器。此信息可一开始就配置在PDP 160上或者可于本地获知。ER-RX 158上的接纳控制块182为预留请求执行上游接纳控制，其中所述的预留请求在其RSVP会话对象内指定的目的地址属于这些地址范围之一。特定边缘路由器的值可由PDP160利用COPS或其他策略协议向下推到本地边缘点识别表252。根据一个实施例，边缘点标识表286可以如下定义为端点标识表ReceiverDomainPrid说明此策略规则类表项的唯一标识符。
对象类型实例ID，32位无符号整数。
ReceiverAddrType说明指定如RFC 2851[M.Daniele等人的“因特网地址的文本协定”，2000年6月]中所定义的地址类型的枚举值。
对象类型RFC 2851所定义的INET地址类型。
ReceiverAddr说明要匹配的会话对象目的地址的IP地址。
对象类型RFC 2851所定义的INET地址类型。
ReceiverAddrMask说明用于匹配INET地址的掩模的长度。
对象类型无符号32位数。
池使用反馈表288包含说明Intserv流目前所占用的资源的表项。此PRC表由PDP 160用于确定何时完成操作者发起的容量更新，在一个例示实施例中可以将其定义为池使用反馈表使用反馈Prid说明虚拟池使用反馈表表项的唯一标识符。
对象类型实例Id(无符号32位数)。
PoolPrid说明用法将描述的特定接纳控制虚拟池表项的实例ID的值。
对象类型无符号32位数。
ResourceAbsRateInUse说明当前在用的总的Intserv资源数。
边界资源池表290定义可由PDP 160分配给与给定输出边界路由器(BR-RX)相关联的各种接纳控制虚拟池的总速率容量。在一个例示实施例中此PRC表可如下定义为边界资源池表边界资源池表BoundaryResourcePooLPrid说明虚拟池使用反馈表项的唯一标识符。
对象类型实例Id(无符号32位数)。
BoundaryLogicalInterfaceName说明标识控制与接纳控制虚拟池表中相同表项相关的本地虚拟池的容量的相邻边界路由器和资源池。
对象类型SNMP字符串。
ResourcePoolMaxAbsRate说明可分配给接纳控制虚拟池表所定义的Intserv会话的以千比特计的最大绝对速率。ER-RX上游虚拟池的总和不会超过相关BoundaryInterfaceName的ResourcePoolMaxAbsRate。
对象类型无符号32位数。
V.网络配置现在参照图8A-8C，它们显示了几个网络图，这些网络图共同说明PDP 160b在BR-RX 156和ER-RX 158上配置并设定策略所采用的最佳技术。所示功能可以通过例如配置管理器软件292的PDP 160的执行来实现。在每个图中，假定PDP 160b和路由器156、158之间的通信是利用COPS来进行的，不过应理解，也可以采用其他协议。
图8A特别说明PDP 160在服务初始化期间如何使ER-RX 158上的虚拟池容量与BR-RX 152上的Diffserv逻辑队列带宽同步。如图8A标号300处所示，网络管理系统(NMS)可以在例如服务初始化期间初始化客户的Intserv容量配置。作为响应，PDP 160b将Intserv虚拟池容量配置推向每个作为Diffserv网络154的边界路由器的受网络管理的下游边缘路由器(其中只示出ER-RX 158)。例如，在所示实施例中，PDP 160b利用消息将接口l.m.n.b/30处LP1所支持的每个Intserv类的虚拟池容量推向ER-RX 158，从而把10兆比特分配给Intserv GS类、把25兆比特分配给Intserv CL类。如果在ER-RX 158上成功设定了该配置，则ER-RX 158以确认(ACK)消息作为应答，如标号304处所示。然后如标号306所示，PDP 160b将相应的Diffserv队列和调度权重配置推向BR-RX 156。如果成功地设定了配置，则BR-RX 156也向PDP 160b返回ACK 308。
如果ER-RX 158未能设置由PDP 160b推过来的虚拟池容量，则ER-RX 158向PDP 160b返回否定确认(NACK)。PDP 160b相应地向网络操作者发送告警消息，例如“未能在ER XX上配置集成服务虚拟池！”类似地，如果不能在BR-RX 156上设置队列和调度权重，则BR-RX 156向PDP 160b返回NACK。作为响应，PDP 160b向ER-RX 156发送释放虚拟池配置的消息，并且还向网络操作者发送“未能在BR XX上配置队列和调度器”的告警消息。
应注意，PDP 160b可能不与网元如BR-RX 156和ER-RX 158直接通信，而是通过其他网元通信。例如，PDP 160b和BR-RX 156之间的消息可以通过ER-RX 158传送。
现将注意力转到这样一种方案其中，为现有的网络服务客户执行服务更新(即，增加或减少预定的Intserv容量)。当当前预留的带宽低于新的预定容量时，增加或减少BR-RX容量是直截了当地过程，因为新的容量可以容纳所有输出客户业务量，这意味着观察不到对服务的影响。但是，当当前预留的带宽大于新的预定容量时，增加或减少BR-RX容量要求在PDP 160b、BR-RX 156和ER-RX 158之间进行协调，如下参照图8B所述。
在图8B中，NMS可启动对现有网络服务客户的Intserv容量的重新配置，如标号320处所示。如标号322处所示，PDP 160b在ER-RX158上设置新的虚拟池容量值。ER-RX 158的接纳控制块182将每个新的虚拟池容量值与每个虚拟池内当前预留的资源总量作比较。如果新的虚拟池容量值大于每个虚拟池中当前预留的资源总量，则ER-RX 158的接纳控制块182用新值重写虚拟池容量值并立即向PDP160b发送ACK 324。但是，如果新的虚拟池容量值小于当前预留资源的总量，则ER-RX 158的接纳控制块182保存新的容量值但不重写旧值。ER-RX 158的接纳控制块182不接受对待执行更新的虚拟池的任何新的预留请求，直到预留资源总量低于新的虚拟池容量为止。一旦预留资源低于新的虚拟池容量，则ER-RX 158的接纳控制块182用新值重写旧的虚拟池容量值并通过向PDP 160b发送ACK324确认已接受新的虚拟池容量值。
PDP 160b推迟在BR-RX 156上安装新的调度权重，直到PDP160b从ER-RX 158接收到ACK 324为止。PDP 160b响应ACK 324，将队列配置和调度权重推向BR-RX 156如标号326处所示。在成功地设置新的队列配置和调度权重之后，BR-RX 156向PDP 160b返回ACK 328。
在备选实施例中，由PDP 160b而非ER-RX 158来确定何时执行虚拟池容量更新。在此实施例中，PDP 160b请求有关当前预留Intserv带宽的报告或者通过程序设定由ER-RX 158定期主动报告当前预留Intserv带宽。如果当前预留带宽大于由NMS指定的新容量，则PDP 160b可将直到预留带宽低于新容量才开始接受新的预留请求的策略推向ER-RX 158。为了进一步减少消息总量，PDP 160b可将一种策略推向ER-RX 158，这一策略指示ER-RX 158仅在预留带宽小于新的容量时才向PDP 160b主动发送报告。作为对来自ER-RX 158的指示当前预留Intserv带宽低于新的虚拟池容量的消息的响应，PDP160b将新的Intserv虚拟池策略推向ER-RX 158并将相应的新的调度队列和权重以上述方式推向BR-RX 156。
如果PDP 160b未能成功地更新ER-RX 158或BR-RX 156，PDP160b可返回旧的虚拟池容量、队列和调度权重配置。此外，PDP 160b可向网络操作者发送告警消息，以描述故障原因(例如，“未能在ERXX上配置更新的集成服务虚拟池容量！”或者“未能在BR XX上配置更新调度权重！”)。
为了防止PDP(如PDP服务器160b)成为单一故障点，可将备用PDP用于一个或多个主PDP。如果主PDP故障，则可将Intserv服务控制切换到备用PDP，并且由主PDP控制的每个ER-RX可向备用PDP报告其当前的预留状态。但是，每个ER-RX应该停止接受新的预留请求，直到完成到备用PDP的切换为止。在主PDP恢复之后，备用PDP首先与主PDP同步状态，然后通知每个ER-RX切换回到主PDP。在切换回到主PDP之后，每个ER-RX使其预留状态与主PDP同步。
如果ER或BR发生故障，则利用IP路由和RSVP刷新消息来发现新的路由并为发生故障的ER或BR周围的流重新进行路由选择。在成功地重新进行路由选择之后，PDP 160b可将策略推向相应的BR-RX 156以释放分配给失效ER-RX的Intserv业务量的Diffserv队列，或者将策略推向失效BR-RX的所有下游ER-RX以释放失效BR-RX的已配置虚拟池。
现在参照图8C，它显示一种例示方案，其中，NMS或网络服务提供操作者直接更改BR-RX 156上的队列和调度权重的配置。作为对更新操作的响应，BR-RX 156将变化通知PDP 160b。如果通知中未包含配置更新，则PDP 160b从BR-RX 156拉取配置更新，如标号342处所示，然后，如标号344处所示，将虚拟池容量的新配置推向所有受影响的ER-RX(其中，仅示出ER-RX 158)。
VI.结论如上所述，本发明提供了一种可扩展的IP网络模型，此模型通过在Diffserv域上实现基于边缘的Intserv从而为选定的流提供端到端的QoS。所述网络模型支持许多功能，包括仅在CPE边缘路由器处利用Intserv RSVP处理执行基于流的接纳控制、接收边缘路由器识别、在接收边缘路由器处进行上游接纳控制、基于池的资源管理以及通过策略管理在接收边界路由器和接收边缘路由器之间同步带宽使用信息。尽管引入了其他功能，但本发明的网络模型与现有的Intserv、COPS和Diffserv模型是一致的，且Diffserv策略提供模型使用了策略和管理信息数据库。本发明的网络模型有利地增强了可扩展性，同时保持了一种标准化体系结构，因此易于采用并实现。
尽管以上已对本发明的各种实施例作了描述，应理解，它们仅作为示例给出，而不是作为限制。因此，本发明的广度和范围不受上述例示实施例局限，而仅根据所附权利要求书及其等效来限定。例如，尽管本发明主要是参照采用资源预留协议(RSVP)和因特网协议(IP)的实施方案来加以讨论的，但应理解，本发明适用于其他通信协议，包括会话发起协议(SIP)和ITU H.323，它们可用于执行接纳控制通过基于策略和可用资源有选择地接纳或拒绝增强QoS流。而且，尽管已参照执行各种功能以便为选定的网络流取得端到端QoS的各种硬件单元对本发明作了说明，但应理解，这些功能也可以通过执行包含在计算机可读媒体中的程序代码来予以实现。本说明书中所使用的术语“计算机可读媒体”指任何参与向数据处理系统提供指令以供执行的媒体。这种媒体可以采取任何形式，包括但不限于非易失性媒体、易失性媒体和传输媒体。
权利要求
1.一种用于数据网络的策略服务器，包括上游路由器和下游路由器，所述上游路由器包括一个或多个数据处理队列，所述策略服务器包括处理资源；与所述处理资源通信的通信接口；以及存储可由所述处理资源执行的配置管理器的数据存储器，其中，所述配置管理器对所述上游路由器的一个或多个数据处理队列进行配置，以向多个数据流业务类中的一个或多个数据流业务流提供选定的带宽，并且，所述配置管理器向所述下游路由器发送一个或多个虚拟池容量，每个所述虚拟池容量对应于所述上游路由器处用于所述多个业务类中一个或多个相关业务类的带宽。
2.如权利要求1所述的策略服务器，其特征在于，所述配置管理器在对所述上游服务器中的所述数据处理队列进行配置之前向所述下游服务器发送所述虚拟池容量。
3.如权利要求2所述的策略服务器，其特征在于，所述配置管理器仅响应于发送给所述下游路由器的所述一个或多个虚拟池容量已被成功设置的确认，而对所述上游路由器上的所述数据处理队列进行配置。
4.如权利要求1所述的策略服务器，其特征在于，所述配置管理器响应收到的业务初始化消息而对所述上游路由器上的所述一个或多个数据处理队列进行配置，并向所述下游路由器发送所述一个或多个虚拟池容量。
5.如权利要求1所述的策略服务器，其特征在于，所述配置管理器通过指定(1)所述一个或多个业务类和所述一个或多个数据处理队列之间的映射；以及(2)每个所述一个或多个数据处理队列的调度权重来对所述上游路由器的所述一个或多个数据处理队列进行配置。
6.如权利要求1所述的策略服务器，其特征在于，所述配置管理器响应所述虚拟池容量大于所述上游路由器处当前预留的带宽的判定，向所述下游路由器发送虚拟池容量。
7.如权利要求1所述的策略服务器，其特征在于，所述配置管理器对未能在所述下游路由器上设置所述一个或多个虚拟池容量或者未能对所述上游路由器上的所述一个或多个数据处理队列进行配置作出响应而输出告警消息。
8.如权利要求1所述的策略服务器，其特征在于，所述配置管理器响应收到的已对所述上游路由器作了重新配置的指示，自动向所述下游路由器发送一个或多个新的虚拟池容量，以使所述一个或多个虚拟池容量与所述一个或多个数据处理队列的新配置重新同步。
9.一种数据网络，包括如权利要求1所述的策略服务器；以及至少上游路由器和下游路由器，所述上游路由器和所述下游路由器被连接用于数据通信。
10.一种供策略服务器用于管理包括上游路由器和下游路由器的数据网络的程序产品，所述上游路由器包括一个或多个数据处理队列，所述程序产品包括计算机可用媒体；和位于所述计算机可用媒体内的配置管理器，所述配置管理器对所述上游路由器上的所述一个或多个数据处理队列进行配置以向多个数据流业务类中的一个或多个数据流业务流提供选定的带宽，并且所述配置管理器向所述下游路由器发送一个或多个虚拟池容量，每个所述虚拟池容量对应于所述上游路由器处用于所述多个业务类中一个或多个相关业务类的带宽。
11.如权利要求10所述的程序产品，其特征在于，所述配置管理器在对所述上游服务器中的所述数据处理队列进行配置之前向所述下游服务器发送所述虚拟池容量。
12.如权利要求11所述的程序产品，其特征在于，所述配置管理器仅响应于发送给所述下游路由器的所述一个或多个虚拟池容量已被成功设置的确认，而对所述上游路由器上的所述数据处理队列进行配置。
13.如权利要求10所述的程序产品，其特征在于，所述配置管理器响应收到的业务初始化消息，而对所述上游路由器上的所述数据处理队列进行配置并向所述下游路由器发送所述一个或多个虚拟池容量。
14.如权利要求10所述的程序产品，其特征在于，所述配置管理器通过指定(1)所述一个或多个业务类和所述一个或多个数据处理队列之间的映射；以及(2)每个所述一个或多个数据处理队列的调度权重来对所述上游路由器的所述一个或多个数据处理队列进行配置。
15.如权利要求10所述的程序产品，其特征在于，所述配置管理器响应所述虚拟池容量大于所述上游路由器处当前预留的带宽的判定，向所述下游路由器发送虚拟池容量。
16.如权利要求10所述的程序产品，其特征在于，所述配置管理器对未能在所述下游路由器上设置所述一个或多个虚拟池容量或者未能对所述上游路由器上的所述一个或多个数据处理队列进行配置作出响应而输出告警消息。
17.如权利要求10所述的程序产品，其特征在于，所述配置管理器响应收到的已对所述上游路由器作了重新配置的指示，自动向所述下游路由器发送一个或多个新的虚拟池容量，以使所述一个或多个虚拟池容量与所述一个或多个数据处理队列的新配置重新同步。
18.一种用于管理包括上游路由器和下游路由器的数据网络的方法，所述上游路由器包括一个或多个数据处理队列，所述方法包括策略服务器对所述上游路由器上的所述一个或多个数据处理队列进行配置以向多个数据流业务类中的一个或多个数据流业务流提供选定的带宽；以及策略服务器向所述下游路由器发送一个或多个虚拟池容量，每个所述虚拟池容量对应于所述上游路由器处用于所述多个业务类中一个或多个相关业务类的带宽。
19.如权利要求18所述的方法，其特征在于，所述策略服务器在对所述上游服务器中的所述数据处理队列进行配置之前向所述下游服务器发送所述虚拟池容量。
20.如权利要求19所述的方法，其特征在于，所述策略服务器仅响应于发送给所述下游路由器的所述一个或多个虚拟池容量已被成功设置的确认，而对所述上游路由器上的所述数据处理队列进行配置。
21.如权利要求18所述的方法，其特征在于，所述策略服务器响应收到的业务初始化消息，而对所述上游路由器上的所述数据处理队列进行配置并向所述下游路由器发送所述一个或多个虚拟池容量。
22.如权利要求18所述的方法，其特征在于，对所述上游路由器的所述一个或多个数据处理队列进行配置包括指定(1)所述一个或多个业务类和所述一个或多个数据处理队列之间的映射；以及(2)每个所述一个或多个数据处理队列的调度权重。
23.如权利要求18所述的方法，其特征在于，所述发送包括所述策略服务器响应所述虚拟池容量大于所述上游路由器处当前预留的带宽的判定，向所述下游路由器发送虚拟池容量。
24.如权利要求18所述的方法，其特征在于还包括所述配置管理器对未能在所述下游路由器上设置所述一个或多个虚拟池容量或者未能对所述上游路由器上的所述一个或多个数据处理队列进行配置作出响应而输出告警消息。
25.如权利要求18所述的方法，其特征在于包括响应收到的已对所述上游路由器作了重新配置的指示，所述策略服务器自动向所述下游路由器发送一个或多个新的虚拟池容量，以使所述一个或多个虚拟池容量与所述一个或多个数据处理队列的新配置重新同步。
26.一种路由器，包括具有可连接到上行链路的输入端口和可连接到下行链路的输出端口的数据面；以及控制面，所述控制面包括具有对应于连接到所述上行链路的上游路由器的资源容量的容量的虚拟池；策略控制接口，策略服务器通过所述策略控制接口设置所述虚拟池容量；以及接纳控制功能，所述接纳控制功能响应为从所述输入端口经由所述数据面到所述输出端口的流预留资源的请求，通过参照所述虚拟池内的资源可用性为所述上行链路执行接纳控制。
27.如权利要求26所述的路由器，其特征在于，所述控制面响应所述虚拟池容量的成功设置而向所述策略服务器发送确认。
28.如权利要求26所述的路由器，其特征在于，所述控制面向所述策略服务器发送通知以指示由所述接纳控制功能接纳的一个或多个流的预留带宽小于所述虚拟池的新的尚未设置的容量。
29.一种路由器，包括具有可连接到上行链路的输入端口和可连接到下行链路的输出端口的数据面，所述数据面包括多个数据处理队列；以及控制面，所述控制面又包括策略控制接口，通过所述策略控制接口，策略服务器对所述数据处理队列中被分配用于处理多种类型的集成服务流中的每种集成服务流类型的相应队列进行配置。
30.如权利要求29所述的路由器，其特征在于，所述控制面响应所述虚拟池容量的成功设置而向所述策略服务器发送确认。
31.如权利要求29所述的路由器，其特征在于，所述控制面向所述策略服务器发送通知以指示所述多个数据处理队列的配置已被修改。32.如权利要求29所述的路由器，其特征在于，配置所述多个数据处理队列，以便将至少两种类型的集成服务流分配给所述多个数据处理队列中的不同队列。
33.如权利要求29所述的路由器，其特征在于，所述数据面还包括对所述多个数据处理队列的分组发送进行调度的调度器，其中，所述策略控制接口还通过向所述调度器提供针对所述多个数据处理队列中各队列的调度权重来配置所述路由器。
全文摘要
数据网包括具有一个或多个数据处理队列的上游路由器、下游路由器和策略服务器。在一个实施例中，策略服务器包括处理资源、与处理资源通信的通信接口以及存储可由处理资源执行的配置管理器的数据存储器。配置管理器对上游路由器的数据处理队列进行配置，以向多个数据流业务类中的一个或多个数据流业务类提供选定的带宽。此外，配置管理器向下游路由器发送一个或多个虚拟池容量，每个虚拟池容量对应于上游路由器处用于多个业务类中一个或多个相关业务类的带宽。在一个实施例中，配置管理器仅响应于对发送给下游路由器的一个或多个虚拟池容量已被成功设置的确认，而对上游路由器上的数据处理队列进行配置。
文档编号G06F15/173GK1511279SQ02810302
公开日2004年7月7日 申请日期2002年3月20日 优先权日2001年3月20日
发明者D·E·麦克戴桑, D E 麦克戴桑, D·J·劳林斯, 劳林斯, L·姚 申请人:全球通讯公司