RSVP

Case Study:Overview

1>rsvp 用来在源到目的的path上进行资源预留.

2>rsvp 信令通知网络中所有的devices,一个特定的应用需要特定的QoS保证.

3>rsvp 需要应用程序去初始化请求.

4>rsvp 本身不提供任何保障,所有的的保障都是由中间设备提供

5> 与rsvp相互操作的QoS机制(WFQ,CBWFQ),必须针对rsvp预留提供相应的保障.

 

Case Study:End-to-End RSVP

所有的中间链路上的网络设备都必须启用对RSVP的支持

每个中间网络设备需要决定它们是否有足够的资源

 

 

Case Study:Pass-Through( 穿越) RSVP

中间链路上的网络设备可能不支持RSVP,那些不支持RSVP的设备执行Best-effort转发.

 

 

Pass-Through RSVP with Class of Service:

中间链路上的一部分网络设备可能不支持RSVP,它们可以通过使用标准的QoS机制, 启用QoS标记(如,CoS,IP优先级,DSCP),将RSVP流标识高的CoS值,实现高可靠性的传输.

必须保核心设备提供对RSVP类别的QoS保证

 

 

 

Case Study:RSVP Applications

RSVP 为那些需要bandwidth和delay相关应用程序提供保障

典型的应用程序有:

1>Voice over IP(Cisco phones,Microsoft NetMeeting,etc.)

2>MPLS traffic engineering

 

 

Case Study:Simple RSVP Configuration

Router(config-if)#ip rsvp bandwidth [total-BW [per-flow-BW]]

配置总的保留带宽(total-BW)及per-flow的最大保留带宽(per-flow-BW).单位:kbps

如果没有指定totol-BW,per-flow-BW,则两个值都为默认接口配置带宽的75%.

总的保留带宽(total-BW)不能超过接口配置带宽的75%.其它的25%用于管理及路由协议等.

Router(config-if)#bandwidth {bandwidth}

配置接口带宽,单位:kbps

应该配置此bandwidth反应真实的link带宽,进而为其它应用做好参考

 

 

Case Study:Proxy RSVP Configuration

因为一般的应用程序没有发送RSVP的能力,所以就需要用一个router来实现模拟一个RSVP用户设备

Router(config)#ip rsvp sender {session-IP} {sender-IP} {protocol} {dport} {sport} {src-hop-IP} {src-intf} {bandwidth} {burst}

模拟一个主机设备发送PATH消息(RSVP请求信息)

 

Router(config)#ip rsvp reservation {session-IP} {sender-IP} {protocol} {dport} {sport} {next-hop-IP} {next-hop-intf} {ff|se|wf} {rate|load} {bw} {burst}

模拟一个主机设备发送RESV消息

 

 

Case Study:RSVP Admission Control

RSVP 主要有两个任务:

1> 决定是否有足够的资源用于分配

2> 决定请求资源的应用是否有访问权限

 

启用RSVP的设备追踪存在的预留会话信息,如果有一万条预留应用,就要追踪一万条预留会话,所以RSVP它的可用性是非常差的.

启用RSVP的设备可以将admission control的部分受权能力下放给一个central servrs(COPS)服务器.类似于访问受权的AAA.

 

Common Open Policy Service(COPS):

COPS 提供可扩展的,更集中化的方案构建RSVP网络

COPS 提供更多的关于RSVP的控制,例如谁可以预留什么?

 

 

Configuring RSVP for COPS:

Case Study:RSVP Configuration Example

Case Study:RSVP with COPS Example

Case Study:Monitoring and Troubleshooting RSVP

Show ip rsvp installed [detail]    列出每个接口的预留情况

show ip rsvp reservation [detail]  查看RSVP保留信息

show ip rsvp request [detail]  查看RSVP请求信息

Case Study:Monitoring and Troubleshooting RSVP with COPS

Show ip rsvp policy [{cops | local} [acl]]   查看所有的策略

Show cops servers    查看所有的cops服务器

Case Study:Subnet Bandwidth Management

RSVP 管理单向的资源保留

RSVP 在共享介质上可能会导致oversubscription(过度使用)

SBM 是RSVP在共享介质上的一个扩展,用于防止oversubscription

 

Witchout SBM:

Ethernet 本身10M带宽

1> 右边每个router初始都是申请7.5Mbps带宽,向左边router

2> 右上边的router过来一个6Mbps的流量,我有7.5Mbps的保留带宽,所以可以发送

3> 右下边的router过来一个7Mbps的流量,我有7.5Mbps的保留带宽,所以发送

4> 这样一共是13Mbps的流量发送到共享的Ethernet上来,远远超过了Ethernet的实际可用带宽

 

With SMB:

DSBM Election:

1> 基于DSBM priority选举DSBM.类似于OSPF中的DR

2> 每一个DSBM Candidate通告它自己的priority(64-128)

3>DSBM Candidate 中priority最高的被选为DSBM

4> 启用RSVP的设备不用做为DSBM Candidates就可以参与Subnet bandwidth management

 

 

Configuring DSBM:

Router(config-if)#ip rsvp dsbm candidate {priority}

配置router做为DSBM Candidate去竞选DSBM,默认的priority为64

Router(config-if)#ip rsvp dsbm non-resv-send-limit {burst|max-unit|min-unit|peak|rate} {value}

Non-Resv-Send-Limit 对象规定:多少没有进行RSVP预留的流量可以被发送到一个管理segment上

 

 

Case Study:SBM Configuration Example

!

interface ethernet0/0

 ip address 10.1.1.1 255.255.255.0

 ip rsvp bandwidth 7500 7500

 ip rsvp dsbm candidate 100

 ip rsvp dsbm non-resv-send-limit rate 100

 ip rsvp dsbm non-resv-send-limit burst 100        // 单位kbps

 ip rsvp dsbm non-resv-send-limit peak 100

!

 

show ip sbm [detail]  

查看使用SBM的接口,detail参数显示更详解的信息本地和DSBM的配置

 

 

 

本文出自 “SENSE” 博客，转载请与作者联系！