為 RSVP 而設計之高效率資源保留樣式
An Efficient Resource Reservation Style for RSVP
童曉儒(Sheau-Ru Tong)、林美賢(Mei-Hsien Lin)
國立屏東科技大學 資訊管理系
{
srtong,mslin}@mail.npust.edu.tw
摘 要
RSVP(Resource Reservation Protocol) 已漸被公 認是一種必要的傳送「服務品質(QoS)」需求的網路協 定,其目的是將 QoS 需求動態的通知各網路節點,以 便保留適當的資源。RSVP 設計了三種資源保留樣式, 分 別 是 : Fixed-Filter(FF) 、 Shared-Explicit(SE) 和 Wildcard-Filter(WF),來處理各種溝通模式的需求。然 而我們發現此三種保留樣式,不足以將溝通模式的 QoS 需求完整的告知每一網路節點,因而可能導致嚴 重的資源浪費,而影響網路的使用效率。有鑑於此, 我們提出一套更有效率的保留樣式,此保留樣式能完 整的將 QoS 需求傳達至每一網路節點,使每一節點做 到最佳的資源保留,因此完全免除了資源浪費的困 擾,而所付出的運算與通訊代價則十分有限。我們模 擬了在 TANet 2 的部分網路架構下,一套分級式遠距 教學系統的運作的情形。其結果驗證了我們所提資源 保留樣式的優越性。 關鍵字:服務品質保證(QoS)、資源保留協定(Resource Reservation Protocol , RSVP) 、 保 留 樣 式 (Reservation Style)。
1. 緒論
近年來使用 Internet 的人口大幅的成長,透過 Internet 傳送資料非常普遍,且網路應用多元化,使得 今日的資料型態不再侷限於文字資料,更包括資料量 大的多媒體資料(如:影片、音樂、動畫),此類資料 需要更高的網路頻寬與更嚴格的傳送速度,雖然網路 技術的進步,大幅提升了網路頻寬,但由於目前仍是 以 best-effort 為主要的傳送模式,且缺乏有效的資源保 留與管理機制,所以無法真正確保資料傳送的品質。 有鑑於此,下一代的網路(如 Internet II),將提供具有 保證傳輸「服務品質(QoS)」的功能,服務型態以 Integrated Service 與 Differentiated Service 為兩大主流 [1,2],兩者各有其特性。Integrated Service 是針對每一 個網路串流(flow)給予 QoS 的保證,雖然每個 flow 都 享有精確的 QoS 保證,但當 flow 數量過多時,網路的 控制的負擔就會變得沈重,所以此服務僅適用於較單 純的環境中,不利於系統的擴張;相對的,Differentiated Service 則是將網路上的網路串流依所需要的 QoS 分成 為幾大類別,然後針對不同的類別,提供不同程度的 QoS,如此網路的控制只與類別的數量有關,而與 flow 的數量無關,所以較無不良擴充性的問題,但 QoS 的 保證無法做到十分精準,可能會造成網路資源保留超 過實際的需求量,一般而言,此服務適用於廣域的連 結上。目前較為大眾所接受的是一種合併式的架構(如 圖 1 所示):用戶區域(customer premises)採用 Integrated Service ; 而 ISP 廣 域 區 域 則 採 用 Differentiated Service[5]。 Router Router Sender Receiver RSVP 用戶區域網路 用戶區域網路 DiffServ RSVP ISP 廣域網路 圖 1 IntServ 與 DiffServ 共存圖 不論是用何種服務型態,不可或缺的是一套告知 (signal)網路應保留多少資源的機制,此種機制可能是 由人為決定,採手動的方式來控制網路節點,此方法 是由主導 Differentiated Service 的研究團體所提倡,雖 然簡單直接,但缺乏彈性,較不適用於動態變化性明 顯的 Internet;或是由需要服務的終端系統主動發出 QoS 需求,網路自動蒐集此訊息,然後主動做出保留 決定,此方法是由主導 Integrated Service 研究團體所 提倡,富有彈性且符合 Internet 之精神。因此本論文的 研究重點將放在後者。「資源保留協定(RSVP/ Resource Reservation Protocol) 」 [4,8,9,10] 是 屬 於 Integrated Service 中的一部分,用來告知(signaling)路徑上的網路 節點有關 QoS 的需求,以便在送收兩者之間建立具有 QoS 保 證 的 通 道 。 雖 然 RSVP 起 源 於 Integrated Service,但它適用於前述的合併式的架構中,且漸被 公認是用來達成 QoS signaling 的最佳選擇。RSVP 必 須運作於既有的路由協定之上,適用於單點(unicast) 或群播(multicast)的傳輸模式,採用 Receiver-oriented 的方式運作,也就是由需要服務的用戶端系統主動發 出 QoS 需求給伺服器端,同時採用 Soft-State 的方式 維護保留資源的狀態[4,6],也就是此 QoS 需求必須週 期性的送出,以便不斷的更新保留的資源狀態,否則 如果用戶端系統離線或者路徑更改,過久未更新的保 留資源會被取消。RSVP 是針對 flow 做資源保留,所 謂的 flow 可以是一點對點的連線,或者是一 multicast session。 RSVP 為了更有效率的達到網路資源共享,提出了三種保留樣式(Reservation Style)來處理 QoS 的需 求:Fixed-Filter Style (FF)、Shared-Explicit Style (SE) 和 Wildcard-Filter Style (WF)。我們可以依實際應用系 統的需要選用適當的保留樣式,當網路上的節點收到 數個屬於同一 flow 的 QoS 需求時,會依其中所指定的 保留樣式進行需求合併,然後做出適當的資源保留決 定,接著產生新的 QoS 需求給下一節點。然而我們發 現此三種保留樣式所產生的合併需求,未能反映出確 切的 QoS 需求,因此某些網路節點所保留的資源會超 出實際上所需要的量,因而導致嚴重的資源浪費,而 間接地影響整個網路的使用效率。有鑑於此,在本論 文中我們提出一套創新的保留樣式,用此保留樣式所 合併後的 QoS 需求即代表著實際的需求,如此一來每 一節點可做到最佳的資源保留,完全免除了前述資源 浪費的問題,而所付出的運算與通訊代價則十分有 限。我們模擬了在 TANet 2 的部分網路架構下,一套 分級式遠距教學系統的運作情形,其中依學生付費的 不同,分成幾種服務等級。其結果驗證了我們所提資 源保留樣式能有效的節省網路資源與降低上線拒絕 率。 本 文 下 面 的 文 章 結 構 說 明 如 下 , 第 二 章 針 對 RSVP 的運作原理及所提供之三種保留樣式的運作做 詳細介紹,並探討保留資源浪費的問題。第三章接著 介紹我們所提出的保留樣式,並討論有關實做此保留 樣式所需的額外負擔。第四章描述我們所模擬的網路 環境與遠距教學系統的運作,將我們的保留樣式與原 有的保留樣式做一比較,針對消耗的網路資源與需求 拒絕率做一討論。第五章為本文總結。
2. RSVP 之概述
2.1 RSVP 運作原理
RSVP 採用由收方主動提出 QoS 要求的模式(如 圖 2),主要運作如下[3]:(1)送方負責送出 Path 訊息 給收方,Path 訊息主要攜帶著送方資料流量特性描述 Tspec 與送方的辨識資訊 sender template (如 sender IP 與 port number)。Path 訊息會依照繞送協定(如:OSPF, DVMRP(Distance Vector Multicast Routing Protocol))等 [7]送至收方,凡於路徑上接收到該 Path 訊息的網路節 點介面,會建立一 Path 狀態,其中記錄了上一個送出 此 Path 訊息的網路節點 IP 位址與 sender template。(2) 收方負責送出 Resv 訊息給送方,Resv 訊息主要攜帶 著資源保留描述 Flowspec 與 Filterspec,Resv 訊息依 據先前所記錄於網路節點中的 Path 狀態,循與 Path 訊息相反的路徑抵達送方,凡接收到 Resv 訊息的網路 節點介面,會依照 Flowspec 與 Filterspec 建立一 Resv 狀態,保留適當的資源。(3)接著資料會循已建立資源 保留的路徑,從送方傳至收方。 Sender RSVP cloud Router Router Receiver (1) PATH (2) PATH (5) RESV (6) RESV (3) PATH (4) RESV 圖 2 RSVP 訊息之流向圖 Flowspec 的值就代表著 QoS 的值(例如:1 Mbps 頻寬 或 10 msec end-to-end 延遲),主要是根據 Path 訊息中 的 Tspec 計算出來的,為了方便討論以下我們採用「頻 寬」為 QoS 的值1。而 Filterspec 就描述那些送方以那 種保留樣式共享此 QoS。2.2 RSVP 保留樣式
保留樣式共分以下三種:(1) Fixed-Filter (FF) Style:QoS 是針對某一特定的送方。我們用 FF {(S1, QS1), (S2, QS2),…}來表示,其中 Sx 表示所選擇之送方的 ID (即 IP + port ID),QSx 表示所需之頻寬。 (2)Shared-Explicit (SE) Style:QoS 是針對某一群特定的送 方。我們以 SE {(S1, S2, …) Q}來表示,其中(S1, S2, …) 代表了一串列共享 QoS 的送方的 ID,Q 表示所需之頻 寬。(3) Wildcard-Filter (WF) Style:QoS 是針對所有屬 於同一 flow (session)中的所有的送方。我們以 WF {*, Q}來代表,其中*表示所有的送方,Q 表示所需之頻 寬。我們接著討論在不同的保留樣式下,路由器如何 處理所收到來自另一個路由器的 Resv 訊息。 FF 保留樣式:收到 FF 訊息的介面,針對不同的來 源路由器記錄個別的(Sx, QSx)。如果來源路由器相同 且已有屬於 Sx的記錄,則採用新收到的 QSx值。在 此介面上所需保留的頻寬為所有存於此介面上 QSx 值的總和。接著所有介面上屬於同一送方的記錄合 併,每一送方對應產生成新的(Sx,QSx’),其中 QSx’ 所有同屬於 Sx的記錄中的最大值,然後這些新的記 錄包裹成 FF 的格式,透過可抵達送方的介面分送 出。以圖 3 為例,說明 FF 保留樣式之運作。 C1 LAN FF{(S1,4B),(S2,5B)} FF{(S1,3B),(S3,B)} FF{(S1,B)} S1 | 4B S2 | 5B S1 | 3B S3 | B FF{(S2,5B),(S3,B)} FF{(S1,4B) Router Router C2 C3 S1 S2, S3 Core Router 圖 3 Fixed-Filter Reservation FF 保留樣式之運作說明如下。 (1) S1、S2與 S3表示送方,C1、C2與 C3表示收方。 (2) FF{(S1,4B),(S2,5B)},表示收方 C1對送方 S1要求 4B 單位頻寬,對送方 S2 要求 5B 單位頻寬。 FF{(S1,3B),(S3,B)},表示收方 C2對送方 S1要求 3B 單位頻寬,對送方 S3則要求 B 單位頻寬。而表示 式 FF{(S1,B)},表示收方 C3對 S1要求一個 B 單位 頻寬。 (3) Core Router 於右上的介面保留 9B 單位,於右下 的 介 面 保 留 4B 單 位 。 然 後 於 左 上 介 面 送 出 FF{(S1,4B)},於左下介面送出 FF{(S2,5B),(S3,B)}。 SE 保留樣式:收到 SE 訊息的介面,針對不同的來 源路由器記錄個別的(S1, S2, …) Q。如果有舊的記 錄,則將之取代。在此介面上所需保留的頻寬為所
1 如何考慮一個以上的 QoS 參數是一個值得進一步 探討的課題。
有存於此介面上 Q 值的最大值。每個介面產生並送 出一個合併的 SE{(S1’, S2’, …) Q’},其中(S1’, S2’, …) 為所有必須透過該介面方可抵達的送方所構成的 串列,而 Q’值為個別成員在介面上所記錄 Q 值的 最大值。以圖 4 為例,說明 SE 保留樣式之運作。 SE{(S1, S3) (3B)} S1 S2, S3 C1 LAN Router Router C2 SE{(S2, S3)(3B)} SE{(S1, S2)(B)} SE{S2(2B)} S1,S2 |(B) S1,S2,S3|(3B) SE{S1(3B)} C3 Core Router 圖 4 Shared-Explicit Reservation SE 資源保留樣式之運作說明如下。 (1) SE{(S1,S2)(B)} ,表示收方 C1對送方 S1與 S2要求 B 單位頻寬。SE{(S1,S3)(3B)},表示收方 C2對送方 S1與 S3要求 3B 單位頻寬。SE{S2(2B),表示收方 C3對送方 S2要求 2B 單位頻寬。 (2) Core Router 則於右上介面保留 B 單位、於右下介 面 保 留 3B 單 位 , 然 後 於 左 上 介 面 送 出 SE{S1(3B)},於左下介面送出 SE{(S2,S3)(3B)}。 WF 保留樣式:比較原保留之頻寬與 Q 值,如果 Q 值較大,則在此介面上保留的頻寬更新為 Q。如果 所有介面保留的頻寬的最大值有所改變,則於每個 介 面 上 ( 除 了 剛 接 收 該 訊 息 的 介 面 ) 送 出 WF{*(Q’)},此處 Q’為新的最大值。以圖 5 為例, 說明 WF 保留樣式之運作。 C1 LAN WF{*(4B)} WF{*(4B)} WF{*(4B)} WF{*(3B)} WF{*(2B)} *︱4B *︱3B Router Router C2 C3 S1 S2, S3 Core Router 圖 5 Wildcard-Filter Reservation WF 保留樣式的運作說明如下。 (1) WF{*(4B)},表示收方 C1對所有的送方(*)要求 4B 單位頻寬。WF{*(3B)},表示收方 C2對所有的送 方(*)要求 3B 單位頻寬。WF{*(2B)},表示收方 C3對所有的送方(*)要求 2B 單位頻寬。 (2) Core Router 於右上介面保留 4B 單位,於右下介面 保留 3B 單位,然後於左上與左下介面皆送出 WF{*(4B)}。 注意,如果路由器所推導出的新訊息內容與先前送出 的訊息內容相同,則放棄立即傳送,而等到更新週期 到期時方主動送出。介面上所記錄的狀態資料,如果 超過某一時間上限仍未被更新,即會被主動移除。 RSVP 僅允許在一個 session 中使用一種保留樣式。為 了說明 RSVP 保留樣式所產生資源浪費的問題,我們 以下用例子來說明。
2.3 資源浪費問題之探討
一個應用系統可能涉及到多種不同形式的資料 流,且資料流之間可能存在某種邏輯關聯,而此邏輯 關聯視通訊模式而定,可能很簡單,例如一群人共同 分享一個聲音頻道;也可能相當複雜且動態改變,例 如一個遠距教學環境,不同的學員可選修不同的課 程,不同的上課型式--同步或非同步線上教學,不同的 選修方式--正式或旁聽等。為了應付如此多樣而變化的 環境,需要一套有效率的方法來描述系統的通訊模 式,以方便分析資源的保留。在此我們採用「真值表」 的方法來描述某一收方如何選擇接收送方的資料流。 假設在整體網路架構中,有 n 個送方可被收方選擇 時,我們將他們編號由 1 到 n,並以 Si表示第 i 個送方, Si是否被選擇以 0 或 1 表示,0 表示沒被選擇,1 表示 被選擇。所以收方對送方選擇的所有組合有 2n種。某 組合是否合法以e表示,若其值為 1 表示合法,0 表 示 不 合 法 , 一 種 合 法 的 組 合 又 稱 之 為 一 個 Truth Assignment。在一個 Truth Assignment 中,所有 Si狀態值為 1 的送方所構成的集合稱為一個 Active Set,以 A 表示。 例如:假設網路中有三個送方分別為 S1、S2與 S3,則可建立 2 3=8 種組合之真值表,其組合情形如 表 1 所示。依需求產生結果e,在表 1 中e值為 1 有 A2、A4與 A5,則 A2、A4與 A5,稱為 Truth Assignment
的 組合 , 在 每 一組 合 中 其 Active Set 的 值 分 別為 A2={S3},A4={S2、S3},A5={S1}。在表 1 中,網底的
部分為 Truth Assignment 與 Active Set 的描述。 表 1 真值表範例 S1 S2 S3 e w A1 0 0 0 0 0 A2 0 0 1 1 b3=7 A3 0 1 0 0 0 A4 0 1 1 1 b2+b3=11 A5 1 0 0 1 b1=3 A6 1 0 1 0 0 A7 1 1 0 0 0 A8 1 1 1 0 0 令 Si所須消耗的頻寬以 bi表示之。在一個 Truth
Assignment k 中,所有 Active Set 內的送方皆會被接 收,所以需要的頻寬可表示為
k i A S i kb
w
又由於一個時間僅存在一種組合,所以必須至少 保留的總頻寬為所有 Truth Assignment 所需頻寬中最 大者,我們稱此頻寬為此真值表 T 的最小頻寬,表示 如下。 BT=max{wk } 以表 1 為例,假設三個送方 S1、S2與 S3的各自頻寬分 別為 b1=3、b2=4 與 b3=7。則所需的 wk列於最右欄, 而 BT為 w4=b2+b3=4+7=11。有了以上的基礎後,我們 嘗試推演出 FF 與 SE 保留樣式的頻寬保留需求。(在此 我們不特別討論 WF,因為就頻寬保留而言,它可視 為 SE 的一種“選擇所有送方”的特例) FF 保留樣式(FF {(S1, QS1), (S2, QS2),…}) 主要是針對特定的送方,做個別資源的保留。假設 網路架構如圖 6 所示,收方 C1的通訊模式為表 1 的 真值表。只要某送方曾出現於某一 Active Set 中, 就必須對該送方發出需求,所以 C1送出的需求便為 FF{(S1,3),(S2,4),(S3,7)}。接著各連線(介面)上頻寬保 留情形分述如下。 (1) C1R1(S1、S2、S3):表示要到達送方 S1、S2、S3, 需經過 C1R1路徑,此路徑保留頻寬為 b1+b2+b3 =3+4+7=14。 (2) R1R2(S1、S2):要到達送方 S1、S2,需經過 R1R2 路徑,此路徑保留頻寬為 b1+b2 =3+4=7。 (3) R2LAN(S1與 S2):要到達送方 S1與 S2,需經過 R2LAN 路 徑 , 此 路 徑 保 留 頻 寬 為 b1+b2 =3+4=7。 (4) R1S3:要到達送方 S3,需經過 R1S3路徑,此 路徑保留頻寬為 b3 = 7。 因此網路各節點所保留頻寬總和為 35。 S3 L A N R1 S2 S1 C1 R2 F F { ( S1, 3 ) , ( S2, 4 ) } B a n d w i d t h = 7 F F { ( S1, 3 ) , ( S2, 4 ) } B a n d w i d t h = 7 F F { ( S3, 7 ) } B a n d w i d t h = 7 F F { ( S1, 3 ) , ( S2, 4 ) , ( S3, 7 ) } B a n d w i d t h = 1 4 T o t a l = 3 5 圖 6 C1送出 FF 保留樣式後網路各節點頻寬保留示意圖 SE 保留樣式(SE {(S1, S2, …), Q}) 從真值表來看,送方串列即所有 Active Set 的聯集, 而共享頻寬為 wk中最大者,也就是 BT。如圖 7 所 示,C1所送出的需求為 SE{(S1, S2, S3),11}。在網路 路徑上,各介面上頻寬保留情形分述如下。 (1) C1R1(S1、S2、S3):表示要到達送方 S1、S2、S3, 需經過 C1R1路徑,因 C1送出 SE{(S1,S2,S3), 11},故 R1介面保留頻寬為 11。 (2) R1R2(S1、S2):要到達送方 S1、S2,需經過 R1R2 路徑,R1送出 SE{(S1, S2),11},R2介面保留頻寬 為 11。 (3) R2LAN(S1與 S2):要到達送方 S1與 S2,需經過
R2 LAN 路徑, R2送出 SE{(S1,S2),11},而 LAN
上保留頻寬2為 11,S 1與 S2介面各保留頻寬為 11。 (4) R1S3:表示到達送方 S3,需經過 R1S3路徑, R1送出 SE{(S3),11}, S3介面保留頻寬為 11。 因此網路各節點所保留頻寬總和為 44。
2 有關如何在 LAN 的環境上保留資源,目前正由
IETF issll (integrated Service over Specific Link) working group 定義中。 S3 L A N R1 S2 S1 C1 R2 S E { ( S1, S2) , 1 1 } B a n d w i d t h = 1 1 S E { ( S1, S2) , 1 1 } B a n d w i d t h = 1 1 S E { ( S3) , 1 1 } B a n d w i d t h = 1 1 S E { ( S1, S2, S3) , 1 1 } B a n d w i d t h = 1 1 T o t a l = 4 4 圖 7 C1送出 SE 保留樣式後網路各節點頻寬保留示意圖 由以上二種情況觀察到令人意外的結果,使用 SE 保留樣式比 FF 保留樣式需要更多的頻寬,似乎違 背了欲用 SE 來提供資源分享的美意。事實上 SE 與 FF 何者為佳,除了取決於應用系統的通訊模式外,亦與 網路的拓樸有密切的關係。一般說來,FF 因為忽略了 資料流間的分享關係,所以易造成接近收方 link 上超 保留;相反的,SE 因為忽略了個別資料流的需求,所 以易造成接近送方 link 上的超保留。 此外,SE 保留樣式的使用,並非想像中的簡單, 我們用下面的例子來說明,假設一個收方 C2欲從 S4 接收資料,其需求頻寬為 b4=14(如圖 8),其真值表如 表 2。C1仍沿用先前的真值表。 表 2 C2之真值表 S4 e w A1 0 0 0 A2 1 1 b4=14 當 使 用 SE 保 留 樣 式 時 , 收 方 C1 仍 發 出 需 求 SE{(S1,S2,S3),11},收方 C2則發出需求為 SE{(S4),14}, 所經路徑其頻寬保留情形分述如下。 (1) C1R1(S1、S2、S3):C1發出 SE{(S1,S2,S3), 11},在 R1介面保留頻寬為 11。 (2) C2R1(S4):C2發出 SE{(S4),14},在 R1介面保留頻 寬為 14。 (3) R1R2(S1、S2、S4):要到達送方 S1、S2、S4,需經 過 R1R2路徑,先前的 SE{(S1,S2,S3),11}與 SE{(S4), 14}合併成 SE{( S1,S2,S3,S4),14},然後由 R1送出, 在 R2介面上保留頻寬為 14。
(4) R2LAN(S1與 S2):R2送出 SE{( S1,S2,S3), 14},LAN
與 S1與 S2分別保留頻寬為 14。 (5) R2S4:R2送出 SE{(S4),14},S4介面保留頻寬為 14。 (6) R1S3:R1送出 SE{(S3),11},S3介面保留頻寬為 11。 因此網路各節點所保留頻寬總和為 78。 S3 L A N R1 S2 S1 R2 S E { ( S1, S2) , 1 4 } B a n d w i d t h = 1 4 S E { ( S1, S2, S4) , 1 4 } B a n d w i d t h = 1 4 S E { ( S3) , 1 1 } B a n d w i d t h = 1 1 T o t a l = 7 8 S4 S E { ( S4) , 1 4 } B a n d w i d t h = 1 4 C2 S E { ( S4) , 1 4 } B a n d w i d t h = 1 4 C1 S E { ( S1, S2, S3) , 1 1 } B a n d w i d t h = 1 1 圖 8 C1與 C2送出 SE 保留樣式後網路節點頻寬保留示意圖
不幸的是,這樣的保留並不正確,因為事實上在 link R1R2上可能同時 C1需要 11,C2需要 14,所以 正確的保留最少應為 25,而非前例中所提的 14。要做 出正確的 SE 需求並不單純,因為必須涉及到參考所有 用戶端(收方)的真值表,但收方的加入或離開可能是隨 時隨地,此意味著必須存在著一個上層管理系統,動 態的集中統合所有真值表,然後做出適當的 SE 需求或 調整既存的 SE,而調整 SE 的動作很可能會要求較高 的頻寬,因而導致資源不足而需求被拒絕,中斷了正 在通訊的連線。有鑑於此,我們將於下一章中提出一 套創新的資源保留樣式—Truth Assignment,此保留樣 式以分散式的方式,計算出每一連線上最小的頻寬需 求,如此一來解決了頻寬超保留的問題,同時降低了 因頻寬調整而被中斷的機率。
3. Truth Assignment 保留樣式
3.1 運作原理
所謂 Truth Assignment (TA)保留樣式,就是在 Resv 訊息中包含真值表,與收方個別的頻寬資訊,路 由器就可依照這些訊息計算出實際所需的頻寬。同時 路由器會將收到的真值表做「合併」與「刪減」的動 作產生新的真值表,然後包裹成 Resv 訊息送出。我們 以單一路由器為例,說明運作的細節,如圖 9 的網路 環境中,有一路由器連結二個收方為 C1、C2與三個送 方分別為 S1、S2與 S3,首先我們定義路由器的訊息之 流向關係,因收方訊息指向路由器,所以稱收方為其 incoming interface 或 downstream(下游),在圖 9 中訊息 a、b 分別為 Resv 訊息。因路由器其訊息輸出指向三 個送方,則稱送方為其 outgoing interface 或 upstream (上游),在圖 9 中訊息 x、y、z 為資源保留要求在合併 後所產生的訊息。Resv a 所表達的真值表 Ta 與 Resv b 所表達的真值表 Tb,分別描述於表 3 與表 4 中,所需 保留的頻寬分別為 B(Ta)對到 C1的 link 而言與 B(Tb)對 到 C2的 link 而言。 R o u t e r S2 S3 C1 C2 S1 a x y z b 圖 9 路由器需求示意圖 表 3 真值表 Ta S1 S2 e 0 0 0 0 1 1 1 0 1 1 1 0 表 4 真值表 Tb S2 S3 e 0 0 0 0 1 1 1 0 1 1 1 0 為要產生新的 x、y、z 需求訊息,Ta與 Tb必須先 行「合併」,合併後的真值表中的 Truth Assignment 就 是 Ta與 Tb的 Truth Assignment 的所有可能“配對”, 所 謂 的 “ 配 對 ” 就 是 將 兩 組 Truth Assignment 的 Active Set 成員「聯集」起來,例如: Ta中的 Active Set
{S1}與 Tb 中的 Active Set {S3} 配對結果產生新的
Active Set {S1, S3},所對應的 Truth Assignment 為 S1、
S2的狀態為 1,S3的狀態為 0。合併後的真值表 Tab, 如表 5 所示。我們用“” 來表示真值表合併的動作。 表 5 Tab真值表 S1 S2 S3 e 0 0 0 0 0 0 1 0 0 1 0 1 0 1 1 1 1 0 0 0 1 0 1 1 1 1 0 1 1 1 1 0 接著為要決定 outgoing interface 所送出的真值 表,我們將 Tab簡化成只描述必須經由該 outgoing interface 方能抵達的送方集合的真值表,也就是刪減 掉不屬於此方集合的送方資訊。令此集合以 G 表示, 其狀態以 r(G)表示,所謂「刪減」就是將原有真值表 中具有相同 r(G)值的列合併成單獨一列,如果這些合 併列中有任一者是 Truth Assignment,則此新的 r(G) 也視為 Truth Assignment。我們將此運算以 d(T,G)表 示,此處 T 為原有的真值表,G 為欲保留的送方集合。 例如,訊息 z 內的真值表為 d(Tab,{S3}),其結果如表 6 所示。(註:全為“0”的狀態是否為 Truth Assignment 對 Truth Assignment 頻寬並無影響,為減少合併時的運 算負擔,我們刻意將它設為非 Truth Assignment。) 表 6 對 S3 做刪減後之真值表 S3 e 1 1 0 0 有了對單一節點的認識後,以下我們以一網路為 例(如圖 10 所示),實際推演訊息的處理與傳送,並瞭 解頻寬保留的情形。 L A N S 1 S 2 S 3 S 4 C 3 C 2 C 1 R 1 R 2 L A N 圖 10 網路架構圖
網路上一端有三個收方為 C1、C2與 C3,其需求為 C1: S1S2,C2:S2S4與 C3:S3;(註:“”表示二者擇 一);另一端有四個送方為 S1、S2、S3與 S4,其頻寬分 別為 b1=3、b2=4、b3=14 與 b4=7;二個路由器分別為 R1與 R2,推演過程如下。
1.
收方 C1與 C2的需求送抵 R1同一介面(左邊),表示 資源可分享,所以 R1會針對他們的真值表,先做合 併動作。表 7 為 C1的真值表,表 8 為 C2的真值表, 在表中網底的部分,表示 Truth Assignment。 表 7 收方 C1:S1S2需求真值表 S1 S2 e 0 0 0 0 1 1 1 0 1 1 1 0 表 8 收方 C2:S2S4需求真值表 S2 S4 e 0 0 0 0 1 1 1 0 1 1 1 0 利用合併後的真值表,來計算收方 C1與 C2R1路 徑的保留頻寬。表 7 有 2 個 Truth Assignment,表 8 有 2 個 Truth Assignment,因此會產生 2 * 2 = 4 種 組合。合併後,產生新的需求真值表,如表 9 所示, 表中每一種組合皆為一 Truth Assignment,利用 Truth Assignment 中之 Active Set,算出每一種組合 之需求頻寬 w,從所有 w 中選出最大者,為該段路 徑的保留頻寬,在本例中保留頻寬為 11(在表 9 中 以網底表示)。 表 9 收方 C1與 C2需求合併後頻寬真值表 (僅顯示 Truth Assignment) S1 S2 S4 w 0 1 1 b2+b4=11 0 1 0 b2=4 1 0 1 b1+b4=10 1 1 0 b1+b2=7 2. 計算收方 C3 R1路徑的保留頻寬。收方 C3的需求 為 S3,其真值表內容說明如表 10,在表中網底的部 分,表示其結果 e 為真之 Truth Assignment,該路徑 上保留的頻寬為 14。 表 10 收方 C3:S3 需求真值表 S3 e w 0 0 0 1 1 b3=14 3. 當資料流傳送到路由器 R1時,因其下游分別來自 C1、C2與 C3,於此將下游之需求合併成一新的真值 表,其合併原則同上所述,利用表 9 與表 10 之 Truth Assignment 組合,產生一個 4*2=8 種組合之真值 表,其結果如表 11 所示。 表 11 送方 C1、C2與 C3合併後之真值表 (僅顯示 Truth Assignment) S1 S2 S3 S4 0 1 0 1 0 1 1 1 0 1 0 0 0 1 1 0 1 0 0 1 1 0 1 1 1 1 0 0 1 1 1 0 4. 以表 11 的內容,來計算路徑 R1R2的保留頻寬。 而在本段路徑上選擇了送方 S1、S2與 S3為對象,經 刪減處理,產生新的真值表及需求保留頻寬,接著 從 w 從中選擇最大者 21 為其保留頻寬,其結果如 表 12 所示。 表 12 R1到 R2路徑保留頻寬真值表 (僅顯示 Truth Assignment) S1 S2 S3 w 0 1 0 b2 =4 0 1 1 b2+ b3=18 1 0 0 b1=3 1 0 1 b1+ b3=17 1 1 0 b1+ b2=7 1 1 1 b1+b2+b3 =21 5. 以表 11 內容,來計算路由器 R2LAN(S1與 S2)路徑 的保留頻寬。對表 11 做刪減之處理,主要針對經過 該路徑之送方為其選擇處理的對象,而在本段路徑 上選擇了送方 S1與 S2為對象,經刪減處理,產生新 的真值表及需求保留頻寬,再從 w 從中選擇最大者 7 為其保留頻寬,其結果如表 13 所示。 表 13 R2到 LAN 路徑保留頻寬真值表 (僅顯示 Truth Assignment) S1 S2 w 0 1 b2=4 1 0 b1=3 1 1 b1+b2=7 6. 以表 11 內容,來計算路由器 R2S3路徑的保留頻 寬。對表 11 做刪減之處理,主要針對經過該路徑之 送方為其選擇處理的對象,而在本段路徑上選擇了 送方 S3,經刪減處理,產生新的真值表及需求保留 頻寬,再從 w 從中選擇最大者 14 為其保留頻寬, 其結果如表 14 所示。 表 14 R2到 S3路徑保留頻寬真值表 (僅顯示 Truth Assignment) S3 w 0 0 1 b3=14 7. 以表 11 內容,來計算路由器 R1S4路徑的保留頻 寬。對表 11 做刪減之處理,主要針對經過該路徑之 送方為其選擇處理的對象,而在本段路徑上選擇了 送方 S4,經刪減處理,產生新的真值表及需求保留 頻寬,再從 w 從中選擇最大者 7 為其保留頻寬,其 結果如表 15 所示。表 15 R1到 S4路徑保留頻寬真值表 (僅顯示 Truth Assignment) S4 w 0 0 1 b4=7 8. 總結上述之狀況,是以 Truth Assignment 保留樣式 作法,求得整體網路所需保留之頻寬總和為: 收方 C1與 C2到 R1路徑+收方 C3到 R1路徑+R1到 R2路徑+R2到送方 S1與 S2路徑+R2到送方 S3路徑+R1 送方 S4路徑 = 11 +14 + 21 + 7 + 14 + 7 = 74 如果使用 FF 的保留樣式,則總共需要之頻寬為 81(我 們省略此部分的推演)。這是因為 TA 保留樣式在每一 link 上頻寬的保留,皆根據真值表來做,其中完整記 錄了所有會使用到該 link 的送方關係,所以保留出來 的結果亦是最佳值,而避免掉了 SE 或 FF 中過多保留 或保留不夠的問題。
3.2 訊息格式與負荷分析
事實上 Truth Assignment 即代表真值表的內涵, 因此我們採用傳送 Truth Assignment 的方式,來節省訊 息傳送的資料量,以下我們利用 BNF 語法描述 TA 保 留樣式的 Resv 訊息規格(如表 16 所示)。基本上 TA 保 留樣式與 FF 保留樣式類似,只是外加了一串 Truth Assignment 的描述,我們只針對與 TA 保留樣式有關 的部分(即網底部分)說明,其它部分的說明請參考[4]。 表 16 Truth Assignment 保留樣式保留訊息格式表 格 式 文 法 說 明1 <Resv Message>::=<Common Header>[<Integrity>] <Session><RSVP_Hop><Time_Value> [<Resv_Confirm>][<Scope>][<Policy_Data>…] <Style><Flow Descriptor List><TA List> 2 <Style>::= TA
3 <Flow Descriptor List>::=<Flowspec><Filter_Spec>| <Flow Descriptor List><Flow Descriptor> 4 <Flow Descriptor> ::= [<Flowspec>]<Filter_Spec> 5 <Truth Assignment List> ::= <Empty>|<Truth Assignment
list><Truth Assignment>
Style:指定保留樣式,為 Truth Assignment (TA)。 Flow Descriptor List:是由一串 Flow Descriptor 所 構成,每一個 Flow Descriptor 說明了一個送方的 ID (<Filter_Spec>),與它所需的頻寬(<Flowspec > )。 Truth Assignment List:是由一串 Truth Assignment
所構成,每一筆 Truth Assignment 是一個 k-bits 的 binary 碼,此處 k 代表著 Flow Descriptor List 中送 方的個數,第 i 個 bit 的值代表著 Flow Descriptor List 中排行第 i 的 Flow Descriptor 所指的送方狀態。 我們採用 TA{{(S,Q)k },{TAp}}的表示法來表示一個 TA 樣式的 Resv 訊息(k 與 p 分別為送方個數與 TA 個數)。 以 3.1 節中圖 10 網路為例,在網路上一端有三個收方 為 C1、C2與 C3,其需求為 C1:S1S2、C2:S2S4與 C3:S3,以 Truth Assignment 保留樣式發出上述的需 求,則個別所發出之 Resv 訊息為(我們只顯示與頻寬 保 留 有 關 資 訊 ) : C1:TA({(S1,3),(S2,4)},{01,10}) 、 C2: TA({ (S2,4) ,(S4,7),}, {01,10})、C3: TA({(S3,14)},{1})。 而負荷主要來自兩方面:一者為 Resv 訊息為攜 帶 Truth Assignment 所需要增加的資料量;另一者為在 節點介面上,為做 Truth Assignment 合併所需的運算負 荷。就第一點而言,我們除了需要攜帶 FF 保留樣式的 所有資訊外,必須附加上有關的 Truth Assignment 的資 訊,假設訊息中共指出了 n 個送方,則每一筆 Truth Assignment 的值可以用一組 n-bits 的 binary code 來代 表 , 在 最 差 的 情 況 下 共有 2n
-1 個 n-bits 的 Truth Assignment (binary code)要送出(註:不會有“00..00” 的組合),如果我們另增一個額外的 check bit 來表示 Truth Assignment List 所代表的是正面含意或反面含 意,則我們可以選擇需要資料量較少的表示方式,來 傳送 Truth Assignment List,如此 Truth Assignment 的 個數會小於 2n-1。一般而言,收方為一般的用戶端,處 理資料的能力有限,因此不會向太多的伺服器(送方) 同 時 要 求 資 料 , 所 以 n 值 不 會 太 大 , 再 者 Truth Assignment 的個數會隨接近送方端而減少(因 n 變 小),所以額外花費在傳送 Truth Assignment 的資料量 應不至於過大。 就第二點而言,兩個真值表的合併,牽涉到個別 Truth Assignment 的 兩 兩 合 併 , 而 每 兩 項 Truth Assignment 的合併,又牽涉到 binary code 的合併,假 設一個 truth table Ta描述了 na個送方,含有 ka個 Truth
Assignment;另一個 truth table Tb描述了 nb個送方,含
有 kb個 Truth Assignment,則兩者合併必須做 ka kb次
的 Truth Assigment 合併,且每次 Truth Assigment 合併 必須檢視 na+nb個 bits,然後做必要的“OR”動作, 所以整個 computational complexity 為 ka kb ( na+ nb) 。 再 一 次 的 說 明 , 如 果 在 送 方 數 目 與 Truth Assignment 的個數不至於太多的話的情況下,此運算 負荷是可以接受的。
4. 環境定義與效能分析
4.1 模擬系統架構
為了驗證 TA 保留樣式的優越性,我們模擬 TANet2 的網路環境,執行了一套分級式的遠距教學系 統,觀察比較 TA 與 FF 保留樣式在「頻寬的使用率」 與「上線拒絕率」上的表現。就 TANet2 所模擬的範 疇而言,其中包括國家高速電算中心(NCHC)、屏東科 技大學(NPUST)、中山大學(NSYSU)、成功大學(NCKU) 與中正大學(CCU) (如圖 11 所示)。其中以 NCHC 的 POP 為中心點,分別連接 NSYSU、NCKU 與 CCU 的 POP 然後各校的 POP 再向下連接至各校的校園網路。 在遠距教學系統中,中山大學(NSYSU)與屏東科技大 學 (NPUST) 各 建 構 了 一 間 遠 距 教 學 教 室 , 分 別 以 Classroom1 及 Classroom2 表示,Classroom1 提供上課 老師的視訊伺服器以 S1表示,其產生每秒 1.5Mb/Sec頻寬的資料量,上課老師聲音伺服器以 S2表示,其產
生每秒 128Kb/Sec 頻寬的資料量(MPEG Layer3 Audio format),與上課資料視訊伺服器以 S3表示,其亦產生
每秒 1.5Mb/Sec 頻寬的資料量。Classroom2 提供的伺 服器同上所述分別為 S4、S5及 S6。因此伺服器系統均
100M b p s L A N 100M b p s LA N 100M b p s L A N 100M b p s L A N 100M b p s LA N N C HC P OP C C UP O P N C K U P O P N S Y S UP O P N S Y S U R ou te r N P US T R ou te r N C K U R ou te r C C U R ou te r T ype1 C lient T ype2 C lie nt T ype3 C lient T yp e4 C lient C la ss ro om 1 C lass roo m 2 S1 1.5 M S2 1 28 K S3 1 .5 M S4 1 .5 M S5 1 28 K S6 1 .5 M 2 0 M bps 2 0 M bps 2 0 M bps 15 5.2 M p b s 1 55 .2M p b s 1 00 M b ps 1.5 M b p s •T AN E T 2骨 幹 •專 線 •校 園 網 路 T yp e1 C lie nt T ype1 C lient T ype2 C lient T ype2 C lient T ype3 C lient T ype3 C lient T ype4 C lient T yp e4 C lient 圖 11 模擬系統網路架構 在 NCKU 的 Router 之下連接著兩個 100 Mbps LAN,在 CCU 的 Router 之下連接著一個 100 Mbps LAN,學生的機器直接連上這些 LAN,收看由 NSYSU 或 NPUST 所播送出來的上課節目。將學生分成幾種不 同等級(如依照付費程度),分別為 Type 1、Type 2、Type 3 及 Type 4,各個 Type 所享有的服務不同,分述如下。 Type 1 : 學 生 可 同 時 收 看 NSYSU (Classroom1) 與
NPUST (Classroom2)老師上課的視訊,只聽其 中一間教室的聲音,且同時可收看 Classroom1 與 Classroom2 上課資料伺服器的資料,所對應 的 Truth Assignment,如表 17 所示。
表 17 Type 1 的 Truth Assignment
S1 S2 S3 S4 S5 S6 1 1 1 1 0 1 1 0 1 1 1 1 Type 2 : 學 生 同 一 時 間 可 選 擇 接 收 Classroom1 或 Classroom2 老師上課的視訊、教室的聲音、上 課資料伺服器的資料,同時允許學生暫時切換 到另一 Classroom 監聽上課內容,所對應的 Truth Assignment,如表 18 所示。
表 18 Type 2 的 Truth Assignment
S1 S2 S3 S4 S5 S6 1 1 1 0 0 0 1 0 1 0 1 0 0 0 0 1 1 1 0 1 0 1 0 1 Type 3 : 學 生 同 一 時 間 可 選 擇 接 收 Classroom1 或 Classroom2 老師上課的視訊、教室的聲音,同 時允許學生暫時切換到另一 Classroom 監聽上 課內容。但無法收看上課資料伺服器的資料, 所對應的 Truth Assignment,如表 19 所示。
表 19 Type 3 的 Truth Assignment
S1 S2 S3 S4 S5 S6 1 1 0 0 0 0 1 0 0 0 1 0 0 0 0 1 1 0 0 1 0 1 0 0 Type 4:學生只能選擇收聽一間教室的聲音。無法收 看到任何視訊,所對應的 Truth Assignment,如 表 20 所示。
表 20 Type 4 的 Truth Assignment
S1 S2 S3 S4 S5 S6 0 1 0 0 0 0 0 0 0 0 1 0 我們假設整個系統中,學生發出收看聽節目的需 求 為 一 Poisson process , 且 收 看 聽 的 時 間 長 度 為 Exponential distribution。當一需求發生時,我們假設 它屬於 Type 1、Type 2、Type 3 與 Type 4 的機率分別 為 5%、10%、30%與 55%,也就是點播的機率隨類型 編號增高而增高。
4.2 系統效能評估與分析
我 們 使 用 LabVIEW (Laboratory Virtual Instrument Engineering Workbench)軟體,來建構我們的 模擬環境。我們發現頻寬的消耗量與 request arrival rate 的關係不顯著,這是因為 multicast 的特性—所有收方 共享從同一送方送出的資料,所以當每個區域有少許 的收方加入時,已保留路徑上所需要的資源,而趨於 穩定狀態,縱然當稍後有更多的收方加入接收時,並 不會造成資源需求明顯的增加。因此在下面的討論中 我們將省略討論改變 request arrival rate 對系統效能的 影 響 , 而 將 它 固 定 在 10 requests/hr 。 我 們 將 針 對 Bandwidth 及 Rejection Probability 等兩項指標進行分 析與討論。
4.2.1 保留頻寬
我們模擬使用 TA 與 FF Style 來產生 Resv 訊 息,並記錄每一時間點的總保留頻寬(也就是所有 link 上所保留頻寬的總和),如圖 12 與圖 13 所示,橫軸的 單位為小時,縱軸的單位為 Kb/Sec。我們先假設 link 的頻寬無限大(也就是說不會有因頻寬不夠而保留被 拒絕的現象)。如我們所預期的,TA Style 所保留的頻 寬總額小於 FF Style 所保留的頻寬,且 FF Style 所保 留的頻寬均集中在 60Mb/Sec 左右,超保留的現象明 顯;反觀 TA Style 所保留的頻寬則會依實際的需求做 調整,而不會發生有超保留的現象。 圖 12 使用 TA Style 的保留頻寬 圖 13 使用 FF Style 的保留頻寬我們收集 100 個小時內的頻寬使用狀況,求得 FF Style 所需的平均頻寬大小為 57093 Kb/Sec,TA Style 所需的平均頻寬大小為 49363 Kb/Sec,使用 TA Style 比 FF Style 節省了 13.5% 的頻寬。
4.2.2 拒絕機率
當使用者的需求超過實體網路所能供應的頻寬 時,就會發生拒絕(rejection)的現象,一個理想的頻寬 保留機制應當盡可能的降低此機率值。我們想瞭解的 是,相較於 FF Style,TA Style 能帶來多顯著的改善。 我們假設 TANet 2 backbone 的 POP 與 POP 間只保留 5Mb/Sec 的頻寬供應用系統使用,且 request arrival rate 為 10 requests/hr,所觀察到的 Rejection Probability 在 TA Style 的環境中為 0.47,而在 FF Style 的環境中為 0.73。大約改善了 35.6%。由此再一次說明 TA Style 能提供較 FF Style 更精準的資源保留,而有效提升系 統的使用率。5. 結論與未來的研究
針對 RSVP 的三種保留樣式 FF、SE 和 WF,經 實例推演後,似乎沒有一定的規則可推得三種保留樣 式中何者最佳,且皆出現超保留網路資源的現象,這 主要是由於此三種保留樣式未能描述出完整的資源共 享關係,而導致網路無法做精確的資源保留。針對此 缺 點 我 們 提 出 一 套 嚴 謹 而可 行 的 保 留 樣 式 —Truth Assignment 保留樣式,來達到保留最小頻寬的目的。 基 本 上 我 們 傳 送 描 述 應 用 系 統 的 通 訊 模 式 (Communication Paradigm) 的 真 值 表 ( 即 Truth Assignment),每個網路節點對收到的真值表做「合 併」處理,然後計算出必須保留的最小頻寬,接著做 「刪減」處理,產生簡化的真值表傳給其它上游節點。 我們使用模擬的方式來驗證我們所提演算法的效能, 以 TANet2 部分群播網路環境為我們的實驗網路,模 擬學生分級選修遠距教學課程之情境,經比較模擬結 果後,證明了 TA 保留樣式之優越性。經過分析,使 用此種保留樣式在網路資源使用效能上的獲益,與所 必須付出的通訊與計算代價上相比,是值得的。參考文獻
[1] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and Weiss, W., “An Architecture for Differentiated Services”, RFC 2475, December 1998.
[2] Braden, R., Clark, D., and Shenker, S., “Integrated Services in the Internet Architecture: an Overview”, RFC 1633, June 1994.
[3] Braden, R. and Zhang, Ed., “Resource ReSerVation Protocol (RSVP) -Version 1 Message Processing Rules”, RFC 2209, September 1997.
[4] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., “Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification”, RFC 2205, September 1997.
[5] Chris, M., “RSVP:General-Purpose Signaling for IP”, IEEE Internet Computing, May June 1999. [6] Pan, P., Schulzrinne, H., and Guerin, R., “Staged
Refresh Timers for RSVP”, Internet Draft,
November 1997.
[7] Waitzman, D., Partridge, C., and Deering, S., “Distance Verctor Multicast Routing Protocol”, Interenet RFC 1075, Novermber 1988.
[8] White, P., “RSVP and Integrated Services in the Internet - A Tutorial”, IEEE Communications Magazine, May1997, Vol 35, Iss 5, pp 100-106. [9] Wroclawski, J., “The Use of RSVP with IETF
Integrated Services”, RFC 2210, September 1997. [10] Zhang, L., Deering, S., Estrin, D., Shenker, S., and
Zappala, D., “RSVP: a new Resource ReSerVation Protocol”, IEEE Network, September 1993.