資源預(yù)留協(xié)議（RSVP）和路由協(xié)議有著相似的功能，雖然它的本質(zhì)并不是路由協(xié)議但是也能完成單播和組播的相關(guān)管理工作。那么具體有什么特殊的意義呢？資源預(yù)留協(xié)議（RSVP）最初是IETF為QoS的綜合服務(wù)模型定義的一個信令協(xié)議，用于在流（flow）所經(jīng)路徑上為該流進行資源預(yù)留，從而滿足該流的QoS要求。資源預(yù)留的過程從應(yīng)用程序流的源節(jié)點發(fā)送Path消息開始，該消息會沿著流所經(jīng)路徑傳到流的目的節(jié)點，并沿途建立路徑狀態(tài)；目的節(jié)點收到該Path消息后，會向源節(jié)點回送Resv消息，沿途建立預(yù)留狀態(tài)，如果源節(jié)點成功收到預(yù)期的Resv消息，則認(rèn)為在整條路徑上資源預(yù)留成功。

資源預(yù)留協(xié)議（RSVP）是一個在ip上承載的信令協(xié)議，它允許路由器網(wǎng)絡(luò)任何一端上終端系統(tǒng)或主機在彼此之間建立保留帶寬路徑，為網(wǎng)絡(luò)上的數(shù)據(jù)傳輸預(yù)定和保證qos。它對于需要保證帶寬和時延的業(yè)務(wù)，如語音傳輸，視頻會議等具有十分重要的作用。

RSVP協(xié)議中涉及到發(fā)送者和接收者的概念，這兩個概念是在邏輯上進行區(qū)分的，發(fā)送者指發(fā)送路徑消息的進程，而接收者是指發(fā)送預(yù)留消息的進程，同一個進程可以同時發(fā)送這兩種消息，因此既可以是發(fā)送者，也可以是接收者。

RSVP是由接收者提出資源預(yù)留申請的，這種申請是單向的，也就是說為從主機a到主機b的數(shù)據(jù)流預(yù)留的資源，對于從主機b到主機a的數(shù)據(jù)流是不起作用的。因為在當(dāng)前的internet中，雙向的路由是不對稱的：從主機a到主機b的路徑并不一定是從主機b到主機a的路徑的反向；另外一個，兩個方向的數(shù)據(jù)傳輸特征和對應(yīng)申請預(yù)留的資源也未必相同。

資源預(yù)留協(xié)議（RSVP）提供兩種類型的預(yù)留：

專用預(yù)留(distinct reservation)：它所要求的預(yù)留資源只用于一個發(fā)送者。即在同一會話(session)中的不同發(fā)送者分別占用不同的預(yù)留資源。

共享預(yù)留(shared reservation)： 它所要求的預(yù)留資源用于一個或多個發(fā)送者。即在同一會話(session)中的多個發(fā)送者共享預(yù)留資源。

資源預(yù)留協(xié)議（RSVP）提供兩種發(fā)送者選擇方式：

通配符方式(wildcard)：默認(rèn)所有發(fā)送者，并通過預(yù)留消息中所攜帶的源端地址列表來限制通配符濾波器

顯式指定方式(explicit)：濾波器明確指定一個或多個發(fā)送者來進行預(yù)留。

資源預(yù)留協(xié)議（RSVP）用interserv模型的兩種服務(wù)方式：

cl服務(wù)(controlled-load service)：給用戶數(shù)據(jù)提供接近于在未超載網(wǎng)絡(luò)上傳輸質(zhì)量的服務(wù)。

gs服務(wù)(guaranteed service)：給用戶數(shù)據(jù)提供能保證帶寬與時延的服務(wù)。

RSVP適用于為frame-relay，hdlc，ppp等網(wǎng)絡(luò)提供預(yù)留保證。

（RSVP：Resource ReSerVation Protocol）