无应用接收端参与的在发送端使用预订协议促进应用同步的制作方法

专利名称：无应用接收端参与的在发送端使用预订协议促进应用同步的制作方法
技术领域：
本发明涉及计算机网络，并且更具体地涉及在计算机网络中在没用应
用接收端参与的情况下，在发送端使用预订(reservation)协议促进应用 同步。
背景技术：
计算机网络是用于在诸如计算机之类的网络节点之间传送数据的互连 子网在地理上的分布集合。局域网(LAN)是这种子网的一个例子。网络 拓扑由通常经由一个或多个中间网络节点(诸如，路由器或交换机)彼此 通信的客户端节点的布置定义。如在这里使用的，客户端节点是被配置为 发起或终止在网络上的通信的网络节点。相反，中间网络节点是促进在客 户端节点之间路由数据的节点。网络节点之间的通信通常会受根据预定义 的协议交换离散数据包的影响。在此上下文中，协议由定义节点如何彼此 交互的规则集合组成。
在网络节点之间传送的数据包可包括固定大小的数据单元和/或可变大 小的数据帧。每个数据包通常包括由至少一个根据网络通信协议格式化的 网络报头预先考虑(封装)的"有效载荷"数据。网络报头包括使客户端 节点和中间节点能够经由计算机网络有效路由包的信息。通常，包的网络 报头至少包括数据链路(层2)报头和网间(层3)报头(internetwork header)，如开放式系统互连(OSI)参考模型所定义的。OSI参考模型通 常在由Radia Perlman于1999年9月发表的标题为"互联第二版 (Interconnections Second Edition)"的参考书的第1.1节中更详细地描 述，将其结合于此作为参考就好像完全在这里阐明。
在运转中，客户端节点可将数据包发送到中间网络节点的网络接口 。 其后，中间网络节点接收包并将包转发到其下一目的地。例如，中间网络节点可执行层2的交换功能，该功能用于基于包的数据链路报头的内容简 单地将包从一个网络接口重定向到另一个。可替换地，中间网络节点可执
行层3路由功能或转发判定，该功能或判定用于基于包的网间报头的内容
选择最适当的网络接口来转发包。
数据包用于在网络和子网上传送许多形式的信息，包括语音和视频信
息。例如，语音信息可根据IP语音协议(VoIP)来发送。VoIP指用于在 数据网络上从源节点向目的节点发送语音信息的一组技术。源和目的节点 采用语音代理，该语音代理将语音信息从其传统的电话形式转换为适于包 传输的形式。换言之，源节点的语音代理将语音信息编码、压縮、和封装 到多个数据包内，并且目的节点的语音代理执行补充的功能以解封装、解 压縮、和解码VoIP包。VoIP代理的例子包括IP电话、VoIP网关、某些 专用交换分机(PBX)、运行通信应用的个人计算机(PC)、提供语音网 关服务的网络设备等。而且，视频信息可通过类似方式根据本领域技术人 员公知的视频点播(VoD)标准来发送。例如，VoD内容服务器可将视频 数据流提供到一个或多个用户的"机顶盒"。具体地，VoIP和VoD的使 用是网络内的节点可操作的应用(例如，在应用层级)的例子。本领域技 术人员将理解，也可在网络节点处操作其它应用。
源节点(发送端)可被配置为在数据网络中向目的节点(接收端)传 送数据包的单向流或"数据流"。数据流(例如)可包括数据或语音/视频 信息。数据流是单向的，因为该数据流中的数据从发送端向接收端单向地 行进。从发送端接收数据包并向接收端发送数据包的中间网络节点的逻辑 行列定义了数据流的数据路径。数据流的数据路径中相比于第二节点更接 近接收端的第一节点被称为是第二节点的"下游"。同样，数据流的数据 路径中相比于第二节点更接近发送端的第一节点被称为是第二节点的"上 游"。
某些数据流与某个层级的服务质量(QoS)相关联。例如，数据流的 QoS可指定支持流所需的最小端到端等待时间或带宽要求。资源预订协议 (RSVP)是使源和目的节点能够"预订"必需的资源以根据流的所需 QoS建立数据流的网络控制协议。RSVP和路由协议结合工作，以(例如)预订沿源和目的节点之间的数据流的资源，以便建立数据流所要求的
QoS层级。RSVP在R. Braden等的Resource Reservation Protocol (RSVP) ， Request For Comments (RFC) 2205中定义，其结合于此作为 参考就好像完全在这里阐明。
在通常的布置中，发送端发送标识其本身并且指示数据流所需的带宽 的RSVP路径消息。路径消息跟随流的数据路径向接收端进发，并且每个 中间网络节点都可更新路径消息的可选"Adspec"对象。Adspec对象包含 关于数据流属性的信息等，例如可用服务、延迟、和带宽估计。可由发送 端或中间节点生成Adspec对象，并且当该Adspec对象从一个节点向另一 个节点行进时被修改。Adspec对象通告由上游的所有先前跳节点的属性组 成的可能的服务参数。即，到达的Adspec对象被与节点自己的参数和服 务条件结合，然后被转发到下一节点。接收端可使用Adspec信息来预测 端到端QoS,选择最适当的服务并且根据网络的当前可能性调节其QoS请 求。
接收端接收路径消息并且可考虑路径消息中的可选Adspec对象的内 容来确定它将为流生成的预订请求的细节。接收端以RSVP预订请求的形 式生成"用于资源的请求"(Resv消息)，其中，该RSVP预订请求逐 跳行进回发送端。在Resv消息内是"FlowSpec"对象，其包含来自发送 端的峰值预期通信量(traffic)(例如，带宽)的指示(Tspec)、和将预 订的所要求通信量的值(Rspec)。在每跳处，相应的中间网络节点留出 (分配)足够的资源来为期望的数据流提供所要求的带宽。从而使得这些 分配的资源对于数据流来说可用，进而使得流的数据包能得到适当的QoS 处理(即，"接纳(admit)"数据流)。
如果没有足够的资源可用，则中间网络节点可"拒绝"Resv消息 (即，不继续转发它)，生成预订错误(ResvErr)消息，并且通过流将 ResvErr消息向下游转发到接收端。接收端最后接收ResvErr消息并且断定 预订已失败。其Resv消息己被拒绝的接收端可尝试通过发送另一请求较 少带宽的Resv消息来获得较少的资源，或者接收端可随后重新尝试通过 重发送另一 Resv消息来获得资源。发送端不受该过程影响，并且它们继续发送路径消息以刷新它们的状态。具体地，通常由沿着发送端和接收端
之间的路径的中间节点逐跳发送和处理PathErr和ResvErr消息，如本领域 技术人员将会理解的。
RSVP信令可用在发送端和接收端之间，以便为要求QoS保证的特定 应用(例如，VoIP、 VoD等)执行资源预订。在该情况下，必须的是 RSVP预订建立紧紧地与应用同步。例如，直到完成RSVP预订之前， VoIP呼叫都不应当"响铃"所呼叫的电话(接收端)，以便避免"虚象" 响铃，如本领域技术人员将会理解的。通常，与RSVP预订的应用同步结 合了应用和预订两者的端点(即，发送端和接收端)的合作，因为应用和 预订的信令中涉及到了这两个端点。实例应用同步在由名为"Update to the session Initiation Protocol (SIP) preconditions Framework"的RFC 4032更 新的名为 "Integration of Resource Management and Session Initiation Protocol (SIP)"的RFC 3312中详细描述，其两者结合于此作为参考就 好像完全在这里阐明。
在应用同步的典型例子中，例如VoIP，发送端可希望发起到接收端的 应用会话(例如，呼叫)，对于该会话需要预订资源以确保会话的QoS。 因此，发送端通过向接收端发送"要约"并且在要约内包括在可完成会话 建立之前应该预订资源的指示(即，资源预订是"前提")来请求会话。 然后，接收端可响应于要约并且提供关于会话的信息细节，但是可将会话 建立中断，直到完成资源预订。然后，发送端可触发预订建立(例如，通 过发送RSVP路径消息)。接收端可应答资源预订请求(例如，通过发送 RSVP Resv消息)。 一旦发送端接收到指示已预订所请求的资源的应答， 发送端在应用层级信令向接收端确认前提。然后，接收端可恢复应用会话 的建立(例如，向发送端确认建立，使它也可建立会话)。通过该方式， 已成功同步应用和资源预订(即，尚未建立应用会话-并且例如，尚未响铃 远程电话-没有首先确认已预订所请求的资源)。
然而，在某些网络环境中，接收端没有被配置为进行资源预订(例如 RSVP)，或者不能参与资源预订。在许多这些情况下，可从接收端 ("应用接收端")向上游定位预订接收端代理。这里，预订接收端代理("预订接收端")代表应用接收端执行资源预订信令。同样地，应用接 收端不涉及资源预订。因此，应用接收端可不参与资源预订和应用建立之 间的同步。而且，由于预订接收端不是应用的端点，所以它也可不参与资 源预订和应用建立之间的同步。具体地，预订接收端代理可不知道应用层 级信令，并且因而可不能有效地与发送端传送同步消息。例如，由资源预 订产生的任何接纳拒绝或错误通常被发送到预订接收端。根据预订协议
(例如，RSVP)，可不向发送端通知失败。常规地，应用接收端会向发
送端通知失败，而如上所述，预订接收端和应用接收端是独立的节点，所 以可能不是这种情况(例如，或可能)。那么，对于发送端来说，使用预 订协议单独同步应用将是有益的。
可参考VoD应用示出预订接收端代理的例子。VoD内容提供者可希 望防止VoD内容分发到机顶盒("应用接收端")，除非预订了适当的资 源(例如，用于接纳控制)，如本领域技术人员将会理解的。然而，许多 机顶盒可能没有被配置为进行资源预订(RSVP)，并且可能难于另外 "升级"盒的配置。可从机顶盒向上游放置预订接收端代理，以处理资源 预订，但是如上所述，存在与和预定接收端代理同步的应用相关联的问 题。
已经提出了用于在没有应用接收端参与的发送端处的应用同步的各种 方案。 一个这种方案由尝试"猜测"预订状态的发送端组成。例如，在发 送端己发送资源预订请求(例如，路径消息)的情况下，如果发送端在可 配置长度的时间内尚未接收到响应(例如，Resv消息)，则发送端可假设 预订已失败。尽管该方案考虑到了应用同步，但是它可能很慢(即，基于 足够宣布失败预订的可配置长度的时间)，并且可能未解决初始预订建立 之后的失败(例如，可响应于网络元件故障随后拒绝建立的预订)，如本 领域技术人将会理解的。
另一提出的方案是让预定接收端代理生成"假的"路径请求错误消息 (例如，PathErr)，以响应于接收预订请求错误消息(例如，ResvErr)而 向发送端发送。通过该方式，"假的"路径请求错误消息("假的"，是 因为对于预订接收端来说响应于预订失败向发送端发送路径请求错误消息不是常规的)可向发送端通知预订失败。该方法还受到各种限制，包括 (例如)慢响应时间。例如，当预订接收端和发送端之间的中间网络节点 检测到预订错误时，预订错误消息向下游被发送到预订接收端并且被逐跳 处理。然后，预订接收端可生成"假的"路径请求错误消息，然后该"假 的"路径请求错误消息向上游被发送到发送端并且被逐跳处理。该逐跳处 理可能是耗时的，因此该方案不是最优的回答。而且，该方案可能缺乏可 伸縮性，因为在出现大的网络错误的情况下，预订接收端代理可被成千上 万条错误消息淹没，从而导致处理浪涌和附加延迟。
因为到预订协议的紧紧应用同步是必需的(例如，以中断相应的数据 流等)，所以如本领域技术人员将会理解的，最小化与向发送端通知预订 失败相关联的延迟是关键的。 一种最小化关于错误通知的延迟的方法是使
用快速失败通知或者"通知"特征，如在日期注明为2003年1月的RFC 3473 ，标题为Generalized Multi-Protocol Label Switching ( GMPLS ) Signaling Resource Reservation Protocol-Traffic Engineering ( RSVP-TE) Extensions中描述的，其全部内容结合于此作为参考。具体地，请求(例 如，通知请求)可包括在路径请求或预订请求消息内，该路径请求或预订 请求消息用于请求检测错误的中间节点连同常规的错误消息一起发送快速 失败通知(例如，分别为PathErr和ResvErr)。例如，预订接收端可请求 快速预订失败通知(例如，用于ResvErr)被生成并且响应于预订请求错 误而被发送到预订接收端(即，不必由其它中间节点处理)。而且，发送 端可请求快速路径失败通知(例如，用于PathErr)被生成并且响应于路径 请求错误而被发送到发送端。
尽管快速失败通知可加速向预订接收端(例如，预订接收端代理)通 知预订失败，但是预订失败通知仍然被寻址到预订接收端并且被其处理， 所以它在向发送端提供失败通知方面没有帮助。因此，仍存在对于在发送 端处紧紧且有效地将应用同步到预订协议的技术的需求。具体地，仍存在 对于在应用层级信令和预订层级信令在不同的端点处(即，在应用接收端 和预订接收端)终止的情况下，(例如)在没有应用接收端参与的情况下 的同步的需求。

发明内容
本发明涉及用于在计算机网络中在没有应用接收端参与的情况下，在 发送端使用预订协议促进应用同步的技术。根据该新颖技术，发送端向预
订接收端发送路径请求消息(例如，使用资源预订协议，RSVP消息)并 且可包括用于将被返回到发送端的快速路径失败通知的请求。预订接收端 (例如，应用接收端上游的预订接收端代理)接收路径请求，并且作为响 应向发送端返回预订请求消息，其中，该预定请求消息包括用于也将被发 送到发送端的快速预订失败通知的请求(例如，响应于检测到快速路径失 败通知请求、本地策略/配置等)。在路径请求或预订请求期间发送端和预 订接收端之间的中间节点检测到错误的情况下，中间节点向发送端发送相 应的快速失败通知。然后，发送端可基于对快速失败通知或成功的预订请 求消息的接收，(例如)使用预订协议同步应用。
有利地，该新颖技术在计算机网络中没有应用接收端参与的情况下， 在发送端使用预订协议促进了应用同步。通过将快速预订失败通知导向发 送端而不是预订接收端，该新颖技术允许发送端使用预订协议来单独同步 应用。具体地，在应用接收端/端点不同于预订接收端/端点的情况下，例 如在使用预订接收端代理的情况下，在发送端的应用同步是可能的。而 且，(例如)由于必须转发失败通知以到达发送端的节点数量更少，所以 可减少中间节点对失败通知的处理。此外，该新颖技术的动态性质减轻了 对麻烦的人工配置的需要。


通过结合附图参考以下描述，可更好地理解本发明的以上和其它优
点，在附图中，相同的参考标号表示相同或功能上相似的元件，其中
图1是可有利地用于本发明的示例性计算机网络的示意性框图2是可有利地用于本发明的示例性节点的示意性框图3是可有利地用于本发明的路径请求消息的部分的示意性框图4是可有利地用于本发明的预订请求消息的部分的示意性框图；图5是可有利地用于本发明的错误消息的示意性框图； 图6是可有利地用于本发明的快速失败通知消息的示意性框图； 图7是与资源预订协议相关联的各种功能块的示意性框图； 图8是表示根据本发明的应用和预订信令交换的同步的说明性示图； 图9是示出根据本发明的用于在发送端使用预订协议促进应用同步的 过程的流程图。
具体实施例方式
图1是可有利地用于本发明的示例性计算机网络100的示意性框图。
网络100包括多个互连网络节点，例如，发送端节点110 (例如，内容服 务器)、预订接收端节点130 (例如，代理)、以及一个或多个应用接收 端节点140A-C。说明性地，发送端110和预订接收端130可(例如)在广 域网(WAN)链路(或局域网"LAN"链路、点到点链路、无线LAN 等)上通过一个或多个中间节点120A-C互连，以形成网络100。本领域 技术人员将会理解，任何数目的节点、链路等都可用在计算机网络100中 并且可以多种方式连接，并且这里示出的视图是为了简明。
图2是示例性节点200的示意性框图，其中，说明性地是可有利地将 路由器作为端点(例如，发送端和/或接收端节点)或中间节点用于本发 明。节点包括通过系统总线250互连的多个网络接口 210、处理器220、 和存储器240。网络接口 210包含机械的、电的、和信令电路，用于在耦 合到网络100的物理链路上传送数据。网络接口可被配置为使用多种不同 的通信协议利用互连的网络节点发送和/或接收数据，其中，所述通信协议 包括TCP/IP、 UDP、 ATM、 RSVP、同步光纤网(SONET)、无线协议、 帧中继、以太网、光纤分布式数据接口 (FDDI)等。
存储器240包括可被处理器220和网络接口 210寻址的多个存储位 置，用于存储与本发明相关联的软件程序和数据结构。处理器220可包括 适于执行软件程序和处理数据结构的必要元件或逻辑。路由器操作系统 242 (例如，思科系统公司(Cisco System, Inc.)的互联网操作系统或 IOSTM)(其部分通常驻留在存储器240中并且由处理器执行)通过调用支持在路由器上执行的软件过程和/或服务的网络操作来在功能上组织路由
器。这些软件过程和/或服务可包括应用服务244、通信量控制服务246、 路由服务247、和RSVP服务249。本领域技术人员将明白的是，包括各 种计算机可读介质的其它处理器和存储装置可用于存储和执行关于这里描 述的本发明技术的程序指令。
路由服务247包含由处理器220执行的计算机可执行指令，以执行由 诸如IGP (例如，OSPF禾n IS-IS) 、 IP、 BGP等的一个或多个路由协议所 提供的功能。这些功能可被配置为管理包含(例如)用于做出转发判定的 数据的转发信息数据库(未示出)。路由服务247还可执行涉及虚拟路由 协议的功能，例如本领域技术人员将会理解的维持VRF实例(未示出)。
应用服务244包含由处理器220执行的计算机可执行指令，以执行由 诸如IP语音(VoIP)、视频点播(VoD)等的一个或多个应用所提供的功 能，如本领域技术人员将会理解的。注意，这些功能可被配置为与预订协 议服务(例如，RSVP服务249)合作，例如根据这里描述的本发明。
根据本发明，RSVP服务249包含用于实现RSVP和处理RSVP消息 的计算机可执行指令。RSVP在Request for Comments (RFC) 2205，标题 为Resource Reservation Protocol ( RSVP )， 和RFC 3473 ，标题为 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extension中描述， 二者都结合在了上面。
根据RSVP，要建立诸如发送端IIO和预订接收端130之类的端点之 间的数据流，发送端可沿着流的数据路径(例如，单播路由)向下游发送 RSVP路径(路径)消息到接收端，以标识发送端并指示(例如)容纳数 据流所需的带宽以及数据流的其它属性。路径消息可包含关于数据流的各 种信息，例如，数据流的通信量特性。
图3是可有利地用于本发明的路径请求(例如，RSVP路径)消息 300的部分的示意性框图。路径消息300包含公用报头310、发送端模板 对象320、通信量说明(Tspec)对象330、先前跳对象340、和所通告的 流说明(Adspec)对象350等。发送端模板对象320保存关于发送端的信息(例如，与发送端相关联的地址和端口)，而Tspec对象330保存(例 如)定义发送端和接收端之间的数据流的各种通信量特性的信息。先前跳 对象340保存涉及发送端和接收端之间的流中的先前跳(节点)的信息。 Adspec对象350包含关于数据流的特性的信息(诸如，可用服务、延迟、 和带宽估计)等。Adspec对象可由发送端或中间节点生成，并且当它们从 一个节点行进到另一个节点时被修改，用于通告由上游的所有先前跳节点 的属性构成的可能的服务参数。
根据以上结合的RFC 3473，通知请求对象360也可包括在路径消息 300内。通知请求对象360可由发送端使用，例如通过将发送端地址包括 在地址字段365中，来在中间节点处的路径状态失败的情况下请求将被发 送到发送端的快速失败通知。因此，在这个意义上，通知请求对象可被称 为"快速失败通知请求"(具体地，"快速路径失败通知请求")。下面 将参考图6的通知消息600更详细地描述快速失败通知。
根据RSVP，预订接收端通过用预订请求(Resv)消息响应发送端的 路径消息来建立用于发送端和接收端之间的数据流的新预订。预订请求消 息沿着从接收端到发送端的流向上游逐跳行进。预订请求消息包含沿着流 的中间节点使用的信息，以为发送端和接收端之间的数据流预订资源。
图4是可有利地用于本发明的预订请求(例如，RSVPResv)消息 400的部分的示意性框图。Resv消息400包含公用报头410、会话对象 420、过滤器说明(filter spec)对象430、和流说明(flowspec)对象 440。会话对象420可包含接收端的地址信息，而过滤器说明对象430可 包含发送端的地址信息。而且，流说明对象440可包含定义与新预订相关 联的各种通信量特性的信息。应当注意，预定请求消息中可以包括(例 如)由RSVP定义的其它对象(例如，策略数据对象、预订确认对象)。 而且，通知请求对象450可包括在Resv消息400内，类似于上面的通知请 求对象360。然而，这里，Resv消息400请求预订状态的快速失败通知 ("快速预订失败通知")，并且地址455常规地包含发送请求的预订接 收端的地址。
如果发送端和接收端之间的流中的中间节点获得了用于新预订的路径消息300或Resv消息400并且不能同意请求(例如，预订用于新预订的足 够资源等)，则中间节点分别生成路径或预订错误(PathErr或ResvErr) 消息并且将其转发到接收端。图5是可有利地用于本发明的(例如)作为 PathErr或ResvErr消息的错误消息500的示意性框图。
错误消息500部分地包括公用报头510、会话对象520、和错误说明 对象530。会话对象520标识消息的目的地址(发送端或接收端)等。错 误说明对象530包含错误节点地址字段535、错误代码字段537、和错误 值字段539等。错误节点地址字段535保存表示流中检测到错误(例如， 资源不足)的节点的地址(例如，IP地址)的值。错误代码字段537保存 描述错误的值，并且错误值字段539保存表示关于错误的附加信息的值。
除了在检测到失败后发送的错误消息500，并且响应于用于快速失败 通知的请求(例如，分别在路径消息300或Resv消息400中的通知请求对 象360或450)，中间节点还生成快速失败通知消息并且将其发送到各地 址字段(365或455)内包含的地址。快速失败通知或通知消息包含向发 送端或接收端指示已出现失败的信息。图6是可有利地用于本发明的快速 失败通知(通知)消息600的示意性框图。
通知消息600包括公用报头610和错误说明对象620。应当注意，通 知消息600中可包括其它对象和信息(例如，会话列表、消息ID等)。 错误说明对象620包含标识失败的信息，类似于上面图5中的PathErr或 ResvErr消息500的错误说明对象530。如上所述，使用快速失败通知消息 避免了中间节点对错误消息500的每跳处理，并且允许端点(例如，发送 端或预订接收端)快速获得相应的失败通知。具体地，通知消息600被发 送到网络层协议(例如，IP)报头605的目的地址字段615内包含的地 址，其中，该地址是从快速失败通知请求的相应地址字段365和455中取 出的。例如，常规地，如果发送端已请求将快速路径失败通知发送到其地 址(地址字段365)，则通知消息的目的地址615是发送端的地址。而且 常规地，如果预订接收端已请求将快速预订失败通知发送到其地址(地址 字段455)，则通知消息的目的地址615是预订接收端的地址。下面进一 步详细描述根据本发明的地址字段365、 455、和615的使用。图7是处理(例如)RSVP消息、以及实现用于端节点(例如，发送 端110和预订接收端130)和中间节点120中的数据流的服务质量 (QoS)的过程中涉及到的各种功能块的示意性框图。端节点110/130包 括与RSVP过程723 (例如，RSVP服务249)和分类器725接口的应用 722 (例如，应用服务244)。另外，端节点110/130包括包调度器726、 策略控制724、和接纳控制727。应用722可发布用于与应用722相关联 的数据流的各种QoS请求。RSVP过程723处理请求，并且响应于请求生 成和发布各种RSVP消息(例如，路径消息、Resv消息)。这些消息可用 于在RSVP层级与中间节点120中的RSVP过程733通信。
用于端节点110/130上的数据流的QoS由统称为"通信量控制"(例 如，通信量控制服务246)的功能实现。这些功能包括分类器725、包调 度器726、和接纳控制727。分类器725确定用于端节点110/130发布的包 的QoS等级。包调度器726确定所发布的包何时从端节点110/130被转发 到中间节点120。接纳控制功能727确定端节点是否包含足够的资源以分 配给与数据流相关联的新预订。
假设节点110/130是发送端110和接收端130之间的流上的预订接收 端130，并且应用722已接收到来自发送端的路径消息。还假设，响应于 路径消息，应用722通过向RSVP过程723发布阐明用于数据流的QoS需 求的请求，来建立用于发送端和接收端之间的数据流的新预订。RSVP过 程723结合策略控制724和接纳控制727，用于确定(检查)是否允许应 用建立新预订，并且如果是，则确定在端节点110/130上是否存在足够的 资源来满足新预订的需求(QoS)。如果两个检查都成功，则在包分类器 725和包调度器726中设置各种参数，以预订端节点110/130上的足够的资 源，以便获得用于新预订的所需的QoS。此外，RSVP过程723可生成经 由中间节点120被转发到发送端的各种RSVP消息(例如，Resv消息)。
中间节点120同样包含RSVP过程733、策略控制功能734、分类器 735、包调度器736、和接纳控制功能737。另外，中间节点包含路由过程 732，该路由过程可被配置为实现各种路由协议(例如，OSPF和ISIS) 。RSVP过程733和策略控制功能734说明性地包含在中间节点的RSVP服务249中。分类器735、包调度器736、和接纳控制737说明性地 包含在中间节点的通信量控制服务246中。
RSVP过程733处理中间节点120获得的RSVP消息(例如，Resv消 息)。该处理可包括将请求传递到策略控制功能734和接纳控制功能 737，以确定(检查)是否允许发布消息的节点(例如，端节点110/130) 进行预订并且确定是否有足够的资源可用于预订。如果两个检查都成功， 则可在中间节点的包分类器735和包调度器736中设置各种参数，以得到 所请求的QoS。此外，中间节点120可将获得的RSVP消息转发到与各种 预订相关联的流中的下一个中间节点。应当注意，图7中示出的功能块可 通过硬件、软件、固件、或他们的某些组合来实现。
本发明涉及用于在计算机网络中在没有应用接收端参与的情况下，在 发送端使用预订协议促进应用同步的技术。根据该新颖技术，发送端将路 径请求消息(例如，使用RSVP消息)发送到预订接收端，并且可包括用 于将被返回到发送端的快速路径失败通知的请求。预订接收端(例如，应 用接收端上游的预订接收端代理)接收路径请求，并且作为响应向发送端 返回预订请求消息，其中，该预定请求消息包括用于也将被发送到发送端 的快速预订失败通知的请求(例如，响应于检测到快速路径失败通知请 求、本地策略/配置等)。在发送端和预订接收端之间的中间节点在路径请 求或预订请求期间检测到错误的情况下，中间节点向发送端发送相应的快 速失败通知。然后，发送端可基于对快速失败通知或成功的预订请求消息 的接收，(例如)使用预订协议同步应用。
根据本发明，发送端110 (例如，既是预订发送端/端点也是应用发送 端/端点的发送端)被配置为与一个或多个应用接收端/端点140 (即，在应 用层级上)和一个或多个预订接收端/端点130 (即，在预订层级上)通 信。说明性地，如图1中所示，应用和预订接收端可被实现为独立节点。 然而，本领域技术人员将理解，两个接收端可被实现在单个节点内，因此 本发明仍可有利地被使用。
发送端IIO和应用接收端140可希望建立应用会话，诸如，VoIP呼叫 或VoD会话(例如，在发送端是VoD内容服务器的情况下)，如本领域技术人员将会理解的。作为响应，发送端no可生成路径请求消息(例 如，RSVP路径消息300)，以便建立到应用接收端140的数据流(流) 路径。路径请求可指示各种前提或约束，例如，对带宽预订的需要等。在 要求紧密同步的情况下，例如根据本发明，发送端110可被配置为(例 如)通过将发送端的地址(例如，IPv4或IPv6地址)放置在地址字段365 内，来包括用于将被返回到发送端的快速路径失败通知的请求(例如，通 知请求360)。然后，路径请求可沿着中间节点120朝向应用接收端140 的路径逐跳转发。在路径请求消息传输期间的任何检测到的失败(例如， 路径状态错误)都可由中间节点120以常规方式来处理。换言之，除了直 接发送到发送端的所请求的快速路径失败通知消息(通知消息600)，路 径错误消息(PathErr 500)可被生成并且被逐跳发送到发送端110。另 外，路径消息可朝向应用接收端140继续。
在沿着路径在应用接收端140之前存在预订接收端代理130的情况 下，例如在应用接收端140没有被配置为用于预订协议信令(例如， RSVP)的情况下，代理作为预订接收端/端点130截取路径请求消息。如 果没有代理，那么应用接收端140也可以是预订接收端/端点。因此，发送 端110可以知道或不知道应用接收端140上游的预订接收端代理130的存 在，并且可简单地尝试将预订协议信令消息转发到应用接收端140 (即， 假设它也是预订接收端130)，如本领域技术人员将会理解的。
响应于所接收的路径请求消息(路径消息300)，预订接收端130说 明性地确定是否包括快速路径失败通知请求(通知请求360)。如果没 有，则预订接收端(例如)通过返回将被发送到发送端的没有快速预订失 败请求(通知请求450)的预订请求消息(Resv消息400)来以常规方式 继续。(本领域技术人员将理解，预订接收端还可包括以常规方式寻址到 其本身的通知请求450。)然而，如果包括了快速路径失败通知请求，则 预订接收端130生成具有快速预订失败通知请求450的预订请求消息 400。可替换地，预订接收端130可被配置为响应于本领域技术人员将会 理解的其它触发器(例如，本地策略/配置总是包括快速预订失败通知请 求、具有某些优先级层级的路径请求300、补丁请求内的其它对象等)来生成具有快速预订失败通知请求450的预订请求消息400。快速路径失败 通知请求仅仅是这种触发器的一个说明性示例，并且本领域技术人员将会 理解，根据本发明可有利地使用其它触发器。
在预订接收端130是一个或多个应用接收端140的代理的情况下，预 订接收端可被配置为知道它是代理。因此，因为代理的存在，代理确定可 不向最终目的地(即，应用接收端)告知下游通知，特别是预订失败通知 (例如，快速或常规的)。同样，代理可确定错误消息应当被发送到发送 端以被适当地处理(即，因为代理不能发信号给应用层级的发送端)。
具体地，RFC 3473 (在上面结合描述通知请求)不阻止预订接收端 (例如，代理或不是代理)在通知请求450的地址字段455内插入除了它 自己的地址之外的地址。因此，本发明以新颖方式利用了这个特征。具体 地，预订接收端检查所接收的快速路径失败通知请求360的地址字段365 的内容(即，地址)，并且将该地址插入到快速预订失败请求的地址字段 455内。因为发送端IIO被配置为将其地址插入到地址字段365内，所以 快速预订失败请求450相应地包括发送端的地址。
预订接收端130沿着中间节点120的路径朝发送端IIO转发预订请求 消息400。在没有检测到预订错误的情况下，成功的预订请求最终到达发 送端110，并且应用可成功地与应用接收端140 (例如，通过应用层级信 令，如本领域技术人员将会理解的)同步。然而，在中间节点120检测到 失败(例如，预定状态错误)的情况下，中间节点以常规方式来处理失 败。换言之，如果预订请求消息400中没有用于快速预订失败通知的请 求，则中间节点120向预订接收端130返回预订错误消息(ResvErr 500)。另一方面，如果存在用于快速失败通知的请求(例如，通知请求 对象450)，则中间节点120生成快速预订失败通知(通知消息600)并 且将其发送到所请求的地址(例如，地址字段455)。然而，根据本发 明，所请求的地址已经被配置为发送端110的地址，并且因此，快速预订 失败通知从而被发送到发送端。
本发明通过在包内插入错误代码并且将包直接发送到发送端(即，到 发送端的快速预订失败通知)，避免了与中间节点120对常规的预订错误消息(ResvErr消息500)的逐跳接收和处理相关联的错误处理和信令延 迟。本发明还避免了与预订接收端130进行的预订错误处理相关联的延 迟，因此在应用和预订接收端是或不是相同接收端的两种情况下都可有利 地应用(即，更快的同步响应)。例如，不是首先将错误发送到单个应用/ 预订接收端，本发明绕过了由接收端进行的任何处理并且将快速失败通知 直接发送到发送端110。具体地，除了常规路径或预订错误消息，可发送 快速失败通知，而不是代替常规的错误消息。具体地，中间节点120和预 订接收端130还可变得通过预订错误消息(ResvErr 500)获知失败，即使 发送端正在接收快速失败通知。这是重要的，从而使得中间节点120和预 订接收端130可移除用于所请求的数据流路径的任何先前预订的状态。
通过将快速预订失败通知600直接发送到发送端110，(例如)尤其 是在预订接收端130不是应用接收端140的情况下，本发明对应用到预订 协议的紧密同步留有余地。具体地，使得发送端110以更快、更有效的方 式获知预订失败，并且使得发送端110可快速确定应用是不成功的。具体 地，因为快速预订失败通知600可包含预订类型错误代码消息(例如，在 错误说明对象620中)，所以发送端IIO可被配置为解释这些错误代码消 息(通常发送到预订接收端)，以便遵照本发明。可替换地，发送端110 可简单地被配置为检测快速预订失败通知600的接收，而不解释错误代码 消息620，并且确定导致了不成功的应用同步。
图8是表示根据本发明的应用和预订信令交换的同步的说明性示图 800。简言之，该示图的顶部示出了成功的应用会话建立。例如，发送端 110和应用接收端140可希望建立请求应用(例如，VoIP呼叫或VoD会 话)。然后，发送端110可向预订接收端130发送具有用于快速路径失败 通知360的说明性请求("具有通知")的路径消息300。具体地，如上 所述的其它触发器(策略/配置等)也可根据本发明来使用。预订接收端 130向发送端110返回具有如本文中所述的用于也将被发送到发送端的快 速预订失败通知450的相应请求的Resv消息400。如果没有出现失败，则 发送端使用预订协议同步成功的应用，并且应用会话可在发送端110和应 用接收端140之间建立。
23然而，该示图的底部示出了不成功的应用会话建立。这里，例如，在
接收到Resv消息400时，中间节点120己检测到预订失败(例如，接纳控 制失败)。作为所包括的快速预订失败通知请求450的结果，中间节点生 成快速预订失败通知600并且将其发送到发送端，即，根据本发明的根据 请求450内包含的地址455。如上所述，ResvErr消息500也可从中间节点 被返回到预订接收端(未输出)。然后，发送端110可将失败的应用会话 同步到应用接收端140，并且应用会话没有被建立(即，是不成功的)。
图9是示出根据本发明的用于在发送端使用预订协议促进应用同步的 过程的流程图。过程900在步骤905开始，并且继续到步骤910，其中在 步骤910，发送端(例如，发送端110)可在路径请求消息(例如，RSVP 路径消息300)内插入用于将被返回到发送端的快速路径失败通知360的 请求。在步骤915，发送端将路径请求消息发送到预订接收端(例如，预 订接收端代理130)。在步骤920中，发送端和预订接收端之间的一个或 多个中间节点(例如，节点120A-C)接收并处理路径请求消息。在步骤 925，只要每个中间节点都确定不存在路径错误，则在步骤930，预订接收 端接收路径请求消息。然后，在步骤935中，预订接收端可从路径请求内 检测到发送端已请求了快速路径失败通知。具体地，在预订接收端没有检 测到所请求的快速失败通知或其它触发器(步骤未示出)的情况下，可以 常规方式来处理失败通知，如本领域技术人员将会理解的。
响应于在步骤935中检测到了用于快速路径失败通知的请求，在步骤 940，预订接收端在预订请求消息(例如，RSVP Resv消息400)内插入用 于也将被发送到发送端的快速预订失败通知450的请求。然而，如上所 述，本领域技术人员将会理解，预订接收端可以可替换地被配置为响应于 其它触发器(例如，策略/配置等)插入用于快速预订失败通知450的请 求。在步骤945，预订接收端向发送端发送预订请求消息，在步骤950， 该预定请求消息可沿着路线由中间节点接收和处理。在步骤955，如果在 中间节点处没有检测到预订错误，那么在步骤960，发送端最终接收了成 功的预订请求消息。在该情况下，在步骤965中，发送端可与应用接收端 (例如，应用接收端140A)同步成功的应用，并且该过程在步骤999结束。
在分别在步骤925或955中，任何一个中间节点检测到路径错误或预 订错误的情况下，相应的快速失败通知被发送到发送端。例如，如果检测 到了路径错误，则在步骤970中，中间节点发送快速路径失败通知，而如 果检测到了预订错误，则在步骤980中，发送快速预订失败通知。具体 地，如本领域技术人员将会理解的，在步骤975中，中间节点可向发送端 发送常规的路径错误消息，并且在步骤985中，中间节点可向预订接收端 发送预订错误消息，如上所述。 一旦发送，则在步骤990中，发送端接收 快速失败通知，并且在步骤995中，发送端与应用接收端同步不成功的应 用，如上所述。该过程在步骤999结束。
有利地，该新颖技术在计算机网络中在没有应用接收端参与的情况 下，在发送端使用预订协议促进了应用同步。通过将快速预订失败通知导 向发送端而不是预订接收端，该新颖技术允许发送端使用预订协议来单独 同步应用。具体地，在应用接收端/端点不同于预订接收端/端点的情况 下，例如在使用预订接收端代理的情况下，在发送端的应用同步是可能 的。而且，(例如)由于必须转发失败通知以到达发送端的节点更少，所 以可减少中间节点对失败通知的处理。此外，该新颖技术的动态性质减轻 了对麻烦的人工配置的需要。
尽管示出和描述了在计算机网络中在没有应用接收端参与的情况下， 在发送端使用预订协议促进应用同步的说明性实施例，但应该理解，在落 入本发明的精神和范围的条件下，可进行各种其它适应和修改。例如，这 里示出并描述了使用RSVP作为预订协议信令交换的本发明。然而，本发 明在其更宽广的意义上并不限于此，并且实际上可用于本领域技术人员将 理解的其它预订信令交换。而且，尽管上面的说明描述了在发送端执行用 于应用和预订层级两者的技术，但是本发明也可有利地用于应用发送端和 发送端代理，如本领域技术人员也将会理解的。例如，发送端代理可请求 将被发送到单个应用/预留接收端的快速失败通知(例如，用于路径请求失 败或预订失败)，从而可以与应用发送端同步应用。可替换地，应用发送 端和发送端代理可被配置为响应于发送端代理对如上所述的快速预订失败通知的接收来交换同步消息。
具体地，本领域技术人员将会明白，可以明白地预期预订接收端130 可以可替换地被配置为发送快速失败通知，相反于描述为上面的无效方案
的"假的"PathErr消息。例如， 一旦预订接收端接收到了常规的快速预订 失败通知，而不是必须沿着中间节点被逐跳处理的假PathErr消息，预订 接收端可向发送端发送快速路径或快速预订失败通知消息，以避免相关联 的延迟。然而，尽管向发送端提供了快速失败通知，但该方案仍然无效 率。具体地，快速失败通知必须首先行进到预订接收端，然后该预定接收 端必须处理该通知，并且然后该快速失败通知必须被发送到发送端。因 此，本领域技术人员将理解，尽管简要提出的方案是可行的，但它不像这 里描述的用于本发明的技术一样有效。
前述描述是针对本发明的特定实施例的。然而，很明显，可对所述实 施例做出各种变化和修改，并获得它们的某些或所有优点。例如，可以明 白地预期，本发明的教导可实现为包括具有在计算机上执行的程序指令的 计算机可读介质的软件、硬件、固件、或他们的组合。而且，可生成电磁 信号，以(例如)在无线数据链路或数据网络(例如，因特网)上传送实 现本发明的多个方面的计算机可执行指令。因此，仅通过示例的方式进行 描述，并且本描述不用于限制本发明的范围。因此，所附权利要求的目的 在于覆盖落入本发明的真实精神和范围内的所有这些变化和修改。
权利要求
1.一种用于在计算机网络中在没有应用接收端参与的情况下，在发送端使用预订协议促进应用同步的方法，所述方法包括从所述发送端向预订接收端发送路径请求消息；在所述预订接收端接收所述路径请求；作为响应，从所述预订接收端向所述发送端返回预订请求消息，所述预订请求包括用于发送到所述发送端的快速预订失败通知的请求；在所述预订请求期间，在所述发送端和预订接收端之间的中间节点处检测错误；以及作为响应，从所述中间节点向所述发送端发送快速预订失败通知。
2. 根据权利要求1所述的方法，还包括基于在所述发送端对所述快速失败通知或者成功预订请求消息的接 收，使用所述预订协议来同步所述应用。
3. 根据权利要求l所述的方法，还包括从所述发送端向所述预订接收端发送所述路径请求消息，所述路径请求包括用于返回到所述发送端的快速路径失败通知的请求；在所述预订接收端检测所述路径请求内的所述快速失败通知请求；以及响应于在所述路径请求内检测到所述快速失败通知请求，从所述预订 接收端向所述发送端返回所述预订请求消息，所述预订请求消息包括用于 发送到所述发送端的快速预订失败通知的请求。
4. 根据权利要求3所述的方法，其中所述路径请求消息和预订请求 消息被实现为资源预订协议(RSVP)信令消息。
5. 根据权利要求4所述的方法，还包括利用RSVP信令消息的通知特性来请求快速失败通知。
6. 根据权利要求3所述的方法，还包括由所述发送端在用于所述路径请求的快速预订失败通知的请求内插入 所述发送端的地址，以请求将所述快速路径失败通知返回到所述发送端。
7. 根据权利要求3所述的方法，还包括由所述发送端在用于所述路径请求的快速预订失败通知的请求内插入 地址，以请求将所述快速路径失败通知发送到该地址；以及由所述预订接收端在用于所述预订请求的快速预订失败通知的请求内 插入用于所述路径请求的快速预订失败通知的请求的地址，以请求将所述 快速预订失败通知发送到该地址。
8. 根据权利要求1所述的方法，还包括由所述预订接收端在用于所述预订请求的快速预订失败通知的请求内 插入所述发送端的地址，以请求将所述快速预订失败通知发送到所述发送 端。
9. 根据权利要求1所述的方法，其中所述预订接收端是所述应用接 收端上游的预订接收端代理。
10. 根据权利要求1所述的方法，还包括从所述中间节点向所述发送端发送具有预订错误代码的快速预订失败 通知；以及在所述发送端解释所述预订错误代码。
11. 根据权利要求1所述的方法，还包括响应于在所述预订期间检测到错误，从所述中间节点向所述预订接收 端发送常规预订失败通知。
12. 根据权利要求1所述的方法，其中所述预订接收端和所述应用接 收端是同一接收端。
13. 根据权利要求1所述的方法，其中所述发送端是内容服务器。
14. 根据权利要求13所述的方法，其中所述内容服务器是视频点播 (VoD)服务器。
15. 根据权利要求14所述的方法，其中所述应用接收端是机顶盒。
16. 根据权利要求1所述的方法，其中所述应用是互联网协议语音 (VoIP)会话。
17. 根据权利要求1所述的方法，还包括响应于所述预订接收端的本地策略，从所述预订接收端向所述发送端返回所述预订请求消息，所述预订请求消息包括用于发送到所述发送端的 快速预订失败通知的请求。
18. —种适于在计算机网络中在没有应用接收端参与的情况下，在发 送端使用预订协议促进应用同步的设备，所述设备包括用于从所述发送端向预订接收端发送路径请求消息的装置； 用于在所述预订接收端接收所述路径请求的装置；作为响应，用于从所述预订接收端向所述发送端返回预订请求消息的 装置，所述预订请求包括用于发送到所述发送端的快速预订失败通知的请求；用于在所述预订请求期间在所述发送端和预订接收端之间的中间节点 处检测错误的装置；以及作为响应，用于从所述中间节点向所述发送端发送快速预订失败通知 的装置。
19. 根据权利要求18所述的设备，还包括用于基于在所述发送端对所述快速失败通知或者成功预订请求消息的 接收来使用所述预订协议同步所述应用的装置。
20. 根据权利要求18所述的设备，还包括用于从所述发送端向所述预订接收端发送所述路径请求消息的装置， 所述路径请求包括用于返回到所述发送端的快速路径失败通知的请求；用于在所述预订接收端检测所述路径请求内的所述快速失败通知请求 的装置；以及用于响应于在所述路径请求内检测到所述快速失败通知请求，从所述 预订接收端向所述发送端返回所述预订请求消息的装置，所述预订请求消 息包括用于发送到所述发送端的快速预订失败通知的请求。
21. —种包含可执行程序指令的计算机可读介质，所述程序指令用于 在计算机网络中在没有应用接收端参与的情况下，在发送端使用预订协议 促进应用同步，所述可执行程序指令包括用于以下的程序指令-从所述发送端向预订接收端发送路径请求消息； 在所述预订接收端接收所述路径请求；作为响应，从所述预订接收端向所述发送端返回预订请求消息，所述预订请求包括用于发送到所述发送端的快速预订失败通知的请求；在所述预订请求期间，在所述发送端和预订接收端之间的中间节点处 检测错误；以及作为响应，从所述中间节点向所述发送端发送快速预订失败通知。
22. 根据权利要求21所述的计算机可读介质，其中所述可执行程序 指令还包括用于以下的程序指令基于在所述发送端对所述快速失败通知或者成功预订请求消息的接 收，来使用所述预订协议同步所述应用。
23. 根据权利要求21所述的计算机可读介质，其中所述可执行程序 指令还包括用于以下的程序指令从所述发送端向所述预订接收端发送所述路径请求消息，所述路径请 求包括用于返回到所述发送端的快速路径失败通知的请求；在所述预订接收端检测所述路径请求内的所述快速失败通知请求；以及响应于在所述路径请求内检测到所述快速失败通知请求，从所述预订 接收端向所述发送端返回所述预订请求消息，所述预订请求消息包括用于 发送到所述发送端的快速预订失败通知的请求。
24. —种系统，被配置为在计算机网络中使用预订协议促进应用同 步，所述系统包括发送端，被配置为发送路径请求消息；预订接收端，被配置为接收所述路径请求，并且作为响应，将预订请 求消息返回到所述发送端，所述预订请求包括用于发送到所述发送端的快 速预订失败通知的请求；以及在所述发送端和所述预订接收端之间的中间节点，所述中间节点被配 置为在所述预订请求期间检测错误，并且作为响应，从所述中间节点向所 述发送端发送快速预订失败通知。
25. 根据权利要求24所述的系统，其中所述发送端还被配置为基于 对所述快速失败通知或者成功预订请求消息的接收来使用所述预订协议同步所述应用。
26. 根据权利要求24所述的系统，其中所述发送端还被配置为向所 述预订接收端发送所述路径请求消息，所述路径请求包括用于返回到所述 发送端的快速路径失败通知的请求；并且所述预订接收端还被配置为在所 述路径请求内检测所述快速失败通知请求，并且响应于在所述路径请求内 检测到所述快速失败通知请求，向所述发送端返回所述预订请求消息，所 述预订请求消息包括用于发送到所述发送端的快速预订失败通知的请求。
27. —种发送端节点，用于在计算机网络中使用预订协议促进应用同 步，所述发送端节点包括一个或多个网络接口；处理器，耦合到所述一个或多个网络接口并且适于执行软件过程；以及存储器，适于存储可由所述处理器执行的预订过程，所述预订过程被 配置为i)发送路径请求消息，所述路径请求包括用于返回到所述发送端 的快速路径失败通知的请求，和ii)基于对所述快速失败通知或者成功预 订请求消息的接收，使用所述预订协议同步所述应用。
28. —种预订接收端节点，用于在计算机网络中使用预订协议促进应 用同步，所述预订接收端节点包括一个或多个网络接口；处理器，耦合到所述一个或多个网络接口并且适于执行软件过程；以及存储器，适于存储可由所述处理器执行的预订过程，所述预订过程被 配置为0从发送端节点接收路径请求消息，和ii)作为响应，向所述发 送端节点返回预订请求消息，所述预订请求包括用于发送到所述发送端节 点的快速预订失败通知的请求。
29. 根据权利要求24所述的预订接收端节点，其中所述预订过程还 被配置为iii)从发送端节点接收所述路径请求消息，所述路径请求包括 用于返回到所述发送端的快速路径失败通知的请求，iv)在所述路径请求 内检测所述快速失败通知请求，和v)响应于在所述路径请求内检测到所述快速失败通知请求，向所述发送端返回所述预订请求消息，所述预订请 求消息包括用于发送到所述发送端的快速预订失败通知的请求。
30. —种中间节点，用于在计算机网络中使用预订协议促进应用同 步，所述中间节点包括一个或多个网络接口；处理器，耦合到所述一个或多个网络接口并且适于执行软件过程；以及存储器，适于存储可由所述处理器执行的预订过程，所述预订过程被配置为i)在从预订接收端节点向发送端节点发送的预订请求期间检测错 误，所述预订请求包括用于发送到所述发送端节点的快速预订失败通知的 请求，和ii)作为响应，向所述发送端节点发送快速预订失败通知。
全文摘要
一种在计算机网络中在没有应用接收端参与的情况下，在发送端使用预订协议促进应用同步的技术。发送端向预订接收端发送路径请求消息并且可包括用于将被返回到发送端的快速路径失败通知的请求。预订接收端(例如，应用接收端上游的预订接收端代理)接收路径请求，并作为响应向发送端返回预订请求消息，包括用于也将被发送到发送端的快速预订失败通知的请求(例如，响应于检测到快速路径失败通知请求、本地策略/配置等)。在发送端和预订接收端之间的中间节点在路径请求或预订请求期间检测到错误时，中间节点向发送端发送相应的快速失败通知。然后，发送端可基于对快速失败通知或成功的预订请求消息的接收，例如使用预订协议来同步应用。
文档编号G06F15/16GK101410820SQ200780011071
公开日2009年4月15日 申请日期2007年3月29日 优先权日2006年3月31日
发明者安卡·扎木法, 弗兰克斯·莱夫彻尔, 阿首克·纳芮阿南 申请人:思科技术公司