CN101410820A - 无应用接收端参与的在发送端使用预订协议促进应用同步 - Google Patents
无应用接收端参与的在发送端使用预订协议促进应用同步 Download PDFInfo
- Publication number
- CN101410820A CN101410820A CNA200780011071XA CN200780011071A CN101410820A CN 101410820 A CN101410820 A CN 101410820A CN A200780011071X A CNA200780011071X A CN A200780011071XA CN 200780011071 A CN200780011071 A CN 200780011071A CN 101410820 A CN101410820 A CN 101410820A
- Authority
- CN
- China
- Prior art keywords
- reservation
- request
- transmitting terminal
- receiver
- path
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
- H04L47/746—Reaction triggered by a failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/803—Application aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
一种在计算机网络中在没有应用接收端参与的情况下,在发送端使用预订协议促进应用同步的技术。发送端向预订接收端发送路径请求消息并且可包括用于将被返回到发送端的快速路径失败通知的请求。预订接收端(例如,应用接收端上游的预订接收端代理)接收路径请求,并作为响应向发送端返回预订请求消息,包括用于也将被发送到发送端的快速预订失败通知的请求(例如,响应于检测到快速路径失败通知请求、本地策略/配置等)。在发送端和预订接收端之间的中间节点在路径请求或预订请求期间检测到错误时,中间节点向发送端发送相应的快速失败通知。然后,发送端可基于对快速失败通知或成功的预订请求消息的接收,例如使用预订协议来同步应用。
Description
技术领域
本发明涉及计算机网络,并且更具体地涉及在计算机网络中在没用应用接收端参与的情况下,在发送端使用预订(reservation)协议促进应用同步。
背景技术
计算机网络是用于在诸如计算机之类的网络节点之间传送数据的互连子网在地理上的分布集合。局域网(LAN)是这种子网的一个例子。网络拓扑由通常经由一个或多个中间网络节点(诸如,路由器或交换机)彼此通信的客户端节点的布置定义。如在这里使用的,客户端节点是被配置为发起或终止在网络上的通信的网络节点。相反,中间网络节点是促进在客户端节点之间路由数据的节点。网络节点之间的通信通常会受根据预定义的协议交换离散数据包的影响。在此上下文中,协议由定义节点如何彼此交互的规则集合组成。
在网络节点之间传送的数据包可包括固定大小的数据单元和/或可变大小的数据帧。每个数据包通常包括由至少一个根据网络通信协议格式化的网络报头预先考虑(封装)的“有效载荷”数据。网络报头包括使客户端节点和中间节点能够经由计算机网络有效路由包的信息。通常,包的网络报头至少包括数据链路(层2)报头和网间(层3)报头(internetworkheader),如开放式系统互连(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 ReS ervation 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 thesession Initiation Protocol(SIP)preconditions Framework”的RFC 4032更新的名为“Integration of Resource Management and Session InitiationProtocol(SIP)”的RFC 3312中详细描述,其两者结合于此作为参考就好像完全在这里阐明。
在应用同步的典型例子中,例如VoIP,发送端可希望发起到接收端的应用会话(例如,呼叫),对于该会话需要预订资源以确保会话的QoS。因此,发送端通过向接收端发送“要约”并且在要约内包括在可完成会话建立之前应该预订资源的指示(即,资源预订是“前提”)来请求会话。然后,接收端可响应于要约并且提供关于会话的信息细节,但是可将会话建立中断,直到完成资源预订。然后,发送端可触发预订建立(例如,通过发送RSVP路径消息)。接收端可应答资源预订请求(例如,通过发送RSVP Resv消息)。一旦发送端接收到指示已预订所请求的资源的应答,发送端在应用层级信令向接收端确认前提。然后,接收端可恢复应用会话的建立(例如,向发送端确认建立,使它也可建立会话)。通过该方式,已成功同步应用和资源预订(即,尚未建立应用会话-并且例如,尚未响铃远程电话-没有首先确认已预订所请求的资源)。
然而,在某些网络环境中,接收端没有被配置为进行资源预订(例如RSVP),或者不能参与资源预订。在许多这些情况下,可从接收端(“应用接收端”)向上游定位预订接收端代理。这里,预订接收端代理(“预订接收端”)代表应用接收端执行资源预订信令。同样地,应用接收端不涉及资源预订。因此,应用接收端可不参与资源预订和应用建立之间的同步。而且,由于预订接收端不是应用的端点,所以它也可不参与资源预订和应用建立之间的同步。具体地,预订接收端代理可不知道应用层级信令,并且因而可不能有效地与发送端传送同步消息。例如,由资源预订产生的任何接纳拒绝或错误通常被发送到预订接收端。根据预订协议(例如,RSVP),可不向发送端通知失败。常规地,应用接收端会向发送端通知失败,而如上所述,预订接收端和应用接收端是独立的节点,所以可能不是这种情况(例如,或可能)。那么,对于发送端来说,使用预订协议单独同步应用将是有益的。
可参考VoD应用示出预订接收端代理的例子。VoD内容提供者可希望防止VoD内容分发到机顶盒(“应用接收端”),除非预订了适当的资源(例如,用于接纳控制),如本领域技术人员将会理解的。然而,许多机顶盒可能没有被配置为进行资源预订(RSVP),并且可能难于另外“升级”盒的配置。可从机顶盒向上游放置预订接收端代理,以处理资源预订,但是如上所述,存在与和预定接收端代理同步的应用相关联的问题。
已经提出了用于在没有应用接收端参与的发送端处的应用同步的各种方案。一个这种方案由尝试“猜测”预订状态的发送端组成。例如,在发送端已发送资源预订请求(例如,路径消息)的情况下,如果发送端在可配置长度的时间内尚未接收到响应(例如,Resv消息),则发送端可假设预订已失败。尽管该方案考虑到了应用同步,但是它可能很慢(即,基于足够宣布失败预订的可配置长度的时间),并且可能未解决初始预订建立之后的失败(例如,可响应于网络元件故障随后拒绝建立的预订),如本领域技术人将会理解的。
另一提出的方案是让预定接收端代理生成“假的”路径请求错误消息(例如,PathErr),以响应于接收预订请求错误消息(例如,ResvErr)而向发送端发送。通过该方式,“假的”路径请求错误消息(“假的”,是因为对于预订接收端来说响应于预订失败向发送端发送路径请求错误消息不是常规的)可向发送端通知预订失败。该方法还受到各种限制,包括(例如)慢响应时间。例如,当预订接收端和发送端之间的中间网络节点检测到预订错误时,预订错误消息向下游被发送到预订接收端并且被逐跳处理。然后,预订接收端可生成“假的”路径请求错误消息,然后该“假的”路径请求错误消息向上游被发送到发送端并且被逐跳处理。该逐跳处理可能是耗时的,因此该方案不是最优的回答。而且,该方案可能缺乏可伸缩性,因为在出现大的网络错误的情况下,预订接收端代理可被成千上万条错误消息淹没,从而导致处理浪涌和附加延迟。
因为到预订协议的紧紧应用同步是必需的(例如,以中断相应的数据流等),所以如本领域技术人员将会理解的,最小化与向发送端通知预订失败相关联的延迟是关键的。一种最小化关于错误通知的延迟的方法是使用快速失败通知或者“通知”特征,如在日期注明为2003年1月的RFC3473,标题为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和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 ResourceReSerVation Protocol-Traffic Engineering(RSVP-TE)Extension中描述,二者都结合在了上面。
根据RSVP,要建立诸如发送端110和预订接收端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是可有利地用于本发明的预订请求(例如,RSVP Resv)消息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和IS-IS)。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中所示,应用和预订接收端可被实现为独立节点。然而,本领域技术人员将理解,两个接收端可被实现在单个节点内,因此本发明仍可有利地被使用。
发送端110和应用接收端140可希望建立应用会话,诸如,VoIP呼叫或VoD会话(例如,在发送端是VoD内容服务器的情况下),如本领域技术人员将会理解的。作为响应,发送端110可生成路径请求消息(例如,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内。因为发送端110被配置为将其地址插入到地址字段365内,所以快速预订失败请求450相应地包括发送端的地址。
预订接收端130沿着中间节点120的路径朝发送端110转发预订请求消息400。在没有检测到预订错误的情况下,成功的预订请求最终到达发送端110,并且应用可成功地与应用接收端140(例如,通过应用层级信令,如本领域技术人员将会理解的)同步。然而,在中间节点120检测到失败(例如,预定状态错误)的情况下,中间节点以常规方式来处理失败。换言之,如果预订请求消息400中没有用于快速预订失败通知的请求,则中间节点120向预订接收端130返回预订错误消息(ResvErr500)。另一方面,如果存在用于快速失败通知的请求(例如,通知请求对象450),则中间节点120生成快速预订失败通知(通知消息600)并且将其发送到所请求的地址(例如,地址字段455)。然而,根据本发明,所请求的地址已经被配置为发送端110的地址,并且因此,快速预订失败通知从而被发送到发送端。
本发明通过在包内插入错误代码并且将包直接发送到发送端(即,到发送端的快速预订失败通知),避免了与中间节点120对常规的预订错误消息(ResvErr消息500)的逐跳接收和处理相关联的错误处理和信令延迟。本发明还避免了与预订接收端130进行的预订错误处理相关联的延迟,因此在应用和预订接收端是或不是相同接收端的两种情况下都可有利地应用(即,更快的同步响应)。例如,不是首先将错误发送到单个应用/预订接收端,本发明绕过了由接收端进行的任何处理并且将快速失败通知直接发送到发送端110。具体地,除了常规路径或预订错误消息,可发送快速失败通知,而不是代替常规的错误消息。具体地,中间节点120和预订接收端130还可变得通过预订错误消息(ResvErr 500)获知失败,即使发送端正在接收快速失败通知。这是重要的,从而使得中间节点120和预订接收端130可移除用于所请求的数据流路径的任何先前预订的状态。
通过将快速预订失败通知600直接发送到发送端110,(例如)尤其是在预订接收端130不是应用接收端140的情况下,本发明对应用到预订协议的紧密同步留有余地。具体地,使得发送端110以更快、更有效的方式获知预订失败,并且使得发送端110可快速确定应用是不成功的。具体地,因为快速预订失败通知600可包含预订类型错误代码消息(例如,在错误说明对象620中),所以发送端110可被配置为解释这些错误代码消息(通常发送到预订接收端),以便遵照本发明。可替换地,发送端110可简单地被配置为检测快速预订失败通知600的接收,而不解释错误代码消息620,并且确定导致了不成功的应用同步。
图8是表示根据本发明的应用和预订信令交换的同步的说明性示图800。简言之,该示图的顶部示出了成功的应用会话建立。例如,发送端110和应用接收端140可希望建立请求应用(例如,VoIP呼叫或VoD会话)。然后,发送端110可向预订接收端130发送具有用于快速路径失败通知360的说明性请求(“具有通知”)的路径消息300。具体地,如上所述的其它触发器(策略/配置等)也可根据本发明来使用。预订接收端130向发送端110返回具有如本文中所述的用于也将被发送到发送端的快速预订失败通知450的相应请求的Resv消息400。如果没有出现失败,则发送端使用预订协议同步成功的应用,并且应用会话可在发送端110和应用接收端140之间建立。
然而,该示图的底部示出了不成功的应用会话建立。这里,例如,在接收到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消息,预订接收端可向发送端发送快速路径或快速预订失败通知消息,以避免相关联的延迟。然而,尽管向发送端提供了快速失败通知,但该方案仍然无效率。具体地,快速失败通知必须首先行进到预订接收端,然后该预定接收端必须处理该通知,并且然后该快速失败通知必须被发送到发送端。因此,本领域技术人员将理解,尽管简要提出的方案是可行的,但它不像这里描述的用于本发明的技术一样有效。
前述描述是针对本发明的特定实施例的。然而,很明显,可对所述实施例做出各种变化和修改,并获得它们的某些或所有优点。例如,可以明白地预期,本发明的教导可实现为包括具有在计算机上执行的程序指令的计算机可读介质的软件、硬件、固件、或他们的组合。而且,可生成电磁信号,以(例如)在无线数据链路或数据网络(例如,因特网)上传送实现本发明的多个方面的计算机可执行指令。因此,仅通过示例的方式进行描述,并且本描述不用于限制本发明的范围。因此,所附权利要求的目的在于覆盖落入本发明的真实精神和范围内的所有这些变化和修改。
Claims (30)
1.一种用于在计算机网络中在没有应用接收端参与的情况下,在发送端使用预订协议促进应用同步的方法,所述方法包括:
从所述发送端向预订接收端发送路径请求消息;
在所述预订接收端接收所述路径请求;
作为响应,从所述预订接收端向所述发送端返回预订请求消息,所述预订请求包括用于发送到所述发送端的快速预订失败通知的请求;
在所述预订请求期间,在所述发送端和预订接收端之间的中间节点处检测错误;以及
作为响应,从所述中间节点向所述发送端发送快速预订失败通知。
2.根据权利要求1所述的方法,还包括:
基于在所述发送端对所述快速失败通知或者成功预订请求消息的接收,使用所述预订协议来同步所述应用。
3.根据权利要求1所述的方法,还包括:
从所述发送端向所述预订接收端发送所述路径请求消息,所述路径请求包括用于返回到所述发送端的快速路径失败通知的请求;
在所述预订接收端检测所述路径请求内的所述快速失败通知请求;以及
响应于在所述路径请求内检测到所述快速失败通知请求,从所述预订接收端向所述发送端返回所述预订请求消息,所述预订请求消息包括用于发送到所述发送端的快速预订失败通知的请求。
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.一种预订接收端节点,用于在计算机网络中使用预订协议促进应用同步,所述预订接收端节点包括:
一个或多个网络接口;
处理器,耦合到所述一个或多个网络接口并且适于执行软件过程;以及
存储器,适于存储可由所述处理器执行的预订过程,所述预订过程被配置为:i)从发送端节点接收路径请求消息,和ii)作为响应,向所述发送端节点返回预订请求消息,所述预订请求包括用于发送到所述发送端节点的快速预订失败通知的请求。
29.根据权利要求24所述的预订接收端节点,其中所述预订过程还被配置为:iii)从发送端节点接收所述路径请求消息,所述路径请求包括用于返回到所述发送端的快速路径失败通知的请求,iv)在所述路径请求内检测所述快速失败通知请求,和v)响应于在所述路径请求内检测到所述快速失败通知请求,向所述发送端返回所述预订请求消息,所述预订请求消息包括用于发送到所述发送端的快速预订失败通知的请求。
30.一种中间节点,用于在计算机网络中使用预订协议促进应用同步,所述中间节点包括:
一个或多个网络接口;
处理器,耦合到所述一个或多个网络接口并且适于执行软件过程;以及
存储器,适于存储可由所述处理器执行的预订过程,所述预订过程被配置为:i)在从预订接收端节点向发送端节点发送的预订请求期间检测错误,所述预订请求包括用于发送到所述发送端节点的快速预订失败通知的请求,和ii)作为响应,向所述发送端节点发送快速预订失败通知。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/395,592 US7702816B2 (en) | 2006-03-31 | 2006-03-31 | Facilitating application synchronization with a reservation protocol at a sender without application receiver participation |
US11/395,592 | 2006-03-31 | ||
PCT/US2007/065446 WO2007115066A2 (en) | 2006-03-31 | 2007-03-29 | Facilitating application synchronization with a reservation protocol at a sender without application receiver participation |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101410820A true CN101410820A (zh) | 2009-04-15 |
CN101410820B CN101410820B (zh) | 2012-09-05 |
Family
ID=38558738
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200780011071XA Active CN101410820B (zh) | 2006-03-31 | 2007-03-29 | 无应用接收端参与的在发送端使用预订协议促进应用同步 |
Country Status (4)
Country | Link |
---|---|
US (1) | US7702816B2 (zh) |
EP (1) | EP2005313B1 (zh) |
CN (1) | CN101410820B (zh) |
WO (1) | WO2007115066A2 (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101958810A (zh) * | 2010-10-27 | 2011-01-26 | 华为数字技术有限公司 | 用于中间节点自主实现故障定位的方法及系统 |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8370423B2 (en) | 2006-06-16 | 2013-02-05 | Microsoft Corporation | Data synchronization and sharing relationships |
US7900203B2 (en) * | 2007-04-24 | 2011-03-01 | Microsoft Corporation | Data sharing and synchronization with relay endpoint and sync data element |
US8724637B2 (en) * | 2008-06-04 | 2014-05-13 | Futurewei Technologies, Inc. | System and method for multi-topology support |
US7957299B2 (en) * | 2008-07-18 | 2011-06-07 | Embarq Holdings Company, Llc | System and method for tracking alarms in a packet network |
US8331231B2 (en) | 2008-09-09 | 2012-12-11 | Centurylink Intellectual Property Llc | System and method for monitoring bursting traffic |
US8259906B2 (en) * | 2008-09-22 | 2012-09-04 | Centurylink Intellectual Property Llc | System and method for testing a DSL and POTS connection |
BR112012015958B1 (pt) * | 2010-01-04 | 2021-08-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Métodos de operação de um primeiro nó em uma rede de conexão orientada, aparelhos e meios de armazenamento relacionados |
US10250492B2 (en) * | 2010-12-15 | 2019-04-02 | Telefonaktiebolaget Lm Ericsson (Publ) | Segment recovery in connection-oriented network |
US9331931B2 (en) | 2012-02-28 | 2016-05-03 | Cisco Technology, Inc. | Path selection based on hop metric distributions |
US9276967B2 (en) * | 2012-07-27 | 2016-03-01 | Centurylink Intellectual Property Llc | System and method for determining optimal bandwidth for streaming to a client device in an adjustable bit rate video system |
US9141416B2 (en) | 2013-03-15 | 2015-09-22 | Centurylink Intellectual Property Llc | Virtualization congestion control framework for modifying execution of applications on virtual machine based on mass congestion indicator in host computing system |
KR102280465B1 (ko) * | 2013-06-14 | 2021-07-22 | 삼성전자 주식회사 | 단말 및 그 단말에서 애플리케이션 동기화 방법 |
US10389577B2 (en) | 2013-08-14 | 2019-08-20 | Centurylink Intellectual Property Llc | Ethernet carrier group alarm (CGA) |
US9864623B2 (en) | 2013-11-21 | 2018-01-09 | Centurylink Intellectual Property Llc | Physical to virtual network transport function abstraction |
US10616377B2 (en) | 2014-04-03 | 2020-04-07 | Centurylink Intellectual Property Llc | System and method for implementing network enhanced gateway functionality |
US20150288767A1 (en) | 2014-04-03 | 2015-10-08 | Centurylink Intellectual Property Llc | Network Functions Virtualization Interconnection Hub |
US10225327B2 (en) | 2014-08-13 | 2019-03-05 | Centurylink Intellectual Property Llc | Remoting application servers |
US9898318B2 (en) | 2014-08-15 | 2018-02-20 | Centurylink Intellectual Property Llc | Multi-line/multi-state virtualized OAM transponder |
US10673978B2 (en) | 2015-05-06 | 2020-06-02 | Centurylink Intellectual Property Llc | Method and system for implementing network experience shifting using shared objects |
US10481938B2 (en) | 2015-05-06 | 2019-11-19 | Centurylink Intellectual Property Llc | System and method for implementing network experience shifting |
US9882833B2 (en) | 2015-09-28 | 2018-01-30 | Centurylink Intellectual Property Llc | Intent-based services orchestration |
US10078528B2 (en) | 2015-10-06 | 2018-09-18 | Centurylink Intellectual Property Llc | Virtual machine-to-port peripheral device driver for implementing communications between virtual machines and client devices |
EP4147132A1 (en) * | 2020-05-08 | 2023-03-15 | Telefonaktiebolaget LM ERICSSON (PUBL) | Direct notification for fast failure handling |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6493317B1 (en) | 1998-12-18 | 2002-12-10 | Cisco Technology, Inc. | Traffic engineering technique for routing inter-class traffic in a computer network |
US6876668B1 (en) | 1999-05-24 | 2005-04-05 | Cisco Technology, Inc. | Apparatus and methods for dynamic bandwidth allocation |
WO2000078120A2 (en) * | 1999-06-21 | 2000-12-28 | Bops Incorporated | Methods and apparatus for initiating and resynchronizing multi-cycle simd instructions |
US6628610B1 (en) | 1999-06-28 | 2003-09-30 | Cisco Technology, Inc. | Methods and apparatus for managing a flow of packets using change and reply signals |
US6606315B1 (en) | 1999-07-02 | 2003-08-12 | Cisco Technology, Inc. | Synchronizing service instructions among forwarding agents using a service manager |
US6721272B1 (en) | 1999-10-08 | 2004-04-13 | Cisco Technology, Inc. | Method and apparatus for generating an RSVP message for a non-RSVP-enabled network device |
EP1211851A1 (en) | 2000-11-30 | 2002-06-05 | TELEFONAKTIEBOLAGET L M ERICSSON (publ) | Method and system for resource reservation in a multicasting network |
US7027389B2 (en) | 2000-12-11 | 2006-04-11 | Cisco Technology, Inc. | Fast failure detection using RTT time considerations on a non-retransmit medium |
US6931028B1 (en) | 2000-12-28 | 2005-08-16 | Cisco Technology, Inc. | Scaleable RSVP signaling between VoIP dial-peers for tandem voice solutions |
US6973035B2 (en) * | 2000-12-29 | 2005-12-06 | Nortel Networks Limited | Method and system for a routing mechanism to support two-way RSVP reservations |
US6778492B2 (en) | 2002-01-17 | 2004-08-17 | Cisco Technology, Inc. | Load balancing for fast reroute backup tunnels |
US7739393B2 (en) | 2002-01-28 | 2010-06-15 | Cisco Technology, Inc. | Apparatus and method for restoring traffic during failover in a cable head end |
US7986618B2 (en) | 2002-06-12 | 2011-07-26 | Cisco Technology, Inc. | Distinguishing between link and node failure to facilitate fast reroute |
US8150951B2 (en) | 2002-07-10 | 2012-04-03 | Cisco Technology, Inc. | System and method for communicating in a loadbalancing environment |
US7286468B2 (en) | 2002-11-12 | 2007-10-23 | Cisco Technology, Inc. | Routing system and method for synchronizing a routing system with peers after failover |
US7599349B2 (en) | 2004-01-29 | 2009-10-06 | Cisco Technology, Inc. | Computing inter-autonomous system MPLS traffic engineering LSP paths |
US7746793B2 (en) | 2004-06-18 | 2010-06-29 | Cisco Technology, Inc. | Consistency between MPLS forwarding and control planes |
US7586841B2 (en) * | 2005-05-31 | 2009-09-08 | Cisco Technology, Inc. | System and method for protecting against failure of a TE-LSP tail-end node |
-
2006
- 2006-03-31 US US11/395,592 patent/US7702816B2/en not_active Expired - Fee Related
-
2007
- 2007-03-29 EP EP07759652.6A patent/EP2005313B1/en active Active
- 2007-03-29 CN CN200780011071XA patent/CN101410820B/zh active Active
- 2007-03-29 WO PCT/US2007/065446 patent/WO2007115066A2/en active Application Filing
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101958810A (zh) * | 2010-10-27 | 2011-01-26 | 华为数字技术有限公司 | 用于中间节点自主实现故障定位的方法及系统 |
WO2011144158A1 (zh) * | 2010-10-27 | 2011-11-24 | 华为技术有限公司 | 用于中间节点自主实现故障定位的方法及系统 |
US9059904B2 (en) | 2010-10-27 | 2015-06-16 | Huawei Technologies Co., Ltd. | Method and system for intermediate node to locate a fault independently |
Also Published As
Publication number | Publication date |
---|---|
EP2005313B1 (en) | 2018-05-09 |
EP2005313A4 (en) | 2014-10-08 |
CN101410820B (zh) | 2012-09-05 |
US7702816B2 (en) | 2010-04-20 |
WO2007115066A2 (en) | 2007-10-11 |
WO2007115066A3 (en) | 2008-09-18 |
EP2005313A2 (en) | 2008-12-24 |
US20070230358A1 (en) | 2007-10-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101410820B (zh) | 无应用接收端参与的在发送端使用预订协议促进应用同步 | |
US8169930B2 (en) | Communications method for a packet-switched network and network employing the method | |
US8891521B2 (en) | Triggering bandwidth reservation and priority remarking | |
US7720073B2 (en) | System and/or method for bidding | |
US7593405B2 (en) | Inter-domain traffic engineering | |
US20070237072A1 (en) | Resilient ip ring protocol and architecture | |
US8014389B2 (en) | Bidding network | |
JPH11163854A (ja) | データ通信方法 | |
EP2901651B1 (en) | Application layer session routing | |
JP2005198331A (ja) | 既存のリザーベーションプロトコルおよびフレームフォーマットを使用してネットワーク内およびネットワークを横切って行われる保証されたサービスの品質またはクラスを提供する方法および装置 | |
CN101675346A (zh) | 伪线负载平衡 | |
US20070101018A1 (en) | Inter-domain QoS reservation establishment and modification | |
KR102271639B1 (ko) | Avb 스트림의 모듈식 배향을 위한 방법 및 디바이스 | |
CN112769614B (zh) | 一种按需vpn的自动管理方法和异构网络的互通系统 | |
KR20080086473A (ko) | 다운스트림 입찰용 시스템 및/또는 방법 | |
Farrel et al. | Unanswered questions in the path computation element architecture | |
US8107465B1 (en) | Slim bandwidth reservation protocol over an IP network | |
US20080107127A1 (en) | Aggregation of Inter-Domain Resource Signaling | |
JP2010226564A (ja) | Ip電話網における帯域利用方法及びip電話システム | |
KR20100112140A (ko) | 패킷 스위칭 네트워크에 대한 자원들이 예약을 돕는 방법, 연관된 관리 디바이스, 및 보조 디바이스 | |
Arnold | A Traffic Engineering Attribute for BGP |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |