RSVP

来自站长百科
跳转至： 导航、​ 搜索

RSVP（资源预留协议）最初是IETF为QoS的综合服务模型定义的一个信令协议，用于在流所经路径上为该流进行资源预留从而满足该流的QoS要求，资源预留的过程从应用程序流的源节点发送Path消息开始，该消息会沿着流所经路径传到流的目的节点并沿途建立路径状态；目的节点收到该Path消息后会向源节点回送Resv消息，沿途建立预留状态，如果源节点成功收到预期的Resv消息则认为在整条路径上资源预留成功。

RSVP的相关知识[ ]

  • RSVP是一个在IP上承载的信令协议，它允许路由器网络任何一端上终端系统或主机在彼此之间建立保留带宽路径为网络上的数据传输预定和保证，它对于需要保证带宽和时延的业务，如语音传输，视频会议等具有十分重要的作用。
  • RSVP协议中涉及到发送者和接收者的概念，这两个概念是在逻辑上进行区分的，发送者指发送路径消息的进程，而接收者是指发送预留消息的进程，同一个进程可以同时发送这两种消息，因此既可以是发送者也可以是接收者。
  • RSVP是由接收者提出资源预留申请的，这种申请是单向的，也就是说为从主机a到主机b的数据流预留的资源，对于从主机b到主机a的数据流是不起作用的，因为在当前的Internet中双向的路由是不对称的：从主机a到主机b的路径并不一定是从主机b到主机a的路径的反向；另外一个两个方向的数据传输特征和对应申请预留的资源也未必相同。

RSVP的两种类型[ ]

  • 专用预留(distinct reservation)：它所要求的预留资源只用于一个发送者，即在同一会话(session)中的不同发送者分别占用不同的预留资源。
  • 共享预留(shared reservation)：它所要求的预留资源用于一个或多个发送者，即在同一会话(session)中的多个发送者共享预留资源。

RSVP的两种发送者选择方式[ ]

  • 通配符方式(wildcard)：默认所有发送者，并通过预留消息中所携带的源端地址列表来限制通配符滤波器
  • 显式指定方式(explicit)：滤波器明确指定一个或多个发送者来进行预留。
  1. rsvp用interserv模型的两种服务方式：
  2. cl服务(controlled-load service)：给用户数据提供接近于在未超载网络上传输质量的服务。
  3. gs服务(guaranteed service)：给用户数据提供能保证带宽与时延的服务。
  4. rsvp适用于为frame-relay，hdlc，ppp等网络提供预留保证。
  • 资源预留和队列机制的结合使用两个关键点：
  1. 端到端的RSVP数据流：数据流从单一或多个源地址向单一或多个目标地址进行单向传输。
  2. 路由器到路由器的WFQ会话：穿越特定接口的单一传输层会话或网络层数据流，WFQ会话通过源地址和目标地址，端口号或协议号等属性进行区分。

配置RSVP步骤如下[ ]

1、启用RSVP,默认带宽预留上限为接口带宽的75%。可以指定RSVP数据流带宽总量，也可以指定每个RSVP数据流的带宽：

2、指定只接收符合特定条件的邻居路由器的RSVP请求。可选：nimokaka(config)#ip rsvp neighbor {ACL}

3、对于符合RSVP所定义的带宽和超出RSVP所定义的带宽的数据包分配IP优先级。 　　

RSVP的show command命令[ ]

  1. 允许远程管理工作站监视RSVP相关的信息：nimokaka(config)#snmp-server enable traps rsvp
  2. 显示接口的RSVP信息：nimokaka#show ip rsvp interface [interface]
  3. 显示接口的RSVP过滤和带宽信息：nimokaka#show ip rsvp installed [interface]
  4. 显示当前的RSVP邻居信息：nimokaka#show ip rsvp neighbor [interface]
  5. 显示RSVP发送方,接收方以及请求信息：nimokaka#show ip rsvp {sender|reservation|request} [interface]

相关条目[ ]

参考来源[ ]

取自“https://www.zzbaike.com/wiki/RSVP?oldid=109246”