IPv6對多媒體傳輸?shù)闹С謃第1頁
IPv6對多媒體傳輸?shù)闹С謃第2頁
IPv6對多媒體傳輸?shù)闹С謃第3頁
IPv6對多媒體傳輸?shù)闹С謃第4頁
全文預覽已結束

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、IPv6 對多媒體傳輸?shù)闹С諭Pv4 的簡單和靈活特性,使得它被廣泛地應用和部署。但是隨著 TCP/IP 協(xié)議體系的廣 泛應用, IPv4 版本的缺點就暴露出來了,例如地址空間不夠、不支持多媒體傳輸、安全問 題等,這些問題不是通過修修補補就能夠解決的,因此 IPv6 應運而生。 IPv6 有許多新的特 性和能力, 例如巨大的地址空間、移動支持、 安全性等, 本文主要從概念上討論其中的多媒 體傳輸支持。一、多媒體傳輸?shù)男枨蠓治?與常規(guī)的字符數(shù)值型數(shù)據(jù)相比, 多媒體數(shù)據(jù)在通信網(wǎng)絡上進行傳輸會有什么不同呢?需要特 殊地考慮嗎?為了清楚地說明以上問題, 我們從多媒體數(shù)據(jù)在網(wǎng)絡上傳輸會帶來什么問題入 手

2、。我們從通信和網(wǎng)絡的角度來看多媒體數(shù)據(jù)的特性。 我們知道, 數(shù)據(jù)在網(wǎng)絡上傳輸, 是需要把 數(shù)據(jù)打包后,一個一個傳輸?shù)?。這個包,在不同的網(wǎng)絡層,名稱不一樣,可以是報文段、數(shù) 據(jù)包或幀。我們把按時間相關的方式傳輸?shù)囊幌盗袛?shù)據(jù)包稱為數(shù)據(jù)流。對于多媒體傳輸來說, 主要問題出在連續(xù)媒體的傳輸上。 我們說連續(xù)媒體, 是針對媒體通信 中的數(shù)據(jù)流來說的。 前面說了, 數(shù)據(jù)流是由數(shù)據(jù)包組成的。 那么這些數(shù)據(jù)包有什么特性呢? 不同的特性, 將對媒體數(shù)據(jù)的傳輸造成明顯的影響。 連續(xù)媒體的特點是相繼傳輸?shù)臄?shù)據(jù)包之 間的間隔基本上是周期性的, 數(shù)據(jù)包的大小的變化基本是有規(guī)律的。 典型的連續(xù)媒體是音頻 和視頻。相對應的,

3、不滿足連續(xù)媒體特性的媒體我們稱為離散媒體,例如圖像、圖形,以及 其他的數(shù)據(jù)流,例如鼠標移動產(chǎn)生的數(shù)據(jù)流等。這里,我們需要強調的是,連續(xù)媒體的傳輸,有嚴格的時間約束,而離散媒體沒有。時間上 的約束不同于實時控制信息傳輸?shù)募s束, 后者需要嚴格的實時傳輸約束, 實時獲取的信息用 于控制和管理, 但是實時控制信息之間的間隔可能沒有周期性。 而多媒體傳輸與常規(guī)字符數(shù) 值數(shù)據(jù)一個重要的不同是: 連續(xù)媒體數(shù)據(jù)包的傳遞是周期性的, 其提交給用戶的表現(xiàn)需要一 個過程, 這個過程是需要用戶感知的, 例如音頻和視頻需要基于時間的播放, 才能表達其中 的含義, 用戶直接觀察和聆聽媒體的表現(xiàn)。 如果傳輸過程中的時間約束

4、不能滿足用戶接收并 感知的要求,用戶就難以接受音頻或視頻攜帶的信息。因此, 總結出來, 多媒體傳輸?shù)闹饕?需求是:(1) 帶寬。多媒體傳輸需要較大的帶寬,實際就是傳輸數(shù)據(jù)率。如果是64kbps,那么只能傳輸郵票大小的視頻。帶寬達到384kbps以上,就可以傳輸較為清晰的視頻。當然,這里說的是一路視頻的帶寬,如果要傳輸多路視頻和音頻,要求的帶寬要大得多。(2) 延遲。這里指的是端到端的延遲。許多人往往忽略對延遲特性的要求,人們往往更關注帶寬??缭骄W(wǎng)絡的端到端延遲因素復雜,它包括編碼和解碼時間、發(fā)送時間、傳播時間、 緩沖時間和協(xié)議的介質訪問時間。 其中編碼和解碼時間, 以及接收端緩沖時間是多媒體引

5、入 的。因為連續(xù)媒體的受眾是人, 而不是機器, 人對視覺和聽覺的感知是有特別的約束的。尤 其是交互式多媒體應用中, 例如可視電話和視頻會議應用, 視頻和音頻是雙向的, 視頻和音 頻的傳輸支持用戶的交互,因此對于延遲有嚴格的要求,端到端的延遲要求小于 150ms。對于單向傳輸?shù)亩嗝襟w應用來說, 這個約束要寬松得多, 例如視頻點播應用。 視頻點播應用的 端到端延遲可以是秒級,但是我們注意到,它受到以下抖動和時滯因素的約束。(3) 抖動和時滯。端到端的延遲約束還不夠,對于時間特性的約束來說,還有抖動和時滯的約束。 什么是抖動和時滯?是由于端到端傳輸延遲的變化而引起的。由于網(wǎng)絡通路的復雜性,中間要經(jīng)過

6、路由器和不同的鏈路,甚至是不同的路徑,每個數(shù)據(jù)包歷經(jīng)的延遲不一樣, 這就造成實際的數(shù)據(jù)包到達時間與理想的時間不一樣。 實際到達時間與理想到達時間的差就 是抖動。我們把這些瞬間差稱為抖動,而把這些差積累的平均值,稱為時滯。抖動又可以劃 分為媒體內抖動和媒體間抖動, 前者指單個媒體傳輸中, 相繼數(shù)據(jù)包之間的間隔不均勻, 造 成畫面或聲音顫抖; 后者是指兩個媒體的對應數(shù)據(jù)包到達時間變化, 后果可能是造成唇同步 的丟失。 時滯是平均差值, 因此反映的是整體的偏差。 時滯也分為媒體內時滯和媒體間時滯, 媒體內時滯是針對單媒體的, 表示一個媒體傳輸中, 數(shù)據(jù)包整體超前或滯后, 結果造成畫面 過快或過慢,

7、聲音的音調變高或變低; 媒體間的時滯是指兩個媒體中對應數(shù)據(jù)包的整體偏差, 或超前或滯后,由此引起媒體間的同步完全喪失。(4)差錯控制。一般地,差錯控制方法是采用檢錯和反饋重發(fā)方式,但是重發(fā)方式的差錯 控制不適合連續(xù)媒體的傳輸, 因為重發(fā)數(shù)據(jù)包, 一方面會影響數(shù)據(jù)包的循序, 另一方面是影 響媒體流的實時性, 重發(fā)的數(shù)據(jù)包到達接收端的時候, 時間太晚了, 它之后的時間包已經(jīng)播 放,因此這種情況下,重發(fā)的數(shù)據(jù)包沒有價值,除非重發(fā)的速度非常快,重發(fā)的數(shù)據(jù)包在它 后面的數(shù)據(jù)包播放之前到達才有意義。那么,連續(xù)媒體流需要采用什么樣的差錯控制機制 呢?幸好, 對于多媒體數(shù)據(jù)來說,其攜帶的是視聽感知信息, 對于

8、人來說, 允許觀看和聆聽 的數(shù)據(jù)有一定程度的差錯。不同的媒體,差錯容忍的程度不同。音頻要比視頻的容忍度低, 壓縮數(shù)據(jù)要比非壓縮數(shù)據(jù)低。 在差錯容忍度范圍內, 傳輸?shù)拿襟w數(shù)據(jù)可以不做差錯控制。 如 果差錯率較高, 那么就需要一些特殊的差錯控制方法, 例如底層做差錯檢測后, 讓高層進行 處理, 縮短差錯處理的整體時間; 采用新的差錯恢復和差錯復原技術, 在接收端盡量恢復原 始數(shù)據(jù)或糾正錯誤。(5)多播。在過去的網(wǎng)絡技術中,就有多播協(xié)議,但是多媒體引入網(wǎng)絡,給多播機制帶來 新的需求。 因為多媒體數(shù)據(jù)量大, 如果要把同樣的多媒體數(shù)據(jù)傳送給多個目的站, 一個站一 個站地傳輸, 顯然會占用大量的帶寬, 還

9、不能實現(xiàn)實時同步傳送媒體數(shù)據(jù)。 而多播機制可以 做得到,特別適合傳輸多媒體數(shù)據(jù), 尤其是大量的接收用戶情況, 例如視頻會議系統(tǒng)、 網(wǎng)絡 電視應用等。因此,多播能力的支持,是傳輸多媒體數(shù)據(jù)的一種重要特性。這些特性要求用一組參數(shù)來描述和表達,就是服務質量 QoS。支持多媒體傳輸就是要能夠為應用提供其所需的 QoS。在了解這些特性的問題的基礎上,下面我們就容易分析出IPv6在哪些方面與多媒體傳輸有關了。二、IPv6 的特點與首部在 1990 年, IETF 開始了新版本 IP 協(xié)議建議的征集工作。 1993 年在 IEEE Network 雜志上發(fā) 表了其中 3 篇較好的建議。后來, Deering

10、 和 Francis 提交的建議被采納,經(jīng)過綜合和修改, 被命名為 IPv6。 IPv6 的主要目標是:(1)重新設置地址空間,支持巨大數(shù)量的主機,為未來各種計算機設備聯(lián)網(wǎng)打下基礎;(2)減少路由表的大小,簡化協(xié)議,使得路由器處理分組更快,減少傳輸延遲,減輕延遲 抖動和時滯;(3)比現(xiàn)有 IP 協(xié)議提供更好的安全性;(4)更加注重服務類型,尤其是實時數(shù)據(jù)類型;(5)改進多播能力,允許指定多播的范圍;(6)主機在漫游的時候,可以不改變地址,更好地支持移動計算;(7)協(xié)議具有可擴展性;(8)新的協(xié)議與現(xiàn)有協(xié)議可以共同運行。從以上目標看,其中第( 2)、(4)、( 5)直接與多媒體傳輸有關。我們注意

11、到,IPv6 并不與IPv4 兼容,但是它與其他相關的 Internet 協(xié)議兼容, 這些協(xié)議包括 TCP、UDP、ICMP、OSPF、 BGP和DNS,但是可能需要做一些小的修改,大部分涉及到更大的地址空間方面的修改。 這樣有利于 IPv6 部署到現(xiàn)有網(wǎng)絡中。為了更好地理解IPv6如何支持多媒體,我們需要看一看它的數(shù)據(jù)包結構, 如圖1和2所示。 其中的一些字段在其他文獻中有解釋, 本文主要根據(jù)它包含的與多媒體相關的字段, 從多個方面來看 IPv6 如何支持多媒體傳輸。三、IPv6 的哪些特性可以支持多媒體傳輸1支持實時數(shù)據(jù)傳輸在首部中包含 “通信量類別 ”字段,如圖 1 所示。用于說明通信量

12、的類別,以支持分級服務 ( Differentiated Service )。分級服務體系結構中, IPv6 數(shù)據(jù)包首部的 “通信量類別 ”字段重新 定義為 分級服務字段” DS DS字段有8個比特,其中6個比特表示分級服務碼點DSCP, 2個比特當前還沒有被使用。 在處理連續(xù)媒體排隊的時候, 路由器可以根據(jù)這個字段, 把連續(xù) 媒體類別放到優(yōu)先級比較高的隊列中, 從而加快轉發(fā)的速度, 而其他通信量類別 (例如 TCP 數(shù)據(jù))的數(shù)據(jù)放置在較低優(yōu)先級隊列中。事實上,用于這種目的的字段在早期的 IPv4 中就有,如圖 2中的“服務類型 ”字段,但是這 個字段很少被路由器實現(xiàn)和使用。另外,首部中還包含

13、一個新的流標簽”字段。這里的 流”(Flow)在網(wǎng)絡學術和技術領域是一個常用的名詞, 它指的是在網(wǎng)絡上傳輸?shù)摹?與端到端 (一個主機發(fā)送到一個單播地址或一 個多播地址)相關聯(lián)的數(shù)據(jù)包序列。 給流打上標簽,表示哪些分組屬于相同數(shù)據(jù)流,使得源 端和目的端可以建立一種具有某種特性和滿足特殊要求的 “偽”連接(不是真實的連接) 。這 樣,采用流標簽,不需要用連接建立分組去通知參與的結點,告訴它們流的特性和QoS 需求是什么, 從而可以實現(xiàn)過去需要建立連接才能實現(xiàn)的 QoS 協(xié)商機制。 因此, 流標簽是 IPv6 在 IP 層實現(xiàn) QoS 保障和資源預留的一個重要字段。每個流用源端的地址、目的地址和流標

14、 簽來確定。注意到, IPv6 的流標簽只有結合某個控制協(xié)議才起作用,協(xié)議將規(guī)定主機和路 由器如何處理某個流的分組。2 改善傳輸?shù)难舆t和抖動IPv6 顯著簡化了數(shù)據(jù)包的首部,把常用的字段留下,不常用的放在擴展首部中。除了版本字段, IPv6 的首部只包含 7個字段, 而 IPv4 首部有 13個字段。 這個改變使得路由器的分組 處理數(shù)據(jù)更快,因此增加了網(wǎng)絡的吞吐量,減少了傳輸延遲。IPv4 的有些字段在 IPv6 中沒有, 但是這些字段偶爾也會使用, 因此 IPv6 引入了擴展首部的 概念。對于擴展首部, IPv6 有新的考慮,擴展首部的使用更加有效率。以前某些在首部中 使用的字段, 現(xiàn)在列為

15、可選, 即放入到擴展首部中。 這里的問題是如何設計和表示擴展首部 及其選項,達到簡化路由處理、減少數(shù)據(jù)報處理時間的目的。我們注意到,在IPv6 數(shù)據(jù)包結構中有一個字段是 “下一個首部 ”,其設置目的就是簡化 IP 數(shù)據(jù)報的首部。如果有擴展首 部,那么該字段標示下面跟的是哪種類型的擴展字段。 目前定義了 6種擴展首部, 它們必須 直接跟在固定首部之后。如果該首部是最后一個 IP 首部,那么 “下一個首部 ”字段指示本數(shù) 據(jù)包中的數(shù)據(jù)部分放的是什么傳送層協(xié)議,例如如果是 TCP 協(xié)議,該值是 6,如果是 UDP 協(xié)議,該值為 7。這時,該字段的含義與 IPv4 中的“協(xié)議”字段的含義相同。比較圖1

16、和圖2中的IPv6和IPv4格式,發(fā)現(xiàn)IPv4的 首都長度” IHL字段沒有了,這是因為 IPv6 的首部是固定長度的。另外,我們還注意到,與分片相關的所有字段都去掉了,這是 因為 IPv6 采用不同的方法進行分片處理。實踐中發(fā)現(xiàn),在端點,即發(fā)送分組的主機,發(fā)送 合適大小的分組,要比讓路由器進行分片處理,效率要好得多。因此,我們希望所有IPv6主機能夠動態(tài)確定發(fā)送數(shù)據(jù)報的大小。 這個規(guī)則表明在端點很少可能進行分片。 同時, 數(shù)據(jù) 包大小的最小值已經(jīng)從 576 增加到 1280,以便能夠放下 1024個字節(jié)和多個首部。另外,當 一個主機發(fā)送的一個 IPv6 數(shù)據(jù)包太大的時候,不是對它分片,而是由

17、不能轉發(fā)該分組的路 由器反饋一個錯誤消息。 這個消息告訴主機調整所有以后發(fā)送到目的地的分組, 減小發(fā)送數(shù) 據(jù)包的大小。還有, “首部校驗和 ”字段也沒有了,因為進行首部校驗和的計算會減少傳輸性3. 多播的改進對多播尋址方式進行了改進, 允許把多播路由限制在指定的區(qū)域中。 在多播地址中, 增加了 “范圍( scope) ”字段,限制一個地址的有效范圍,例如把多播限制在一個企業(yè)的內聯(lián)網(wǎng)中。 用“標志( flags )”字段來區(qū)分永久和臨時的多播組地址。通過這些新的字段設置,改善了多 播通信的尋址方式, 方便在網(wǎng)絡上實現(xiàn)多播數(shù)據(jù)傳輸, 有利于分布多媒體應用的實施和部署。4. 差錯控制和流量控制在網(wǎng)絡層, IPv6 仍然是非連接的,沒有差錯控制和

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論