CN101433031A - 在传输网络中协调接纳控制的方法和*** - Google Patents

Abstract

本发明提供了在传输网络域的接纳控制接口处提供媒介的协调实体的协调层，和代表应用层信号通知QoS请求的任意QoS信号机。协调层用来通过利用协调请求消息来跨多个传输网络域分发接纳控制请求，该协调请求消息包含通过协调实体的协调层转发的接纳控制请求。在各协调实体处，接纳控制请求被传递到该协调实体服务的传输网络的接纳控制接口上，并获得接纳控制响应。接着，该接纳控制响应与通过协调层经由协调消息传播的来自其他域的接纳控制响应合并。由此，协调层将各种接纳控制响应合并成合并响应，该合并响应可以被提供回QoS信号机(或者其他请求实体)。因此，在QoS信号机不必与各单独域联系的情况下，实现了对跨多个传输网络域的接纳控制进行协调。

Description

在传输网络中协调接纳控制的方法和***

技术领域

本发明涉及用于在传输网络中协调用于接纳控制请求和响应的请求和/或响应消息的方法和***。具体地说，在本发明的实施方式中，可以与所使用的服务质量定义的形式无关地整理和/或协调服务质量消息。

背景技术

在诸如互联网协议(IP：internet protocol)网络的网络中，从源应用到目的地应用的一连串分组被称为流。传输网络应该如何处理形成流的分组很大程度取决于应用的需要，应用的需要进而限定了各个流的需要。通常可以定义四个参数来指定流对于传输网络所要求的性能指标，这四个参数为所要求的带宽(数据速率)、延迟(网络将分组从源传送到目的地要花费多长时间)、抖动(分组到达时间对于分组发送时间的变化，例如标准偏差)以及可靠性(表征流可以容许分组丢失的程度)。这些参数一起定义了流要求的服务质量(QoS：Quality of Service)。任何特定流根据上面提到的四个参数的特性要求的特定服务质量取决于从其发送或接收流的应用。例如，电子邮件应用可能要求高可靠性，但对带宽、延迟或抖动具有较低期望，而视频会议应用对延迟、抖动以及带宽具有高得多的期望，但可以容许一定程度的分组丢失。

在过去，互联网工程任务组(IETF：Internet Engineering Task Force)的成员已经承担了很多工作以制定在传输网络(具体地说，IP网络)中提供服务质量的机制。该工作的一个分支产生了多种基于流的QoS机制(被称为“综合业务”)。在多个IETF RFC(具体地说，在RFC 2205到2210)中对这些机制进行了描述。在综合业务的支持下考虑两种具体类型的基于流的QoS，即，在IETF提案标准RFC 2212中描述的“保证传递”服务和在IETF RFC 2211中描述的“受控加载传递”服务。在图12中给出的表中示出了保证传递服务和受控加载传递服务的特性。具体地说，保证传递提供固定带宽，以及延迟的固定上限。还提供非常低的抖动，并且该服务被确保不存在分组丢失。因此，保证传递服务代表来自传输网络的高质量服务。

对于受控加载传递，未给出速率保证，但是对于分组延迟、抖动以及分组丢失设置了限制，即规定了低延迟、低抖动以及几乎没有丢失。用于提供综合业务体系结构的主IETF协议是RFC 2205、RFC 2210等中描述的资源预留协议(RSVP：resource reservation protocol)。

如RFC 2210中所描述的，作为数据发送方加入RSVP会话的应用实例向RSVP登记。该应用实例提供的一条信息是描述该应用期望生成的业务的发送方TSpec。该信息被用来构建RSVP SENDER_TSPEC对象，该对象被包括在针对该应用生成的RSVP PATH消息中。

发送应用还构建初始RSVP ADSPEC对象。该adspec携带关于QoS控制能力和发送应用本身的要求的信息，并形成用于积累下面描述的路径属性的开始点。ADSPEC被添加到在该发送方处创建的RSVP PATH消息中。

典型地，在这种情况中由主机RSVP提供的默认ADSPEC将支持该主机已知的所有QoS控制服务，但是该机制的具体行为是随实现而定的。

随着RSVP PATH消息从发送方移动到接收方，由随后的网元修改ADSPEC。在各网元处，将ADSPEC从RSVP传递至业务控制模块。业务控制模块通过识别ADSPEC中提及的服务并分别调用这些服务以更新它的ADSPEC部分来更新ADSPEC，所述ADSPEC可以包含用于几种QoS控制服务的数据。如果业务控制模块发现在ADSPEC中被提及但是未通过网元实现的QoS控制服务，则设置标记以向接收方报告该情况。接着，更新后的ADSPEC被返回到RSVP以沿该路径传递到下一跳。

PATH消息一到达应用接收方处，就将SENDER_TSPEC中的数据和ADSPEC对象跨RSVP API传递给该应用。该应用(可能在公共资源预留函数库的帮助下)解释到达的数据，并使用该数据来指导资源预留参数的选择。

希望预留资源的应用接收方向它的本地RSVP提供必要的预留参数。这些参数包括期望的QoS控制服务(保证或受控加载控制服务)、描述应该对其预留资源的业务的级别的业务分类符(TSpec)，并且如果选择的QoS控制服务需要的话，还包括描述期望的服务的级别的RSpec。这些参数构成了RSVP FLOWSPEC对象并被RSVP传输到上游。

在网络中的各RSVP察觉点(aware point)处，到达PATH消息的SNEDER_TSPEC和到达RESV消息的FLOWSPEC被用来向期望的QoS控制服务请求合适的资源预留。根据RSVP协议的规则进行状态合并、消息转发以及差错处理。

最后，到达各RSVP会话的数据发送方的合并后的FLOWSPEC对象被传递到应用，以向各发送方通告合并后的预留请求和数据路径的属性。

除了基于流的算法(例如，综合业务)之外，IETF还设计了基于类的服务质量体系结构(被称为“区分服务”(DiffServ))。对于基于类的服务，流(例如互联网电话流)的整个类具有相同的服务质量，由此意味着服务质量机制不需要处理单独流。在此方面，DiffServ体系结构被认为比综合业务体系结构更简单明了。

DiffServ环境中的服务类的选择取决于各网络运营商，但是IETF已经定义了与网络无关的服务类。一种具体服务类是在RFC3246中描述的“加速转发(Expedited Forwarding)”。加速转发(被称为“EF”)提供固定速率、较低的或者无延迟、抖动或分组丢失。

DiffServ体系结构下的其他服务类是在RFC 2597中描述的“确保转发”并被称为“AF”。在确保转发中，规定四种优先类，每个类具有其自身的资源。然后，分组的四种类例如利用漏桶算法或者令牌桶算法来进行流量整形(traffic shaping)以保持服务质量。通过确保转发给出的速率取决于相同类中的其他流，并且未针对延迟或抖动给出保证。然而，只要业务在它的指定包络(envelope)内，则不会发生分组丢失。

尽管综合业务和区分服务具有牢固的理论基础，但是在原理上因为它们要求发送应用知道传输网络所使用的具体服务质量体系结构，所以在实践中已经证明它们很难得到应用。然而，如从以上描述可知的，之前已经提出至少两种不同的服务质量体系结构，在所述服务质量体系结构中，可以采用其他不同的机制来提供QoS。由于不同技术的不断发展，由于需要建立与所有不同QoS体系结构的兼容性，因此通常还未将QoS请求方机制构建到应用中。然而，任何具体应用根据其是可以接受弹***、具有分组丢失的实时服务还是不存在分组丢失的实时服务而具有对其QoS要求的一般思想。另外，应用还倾向于具有它的带宽和分组大小特性的思想。因此，允许应用以不同形式指定QoS将更有益，然后所述QoS可以被翻译成传输网络技术指定的QoS，来用于资源预留。

此外，对于不同类型的QoS，目前尚不存在允许在大型多域网络上协调接纳控制决定的集成技术，在所述大型多域网络中，单独域可以采用不同QoS体系结构。上述的RSVP提供综合业务体系结构中的QoS的协调，其中在所述综合业务体系结构中，各节点均为支持RSVP的节点，但是被固有地限制为采用支持RSVP的节点进行操作。因此，如果流必须经过的各节点均为RSVP节点，则RSVP在这些节点处有效地协调各种QoS接纳控制决定。然而，在涉及使用不同QoS体系结构(例如DiffServ体系结构)的多个域，或者根本不进行任何QoS预留或保证的情况中，RSVP不能提供协调。

Wen-Tsuen Chen、Chin-Fu Lin和Chung-Shih Tang(2001年6月11-14日在Finland的Helsinki举办的ICC 2001，IEEE International Conferenceon Communications的会议记要的1792-1796页)发表了论文“ABandwidth Reservation Protocol for Hard QoS Guaranteed DifferentiatedServices(一种在区分服务中提供严格QoS保证的带宽预留协议)”，该论文旨在提供一种在DiffServ中跨域的具有端对端行为的严格QoS保证服务，并且似乎部分描述了协调EF网络的方法。该方法根据关注的服务是EF还是AF来使用不同的消息，所以该协议取决于QoS的类型。

参照现有专利文献，EP1589696涉及用于在网络通信中实现资源分配的***和方法，并旨在通过将通信网络划分成多个QOS域并对这些域进行管理来解决端对端QOS问题。WO02056564涉及在移动电信***中提供端对端QoS的方法和***，所述移动电信***包括利用基于IP的传输连接到至少一个无线接入网的至少一个网络装置(例如，核心网络)。

因此，需要进一步的信令协议和相关技术来协调跨多个域的相关OoS的接纳控制，各个域可以具有不同的QoS体系结构。

发明内容

考虑到上面的问题，本发明提供了在传输网络域的接纳控制接口处提供媒介的协调实体的协调层，以及代表应用层信号通知QoS请求的任意QoS信号机。协调层用来通过利用协调请求消息来跨多个传输网络域分发接纳控制请求，该协调请求消息包含通过协调实体的协调层转发的接纳控制请求。在各协调实体处，接纳控制请求被传递到该协调实体服务的传输网络的接纳控制接口上，并获得接纳控制响应。接着，该接纳控制响应与通过协调层经由协调消息传播的来自其他域的接纳控制响应合并。由此，协调层将各种接纳控制响应合并成合并响应，该合并响应可以被提供回QoS信号机(或者其他请求实体)。因此，在QoS信号机不必与各单独域联系的情况下，实现了对跨多个传输网络域的接纳控制进行协调。

考虑到上述内容，根据本发明的第一方面，提供了一种跨多个传输网络域协调接纳控制信号的方法，该方法包括：为传输网络域提供至少一个协调器实体，该至少一个协调器实体被设置为与该协调器实体被提供给的传输网络域的接纳控制接***换接纳控制请求和响应消息；以及在多个传输网络域的协调器实体之间交换协调请求和响应消息，以合并各个域的接纳控制响应。

如上面所提到的，本发明的第一方面提供这样的优点，即可以通过将接纳控制响应合并到单个、合并响应来实现跨多个域的协调。此外，依靠位于分离的协调层中的传输网络域上方的协调器实体，可以使用这些协调器实体来协调接纳控制，而无需考虑单独传输网络所采用的QoS体系结构。在此方面，优选的是，接纳控制请求和响应包括QoS描述，但是该描述几乎可以为任意形式。此外，在协调层中交换的协调消息与所使用的QoS描述的形式无关。

在本发明的一个实施方式中，协调器实体在阻塞模式下工作，其中针对接收到的包含接纳控制请求的协调请求消息，从该协调器实体工作的网络域获得接纳控制响应，在将该协调请求消息转发到下一跳传输网络域的下一协调器实体之前，将该响应与所述接纳控制请求合并。因此，这种操作允许在后面域之前针对流路径中前面的域做出接纳控制决定，并且将决定的结果合并到继续转发的接纳控制请求中。以这种方式，可以以接纳控制请求的形式沿流路径传播来自较早域的接纳控制响应。接着，最后跳域可以在知道流路径中较早域进行的网络预留的情况下回应QoS信号机，以使得该响应表示沿路径的所有域做出的接纳控制响应。

在另一实施方式中，协调器实体在非阻塞模式下工作，其中在从协调器实体工作的网络域获得接纳控制响应之前，向下一跳传输网络域的下一协调器实体转发接收到的包含接纳控制请求的协调请求消息。这种操作使得能够尽可能快地向所有域传播接纳控制请求。

在其他实施方式中，针对接收到的包含接纳控制请求的协调请求消息，从该协调器实体工作的网络域获得接纳控制响应，该响应与在来自用于下一跳传输网络域的下一协调器实体的协调响应消息中接收到的接纳控制响应合并。因此，这里改为在与阻塞模式相反的方向上合并接纳控制响应，即，各域做出其自身的接纳控制响应，并接着该域的协调器等待从所述下一条协调器接收该下一条协调器的接纳控制响应。接着，合并各自的响应，并向上传播回流路径。

在本发明的实施方式中，优选的是，合并步骤还包括：将接纳控制响应与以下中的一项进行比较：i)在阻塞模式中，接纳控制请求信息；或者ii)在非阻塞模式中，在协调响应消息中接收到的接纳控制响应信息；确定所比较的信息中表示这两个比较信息的最小值的信息；以及产生包含与所确定的最小值信息相对应的接纳控制请求或响应信息的所述进一步协调消息。因此，当域仅能授权比请求QoS更低的QoS时，可用将更低的QoS级别并入整体响应。

在本发明的优选实施方式中，提供协调器实体的层级结构，该层级结构包括每一个均针对单个传输网络域工作的最低层的协调器实体和一个或更多个较高层的协调器，较高层的协调器用来与紧邻较低层中的协调器交换消息，由此聚集来自多个传输网络域的接纳控制响应。协调器的层级结构的使用使得能够向每个作为传输网络域的集合的管理域指派协调器，接着在任何具体管理域中以传输网络级别执行协调，并接着以管理域级别执行协调。这种布置更准确地反映了实际网络的布置。

在本发明的实施方式中，优选的是，接纳控制请求消息包含具有所请求的QoS的流QoS描述的信息。此外，优选的是，接纳控制响应消息还包含具有被授权的QoS的流QoS描述的信息。优选的是，流QoS描述包括指示所请求的QoS类型或被授权的QoS类型的第一部分和包含一个或更多个所请求的QoS参数的第二部分。这种特征使得能够向接纳控制消息中并入QoS请求和响应。

优选的是，所请求的QoS类型包括端对端类型(可以由发送和接收应用而不是具体传输网络理解的QoS类型)的服务。在本发明的优选实施方式中，端对端QoS类型选自包含以下类型的组中：弹性、实时容错、以及实时非容错。根据这种布置，端对端QoS定义可以被映射到传输网络专用的QoS，因此在应用设计和生产中提供进一步的灵活性。

根据另一方面，本发明提供了一种由用于一个或更多个传输网络域的本地子集的协调器实体执行跨多个传输网络域来协调接纳控制消息的方法，该方法包括以下步骤：i)接收包含接纳控制请求信息的至少一个协调请求消息；ii)向一个或更多个所述传输网络域的子集的接纳控制接口或功能转发包含所述接纳控制请求信息的接纳控制请求消息；iii)接收含有本地接纳控制响应信息的接纳控制响应消息，该本地接纳控制响应信息是根据传输网络域的所述本地子集或各个本地子集响应于接纳控制请求信息做出的接纳控制响应而得到的；iv)至少根据接纳控制响应信息来生成进一步协调消息；以及v)传输该进一步协调消息。

在此进一步方面中，可以获得先前关于第一方面描述的进一步特征和优点。

根据本发明的另一方面，还提供了一种被这样设置的计算机程序或计算机程序套件，即当计算机***执行该计算机程序或套件时，计算机程序或套件促使该计算机***根据前述方面中的任意一种方法工作。此外，根据本发明，还提供一种存储根据上面提到的方面的计算机程序或至少一个计算机程序套件的计算机可读存储介质。所述计算机可读存储介质可以是本领域已知的任意磁学、光学、磁光学、固态或其他数据存储介质。

从所附权利要求书将清楚本发明的进一步方面和特征。

附图说明

根据仅作为实施例阐述的本发明实施方式的以下说明，并通过参考附图，将清楚本发明的进一步特征和优点，在附图中，相同标号指相同部件，并且其中：

图1是现有技术的接纳控制信令中包含的元件的图；

图2是使用根据本发明的一个实施方式的协调层的接纳控制信令的图；

图3是例示在本发明的一个实施方式中协调层可以如何从端对端延伸的图；

图4是例示在本发明的一个实施方式中使用的协调器实体的接口的框图；

图5是详述在本发明的一个实施方式中的传输网络域的接纳控制接口处执行的步骤的流程图；

图6是在本发明的一个实施方式中的传输网络域中的接纳控制接口处执行的部分接纳控制检查的流程图；

图7是在本发明的一个实施方式中将具体流与专用传输网络服务匹配的匹配功能的流程图；

图8是在本发明的一个实施方式中允许将端对端QoS请求翻译成指定传输网络QoS的表；

图9是例示在本发明的一个实施方式中使用的接纳控制请求消息的格式的图；

图10是例示在本发明的一个实施方式中使用的接纳控制请求消息的格式的图；

图11是例示在本发明的一个实施方式的阻塞模式下的协调器实体的操作的状态图；

图12是例示在本发明的一个实施方式中在处理状态下由协调器实体执行的步骤的流程图；

图13是例示本发明的一个实施方式中的消息交换的图；

图14是例示在本发明的一个实施方式的非阻塞模式下的协调器实体的操作的状态图；

图15是例示在本发明的一个实施方式中在非阻塞模式的处理状态下的协调器实体的操作的流程图；

图16是例示本发明的一个实施方式的消息交换的图；

图17是例示本发明的一个实施方式的消息交换的图；

图18是例示在本发明的一个实施方式中在协调器实体处执行的步骤的流程图；

图19是例示在本发明的一个实施方式中的协调消息的格式的图；

图20是例示在本发明的一个实施方式中的协调器实体的层级结构排列的框图；

图21是例示应用于本发明的一个实施方式的协调器实体和管理域与传输网络域的层级结构排列的另一图；

图22是例示在操作的阻塞模式下跨图21的层级结构排列的消息交换的图；

图23是类似于图21的管理域与传输网络域的层级结构排列；

图24是描绘在本发明的一个层级结构实施方式中处于非阻塞操作模式下的消息交换的图；以及

图25是例示网关路由器的框图，该网关路由器配备有使该网关路由器能够提供本发明的各实施方式的软件。

具体实施方式

在描述本发明的实施方式之前，图1例示了用于信令通知接纳控制请求的现有技术体系结构。这里，通常数据源(例如，应用等)10向QoS信号机(signaller)30提供接纳控制请求，QoS信号机30可以被并入该应用中，或者可以是安装在同一机器或某个不同机器(例如，通过LAN连接到数据源10的主机上的一种机器)上的独立实体。QoS信号机30向数据传输网络20的接纳控制接口40发送接纳控制请求，其中来自QoS信号机30的请求必须包含必需的信息并且具有正确的格式，从而与数据传输网络20专用的QoS机制兼容。因而，例如在数据传输网络20使用利用RSVP的综合业务体系结构的情况下，QoS信号机30必须利用RSVP向网络接纳控制实体40发送接纳控制请求。

为了解决上面提到的现有技术的缺点，本发明的实施方式提供了协调器实体的“协调层”，对每个域提供至少一个协调器实体。如将从要描述的实施方式中清楚的，对各传输网络域提供协调器实体，并且协调器实体可以层级结构排列，以将传输网络域的管理集合(administrativecollection)反映给管理域。提供协调层使得QoS信号机能够进行单个接纳控制请求，接着通过协调器实体的动作经由协调层来分布该单个接纳控制请求，聚集来自传输网络域接纳控制接口的接纳控制响应并将这些接纳控制响应合并成单个协调接纳控制响应。此外，本发明的实施方式的协调层并不依赖于任何具体QoS体系结构，并因此可以被用来协调和合并不同QoS体系结构的传输网络域中的接纳控制请求。在此方面，协调层消息格式包含其中可以携带QoS描述但是并不考虑QoS描述的精确格式的字段。因此，与例如RSVP的情况不同的是，本发明的实施方式提供了附加、独立的协调层，该协调层位于传输网络域接纳控制接口的顶部，并且不依赖其任何具体的QoS体系结构。

图2和图3例示了关于本发明的第一实施方式的数据传输网络域的协调器实体的构造。更具体地说，图2例示了QoS信号机30如何与协调器50交换协调请求和响应消息，QoS信号机30可以是发送应用的一部分，或者可以是为应用提供服务的独立实体。协调器50位于数据传输网络域20的接纳控制接口40的顶部，并且通过交换接纳控制请求和响应消息来与接纳控制接口40通信。第一跳传输网络域20的协调器50还与第二跳协调器50交换协调请求和响应消息，该第二跳协调器位于第二跳数据传输网络域20的接纳控制接口40的顶部。因此，图2例示了本发明第一实施方式的主要特征，即，在第一实施方式中，对各传输网络域20设置协调器实体50，并且协调器实体50位于其接纳控制接口的顶部。因此，QoS信号机30仅需要在向第一跳协调器实体50发送的接纳控制请求和从第一跳协调器实体50接收接纳控制响应期间与第一跳协调器实体50通信。如将在稍后详细描述的，协调器实体50用来将接纳控制请求传递到各个数据传输网络域20的接纳控制接口40，并接收包含响应于在各传输网络内的请求而做出的网络预留的接纳控制响应信息，并且将这些响应协调成单个响应。

图3对图2进行扩展以提供经由多个传输网络域20从数据源10至数据目的地12的数据流的端对端图。各传输网络域20均具有各自的接纳控制接口40和各自的协调器实体50。如图3所示，数据源10向QoS信号机30发出服务请求，接着QoS信号机30将该服务请求封装为协调请求消息中的接纳控制请求信息，并将该协调请求消息发送到第一跳协调器50。第一跳协调器50经由协调请求消息向各数据传输网络的其他协调器50传播该接纳控制请求信息，并且还通过在接纳控制请求消息中向数据传输网络的接纳控制接口转发接纳控制请求信息来为其自身的数据传输网络激励接纳控制过程。在各传输网络域20处检验(examine)接纳控制请求信息，并且执行接纳控制检查以确定是否可以为该请求提供服务，并响应于该请求适当地进行网络预留。在这方面，如果可以提供服务，则接纳控制请求信息典型地包含该发送应用所期望的、网络要满足的QoS参数的QoS描述。如果不可以提供服务，则或者授权较低的QoS级别，或者完全不进行QoS预留。无论接纳控制检查的结果如何，该结果都会以包含接纳控制响应信息的接纳控制响应消息的形式传送回协调器50。在各自协调器和各数据传输网络的接纳控制接口之间执行这些步骤，并且接着可以通过适当地交换协调请求消息和协调响应消息来在协调层合并接纳控制响应。更具体地说，存在两种用于合并接纳控制响应的操作模式，这里我们称之为“阻塞模式”和“非阻塞模式”。接下来简要描述这两种模式，并在后面进行详细说明。

具体地说，在“阻塞模式”中，协调器50接收协调请求消息中的接纳控制请求，并接着在转发该接纳控制请求之前确定它服务的传输网络域是否可以授权接纳控制请求。因此，参照图3，当第一跳协调器50从QoS信号机30接收到包含接纳控制请求的协调请求消息时，在将该协调请求消息转发到第二跳协调器之前，它将该接纳控制请求信息封装在接纳控制请求消息中，并将该接纳控制请求消息发送给数据传输网络20的接纳控制接口40。因为接纳控制请求信息通常包括具有各种QoS参数的QoS描述，所以数据传输网络20的接纳控制接口40可以确定是否可以为该QoS请求提供服务，并且如果可以提供服务，则进行必要的网络预留。如果无法为该请求提供服务，则可以传递回降低的QoS级别或者差错消息。无论是何种响应，接纳控制接口40都会整理(formulate)具有被授权的QoS(或者不具有被授权的QoS)的接纳控制响应消息，将该接纳控制响应消息从接纳控制接口40发送到协调器50。协调器50接收具有被授权的QoS的接纳控制响应消息，并且，假设未接收到差错消息(在接收到差错消息的情况下，第一跳域根本不会授权接纳控制请求)，则第一跳协调器50将包含被授权的QoS参数的接纳控制响应信息与原始接纳控制请求信息合并成新的接纳控制请求信息，接着在第二协调请求消息中将新的接纳控制请求信息转发到第二跳协调器。

在第二跳协调器处，执行同样的动作，并且在每一跳协调器处执行相同动作，从而沿流路径逐跳传输沿该路径通过接纳控制器响应适当修改的接纳控制请求信息。在最后跳协调器处，将包含沿整个路径聚集并合并的响应的协调响应消息发送回QoS信号机30。

相反，在“非阻塞模式”中，只要协调器实体接收到包含接纳控制请求信息的协调请求消息，它就立即将该请求转发到下一跳协调器。接着，将接纳控制请求信息传递给该协调器服务的具体数据传输网络20的接纳控制接口40，并获得接纳控制响应。然后，各协调器等待，直到它从下游协调器接收到协调响应消息。即，除最后跳协调器外，其他协调器均会在它从其本地接纳控制接口接收到接纳控制响应时整理协调响应消息以将其本地接纳控制响应继续传递给上游的前一跳。接着，上游的前一跳将其本地接纳控制响应与接收到的接纳控制响应合并成新的接纳控制响应，接着将该新的接纳控制响应传递回上游。以这种方式，从协调器向上游的协调器传输并合并接纳控制响应，直到第一跳协调器能够向QoS信号机提供包含接纳控制响应信息的单个协调响应消息，该单个协调响应消息代表来自各数据传输网络的接纳控制响应。

稍后将给出关于阻塞和非阻塞模式中协调器的操作的进一步信息以及其他实施例。

图4是例示任意具体协调器50所要求的接口的图。具体地说，任意具体协调器实体50必须具有与协调层内与其自身处于相同级别的协调器实体(例如，如图4所示的QoS信号机30和另一协调器50)交换协调请求消息和响应消息的接口。此外，协调器实体必须具有额外消息接口，以使得能够在该协调层下方与传输网络的至少一个接纳控制接口40交换接纳控制请求消息和响应消息。另外，在后面要描述的本发明的其他实施方式中，使用同一接纳控制接口来与层级结构协调层中更低和更高级别的协调器交换接纳控制请求消息和响应消息。

现在将针对图11到图13以及图18和图19对第一实施方式的“阻塞模式”变型的操作的更详细描述进行说明。

如上面所提到的，在阻塞模式中，在协调器实体向下一跳协调器转发接纳控制请求之前，协调器实体运行的具体传输网络域为该接纳控制请求提供服务。图11例示了在“阻塞模式”下运行的协调器实体的操作的状态图。

在加电并启动之后，在阻塞模式下运行的协调器实体50进入等待接收协调请求消息co-ord(req)的空闲状态110。可以从任何QoS信号机30(在该协调器是具体流的第一跳协调器的情况)或者从该协调层中的另一协调器实体50接收协调请求消息co-ord(req)。典型地，对于任意具体数据流，将从前一跳协调器接收协调请求消息co-ord(req)。当接收到co-ord(req)消息时，退出空闲状态110，并且协调器实体50将接纳控制请求消息ac_req发送到该协调器实体针对其运行的接纳控制接口40。已经发送接纳控制请求消息的协调器50接着进入等待状态112，以等待来自接纳控制接口40的接纳控制响应消息。

图19例示了协调消息的格式，取决于消息类型字段的标记变量的值，该协调消息可以是协调请求消息或者是协调响应消息。具体地说，协调消息1900包括第一字段1902，该第一字段具有QoS信号机正在针对其请求接纳控制的IP流的流ID。第二字段是消息类型字段1904，该消息类型字段包含指示协调消息是请求消息、响应消息、还是差错消息的标记。消息类型字段后面是整体QoS描述字段1906，整体QoS描述字段1906包含针对具有该流ID的流所要求的具体QoS参数的值的QoS描述。应该注意到，本发明的实施方式并未指定任何具体QoS描述格式，因此任何类型的QoS描述都可以包括在整体QoS描述字段1906中。图19例示了在稍后要描述的本发明的其他实施方式中用到的、可以包括在整体QoS描述字段1906中的QoS描述的类型的实施例。然而，对于本实施方式来说，应该注意的是，整体QoS描述字段1906要求：该字段足够大以能够携带任意期望形式的QoS描述，并且数据传输网络20的接纳控制接口40能够理解这些QoS描述。

整体QoS描述字段之后的第四字段是“整体响应”字段1908，“整体响应”字段1908包含可以取成功、失败或降低(degrade)值的变量。特别是当消息类型为响应消息类型时，采用该字段来指示接纳控制请求是否已经成功、失败，或者是否已经部分成功(即，已经降低任意特定流的被授权的QoS)。

当协调器实体处于状态110(空闲)时，其可以接收在消息类型字段1904中具有“请求”标记并且在整体QoS描述字段1906中包含QoS描述的协调请求消息。接着，协调器取得整体QoS描述字段1906的内容，并将它们封装在图9所示形式的接纳控制请求消息中。这里，整体QoS描述字段1906的内容具有附接在其前部的流ID字段902，并接着被发送给传输网络的接纳控制接口40。

返回图11，在发送了接纳控制请求消息后，如上面所提到的协调器50接着等待接纳控制响应消息。接纳控制响应消息340具有图10中示出的格式，并且包括正在进行响应的流ID的第一字段1002，以及包含取“成功”、“失败”或“降低”值的变量的响应字段1004。附加字段是被授权的QoS描述字段1006，被授权的QoS描述字段1006包含已经针对流进行传输网络预留的QoS描述。优选的是，该QoS描述与在接纳控制请求消息中传递到接纳控制接口40的QoS描述具有相同的格式。应该注意的是，图9和图10例示了可以与稍后描述的本发明的另一实施方式一起使用的示例QoS描述。然而，在当前描述的实施方式中，不要求具体类型的QoS描述，并且可以使用接纳控制接口可以理解的任何QoS描述。

返回图11，当从协调器50正服务的接纳控制接口40接收到接纳控制响应消息时，该协调器退出等待状态112。接着，协调器进入处理状态114，其中将接纳控制响应信息根据后面描述的一些适当合并逻辑与接纳控制请求信息合并。图12例示了在处理状态114中执行的处理步骤。

首先，在步骤12.2，运行合并逻辑以更新包括在协调响应消息的整体响应字段1908中的“整体响应”变量。另外，在同一步骤中，整体QoS描述也被更新，并被包括在协调响应消息的整体QoS描述字段1906中。稍后将对执行这些步骤的合并逻辑的操作进行说明。

接着，处理前进到步骤12.4，其中针对整体响应变量是否取成功值或降低值进行评估。如果是这种情况，则处理前进到步骤12.6，其中采取进一步评估以确定该协调器是否为最后跳协调器。如果不是最后跳协调器，则处理前进到步骤12.8，其中在步骤12.8处发送协调请求消息1900，该协调请求消息1900包含如步骤12.2处更新的变量整体响应以及在同一步骤中更新的整体QoS描述，并且具有“请求”消息类型。随后，该处理结束。相反，如果在步骤12.6处确定协调器为最后跳协调器，则将协调响应消息直接发送回QoS信号机，该协调响应消息具有“响应”消息类型，并且在字段1906和1908中包含整体QoS描述和整体响应。

与以上情况不同的是，如果在步骤12.4处的评估为整体响应不成功或未降低，则必定是整体响应变量取“失败”值，在这种情况下，处理前进到步骤12.12，其中协调响应消息被发送到前一跳的协调器，并发送到QoS信号机，该协调响应消息在整体响应字段中包含“失败”整体响应变量。此外，如果当前协调器不是最后跳协调器，则将“差错”类型的协调差错消息发送给下一跳协调器。在这种情况中，如果传输网络根本不能授权接纳控制请求，则获得失败消息。

图18例示了在步骤12.2中执行的合并逻辑的操作。

这里，在步骤18.2处，合并逻辑接收变量local_response、overall_response、overall_QoS_DES以及local_QoS_DES。这里，变量local_response是从接纳控制响应消息340的响应字段1004取得的值，并且可以取成功值、失败值或降低值。具体地说，当接纳控制接口能够完全授权请求的QoS时发送“成功”值，当不能进行接纳控制预留时发送“失败”值，而当接纳控制接口40能够至少部分或尽可能接近地授权接纳控制请求时发送“降低”值。

从协调请求消息的整体响应字段1908取出变量“overall response”，并且取成功值、失败值或降低值。这里，同样地，当前一协调器能够完全满足请求的QoS时发送“成功”值。当前一跳域部分满足请求的QoS，或者已经进行了与请求的QoS尽可能接近的预留时，接收“降低”变量。当前一跳域不能进行请求的预留时，接收“失败”变量作为整体响应。

变量overall_QoS_DES是从在协调器处接收到的协调请求消息中的整体QoS描述字段1906中取得的QoS描述。类似地，变量local_QoS_DES是从接纳控制接口40接收回的、位于接纳控制请求消息340的被授权的QoS描述字段1006中的QoS描述。在接收到所有这些变量之后，合并逻辑功能可以进行如下操作。

首先，在步骤18.4处，执行评估来确定overall_response变量是否取失败值。如果是，则没必要执行剩余合并功能，并且处理前进到步骤18.6，其中返回现有整体响应(即失败)以及现有整体QoS描述(由于之前为失败，所以该现有整体QoS描述极可能取空值)。接着，合并逻辑的处理结束。

相反，如果在步骤18.4处整体响应未被确定为失败，则在步骤18.8处进行评估来确定整体响应变量是否取成功值。如果是，则处理前进到步骤18.10，其中进行评估以确定本地响应变量是否为失败。如果是，即尽管前一跳域能够授权请求，但是当前域不能授权接纳控制请求，则在步骤18.12处整体响应变量被设置为失败，并且接着在步骤18.14处整体QoS描述等于空。接着，处理前进到步骤18.6，其中返回更新的整体响应和整体QoS描述。

返回到步骤18.10，如果该评估结果为否，即本地响应不是失败，则处理前进到步骤18.16，在这种情况中，针对本地响应是否为降低进行评估。如果是，则此时的整体响应(即来自之前域的响应)已经成功，但是本地响应为需要对本地域降低被授权的QoS，并因此整体响应也应该被设置为降低。在步骤18.18处执行该过程，并且进一步在步骤18.20处，令整体QoS描述等于本地QoS描述。处理接着前进到步骤18.6，在该步骤返回更新后的整体响应和整体QoS描述值。

相反，在步骤18.16处，如果本地响应是否为降低的评估返回否定，则这必定意味着本地响应为成功，并且可以利用请求的QoS适当地为接纳控制请求提供服务。在这种情况中，因为整体响应已经成功，所以如果本地响应为成功，则整体响应和整体QoS描述变量都不需要改变，并且因此可以在步骤18.6处以它们的现有形式返回。

返回到步骤18.8，如果整体响应是否成功的评估返回否定，则处理前进到步骤18.22。这里，在给出步骤18.4和18.8的先前评估的情况下，则整体响应必定为降低。接着处理前进到步骤18.24，在该步骤执行关于本地响应是否降低或成功的评估。如果属于降低或成功的情况，则处理前进到步骤18.26，其中整体QoS描述被设置为等于现有整体QoS描述或本地QoS描述的最小值。这里，先前域已经降低了最初请求的被授权的QoS，并因此该功能判断本地接纳控制接口是否进一步降低了能够授权该流授权的QoS。例如，本地接纳控制接口能够根据平均速率来匹配整体QoS描述，但是提供比以前已经授权的速率更低的峰值速率。如果属于这种情况，则最小QoS描述将成为本地QoS描述。

在这方面，在如何对整体QoS描述与本地QoS描述进行比较以确定哪个为最小值方面存在着开阔的设计改变空间。例如，可以是非常简单的最小值函数，该最小值函数仅考虑一种QoS参数(例如，平均速率或峰值速率)，并且确定本地QoS描述或整体QoS描述中的哪一个具有该参数的最小值。更复杂的最小值函数可以考虑QoS参数的子集(例如平均速率和峰值速率)，并组合两种QoS描述的参数之间的各自参数差来确定最小值。更加复杂的最小值函数可以在组合这些差时对相对于其他参数来说更重要的各种QoS参数进行加权。例如，可以通过这样的方式来确定最小值，即，利用这种加权技术，可以对于比峰值速率的差更小的平均速率的差进行加权(例如，乘以一因子)以使其比较而言在整体差中更重要。

相反，其他更复杂的最小值函数例如可以采用各个QoS描述之间的欧几里德距离。在后一方面中，例如，可以对各描述的各种QoS参数进行平方后求和，并接着对该和取平方根，然后对每种QoS参数的最终值进行比较以确定最小值。在一种变形中，还可以在平方运算之前或之后，对QoS参数应用加权因子。

因此，本领域技术人员将清楚用于确定两种QoS描述的最小值的几种机制，并且将清楚确定实际上两种QoS描述中的哪一种表示其最小值的各种其他机制，并且这些机制可以被用在各实施方式中并且本发明意欲涵盖这些机制。

不管怎样确定最小值，在步骤18.26处都会将overall_QoS_DES变量设置为等于现有overall_QoS_DES变量和local_QoS_DES变量的最小值，并且接着在步骤18.6处返回更新后的overall response和overall_QoS_DES变量。

返回到步骤18.24，如果本地响应的评估为这样的评估，即本地相应不是降低或成功，则处理前进到步骤18.28，其中本地响应变量必定取失败值。即，尽管先前的跳域已经能够授权降低的接纳控制请求，但是本地域不能授权该请求。在这种情况中，在步骤18.30，整体响应变量被设置为失败，而在步骤18.32处，整体QoS DES变量被设置为空。接着处理前进到步骤18.6，在该步骤返回更新后的整体响应和整体QoS DES变量。接着，在前述的图12中使用返回值。

返回到图11，在状态114处执行处理，并适当地发送协调请求、响应或差错消息以后，协调器返回到空闲状态110。接着，协调器针对不同的流等待接收未来协调请求消息。接着协调器关于初始接收到的协调请求消息的操作结束。

当在阻塞模式工作时，流路径上的各协调器50根据上述描述工作。图13给出了QoS信号机和沿路径的各个协调器之间的消息流的实施例。具体地说，QoS信号机首先向第一跳协调器发送协调请求消息13.2，该协调请求消息13.2包含流ID、协调消息类型(这里为请求)、QoS描述以及响应项(当前取空值)。接着，第一跳协调器执行上面概述的动作，并且如果成功(在这里，如果响应为“成功”或“降低”)，则第一跳协调器向第二跳协调器发送包含流ID、请求消息类型、更新后的QoS描述以及更新后的响应的进一步协调请求消息13.4。接着，第二跳协调器执行上面概述的步骤，并且如果成功，则以第三协调请求消息13.6的形式转发接纳控制请求，该第三协调请求消息13.6包含流ID、请求消息类型标记、进一步更新的QoS描述以及响应。接着在最后跳协调器处接收该第三协调请求消息。随后，最后跳协调器执行上面提到的步骤，但是因为该协调器是最后跳协调器并且不需要进一步转发协调请求消息，所以其改为整理包含流ID、响应消息类型以及更新的QoS描述与响应的协调响应消息13.8，接着将该协调响应消息13.8发送回QoS信号机。因此，QoS信号机发送单个协调请求消息13.2，并从协调层接收回单个协调响应消息13.8，该单个协调响应消息13.8向QoS信号机指示：是否对该信号机的接纳控制请求提供服务，并且指示已授权的QoS参数。

现在将对采用“非阻塞模式”变形的第一实施方式的操作进行进一步说明。图14是例示在非阻塞模式下工作的协调器50的操作的状态图。应该记住的是：在非阻塞模式中，接纳控制请求在本地传输网络的接纳控制接口提供服务之前被转发到下一跳协调器。

参照图14，在加电并启动后，非阻塞模式的协调器进入空闲状态142，其在该状态等待接收协调请求消息。该协调消息与先前针对阻塞模式描述的、如图19中所示的格式完全相同。当在步骤142处接收协调请求消息时，在非阻塞模式下工作的协调器50立即将该协调请求消息转发到下一跳协调器，并将接纳控制请求消息发送给本地接纳控制接口40。在这方面，该接纳控制请求消息也具有与如先前在图9中所示出的阻塞模式中使用格式相同的格式。接着，协调器进入等待状态144，在等待状态144中，该协调器等待来自它的本地传输网络的接纳控制响应消息，以及来自下一跳协调器的协调响应消息。

等待状态144等待接收本地接纳控制响应消息以及来自下一跳协调器的协调响应消息。其原因在于，在非阻塞模式中，协调器必须将本地接纳控制响应与从下一跳协调器接收到的协调响应消息中的整体响应以及整体QoS描述合并。这是因为，如前面所描述的，在“非阻塞模式”中，接纳控制响应的聚集和合并在与阻塞模式相反的方向上发生。当然，如果协调器为最后跳协调器，则因为不存在下一跳协调器，因此不需要在状态144处等待来自下一跳协调器的协调响应消息。在这种情况中，只要接收到本地接纳控制响应消息，就可以退出该等待状态。

当已经接收到必要的消息时，协调器进入图15中更详细示出的处理状态146。

参照图15，在步骤15.2处的处理状态中，运行响应合并逻辑，以更新overall_response变量和overall_QoS_description变量。该响应合并逻辑与先前针对图18描述的阻塞模式中使用的响应合并逻辑相同。然而，这里，overall_response变量和overall_QoS_description变量是在来自下一跳协调器的协调响应消息中接收到的变量。而除了这点差异之外，该合并逻辑与先前描述的一样，并且以与先前针对阻塞模式描述相同的方式返回更新后的overall_response变量和overall_QoS_description变量。

返回到图15，在步骤15.4，在运行响应合并逻辑之后，检查更新后的overall_response变量以确定它该变量是否取成功值或者降低值。如果为是，则处理前进到步骤15.6，其中将协调响应消息发送到前一跳协调器，该协调响应消息与先前描述的图19中示出的消息具有相同格式，并且包含整体响应字段1908和整体QoS描述字段1906中的更新过的overall_response变量和overall_QoS_description变量。接着处理结束。

相反，如果在步骤15.4处确定overall_response变量不是成功或降低，则overall_response变量必然为失败，在这种情况下，处理前进到步骤15.8，其中协调响应消息被发送到前一跳协调器，但是在整体响应字段1908中包含失败值。可以在整体QoS描述字段1906中包含空值。

此外，在步骤15.10，进行确定协调器是否为最后跳协调器的评估，如果不是，则向下一跳协调器发送协调差错消息以向其通告该差错。应该将该协调差错消息沿流方向朝着最后跳协调器的方向向回传播。

在状态146期间发送必要的协调响应或差错消息后，接着在非阻塞模式下工作的协调器返回如图14所示的空闲状态142。接着保持空闲状态142，直到针对另一流接收新的协调请求消息。

图16例示了当未发生差错时非阻塞模式下的消息流的实施例。具体地说，将包含流ID和请求的QoS描述的第一协调请求消息16.2从QoS信号机发送到第一跳协调器。接着，第一跳协调器立即在第二协调请求消息16.4中将该接纳控制请求向前转发到第二跳协调器。同样地，包括流ID、消息类型、所请求的QoS描述以及结果(可以取空值)。同时，第一跳协调器将流ID和QoS描述作为接纳控制请求消息转发到它的本地接纳控制接口，并接着等待接纳控制响应消息以及接收来自下一跳协调器的协调响应消息。在第二跳协调器处，将接收到的协调请求消息作为第三协调请求消息16.6立即转发给最后跳协调器。同样地，包括流ID、消息类型、请求的QoS描述以及结果。第二跳协调器还以接纳控制请求消息的形式将流ID和QoS描述转发到它的本地接纳控制接口，并接着等待本地接纳控制响应消息以及来自最后跳协调器的协调响应消息。在最后跳协调器处接收第三协调请求消息16.6，但未继续转发。然而，将流ID和QoS描述作为接纳控制请求消息传递到其本地接纳控制接口，并且协调器接着等待它的本地接纳控制响应消息。

当最后跳协调器接收到接纳控制响应消息时，它将流ID和被授权的QoS描述封装在协调响应消息中，接着将该协调响应消息作为第一协调响应消息16.8发送到第二跳协调器。当该第二跳协调器接收到该第一协调响应消息时，该第二跳协调器检查以确定其是否已经接收到它的本地接纳控制响应消息，如果没有，则等待直到接收到该消息。一旦接收到协调响应消息和本地接纳控制响应消息二者，则其执行先前在处理状态146中提到的动作，并将第二协调响应消息16.10转发到第一跳协调器。第二协调响应消息包含流ID和更新后的QoS描述以及协调结果。接着在第一跳协调器处接收到该第二协调响应消息，该第一跳协调器检查其是否已经接收到它的本地接纳控制响应消息。如果没有，则等待直到接收到本地接纳控制响应消息。一旦在第一跳协调器处接收到协调响应消息和本地接纳控制响应消息二者，则第一跳协调器执行先前针对状态146描述的合并功能，并接着生成包含流ID和更新后的整体QoS描述以及整体结果的第三协调响应消息16.12。接着，将该第三协调响应消息传递回QoS信号机30。因此，和“阻塞模式”一样，对于“非阻塞模式”，QoS信号机30能够向第一跳协调器发送包含接纳控制请求的单个协调请求消息，并且接着从该第一跳协调器接收回单个协调响应消息，不过该消息包含聚集了跨多个域的所有接纳控制响应的合并响应。而且，在不依赖于任何具体QoS描述的情况下实现这一点，并由此可以应用到不同类型的QoS体系结构中。

为了完整起见，图17例示了发生差错的情况，在该情况中，第二跳域不能授权接纳控制请求或者发生一些其他差错威胁。这里，按照与先前关于图16描述相同的方式，通过协调层传播协调请求消息17.2、17.4以及17.6。在各协调器处，只要接收到协调请求消息，就会将接纳控制消息发送到它的本地接纳控制接口。然而，在图17的实施例中，尽管最后跳协调器能够授权请求并发送了协调响应消息，但是在第二跳协调器处不能对接纳控制请求提供服务，或者发生了一些其他差错。在这种情况下，响应被设置为失败，并且整体QoS描述被设置为空。接着，向第一跳协调器发送包含失败响应和空QoS描述的协调响应消息17.12，并作为消息17.12和17.14被传播回QoS信号机。为了向最后跳协调器通告该差错以使得该协调器可以取消它的预留，以消息17.10的形式将差错类型的协调差错消息沿流向最后跳协调器的流的方向发送回该最后跳协调器。

因此，利用本发明第一实施方式的阻塞或非阻塞变形，提供了这样的协调层，即，该协调层位于多个网络域的接纳控制接口的顶部并用来协调多个域的接纳控制决定，以使得QoS信号机可以发出单个接纳控制请求，并接收单个接纳控制响应。因此，解决了QoS信号机必须与多个接纳控制接口通信的问题，并且可以提供跨多个域的端对端QoS。

上述实施方式设想了协调层包括位于这样的传输网络接纳控制接口的顶部上的协调器50，即，认为所有协调器处于相同级别。这种观点是传输网络执行接纳控制协调方式的核心观点，该观点要求协调器知道到下一跳协调器的寻址和路由信息，即使下一跳协调器属于可能位于不同国家或者由不同公司拥有的传输网络。即，上述的第一实施方式没有按地理位置、所有权等来将传输网络的所有权或组织考虑为“管理域”。例如，实际中，任何具体传输网络归运营商(例如，本申请人)所有。该运营商实际上可以拥有各种类型的传输网络的集合，例如诸如DSL网的本地接入网、或者诸如MPLS网的核心网。此外，任何具体运营商可以具有不同类型的网络，该不同类型的网络根据运营商的网络部署的历史为不同的地理区域提供服务。因此，实际上，任何单个IP流都不得不经过由多个管理实体管理组织的许多不同类型的不同传输网络。

图21和图23中示出上面的实施例，其中为了使IP流从发送应用2101传递到接收应用2102，它必须经过多个传输网络TN1 2114、TN22116和TN3 2124、TN4 2126、TN5 2134以及TN6 2136。然而，这些传输网络以自管理方式排列在管理域中，传输网络TN1和TN2处于BT管理域2110中、传输网络TN3和TN4处于FT管理域2120中，而传输网络TN5和TN6在DT管理域2130中。尽管在任何具体管理域内包括了传输网络的集合，协调器实体还是可以相对简单地获知同一域中其他协调器实体的地址，更多的问题出在一个管理域中的协调器实体了解其他管理域中的协调器实体的地址方面。因此，为了解决此问题，在本发明第二实施方式中，我们引入包括按管理域层级结构排列的协调器实体的协调层概念。这种层级结构排列使得处于相同级别(例如，位于接纳控制接口的顶部上)的协调器实体在同一管理域内能够进行相互协调接纳控制请求和响应，并接着向管理域级别协调器提供接纳控制响应。接着，该管理域级别协调器与其他管理域级别协调器协调它的接纳控制响应，以产生跨所有管理域和更低级别传输网络的单个接纳控制响应。图20示出了这种层级结构排列的实施例。

从图20将看到，和先前在第一实施方式中描述的一样，对于每个接纳控制接口40，在这些接纳控制接口的顶部上设置协调器50。这些协调器实体以和第一实施方式的协调器实体完全相同的方式工作，并且具有相同的接纳控制请求和响应消息接口，以及协调请求和响应消息接口。然而，为了能够跨多个层级进行协调，按附加的接纳请求和响应消息接口的形式对一些协调器设置附加接口，以从管理层级结构上游的下一级别中的协调器接收接纳控制请求和响应消息。图20实际上例示了三个层级，但是使用基本相同的协调器和与先前描述的相同的接口来从QoS信号机30接收具有接纳控制请求的单个协调请求消息，并将具有接纳控制响应的单个协调响应消息提供回该QoS信号机。层级结构排列的一个主要特征是协调请求和响应消息被用来在处于层级结构的同一级别的协调器之间通信，而接纳控制请求和响应消息被用于最低级别的协调器以与传输网络的接纳控制接口通信，并且还用于处于层级结构的不同层的协调器之间的通信。然而，协调请求和响应消息以及接纳控制请求和响应消息的格式与先前关于第一实施方式描述的格式相同，此外，接收这种消息的操作也相同。另外，如将从下面实施例中清楚的，这种层级结构排列也可以在“阻塞模式”或“非阻塞模式”或者“非阻塞模式”下工作。

转到图21和图22，如先前所述，图21例示IP流必须经过的传输网络的集合，并且这些传输网络被排列成三个管理域。各传输网络均具其顶部设有协调器的接纳控制接口(未示出)。因此，例如传输网络TN1配备有协调器2112，而传输网络TN2配备有协调器2118。传输网络TN3配备有协调器2122，而传输网络TN4配备有协调器2128。传输网络TN5配备有协调器2132，而传输网络TN6配备有协调器2138。协调器2112、2118、2122、2128、2132以及2138与传输网络TN1、TN2、TN3、TN4、TN5以及TN6的相应接纳控制接***换接纳控制请求和响应消息。

另外为各管理域设置了附加协调器。因此，BT域2110配备有协调器2111、FT域2120配备有协调器2121，而DT域配备有协调器2131。各个协调器经由接纳控制请求和响应消息与它们管理域中第一跳传输网络级别的协调器通信。因此，例如协调器2111与协调器2112通信、协调器2121与协调器2122通信，而协调器2131与协调器2132通信。此外，管理域级别协调器相互通信，并且经由按先前在前面实施方式中讨论的格式的协调请求和响应消息与发送应用2101和接收应用2102的QoS信号机通信。通过协调器的这种排列并利用接纳控制请求与响应消息以及先前讨论的协调请求与响应消息来获得层级结构的协调层，该层级结构的协调层可以以针对第一实施方式描述的“阻塞模式”或“非阻塞模式”中的任一种模式工作。下面给出了这种层级结构排列在“阻塞模式”和“非阻塞模式”下工作的实施例。

图22例示了在“阻塞模式”下各种协调器之间的消息交换序列。应该注意的是，图22没有例示在传输网络级别协调器和各个接纳控制接口之间的接纳控制请求与响应消息的交换，但是如将从下面清楚的，将发生这些消息的交换。

假设应用的QoS信号机2101要为IP流建立接纳控制预留。第一步骤是QoS信号机向属于第一跳管理域2110的第一跳管理协调器2111发送包含接纳控制请求信息的协调请求消息，该接纳控制请求信息包含QoS描述。第一跳管理协调器2111接收该协调请求消息，并接着将包括QoS描述的接纳控制请求信息作为接纳控制请求消息转发到第一跳传输网络协调器2112。在阻塞模式中，第一跳传输网络协调器2112整理其发送给传输网络TN1的接纳控制接口的其自身的接纳控制请求消息，并接着以先前关于第一实施方式描述的方式从传输网络接口接收接纳控制响应消息。随后，协调器2112对接纳控制响应信息与接纳控制请求信息进行合并，并将该接纳控制请求信息作为协调请求消息3转发到第二跳传输网络协调器2118。接着，第二跳传输网络协调器2118与传输网络TN2的接纳控制接口进行接纳控制请求和响应消息交换、合并接纳控制响应信息并将协调响应消息4发送回协调器2112。接着，协调器2112将包含当前整体响应与整体QoS描述的接纳控制响应信息封装在接纳控制响应消息中，随后它将该接纳控制响应消息作为接纳控制响应消息5转发到第一跳管理协调器2111。通过随后针对管理域BT中传输网络TN1和TN2进行的对于流的传输网络预留，管理域协调器2111将以整体QoS描述和QoS响应的形式的接纳控制请求信息转发到属于管理域FT的第二跳管理域协调器2121。

接着，第二跳管理域协调器2121基本执行与第一跳管理域协调器2111相同的动作。具体地说，其在接纳控制请求消息中向第二管理域的第一跳传输网络协调器2122转发接纳控制请求信息，该第一跳传输网络协调器将该接纳控制请求信息封装在其发送给传输网络TN3的接纳控制接口的自身接纳控制请求消息中。传输网络TN3以包含它的接纳控制响应信息的接纳控制响应消息作为响应，并且协调器2122将该响应信息与请求信息合并，并接着在协调请求消息中向传输网络TN4的协调器2128转发更新后的接纳控制请求信息。接着，协调器2128进行与传输网络TN4的接纳控制接口其自身的接纳控制请求和响应消息交换、合并这些响应，并向协调器2122发送包含更新后的QoS描述和响应的协调响应消息。接着，协调器2122以接纳控制响应消息10向第二跳管理域协调器2121做出响应。

接着，第二跳管理域协调器2121将更新后的接纳控制请求信息作为协调请求消息11转发到第三跳管理域协调器2131。第三跳管理域协调器2131将接纳控制请求信息作为接纳控制请求消息12转发到第三管理域的第一跳传送网络协调器2132，该第一跳传输网络协调器与传输网络TN5的接纳控制接口执行其自身的接纳控制请求和响应消息交换。协调器2132对来自传输网络TN5的接纳控制响应信息与接纳控制请求信息进行合并，并将合并后的消息转发给第三管理域的第二跳传输网络协调器2138。协调器2138与传输网络TN6的接纳控制接口进行其自身的接纳控制请求和响应消息交换、对来自传输网络TN6的接纳控制响应信息与接收到的接纳控制请求信息进行合并，并将更新的接纳控制信息以协调请求消息14转发回协调器2132。接着，协调器2132在接纳控制响应消息中将更新后的接纳控制信息转发给第三跳管理域协调器2131。在此时间点处，已经针对跨各个传输网络TN1到TN6的流进行了网络预留。为了向接收应用2102通告该预留，第三跳管理域协调器2131在协调请求消息中将包含整体响应和整体QoS描述的接纳控制信息传递给应用2102，并且如果该应用接受被授权的QoS，则它以协调请求消息17对第三跳管理域协调器2131进行响应，接着协调请求消息17作为协调响应消息18被转发到第二跳管理域协调器2121，并接着作为协调请求消息19被转发到第一跳管理域协调器2111。接着，应用的QoS信号机2101从第一跳管理域协调器2111接收包含整体QoS描述和整体响应的最终协调响应消息作为协调响应消息20。

因此，对于这种层级结构排列，任何具体层内的协调器仅需要知道它相同层内协调器的地址，而对于传输网络级别协调器，需要知道相同管理域内的协调器的地址。对于管理域级别协调器，仅需要知道其他管理域级别协调器的信令地址。同样，对于QoS信号机，仅需要知道第一跳管理域协调器的信令地址。因此，获得了先前关于第一实施方式描述的协调接纳控制请求和响应消息的益处，并且通过这种层级结构排列大大降低了要知道许多协调器的地址的要求。

图24例示了“非阻塞模式”下层级结构协调层的操作。更具体地说，在第一跳管理域2111处，接收来自针对应用工作的QoS信号机2101的协调请求消息，该协调请求消息包含具有所要求的QoS描述接纳控制请求信息。接着，作为接纳控制请求消息向第一跳传输网络协调器2112转发该接纳控制请求信息，并且因为协调器在“非阻塞模式”下工作，所以还向第二跳管理域协调器2121发送关于该接纳控制请求信息而转发的协调请求消息2。在第一跳传送协调器2112处接收到接纳控制请求消息A，并且该接纳控制请求信息作为协调请求消息B被立即转发到第二跳传输网络协调器2118。协调器2112还将该接纳控制请求信息作为接纳控制请求消息转发到传输网络TN1的本地接纳控制接口，并且一旦从传输网络TN1接收到接纳控制响应，则协调器2112就会等待来自协调器2118的协调响应消息。在接收到协调请求消息B时，协调器2118与传输网络TN2的接纳控制接口执行接纳控制请求和响应消息交换，并在对将接收到的接纳控制响应信息与请求信息进行合并后，将协调响应消息C发送回协调器2112。接着，协调器2112可以将协调响应消息C中包含的接纳控制信息与它的本地接纳控制响应信息进行合并，并向第一跳管理域协调器2111发送包含更新后的QoS描述和响应的接纳控制响应消息D。接着，第一跳管理域管理器2111等待从第二跳管理域协调器2121接收协调响应消息。

在第二跳管理域协调器2121处，在接收到协调请求消息2以后，将包含整体请求的QoS描述的接纳控制响应信息作为协调请求消息3转发到第三跳管理域协调器2131。同时，第二跳管理域协调器2121将接纳控制请求信息作为接纳控制请求消息A转发到第二域的第一跳传输网络协调器2122。协调器2122与传输网络TN3的接纳控制接口执行其自身的接纳控制请求和响应消息交换，并且还将接纳控制请求信息作为协调请求消息B转发到第二域的第二跳传输网络协调器2128。协调器2128与传输网络TN4的接纳控制接口执行其自身的接纳控制请求和响应消息交换，并且在将从网络TN4接收到的接纳控制响应信息与请求合并之后，将协调响应消息C发送回协调器2122。接着，协调器2122将随后包含在协调响应消息C中的接纳控制响应信息与其自身的本地接纳控制响应信息合并，并将具有更新后的接纳控制响应信息(包括QoS描述和响应标记)的接纳控制响应消息D发送到第二跳管理域协调器2121。接着，管理域协调器2121不进行任何操作，等待接收来自第三跳管理域协调器2131的协调响应消息6。

在第三跳管理域协调器2131处，接收到协调请求消息3，并作为协调请求消息4被立即转发到接收应用2102。同时，作为接纳控制请求消息A向第三管理域的第一跳传输网络协调器2132转发接纳控制请求信息。协调器2132与传输网络TN5的接纳控制接口执行其自身的接纳控制请求和响应消息交换，并且还将接纳控制请求信息作为协调请求消息B转发到传输网络TN6的协调器2138。协调器2138与传输网络TN6的接纳控制接口执行接纳控制请求和响应消息交换，并将包含更新后的QoS描述和响应的协调响应消息C发送到协调器2132，该响应包含传输网络TN6的接纳控制响应。协调器2132将接收到的接纳控制响应信息与其自身的接纳控制响应信息合并，并将接纳控制响应消息D发送回第三跳管理域协调器2131。接着，管理域协调器2131等待从应用2102接收协调响应消息。

假设所请求的QoS对接收应用2102来说是可接受的，则该接收应用将协调响应消息5发送回第三跳管理协调器2131。然后，将协调响应消息5(要进行修改)中包含的接纳控制信息与从协调器2132接收到的接纳控制响应信息合并，并且接着将更新后的接纳控制响应信息作为协调响应消息6转发到第二跳管理域协调器2121。接着，协调器2121将接收到的接纳控制响应信息与从协调器2122接收到的它的本地接纳控制响应信息合并，并将更新后的接纳控制响应信息作为协调响应消息7发送到第一跳管理域协调器2111。接着，协调器2111将接收到的接纳控制响应信息与从协调器2112接收到的它的本地接纳控制响应信息合并，并将最终的协调响应消息8发送回发送应用2101的QoS信号机。

因此，即使当在“非阻塞”模式下工作时，本发明第二实施方式的层级结构协调层也能够通过以协调请求消息的形式接收单个接纳控制请求来服务接纳控制请求，并经由协调响应消息提供单个接纳控制响应。

另外，在本发明的实施方式中，QoS信令实体仅需要知道第一跳协调器的信令接口，而不需要知道如何直接联系传输网络接纳控制接口。因此，通过在传输网络的接纳控制接口的顶部上的协调层中提供协调器，并且具有到由上面讨论的coord()消息来定义的协调器的接口，可以为独立于传输网络的任何QoS信令实体提供公用接口。

在上述实施方式中，我们已经关注了本发明的协调器方面，这些协调器与QoS请求类型的具体形式无关，并且可以用来与QoS请求和响应的形式无关地协调接纳控制。然而，在下面描述的实施方式中，我们进一步解决前面提到的现有技术另外的问题，即在现有技术中，数据源10或QoS信号机30必须典型地与数据传输网络20通信，以使用专用于使用中的数据传输网络QoS技术的QoS信令消息来针对具体流建立QoS。

为了克服这些进一步的问题，在本发明的可以将上面描述的任何实施方式作为它们基础的进一步实施方式中，从协调器50接收接纳控制请求的接纳控制接口40包括翻译器实体，该翻译器实体将这些请求翻译成数据传输网络20中采用的QoS机制所要求的形式。因此，在此方面，数据传输网络20的接纳控制接口40可以被考虑为QoS翻译器，并且因此在下文中被称为翻译器40。

翻译器40用作协调器50和数据传输网络20的接纳控制功能之间的媒介，从位于接纳控制功能正上方的协调器50接受接纳控制请求，并以关于已经做出的QoS预留的信息作为对协调器50的响应。在协调器50和数据传输网络的接纳控制功能之间提供翻译器40消除了要求任何QoS信号机理解IP流必须经过的各传输网络20的QoS机制。

如先前所描述的，在协调器50和翻译器40之间传递的消息流为前面提及并在图9中示出的接纳控制请求/响应消息ac_req()和ac_res()。这里，接纳控制请求消息320至少包含针对其请求QoS的流ID，以及描述数据源要求的QoS级别的QoS描述。应该注意的是，该QoS描述可以由QoS信号机30添加，或者从传递到QoS信号机的服务请求消息中的数据源10中接收得到。QoS描述携带端用户应用要求的性能限制，以提供端用户请求的服务。

一旦接收到接纳控制请求消息320，翻译器40就会在翻译器和数据传输网络20之间执行技术专用检查(technology specific check)，以确定数据传输网络20是否能够提供所请求的QoS。稍后将对这些检查进行更详细地说明。一旦已经执行了检查，翻译器40将接纳控制响应消息340发送回QoS信号机30，该接纳控制响应消息包含指示QoS请求是成功、失败或者QoS描述是否必须被降低的响应变量，如果必要的话，还一同包含降低的QoS特性的描述。生成接纳控制请求消息的协调器50接收该响应消息，并接着根据它是在阻塞还是非阻塞模式下工作和它是否为最后跳协调器，来生成如之前描述的实施方式中描述的coord(REQ)或者coord(RES)消息。

本发明的利用协调器50和网络接纳控制之间的翻译器实体40的当前描述的实施方式的一个目的是：允许发送应用来请求具体的服务质量而该请求不必具有具体形式或者符合数据传输网络中QoS体系结构的要求。其原因在于，假设在数据传输网络中可以使用的许多类型的QoS体系结构的情况下，尚未证明产生能够与所有这些QoS体系结构交互的应用是具体可行。因此，在本发明当前描述的实施方式中，我们使用提供端对端服务的概念，该服务是为应用所理解的QoS服务，而不是传输网络专用的QoS服务。接着，通过翻译器实体40将端对端服务定义翻译成传输网络专用的QoS服务。

具体地说，在本发明当前描述的实施方式中，我们定义了三种不同类型的端对端服务。第一种类型被定义为“弹性”服务。这等同于传输网络中通常提供的“尽力(best effort)”服务，并且涉及尽可能快地转发的分组。在没有任何特定QoS请求的情况下，这种弹***为针对应用生成的IP流给出的默认服务。

第二种类型的服务为“实时非容错服务(real time intolerant service)”。如图8中表内所示出的，实时非容错服务的特征在于提供有保证的最小数据速率和有保证的最大延迟时间。另外，这种服务提供了非常低的抖动，并且没有分组丢失。例如，诸如视频会议应用的视频流应用可以请求这种服务。这种端对端服务映射到综合业务传输网络中的保证传递服务，或者DiffServ网络中的加速转发类。为了调用这种服务，应用或QoS信号机应该包括服务请求，以及coord(REQ)消息的整体QoS描述部分1906中的业务特性参数集。具体地说，在本发明当前描述的实施方式中，我们设想了包含所要求的平均数据速率、要生成的业务的“突发性(burstiness)”的测量以及业务的峰值速率的业务特性参数。附加参数为最小分组大小和最大分组大小。稍后将讨论这些参数的进一步细节。

第三种类型的端对端服务为“实时容错(in time tolerant)”服务。这可以用于速率自适应或延迟自适应的应用，并且这种服务的特征在于在指定业务包络中提供低级别分组丢失和高数据速率。即，倘若实时容错应用坚持其指派的QoS，则将提供高数据速率。

根据上面定义的端对端服务的类型，本发明当前描述的实施方式中包含的翻译器意图取得针对具体类型的端对端服务的请求，并将它翻译成传输专用QoS体系结构(例如，综合业务体系结构或区分服务体系结构)。通过在翻译器40存储服务类型翻译表来实现这一点，该服务类型翻译表指示端对端服务类型应该被映射到基于哪种流的QoS或基于哪个类的QoS。存储在翻译器40处的服务类型翻译表对应于图8中示出的表，但是没有该表的第二和第三列。因此，通过查找所请求的端对端服务类型，并接着沿该表的行读取，直到列为与传输网络中使用的具体QoS体系结构相关的列，接着可以选择传输网络QoS类型。因此，例如，假设翻译器40是用于使用DiffServ体系结构的传输网络的翻译器，并且翻译器接收对实时容错服务的请求，则根据该表，翻译器可以知道QoS请求需要被翻译成DiffServ体系结构的加速转发类。类似地，作为另一实施例，假设使用综合业务体系结构的传输网络的翻译器接收到对实时容错服务的服务请求，则该服务被翻译成传输网络的受控加载服务。

现在将针对图5描述本发明当前描述的实施方式中的翻译器40的操作。应该注意的是，作为实施例，本发明当前描述的实施方式可以被用于多协议标签交换(MPLS：multi-protocol label switching)网，在这种情况中，IP流被映射到被建立以提供所要求的QoS的标签交换路径(LSP：label switched path)。这种映射可以是一对一的，即单个IP流被映射到单个LSP，或者在为LSP提供多个资源的情况下，倘若LSP能够处理与其匹配的IP流的多重服务质量要求，则可以对LSP映射一个以上的IP流。

在其他实施方式中，可以使用数字用户线路(DSL：digital subscriberline)传输网，该数字用户线路(DSL)传输网将异步传输模式用作网络技术。在这种情况中，可以利用具体QoS特性来创建虚拟回路，并且IP流与能够满足IP流QoS要求的VC匹配。对于MPLS的情况，如果为一个虚拟回路提供多个资源，倘若该虚拟回路能够处理不同IP流的多重QoS要求，则可以对该虚拟回路映射一个以上的IP流。

鉴于以上情况，在下面的描述中，我们描述将IP流映射到确定的LSP(在MPLS实施方式中)或者映射到VC(在基于ATM的DSL的实施方式中)上的情况。

现在转到图5，将对翻译器40的整体操作进行说明。另外，下面展示了翻译器40的操作的伪码表示。

Upon receipt of ac_req(flow_id，qos_des)

{

//在本MPLS实施例中，这是传输专用函数

result＝admission_control_check(flow_id，qos_des，qos_des_degrade，lsp)；

//根据结果进行不同操作

if(result＝＝success)

{

//在将IP流ID映射到LSP的表中添加条目

install_policy(flow_id，lsp)；

response＝success；

}

//接纳控制检查已经失败

else if(result＝＝failure)

{

Response＝failure；

}

//接纳控制确认将必须降低新流的级别

else

{

response＝degrade；

//用降低的版本修改请求的qos描述

qos_des＝qos_des_degrade；

}

//将接纳控制响应发送到QoS信号机

//如果响应为降低，则qos_des包含新的qos描述；否则，qos_des可以被忽略

send(ac_res(response，qos_des)，qos_signaller)；

}

在步骤5.2处，翻译器40从负责协调针对具体翻译器40所属的传输网络的接纳控制响应的协调器50接收接纳控制请求消息320。接纳控制请求消息320包含图9中示出的信息。具体地说，该消息包含已经针对其请求QoS的IP流ID。随后包括服务请求部分，接着是包括所请求的QoS描述的部分。整个消息可以为统一的XML文件格式。典型地，在协调器50处从QoS信号机30接收到的((第一跳协调器)或上游协调器(中间或最后跳协调器))的coord(REQ)消息的整体QoS描述部分1906中，至少已经接收到服务请求部分904和QoS描述部分906。

服务请求部分904包含指示请求的服务类型的第一部分9042。如先前所提到的，在本发明的实施方式中，服务类型可以是弹***、实时容错服务或实时非容错服务。在部分9044处，服务请求部分的第二部分为对用比特每秒来表示的请求的数据速率的指示。在部分9066处，第三部分是对用微秒来表示的延迟项(delay slack term)的指示。是包括数据速率还是延迟项将取决于服务请求的类型。

更具体地说，在所请求的服务类型为弹***的情况下，服务请求部分904的部分9042指示请求弹***。然而，对于这种弹***，未请求具体的数据速率，并且也未要求的延迟的指示，因此，部分9044和9066为空，并且携带空指示符。类似地，在服务请求针对弹***的情况中，没有请求具体QoS，并由于未要求具体业务特性，因此所请求的QoS描述906也包含空指示符。

另选的是，在服务请求类型针对实时非容错服务的情况中，服务请求部分904的部分9042将指示请求了实时非容错服务。对于这种服务请求，需要在部分9044处指示所请求的数据速率，并在部分9066处指示延迟项。另外，如先前所讨论的，当请求这种服务时，应用还必须提供业务特性参数。这些参数位于所请求的QoS描述部分906的9062处。如先前所提到的，业务特性参数包括所请求的用比特每秒表示的平均速率。还包括峰值速率请求，它等于平均速率加上某个附加值delta。因此，峰值的单位亦为比特每秒。第三个参数为“突发性”，在本发明当前描述的实施方式中，该参数等于峰值速率加上另一不同项delta_2。注意，delta和delta_2可以不同或者相同。

另外提供为QoS描述中的业务特性的部分为应用期望发送的最小分组大小和最大分组大小的字节指示。上面提到的所有参数都被用作匹配元素，来将针对流请求的QoS与例如经由传输网络的LSP和VC提供的QoS进行合适地匹配。

返回到图5，因此，在接收到以上描述的形式的接纳控制请求消息之后，在步骤5.4处，翻译器40执行如后面参照图6和图7所描述的接纳控制检查函数。该接纳控制检查函数以服务类型请求、流ID以及业务描述为输入，并输出响应变量，该响应变量指示接纳控制检查是成功还是失败，或者是否需要降低QoS描述。在响应变量指示“降低”的情况中，接纳控制检查函数还返回描述已经被网络授权的降低的QoS的QoS描述。下文中将给出接纳控制检查函数的进一步细节。

在接纳控制检查函数之后，在步骤5.6处，执行关于接纳控制检查是否为成功(即响应变量是否等于“成功”)的评估。如果是，则在步骤5.8处，翻译器控制传输网络的接纳控制接口以将具体IP流的流ID映射到被确定为能够提供所请求的QoS的LSP或VC的形式的传输网络服务。这里，传输网络维护将IP流适当地映射到不同LSP或VC的表，并且在步骤5.8处，在指定IP流和被确定为能够提供所请求的QoS的VC或LSP之间的映射的表中添加新的条目。其后，针对映射表确定的LSP或VC上的跳传输属于IP流的分组。在该步骤之后，在步骤5.10处，翻译器将接纳控制响应消息发送回发送该请求消息的协调器50，该接纳控制响应消息包含指示“成功”的响应变量。

在图10中示出了接纳控制响应消息的格式。这里，接纳控制响应消息340包括第一部分1002和第二部分1004，第一部分1002包含与该消息相关的流ID，第二部分1004包含响应变量。如之前所提到的，响应变量可以取“成功”或“失败”或者“降低”(如部分1014所提到的)值。另外提供了包含被授权QoS描述(作为网络授权的QoS)的另一部分1006。在该部分中包含网络实际授权的QoS参数的表示(例如以XML格式)。在响应为“成功”的情况，可以期望这些QoS参数与所请求的QoS参数相匹配，在这种情况(即，在响应为“成功”的情况)下，被授权的QoS描述1006可以被考虑为可选选项。然而，在响应部分1004包含变量“降低”的情况，被授权QoS描述1006包含指示网络向应用授权降低的QoS的QoS参数1016。

再次返回到图5，如果在步骤5.6处，接纳控制检查函数返回非“成功”值，则处理前进到步骤5.12，其中执行评估来确定返回值是否为“失败”。如果是，则处理前进到步骤5.14，其中发送在响应变量部分1004包含“失败”值的接纳控制响应消息。在这种情况下，可以不包括被授权QoS描述部分1006，或者可以包括该QoS描述部分，但其内容为空项。

最后，如果在步骤5.12处，接纳控制确认响应不是“失败”，则处理前进到步骤5.16，其中执行评估来确定接纳控制确认响应是否为“降低”。当传输网络不能提供与所请求的QoS描述匹配的LSP或VC时则返回该响应，在这种情况下，选择与所请求的QoS最匹配的另选LSP或VC。在QoS描述中指示由下一最佳LSP或VC提供的QoS。因此，当接纳控制检查函数响应为“降低”时，在步骤5.18处，发送在响应部分1004中包含“降低”的接纳控制响应消息，并且在被授权QoS描述部分1006中包括为流已分配的LSP或VC的QoS描述。如之前所提到的，在发送接纳控制请求消息的协调器50处接收回接纳控制响应消息。

根据本发明当前描述的实施方式中的这种排列，应用10可以使用独立于可能存在多种传输网络QoS定义的端对端服务定义来请求QoS。因此，可以实现端对端服务和传输网络服务之间的映射。

图6是更详细地例示如何执行步骤5.4的接纳控制检查函数的流程图。另外，为了完整起见，下面展示了接纳控制检查函数的伪码表示。应该注意的是，尽管该伪码表示针对MPLS实施方式，但是也可以容易修改为针对DSL VC的实施方式。

//MPLS专用函数

boolean admission_control_check(flow_id，qos_des，qos_des_degrade，lsp)

{

while(MPLS finds an available LSP(with certain qos characteristics)OR MPLS does not find any available LSP)

{

lsp＝get_LSP(qos_des)；

//该函数查询形式为(lsp，lsp_qos_characteristics)的表；并且它选择和所请求的流的qos_des具有最接近的QoS特性的lsp

//检查在LSP上存在足够资源

response＝check_resources(lsp，qos_des)；

}

if(response＝＝successful OR response＝＝failure)

{

//不需要使用qos_des_degrade变量

qos_des_degrade＝null；

}

else

{

/^*MPLS发现具有比请求的流的QoS描述更低QoS特性的LSP。所以，为降低的QoS描述指派MPLS发现的(对可用资源来说最合适的)LSP的特性^*/

qos_des_degrade＝lsp_qos_characteristics；

}

return(response)；

/^*另外，lsp返回在IP流将被映射到其上的情况的所选LSP；qos_des携带该LSP的特性(如果该LSP的特性与qos_des相匹配)；否则，qos_des_degrade将携带LSP的QoS特性^*/

}

返回到图6，在步骤6.2处，接纳控制检查函数接收所请求的QoS特性加上服务请求类型。即，该函数已经向它传递服务请求部分904的部分9042的内容，以及接纳控制请求消息的所请求的QoS描述部分906的部分9062中包含的业务特性参数。在步骤6.4处，如先前所描述的，利用图8的服务类型映射表向传输网络专用QoS体系结构映射所请求的服务类型。因此，在服务类型指示请求“实时容错”服务，并且翻译器用于DiffServ体系结构传输网络的情况中，流ID将被映射到确保转发服务类。相反，如果翻译器代表综合业务传输网络操作，则流将被处理为受控的加载流。

在步骤6.4处执行了向传输网络专用的QoS的映射后，在步骤6.6处，检查确定的类中的或者提供基于具体类型的流的服务的(合适)LSP或VC，以确定是否任何可用LSP或VC都具有匹配所请求的QoS描述的QoS特性，或者哪些最接近所请求的QoS描述。步骤6.6返回与QoS特性或者最接近QoS特性匹配的LSP或VC的LSP或VC标识符。后面将针对图7描述如何执行步骤6.6的具体实施例。然而，本领域技术人员将意识到，可以执行许多不同类型的匹配，以获得匹配的或最接近的LSP或VC。

在步骤6.6之后的步骤6.8处，针对是否发现匹配的LSP或VC进行评估。在此方面，“匹配”是指发现能够提供所有请求的QoS参数的LSP或VC。如果是该情况，则在步骤6.14处，返回“成功”响应，并一同返回匹配信道的LSP或VC ID。

或者，如果在步骤6.8处，确定未发现匹配的LSP或VC，则在步骤6.10处，执行另一评估来确定是否根本不存在匹配或最接近的LSP或VC。如果是这种情况，则函数在步骤6.16处返回失败值。

最后，如果步骤6.10的评估返回失败，则处理前进到步骤6.12，其中针对是否存在最接近的LSP或VC(即，是否存在最接近地满足请求的QoS参数，但是与所请求的QoS参数并不完全匹配的LSP或VC)进行评估。如果是该情况(也必定为该情况)，则在步骤6.18处，接纳控制检查函数返回“降低”值，并一同返回最接近匹配的可用LSP或VC的LSP或VC ID，以及LSP或VC能够提供的QoS特性。

因此，接纳控制检查函数用来确定传输路径或回路是否可用，并且如果它们可用则返回它们的标识符，或者如果可用，则返回次最佳路径或回路的标识。

图7给出了可以如何执行图6的步骤6.6的一个实施例。即，图7给出关于可以如何将所请求的QoS特性与可用LSP或VC进行匹配的一个实施例。在此方面，仅作为实施例提供的图7给出了合适的匹配函数的实施例，该匹配函数将QoS特性映射到提供QoS特性的LSP或VC，以识别能够完全满足特性的LSP或VC，或者，如果没有这种LSP或VC可用，则识别具有最高峰值速率的LSP或VC。在发现多个满足QoS特性的LSP或VC的情况下，选择满足QoS描述的具有最小峰值速率的LSP或VC。为了完整起见，下面给出匹配函数的伪码表示。同样，应该注意的是，尽管该伪码表示针对MPLS实施方式，但是也可以容易修改为针对VC实施方式。

get_LSP(qos_des)

{

  //QoS描述的参数(考虑为C结构的情况)

  //qos_des.p＝＝peak rate(峰值速率)

  //qos_des.m＝＝minimum packet size(最小分组大小)

  //qos_des.M＝＝maximum packet size(最大分组大小)

  //例程的变量

  lsp_type LSP_best＝＝NIL∥最佳LSP

  lsp_type LSP_sub_best＝＝NIL∥如果没有LSP可以完全满足QoS请求，则算法记忆具有最高峰值速率的LSP

  LSP_best.p＝INFINITY；

  LSP_sub_best.p＝NIL；

  for(i＝0；i<MAX_NUMBER_OF_LSP；i++)

  {

     //如果当前LSP满足QoS描述的限制，即可以完全满足QoS请求

     if(qos_des.p<＝LSP[i].p&&qos_des.m>＝LSP[i].m&&qos_des.M<＝LSP[i].M)

       {

  //算法在可以完全满足QoS描述中的峰值速率(即它们具有LSP[i].p>＝qos_des.p)的LSP中查找具有最小峰值速率的LSP

          if(LSP_best.p>LSP[i].p)

              LSP_best＝LSP[i]

         }

         else

         {

            if(LSP_sub_best.p<LSP[i].p)

                LSP_sub_best＝LSP[i]

         }

   }

  //测试算法是否发现合适的LSP

  if(LSP_best＝＝NIL)

     return(LSP_sub_best)

   else

     return(LSP_best)

 }

参照图7，步骤6.6的匹配函数首先在步骤7.2处获得来自所请求的QoS描述中的QoS特性。接着，在步骤7.4处，匹配函数初始化两个变量“LSP/VC_best”和“LSP/VC_sub＿best”，这两个参数将跟踪确定出的满足QoS要求或最接近的LSP或VC。这两个参数被初始化为包含空值。

接着，在步骤7.6处，处理循环被初始化为比较具体服务类(DiffServ网络)中的各可用LSP或VC，或者比较能够提供可用于服务QoS请求的基于流的服务类型(针对综合业务网络)的各可用LSP或VC。在步骤7.6处开始FOR循环，来依次处理这些可用LSP或VC中的每一个。

FOR循环中的第一步骤为步骤7.8的步骤，该步骤为确定当前处理的LSP或VC(为LSP/VC[i])是否满足QoS特性的评估。即，在本实施方式中，被考虑的QoS特性为峰值速率、最小分组大小以及最大分组大小。这些特性与各LSP/VC的对应参数进行比较，以确定是否满足QoS要求。如果当前处理的LSP/VC能够满足这些QoS要求(即，存在满足要求的可用资源)，接着处理前进到步骤7.12，其中执行进一步评估来确定“LSP/VC_best”(先前发现并被分配给变量)的峰值速率是否大于当前处理的LSP或VC的峰值速率。如果是该情况，则在步骤7.14处，令当前处理的LSP或VC等于LSP/VC_best变量，即当前处理的LSP或VC被确定为最佳匹配的LSP或VC。步骤7.12的这种第二评估确保在可以满足QoS要求的LSP或VC中选择具有最低峰值速率的LSP或VC。

如果在步骤7.8处，当前处理的LSP或VC不能满足QoS要求，则在步骤7.10处针对当前指派给“LSP/VC_sub_best”变量的LSP或VC的峰值速率是否小于当前处理的LSP或VC的峰值速率进行评估。如果是这种情况，则在步骤7.16处，用当前处理后的LSP或VC的ID初始化LSP/VC_sub_best变量。

如上面所提到的，执行上面处理的结果为，该算法确定满足所有QoS要求但是具有最低可用峰值速率的LSP或VC，接着返回LSP或VC的ID作为变量LSP/VC_best。另外，该算法还确定不满足QoS要求但是具有最大峰值速率的LSP或VC。在步骤7.20处，除非该变量LSP/VC_best的值为空，否则返回该变量中包含的LSP或VC ID，在LSP/VC_best的值为空的情况下，返回LSP/VC_sub_best变量中包含的LSP或VC ID。

如先前所提到的，图7的匹配算法仅是QoS特性可以如何与LSP或VC中可用QoS相匹配的一个实施例，并且可以使用其他匹配算法。

应该注意的是，具有如上所述操作的翻译器实体40可以与先前描述的第一或第二实施方式的协调器50一同使用，以提供本发明的进一步实施方式。具体地说，翻译器实体40典型地位于协调器50和IP流必须经过的传输网络20的本地接纳控制接口之间。通过结合先前描述的第一和第二实施方式的协调器使用这种翻译器功能，获得了对接纳控制请求和响应进行协调的益处，而利用该增加的优点，端对端QoS描述可以被映射到技术专用的QoS体系结构。因此，在没有本发明的进一步实施方式的情况下，也一样可以克服任意特定应用不得不根据多种可用QoS体系结构信号通知许多不同类型的QoS的附加问题。

图25例示了用作通往传输网络20的域网关的计算机***40/50。计算机***40/50配备有计算机可读存储介质410以及常规的处理器、存储器、输入和输出功能等。用作传输网络20的域网关的计算机***40/50具有在其上以及在传输网络级别协调器实体50上运行的多个处理，这些处理执行传输网络20的接纳控制接口功能40。因此，为了提供这种功能，在计算机可读存储介质410上存储提供接纳控制接口功能的接纳控制程序4010。具体地说，在基于本发明的上述第三实施方式的实施方式中，接纳控制程序4010用来提供所述的翻译器功能。在本发明的其他实施方式中，例如基于先前描述的第一和第二实施方式的实施例中，接纳控制程序4010用来执行先前描述的接纳控制接口功能(即，接受包括QoS描述的接纳控制请求信息)以检查传输网络服务对于QoS描述的可用性，并且根据QoS描述进行任意网络预留并返回报告。该功能还可以根据需要而具有授权降低的QoS级别的能力。

为了提供位于接纳控制接口上方的传输网络级别协调器实体50，计算机可读介质410还配备有协调器程序4110，当计算机***运行该程序时，协调器程序4110提供如上面的实施方式中描述那样操作的协调器实体50。提供单独的合并逻辑程序4210，可以由协调器程序4110调用该单独的逻辑合并程序4210，并且如之前参照图18所描述的，提供接纳控制响应信息合并函数。如果需要的话，提供单独的合并逻辑程序4210使得能够使用不同的合并函数。例如，如先前描述的，可以采用各种不同机制来确定与另一QoS描述格式不同的一个具体QoS描述是否提供更低的QoS级别，并且可以在合并逻辑程序4210中编码可能执行该函数的任何不同策略。当计算机***运行该程序时，程序4110和4210一同提供协调器实体50功能。

在计算机可读存储介质410中附加提供了常规的操作***软件4310以及域网关功能软件4410，以使得计算机***能够充当域网关，并且同样地，网关功能软件4410是也常规软件。然而，根据基于本发明第三实施方式的各实施方式，还提供了流ID到LSP或VC的映射表4510，该映射表4510将流ID映射到确定的LSP或VC，并且当它从具有具体流ID的数据源10接收分组时，计算机***(具体地说，在该计算机***上运行的接纳控制处理4010)参考该映射表4510，以知道它必须将分组安置到哪个LSP或VC上。在此方面，当以这种方式操作时，计算机***是传输网络的路由器。

可以对上述实施方式进行各种修改以提供落入所附权利要求范围内的进一步实施方式。

Claims (58)

1.一种由用于一个或更多个传输网络域的本地子集的协调器实体执行跨多个传输网络域来协调接纳控制消息的方法，该方法包括以下步骤：

i)接收至少一个协调请求消息的步骤，接收包含接纳控制请求信息的至少一个协调请求消息；

ii)转发步骤，向一个或更多个所述传输网络域的子集的接纳控制接口或功能转发包含所述接纳控制请求信息的接纳控制请求消息；

iii)接收接纳控制响应消息的步骤，接收含有本地接纳控制响应信息的接纳控制响应消息，该本地接纳控制响应信息是根据传输网络域的所述本地子集或各个本地子集响应于所述接纳控制请求信息做出的接纳控制响应而得到的；

iv)生成步骤，至少根据所述接纳控制响应信息来生成进一步协调消息；以及

v)传输步骤，传输所述进一步协调消息。

2.根据权利要求1所述的方法，其中所述协调器实体在阻塞模式下工作，其中所述生成步骤包括根据所述本地接纳控制响应信息和接收到的所述接纳控制请求信息来生成进一步协调请求消息作为所述进一步协调消息，并且所述传输步骤包括将所述进一步协调请求消息传输到用于一个或更多个传输网络域的下一相邻子集的下一跳协调器实体。

3.根据权利要求1所述的方法，其中所述协调器实体在非阻塞模式下工作，该方法包括以下步骤：在接收到所述至少一个协调请求消息后，向用于一个或更多个传输网络域的下一相邻子集的下一跳协调器实体转发所述协调请求消息。

4.根据权利要求3所述的方法，其中所述方法还包括：

从所述下一跳协调器实体接收包含接纳控制响应信息的协调响应消息；

其中，所述生成步骤接着生成包含根据所述本地接纳控制响应信息和接收到的所述接纳控制响应信息而生成的接纳控制响应信息的协调响应消息作为进一步协调消息，并且所述传输步骤包括传输所述协调响应消息。

5.根据权利要求4所述的方法，其中向用于一个或更多个传输网络域的前一相邻子集的前一跳协调器实体传输所述协调响应消息。

6.根据权利要求2到5中的任意一项所述的方法，其中所述生成步骤还包括：

将所述本地接纳控制响应信息与以下中的一项进行比较：

i)在阻塞模式中，接纳控制请求信息；或者

ii)在非阻塞模式中，在所述协调响应消息中接收到的所述接纳控制响应信息；

确定所比较的信息中表示这两个比较信息的最小值的信息；以及

产生包含与所确定的最小值信息相对应的接纳控制请求或响应信息的进一步协调消息。

7.根据前述权利要求中的任意一项所述的方法，其中提供协调器实体的层级结构，用于传输网络域的所述本地子集的协调器实体形成所述层级结构的一部分，所述层级结构包括每一个均针对单个传输网络域工作的最低层协调器实体和一个或更多个较高层的协调器，较高层的协调器用来与更低一层的协调器交换消息，由此聚集来自多个传输网络域的接纳控制响应。

8.根据权利要求7所述的方法，其中对于在所述最低层中工作的协调器实体来说，所述转发步骤包括向所述协调器实体所工作的传输网络域的接纳控制接口转发所述接纳控制请求消息。

9.根据权利要求7或8所述的方法，其中对于在所述最低层之外的层中工作的协调器实体来说，所述转发步骤包括在朝向所述传输网络的方向的下一层中的协调器实体转发所述接纳控制请求消息。

10.根据前述权利要求中的任意一项所述的方法，其中所述本地接纳控制响应信息指示在传输网络域的所述子集或各个子集处，响应于所述接纳控制请求信息而进行的被授权传输网络预留的状态和/或特性。

11.根据前述权利要求中的任意一项所述的方法，其中所述接纳控制请求信息包括所请求的QoS的流QoS描述。

12.根据前述权利要求中的任意一项所述的方法，其中所述接纳控制响应信息包括被授权的QoS的流QoS描述。

13.根据权利要求11所述的方法，其中所述流QoS描述包括指示所请求的QoS类型的第一部分和包含一个或更多个所请求的QoS参数的第二部分。

14.根据权利要求13所述的方法，其中所请求的QoS类型包括选自包含以下类型的组中的端对端类型：弹性、实时容错、以及实时非容错。

15.根据权利要求13或14所述的方法，其中所请求的QoS参数包括从下面参数中选择的一个或更多个参数：平均速率、峰值速率、突发性、最小分组大小、以及最大分组大小。

16.一种跨多个传输网络域协调接纳控制信号的方法，该方法包括以下步骤：

为传输网络域提供至少一个协调器实体，所述至少一个协调器实体被设置为与该协调器实体被提供给的所述传输网络域的接纳控制接***换接纳控制请求和响应消息；以及

在所述多个传输网络域的协调器实体之间交换协调请求和响应消息，以合并所述域的所述接纳控制响应。

17.根据权利要求16所述的方法，其中所述协调器实体在阻塞模式下工作，其中针对接收到的包含接纳控制请求的协调请求消息，从所述协调器实体工作的所述网络域获得接纳控制响应，在将所述协调请求消息转发到下一跳传输网络域的下一协调器实体之前，所述响应与所述接纳控制请求合并。

18.根据权利要求16所述的方法，其中所述协调器实体在非阻塞模式下工作，其中在从所述协调器实体工作的网络域获得接纳控制响应之前，向下一跳传输网络域的下一协调器实体转发接收到的包含接纳控制请求的协调请求消息。

19.根据权利要求18所述的方法，其中针对接收到的包含接纳控制请求的协调请求消息，从所述协调器实体工作的网络域获得接纳控制响应，该响应与在来自用于下一跳传输网络域的下一协调器实体的协调响应消息中接收到的接纳控制响应合并。

20.根据权利要求19所述的方法，其中接着向用于前一跳传输网络域的前一协调器实体转发所述协调响应消息。

21.根据权利要求17到20中的任意一项所述的方法，其中所述合并步骤还包括：

将所述接纳控制响应与以下中的一项进行比较：

i)在阻塞模式中，接纳控制请求信息；或者

ii)在非阻塞模式中，在所述协调响应消息中接收到的接纳控制响应信息；

确定所比较的信息中表示这两个比较信息的最小值的信息；以及

产生包含与所确定的最小值信息相对应的接纳控制请求或响应信息的所述进一步协调消息。

22.根据权利要求16到21中的任意一项所述的方法，其中提供协调器实体的层级结构，该层级结构包括每一个均针对单个传输网络域工作的最低层的协调器实体和一个或更多个较高层的协调器，较高层的协调器用来与更低一层中的协调器交换消息，由此聚集来自所述多个传输网络域的接纳控制响应。

23.根据权利要求16到22中的任意一项所述的方法，其中所述接纳控制响应消息包含这样的信息，该信息指示在所述传输网络域处，响应于所述接纳控制请求消息而进行的被授权传输网络预留的状态和/或特性。

24.根据权利要求16到23中的任意一项所述的方法，其中所述接纳控制请求消息包含具有所请求的QoS的流QoS描述的信息。

25.根据权利要求16到24中的任意一项所述的方法，其中所述接纳控制响应消息包含具有被授权的QoS的流QoS描述的信息。

26.根据权利要求24所述的方法，其中所述流QoS描述包括指示所请求的QoS类型或被授权的QoS类型的第一部分和包含一个或更多个所请求的QoS参数的第二部分。

27.根据权利要求26所述的方法，其中所请求的QoS类型包括选自包含以下类型的组中的端对端类型：弹性、实时容错、以及实时非容错。

28.根据权利要求26或27所述的方法，其中所请求的QoS参数包括从下面参数中选择的一个或更多个参数：平均速率、峰值速率、突发性、最小分组大小、以及最大分组大小。

29.一种被这样设置的计算机程序或计算机程序套件，即当计算机***执行所述计算机程序或套件时，所述计算机程序或套件促使所述计算机***根据前述权利要求中的任意一项所述的方法工作。

30.一种存储根据权利要求29所述的计算机程序或至少一个所述计算机程序套件的计算机可读存储介质。

31.一种跨多个传输网络域协调接纳控制消息的协调器***，该协调器***用于一个或更多个所述传输网络域的本地子集，所述***包括：

消息接口，所述消息接口被设置用于：

i)接收包含接纳控制请求信息的至少一个协调请求消息；

ii)向一个或更多个所述传输网络域的子集的接纳控制接口或功能转发包含所述接纳控制请求信息的接纳控制请求消息；以及

iii)接收含有本地接纳控制响应信息的接纳控制响应消息，该本地接纳控制响应信息是根据传输网络域的所述本地子集或各个本地子集响应于所述接纳控制请求信息做出的接纳控制响应而得到的；

控制元件，所述控制元件被设置用于：

i)至少根据所述接纳控制响应信息来生成进一步协调消息；

所述消息接口还被设置用于：

iv)传输所述进一步协调消息。

32.根据权利要求31所述的***，其中所述协调器***在阻塞模式下工作，其中所述控制元件根据所述本地接纳控制响应信息和接收到的所述接纳控制请求信息来生成进一步协调请求消息作为所述进一步协调消息，并且所述消息接口将所述进一步协调请求消息传输到用于一个或更多个传输网络域的下一相邻子集的下一跳协调器实体。

33.根据权利要求31所述的***，其中所述协调器***在非阻塞模式下工作，其中所述消息接口在接收到所述至少一个协调请求消息后，向用于一个或更多个传输网络域的下一相邻子集的下一跳协调器实体转发所述协调请求消息。

34.根据权利要求33所述的***，其中所述消息接口还被设置用于从所述下一跳协调器实体接收包含接纳控制响应信息的协调响应消息，接着所述控制元件生成包含根据所述本地接纳控制响应信息和接收到的所述接纳控制响应信息而生成的接纳控制响应信息的协调响应消息作为进一步协调消息，所述消息接口接着传输该协调响应消息。

35.根据权利要求34所述的***，其中向用于一个或更多个传输网络域的前一相邻子集的前一跳协调器实体传输所述协调响应消息。

36.根据权利要求32到35中任意一项所述的***，其中所述控制元件还被设置用于：

将所述本地接纳控制响应信息与以下中的一个进行比较：

i)在阻塞模式中，接纳控制请求信息；或者

ii)在非阻塞模式中，在所述协调响应消息中接收到的所述接纳控制响应信息；

确定所比较的信息中表示这两个比较信息的最小值的信息；以及

产生包含与所确定的最小值信息相对应的接纳控制请求或响应信息的进一步协调消息。

37.根据权利要求31到36中的任意一项所述的***，其中提供协调器实体的层级结构，用于传输网络域的所述本地子集的协调器实体形成所述层级结构的一部分，所述层级结构包括每一个均针对单个传输网络域工作的最低层协调器实体和一个或更多个较高层的协调器，较高层的协调器用来与更低一层的协调器交换消息，由此聚集来自多个传输网络域的接纳控制响应。

38.根据权利要求37所述的***，其中对于在所述最低层中工作的协调器实体来说，所述转发步骤包括向所述协调器实体所工作的传输网络域的接纳控制接口转发所述接纳控制请求消息。

39.根据权利要求37或38所述的***，对于在和所述最低层不同的层中工作的协调器实体来说，所述转发步骤包括向所述传输网络向下的下一层中的协调器实体转发所述接纳控制请求消息。

40.根据权利要求31到39中的任意一项所述的***，其中所述本地接纳控制响应信息指示在传输网络域的所述子集或各个子集处，响应于所述接纳控制请求信息而进行的被授权传输网络预留的状态和/或特性。

41.根据权利要求31到40中的任意一项所述的***，其中所述接纳控制请求信息包括所请求的QoS的流QoS描述。

42.根据权利要求31到41中的任意一项所述的***，其中所述接纳控制响应信息包括被授权的QoS的流QoS描述。

43.根据权利要求41所述的***，其中所述流QoS描述包括指示所请求的QoS类型的第一部分和包含一个或更多个所请求的QoS参数的第二部分。

44.根据权利要求43所述的***，其中所请求的QoS类型包括选自包含以下类型的组中的端对端类型：弹性、实时容错、以及实时非容错。

45.根据权利要求43或44所述的***，其中所请求的QoS参数包括从下面参数中选择的一个或更多个参数：平均速率、峰值速率、突发性、最小分组大小、以及最大分组大小。

46.一种跨多个传输网络域协调接纳控制信号的***，该***包括：

为传输网络域提供的至少一个协调器实体，并且所述至少一个协调器实体被设置为与该协调器实体被提供给的所述传输网络域的接纳控制接***换接纳控制请求和响应消息；

所述协调器实体还被设置为与所述多个传输网络域的其他协调器实体交换协调请求和响应消息，以合并所述域的所述接纳控制响应。

47.根据权利要求46所述的***，其中所述协调器实体在阻塞模式下工作，其中针对接收到的包含接纳控制请求的协调请求消息，从所述协调器实体工作的所述网络域获得接纳控制响应，在将所述协调请求消息转发到用于下一跳传输网络域的下一协调器实体之前，所述响应与所述接纳控制请求合并。

48.根据权利要求46所述的***，其中所述协调器实体在非阻塞模式下工作，其中在从所述协调器实体工作的网络域获得接纳控制响应之前，向下一跳传输网络域的下一协调器实体转发接收到的包含接纳控制请求的协调请求消息。

49.根据权利要求48所述的***，其中针对接收到的包含接纳控制请求的协调请求消息，从所述协调器实体工作的网络域获得接纳控制响应，该响应与在来自用于下一跳传输网络域的下一协调器实体的协调响应消息中接收到的接纳控制响应合并。

50.根据权利要求49所述的***，其中接着向用于前一跳传输网络域的前一协调器实体转发所述协调响应消息。

51.根据权利要求47到50中的任意一项所述的***，其中所述协调器实体通过以下步骤来合并所述接纳控制响应：

将所述协调器实体工作的网络域的所述接纳控制响应与下面中的一项进行比较：

i)在阻塞模式中，接纳控制请求信息；或者

ii)在非阻塞模式中，在所述协调响应消息中接收到的接纳控制响应信息；

确定所比较的信息中表示这两个比较信息的最小值的信息；以及

产生包含与所确定的最小值信息相对应的接纳控制请求或响应信息的所述进一步协调消息。

52.根据权利要求46到51中的任意一项所述的***，其中提供协调器实体的层级结构，该层级结构包括每一个均针对单个传输网络域工作的最低层的协调器实体和一个或更多个较高层的协调器，较高层的协调器用来与更低一层中的协调器交换消息，由此聚集来自所述多个传输网络域的接纳控制响应。

53.根据权利要求46到52中的任意一项所述的***，其中所述接纳控制响应消息包含这样的信息，该信息指示在所述传输网络域处，响应于所述接纳控制请求消息而进行的被授权传输网络预留的状态和/或特性。

54.根据权利要求46到53中的任意一项所述的***，其中所述接纳控制请求消息包含具有所请求的QoS的流QoS描述的信息。

55.根据权利要求46到54中的任意一项所述的***，其中所述接纳控制响应消息包含具有被授权的QoS的流QoS描述的信息。

56.根据权利要求54所述的***，其中所述流QoS描述包括指示所请求的QoS类型或被授权的QoS类型的第一部分和包含一个或更多个所请求的QoS参数的第二部分。

57.根据权利要求56所述的***，其中所请求的QoS类型包括选自包含以下类型的组中的端对端类型：弹性、实时容错、以及实时非容错。

58.根据权利要求56或57所述的***，其中所请求的QoS参数包括从下面参数中选择的一个或更多个参数：平均速率、峰值速率、突发性、最小分组大小、以及最大分组大小。

Images