通信網(wǎng)banner.jpg)
前言：
RSVP(資源預(yù)留協(xié)議)是一種服務(wù)質(zhì)量協(xié)議，也是一種商業(yè)的開放協(xié)議，當(dāng)然它也是一種Internet上的大型協(xié)議，如果說它是網(wǎng)絡(luò)上流動(dòng)的一種鈔票，這樣的形容可以說是再合適不過了，利用RSVP消息，端點(diǎn)應(yīng)用程序可以根據(jù)需求提出數(shù)據(jù)傳送全程所必須網(wǎng)絡(luò)帶寬和緩沖大小以及延遲等等，同時(shí)也確定了沿途的路由器傳輸調(diào)度的策略，從而達(dá)到對(duì)每個(gè)數(shù)據(jù)流的QoS進(jìn)行控制。
RSVP支持兩種服務(wù)類型：受控載荷服務(wù)和保證服務(wù)，前者是在設(shè)定網(wǎng)絡(luò)的載荷非常輕的情況下，所有的數(shù)據(jù)流都按照盡力的方式來處理且網(wǎng)絡(luò)緩沖區(qū)為空，對(duì)于音頻信號(hào)而言這種方法是正好合適的，而后者不是這樣，不僅請(qǐng)求帶寬，而且也要求最大傳輸延遲，那么所得到的結(jié)果就是在網(wǎng)絡(luò)的負(fù)荷增加的時(shí)候不會(huì)讓QoS有非常明顯的減低。
如果從RSVP所支持的傳輸類型來區(qū)分QoS的服務(wù)，可以分成三種傳輸類型：最好性能（best-effort），速率敏感（rate-sensitive）與延遲敏感（delay-sensitive）。用來支持這些傳輸類型的數(shù)據(jù)流服務(wù)依賴保證QoS的協(xié)議實(shí)施。比如各種TCP/IP協(xié)議就是遵循最好性能傳輸?shù)膫鬏敺⻊?wù)協(xié)議：TFTP，HTTP，SMTP，POP3等等；速率敏感傳輸放棄及時(shí)性，而確保傳輸速率。例如：速率敏感傳輸請(qǐng)求128 kbps帶寬，如在擴(kuò)展期實(shí)際發(fā)送256 kbps，路由器可能進(jìn)行數(shù)據(jù)的隊(duì)列緩沖，并且延遲傳輸；這類傳輸與采用電交換網(wǎng)絡(luò)有關(guān)系，當(dāng)然在internet主干網(wǎng)絡(luò)和邊沿網(wǎng)絡(luò)也有這樣的情況出現(xiàn)，RSVP服務(wù)支持速率敏感傳輸，稱為位速率保證服務(wù)。延遲敏感傳輸要求傳輸及時(shí)，并因而改變其速率。例如：SIP或者H.323協(xié)議傳輸采用H.261協(xié)議壓縮圖象并且傳輸?shù)臅r(shí)候流量可能達(dá)到384-768kbps，384Kbps可能對(duì)應(yīng)一個(gè)靜態(tài)的背景，而768kbps 可能是一個(gè)動(dòng)態(tài)的圖象。熟悉H.261協(xié)議的人都知道在H.261中存在I-frame和P-frame的兩種壓縮方式，前者是本地壓縮，那么必然產(chǎn)生一個(gè)淬發(fā)的數(shù)據(jù)尖峰，而后者和平均帶寬的要求和接近，以Microsoft NetMeeting 為例子每15個(gè)P-frame產(chǎn)生一個(gè)I-frame，由于單個(gè)幀要求在一幀時(shí)間內(nèi)發(fā)送出去，或解碼器速度跟不上，必須對(duì)I-frame的傳輸進(jìn)行特定優(yōu)先級(jí)別協(xié)調(diào)，RSVP服務(wù)支持延遲敏感傳輸，可以被看作控制延遲服務(wù)（非實(shí)時(shí)服務(wù)）與預(yù)報(bào)服務(wù)（實(shí)時(shí)服務(wù)）的混合。
上面詳細(xì)的闡述了RSVP的服務(wù)類型和傳輸類型，這樣我們可以看出在以H.323或者是SIP為基礎(chǔ)的視頻通訊系統(tǒng)中，QoS的保證是比較復(fù)雜的，即有延遲敏感傳輸?shù)姆⻊?wù)也有速率敏感傳輸?shù)姆⻊?wù)，RSVP目前對(duì)這兩種服務(wù)都可以做到很好的支持,我在下面的文章中會(huì)闡述一下如何在H.323和SIP的協(xié)議棧中實(shí)現(xiàn)RSVP，重點(diǎn)介紹Vovida中Vocal的SIP的實(shí)現(xiàn)方式，但是這里之介紹點(diǎn)對(duì)點(diǎn)的情況，而不介紹多點(diǎn)互聯(lián)和廣播的情況。
RSVP資源預(yù)留協(xié)議的具體內(nèi)容可以參看RFC 1633中對(duì)RSVP的具體定義，另外在draft-ietf-rsvp-rapi-01.txt中定義關(guān)于RSVP相關(guān)的基本API函數(shù)調(diào)用。
RSVP工作順序描述如下圖所示：
發(fā)送方發(fā)送PATH消息，消息中包含有數(shù)據(jù)業(yè)務(wù)特征，該消息沿所選的路徑傳送，沿途的路由器按照PATH準(zhǔn)備路由資源，接收方接收到PATH消息以后，根據(jù)業(yè)務(wù)特征和所需要的QOS計(jì)算出所需要的資源，回送RESV消息，消息中包含的參數(shù)就包括請(qǐng)求預(yù)留的帶寬，延PATH的原路途返回，沿途的路由器接收到RESV操作后才執(zhí)行資源預(yù)留操作。發(fā)送方接收到RESV消息以后才發(fā)送用戶數(shù)據(jù)。
簡述在H.323協(xié)議中如何實(shí)現(xiàn)RSVP功能：
對(duì)于一個(gè)H.323或者是SIP的多媒體通訊系統(tǒng)而言，為了保證實(shí)時(shí)通訊的質(zhì)量，一般來說采用了很多方面來保證QoS，對(duì)于H.323來說方式?jīng)]有SIP那樣靈活，在H.323v3版本采用了一些幾種方式來增強(qiáng)QOS保證,另外這里暫時(shí)不對(duì)多播的情況考慮。
a. 增強(qiáng)的RAS過程，在ARQ中指明了是否具備資源預(yù)留能力；
b. 增強(qiáng)的能力交換過程，收發(fā)端點(diǎn)都具備RSVP功能，通過能力交換過程可以雙方具備RSVP能力（RSVP屬于能力集合的一個(gè)部分），在OpenLogicalChannel原語中定義了一個(gè)參數(shù)qOSCapability來表示；
c. 增強(qiáng)的邏輯信道能力在邏輯信道打開過程中包含Path和Resv兩個(gè)過程。
下面我們用圖來表示邏輯信道的打開過程和資源預(yù)留過程：
1. 發(fā)送端點(diǎn)向接受端點(diǎn)發(fā)送OpenLogicalChannel消息在qOSCapability中標(biāo)明該信道的RSVP參數(shù)和綜合業(yè)務(wù)類別。
2. 接收端點(diǎn)創(chuàng)建RSVP會(huì)話（調(diào)用Rapi_session API）向發(fā)送端點(diǎn)發(fā)送OpenLogicalChannel Ack。
3. 在OpenLogical Ack中包含F(xiàn)lowControl=0，抑制當(dāng)前的媒體數(shù)據(jù)流。
4. 4和5表示發(fā)送端點(diǎn)和接收端點(diǎn)執(zhí)行RSVP過程。
5. 接收端點(diǎn)接收到ResvConfirm以后知道預(yù)留成功。
6. FlowControl為最大的比特率，當(dāng)前的媒體數(shù)據(jù)流為最大。
要注意的一點(diǎn)是由于通訊是雙向的實(shí)際上述的過程發(fā)送和接收方需要對(duì)掉，特別在雙方的能力集不相同的情況之下需要變換主叫和被叫的身份執(zhí)行上述過程。
在SIP中實(shí)現(xiàn)RSVP功能：
以Vovida的Vocal為例子，在Vocal的SIP協(xié)議棧軟件中提供了一個(gè)非常簡便的實(shí)現(xiàn)RSVP的方式，當(dāng)然按照這個(gè)方式實(shí)現(xiàn)RSVP是相當(dāng)?shù)牟怀墒斓�，很多參量在�?yīng)用程序都沒有反饋并且處理，僅僅是在路由器之間相互的匯報(bào)，不過這個(gè)簡單的方式實(shí)現(xiàn)RSVP的構(gòu)架，所以仍然有一定的使用價(jià)值。
在Vovida的SIP中實(shí)現(xiàn)RSVP的步驟如下：
在上圖中實(shí)線的部分是SIP命令，虛線部分是RSVP消息
Vocal中的RSVP實(shí)現(xiàn)過程：
我們先看一下RSVP API中定義的流程：
我們先來看一下RSVP的API調(diào)用過程：
首先通過rapi_session()打開一個(gè)Unix域的RAPI Socket，并創(chuàng)建一個(gè)RSVP的會(huì)話實(shí)例,如果成功則返回一個(gè)非零的數(shù)值用于表示建立的會(huì)話ID號(hào)。
例如在Vocal的SIP Stack中這樣創(chuàng)建：
session_id = rapi_session(&(dest_addr),//會(huì)話對(duì)端的目的地址；
proto_id, //協(xié)議號(hào) udp 17；
RAPI_USE_INTSERV,//這里表示采用IntServ定義（和Diffserv相對(duì)應(yīng)）
(rapi_event_rtn_t)upcallHandler,//在RSVP錯(cuò)誤發(fā)生時(shí)候的回調(diào)函數(shù)
0,//RSVP事件的過濾器
&rtn_code);//建立會(huì)話的錯(cuò)誤返回值。
使用rapi_session創(chuàng)建會(huì)話是發(fā)送RSVP PATH或者是發(fā)送RSVP RESV都需要在調(diào)用相應(yīng)的函數(shù)之前調(diào)用它，現(xiàn)在我們看下面具體的程序部分的調(diào)用過程：
1．首先是主叫部分發(fā)送INVITE命令，我們知道命令中包含有主叫的會(huì)話描述（這里我們稱為Remote SDP）；
2．被叫部分此時(shí)處于OpRing的狀態(tài)中接收到主叫的INVITE消息以后，根據(jù)主叫的INVITE消息和主叫的SDP，得到主叫的地址和主叫的RSVP端口（主叫的RTP端口）；被叫調(diào)用setupRsvp子程序發(fā)送包含有數(shù)據(jù)流標(biāo)識(shí)和數(shù)據(jù)業(yè)務(wù)流特征的PATH消息到主叫，具體發(fā)送的業(yè)務(wù)流Tspec特征如下：
//Sender Tspec(數(shù)據(jù)流的話務(wù)描述特征)的定義：
rapi_tspec_t *tspec_ptr = &(snd_tspec);
qos_tspecx_t *qos_tspec = &(tspec_ptr->tspecbody_qosx);
qos_tspec->spec_type = QOS_TSPEC;//發(fā)送方業(yè)務(wù)流特征標(biāo)示
qos_tspec->xtspec_r = 10000;//業(yè)務(wù)流量
qos_tspec->xtspec_b = 200;//標(biāo)記存儲(chǔ)桶寬度
qos_tspec->xtspec_p = 10000;//突發(fā)流量
qos_tspec->xtspec_m = 200;//本地緩沖最大保留量（漏桶參數(shù)）
qos_tspec->xtspec_M = 200;//SDU的最大值
tspec_ptr->len = sizeof(rapi_hdr_t) + sizeof(qos_tspecx_t);
// RAPI Sender
tspec_ptr->form = RAPI_TSPECTYPE_Simplified;
… …
我們先來看一下在RSVP API中定義的發(fā)送一個(gè)PATH消息的函數(shù)：
rtn_code = rapi_sender(session_id,//在rapi_session中創(chuàng)建的會(huì)話ID號(hào)。
0,//該標(biāo)志暫時(shí)未被使用
&(src_addr), //源地址和源端口
NULL, //發(fā)送方的端口號(hào)和源地址，可以為空
&(snd_tspec), //發(fā)送方的數(shù)據(jù)流的話務(wù)描述特征
NULL, /* sender adsepc *///Apspec的內(nèi)容，可以為空
NULL, /* Policy */ //發(fā)送方策略值，一般為空
ttl); //消息的生存周期`````
這里似乎和RSVP的——呼叫方發(fā)送PATH消息的精神有一些違背，是被叫方發(fā)送PATH消息，其實(shí)二者沒有什么不同，首先主叫方，沒有收到被叫方的SDP所以不能確定被叫方接收RSVP消息的端口和IP地址，其次，媒體流是雙向的，雙方都必須在網(wǎng)路上通過PATH——Reserve的方式預(yù)流資源。
來源：ZDNet
