下一代互聯(lián)網(wǎng)關(guān)鍵技術(shù)IP QoS(1)

2019-11-03 09:03:43

字體：大中小

供稿：網(wǎng)友

姜明

　　1.ip QoS產(chǎn)生的背景

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

　　早在70年代中期，ARPA為了實(shí)現(xiàn)異種網(wǎng)之間的互聯(lián)與互通，推出了TCP/IP體系結(jié)構(gòu)和協(xié)議規(guī)范。時(shí)至今日，TCP/IP協(xié)議也成為最流行的網(wǎng)際互聯(lián)協(xié)議。它不是國(guó)際標(biāo)準(zhǔn)化組織制定的，卻已成為網(wǎng)際互聯(lián)事實(shí)上的標(biāo)準(zhǔn)，并由單純的TCP/IP協(xié)議發(fā)展成為一系列以IP為基礎(chǔ)的TCP/IP協(xié)議簇。TCP／IP協(xié)議簇為互聯(lián)網(wǎng)提供了基本的通信機(jī)制。

　　隨著互聯(lián)網(wǎng)的指數(shù)增長(zhǎng)，其體系結(jié)構(gòu)也由ARPANET基于集中控制模型的網(wǎng)絡(luò)體系結(jié)構(gòu)演變?yōu)橛蒊SP運(yùn)營(yíng)的分散的基于自治系統(tǒng)（Autonomous systems AS）模型的體系結(jié)構(gòu)。互聯(lián)網(wǎng)目前幾乎覆蓋了全球的每一個(gè)角落，其飛速發(fā)展充分說明了TCP/IP協(xié)議取得了巨大的成功。

　　但是互聯(lián)網(wǎng)發(fā)展的速度和規(guī)模，也遠(yuǎn)遠(yuǎn)出乎于二十多年前互聯(lián)網(wǎng)的先驅(qū)們制定TCP/IP協(xié)議時(shí)的意料之外，他們從未想過互聯(lián)網(wǎng)會(huì)發(fā)展到如此的規(guī)模，并且仍在飛速增長(zhǎng)。隨著互聯(lián)網(wǎng)的普及，網(wǎng)絡(luò)同人們的生活和工作已經(jīng)密切相關(guān)。同時(shí)伴隨互聯(lián)網(wǎng)用戶數(shù)膨脹所出現(xiàn)的問題也越來(lái)越嚴(yán)重。除了我們眾所周知的IP地址匱乏外，另外一個(gè)嚴(yán)重問題就是缺乏服務(wù)質(zhì)量（Quality of Service QoS）保障。

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

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

　　2.IP QoS的定義及其實(shí)施方案

　　IP QoS的研究目標(biāo)是有效地為用戶提供端到端的服務(wù)質(zhì)量控制或保證。QoS就是網(wǎng)絡(luò)單元（例如，應(yīng)用程序，主機(jī)或路由器）能夠在一定級(jí)別上確保它的業(yè)務(wù)流和服務(wù)要求得到滿足。QoS并沒有創(chuàng)造帶寬，只是根據(jù)應(yīng)用程序的需求以及網(wǎng)絡(luò)狀況來(lái)管理帶寬。IP QoS有一套性能參數(shù)，主要包括：

　　業(yè)務(wù)可用性：用戶到Internet業(yè)務(wù)之間連接的可靠性。

　　傳輸延遲：指兩個(gè)參照點(diǎn)之間發(fā)送和接收數(shù)據(jù)包的時(shí)間間隔。

　　可變延遲：也稱為延遲抖動(dòng)（Jitter），指在同一條路由上發(fā)送的一組數(shù)據(jù)流中數(shù)據(jù)包之間的時(shí)間差異。

　　吞吐量：網(wǎng)絡(luò)中發(fā)送數(shù)據(jù)包的速率,可用平均速率或峰值速率表示。

　　丟包率：在網(wǎng)絡(luò)中傳輸數(shù)據(jù)包時(shí)丟棄數(shù)據(jù)包的最高比率。數(shù)據(jù)包丟失一般是由網(wǎng)絡(luò)擁塞引起的。

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

　　基于資源預(yù)留：網(wǎng)絡(luò)資源按照某個(gè)業(yè)務(wù)的QoS要求進(jìn)行分配，制定資源管理策略。互聯(lián)網(wǎng)工程任務(wù)組IETF（Internet Engineering Task Force）提出的綜合服務(wù)（Integrated Services， IntServ）體系結(jié)構(gòu)便是基于這種策略，資源預(yù)留協(xié)議（Resource reSerVation PRotocol, RSVP）是其核心部分。

　　基于優(yōu)先級(jí)：網(wǎng)絡(luò)邊界節(jié)點(diǎn)對(duì)業(yè)務(wù)流進(jìn)行分類、整形、標(biāo)記。核心節(jié)點(diǎn)按照資源管理策略分配資源，對(duì)QoS要求高的業(yè)務(wù)給以優(yōu)先處理。IETF提出的區(qū)分服務(wù)（Differentiated Services，DiffServ）便是基于這種策略。

　　這些QoS方法可以被用于單個(gè)數(shù)據(jù)流或聚集的數(shù)據(jù)流（aggregate flow）。根據(jù)應(yīng)用的數(shù)據(jù)流的不同，IPQoS可以分類為：

　　用于單數(shù)據(jù)流：?jiǎn)蝹€(gè)數(shù)據(jù)流為在兩個(gè)應(yīng)用（發(fā)送者和接受者）之間的單個(gè)的、單向的數(shù)據(jù)流。可以用傳輸協(xié)議、源地址、源端口號(hào)碼、目的地址和目的端口號(hào)碼這五種參數(shù)來(lái)分類。

　　用于聚集流：綜合流由兩個(gè)或更多個(gè)單個(gè)數(shù)據(jù)流組成。這些流在一個(gè)或多個(gè)參數(shù)、標(biāo)記或優(yōu)先數(shù)以及一些認(rèn)證信息方面有一些共同點(diǎn)。

　　為了解決IP QoS問題，IETF已經(jīng)提出了幾種服務(wù)模型和機(jī)制，主要有：

　　綜合服務(wù)和資源預(yù)留協(xié)議IntServ/RSVP：以RSVP信令向網(wǎng)絡(luò)提出業(yè)務(wù)流傳輸規(guī)格（Flowspec），并建立和拆除傳輸路徑上的業(yè)務(wù)流狀態(tài)。主機(jī)和路由器節(jié)點(diǎn)建立和保持業(yè)務(wù)流狀態(tài)信息。盡管RSVP經(jīng)常用于單個(gè)流，但也用于聚流的資源預(yù)留。

　　區(qū)分服務(wù)：在區(qū)分服務(wù)網(wǎng)絡(luò)中，邊界路由器根據(jù)用戶的流規(guī)格（stream profile）將用戶流劃分為不同的級(jí)別，再聚合成流聚集，聚集信息存放在IP包頭的DS標(biāo)記域，稱為DS標(biāo)記（Differentiated Services CodePoint，DSCP）。內(nèi)部節(jié)點(diǎn)則根據(jù)DSCP提供不同質(zhì)量的調(diào)度轉(zhuǎn)發(fā)服務(wù)。

　　多協(xié)議標(biāo)記交換（MultiProtocol Lable Switch，MPLS）：根據(jù)分組頭的標(biāo)記，通過網(wǎng)絡(luò)路徑控制來(lái)提供流聚集的帶寬管理子網(wǎng)帶寬管理（Subnet Bandwidth Management，SBM）：負(fù)責(zé)OSI第二層（數(shù)據(jù)鏈路層）的分類和優(yōu)先級(jí)排列，同IEEE 802網(wǎng)絡(luò)進(jìn)行共享和交換。

　　3.綜合服務(wù)模型和資源預(yù)留協(xié)議

　　IntServ/RSVP簡(jiǎn)介

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

　　在服務(wù)層次上，IntServ/RSVP提供了3種級(jí)別的業(yè)務(wù)：

　　端到端的質(zhì)量保證型服務(wù)（Guaranteed Service）：保證帶寬、限制延遲、無(wú)丟包。

　　可控負(fù)載型服務(wù)（Controlled－Load Service）：類似于在當(dāng)前的一個(gè)負(fù)載較輕網(wǎng)絡(luò)中實(shí)現(xiàn)的盡力而為業(yè)務(wù)的服務(wù)質(zhì)量。

　　盡力而為的服務(wù)（Best Effort Service）：類似當(dāng)前Internet在提供的盡力而為的服務(wù)。

　　在結(jié)構(gòu)層次上，IntServ/RSVP服務(wù)模型主要由四個(gè)部分構(gòu)成：信令協(xié)議RSVP，接入控制器（admission control routines），分類器（classifier）以及包調(diào)度器（packet scheduler）。

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

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

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

　　RSVP不是傳輸協(xié)議而是網(wǎng)絡(luò)（控制）協(xié)議，它不攜帶數(shù)據(jù)，但是和TCP或UDP數(shù)據(jù)流并行工作。

　　應(yīng)用要求API決定流的初始預(yù)留請(qǐng)求，并且接收在經(jīng)過初始請(qǐng)求和全過程中預(yù)留成功或失敗的通知。

　　為了能夠容納大量不同的接收者，預(yù)留是以接收端驅(qū)動(dòng)的（Receiver-Driven)。

　　多播的預(yù)留在上行的數(shù)據(jù)流復(fù)制點(diǎn)上被結(jié)合。

　　RSVP數(shù)據(jù)流可以通過不支持RSVP的路由器，這會(huì)在QoS鏈上產(chǎn)生弱鏈路，在這些弱鏈路上無(wú)法提供QoS保證，因而此時(shí)的服務(wù)就是盡力而為型的。

　　使用RSVP信令建立數(shù)據(jù)發(fā)送路徑以及為業(yè)務(wù)流預(yù)留資源的過程如下：

　　發(fā)送端向接收端發(fā)送一個(gè)包含業(yè)務(wù)流規(guī)格說明（TSpec）的PATH消息，其中包含了業(yè)務(wù)流標(biāo)識(shí)(即目的地址)及其業(yè)務(wù)特征，包括所需要的帶寬的上下限，延遲以及延遲抖動(dòng)等。如圖1中①所示。

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

　　接收方收到此消息后從業(yè)務(wù)特征和所要求的QoS計(jì)算出所需要的資源，向其上游節(jié)點(diǎn)發(fā)送一個(gè)資源預(yù)留請(qǐng)求RESV消息，該消息中包含了TSpec、RSpec以及Filter Spec，其主要包含的參數(shù)就是要求預(yù)留的帶寬。如圖1中④所示。

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

　　當(dāng)最后的路由器收到RESV消息并且接受該請(qǐng)求時(shí)，它向接收端發(fā)回一個(gè)確認(rèn)消息。如圖1中⑥所示。

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

　　在此過程中，我們注意到，和電信網(wǎng)絡(luò)中的呼叫建立過程相反，RSVP是由接收端驅(qū)動(dòng)的資源預(yù)留。其目的是考慮在組播的情況下，以接收端驅(qū)動(dòng)，可以適應(yīng)組播群成員的動(dòng)態(tài)增減，以及各接收端要求不同QoS的異質(zhì)請(qǐng)求情況。當(dāng)通信結(jié)束或者一方退出會(huì)話后預(yù)留的資源可以由超時(shí)機(jī)制釋放。RSVP還定義了顯式的釋放機(jī)制，通過PathTear由啟動(dòng)點(diǎn)沿下游方向傳送至接收端，通知沿途各路由器釋放資源。ResvTear則反向傳送，功能相似。它們可由端系統(tǒng)發(fā)出，也可由路由器在狀態(tài)超時(shí)時(shí)發(fā)送出。至此，業(yè)務(wù)流的傳輸路徑已經(jīng)建立起來(lái)了，數(shù)據(jù)流可以進(jìn)行發(fā)送了。

　　RSVP可以看作是配置業(yè)務(wù)處理的機(jī)制，綜合服務(wù)則是在RSVP信令基礎(chǔ)上夠用以提供端到端QoS保證的體系結(jié)構(gòu)。IntServ設(shè)定網(wǎng)絡(luò)設(shè)備支持業(yè)務(wù)的處理機(jī)制，保證每一個(gè)業(yè)務(wù)流嚴(yán)格獨(dú)立于其他業(yè)務(wù)流的服務(wù)，并設(shè)定提供特定量化資源的服務(wù)。

　　從以上討論可以看出，IntServ/RSVP服務(wù)模型對(duì)傳統(tǒng)Internet體系結(jié)構(gòu)的擴(kuò)展主要包括在路由器中保存業(yè)務(wù)流狀態(tài)信息以及明確的狀態(tài)建立機(jī)制。這種模型在路由器中所保存的業(yè)務(wù)流狀態(tài)信息是軟狀態(tài)信息，由于軟狀態(tài)信息在路由器發(fā)生錯(cuò)誤時(shí)容易通過RSVP信令刷新而隱含地拆除并在另外路由器中重建業(yè)務(wù)流狀態(tài)信息，而硬狀態(tài)信息（hard state）需要明確地拆除狀態(tài)信息，因而保持了網(wǎng)絡(luò)體系結(jié)構(gòu)的魯棒性（robustness）。同時(shí)，由于這種模型有效地集成了各種實(shí)時(shí)應(yīng)用和非實(shí)時(shí)應(yīng)用，因而保持了網(wǎng)絡(luò)的效率。另外，由于兼容了傳統(tǒng)網(wǎng)絡(luò)體系結(jié)構(gòu)和協(xié)議棧，因此能對(duì)網(wǎng)絡(luò)進(jìn)行有效的管理。

　　IntServ/RSVP的缺陷

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

　　可擴(kuò)展性差：可擴(kuò)展性是IntServ/RSVP模型最致命的一個(gè)問題，其基于流的資源預(yù)留、調(diào)度處理以及緩沖區(qū)管理，有利于提供QoS保證，但狀態(tài)信息隨業(yè)務(wù)流數(shù)量的增長(zhǎng)而增長(zhǎng)，沿途的路由器要為每個(gè)數(shù)據(jù)流都維持一個(gè)"軟狀態(tài)"，而路由器的存儲(chǔ)器容量有限,可以保存的軟狀態(tài)信息都是有限的，在一個(gè)運(yùn)營(yíng)商規(guī)模的網(wǎng)絡(luò)中幾乎不可能實(shí)現(xiàn)這一要求。

　　對(duì)路由器的要求過高，網(wǎng)絡(luò)中所有的路由器都必須支持RSVP信令協(xié)議，接入控制程序，分類器以及調(diào)度器。

　　RSVP中引入每流狀態(tài)（per-flow state）的概念，對(duì)于數(shù)據(jù)通信和實(shí)時(shí)應(yīng)用通信而言，IP網(wǎng)絡(luò)同時(shí)扮演了面向無(wú)連接和面向連接網(wǎng)絡(luò)的兩個(gè)不同角色，提供兩種功能,這與其簡(jiǎn)化設(shè)計(jì)原則相抵觸。

　　資源預(yù)留不適用于短時(shí)流，比如Web流等，而在因特網(wǎng)中Web流量超過了50％。

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

　　因此，要實(shí)現(xiàn)IntServ的QoS保證是很困難的，它需要基于流的、復(fù)雜的資源預(yù)留、接納控制、QoS路由和調(diào)度機(jī)制。在諸如互聯(lián)網(wǎng)這種復(fù)雜的、大規(guī)模的網(wǎng)絡(luò)中，鏈路狀態(tài)是不確定的，有效地預(yù)留帶寬資源非常困難。而且資源預(yù)留本身就與IP網(wǎng)絡(luò)的最大特點(diǎn)"無(wú)連接"相沖突。更重要地問題就是IntServ面臨地可擴(kuò)展性（scalability）問題和魯棒性（rubustness）問題，這主要是因?yàn)樵诜植际骄W(wǎng)絡(luò)環(huán)境中，很難維持動(dòng)態(tài)的、可復(fù)制的傳輸流狀態(tài)一致性。

　　早期的IntServ是面向單流的，在路由器配置和使用多域分類準(zhǔn)則，這給路由器尤其是主干網(wǎng)絡(luò)核心路由器帶來(lái)了巨大負(fù)荷。為了增加IntServ的擴(kuò)展性，近期RSVP已經(jīng)開始支持流聚集，即將沿相同業(yè)務(wù)流傳輸路徑流聚合成宏流（macro-flow），按宏流來(lái)預(yù)留資源。這雖然減輕了核心路由器的一些負(fù)擔(dān)，但I(xiàn)ntServ本身的體系結(jié)構(gòu)已經(jīng)決定了其高復(fù)雜性，而且由于路徑數(shù)是邊界節(jié)點(diǎn)數(shù)的平方，宏流數(shù)仍然很龐大。

　　由于IntServ/RSVP體系存在著諸多問題，一種新的體系結(jié)構(gòu)便應(yīng)運(yùn)而生，這就是區(qū)分服務(wù)體系結(jié)構(gòu)(Differentiated Services，DiffServ)。

　　
摘自　賽迪網(wǎng)

上一篇：下一代互聯(lián)網(wǎng)關(guān)鍵技術(shù)IP QoS(2)

下一篇：無(wú)線“第三者”—UWB