摘? 要: 對(duì)RTCP的可擴(kuò)縮性問題進(jìn)行分析,探討了一種RTCP可擴(kuò)縮性的改進(jìn)策略,并將其應(yīng)用于大型的動(dòng)態(tài)多播組中。

　　關(guān)鍵詞: RTCP? 可擴(kuò)縮性? 動(dòng)態(tài)多播組

?

　　為了解決Internet上多媒體通信所面臨的問題,IETF提出了實(shí)時(shí)傳輸協(xié)議(RTP)標(biāo)準(zhǔn),為用戶提供端到端連續(xù)媒體數(shù)據(jù)的實(shí)時(shí)服務(wù)。實(shí)時(shí)控制協(xié)議(RTCP)是RTP的控制部分,主要用于發(fā)送者改變數(shù)據(jù)傳輸速率來(lái)適合網(wǎng)絡(luò)當(dāng)前狀態(tài)。RTP和RTCP能在中小型會(huì)話中工作得非常好。但隨著多媒體需求的持續(xù)增長(zhǎng),擁有上千個(gè)成員的MBone會(huì)話將成為平常事,并且成員數(shù)會(huì)動(dòng)態(tài)漲落。這時(shí),RTCP可擴(kuò)縮性的問題將變得十分明顯。

　　本文在詳細(xì)分析這些問題的基礎(chǔ)上,探討了一種應(yīng)用于大型動(dòng)態(tài)多播組的RTCP可擴(kuò)縮性的改進(jìn)策略。

1? RTCP協(xié)議介紹

　　RTCP協(xié)議和RTP一起提供流量控制和擁塞控制服務(wù)。在RTP會(huì)話期間,將控制包周期地發(fā)送給所有的連接者,應(yīng)用與數(shù)據(jù)包相同的分布機(jī)制。RTCP執(zhí)行以下4種控制功能。

　　(1)QoS監(jiān)控和擁塞控制。發(fā)送音頻(或視頻)數(shù)據(jù)的發(fā)送者會(huì)產(chǎn)生一個(gè)SR包,包中含有所發(fā)送的包數(shù)和字節(jié)數(shù)統(tǒng)計(jì)等信息。接收者可據(jù)此估計(jì)出實(shí)際的數(shù)據(jù)率。會(huì)話成員向所有參與會(huì)話活動(dòng)的音頻和視頻源發(fā)送RR包,包中含有所接收的最高包序列號(hào)、丟失的包數(shù)、包間隔抖動(dòng)測(cè)量值以及計(jì)算源端和目的端之間來(lái)回時(shí)間(Round-Trip-Time,RTT)所需的時(shí)間戳。

　　(2)標(biāo)志媒體間的同步。RTCP的SR包中含有實(shí)際時(shí)間和相應(yīng)的RTP時(shí)間戳,可用于不同媒體間的同步。

　　(3)提供標(biāo)志信息。RTP數(shù)據(jù)包只能通過隨機(jī)產(chǎn)生的32位標(biāo)志符來(lái)標(biāo)識(shí)源,而RTCP的源描述SDES數(shù)據(jù)包為每個(gè)對(duì)話成員提供了全局惟一的標(biāo)志符信息,可以滿足復(fù)雜應(yīng)用的需要。

　　(4)會(huì)話規(guī)模估計(jì)和規(guī)劃。參與會(huì)話的每個(gè)成員周期地發(fā)送RTCP包,各站點(diǎn)可據(jù)此估計(jì)或計(jì)算出參與會(huì)話的人數(shù),及時(shí)調(diào)節(jié)實(shí)時(shí)監(jiān)控的信息量,使得控制信息量和媒體業(yè)務(wù)量達(dá)到平衡。

　　RTCP數(shù)據(jù)包有以下5種包類型:①SR源報(bào)告包,用于發(fā)送和接收活動(dòng)源的統(tǒng)計(jì)信息。②RR接收者報(bào)告包,用于接收非活動(dòng)站的統(tǒng)計(jì)信息。③SDES源描述包,用于報(bào)告和用戶相關(guān)的信息。④BYE用戶離開系統(tǒng)報(bào)告包。⑤APP特殊應(yīng)用包。

2? RTCP可擴(kuò)縮性分析

　　RTCP應(yīng)用于大型的多播組特別是動(dòng)態(tài)的多播組時(shí),其可擴(kuò)縮性問題十分突出。

　　(1)擁塞:通常期望多播會(huì)話在某個(gè)時(shí)間點(diǎn)能及時(shí)地容納組成員的快速增長(zhǎng)。然而當(dāng)大量用戶幾乎在同一時(shí)間加入同一個(gè)會(huì)話時(shí),每個(gè)用戶都認(rèn)為他是惟一的用戶,他們將在相當(dāng)短的時(shí)間內(nèi)發(fā)送一個(gè)初始的RTCP包,致使RTCP包溢出,發(fā)生擁塞。對(duì)于那些以低帶寬連接的成員,這將直接導(dǎo)致部分成員的初始包丟失,影響對(duì)組大小的估計(jì)。由于成員離開會(huì)話時(shí)會(huì)以多播方式發(fā)送一個(gè)BYE包給組內(nèi)的所有成員,所以大量用戶同時(shí)離開多播組也會(huì)發(fā)生擁塞。

　　(2)狀態(tài)存儲(chǔ):為了估計(jì)組的大小,主機(jī)必須根據(jù)多播組的反饋報(bào)告來(lái)計(jì)數(shù)該多播組中的成員。為了保證每個(gè)終端系統(tǒng)僅被計(jì)數(shù)一次,需要存儲(chǔ)其惟一的標(biāo)識(shí)符(SSRC)。一旦多播組急劇增大將需要巨大的存儲(chǔ)空間。這使得RTCP狀態(tài)存儲(chǔ)的可擴(kuò)縮性成為一個(gè)重要問題。

　　(3)延遲:隨著組的增加,從某個(gè)特定用戶得到RTCP報(bào)告的時(shí)間將變得非常長(zhǎng)(例如:在一個(gè)大約3 000成員的組中,相互發(fā)送一個(gè)RTCP包大約需要一個(gè)小時(shí))。如此長(zhǎng)的間隔意味著來(lái)自某個(gè)特定用戶的QoS問題的反饋報(bào)告將變得毫無(wú)意義。

　　(4)過早停機(jī):當(dāng)大量成員同時(shí)離開時(shí)可能產(chǎn)生的另一個(gè)問題就是在用戶還沒有全部離開應(yīng)用程序時(shí)程序就停止了。這是由于在現(xiàn)行的標(biāo)準(zhǔn)中,一個(gè)用戶如果在持續(xù)的5個(gè)RTCP包的間隔內(nèi)不發(fā)送RTP或RTCP包,他就被停止了。在一個(gè)動(dòng)態(tài)組中,間隔本身就是動(dòng)態(tài)的。當(dāng)大量用戶同時(shí)離開組時(shí),他們的BYE包使得組的大小的估計(jì)值急劇降低。這就導(dǎo)致了停機(jī)間隔的縮短。如果用戶離開的人數(shù)足夠多,則該停機(jī)間隔將降低到使得殘留的用戶也將被停止。

　　除了以上提到的這些問題外,由于目前越來(lái)越多的實(shí)時(shí)的適應(yīng)性應(yīng)用程序使用基于接收者的速率適應(yīng)機(jī)制,而非基于發(fā)送者的速率適應(yīng)機(jī)制,這也使得RR中的一些域的功能也出現(xiàn)了問題。

3?RTCP可擴(kuò)縮性的改進(jìn)策略

　　從RTCP的工作情況和RR的功能可以發(fā)現(xiàn)反饋(Feedback)在其中起到的重要作用,RTCP的許多擴(kuò)縮性問題都與它有關(guān)。以下提到的這種方法不需要每個(gè)成員都計(jì)算整個(gè)多播組的大小,也不需要廣播RR,從而有效地解決了RTCP中由大量包的多播帶來(lái)的種種不便于擴(kuò)縮的問題,更有效地利用了RR。

　　本文論述的這種策略要使用本地域及其成員的結(jié)構(gòu)樹圖如圖1所示。這里所指的成員是在同一個(gè)RTP會(huì)話中所有的接收者或發(fā)送者。該結(jié)構(gòu)將成員動(dòng)態(tài)地組織到一個(gè)多層次的本地域(Local Region)中。

?

?

　　在每個(gè)本地域中都有一個(gè)Aggregator(AG),它的子節(jié)點(diǎn)可以是AG、LAG或者普通的成員(用空心圈表示)。AG1是第一層的AG,AG2屬于第二層,是AG1的子節(jié)點(diǎn)。AG接收其子節(jié)點(diǎn)發(fā)送的RR,產(chǎn)生統(tǒng)計(jì)表,并發(fā)送給Manager。由AG或LAG發(fā)給Manager的RR稱為AGR。LAG是處在LAN中的AG,它與AG的功能相同。同一個(gè)LAN中只有一個(gè)LAG。Manager是整個(gè)層次結(jié)構(gòu)的根,也可以看作是AG0,它接收來(lái)自既非AG也非LAG的直接子節(jié)點(diǎn)的RR,也接收AGR。Manager是惟一沒有子節(jié)點(diǎn)數(shù)量限制的AG。如果某子節(jié)點(diǎn)不能被其雙親AG接收,則它會(huì)被Manager接收。

4?應(yīng)用于大型動(dòng)態(tài)多播組的工作過程

　　下面從一個(gè)RTP會(huì)話的建立開始,具體說(shuō)明該策略在大型動(dòng)態(tài)多播組中的應(yīng)用。

4.1 初始工作

　　一個(gè)RTP會(huì)話開始后,首先通告2個(gè)多播地址:第一個(gè)地址傳輸RTP數(shù)據(jù)包,第二個(gè)傳輸RTCP控制包。然后,Manager加入多播的控制組。

4.2 Manager的作用

　　Manager是整個(gè)層次結(jié)構(gòu)的根,僅存在于控制組中,不對(duì)數(shù)據(jù)組起任何作用。它對(duì)加入或刪減成員及各種角色選舉結(jié)果的信息進(jìn)行管理。

　　Manager在每個(gè)間隔期間分析AGR中的數(shù)據(jù),將有用的統(tǒng)計(jì)表記入日志,據(jù)此診斷、估計(jì)可能或已發(fā)生問題的區(qū)域,監(jiān)視數(shù)據(jù)在多播組中的分布。收集和分析統(tǒng)計(jì)數(shù)據(jù),幫助估計(jì)每個(gè)區(qū)域的接收質(zhì)量,發(fā)現(xiàn)單個(gè)會(huì)話內(nèi)的熱點(diǎn)區(qū)域。所以,應(yīng)該被高速地連入網(wǎng)絡(luò)。

4.3 本地域的建立

　　本地域的建立在Manager加入以后進(jìn)行,主要包括新成員的加入和LAG、AG的選舉。

4.3.1 普通成員的加入及AG的選舉

　　當(dāng)一個(gè)新成員加入會(huì)話時(shí),首先執(zhí)行一個(gè)擴(kuò)展的環(huán)搜索。新成員通過增加TTL的值來(lái)重復(fù)搜尋雙親AG直到它找到一個(gè)鄰近的雙親。TTL是IP包中的一個(gè)域,發(fā)送者根據(jù)想要包到達(dá)距離的長(zhǎng)短,對(duì)TTL域初始化。每經(jīng)過一個(gè)路由器TTL減1,當(dāng)TTL=0時(shí),該包被丟棄。TTL=1的廣播包僅用于對(duì)同一局域網(wǎng)內(nèi)成員的發(fā)送。新節(jié)點(diǎn)尋找雙親的信息交換過程如圖2所示。首先,它廣播一個(gè)TTL值較小且大于1的“Search-for-Parent”的請(qǐng)求,如果一段時(shí)間內(nèi)沒有答復(fù),它將以一個(gè)大一點(diǎn)的TTL再做一次擴(kuò)展的環(huán)搜索。依此類推,直到它在現(xiàn)有的AG中接收到一個(gè)“Potential-Child-Acceptance”回應(yīng)。

?

?

　　新成員(NM)接收到候選雙親的回復(fù)后,對(duì)每個(gè)候選雙親(CP)的AG進(jìn)行判定,以確定自己是可能的子節(jié)點(diǎn)(PC)還是侯選(CC)AG。新成員角色判斷的流程圖如圖3所示。

?

?

　　每個(gè)雙親AG所能有的直接成員(包括非AG和AG)的最大數(shù)量分別用MAX1和MAX2表示。這種信息通過以下方式傳遞:當(dāng)會(huì)話剛開始僅有Manager時(shí),如果有成為AG的新節(jié)點(diǎn)加入,則Manager就將這些信息傳遞給AG,AG再將這些從Manager得到的初始信息傳給它們的子AG。初始的管理信息都是通過這種方式發(fā)送的。

　　N和M是某個(gè)特定的值,N限制了結(jié)構(gòu)樹的高度,當(dāng)樹高≥N時(shí),新成員不會(huì)成為AG。M是對(duì)到新成員距離的限制,它保證了一個(gè)離雙親很近的成員,不能成為AG。

　　新成員收到多個(gè)候選雙親的回復(fù)(實(shí)箭頭)時(shí)的選擇過程描述圖如圖4所示。此時(shí),選擇帶有最大TTL值的那個(gè)候選雙親作為雙親,該雙親到新成員的距離最短。然后向沒被選中的雙親發(fā)送“Reject-Parent”消息(虛箭頭)。如果新產(chǎn)生的AG沒有任何子節(jié)點(diǎn),則雙親就把該AG恢復(fù)為普通子成員。

?

?

　　被接收的成員向選定的雙親單播“Accept-Child”消息,存儲(chǔ)接收到的“Potential-Child-Acceptance”消息。對(duì)選定的雙親要做些修改:增加子節(jié)點(diǎn)的數(shù)量;存儲(chǔ)原始TTL的剩余值,此剩余值即為選定雙親到新加入的子節(jié)點(diǎn)的距離。如果接收的新成員是AG,則雙親還要增加它的AG數(shù)目。

4.3.2 LAG的選舉

　　當(dāng)一個(gè)新的LAN成員加入某個(gè)會(huì)話時(shí),本地先多播(TTL=1)一個(gè)“搜索LAG”包,詢問所在的LAN是否存在LAG。如果LAG存在,則所有的成員(包括LAG)本地多播一個(gè)“LAG存在”的回應(yīng)(包括LAG的IP地址)。為了避免回復(fù)報(bào)告的溢出,采用隨機(jī)的退出時(shí)鐘來(lái)控制報(bào)告的發(fā)送:每個(gè)成員附帶一個(gè)隨機(jī)的退出時(shí)鐘。延遲最小的成員最先終止它的時(shí)鐘,并立即發(fā)送回復(fù)消息。一旦得到回復(fù)消息,其他成員就停止發(fā)送回復(fù),并取消這些成員的時(shí)鐘。

　　如果一段時(shí)間內(nèi)沒收到回復(fù),則認(rèn)為該LAN中還沒有LAG,這時(shí)它被認(rèn)為是該LAN中參加這個(gè)會(huì)話的第一個(gè)成員,且被選為L(zhǎng)AG。接著開始搜索自己的雙親AG。一旦有一個(gè)LAG加入,不管它的雙親AG有多少個(gè)子節(jié)點(diǎn),都能立刻被接收。LAG在它所在的局域網(wǎng)內(nèi)沒有成員數(shù)量的限制。

4.4 各成員的離開

4.4.1 AG的崩潰或離開

　　AG周期性地對(duì)本地多播更新消息給它所有的子節(jié)點(diǎn)(AG的TTL值=離它最遠(yuǎn)的子節(jié)點(diǎn)的TTL)來(lái)通知它還存在。如果子節(jié)點(diǎn)在一段時(shí)間內(nèi)接收不到這樣的消息,就假設(shè)AG已經(jīng)崩潰。如果AG離開組,就向其所有子節(jié)點(diǎn)本地多播一個(gè)RTCP BYE包。不管哪種情況,該AG的每個(gè)子節(jié)點(diǎn)都將重新開始一個(gè)擴(kuò)展的找尋雙親的過程。

4.4.2 LAG的崩潰或離開

　　發(fā)現(xiàn)LAG崩潰或離開的過程與發(fā)現(xiàn)AG崩潰或離開的過程是類似的。LAG也是通過一個(gè)信息包的周期性多播來(lái)證明自己的存在,如果離開就多播BYE包。一旦發(fā)現(xiàn)LAG不存在,則LAN中的成員開始選擇一個(gè)新的LAG。每個(gè)成員都本地多播一個(gè)“要成為L(zhǎng)AG”的請(qǐng)求。這里同樣使用可以阻止多播請(qǐng)求溢出的隨機(jī)退出時(shí)鐘。當(dāng)某個(gè)成員的時(shí)鐘終止,就多播一個(gè)包括IP地址的“LAG存在”的消息。一旦接收到這個(gè)消息,LAN中其他的成員就停止自己“要成為L(zhǎng)AG”的請(qǐng)求,接收那個(gè)成員作為新的LAG,并存儲(chǔ)它的IP地址。這就直接決定了一個(gè)新的LAG。確定了新的LAG后要通知祖先AG,并修改有關(guān)信息。

4.4.3 一般成員的崩潰或離開

　　一個(gè)既非AG又非LAG的普通成員離開時(shí),只需向它的雙親AG發(fā)送BYE包。然后相關(guān)的AG作一些修改:更新相應(yīng)的記錄表,在它雙親AG的子節(jié)點(diǎn)數(shù)量中減掉1,并修改相應(yīng)祖先AG的信息。

4.5 Manager的離開

　　當(dāng)所有的成員都離開會(huì)話,或者會(huì)話結(jié)束時(shí),Manager失去了存在的意義,會(huì)自動(dòng)離開會(huì)話。

5? 總? 結(jié)

　　這里描述的改進(jìn)機(jī)制并不能完全解決關(guān)于大型動(dòng)態(tài)多播組中RTCP擴(kuò)縮性的問題,只能從某些方面減輕問題。關(guān)于擴(kuò)展的RTCP一些更為細(xì)致的工作正在研究之中。在具體的模擬實(shí)踐中需要不斷地改進(jìn)該策略以期能更好地服務(wù)于不斷發(fā)展的網(wǎng)絡(luò)多媒體應(yīng)用。

?

參考文獻(xiàn)

1?? Schulzrinne H,Casner S,Frederick R et al.RTP: A　Transport Protocol for Real-time Applications.RFC?1889,1996

2?? Aboba B.Alternatives of Enhancing RTP Scalability.draft-aboba-rtpscale-02.txt,1996

3?? Rosenberg R,Schulzrinne H.Timer Reconsideration for Enhanced RTP Scalability. draft-ietfavt-reconsider-00.ps,1997

4?? Marakby R E,Hutchison D.Scalability Improvement of the RTCP Leading to Management Facilities in the?Internet.in:Proc of the third IEEE Symposium on?Computers and Communications(ISCC′98),Athens,Greece,1998

5?? Friedman T,Caceres R,Almeroth K et al.RTCP Reporting Extensions.Internet Engineering TaskForce,2002