下一代互聯網關鍵技術IP QoS(1)

2019-11-03 09:03:43

字體：大中小

來源：轉載

供稿：網友

姜明

　　1.ip QoS產生的背景

　　互聯網源于美國國防部的ARPANET計劃。在上世紀60年代中期，正是冷戰的高峰，美國國防部希望有一個命令和控制網絡能夠在核戰爭的條件下幸免于難，而傳統的電路交換的電話網絡則顯得太脆弱。國防部指定其下屬的高級研究計劃局（ARPA）解決這個問題，此后誕生的一個新型網絡便稱為ARPANET。當ARPANET與美國國家科學基金會（NSF）建成的NSFNET互聯以后，其上的用戶數以指數增長，并且開始與加拿大、歐洲和太平洋地區的網絡連接。到了80年代中期，人們開始把互聯的網絡稱為互聯網。

　　早在70年代中期，ARPA為了實現異種網之間的互聯與互通，推出了TCP/IP體系結構和協議規范。時至今日，TCP/IP協議也成為最流行的網際互聯協議。它不是國際標準化組織制定的，卻已成為網際互聯事實上的標準，并由單純的TCP/IP協議發展成為一系列以IP為基礎的TCP/IP協議簇。TCP／IP協議簇為互聯網提供了基本的通信機制。

　　隨著互聯網的指數增長，其體系結構也由ARPANET基于集中控制模型的網絡體系結構演變為由ISP運營的分散的基于自治系統（Autonomous systems AS）模型的體系結構。互聯網目前幾乎覆蓋了全球的每一個角落，其飛速發展充分說明了TCP/IP協議取得了巨大的成功。

　　但是互聯網發展的速度和規模，也遠遠出乎于二十多年前互聯網的先驅們制定TCP/IP協議時的意料之外，他們從未想過互聯網會發展到如此的規模，并且仍在飛速增長。隨著互聯網的普及，網絡同人們的生活和工作已經密切相關。同時伴隨互聯網用戶數膨脹所出現的問題也越來越嚴重。除了我們眾所周知的IP地址匱乏外，另外一個嚴重問題就是缺乏服務質量（Quality of Service QoS）保障。

　　現有的互聯網所提供的是"盡力而為"（best-effort）的服務，在這種服務模型下，所有的業務流被"一視同仁"地公平地競爭網絡資源，路由器對所有的IP包都采用先來先處理（First Come First Service FCFS）的工作方式，它盡最大努力將IP包送達目的地。但對IP包傳遞地可靠性、延遲等不能提供任何保證。這很適合Email、Ftp、WWW等業務。

　　但隨著互聯網的高速增長，IP業務也得到了快速增長和多樣化。特別是隨著多媒體業務的興起，計算機已經不是單純的處理數據的工具，而是越來越貼近生活，計算機的交互越來越實時和生動，這對計算機互聯網絡也就相應地提出了更高的要求。對那些有帶寬、延遲、延遲抖動等特殊要求的應用來說，現有的"盡力而為"的服務顯然是不夠的。盡管由于網絡技術的發展，網絡帶寬以及網絡速度都得到了極大的提高，但需要通過網絡傳輸的數據卻也幾乎以與網絡發展速度相同的速度增加，甚至超過網絡發展的速度，這使得網絡帶寬與網絡速度依然是一個瓶頸問題。同時，近年來發展起來的一些新的應用（如多媒體應用，組播應用等）不僅增加了網絡流量，更因為這些應用改變了以往互聯網上的流量性質，因而它們需要全新的服務要求。由于不具備服務質量保障特性，不能預留帶寬，不能限定網絡時延，因此，目前的因特網無法支持許多新的應用如遠程教學、遠程手術、遠程會議和學術交流等。

　　2.IP QoS的定義及其實施方案

　　IP QoS的研究目標是有效地為用戶提供端到端的服務質量控制或保證。QoS就是網絡單元（例如，應用程序，主機或路由器）能夠在一定級別上確保它的業務流和服務要求得到滿足。QoS并沒有創造帶寬，只是根據應用程序的需求以及網絡狀況來管理帶寬。IP QoS有一套性能參數，主要包括：

　　業務可用性：用戶到Internet業務之間連接的可靠性。

　　傳輸延遲：指兩個參照點之間發送和接收數據包的時間間隔。

　　可變延遲：也稱為延遲抖動（Jitter），指在同一條路由上發送的一組數據流中數據包之間的時間差異。

　　吞吐量：網絡中發送數據包的速率,可用平均速率或峰值速率表示。

　　丟包率：在網絡中傳輸數據包時丟棄數據包的最高比率。數據包丟失一般是由網絡擁塞引起的。

　　實現QoS的一種方法是按照服務水平的要求分配資源給每一個數據流。這種采用"資源預留"進行帶寬分配的方法并不適合"盡力而為"型應用。由于帶寬資源是有限的，QoS的設計者引入了優先級概念，使得在資源預留后"盡力而為"服務的數據流的傳輸也能得到一定的保障。因此，IP QoS可以分為兩種基本類型：

　　基于資源預留：網絡資源按照某個業務的QoS要求進行分配，制定資源管理策略?；ヂ摼W工程任務組IETF（Internet Engineering Task Force）提出的綜合服務（Integrated Services， IntServ）體系結構便是基于這種策略，資源預留協議（Resource reSerVation PRotocol, RSVP）是其核心部分。

　　基于優先級：網絡邊界節點對業務流進行分類、整形、標記。核心節點按照資源管理策略分配資源，對QoS要求高的業務給以優先處理。IETF提出的區分服務（Differentiated Services，DiffServ）便是基于這種策略。

　　這些QoS方法可以被用于單個數據流或聚集的數據流（aggregate flow）。根據應用的數據流的不同，IPQoS可以分類為：

　　用于單數據流：單個數據流為在兩個應用（發送者和接受者）之間的單個的、單向的數據流?？梢杂脗鬏攨f議、源地址、源端口號碼、目的地址和目的端口號碼這五種參數來分類。

　　用于聚集流：綜合流由兩個或更多個單個數據流組成。這些流在一個或多個參數、標記或優先數以及一些認證信息方面有一些共同點。

　　為了解決IP QoS問題，IETF已經提出了幾種服務模型和機制，主要有：

　　綜合服務和資源預留協議IntServ/RSVP：以RSVP信令向網絡提出業務流傳輸規格（Flowspec），并建立和拆除傳輸路徑上的業務流狀態。主機和路由器節點建立和保持業務流狀態信息。盡管RSVP經常用于單個流，但也用于聚流的資源預留。

　　區分服務：在區分服務網絡中，邊界路由器根據用戶的流規格（stream profile）將用戶流劃分為不同的級別，再聚合成流聚集，聚集信息存放在IP包頭的DS標記域，稱為DS標記（Differentiated Services CodePoint，DSCP）。內部節點則根據DSCP提供不同質量的調度轉發服務。

　　多協議標記交換（MultiProtocol Lable Switch，MPLS）：根據分組頭的標記，通過網絡路徑控制來提供流聚集的帶寬管理子網帶寬管理（Subnet Bandwidth Management，SBM）：負責OSI第二層（數據鏈路層）的分類和優先級排列，同IEEE 802網絡進行共享和交換。

　　3.綜合服務模型和資源預留協議

　　IntServ/RSVP簡介

　　Int-Serv/RSVP服務模型在IETF RFC1633中進行了定義。RFC1633將資源預留協議RSVP作為IntServ結構中的主要信令協議。其基本思想就在于以資源預留的方式來實現QoS保障，RSVP是其核心部分。RSVP是主機用來從應用程序獲得特定的QoS的一種控制協議，完成綜合服務需要定義的呼叫接納控制功能和資源預留功能。端點應用程序利用RSVP消息向網絡提出完成數據傳送必須保留的網絡資源（如帶寬及緩沖區大小等），同時也確定沿傳送路徑的各個節點傳輸處理策略，從而對每個業務流實現逐個控制。

　　在服務層次上，IntServ/RSVP提供了3種級別的業務：

　　端到端的質量保證型服務（Guaranteed Service）：保證帶寬、限制延遲、無丟包。

　　可控負載型服務（Controlled－Load Service）：類似于在當前的一個負載較輕網絡中實現的盡力而為業務的服務質量。

　　盡力而為的服務（Best Effort Service）：類似當前Internet在提供的盡力而為的服務。

　　在結構層次上，IntServ/RSVP服務模型主要由四個部分構成：信令協議RSVP，接入控制器（admission control routines），分類器（classifier）以及包調度器（packet scheduler）。

　　在實現層次上，綜合服務需要所有路由器在控制路徑上處理每個流的信令消息并維護每個流的路徑狀態和資源預留狀態，在數據路徑上執行流的分類、調度和緩沖區管理。具體而言，資源預留協議RSVP負責逐點（hop-by-hop）地建立或者拆除每個流的資源預留軟狀態（soft tate），也即建立或拆除數據傳輸路徑；接入控制器將決定是否接受一個資源預留請求，其根據是鏈路和網絡節點的資源使用情況以及QoS請求的具體要求；分類器則對傳輸的數據包進行分類成傳輸流， IntServ常用的分類器是多域（Multi-Field，MF）分類器，當路由器接收到數據包時，它根據數據包頭部的多個域（如5元組：源IP地址，目的IP地址，源端口號，目的端口號，傳輸協議），將數據包放入相應的隊列中；調度器則根據不同的策略對各個隊列中的數據包進行調度轉發。資源預留協議RSVP

　　RSVP早在1993年就被提出，用于為IP網提供QoS能力。1997年初IETF批準RSVP成為RFC文件，在+IntServ工作組內進行標準制定工作。RSVP是一種提供預留設置和控制以實現綜合服務合協議，是所有QoS協議中最復雜的。RSVP資源預留請求包括流規格說明（TSpec）、資源預留規格說明（RSpec）和過濾器規格說明（Filter Spec），它們一起稱為"流描述符"（Flow Des-criptor）。資源預留請求中的流規格說明通常包含服務類型和數字參數集合。預留說明和業務流說明決定于綜合服務模型并且對RSVP來說是透明的。過濾器規格說明的格式依賴于所使用的網絡層協議，即IPv4或IPv6。目前所用的RSVP中定義的基本過濾器規格說明格式具有嚴格的形式：發送端IP地址和可選的TCP/UDP端口號。在服務保證、資源分配的粒度和對保證QoS應用及用戶反饋的細節等方面RSVP都能提供最高級的QoS。歸納起來，RSVP有以下6個特點：

　　在每一個路由器中的預留是"軟"的，這意味著需要由接收者周期地更新。

　　RSVP不是傳輸協議而是網絡（控制）協議，它不攜帶數據，但是和TCP或UDP數據流并行工作。

　　應用要求API決定流的初始預留請求，并且接收在經過初始請求和全過程中預留成功或失敗的通知。

　　為了能夠容納大量不同的接收者，預留是以接收端驅動的（Receiver-Driven)。

　　多播的預留在上行的數據流復制點上被結合。

　　RSVP數據流可以通過不支持RSVP的路由器，這會在QoS鏈上產生弱鏈路，在這些弱鏈路上無法提供QoS保證，因而此時的服務就是盡力而為型的。

　　使用RSVP信令建立數據發送路徑以及為業務流預留資源的過程如下：

　　發送端向接收端發送一個包含業務流規格說明（TSpec）的PATH消息，其中包含了業務流標識(即目的地址)及其業務特征，包括所需要的帶寬的上下限，延遲以及延遲抖動等。如圖1中①所示。

　　該消息由沿路徑的路由器逐跳傳送，并且每個路由器都被告知準備預留資源，從而建立一個"路徑狀態"，該狀態信息包含PATH消息中的前一跳源地址。如圖1中②、③所示。

　　接收方收到此消息后從業務特征和所要求的QoS計算出所需要的資源，向其上游節點發送一個資源預留請求RESV消息，該消息中包含了TSpec、RSpec以及Filter Spec，其主要包含的參數就是要求預留的帶寬。如圖1中④所示。

　　RESV是沿PATH的發送路徑原路返回的，沿途的路由器收到RESV消息后，調用自己的接入控制程序以決定是否接受該業務流，如果接受，則按要求為業務流分配帶寬和緩存空間，并記錄該流狀態信息，然后將RESV消息繼續向上游轉發；如果拒絕，則向接收端返回一個錯誤信息給接收端以終止呼叫。如圖1中⑤所示。

　　當最后的路由器收到RESV消息并且接受該請求時，它向接收端發回一個確認消息。如圖1中⑥所示。

圖1 RSVP建立傳輸路徑以及預留資源的過程

　　在此過程中，我們注意到，和電信網絡中的呼叫建立過程相反，RSVP是由接收端驅動的資源預留。其目的是考慮在組播的情況下，以接收端驅動，可以適應組播群成員的動態增減，以及各接收端要求不同QoS的異質請求情況。當通信結束或者一方退出會話后預留的資源可以由超時機制釋放。RSVP還定義了顯式的釋放機制，通過PathTear由啟動點沿下游方向傳送至接收端，通知沿途各路由器釋放資源。ResvTear則反向傳送，功能相似。它們可由端系統發出，也可由路由器在狀態超時時發送出。至此，業務流的傳輸路徑已經建立起來了，數據流可以進行發送了。

　　RSVP可以看作是配置業務處理的機制，綜合服務則是在RSVP信令基礎上夠用以提供端到端QoS保證的體系結構。IntServ設定網絡設備支持業務的處理機制，保證每一個業務流嚴格獨立于其他業務流的服務，并設定提供特定量化資源的服務。

　　從以上討論可以看出，IntServ/RSVP服務模型對傳統Internet體系結構的擴展主要包括在路由器中保存業務流狀態信息以及明確的狀態建立機制。這種模型在路由器中所保存的業務流狀態信息是軟狀態信息，由于軟狀態信息在路由器發生錯誤時容易通過RSVP信令刷新而隱含地拆除并在另外路由器中重建業務流狀態信息，而硬狀態信息（hard state）需要明確地拆除狀態信息，因而保持了網絡體系結構的魯棒性（robustness）。同時，由于這種模型有效地集成了各種實時應用和非實時應用，因而保持了網絡的效率。另外，由于兼容了傳統網絡體系結構和協議棧，因此能對網絡進行有效的管理。

　　IntServ/RSVP的缺陷

　　從理論上講IntServ/RSVP模型完全可以保證為IP網絡提供QoS保障。但隨后在一些網上的實驗表明這種服務模型有很明顯的局限性，這些問題主要表現在：這不僅表現在擴展性差上，更大的問題是它要求核心路由器必須保持經過它的每一個單個數據流的狀態，而核心路由器是不能這么做的。另一個大問題是這種方法因此，盡管主要的路由器生產商和主機都支持RSVP,它也被廣泛接受，但是它始終沒有成為主流，原因是ISP們不愿意采用它，很少有大型網絡采用它。近來，人們認識到RSVP的出路在于與區分服務配合工作，相輔相成。

　　可擴展性差：可擴展性是IntServ/RSVP模型最致命的一個問題，其基于流的資源預留、調度處理以及緩沖區管理，有利于提供QoS保證，但狀態信息隨業務流數量的增長而增長，沿途的路由器要為每個數據流都維持一個"軟狀態"，而路由器的存儲器容量有限,可以保存的軟狀態信息都是有限的，在一個運營商規模的網絡中幾乎不可能實現這一要求。

　　對路由器的要求過高，網絡中所有的路由器都必須支持RSVP信令協議，接入控制程序，分類器以及調度器。

　　RSVP中引入每流狀態（per-flow state）的概念，對于數據通信和實時應用通信而言，IP網絡同時扮演了面向無連接和面向連接網絡的兩個不同角色，提供兩種功能,這與其簡化設計原則相抵觸。

　　資源預留不適用于短時流，比如Web流等，而在因特網中Web流量超過了50％。

　　IntServ/RSVP還存在著資源預留和路由協議之間的矛盾。如圖2所示，從路由角度來看它是一條好的路徑，但從資源預留來看，由于沒有足夠的資源可以預留，不能為數據流建立起一條路徑，因此這一進程只能停留在這里，等待上層超時拆除這個應用進程，再重新建立路徑。

　　因此，要實現IntServ的QoS保證是很困難的，它需要基于流的、復雜的資源預留、接納控制、QoS路由和調度機制。在諸如互聯網這種復雜的、大規模的網絡中，鏈路狀態是不確定的，有效地預留帶寬資源非常困難。而且資源預留本身就與IP網絡的最大特點"無連接"相沖突。更重要地問題就是IntServ面臨地可擴展性（scalability）問題和魯棒性（rubustness）問題，這主要是因為在分布式網絡環境中，很難維持動態的、可復制的傳輸流狀態一致性。

　　早期的IntServ是面向單流的，在路由器配置和使用多域分類準則，這給路由器尤其是主干網絡核心路由器帶來了巨大負荷。為了增加IntServ的擴展性，近期RSVP已經開始支持流聚集，即將沿相同業務流傳輸路徑流聚合成宏流（macro-flow），按宏流來預留資源。這雖然減輕了核心路由器的一些負擔，但IntServ本身的體系結構已經決定了其高復雜性，而且由于路徑數是邊界節點數的平方，宏流數仍然很龐大。

　　由于IntServ/RSVP體系存在著諸多問題，一種新的體系結構便應運而生，這就是區分服務體系結構(Differentiated Services，DiffServ)。

　　
摘自　賽迪網

上一篇：下一代互聯網關鍵技術IP QoS(2)

下一篇：無線“第三者”—UWB