1. 首页 > 经验  > 正文

资源预留协定

资源预留协定(Resource ReSerVation Protocol;RSVP)是一种用于网际网路上质量整合服务的协定。RSVP 允许主机在网路上请求特殊服务质量用于特殊应用程式数据流的传输路由也使用 RSVP 传送服务质量(QOS)请求给所有结点(沿着流路径)并建立和维持这种状态以提供请求服务。

基本介绍

中文:资源预留协定外文名:Resource ReSerVation Protocol;RSVP性质:网际网路上质量整合服务的协定RSVP设计目标:单播和组播选择协定同时运行

资源预留协定

通常 RSVP 请求将会引起每个节点数据路径上的资源预留。
RSVP 只在单方向上进行资源请求,因此,儘管相同的应用程式,同时可能既担当传送者也担当接受者,但 RSVP 对传送者与接受者在逻辑上是有区别的。 RSVP 运行在 IPV4 或 IPV6 上层,占据协定栈中传输协定的空间。 RSVP 不传输套用数据,但支持网际网路控制协定,如 ICMP、IGMP 或者路由选择协定。正如路由选择和管理类协定的实施一样, RSVP 的运行也是在后台执行,而并非在数据转发路径上。

资源预留协定

RFC2205对RSVP的特徵做出以下的描述
(1)支持单播与组播;
(2)单向预留;
(3)接收者发起预留;
(4)维护Internet中的软状态。

RSVP设计目标

RSVP 本质上并不属于路由选择协定, RSVP 的设计目标是与当前和未来的单播(unicast)和组播(multicast)路由选择协定同时运行。 RSVP 进程参照本地路由选择资料库以获得传送路径。以组播为例,主机传送 IGMP 信息以加入组播组,然后沿着组播组传送路径,传送 RSVP 信息以预留资源。路由选择协定决定数据包转发到哪。 RSVP 只考虑根据路由选择所转发的数据包的 QOS 。为了有效适应大型组、动态组成员以及不同机种的接收端需求通过 RSVP ,接收端可以请求一个特定的 QOS[RSVP93] 。 QOS 请求从接收端主机应用程式被传送至本地 RSVP 进程,然后 RSVP 协定沿着相反的数据路径,将此请求传送到所有节点(路由器和主机),但是只到达接收端数据路径加入到组播分配树中时的路由器。所以, RSVP 预留开销是和接受端的数量成对数关係而非线性关係。
RSVP是由接收者提出资源预留申请的,这种申请是单向的,也就是说为从主机a到主机b的数据流预留的资源,对于从主机b到主机a的数据流是不起作用的。因为在当前的internet中,双向的路由是不对称的:从主机a到主机b的路径并不一定是从主机b到主机a的路径的反向;另外一个,两个方向的数据传输特徵和对应申请预留的资源也未必相同。
RSVP标準[RFC 2205]没有定义网路向数据流提供预约频宽的方法,它只是一个允许套用预约必要链路频宽的协定。一旦某预约付诸实施,英特网中的路由器就实际向数据流提供预约的频宽。

讯息

有以下几种主要的讯息:

路径讯息

路径讯息被沿着数据路径从传送方主机传送,并记录路径上每个节点的的路径状态。
路径状态包括先前节点的IP位址和一些数据对象
sender template(传送方模板)是用于描述传送方数据格式
sender tspec(数据流的话务描述特徵)是用于描述数据流传输特徵
adspec携带广告数据

预留讯息

预留讯息(resv)是由接收方沿着反向路径传送到传送方。在每个节点上,预留讯息的IP目的地址将会改成反向路径上下一节点的地址,同时IP源地址将会改成反向路径上前一节点的地址。预留讯息包括流量说明(flowspec)数据对象,这个数据对象上用于确定流需要的资源。
RSVP讯息的数据对象可以被按任何顺序进行传输。RSVP讯息和其数据对象的所有列表可以在RFC 2205中看到。

拆除讯息

拆除讯息(Teardown)的作用是立刻删除预留的链路或状态。虽然没有必要显式地(Explicitly)删除一个原有的预留资源,IETF.htm target=_blank class=infotextkey>TF仍然建议所有的终端主机在套用结束时应该立即传送Teardown讯息进行资源的显示释放
Teardown讯息有两种类型:路径拆除(PathTear)讯息和预留请求拆除(ResvTear)讯息。PathTear讯息沿数据流的路由方向传递,删除沿途中的链路状态以及与其相关的所有预留链路的状态。ResvTear讯息沿数据流路由的反方向传递,删除沿途中的资源预留状态。

差错讯息

差错讯息(Errors)讯息有;两种类型:路径差错(PathErr)和预留请求差错(ResvErr)。
PathErr用来报告处理Path讯息中产生的错误。当网路中的几点在处理Path讯息中产生的错误时,就会产生一个PathErr讯息传送到传送方。PathErr讯息在经过的网路结点时不改变包中的任何状态。
ResvErr讯息用来报告在处理Resv讯息中产生的错误。当网路中的结点在处理Resv讯息中产生的错误时,就会产生一个ResvErr讯息传送到接收方。它的转发依靠预留状态中保存的下一跳结点的地址。它在每一个结点上进行转发时,分组的IP目的地址就是下一跳的IP位址。这一点与ResvErr讯息的转发有所不同。

证实讯息

证实讯息ResvConf是用来确认资源预留请求的。它是一个可选的功能;当Resv讯息中带有RESV_CONFIRM参数值时才会要求返回确认的讯息。

RSVP资源预留模式

RSVP中的资源预留请求通过流描述符来表示,包括“流规範(Flowspec)”和“过滤器规範(Filter spec)”。其中,Flowspec描述符所希望得到的QoS保证,它用来设定相应网路结点中分调度部件或者链路层机制的参数;而Filter spec 用来设定分组流分类器的参数。Flowerspec一般由服务类型(Service Class)和参数“Rspec”、“Tspec”组成。“Rspec”用来定义所希望的QoS服务,而“Tspec”用来描述数据流。“Rspec”与“Tspec”的格式和内容对RSVP是透明的,它由IntServ的服务类型来描述。
RSVP资源预留讯息由接收方发起并一次向上游传送,上游在这里是从接收方到传送方的方向。在途径的每一个结点上,资源预留请求会触发下面的两个动作
(1)在链路上进行资源预留
每一个结点上的RSVP进程(RSVP Process)都会将 请求资源预留的讯息传递给接纳控制部件(Admission Control)和策略控制部件(Policy Control)。只要这两个部件中任何一个在检测是否可接纳时失败,那幺资源资源预留请求就会被拒绝;同时,RSVP进程产生一个错误讯息传送给接收方。如果二者都能成功,结点就会同时对分组流分类器进行相应的设定,从而在实际数据流传输时能够将这个预留的数据分组从进入路由器中的所有分组中挑选出来,进而为它提供QoS保证。
(2)向上游结点转发资源预留请求

操作过程

一个需要按特定服务质量传送数据流的RSVP主机将会传输一个RSVP路径讯息,这个路径讯息将会沿单播或组播路由通过路由协定预先建立的路径传输。如果路径讯息到达一个不理解RSVP的路由器,将会将这个讯息转发并不对其内容进行分析而且不会为这个流进行资源预留。
当目的路由器接收到路径讯息,它将会:
按照请求的参数进行资源预留。对此,许可控制和策略控制处理请求参数并通知分组分类以便正确处理选定的数据分组,或者和上层协商如何进行分组处理。
向上游转发请求(朝着传送方方向)。在每个节点上,预留讯息的流量说明(flowspec)可以由前向节点更改。(例如:在多播流资源预留时,预留请求就可以被合併)
路径上的每个节点都可以接收或者拒绝请求。

其他特点

加密技术——往RSVP讯息中添加信息摘要,这是通过一个信息摘要算法(一般是MD5)将讯息内容和一个共享密钥结合。密钥可以通过2个讯息类型被分配和确认:完整的挑战要求和完整的挑战回响。
错误报告——当一个节点侦听到一个错误,则会使用错误编码产生一个错误讯息,并按相反的路逕往上游传送直到源节点。
RSVP流信息:两种诊断信息允许网路管理者通过特定的流对RSVP状态信息进行请求。
诊断设备:这是规划的扩展部分,它使用户能够收集沿路径上的RSVP状态的信息。详见RFC2745 - RSVP Diagnostic Messages
RSVP是IntServ模型用于资源预留控制的一种协定,它本身并不是一个路由协定,而是Internet控制协定的一种,因此它的运行必须依赖于现有的路由协定提供的路由信息。RSVP工作在UDP和IP协定层之上,既支持IPV4,也支持IPV6,它也可以透明地通过不支持资源预留的路由器,但是只有当预留资源路径上的所有节点都支持RSVP协定时,才能进行有效的资源预留。
RSVP提供了不同的资源预留类型来适应多种不同的套用,它不仅可以为单播,也可以为组播进行资源预留,在组播套用中,它能根据组播成员与路由器的变化进行动态调整
RSVP的资源预留是由接收方发起的单项操作,它只保证了从传送者到接受者的单向资源预留,并不保证从接收者到传送者的资源,因此RSVP提供的QoS服务只限于从传送者到接收者的路径上。

本文由'励馨然'发布,不代表演示站立场,转载/删除联系作者,如需删除请-> 关于侵权处理说明