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

摘要

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

说明书

技术领域

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

背景技术

在诸如互联网协议(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 Conference on Communications的会议记要的1792-1796页)发表了论文“A Bandwidth Reservation Protocol for Hard QoS Guaranteed Differentiated Services(一种在区分服务中提供严格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发送接纳控制请求。

为了解决上面提到的现有技术的缺点，本发明的实施方式提供了协 调器实体的“协调层”，对每个域提供至少一个协调器实体。如将从要描 述的实施方式中清楚的，对各传输网络域提供协调器实体，并且协调器 实体可以层级结构排列，以将传输网络域的管理集合(administrative collection)反映给管理域。提供协调层使得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、TN2 2116和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 subscriber line)传输网，该数字用户线路(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上。在此方面，当以这种方式操作时，计算机系统 是传输网络的路由器。

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