視頻壓彎了IP網
2003/11/24
IP融合，大勢所趨。
繼IP電話后，IP視頻業(yè)務已成為運營商必爭之地。
然而，要想實現(xiàn)運營級的IP視頻業(yè)務，傳統(tǒng)的IP協(xié)議是無法勝任的。
為了實現(xiàn)運營級的視頻業(yè)務，IP協(xié)議必須改進！
在IP網上實現(xiàn)視頻傳輸，除了需要解決寬帶接入問題和研制更有效的壓縮算法外，對傳統(tǒng)IP協(xié)議的改進必不可少。在這些改進中，IP QoS和IP組播是最重要的兩個部分。
傳統(tǒng)IP：承載視頻很困難
在早期，IP網絡只跑數(shù)據業(yè)務（比如www或者E-mail）時，這種處理方式是適用的。但當IP網絡上傳輸?shù)膱笪牟辉賰H僅是數(shù)據業(yè)務，還包括了對實時性要求很高的語音和視頻時，就需要IP協(xié)議能夠對不同報文做不同的對待，就此引入QoS。
另外，傳統(tǒng)的IP通信是在一個源IP主機和一個目標IP主機之間（單播）或者一個源IP主機和網絡中所有的IP主機之間（廣播）進行的。在視頻廣播應用中，要將信息發(fā)送給網絡中的多個而非所有IP主機。在傳統(tǒng)IP協(xié)議里，要么采用廣播方式，要么由源IP主機分別向網絡中的多個目標IP主機發(fā)送IP包。前一種方式不僅會將信息發(fā)送給不需要的IP主機而浪費帶寬，也可能由于路由回環(huán)引起一場嚴重的廣播風暴；而后一種方式由于IP包的重復發(fā)送而白白浪費掉大量帶寬，也增加了服務器的負載�？梢哉f傳統(tǒng)的IP通信技術不能有效地解決單點發(fā)送多點接收的問題。
QoS：為視頻傳輸保駕護航
在傳統(tǒng)的IP網絡中，所有的報文都無區(qū)地的等同對待，每個路由器對所有的報文采用先入先出的策略（FIFO）處理，它盡最大的努力（Best-Effort）將報文送到目的地，見圖1。
為了實現(xiàn)QoS，需要改變傳統(tǒng)IP網絡的FIFO隊列傳輸報文機制，轉而采用優(yōu)先級隊列（Priority Queueing, PQ）機制，見圖2。
PQ機制對報文進行分類，將所有報文分成最多至4類，分別屬于PQ的4個隊列中的一個。然后，按報文的類別將報文送入相應的隊列。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è)務（如Video）的報文能夠得到優(yōu)先處理，非實時業(yè)務（如E-mail）的報文在網絡處理完實時業(yè)務后的空閑中得到處理。既保證了實時業(yè)務的優(yōu)先，又充分利用了網絡資源。
當前的IP協(xié)議能夠支持三種QoS模型，見表1。
Best-Effort是一個單一的服務模型，也是最簡單的服務模型。應用程序可以在任何時候，發(fā)出任意數(shù)量的報文，而且不需要事先獲得批準，也不需要通知網絡。對Best-Effort服務，網絡盡最大的努力來發(fā)送報文，但對時延、可靠性等性能不提供任何保證。 Best-Effort服務是現(xiàn)在Internet的缺省服務模型，它適用于絕大多數(shù)網絡應用，如FTP、E-mail等，它通過先入先出（FIFO）隊列來實現(xiàn)。
Intserv是一個綜合服務模型，它可以滿足多種QoS需求。這種服務模型在發(fā)送報文前，需要向網絡申請?zhí)囟ǖ姆⻊�。這個請求是通過信令（Signal）來完成的。傳送QoS請求的信令是RSVP（資源預留協(xié)議），它將應用程序的QoS需求通知給路由器。應用程序首先通知網絡它自己的流量參數(shù)和需要的特定服務質量請求，包括帶寬、時延等。應用程序一般在收到網絡的確認信息，即網絡已經為這個應用程序的報文預留了資源后，發(fā)送報文。而應用程序發(fā)出的報文應該控制在流量參數(shù)描述的范圍內。
網絡在收到應用程序的資源請求后，執(zhí)行資源分配檢查（Admission Control），即基于應用程序的資源申請和網絡現(xiàn)有的資源情況，判斷是否為應用程序分配資源。一旦網絡確認已經為應用程序的報文分配了資源，則只要應用程序的報文被控制在流量參數(shù)描述的范圍內，網絡就會承諾滿足應用程序的QoS需求。而網絡將為每個流（Flow，由兩端的IP地址、端口號、協(xié)議號確定）維護一個狀態(tài)，并基于這個狀態(tài)執(zhí)行報文的分類、流量監(jiān)管（Policing）、排隊及其調度，來滿足對應用程序的承諾。
Diffserv是一個多服務模型，它可以滿足不同的QoS需求。與Intserv不同，它不需要信令，即應用程序在發(fā)出報文前，不需要通知路由器。對Diffserv，網絡不需要為每個流維護狀態(tài)，它根據每個報文指定的QoS，來提供特定的服務�？梢杂貌煌姆椒▉碇付▓笪牡腝oS，如IP包的優(yōu)先級位（IP Precedence)、報文的源地址和目的地址等。網絡通過這些信息來進行報文的分類、流量整形、流量監(jiān)管和排隊。
通常在配置Diffserv時，邊界路由器通過報文的源地址和目的地址等對報文進行分類，對不同的報文設置不同的IP優(yōu)先級，而其他路由器則只需要用IP優(yōu)先級位來進行報文的分類。
IP組播：使視頻廣播成為可能
IP組播技術允許源IP主機將IP信息包發(fā)送到IP網絡上的任意一組目標主機上，可以有效地解決單點發(fā)送多點接收、多點發(fā)送多點接收的問題。在實際使用IP組播技術時，首先需要定義一個組播地址（Group Address），每個組播地址代表源IP主機與目的IP主機之間的一個會話（Session）。目的IP主機可以使用組播地址告訴路由器，該主機希望加入或退出那一個組播組，IP組播協(xié)議能初始化或終止從源IP主機到該目標IP主機的數(shù)據流。然后，源IP主機就可以使用組播地址發(fā)送分組。源IP主機可以不知道任何有關目的IP主機的信息，如IP目標主機在什么位置等，它只要知道組播地址即可。
由于組播地址資源非常有限，控制組播地址分配的IANA傾向于為特定網絡協(xié)議的使用確定單獨的IP組播地址，也就是說剩余的IP組播地址是以動態(tài)的、合作的方式被整個網絡使用。組播應用要求有一個地址管理服務機制來管理和分配組播地址。目前組播應用有三種方法可以獲得組播地址，包括硬編地址、聲明地址、以及計算推導等等。
IP組播在實際應用中需要解決由于不同目的主機所處不同網絡環(huán)境而帶來的問題。因特網是由許多網絡連接起來構成的一個世界范圍的大型網絡，而構成因特網的許多局部網絡之間，在數(shù)據傳輸速度、穩(wěn)定性、可靠性等方面存在巨大的差異，同時因特網中發(fā)生擁塞的時間、地點也是隨機的、不可預測的。IP組播應用應能適應這樣不同的網絡環(huán)境，提供用戶滿意的組播服務。
當網絡不能滿足現(xiàn)有的數(shù)據發(fā)送速率時，單播應用可以使用傳送層的TCP協(xié)議來自動調節(jié)數(shù)據發(fā)送速率（盡管較低的數(shù)據發(fā)送速度可能不滿足CBR需求），或者在應用層使用回饋循環(huán)機制來調節(jié)數(shù)據本身（如改變數(shù)據的分辨率、使用有損壓縮技術等）以達到降低數(shù)據發(fā)送速率的目的。而IP組播應用有多個目的主機，上述方法顯然不能照搬。首先不管是TCP協(xié)議還是回饋循環(huán)機制都要求目的主機向源主機匯報接收情況（如：數(shù)據丟失、傳送錯誤等），如果許多目的主機同時向發(fā)送者發(fā)出數(shù)據丟失報告，源主機很可能被一場嚴重的“應答報文風暴”淹沒。同時一個組播組中，不同的目的主機其網絡帶寬和接收能力有很大的差異，如果發(fā)送者按照最低接收能力目的主機的要求來調節(jié)發(fā)送速度，那么它只能提供較差的服務。為解決上述問題，人們提出了許多方法來支持異種目的主機，其中比較著名的有應答報文抑制機制（如果一個接收者發(fā)現(xiàn)報文錯誤或丟失，它并不立即向發(fā)送者發(fā)送應答報文，而是等待一個隨機時間，在這段時間內如果監(jiān)聽到別的接收者向發(fā)送者發(fā)送報文出錯應答，就不再發(fā)送應答報文，否則該接收者向發(fā)送者發(fā)送報文出錯應答），和設立托管節(jié)點機制（將網絡中的部分目的主機設計成局部托管節(jié)點，作為源主機和本局部網絡所有目 的主機之間的橋梁和中轉站。托管結點可以對出錯的報文進行重發(fā)，也可以對源主機發(fā)來的組播包進行重新編碼，以降低數(shù)據傳送速率，還可以向源主機發(fā)送應答報文）。
圖1 傳統(tǒng)IP網絡傳輸報文模式
圖2 PQ傳輸示意圖
賽迪網
中國信息化(industry.ccidnet.com)
相關鏈接: