第4講--網(wǎng)絡服務質(zhì)量控制_第1頁
第4講--網(wǎng)絡服務質(zhì)量控制_第2頁
第4講--網(wǎng)絡服務質(zhì)量控制_第3頁
第4講--網(wǎng)絡服務質(zhì)量控制_第4頁
第4講--網(wǎng)絡服務質(zhì)量控制_第5頁
已閱讀5頁,還剩148頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

1、第四講:網(wǎng)絡服務質(zhì)量控制LIXIUQIN本講主要的內(nèi)容nQoS的基本概念n擁塞控制n隊列管理nQoS網(wǎng)絡模型nQoS路由 1.為什么需要QoS? QoS是指服務方和用戶應用程序方之間的一種定量或定性的約定。一種QoS連接請求具有一系列的給定約束。n傳統(tǒng)的IP網(wǎng)絡n主要承載數(shù)據(jù)業(yè)務,采用盡力傳送(Best Effort)的方式,服務質(zhì)量顯得無關緊要n 當前的IP網(wǎng)絡n由一個單純的數(shù)據(jù)網(wǎng)絡轉(zhuǎn)變?yōu)榫哂猩虡I(yè)價值的多業(yè)務承載網(wǎng),IP網(wǎng)絡必須為其所承載的每一類業(yè)務提供相應的服務質(zhì)量4.1 QoS的基本概念的基本概念 1.為什么需要QoS?n應用對延時、丟包、抖動等參數(shù)非常敏感;n在網(wǎng)絡中總有一些諸如傳輸時

2、延、處理延時、CRC錯誤之類不可調(diào)整的因素存在;n在網(wǎng)絡中還存在如緩沖延時、丟包率等和鏈路有關的因素存在;n在絕大多數(shù)的網(wǎng)絡中都存在一定程度的擁塞;n不能總用增加帶寬的方式來解決問題;n在這種情況下最好的解決方案就是應用一個“可保證”的策略。4.1 QoS的基本概念的基本概念 2. QoS的基本測度 n廣義的網(wǎng)絡服務質(zhì)量n包括網(wǎng)絡性能、可用性、可靠性網(wǎng)絡性能、可用性、可靠性 和安全性安全性等各種指標n本講研究的QoS控制都是為了提高網(wǎng)絡保證性保證性能能 的能力n和性能相關的主要的QoS參數(shù)有帶寬帶寬、延遲延遲/ /延遲抖延遲抖動動和分組丟失率分組丟失率 等4.1 QoS的基本概念的基本概念 2

3、. QoS的基本測度 n帶寬bandwidth:預期完成時間的保證n延遲delay/抖動jitter:傳輸?shù)目捎眯詎丟包率loss rate:數(shù)據(jù)的傳輸效率n穩(wěn)定性burstn擁塞控制的最重要目標。4.1 QoS的基本概念的基本概念 2. QoS的基本測度 n網(wǎng)絡帶寬4.1 QoS的基本概念的基本概念BWmax=min(100M, 2M, 10M, 1000M)=2Mn網(wǎng)絡帶寬用于衡量網(wǎng)絡的吞吐能力,單位為bps。n網(wǎng)絡帶寬的最大值為數(shù)據(jù)轉(zhuǎn)發(fā)路徑上最小鏈路的帶寬值。n如果網(wǎng)絡上存在多個數(shù)據(jù)流,它們將互相競爭帶寬。n網(wǎng)絡帶寬取決于物理鏈路的速率,通過QoS技術可以提高網(wǎng)絡帶寬的利用效率。RTAP

4、C1RTBRTCPC22M數(shù)據(jù)流數(shù)據(jù)流10M1000M100M 2. QoS的基本測度 n網(wǎng)絡延遲4.1 QoS的基本概念的基本概念Delay=(T1+P1+S1)+(T2+P2+S2)+(T3+P3+S3)n網(wǎng)絡延遲用于衡量網(wǎng)絡傳輸時間長短,單位為ms。n單個網(wǎng)絡設備的延遲包括傳輸延遲、調(diào)度延遲、串行延遲。n網(wǎng)絡延遲為數(shù)據(jù)轉(zhuǎn)發(fā)路徑上所有網(wǎng)絡設備延遲的總和。n實時應用比較關注延遲大小,如語音、視頻等應用。 2. QoS的基本測度 n抖動4.1 QoS的基本概念的基本概念Jitter=abs(T1-T2)n抖動用于衡量網(wǎng)絡時延的穩(wěn)定性,單位為ms。n同一個數(shù)據(jù)流的不同數(shù)據(jù)包,在網(wǎng)絡中經(jīng)歷的延遲可

5、能不同,從而產(chǎn)生抖動。n抖動對實時應用的影響較大,如語音、視頻等應用,會造成失真。 2. QoS的基本測度 n網(wǎng)絡丟包4.1 QoS的基本概念的基本概念n網(wǎng)絡丟包用于衡量網(wǎng)絡的可靠性,單位為pps或者百分比。n網(wǎng)絡發(fā)生擁塞的情況下,由于所有隊列被占滿,必然導致部分數(shù)據(jù)包被丟棄。n通過擁塞管理技術可以實現(xiàn)區(qū)分式服務,保證關鍵數(shù)據(jù)流優(yōu)先轉(zhuǎn)發(fā)。n通過早期丟棄技術可以平滑網(wǎng)絡流量,防止網(wǎng)絡流量的全局同步問題。n各種應用的QoS需求4.1 QoS的基本概念的基本概念nQoS需求示例4.1 QoS的基本概念的基本概念n語音業(yè)務QoS需求 u丟包率不超過1%u單向時延不超過150200msu平均抖動不應超過

6、30msu每個呼叫需要21106kb/s的保證優(yōu)先帶寬n視頻業(yè)務QoS需求u丟包率不應超過2u單向時延不應超過1su平均抖動不應超過1su帶寬需求依賴于視頻流的編碼和速率 3. 怎樣保證QoS?n保證服務質(zhì)量的第一步是使網(wǎng)絡有較合理的設計和配置.盡量避免瓶頸。n目前,用不斷提高網(wǎng)絡容量的方法來支持QoS是不現(xiàn)實的。 n兩種方法可以用來緩解網(wǎng)絡擁塞,提高服務質(zhì)量:1)為每個用戶建立端到端的資源預留,當資源不夠時,禁止一些用戶向網(wǎng)絡發(fā)送IP包 呼叫抑制2) 所有用戶都可以向網(wǎng)絡發(fā)送IP包, 但當網(wǎng)絡擁塞時,某些用戶的IP包有更好的機會來穿過網(wǎng)絡 設定優(yōu)先權(quán)4.1 QoS的基本概念的基本概念 4.

7、集成服務網(wǎng)絡和區(qū)分服務網(wǎng)絡4.1 QoS的基本概念的基本概念IPIPIntServ networkDiffServ network“呼叫抑制呼叫抑制” 方法方法“設定優(yōu)先權(quán)設定優(yōu)先權(quán)” 方法方法 5. 端到端QoSn需要三個部分來完成端到端的QoS:n網(wǎng)絡元件(交換機、路由器)n信令技術(協(xié)調(diào)端到端之間的網(wǎng)絡元件為報文提供QoS)n傳送管理(QoS控制和管理端到端之間的報文在一個網(wǎng)絡上的發(fā)送)n每個網(wǎng)絡元件提供如下功能:n報文分類(對不同類別的報文提供不同類別的處理)n隊列管理和調(diào)度(來滿足不同應用要求的不同服務質(zhì)量)n流量監(jiān)管和整形(限制和調(diào)整報文輸出的速度)4.1 QoS的基本概念的基本概

8、念 6. QoS控制粒度n分組級(時間粒度大約為1到100微秒)n分組是互聯(lián)網(wǎng)QoS控制機制的最小單位最小單位n流量調(diào)節(jié)機制流量調(diào)節(jié)機制(包括分組分類器、分組標記器和流量整形器等),分組調(diào)度機制分組調(diào)度機制 和主動隊列管理機制主動隊列管理機制 等n分組的往返時間(round trip time),大約為1到100毫秒n在這個粒度工作的是擁塞控制和流量控制擁塞控制和流量控制 等基于反饋的控制機制n會話級的(以秒和分鐘為單位),也就是用戶會話持續(xù)的時間(會話可以采用各種方式定義)n在這個粒度工作的QoS機制包括準入控制和準入控制和QoSQoS路由路由n長期的QoS控制機制n主要包括流量工程,能力規(guī)

9、劃和服務定價流量工程,能力規(guī)劃和服務定價 等4.1 QoS的基本概念的基本概念 6. QoS控制信息nQoS控制機制使用的控制信息的粒度(granularity)n根據(jù)每流(per-flow)狀態(tài)對每個用戶流進行控制n一般來說,流采用IPIP源地址、目的地址、源端口號、目的端口源地址、目的地址、源端口號、目的端口號和協(xié)議域號和協(xié)議域 這五元組進行標識n對流的聚集進行控制n流聚集也可以有各種方法,比如每臺主機、每個網(wǎng)絡前綴、每個服務類別等等n控制狀態(tài)的攜帶者和控制本身的位置n控制狀態(tài)的攜帶者可以是路由器路由器,也可以是分組分組n控制的位置可以在用戶主機用戶主機、網(wǎng)絡邊緣路由器網(wǎng)絡邊緣路由器,或者

10、是網(wǎng)絡網(wǎng)絡核心路由器核心路由器4.1 QoS的基本概念的基本概念18服務質(zhì)量控制概述QoS控制空間edge router control granularitypacketflowflowaggregationcontrolstatepacketrouterhostcore routerround tripsessioncontrolpositionpackettime 1. 擁塞控制的基本概念n網(wǎng)絡擁塞定義n網(wǎng)絡或其一部分由于超載而引起性能嚴重下降的現(xiàn)象稱為擁塞。n 擁塞的原因資源相對不足n過多的突發(fā)報文:在無連接服務的情況下,有大量報文突然涌向同一個端口而來不及處理或輸出,引起報文排隊而且

11、造成緩沖不夠,于是報文開始丟失,形成擁塞。報文的重發(fā)可能會惡化擁塞的情況n系統(tǒng)處理能力不夠:路由器的CPU處理能力不夠,或信道帶寬不夠,或路由器的緩沖容量不足,均可能造成報文來不及處理而丟失,從而引發(fā)擁塞。n重傳處理不當:網(wǎng)絡的鏈路層、網(wǎng)絡層和運輸層的超時計時器間隔,流量控制的窗口大小,重發(fā)的選擇(選擇重發(fā)還是退回重發(fā)),應答報文是否搭載(piggy back)等因素都會影響網(wǎng)絡內(nèi)重發(fā)報文的數(shù)量。n路由不合理:路由策略不能使網(wǎng)絡的流量比較均勻,造成流量相對集中于幾條鏈路。4.2 擁塞控制 1. 擁塞控制的基本概念n擁塞現(xiàn)象4.2 擁塞控制擁塞會導致傳輸時延的急劇增加并造成大量的分組丟失,更為嚴

12、重的是擁塞還可能導致惡性循環(huán)造成網(wǎng)絡崩潰的發(fā)生。擁塞不會隨著網(wǎng)絡處理能力的提高而自動消除。 1. 擁塞控制的基本概念n擁塞控制的目的4.2 擁塞控制Avoid global synchronization 1. 擁塞控制的基本概念n擁塞處理n擁塞控制n對發(fā)生網(wǎng)絡超載的反映n擁塞避免n過載發(fā)生前的檢測和預防行動4.2 擁塞控制 1. 擁塞控制的基本概念n擁塞控制與資源分配的主體n在網(wǎng)絡設備中可用各種排隊規(guī)則控制分組傳送的順序和丟棄那些分組。排隊規(guī)則還可以隔離通信量,使一個用戶的分組不會過分影響另一個用戶的分組。n在端主機,協(xié)調(diào)控制源端發(fā)送分組速度n盡量避免擁塞出現(xiàn),一旦出現(xiàn),盡快消除。n資源分配

13、是一個過程,通過它,網(wǎng)絡設備盡量滿足應用對網(wǎng)絡資源的競爭需求。4.2 擁塞控制 1. 擁塞控制的基本概念n資源分配的基本方式n依據(jù)處理對象nRouter centric:由路由器決定報文的發(fā)送和丟棄,以及允許主機發(fā)送的報文數(shù)量。nHost centric:由主機提供端端的流量控制機制。n依據(jù)分配的時間nReservation-based:傳輸開始前在傳輸路徑上預留資源。nFeedback-based:在傳輸過程中動態(tài)調(diào)整資源分配。n依據(jù)使用策略nWindow-based:使用窗口機制控制資源的使用。nRate-based:根據(jù)接受者的處理能力確定傳輸路徑的資源分配4.2 擁塞控制 2. TCP

14、的擁塞控制n1) 基于滑動窗口的擁塞控制n滑動窗口的概念n發(fā)送方傳輸一個分組后,在傳輸另一個分組前要等待響應的確認n滑動窗口協(xié)議允許發(fā)送方在等待一個確認到達時發(fā)送多個分組4.2 擁塞控制一個窗口中包含8個分組的滑動窗口協(xié)議,在分組1的確認收到后窗口向后滑動一格,從而使分組9能被發(fā)送。只有未被確認的分組才會重傳。 2. TCP的擁塞控制n1) 基于滑動窗口的擁塞控制n報文段、流和序號nTCP把數(shù)據(jù)流當成八位組或字節(jié)的序列,為便于傳輸把序列劃分成若干報文段(segment);nTCP的滑動窗口機制是按八位組操作的,而不是按報文段或分組操作的;n數(shù)據(jù)流的八位組按順序編號;n發(fā)送方給每個連接保留三個指

15、針,定義了一個滑動窗口4.2 擁塞控制 2. TCP的擁塞控制n1) 基于滑動窗口的擁塞控制n基于滑動窗口的擁塞控制4.2 擁塞控制滑動窗口的左邊界,把已經(jīng)發(fā)送并得到確認的字節(jié)與尚未得到確認的字節(jié)區(qū)分開位于窗口內(nèi)部,把已發(fā)送和未發(fā)送的字節(jié)區(qū)分開滑動窗口的右邊界, 指出在收到更多確認之前,序列中可以發(fā)送的最高字節(jié)序號 2. TCP的擁塞控制n1) 基于滑動窗口的擁塞控制n基于滑動窗口的擁塞控制n發(fā)送窗口并不總是和接收窗口一樣大(因為有一定的時間滯后)nTCP 標準沒有規(guī)定對不按序到達的數(shù)據(jù)應如何處理。通常是先臨時存放在接收窗口中,等到字節(jié)流中所缺少的字節(jié)收到后,再按序交付上層的應用進程。nTCP

16、 要求接收方必須有累積確認的功能,這樣可以減小傳輸開銷。 4.2 擁塞控制 2. TCP的擁塞控制n1) 基于滑動窗口的擁塞控制n基于滑動窗口的擁塞控制nRTT 的估算nTCP 保留了平均往返時間 RTT 的一個加權(quán)平均往返時間 RTTS(這又稱為平滑的往返時間)。n第一次測量到 RTT 樣本時,RTTS 值就取為所測量到的 RTT 樣本值。以后每測量到一個新的 RTT 樣本,就按下式重新計算一次 RTTS:新的 RTTS (1 ) (舊的 RTTS) (新的 RTT 樣本) n式中,0 1。若 很接近于零,表示 RTT 值更新較慢。若選擇 接近于 1,則表示 RTT 值更新較快。nRFC 2

17、988 推薦的 值為 1/8,即 0.125。 4.2 擁塞控制 2. TCP的擁塞控制n1) 基于滑動窗口的擁塞控制n基于滑動窗口的擁塞控制n超時重傳時間 RTOnRTO 應略大于上面得出的加權(quán)平均往返時間 RTTS。nRFC 2988 建議使用下式計算 RTO:n RTO RTTS + 4 RTTD nRTTD 是 RTT 的偏差的加權(quán)平均值。nRFC 2988 建議這樣計算 RTTD。第一次測量時,RTTD 值取為測量到的 RTT 樣本值的一半。在以后的測量中,則使用下式計算加權(quán)平均的 RTTD:新的 RTTD = (1 ) (舊的RTTD) + RTTS 新的 RTT 樣本 是個小于

18、1 的系數(shù),其推薦值是 1/4,即 0.25。4.2 擁塞控制往返時間 RTT?往返時間的測量相當復雜 nTCP 報文段 1 沒有收到確認。重傳(即報文段 2)后,收到了確認報文段 ACK。n如何判定此確認報文段是對原來的報文段 1 的確認,還是對重傳的報文段 2 的確認? 發(fā)送一個TCP 報文段超時重傳TCP 報文段收到 ACK時間12往返時間 RTT?是對哪一個報文段的確認?Karn 算法 n在計算平均往返時間 RTT 時,只要報文段重傳了,就不采用其往返時間樣本。n這樣得出的加權(quán)平均平均往返時間 RTTS 和超時重傳時間 RTO 就較準確。 n報文段每重傳一次,就把 RTO 增大一些:新

19、的 RTO (舊的 RTO) n系數(shù) 的典型值是 2 。n當不再發(fā)生報文段的重傳時,才根據(jù)報文段的往返時延更新平均往返時延 RTT 和超時重傳時間 RTO 的數(shù)值。n實踐證明,這種策略較為合理。 修正的 Karn 算法 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP協(xié)議中的擁塞控制機制RFC2581/RFC2582n段:任意TCP報文。n發(fā)送方最大段長(SMSS):發(fā)送方能發(fā)送的最大數(shù)據(jù)長度(不包括報頭),與MTU和RMSS等因素有關。n接收方最大段長(RMSS):接收方能接收的最大數(shù)據(jù)長度(不包括報頭),這個參數(shù)在連接建立時給出,缺省為536字節(jié)。n全長段:數(shù)據(jù)長度為SMSS的

20、報文。n接收窗口(rwnd):由接收者最新確認的窗口長度(實際的流量控制窗口) 。 4.2 擁塞控制 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP協(xié)議中的擁塞控制機制RFC2581/RFC2582n擁塞窗口(cwnd):給出當前網(wǎng)絡可接受的最大數(shù)據(jù)量,它表達了數(shù)據(jù)發(fā)送方在收到接收方發(fā)來的ACK報文之前,可向網(wǎng)絡發(fā)送的數(shù)據(jù)量上界。它用于限制TCP數(shù)據(jù)發(fā)送的狀態(tài)變量,使得在任意時刻, 發(fā)送數(shù)據(jù)的順序號= 最大的應答順序號min cwnd, rwndncwnd的初始上界不能超過接收方的窗口長度,但它的值將隨數(shù)據(jù)的發(fā)送情況并使用不同的方法進行調(diào)整。ncwnd根據(jù)對ACK報文的接受情況進

21、行變化,變化的原則是AIMD:加法遞增(如果當前發(fā)送的報文都被正確應答,則下次多發(fā)一個報文),乘法遞減(如果當前發(fā)送的報文中有一個丟失,則下次只發(fā)一半數(shù)量);但cwnd不會小于一個最大報文長度(MSS),4.2 擁塞控制 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP協(xié)議中的擁塞控制機制RFC2581/RFC2582n慢啟動閾值ssthresh:它決定使用何種方法來調(diào)整cwnd的值,這是擁塞控制中慢啟動階段和擁塞避免階段的分界點,初值通常為65535字節(jié)。如果cwnd的值小于ssthresh的值,使用慢啟動算法增加cwnd的值;否則使用擁塞避免算法nssthresh的初值為接收方

22、的窗口長度,當察覺到網(wǎng)絡可能發(fā)生擁塞時,ssthresh的值要遞減。n飛行長度:已經(jīng)發(fā)送但尚未確認的數(shù)據(jù)長度。4.2 擁塞控制 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP擁塞控制算法n慢啟動(slow-start)n擁塞避免(congestion avoidance)n快速重傳 (fast retransmit)n快速恢復(fast recovery)4.2 擁塞控制 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP擁塞控制算法_慢啟動慢啟動(slow-start)n當一個主機開始向一個TCP連接發(fā)送數(shù)據(jù)時,它并不能知道它與接收者之間的網(wǎng)絡狀態(tài)。為了避免發(fā)送過大的

23、報文,使得網(wǎng)絡一開始就發(fā)生擁塞,TCP在開始數(shù)據(jù)傳輸時使用慢啟動(Slow Start)算法。慢啟動和擁塞避免算法可用來控制TCP的飛行長度,它們受cwnd和rwnd的制約。4.2 擁塞控制 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP擁塞控制算法_慢啟動慢啟動(slow-start)n慢啟動算法的基本思想是當TCP開始在一個網(wǎng)絡中傳輸數(shù)據(jù)或發(fā)現(xiàn)數(shù)據(jù)丟失并開始重發(fā)時,首先需要慢慢地對網(wǎng)絡實際容量進行試探,避免由于發(fā)送了過量的數(shù)據(jù)而導致?lián)砣?。主機在發(fā)送了一個報文后就要停下來等待應答。每收到一個應答,cwnd的值加 1,即增加一個 MSS 的數(shù)值,直至cwnd的值等于ssthres

24、h的值,或網(wǎng)絡發(fā)生了報文丟失(這對于TCP意味著有擁塞發(fā)生)。顯然,cwnd的增長將隨RTT呈指數(shù)級增長。初始時應有 cwnd= IW = min2*SMSS, 2*段長。4.2 擁塞控制發(fā)送方接收方發(fā)送 M1 確認 M1發(fā)送 M2M3 確認 M2M3 發(fā)送 M4M7 確認 M4M7 cwnd = 1 cwnd = 2 cwnd = 4 發(fā)送 M8M15cwnd = 8 tt輪次 1輪次 2輪次 3慢啟動 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP擁塞控制算法_慢啟動慢啟動(slow-start)n傳輸輪次傳輸輪次(transmission round)n使用慢開始算法后,每

25、經(jīng)過一個傳輸輪次,擁塞窗口 cwnd 就加倍。 n一個傳輸輪次所經(jīng)歷的時間其實就是往返時間 RTT。n“傳輸輪次”更加強調(diào):把擁塞窗口 cwnd 所允許發(fā)送的報文段都連續(xù)發(fā)送出去,并收到了對已發(fā)送的最后一個字節(jié)的確認。n例如,擁塞窗口 cwnd = 4,這時的往返時間 RTT 就是發(fā)送方連續(xù)發(fā)送 4 個報文段,并收到這 4 個報文段的確認,總共經(jīng)歷的時間。 4.2 擁塞控制 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP擁塞控制算法_擁塞避免擁塞避免( Congestion Avoidance)n慢開始門限 ssthresh 的用法如下:n當 cwnd ssthresh 時,停止

26、使用慢開始算法而改用擁塞避免算法。n當 cwnd = ssthresh 時,既可使用慢開始算法,也可使用擁塞避免算法。n擁塞避免算法的思路是讓擁塞窗口 cwnd 緩慢地增大,即每經(jīng)過一個往返時間 RTT 就把發(fā)送方的擁塞窗口 cwnd 加 1,而不是加倍,使擁塞窗口 cwnd 按線性規(guī)律緩慢增長。4.2 擁塞控制 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP擁塞控制算法_擁塞避免擁塞避免( Congestion Avoidance)n當網(wǎng)絡出現(xiàn)擁塞時當網(wǎng)絡出現(xiàn)擁塞時:n無論在慢開始階段還是在擁塞避免階段,只要發(fā)送方判斷網(wǎng)絡出現(xiàn)擁塞(其根據(jù)就是沒有按時收到確認),就要把慢開始門限

27、 ssthresh 設置為出現(xiàn)擁塞時的發(fā)送方窗口值的一半( “乘法減小“,但不能小于2)。n然后把擁塞窗口 cwnd 重新設置為 1,執(zhí)行慢開始算法。n這樣做的目的就是要迅速減少主機發(fā)送到網(wǎng)絡中的分組數(shù),使得發(fā)生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。4.2 擁塞控制2216慢開始和擁塞避免算法的實現(xiàn)舉例 當 TCP 連接進行初始化時,將擁塞窗口置為 1。圖中的窗口單位不使用字節(jié)而使用報文段。慢開始門限的初始值設置為 16 個報文段,即 ssthresh = 16?!俺朔p小”24681012141618200048122024擁塞窗口 cwnd新的 ssthresh 值網(wǎng)絡擁塞指數(shù)

28、規(guī)律增長ssthresh 的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例 發(fā)送端的發(fā)送窗口發(fā)送端的發(fā)送窗口不能超過擁塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我們假定接收端窗口足夠大,因此現(xiàn)在發(fā)送窗口的數(shù)值等于擁塞窗口的數(shù)值。2216“乘法減小”24681012141618200048122024擁塞窗口 cwnd新的 ssthresh 值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh 的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例 在執(zhí)行慢開始算法時,擁塞窗口 cwnd 的初

29、始值為 1,發(fā)送第一個報文段 M0。 2216“乘法減小”24681012141618200048122024擁塞窗口 cwnd新的 ssthresh 值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh 的初始值慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例 發(fā)送端每收到一個確認 ,就把 cwnd 加 1。于是發(fā)送端可以接著發(fā)送 M1 和 M2 兩個報文段。 2216“乘法減小”24681012141618200048122024擁塞窗口 cwnd新的 ssthresh 值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh 的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避

30、免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例 接收端共發(fā)回兩個確認。發(fā)送端每收到一個對新報文段的確認,就把發(fā)送端的 cwnd 加 1?,F(xiàn)在 cwnd 從 2 增大到 4,并可接著發(fā)送后面的 4 個報文段。 2216“乘法減小”24681012141618200048122024擁塞窗口 cwnd新的 ssthresh 值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh 的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例 發(fā)送端每收到一個對新報文段的確認,就把發(fā)送端的擁塞窗口加 1,因此擁塞窗口 cwnd 隨著傳輸輪次按指數(shù)規(guī)律增長。 2216“

31、乘法減小”24681012141618200048122024擁塞窗口 cwnd新的 ssthresh 值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh 的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”傳輸輪次慢開始和擁塞避免算法的實現(xiàn)舉例 當擁塞窗口 cwnd 增長到慢開始門限值 ssthresh 時(即當 cwnd = 16 時),就改為執(zhí)行擁塞避免算法,擁塞窗口按線性規(guī)律增長。 2216“乘法減小”24681012141618200048122024擁塞窗口 cwnd新的 ssthresh 值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh 的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞

32、避免“加法增大”傳輸輪次2216“乘法減小”24681012141618200048122024擁塞窗口 cwnd新的 ssthresh 值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh 的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”慢開始和擁塞避免算法的實現(xiàn)舉例 假定擁塞窗口的數(shù)值增長到 24 時,網(wǎng)絡出現(xiàn)超時,表明網(wǎng)絡擁塞了。 傳輸輪次2216“乘法減小”24681012141618200048122024擁塞窗口 cwnd新的 ssthresh 值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh 的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”慢開始和擁塞避免算法的實現(xiàn)舉

33、例 更新后的 ssthresh 值變?yōu)?12(即發(fā)送窗口數(shù)值 24 的一半),擁塞窗口再重新設置為 1,并執(zhí)行慢開始算法。 傳輸輪次2216“乘法減小”24681012141618200048122024擁塞窗口 cwnd新的 ssthresh 值網(wǎng)絡擁塞指數(shù)規(guī)律增長ssthresh 的初始值慢開始慢開始慢開始擁塞避免“加法增大”擁塞避免“加法增大”慢開始和擁塞避免算法的實現(xiàn)舉例 當 cwnd = 12 時改為執(zhí)行擁塞避免算法,擁塞窗口按按線性規(guī)律增長,每經(jīng)過一個往返時延就增加一個 MSS 的大小。 傳輸輪次必須強調(diào)指出 n“擁塞避免”并非指完全能夠避免了擁塞。利用以上的措施要完全避免網(wǎng)絡擁塞

34、還是不可能的。n“擁塞避免”是說在擁塞避免階段把擁塞窗口控制為按線性規(guī)律增長,使網(wǎng)絡比較不容易出現(xiàn)擁塞。 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP擁塞控制算法_快重傳快重傳nTCPTCP通常使用基于通常使用基于RTTRTT的重發(fā)計時器來檢查是否有報文丟失,若超時的重發(fā)計時器來檢查是否有報文丟失,若超時而未收到應答則要進行重發(fā)。而未收到應答則要進行重發(fā)。n另外另外接收方可能收到失序的報文接收方可能收到失序的報文,這時它要返回已收到的有序報文,這時它要返回已收到的有序報文的最大順序號(以反映它的正常接收情況),而這個應答順序號應的最大順序號(以反映它的正常接收情況),而這個應答

35、順序號應該是已經(jīng)發(fā)送過的,因此發(fā)送方會收到重復的應答順序號。該是已經(jīng)發(fā)送過的,因此發(fā)送方會收到重復的應答順序號。n為了為了提高傳輸效率提高傳輸效率,TCPTCP發(fā)送方在收到重復的應答時要使用快速重發(fā)發(fā)送方在收到重復的應答時要使用快速重發(fā)算法和快速恢復算法來檢測和修復丟失的數(shù)據(jù)。算法和快速恢復算法來檢測和修復丟失的數(shù)據(jù)。n快速重發(fā)算法要求快速重發(fā)算法要求發(fā)送方在收到發(fā)送方在收到3 3個相同的重復應答個相同的重復應答之后之后立即啟動重立即啟動重發(fā)發(fā),而不必等待重發(fā)計時器超時。,而不必等待重發(fā)計時器超時。4.2 擁塞控制發(fā)送方發(fā)送方接收方接收方發(fā)送 M1 確認 M1t 確認 M2 發(fā)送 M2發(fā)送 M

36、3發(fā)送 M4 ?發(fā)送 M5發(fā)送 M6 重復確認 M2 立即重傳 M3 重復確認 M2 重復確認 M2 t發(fā)送 M7收到三個連續(xù)的對 M2 的重復確認立即重傳 M3丟失丟失快速重傳 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP擁塞控制算法_快恢復算法快恢復算法n當發(fā)送端收到連續(xù)三個重復的確認時,就執(zhí)行“乘法減小”算法,把慢開始門限 ssthresh 減半。但接下去不執(zhí)行慢開始算法。n由于發(fā)送方現(xiàn)在認為網(wǎng)絡很可能沒有發(fā)生擁塞,因此現(xiàn)在不執(zhí)行慢開始算法,即擁塞窗口 cwnd 現(xiàn)在不設置為 1,而是設置為慢開始門限 ssthresh 減半后的數(shù)值,然后開始執(zhí)行擁塞避免算法(“加法增大”

37、),使擁塞窗口緩慢地線性增大。 n 如果重發(fā)報文的應答返回,表明通路已暢通,置cwnd= ssthresh,并退出快速恢復規(guī)程而進入阻塞避免規(guī)程。如果重發(fā)計時器超時,則表明網(wǎng)絡連接有問題,也退出快速恢復規(guī)程。4.2 擁塞控制24從連續(xù)收到三個重復的確認轉(zhuǎn)入擁塞避免 2468101214161820220048121620傳輸輪次擁塞窗口 cwnd收到 3 個重復的確認執(zhí)行快重傳算法慢開始“乘法減小”擁塞避免“加法增大”TCP Reno版本TCP Tahoe 版本(已廢棄不用)ssthresh 的初始值擁塞避免“加法增大”新的 ssthresh 值慢開始快恢復TCP擁塞控制 NewReno快速恢

38、復算法n如果收到第3個重復的應答報文,且發(fā)送方尚未進入快速恢復規(guī)程,則置ssthresh= max (飛行長度/ 2, 2*SMSS),同時將已發(fā)送的最大順序號記入變量“recover”。n重發(fā)丟失的段,并置cwnd= ssthresh+ 3*SMSS;n每收到一個重復的應答,cwnd+= SMSS。n如果cwnd的值和接收者返回的窗口值允許,就發(fā)送一個報文.n當收到數(shù)據(jù)的應答時,重發(fā)計時器復位n如果這個應答覆蓋了recover的值,則這個報文應答了所有已發(fā)送的數(shù)據(jù),置cwnd= min (ssthresh, 飛行長度+ SMSS),離開快速恢復規(guī)程。n如果這個應答沒有覆蓋所有已發(fā)送的數(shù)據(jù),則

39、它是一個部分應答。這時重發(fā)第1個尚未確認的報文,置cwnd= cwnd-應答的數(shù)據(jù)長度+ SMSS(其目的是減少在途的數(shù)據(jù))。如果cwnd的新值允許,就再發(fā)送一個報文,并回到第3步。TCP Vegas n不是用分組丟失率而是用增長的RTT度量擁塞程度n設無擁塞時的RTT為BaseRTT,則定義期望速率為ExpectedRate= cwnd/BaseRTTn每發(fā)送一個長度為M的報文段X都記錄下發(fā)送時間,當收到X的ACK時計算實際速率ActualRate= M/(ACKX的到達時間X的發(fā)送時間);n定義= ExpectedRateActualRaten定義兩個閾值常量和,其中0 ;如果 ,表示Fl

40、ightsize太大,Vegas在下一個RTT中線性地減小cwnd;如果介于和之間,保持cwnd不變。 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制nTCP擁塞控制小結(jié)擁塞控制小結(jié)nTCP的阻塞控制分為兩類。的阻塞控制分為兩類。n如果是如果是通過重復的應答發(fā)現(xiàn)的阻塞通過重復的應答發(fā)現(xiàn)的阻塞,則這個報文可能還在,則這個報文可能還在途中,信道上仍有應答報文返回,因此阻塞現(xiàn)象并不嚴重途中,信道上仍有應答報文返回,因此阻塞現(xiàn)象并不嚴重,可采用快速恢復算法進行恢復,并轉(zhuǎn)入阻塞避免算法的,可采用快速恢復算法進行恢復,并轉(zhuǎn)入阻塞避免算法的控制??刂啤如果阻塞是如果阻塞是通過重發(fā)計時器的超時發(fā)現(xiàn)的通

41、過重發(fā)計時器的超時發(fā)現(xiàn)的,表明阻塞已經(jīng),表明阻塞已經(jīng)比較嚴重,無報文返回。因此要退回到比較保守的慢啟動比較嚴重,無報文返回。因此要退回到比較保守的慢啟動算法進行恢復。算法進行恢復。4.2 擁塞控制 2. TCP的擁塞控制n2) TCP協(xié)議中的擁塞控制n兩類擁塞控制算法兩類擁塞控制算法n源算法:在主機和網(wǎng)絡邊緣設備中執(zhí)行,根據(jù)反饋信息調(diào)整發(fā)送速率,其關鍵是如何給出反饋和如何響應反饋信息。nTCP中的慢啟動、擁塞避免、快速重傳、快速恢復、選擇性應答。n鏈路算法:在網(wǎng)絡設備中執(zhí)行,檢測擁塞的發(fā)生,生成擁塞反饋信息;n傳統(tǒng)的隊尾丟棄DropTail、主動隊列管理(如RED)4.2 擁塞控制 1. 隊列

42、調(diào)度 2. 主動隊列管理4.3 隊列管理1. 隊列調(diào)度l目的:網(wǎng)絡擁塞時,保證不同優(yōu)先級的報文得到不同的QoS待遇, 包括時延、帶寬等。l方式:將不同優(yōu)先級的報文入不同的隊列,不同隊列將得到不同的調(diào)度優(yōu)先級、概率或帶寬保證。l算法:lFIFO( First In First Out )lPQ( Priority Queue )lSFQ( Stochastic Fairness Queuing )l。LD輸出隊列輸出隊列優(yōu)先隊列優(yōu)先隊列金牌服務金牌服務銀牌服務銀牌服務銅牌服務銅牌服務LU流流分分類類lFQ( Fair Queue )lWFQ( Weighted Fair Queuing )Flo

43、w 的精確定義n流的定義nMPLS的等價轉(zhuǎn)發(fā)類n單向報文序列n流的識別n對應應用一次數(shù)據(jù)發(fā)送的報文集合n一組連續(xù)的報文(超時)n一個處理周期的報文(測量)丟包策略丟棄發(fā)送入隊出隊調(diào)度IP & MPLS 報文lFIFO (First In First Out)先進先出隊列,報文入隊的順序和報文出隊的順序相同,算法簡單,轉(zhuǎn)發(fā)的速度快l所有報文被等同處理,簡單、高效,沒有任何附加開銷lInternet 的默認服務模式Best-Effort采用的隊列策略l無QOSFIFO - 先進先出隊列n 區(qū)分各個到達報文獲得處理的優(yōu)先級,按優(yōu)先級排隊,可有區(qū)別地處理用戶的不同要求。n 優(yōu)先級可針對不同的目標來確定

44、,例如延時、丟包率、和吞吐量等,也可以是它們的組合。n 處理代價高于FIFO方法。n 有處理不同數(shù)據(jù)流的能力。丟包丟包發(fā)送發(fā)送入隊入隊出隊出隊調(diào)度調(diào)度丟包丟包丟包丟包丟包丟包分類器分類器IP 報文報文highmiddlenormalbottomPQ 優(yōu)先隊列FQ 公平隊列n 對各隊列進行平等的循環(huán)處理。n 由于各隊列的報文長度往往不一致,因此循環(huán)處理應逐字節(jié)進行,依次從每個隊列輸出一個字節(jié)。n Weighted Fair Queuing方法(1996年提出)是以加權(quán)的方式為每個隊列分配資源,可用于區(qū)分不同用戶的流。n 加權(quán)公平隊列方法給一些隊列更高的優(yōu)先級,使它們在一個處理周期內(nèi)可傳輸多個字節(jié)

45、。n 處理代價高于優(yōu)先級隊列方法。n 有處理不同數(shù)據(jù)流的能力。n WFQ的問題n 需要per-flow queuing,不適合在主干網(wǎng)中使用,例如DiffServ網(wǎng)絡;n 流的權(quán)重若有變化,需要一個信令機制來在網(wǎng)絡中進行通知;n 計算開銷大。WFQ 加權(quán)公平隊列隨機公平隊列SFQnStochastic Fairness Queuing(1990年提出)將流的源宿地址對用散列函數(shù)映射到某個隊列去,可減少隊列的趨向性和規(guī)律性;散列函數(shù)需要經(jīng)常更換。n有數(shù)據(jù)的隊列稱為活躍(active)隊列,各隊列對帶寬的分配由一個策略控制。n通常要求隊列的個數(shù)比流的個數(shù)多,因此各個流有很大的可能性會獲得不同的優(yōu)先

46、級。n處理代價高于優(yōu)先隊列方法。n不能限制長流對資源的多用。n由于散列函數(shù)可以改變,因此突發(fā)流的數(shù)據(jù)可以分散到不同隊列n有處理不同數(shù)據(jù)流的能力。公平緩沖分配FBAnFair Buffer Allocation方法(1995年提出)要求每個緩沖記住自己當前隊列中各個流的長度,當空間占用超過警戒線時,開始丟棄最長的流的到達報文。n建議的控制計算公式(滿足條件就開始丟包)為nx c2 并且S(i)/E(S(i) c1*(1+(1-x)/(x-c2)其中nS(i)為流i所占用的隊列空間長度;nE(S(i)為當前所有流的平均占用長度;nx為隊列總長度/緩沖總長度;nc1是丟包的調(diào)節(jié)系數(shù),要求c11;nc

47、2是緩沖使用的警戒線值。n處理代價高于SFQ方法。n對長流總不利,對突發(fā)流處理效果不好。n有處理不同數(shù)據(jù)流的能力。類別隊列CBQnClass-Based Queuing方法(1998年提出)將服務映射到隊列,可用于防止某一類服務出現(xiàn)被完全拒絕的情形。n分類的原則n應用的需求:按應用分類,每一類中可能有大量的用戶;n付出的價格:按不同的價格分類;n用戶的組織:按用戶群分類。n處理代價類似于優(yōu)先級隊列方法。n可以支持不同類別用戶的公平性要求。n有處理不同數(shù)據(jù)流的能力。2 主動隊列管理nWhy Active Queue Management?nRFC2309nLock-out問題ndrop-tail

48、 allows a few flows to monopolize the queue space, locking out other flows (due to synchronization)nFull queues 問題ndrop tail may maintain full or nearly-full queues during congestionn尾丟棄:tail dropn當隊列滿時,丟棄所有到達的報文n在隊列丟包期間,來自于大量TCP連接的報文都將被丟棄,TCP的重傳機制將導致新的一輪的擁塞,這種現(xiàn)象稱為“全局同步”n全局同步現(xiàn)象將嚴重影響網(wǎng)絡的性能及服務質(zhì)量隊列隊列尾丟棄

49、尾丟棄丟棄丟棄發(fā)發(fā)送送入隊入隊出隊出隊調(diào)調(diào)度度隊列是否滿隊列是否滿IP 報文報文尾丟棄隨機早期檢測 RED (Random Early Detection )nRED方法(1993年提出)是在緩沖使用超過一定闞值(平均隊列長度)之后,對每個流按不同的概率丟棄一個報文。由于這種丟棄不是同時發(fā)生的,從而在放慢發(fā)送速率的同時,使引起的波動為最小。n使用平均隊列長度來度量網(wǎng)絡的阻塞程度,然后使用線性的方式將阻塞情況反饋給端系統(tǒng)。n使平均隊列長度保持在一個較小的值附近,以吸收突發(fā)流量,減少總的丟包量,降低分組的平均排隊時間。n避免大數(shù)據(jù)流長時間搶占小數(shù)據(jù)流的隊列空間n處理代價比FIFO方法略高。n送得越

50、多,被丟棄的也越多;因此平均看來,對所有流基本是公平的。RED 將路由器的到達隊列劃分成為三個區(qū)域 從隊首發(fā)送最小門限minth最大門限 maxth分組到達平均隊列長度平均隊列長度 Lav排隊丟棄以概率 pd 丟棄丟棄概率 p 與 THmin 和 Thmax 的關系 最小門限 minth最大門限 maxth平均隊列長度 Lav分組丟棄概率 p1.00pMn當 LAV minth 時,丟棄概率 p = 0。n當 LAV maxth時,丟棄概率 p = 1。n當 minth LAV maxth時, 0 p 1 。 例如,按線性規(guī)律變化,從 0 變到 pM。瞬時隊列長度和平均隊列長度的區(qū)別 隊列長度

51、時間瞬時隊列長度平均隊列長度Weighted RED - CisconWRED算法使用兩組閾值,并根據(jù)平均隊列長度將路由器的擁塞狀態(tài)分為5個階段,報文按是否超過指定帶寬分為In和Out兩種狀態(tài)n無擁塞階段(Qavgmin_out):路由器無擁塞,In和Out報文的總量低于鏈路容量,無報文丟失。n擁塞敏感階段(min_out Qavgmax_out):路由器察覺可能會有擁塞發(fā)生,開始丟棄Out報文,向源端發(fā)擁塞信號。n擁塞容忍階段(max_out Qavgmin_in):所有的Out報文都被丟棄,但In報文還能被正常傳輸,表明資源正在趨于飽和。n擁塞警報階段(min_in max_in):路由器

52、丟棄所有報文,鏈路完全擁塞,WRED退化為Drop-Tail。WRED 的特點n基本性質(zhì)與RED相似,但比RED控制得更加細致。n擁塞敏感階段和擁塞容忍階段是WRED的理想工作狀態(tài),資源利用率高且SLA可以滿足;而無阻塞階段的資源利用率可能較低。nIn和Out分類可進一步改進成Green、Yellow和Red,以區(qū)分保證帶寬(Committed)、競爭帶寬(Best Effort)和超出部分帶寬。CHOKenCHOKe(choose and keep/kill) (Infocom2000)ncompare new packet with random packet in queuenif fr

53、om same flow, drop bothnif not, use RED to decide fate of new packetn尋找占用資源較多的流,它們被同時取中兩個報文的概率要大于較小的流。這種方法針對惡意流,因為它可能不遵守流量控制規(guī)程(例如UDP流),因此每到達一個,就丟掉兩個,使其數(shù)量在隊列中逐漸減少。DEC-bitn基于反饋的擁塞控制機制n基本思想non congestion, router sets a bit (CI) on packetnreceivers relay bit to sender in acknowledgementsnsenders use fee

54、dback to adjust sending raten關鍵問題nRouter: Feedback policy (how and when does a router generate feedback)nSource: Signal filtering (how does the sender respond?) 1. 集成服務( IntServ) 2. 區(qū)分服務(DiffServ)4.4 QoS網(wǎng)絡模型1.集成服務( IntServ) 流AD需要帶寬,延遲和丟失率保證 交叉的流量是不可預測的 IP可以提供這種保證嗎? 為了實現(xiàn)這一目標需要對為了實現(xiàn)這一目標需要對IP進行什么修改?進行什

55、么修改?ABCDCross TrafficEF5 Mbps10 Mbps問題IP的限制nIP僅僅提供best effort服務nIP并不參加資源管理n不能根據(jù)每個流的狀態(tài)提供服務保證n不能在流量聚集之間提供服務區(qū)分n早期的研究工作nBerkeley大學的Tenet研究組2nATMnIETF的工作n集成服務框架集成服務框架n區(qū)分服務框架區(qū)分服務框架那么,需要做哪些工作?n流區(qū)分n簡單的FIFO調(diào)度不能工作n流標識n準入控制n資源預留ABCDCross TrafficEF5 Mbps10 MbpsInternet集成服務框架n增強了IP的服務模型n原有模型:簡單的best effort服務類型n新

56、模型:多種服務類型,包括best effort和QoS類型n設計了支持新的服務模型的協(xié)議和算法n原有模型:在IP層次沒有資源管理n新模型:在IP層次進行顯式的顯式的 資源管理n關鍵的體系結(jié)構(gòu)區(qū)別n原有模型:無狀態(tài)無狀態(tài)n新模型:路由器維護每流狀態(tài)每流狀態(tài)n用于準入控制和調(diào)度n由信令協(xié)議建立集成服務網(wǎng)絡n流或者會話作為QoS抽象n每個流有一條固定的或者穩(wěn)定的路徑n沿著路徑的路由器維護每流的狀態(tài) SenderReceiver集成服務實例n獲得每流的帶寬和延遲保證n實例:為流保證1Mbps和100ms的延遲 SenderReceiver集成服務實例n分配資源執(zhí)行每流的準入控制 SenderRecei

57、ver集成服務實例n設置每流狀態(tài) SenderReceiver集成服務實例n設置每流狀態(tài),執(zhí)行資源預留 SenderReceiver 集成服務實例:數(shù)據(jù)路徑n每流分類 SenderReceiver n每流緩沖管理集成服務實例:數(shù)據(jù)路徑集成服務實例n每流調(diào)度 SenderReceiver 服務類型n最早由MIT 93年提出nIntserv: RFC1633 nRSVP: RFC2205, RFC2211,RFC2212n基于兩點假設n帶寬資源必須經(jīng)過顯式的分配和管理才能滿足應用的服務質(zhì)量需要:資源預留和準入控制nInternet需要同時支持實時通信和非實時通信:多業(yè)務n三種常見的服務nbest-

58、effort (“elastic” applications)nhard real-time (“real-time” applications)nsoft real-time (“tolerant” applications)服務類型nHard Real Time:Guaranteed Services確保服務nIP網(wǎng)絡中的“比特流管道”: 需要信令, 接納控制和監(jiān)控n算法支持n基于最壞情況分析的準入控制準入控制n路由器執(zhí)行每流分類和調(diào)度每流分類和調(diào)度nSoft Real Time: Controlled Load Service可控負載可控負載務n相當于輕負載網(wǎng)絡中盡力而為的服務質(zhì)量n算法

59、支持n基于聚集測量的準入控制聚集測量的準入控制n對聚集的調(diào)度調(diào)度工作機制n網(wǎng)絡為每個數(shù)據(jù)流進行帶寬資源預留,網(wǎng)絡節(jié)點可以因為資源不足而拒絕服務,但如果承諾服務,則要保存其狀態(tài)信息并預留資源。n主機在向網(wǎng)絡發(fā)送數(shù)據(jù)流之前,使用RSVP協(xié)議信令向網(wǎng)絡提交數(shù)據(jù)流規(guī)格Flowspec(所期望的帶寬、傳輸延遲、延遲抖動以及丟包率等要求)。數(shù)據(jù)流傳輸路徑中的節(jié)點根據(jù)自己當前的資源狀態(tài)決定是否接納這個請求。如果接納,則為其建立相應的狀態(tài)信息。n主機和路由器節(jié)點一直保持已經(jīng)建立的數(shù)據(jù)流狀態(tài)信息,以保證該流的每個報文都得到保證的QoS服務,直到該數(shù)據(jù)流的結(jié)束時才清除相應的狀態(tài)信息。nIntServ使用接納控制器

60、決定是否接受一個資源預留請求;使用分類器來區(qū)分不同數(shù)據(jù)流的報文;使用報文調(diào)度器來管理各個數(shù)據(jù)隊列的報文發(fā)送。RSVP(Resource ReSerVation Protocol)n用于建立每流狀態(tài)的信令信令 協(xié)議n攜帶攜帶從主機到路由器的資源請求n收集收集從路由器到主機的必要的信息n在每一跳n和準入控制模塊以及策略模塊交互n建立準入狀態(tài)或者通知請求發(fā)起者需求不能滿足n接收方接收方 發(fā)起預留過程n路由和預留機制相互獨立,配合工作RSVP的基本操作n發(fā)送方通過數(shù)據(jù)發(fā)送路徑數(shù)據(jù)發(fā)送路徑發(fā)送PATH消息n在路徑中的每臺路由器上設置包括前一跳地址在內(nèi)的路徑狀態(tài)路徑狀態(tài)n接收方沿著發(fā)送路徑反方向發(fā)送路徑反

溫馨提示

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

評論

0/150

提交評論