首頁 > 通信工程師 > 互聯(lián)網(wǎng)技術(shù) > 通信工程師互聯(lián)網(wǎng)技術(shù)考試IPv6的QoS機制

通信工程師互聯(lián)網(wǎng)技術(shù)考試IPv6的QoS機制

互聯(lián)網(wǎng)技術(shù) 責(zé)任編輯：long_18 2013-12-03

摘要：通信工程師互聯(lián)網(wǎng)技術(shù)考試IPv6的QoS機制：隨著Internet規(guī)模的不斷增大，各種各樣的網(wǎng)絡(luò)服務(wù)爭相涌現(xiàn)，先進的多媒體系統(tǒng)層出不窮，Internet需要能夠同時支持已有和新出現(xiàn)的應(yīng)用和服務(wù)。

5.9 IPv6的QoS機制
5.9.1 IPv6與QoS
隨著Internet規(guī)模的不斷增大，各種各樣的網(wǎng)絡(luò)服務(wù)爭相涌現(xiàn)，先進的多媒體系統(tǒng)層出不窮，Internet需要能夠同時支持已有和新出現(xiàn)的應(yīng)用和服務(wù)。由于IPv4的某些局限性，現(xiàn)有的IP網(wǎng)絡(luò)暴露出了很多無法解決的問題和不足，IP網(wǎng)絡(luò)將向著IPv6網(wǎng)絡(luò)的方向發(fā)展，同時，各種網(wǎng)絡(luò)服務(wù)也必將會轉(zhuǎn)移到IPv6上運行。因此,提供可靠的網(wǎng)絡(luò)服務(wù)并保證服務(wù)質(zhì)量是當(dāng)前IPv4網(wǎng)絡(luò)及將來IPv6網(wǎng)絡(luò)發(fā)展過程中需要解決的關(guān)鍵問題。
眾所周知，標(biāo)準(zhǔn)Internet協(xié)議(IPv4)的網(wǎng)絡(luò)提供盡力而為的數(shù)據(jù)傳輸。這種IP網(wǎng)絡(luò)允許客戶端主機的結(jié)構(gòu)復(fù)雜一些，而網(wǎng)絡(luò)端的結(jié)構(gòu)可以保持相對簡單，因為Internet要支持自身的快速發(fā)展,所以，這樣的結(jié)構(gòu)劃分是有好處的。當(dāng)越來越多的主機連在一起的時候，網(wǎng)絡(luò)服務(wù)的需求最終會超過網(wǎng)絡(luò)的承載能力，而新的服務(wù)要求卻不會停止，由此會造成網(wǎng)絡(luò)性能的逐漸惡化，進而引起傳輸遲延的變化(抖動>，甚至導(dǎo)致分組丟失。雖然常用的Internet應(yīng)用（如電子郵件，文件傳輸和Web應(yīng)用）不會受太大影響，但是其他應(yīng)用就不能適應(yīng)這種有遲延的服務(wù)。傳輸遲延給有實時要求的應(yīng)用（例如傳送多媒體信息）及大多數(shù)雙向通信(如電話)帶來了問題。
滿足這些實時應(yīng)用的常見方法是增加帶寬。增加網(wǎng)絡(luò)帶寬雖然可以緩解網(wǎng)絡(luò)擁塞，但并不能消除擁塞。為了在Internet上提供能夠滿足要求的服務(wù)，必須補充制訂有關(guān)服務(wù)數(shù)量或服務(wù)質(zhì)量水平的規(guī)定。規(guī)定中需要在網(wǎng)絡(luò)方面增加一些協(xié)議，來區(qū)分具有嚴(yán)格實時要求的業(yè)務(wù)和能夠容忍延遲、抖動和分組丟失的業(yè)務(wù)。這就是服務(wù)質(zhì)量（QoS)協(xié)議要做的事情。QoS不是創(chuàng)造帶寬，而是管理帶寬，因此它能廣泛的應(yīng)用.能滿足更多的應(yīng)用需求。QoS的目標(biāo)是要提供一些可預(yù)測的質(zhì)量級別，以及控制超過目前IP網(wǎng)絡(luò)最大服務(wù)能力的服務(wù)。
20世紀(jì)90年代以來，IETF已經(jīng)建議了很多服務(wù)模型和機制，以滿足QoS的需求，其中比較有名的有:綜合服務(wù)（IntSenO/RSVP模型，區(qū)分服務(wù)模型（DiffServ),多協(xié)議標(biāo)記交換(MPLS)，流量工程和約束路由等用來在不同的場合提供相應(yīng)的質(zhì)量保證。但是現(xiàn)有的各種QoS的協(xié)議和結(jié)構(gòu)都是建立在IPv4協(xié)議的基礎(chǔ)上的。由于IPv4協(xié)議本身沒有提供對QoS的支持，因此基于IPv4的各種QoS模型的實現(xiàn)比較復(fù)雜,需要增加額外的協(xié)議和組件。
IPv6是下一代互聯(lián)網(wǎng)的核心協(xié)議，未來的QoS產(chǎn)品需要IPv6。IPv6在設(shè)計上對QoS具有很好的支持，如簡化的報頭，分層次的髙效路由，對移動性的支持以及多播機制等，更重要的是IPv6還定義了流標(biāo)號和通信類型字段來支持實時應(yīng)用和流。但對于這兩個字段的使用方式和定義規(guī)范卻還沒有統(tǒng)一的標(biāo)準(zhǔn)。
IPv4的QoS標(biāo)準(zhǔn)，在支持實時傳輸方面主要依賴于IPv4的服務(wù)類型字段（ToS)和使用UDP或TCP端口進行身份認(rèn)證。但IPv4的ToS字段功能有限，而可能造成實時傳輸超時的因素又太多。此外，如果IPv4數(shù)據(jù)包加密的話，就無法使用TCP/UDP端口進行身份認(rèn)證。但是IPv6卻具有很好的QoS機制，能夠提供更好的實時QoS的支持。
IPv4通常被描述為無連接協(xié)議。在IPv4中，對所有的包大致同等對待，這意味著每個包都是由中間路由器按照自己的方式來處理的。路由器并不跟蹤任意兩臺主機間發(fā)送的包，因此不能“記住”如何對將來的包進行處理。每個包都分別處理的結(jié)果是兩個從相同數(shù)據(jù)源發(fā)往相同目的地的包可以采用完全不同的路由來穿越整個網(wǎng)絡(luò)。這對于適應(yīng)網(wǎng)絡(luò)突發(fā)事件來說是個好辦法，因為突發(fā)事件意味著任何一個路由可能在任何時間出現(xiàn)故障，但只要兩主機間存在某些路由，就可以進行數(shù)據(jù)的交互。
但是這種方法的效率可能不太高，尤其是當(dāng)數(shù)據(jù)包并不是孤立的，而且實際上是兩個通信系統(tǒng)間的業(yè)務(wù)流的一部分時。進一步考慮一個包序列從一臺主機發(fā)往另一主機時它所經(jīng)過的路徑上可能發(fā)生的事情：每個中間路由器對每個包的處理將導(dǎo)致在鏈路上輕微地增加延時。對于類似文件傳輸或終端仿真之類的大部分傳統(tǒng)Internet應(yīng)用，延時只會帶來一點不方便而已，但對于一些提供互操作的音頻和視頻應(yīng)用而言，即使只是增加一點點延時也會顯著降低服務(wù)質(zhì)量。
對于每個IPv4包均進行單獨處理帶來的另一個問題在于難以把特定的業(yè)務(wù)流指定到較低代價的鏈路上。例如，電子郵件的傳輸優(yōu)先級不高，并且不是實時應(yīng)用，但IPv4管理員卻沒有簡單的辦法來標(biāo)記這些包，把它們傳輸?shù)捷^低開銷的Internet鏈路,并為實時應(yīng)用保留較高開銷的鏈路。
IPv6實現(xiàn)了流概念，有助于解決類似的問題。流的定義如RFC1883中所述：流指的是從一個特定源發(fā)向一個特定（單播或者是多播）目的地的包序列，源點希望中間路由器對這些包進行特殊處理。
路由器需要對流進行跟蹤并保持一定的信息，這些信息在流中的每個包中都是不變的。這種方法使路由器可以對流中的包進行高效處理。對流中的包的處理可以與其他包不同。但無論如何，對它們的處理更快，因為路由器無需對每個包頭重新處理。
在圖5-18所示的IPv6基本報頭中新定義了兩個字段：通信流類型（trafficclasses)和數(shù)據(jù)流標(biāo)號(flowlabel),實現(xiàn)對QoS的處理。此外，IPv6引人的擴展報頭可以消滅或至少大,減少選項帶來的對性能的沖擊。通過把選項從IP頭中搬到凈荷中，路由器可以像摶發(fā)選項包一樣來轉(zhuǎn)發(fā)包含選項的包。除了規(guī)定必須由每個轉(zhuǎn)發(fā)路由器進行處理的跳到跳選項之外。IPv6包中的選項對于中間路由器而言是不可見的。這樣的處理減輕了路由器的處理開銷。加快了數(shù)據(jù)包的轉(zhuǎn)發(fā)速度。