首頁>>>技術(shù)>>>視像通信　　視像通信產(chǎn)品

視頻壓彎了IP網(wǎng)

2003/11/24

　　IP融合，大勢所趨。

　　繼IP電話后，IP視頻業(yè)務(wù)已成為運營商必爭之地。

　　然而，要想實現(xiàn)運營級的IP視頻業(yè)務(wù)，傳統(tǒng)的IP協(xié)議是無法勝任的。

　　為了實現(xiàn)運營級的視頻業(yè)務(wù)，IP協(xié)議必須改進！

　　在IP網(wǎng)上實現(xiàn)視頻傳輸，除了需要解決寬帶接入問題和研制更有效的壓縮算法外，對傳統(tǒng)IP協(xié)議的改進必不可少。在這些改進中，IP QoS和IP組播是最重要的兩個部分。

　　傳統(tǒng)IP：承載視頻很困難

　　在早期，IP網(wǎng)絡(luò)只跑數(shù)據(jù)業(yè)務(wù)（比如www或者E-mail）時，這種處理方式是適用的。但當(dāng)IP網(wǎng)絡(luò)上傳輸?shù)膱笪牟辉賰H僅是數(shù)據(jù)業(yè)務(wù)，還包括了對實時性要求很高的語音和視頻時，就需要IP協(xié)議能夠?qū)Σ煌瑘笪淖霾煌膶Υ�，就此引入QoS。

　　另外，傳統(tǒng)的IP通信是在一個源IP主機和一個目標(biāo)IP主機之間（單播）或者一個源IP主機和網(wǎng)絡(luò)中所有的IP主機之間（廣播）進行的。在視頻廣播應(yīng)用中，要將信息發(fā)送給網(wǎng)絡(luò)中的多個而非所有IP主機。在傳統(tǒng)IP協(xié)議里，要么采用廣播方式，要么由源IP主機分別向網(wǎng)絡(luò)中的多個目標(biāo)IP主機發(fā)送IP包。前一種方式不僅會將信息發(fā)送給不需要的IP主機而浪費帶寬，也可能由于路由回環(huán)引起一場嚴(yán)重的廣播風(fēng)暴；而后一種方式由于IP包的重復(fù)發(fā)送而白白浪費掉大量帶寬，也增加了服務(wù)器的負(fù)載�？梢哉f傳統(tǒng)的IP通信技術(shù)不能有效地解決單點發(fā)送多點接收的問題。

　　QoS：為視頻傳輸保駕護航

　　在傳統(tǒng)的IP網(wǎng)絡(luò)中，所有的報文都無區(qū)地的等同對待，每個路由器對所有的報文采用先入先出的策略（FIFO）處理，它盡最大的努力（Best-Effort）將報文送到目的地，見圖1。

　　為了實現(xiàn)QoS，需要改變傳統(tǒng)IP網(wǎng)絡(luò)的FIFO隊列傳輸報文機制，轉(zhuǎn)而采用優(yōu)先級隊列（Priority Queueing, PQ）機制，見圖2。

　　PQ機制對報文進行分類，將所有報文分成最多至4類，分別屬于PQ的4個隊列中的一個。然后，按報文的類別將報文送入相應(yīng)的隊列。PQ的4個隊列分別為高優(yōu)先隊列、中優(yōu)先隊列、正常優(yōu)先隊列和低優(yōu)先隊列，它們的優(yōu)先級依次降低。在報文出隊的時候，PQ首先讓高優(yōu)先級隊列中的報文出隊并發(fā)送，直到高優(yōu)先隊列中的報文發(fā)送完，然后發(fā)送中優(yōu)先隊列中的報文。同樣，直到發(fā)送完，然后是正常優(yōu)先隊列和低優(yōu)先隊列。這樣，分類時屬于較高優(yōu)先級隊列的報文將會得到優(yōu)先發(fā)送，而較低優(yōu)先級的報文將會在發(fā)生擁塞時被較高優(yōu)先級的報文搶先。使得實時業(yè)務(wù)（如Video）的報文能夠得到優(yōu)先處理，非實時業(yè)務(wù)（如E-mail）的報文在網(wǎng)絡(luò)處理完實時業(yè)務(wù)后的空閑中得到處理。既保證了實時業(yè)務(wù)的優(yōu)先，又充分利用了網(wǎng)絡(luò)資源。

　　當(dāng)前的IP協(xié)議能夠支持三種QoS模型，見表1。

　　Best-Effort是一個單一的服務(wù)模型，也是最簡單的服務(wù)模型。應(yīng)用程序可以在任何時候，發(fā)出任意數(shù)量的報文，而且不需要事先獲得批準(zhǔn)，也不需要通知網(wǎng)絡(luò)。對Best-Effort服務(wù)，網(wǎng)絡(luò)盡最大的努力來發(fā)送報文，但對時延、可靠性等性能不提供任何保證。 Best-Effort服務(wù)是現(xiàn)在Internet的缺省服務(wù)模型，它適用于絕大多數(shù)網(wǎng)絡(luò)應(yīng)用，如FTP、E-mail等，它通過先入先出（FIFO）隊列來實現(xiàn)。

　　Intserv是一個綜合服務(wù)模型，它可以滿足多種QoS需求。這種服務(wù)模型在發(fā)送報文前，需要向網(wǎng)絡(luò)申請?zhí)囟ǖ姆⻊?wù)。這個請求是通過信令（Signal）來完成的。傳送QoS請求的信令是RSVP（資源預(yù)留協(xié)議），它將應(yīng)用程序的QoS需求通知給路由器。應(yīng)用程序首先通知網(wǎng)絡(luò)它自己的流量參數(shù)和需要的特定服務(wù)質(zhì)量請求，包括帶寬、時延等。應(yīng)用程序一般在收到網(wǎng)絡(luò)的確認(rèn)信息，即網(wǎng)絡(luò)已經(jīng)為這個應(yīng)用程序的報文預(yù)留了資源后，發(fā)送報文。而應(yīng)用程序發(fā)出的報文應(yīng)該控制在流量參數(shù)描述的范圍內(nèi)。

　　網(wǎng)絡(luò)在收到應(yīng)用程序的資源請求后，執(zhí)行資源分配檢查（Admission Control），即基于應(yīng)用程序的資源申請和網(wǎng)絡(luò)現(xiàn)有的資源情況，判斷是否為應(yīng)用程序分配資源。一旦網(wǎng)絡(luò)確認(rèn)已經(jīng)為應(yīng)用程序的報文分配了資源，則只要應(yīng)用程序的報文被控制在流量參數(shù)描述的范圍內(nèi)，網(wǎng)絡(luò)就會承諾滿足應(yīng)用程序的QoS需求。而網(wǎng)絡(luò)將為每個流（Flow，由兩端的IP地址、端口號、協(xié)議號確定）維護一個狀態(tài)，并基于這個狀態(tài)執(zhí)行報文的分類、流量監(jiān)管（Policing）、排隊及其調(diào)度，來滿足對應(yīng)用程序的承諾。

　　Diffserv是一個多服務(wù)模型，它可以滿足不同的QoS需求。與Intserv不同，它不需要信令，即應(yīng)用程序在發(fā)出報文前，不需要通知路由器。對Diffserv，網(wǎng)絡(luò)不需要為每個流維護狀態(tài)，它根據(jù)每個報文指定的QoS，來提供特定的服務(wù)�？梢杂貌煌姆椒▉碇付▓笪牡腝oS，如IP包的優(yōu)先級位（IP Precedence)、報文的源地址和目的地址等。網(wǎng)絡(luò)通過這些信息來進行報文的分類、流量整形、流量監(jiān)管和排隊。

　　通常在配置Diffserv時，邊界路由器通過報文的源地址和目的地址等對報文進行分類，對不同的報文設(shè)置不同的IP優(yōu)先級，而其他路由器則只需要用IP優(yōu)先級位來進行報文的分類。

　　IP組播：使視頻廣播成為可能

　　IP組播技術(shù)允許源IP主機將IP信息包發(fā)送到IP網(wǎng)絡(luò)上的任意一組目標(biāo)主機上，可以有效地解決單點發(fā)送多點接收、多點發(fā)送多點接收的問題。在實際使用IP組播技術(shù)時，首先需要定義一個組播地址（Group Address），每個組播地址代表源IP主機與目的IP主機之間的一個會話（Session）。目的IP主機可以使用組播地址告訴路由器，該主機希望加入或退出那一個組播組，IP組播協(xié)議能初始化或終止從源IP主機到該目標(biāo)IP主機的數(shù)據(jù)流。然后，源IP主機就可以使用組播地址發(fā)送分組。源IP主機可以不知道任何有關(guān)目的IP主機的信息，如IP目標(biāo)主機在什么位置等，它只要知道組播地址即可。

　　由于組播地址資源非常有限，控制組播地址分配的IANA傾向于為特定網(wǎng)絡(luò)協(xié)議的使用確定單獨的IP組播地址，也就是說剩余的IP組播地址是以動態(tài)的、合作的方式被整個網(wǎng)絡(luò)使用。組播應(yīng)用要求有一個地址管理服務(wù)機制來管理和分配組播地址。目前組播應(yīng)用有三種方法可以獲得組播地址，包括硬編地址、聲明地址、以及計算推導(dǎo)等等。

　　IP組播在實際應(yīng)用中需要解決由于不同目的主機所處不同網(wǎng)絡(luò)環(huán)境而帶來的問題。因特網(wǎng)是由許多網(wǎng)絡(luò)連接起來構(gòu)成的一個世界范圍的大型網(wǎng)絡(luò)，而構(gòu)成因特網(wǎng)的許多局部網(wǎng)絡(luò)之間，在數(shù)據(jù)傳輸速度、穩(wěn)定性、可靠性等方面存在巨大的差異，同時因特網(wǎng)中發(fā)生擁塞的時間、地點也是隨機的、不可預(yù)測的。IP組播應(yīng)用應(yīng)能適應(yīng)這樣不同的網(wǎng)絡(luò)環(huán)境，提供用戶滿意的組播服務(wù)。

　　當(dāng)網(wǎng)絡(luò)不能滿足現(xiàn)有的數(shù)據(jù)發(fā)送速率時，單播應(yīng)用可以使用傳送層的TCP協(xié)議來自動調(diào)節(jié)數(shù)據(jù)發(fā)送速率（盡管較低的數(shù)據(jù)發(fā)送速度可能不滿足CBR需求），或者在應(yīng)用層使用回饋循環(huán)機制來調(diào)節(jié)數(shù)據(jù)本身（如改變數(shù)據(jù)的分辨率、使用有損壓縮技術(shù)等）以達到降低數(shù)據(jù)發(fā)送速率的目的。而IP組播應(yīng)用有多個目的主機，上述方法顯然不能照搬。首先不管是TCP協(xié)議還是回饋循環(huán)機制都要求目的主機向源主機匯報接收情況（如：數(shù)據(jù)丟失、傳送錯誤等），如果許多目的主機同時向發(fā)送者發(fā)出數(shù)據(jù)丟失報告，源主機很可能被一場嚴(yán)重的“應(yīng)答報文風(fēng)暴”淹沒。同時一個組播組中，不同的目的主機其網(wǎng)絡(luò)帶寬和接收能力有很大的差異，如果發(fā)送者按照最低接收能力目的主機的要求來調(diào)節(jié)發(fā)送速度，那么它只能提供較差的服務(wù)。為解決上述問題，人們提出了許多方法來支持異種目的主機，其中比較著名的有應(yīng)答報文抑制機制（如果一個接收者發(fā)現(xiàn)報文錯誤或丟失，它并不立即向發(fā)送者發(fā)送應(yīng)答報文，而是等待一個隨機時間，在這段時間內(nèi)如果監(jiān)聽到別的接收者向發(fā)送者發(fā)送報文出錯應(yīng)答，就不再發(fā)送應(yīng)答報文，否則該接收者向發(fā)送者發(fā)送報文出錯應(yīng)答），和設(shè)立托管節(jié)點機制（將網(wǎng)絡(luò)中的部分目的主機設(shè)計成局部托管節(jié)點，作為源主機和本局部網(wǎng)絡(luò)所有目　　的主機之間的橋梁和中轉(zhuǎn)站。托管結(jié)點可以對出錯的報文進行重發(fā)，也可以對源主機發(fā)來的組播包進行重新編碼，以降低數(shù)據(jù)傳送速率，還可以向源主機發(fā)送應(yīng)答報文）。


圖1 傳統(tǒng)IP網(wǎng)絡(luò)傳輸報文模式


圖2 PQ傳輸示意圖

賽迪網(wǎng) 中國信息化(industry.ccidnet.com)

相關(guān)鏈接:
視頻通信新奇軍 2003-11-21
國內(nèi)視頻是否會重蹈寬帶覆轍？ 2003-11-20
視頻會議系統(tǒng)市場評估及預(yù)測 2003-11-19
會議電視系統(tǒng)在ATM網(wǎng)絡(luò)中的應(yīng)用 2003-11-19
網(wǎng)絡(luò)視頻時代為期不遠 2003-11-05

分類信息:  網(wǎng)絡(luò)文摘_與_視像通訊     文摘   網(wǎng)絡(luò)文摘   技術(shù)_視像通訊_文摘