利用特定URI的质量参数协商

摘要

一种应用客户端(C)与应用服务器(S)用于协商连接它们的通信网络(N

说明书

技术领域

本发明涉及通过应用服务器与应用客户端之间的通信网络传输 信息的领域。

背景技术

通过指定资源的标识符或URI，通信网络使得诸如浏览器的应用 客户端能够与应用服务器(或web服务器)进行导航。

这些URI(统一资源标识符)包括根据RFC 1738的URL(统一 资源定位符)，并且定义了因特网中的唯一资源。可以将资源视为 一条最小可用信息。其可以是根据HTML(超文本标记语言)编写 的网页、音频流或音视频流、多媒体或文本文件等。

对于一些类型的信息，一定的服务质量可能是必须的或者至少 是希望的。例如可能必须将音频流或音视频流实时传递到应用客户 端，并且使流的分组之间具有最小的延时以获得到末端用户的流畅 表现。

可以在应用客户端与应用服务器之间协商合适的质量参数，但 是该协商对于通信网络的影响很小，而质量下降的原因在大多数时 候是由于通信网络中的节点。

还存在用于确保沿着通信路径的一定服务质量的机制，如 DiffServ、RSVP等，但是这些方案是在协议栈的低层可用的，而在 应用级不可用。末端用户不可能使用这些协议来请求服务质量。

因此需要一种使得应用能够以与现有标准和实践兼容的方式来 协商服务质量参数的方案。

发明内容

本发明的目的在于通过为应用客户端与应用服务器提出一种对 连接它们的通信网络中的路径的质量参数进行协商的方法来满足该 需求。该方法包括所述应用客户端向所述应用服务器发送包括资源 的标识符的请求，以及所述应用服务器向所述应用客户端发送至少 一个包括与所述资源相关联的数据的应答。所述请求和所述应答通 过所述路径传输。

该方法的特征在于所述标识符指定所述至少一个应答应当符合 质量感知协议(quality-aware protocol)并且包括将要被该路径上的网 络节点实施的质量参数。

根据本发明的一个实施方式，所述标识符是以用于指定所述质 量感知协议的特定方案开始的统一资源标识符(URI)。

所述网络节点可以读取所述质量参数并且调谐它们自己的参数 以确保将根据这些质量参数来传输所述应答。

所述质量参数包括由延时约束、抖动约束、带宽约束组成的组 中的一个或多个参数。

所述应用服务器和所述应用客户端可以在收到所述应答之后开 始协商阶段，该协商阶段包括使得能够进行质量测量的重复的消息 序列，并且至少当这些质量测量符合所述质量参数时，所述协商阶 段终止。

附图说明

在下文中将结合附图来更清楚地描述本发明及其优点。

图1图示了可以连接应用服务器和应用客户端并且实现本发明 的通信网络的实例。

图2示出了在本发明的背景中的应用客户端末端处可以使用的 典型的人机接口。

具体实施方式

可以将该方法视为具有三个阶段。

将第一阶段定义为握手阶段，在该握手阶段中由应用客户端联 系应用服务器，并且应用服务器传送质量约束。

为此，应用客户端可以向用户请求应用服务器的资源的标识符。 图2示出了用于该步骤的典型实施方式，其中人机接口(MMI)显 示与使得用户能够浏览因特网的软件相关联的窗口SB。利用该软件， 用户可以在专用字段AF中输入该资源的地址。

该地址典型而言是URL(“统一资源定位符”)或URI(“统 一资源标识符”)。该地址以指定要使用的协议的方案开始。如IEFT 的RFC 1738所定义的，该方案可以采取值“ftp”、“http”、“mailto” 等等。根据本发明，使用新的方案来指定质量感知协议。该方案例 如可以是“httpq”，以表明其是基于如RFC2616所定义的HTTP协 议并且还是质量感知的，由字母“q”表达。

由用户输入的URL可以遵守格式：

″httpq:″″//″host[″:″port][path[″？″query]]

还应该理解，应用客户端通过除了通过可视MMI来提示用户之 外的其他方式来确定资源标识符也在本发明的范围中。首先，MMI 当然可以使用其他输入方式(例如口头命令)，但是一些应用可以 以对用户透明的方式自动地发送httpq请求。

可选择地，应用客户端也可以发送质量头部，并且当应用服务 器利用选定的值来构造它的应答时，可以考虑这些质量头部。

应用服务器可以使用HTTP 303错误消息来进行应答，该HTTP 303错误消息可以包括如下QHTTP头部中的一些或全部：

●Q-延时-约束(Q-Latency-constraint)：该头部指示该应用 所需的最大延时。

●Q-抖动-约束(Q-Jitter-constraint)：该头部指示该应用可 允许的最大抖动。

●Q-带宽-约束(Q-Bandwidth-constraint)：该头部指示该应 用所需的最小带宽，以比特每秒为单位测量。

●Q-端口范围-约束(Q-PortRange-constraint)：该头部指示 用于该应用的UDP或TCP端口范围。利用以下语法可以在该头 部中包括多个值，由“，”分隔开：

<协议><初始端口范围>[-<最终端口范围>][，<协议><初 始端口范围>[-<最终端口范围>]]

●位置(Location)：该头部指示在协商阶段中将要使用的 下一个URL，迫使web浏览器向新的HTTPQ URL发送新 Q-HTTP请求。

●Q-尝试(Q-tries)：该头部包括在协商阶段期间进行的尝 试的数量以及最大尝试次数。最初将尝试的次数设置为0。如果 达到尝试的极限，则认为不再能够改进质量。由“，”分隔开两 个值。

●Q-间隔(Q-Interval)：该头部指示服务器允许客户端重启 协商阶段的间隔时间(例如以秒为单位)。

●Q-结果(Q-Result)：该头部包括质量协商处理的结果。 最初将其设置为“OK”或者具有相同的含义的其他值。

●Q-升级(Q-Upgrade)：该头部指示需要网络质量的升级。 在某种意义上，它与在该实施方式中使用的消息(错误303)的 类型是部分冗余的，但是如果服务器想要在要求升级网络的质 量之前执行某些测量，则它仍然可以是有用的。例如如果该值 是“否”，则不要求网络升级；如果该值是“需要的”，则其 指示需要网络质量升级。

●Q-摘要(Q-Digest)：该头部包括使用全部质量头部和秘 密服务器关键字所生成的散列值，以避免在协商阶段的接下来 的消息中头部被修改。

●Q-自治-系统(Q-Autonomous-systems)：由“；”分隔的 值。每个中间自治系统应该填充它的标识符以便在该头部中得 到自治系统的完整列表。

在这两个消息之后，第一阶段完成。路径被建立，并且已向应 用客户端发送了质量参数。因此，所有中间网络元件已有机会读取Q 头部。

图1图示了可以连接应用服务器和应用客户端并且实现本发明 的通信网络的实例。

在实施中，该通信网络可以由多个子网络构成。在该实例中， 应用客户端C连接到接入网N_AC，接入网N_AC包括网络元件(或节点) N₁。应用服务器S连接到接入网N_AS，接入网N_AS包括网络节点N₇。

两个接入网N_AC和接入网N_AS分别连接到城域网N_MC和城域网 N_MS，城域网N_MC和城域网N_MS又通过骨干网N_B连接在一起。城域 网N_MC包括2个节点N₂和N₃，城域网由单个节点N₆组成。骨干网 包括两个节点N₄和N₅。

当然，在本领域中存在可以由本领域技术人员容易地部署本发 明的许多其他拓扑。

用于链接应用客户端C与应用服务器S的通信路径P通过网络 元件N₁、N₂、N₃、N₄、N₅、N₆、N₇。

如前所述，由于处在通信路径中，因此所有这些网络元件已经 传输了由应用客户端C与应用服务器S交互的这两个消息，并且知 道使用服务器的应答所传输的头部。知道了这些头部和它们包含的 质量参数，网络元件随后就可以实施它们。

存在网络节点实施质量参数的多种方式。

例如，接入节点可以触发向质量管理服务器MS发送消息m，质 量管理服务器MS在其负责的网络节点之中负责提供所请求的服务 质量。触发可以在客户端侧(即由节点N₁)或者在服务器侧(即由 节点N₇)进行。

根据另一个实施方式，位于路径P中的部分或全部网络节点可 以自行提供确保所请求的质量参数所需要的资源。

算法的第二阶段是质量协商阶段。由于该阶段对在握手阶段期 间已达成的内容添加了质量保证，所以该阶段可以被视为是可选的。

该协商阶段包括消息的重复序列，直到路径P符合最小质量约 束为止。该序列进一步使得网络能够执行一些质量测量。

应用客户端C向应用服务器S发送包含所有Q-HTTP质量头部 的Q-HTTP GET消息。将头部保持在所有消息中以向所有中间网络 元件提供该信息。应该注意到，这一点与常规HTTP协议不同，根 据常规HTTP协议，客户端在接收到位置头部之后不发送所有头部。

根据本发明的实施方式，应用服务器S必须用HTTP错误303 消息来进行应答，HTTP错误303消息包括：

●所接收的请求的所有质量头部。

●Q-时间戳(Q-Timestamp)：新的附加头部，其使用0作 为初始值。

●Q-结果(Q-Result)：设置为“OK”。

●位置：要重定向到的下一个“httpq”。将要使用通常的 模式是：″httpq″″//″host[″:″port][path[″？″query]]，其中每次使用 不同的查询值。该查询值可以是“Q-尝试”头部的值。

●更新Q-尝试头部，将Q-尝试头部的前一值增加1。

●用所有其他头部的新值来重新计算Q-摘要头部。

当应用客户端C接收该消息时，其再次发送Q-HTTP GET请求。 不应该修改任何头部，包括由服务器建立的时间戳头部。

通过这么做，应用服务器S能够测量在第一时间戳与新接收的 消息中的时间戳之间经过的时间。在这一点上，存在三种可能性：

1)达到了最大尝试次数。在这种情况下，我们可以认为不 再能够改进质量。应用服务器使用HTTP 412消息来应答，其中 在该HTTP 412消息中“Q-结果”头部的值是“NOK”。根据如 IETF的RFC 2616中段落10.4.13所定义的HTTP协议，“412” 消息意味着尚未满足客户端或服务器所要求的前提设置。

2)时间戳头部与当前时间之间的差异小到足以符合延时约 束。在这种情况下，应用服务器S使用HTTP 200消息来应答， 其中HTTP 200消息包括被设置为“OK”的“Q-结果”头部。

3)在最后一种情况下，该差异不够小，但是尝试的次数尚 未达到最大值。在这种情况下，HTTP 303消息被发回，该HTTP 303消息包括：

●在该请求中收到的所有的质量头部，

●Q-时间戳头部的新值，

●设为“NOK”(或者意味着结果不是OK的任意其他值) 的Q-结果头部的值，

●设为新值的位置头部。

在满足其中一个终止条件之后，应用客户端将使用HTTP位置头 部机制发送Q-HTTP请求，以便允许通信网络N_AC、N_MC、N_B、N_MS、 N_AS来调谐它们自己。

当接收到200OK消息时，这意味着已经达到了最佳条件，并且 客户端可以利用网络提供的足够的质量连接或者至少最佳质量连接 来接入服务。

服务器S然后可以开始向所述应用客户端发送包括与客户端所 请求的资源相关联的数据的消息。例如，该消息可以是包括多媒体 资源(例如电影和/或音频流)的数据的分组。该资源也可以是应用 服务器可以与之建立链接的另一个客户端的地址，并且那么数据可 以包括音频和/或视频呼叫内容。

根据本发明的实施方式，还可以在应用正在运行时部署第三阶 段，以便当网络条件改变并且总质量降低时进行检查和做出反应。 应用客户端可以如上所述周期性地重新执行协商阶段，使得能够重 新调谐网络节点。在Q-间隔头部中指示了能够用来执行这种重新协 商的间隔。

为了避免由于来自客户端的过多请求而导致的任何性能问题， 如果不满足Q-间隔要求，则服务器可以使用200OK响应来自动应 答。

根据本发明的实施方式，在IP/MPLS层级上可以根据DiffServ 来完成网络节点内部的资源供应。然后在协商阶段可以将转发等级 (Forwarding Class)改为用于应用目的的合适的值。可以通过在协 商的每个步骤中将HTTP业务移动到更高的转发等级来实现动态自 适应，而不是读取Q-HTTP头部中所包括的实际值。如前所述，当 满足所配置的最大重复时或者当质量参数(在应用看来)足够好时 该过程结束。

在网络看来，也可以定义不活动性定时器，以便在会话完成之 后将QoS配置文件恢复到它的默认设置。

其他网络元件可以使用质量头部实现质量约束，并且假设每个 元件已使用Q-HTTP头部带宽约束和延时(其通常意味着一些优先 策略)调谐了它自己的带宽。

在客户端浏览器上，为了提供默认配置，浏览器在浏览器设置 菜单中具有可配置的一组质量头部将会很好，使得这些质量头部能 够容易地出现在第一消息中。

在本技术发明之上可以设计不同的商业模型。例如，根据谁对 质量付费，应用服务器可以接受在第一消息中发送的希望的应用客 户端参数，或者强制使用服务器进行付费的参数。