IPv6 QoS及其實現進一步探討

         目前,IPv4 QoS已經獲得比較好的發展,因此在IPv6大規模部署之前,可以先借助IPv4 QoS的成果,進一步研究Flow Label機制的使用。從目前情況看,可以通過Diff-Serv實現QoS,以後隨着技術的發展和標準的成熟,可以逐漸引入其他更有效的方法。而終結目標是,伴隨着ITU-T的QoS架構和實現方法的成熟,最終解決IPv6 QoS。

現在的信息網絡可以用“Everything over IP”和“IP over Everything”來概括。業界基本達成共識,IP網絡將成爲下一代信息網絡的基礎設施。 但自由、開放和“Best Effort”的IP網絡,在擔負這樣的責任時,還需要大量的改進。

一方面,由於寬帶網絡的高速發展、NGN(下一代網絡)和3G網絡的大規模部署以及家庭網絡等即將成爲現實,需要大量的IP地址,而目前廣泛使用的IPv4地址,由於總量的缺乏以及分配的不公平性等原因存在嚴重短缺,在不久的將來勢必耗盡。所以,早在10多年前,鑑於當時B類地址需求高速增長,眼看地址耗盡指日可待,一度造成恐慌而發展了具有巨大地址空間的IPv6技術。同時,也發展了CIDR(無級別域內路由選擇)和保留地址/NAT技術,以進一步延緩IPv4地址的消耗速度。另一方面,IPv4在地址自動配置、QoS、安全性以及移動性等方面也難以滿足下一代網絡的發展要求,因此,IPv6不僅僅解決地址問題,也在其他方面做了相應的改進。
本來希望IPv6一勞永逸地解決一系列問題,但經過10多年的發展,許多目標並沒有實現,包括下面將要討論的IPv6 QoS問題。
IPv6 QoS基本情況
和IPv4相比,IPv6在QoS方面提供了更多的措施,以期改善甚至徹底解決網絡的服務質量問題。最初的想法是,根據當時IP QoS的研究進展,引入Flow Label機制,幫助處理QoS。由於受到當時網絡技術發展水平的限制,第一個比較成熟的成果在1994年前後才推出,即所謂的Int-Serv模型。該模型在信息傳遞之前,使用資源預留協議(RSVP)建立一個可以保證QoS各有關指標的一個通道。這種想法似乎是可行的,因爲和它相類似的ATM技術在QoS上獲得了較大的成功,或者說後者的一個主要特點就是解決了QoS問題(當然,各有關技術還在不斷髮展之中)。但是,Int-Serv並沒有獲得廣泛的應用。今天再來分析其原因,可以發現,ATM網絡支持的電路/流的數量,基本上是以千條(thousands)爲單位實施擴展的;而IP網絡,特別是Internet這樣的全球網絡,其業務流基本上是以百萬條(millions)爲基本單位的,這對於網絡中的路由器設備來說,很難支持如此大量的軟狀態。同時,也存在跨多個運營商進行資源預留管理等問題。後來進一步發展了Diff-Serv模型,它基於對網絡業務的分類來簡化處理的類別,從而解決了可擴展性問題,爲IP網絡的QoS提供了一個可行的解決方案。但是,Diff-Serv模型並不能提供一個端到端的解決方案,其對IP QoS的實現,需要通過與PHB(Per-Hop-Behavior)、網絡流量規劃或者流量工程(Traffic Engineering,TE)等措施聯合提供。
IPv6 QoS定義
IP QoS的實現,需要網絡中所有相關元素的全面支持,包括應用、終端和網絡設備等。在基本的IP協議層面,提供一些字段的定義,用於支持QoS的實現。IPv6同樣如此。
IPv6包頭格式
IPv6的報頭格式如圖1所示(圖中同時顯示了IPv4報頭格式,以示對比)。和IPv4相比,IPv6採用更規整的結構,便於使用硬件進行高速處理。IPv6定義了一個固定長度的基本報頭,其他的一些選項歸類爲擴展報頭,其中包括每一個網絡節點都必須處理的Hop by Hop報頭等。
從圖中可以看出,IPv6有兩個字段與QoS有關,分別爲流量類別(Traffic Class,TC)和流標籤(Flow Label,FL)字段。流量類別字段有8位,和IPv4的服務類型(ToS)字段功能相同,用於對報文的業務類別進行標識;流標籤字段有20位,用於標識屬於同一業務流的包。流標籤和源、目的地址一起,惟一標識了一個業務流。同一個流中的所有包具有相同的流標籤,以便對有同樣QoS要求的流進行快速、相同的處理。
        流標籤規範
流標籤規範定義了流以及與流標籤有關的一些基本規範,同時提出了不少建議草案。這裏摘要簡單介紹。
流是從某一源節點發往某一單播、任播或組播地址的目的節點的一系列包。源節點用流標籤標識一個流。一個具體的傳輸連接或媒體流中的所有包都屬於一個流。當然,並非一個流必須和一個傳輸連接 1:1對應。
流標籤在高效處理方面具有特別的優勢。和五元組相比,IPv6的源地址、目的地址以及流標籤都出現在基本報頭中。而五元組則由於或者是報文的分段,或者是加密,或者是協議在多個擴展的報頭之後纔可以取得,因此在處理的效率上要差一些。
當然,由於流標籤處在一個非常暴露的位置,在抵抗服務盜用以及DoS(拒絕服務)***方面比較脆弱,需要一定的措施來保護。一般需要一個比較信任的環境,或者啓用入境(ingress)過濾等防範措施。
現在,流標籤規範還只是一個框架,並沒有對流標籤的使用做出明確的定義,只規定了一些非常原則的內容,主要包括:(1)IPv6流支持的最低要求是標記流(給流打標籤)。流標籤應該由流的發起者信源節點賦予一個流。流標籤是一個1-FFFFF的僞隨機數。對那些不支持流標籤處理的節點和應用應將FL置成0,或者不對該字段進行處理。(2)源節點應該能夠爲流選擇沒有用過的流標籤值。當新建流時,源節點必須保證它不會無意識地重用當前正用或是最近剛用過的流標籤值。也就是說,新建同一源地址和目的地址之間的流,不能用之前120s之內用過的流標籤值。對於各自不同的流,源節點應該能夠提供方法,爲應用和傳輸協議指定留驗期長於120s。(3)爲了避免由於系統每次重新啓動而意外地重用流標籤值,初始值應該能夠從存儲在非易失性存儲器裏的上一次流標籤值導出,如果這些歷史數據也丟失了,則用一個好的隨機數算法產生一個隨機初始值。(4)流狀態的建立方式必須滿足的最低要求是,提供具體流處理功能的IPv6節點具有清理流狀態的手段;當請求的流狀態節點不能支持時,流狀態建立方法必須能夠恢復,從而保證不同的方法可以被使用。
當然,對流標籤的定義和使用還提出了不少草案。例如,將20位進一步細分爲3+17位,前3位可以定義爲支持諸如Diff-Serv、Int-Serv等幾種類別,後17位則根據前面定義的類別再定義相應的功能或者應用。這裏不詳細介紹。
IPv6 QoS信令擴展
QoS信令是目前研究的熱點之一,也是支持端到端QoS技術的一個重要方面。從技術的角度看,可以支持帶內或者帶外的信令。RSVP和802.1p分別是一個示例。但如前所述,RSVP可能並不適合在Internet這種大規模的網絡中使用。
IPv6可以比較方便地支持QoS信令的實現,具體的做法是,根據IPv6的Hop by Hop擴展頭對信令進行定義。由於每個IPv6節點都必須處理Hop by Hop擴展頭,這樣就可以實現QoS信令。即通過在數據流的第一個數據包中攜帶有關信息,在經過逐跳處理和預留以後到達接收端,接收端根據情況將有關信息回傳發送方,這樣就可以進行有QoS保證的數據發送了。
QoS信令的定義還處於探討階段,具體的內容包括可用帶寬、保證帶寬、優先級以及與報文處理有關的一些定義字段等。
IPv6 QoS實現方案
IPv6 QoS的實現可以在不同層面進行。例如網絡應用,可以通過流量類別字段和/或流標籤字段提出QoS要求,也可以在用戶接入的服務提供商(SP)網絡邊緣節點對用戶業務進行標識。當然,這裏涉及服務提供商和用戶之間的QoS/SLA協商,以及據此制定的服務策略。最關鍵之處還在於網絡設備,必須可以根據這些業務要求完成相應的處理並保證QoS。需要說明的是,在IPv6 QoS信令實現比較成熟的情況下,網絡應用還可以通過信令和網絡進行協商,實現動態的QoS處理。
圖2簡單示意了IPv6 QoS的實現方案,實際的網絡可能更復雜一些。處於服務提供商網絡邊緣的支持QoS的節點與最終客戶之間,可能有一個寬帶接入網絡,其QoS也是問題的一個部分,但可以通過一定的帶寬集中方式獲得保證。這裏不討論。
圖2示出了對網絡應用進行QoS處理的兩種情況:支持QoS的標記和在服務提供商網絡邊緣對不同的應用流重新進行標記。但從網絡運營的角度看,在網絡邊緣進行標記處理更加合理。這一方面有利於用戶和服務提供商之間的協商;另一方面有利於服務提供商驗證用戶的標記是否與其SLA相一致,以阻斷用戶私自提高服務等級等情況的發生。而在網絡的核心,通過和邊緣配合的方法實現具體的QoS處理。
      
如前所述,IPv6 QoS的實現可以使用Diff-Serv、Int-Serv以及IPv6 QoS信令等方式,但具體到在網絡節點上的實現,主要還是標記、排隊和擁塞避免等一些具體的措施。
在網絡邊緣節點對進入網絡的報文進行分類,根據不同的SLA和QoS策略,可以有多種方法。對IPv6而言,可以根據源地址、目的地址和流標籤進行標記;也可以根據IP包的5元組(源、目的IP地址,源、目的端口號,傳輸協議)來確定。從廣泛的適用性看,還應該支持DSCP(差異化服務編碼點)、802.1p以及MPLS(多協議標籤交換)QoS機制的E-LSP/L-LSP等。
進入網絡的報文在網絡節點由PHB控制,實現不同的QoS,包括帶寬、延時、丟包率等。具體的實現將根據不同的設備資源和功能情況有所不同,但基本上都是通過設置一定的緩存隊列,在發生擁塞時通過隊列進行緩衝,通過對不同隊列的不同調度算法,實現不同業務的優先級和各有關QoS指標。
現在,已經發展了多種隊列調度算法。可以根據不同的設備等級,選用其中一些或者它們的組合,比如PQ(優先級隊列)、WFQ(加權公平隊列)、DRR(虧空循環)等等。其中的一些類別還進一步發展了一些細分技術,例如SPQ(嚴格優先隊列)、W2FQ等。
隊列技術雖然解決了在競爭情況下哪種業務獲得優先服務的問題,但並沒有解決擁塞引起的丟包問題。例如,多個輸入端口同時向一個輸出端口發送報文,如果輸出端口無法及時處理這些報文,則必然有報文被丟棄。RED/WRED(隨機早期檢測/加權隨機早期檢測)可以緩解擁塞問題。
由於目前高端設備都具有大量的緩存,可以存貯高速端口約200ms的數據包,因此在極端的情況下,可能引起較大的延時。因此,對一些業務通過網絡節點的數量以及在每個節點的延時都要做相應的規劃,或者通過流量工程來實現。
另外,針對IP網絡的業務突發量比較大的情況,可以通過流量×××以及在接入端採用CAR(承諾訪問速率)使得網絡的流量比較平緩,從而保證比較好的服務質量。
上述解決方案是基於Diff-Serv實現的。也許IPv6信令和Diff-Serv的結合,可以產生新的更有效的IPv6 QoS實現方案。
建設IP網絡,QoS是一個非常重要的方面。而IPv6在未來的2~5年內,必然會成爲網絡建設的主流,因此,探討IPv6 QoS有其現實的意義,對IP網絡向電信級過渡以及相關產品的研發均能提供有效的線索。
目前,IPv4 QoS已經獲得比較好的發展,因此在IPv6大規模部署之前,可以先借助IPv4 QoS的成果,進一步研究Flow Label機制的使用。從目前情況看,可以通過Diff-Serv實現QoS,以後隨着技術的發展和標準的成熟,可以逐漸引入其他更有效的方法。而終結目標是,伴隨着ITU-T的QoS架構和實現方法的成熟,最終解決IPv6 QoS。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章