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

　　關鍵詞: RTCP? 可擴縮性? 動態(tài)多播組

?

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

　　本文在詳細分析這些問題的基礎上,探討了一種應用于大型動態(tài)多播組的RTCP可擴縮性的改進策略。

1? RTCP協(xié)議介紹

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

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

　　(2)標志媒體間的同步。RTCP的SR包中含有實際時間和相應的RTP時間戳,可用于不同媒體間的同步。

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

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

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

2? RTCP可擴縮性分析

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

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

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

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

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

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

3?RTCP可擴縮性的改進策略

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

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

?

?

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

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

　　下面從一個RTP會話的建立開始,具體說明該策略在大型動態(tài)多播組中的應用。

4.1 初始工作

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

4.2 Manager的作用

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

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

4.3 本地域的建立

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

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

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

?

?

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

?

?

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

　　N和M是某個特定的值,N限制了結構樹的高度,當樹高≥N時,新成員不會成為AG。M是對到新成員距離的限制,它保證了一個離雙親很近的成員,不能成為AG。

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

?

?

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

4.3.2 LAG的選舉

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

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

4.4 各成員的離開

4.4.1 AG的崩潰或離開

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

4.4.2 LAG的崩潰或離開

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

4.4.3 一般成員的崩潰或離開

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

4.5 Manager的離開

　　當所有的成員都離開會話,或者會話結束時,Manager失去了存在的意義,會自動離開會話。

5? 總? 結

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

?

參考文獻

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