即時性乙太網路之子網路頻寬管理系統

　

陳郁堂、游順發、臺彥博

國立臺灣科技大學電子工程系

台北市基隆路四段43號

TEL : (02) 27333141 EXT. 6420

EMAIL : ytchen@et.ntust.edu.tw , foxboy1@ms24.hinet.net

　

　

摘要

在網路上傳送多媒體資料已成為一個重要趨勢，然而現有在乙太網路上無法對多媒體資料提供保證品質的服務，本論文提出一主從式 Centralized Token-Bus，將網路傳輸權以Token-Passing方式由伺服器作統一的管理與分配，使作業平台具提供即時服務與保證延遲率的能力。經實驗顯示，在容錯性與有效傳輸率上，Centralized Token-Bus確實比RETHER[5,8]為佳。

　

  1. 研究動機：

由於網際網路的技術一日千里，其應用面也由單純文字傳輸，逐漸演變成複雜但卻聲光效果十足的多媒體。然而多媒體的資料量都相當龐大，在傳統的網路環境下運作產生相當多的問題，其中資料傳輸延遲(delay)是個嚴重的問題。網路上多媒體應用，在網路負載輕時﹐其效能尚可勉強接受，當網路擁塞嚴重時，其效能慘不忍睹。RETHER、PACE、100VG-AnyLAN[2]、ATM等網路架構被提出來解決多媒體資料在網路傳送因擁塞而產生的延遲問題，然而這些網路架構大都需要更新全部或部份的軟硬體，因此無法廣泛為一般使用者所接受。如何在現有網路下避免擁塞為一重要課題，而現有網路中以乙太網路(Ethernet)使用最廣泛。如何在乙太網路環境下提供多媒體資料保證品質的服務，引發我們對這個問題產生研究興趣。

　

二、系統架構

本論文提出一主從式Centralized Token-Bus平台架構，來解決乙太網路上影響即時服務的碰撞問題。所謂主從式是指發言權(token)控制而言。伺服器將網路傳輸權也就是發言權集中管理，再依各節點的需求分配傳輸時間。使同一時段內，只有單一節點進行傳輸資料，藉以避開碰撞的發生。由於頻寬是有限的，隨節點數增加，每一節點的有效傳輸量必然會下降，無法對即時應用提供使用頻寬的保證。因此藉由允入控制機制，有效控制網路負載。

本架構下，除了提供即時性的應用能執行，並保留固定頻寬給非即時的節點，讓網路上每一節點在固定時間內皆可傳出若干資料。目前我們採用函式庫(function library)的方式來架構即時平台。即時應用軟體在傳送資料時可藉由呼叫函式庫，來達到即時服務的要求。

　

2-1 工作原理:

在本通訊協定下，整個子網路(Subnet)可在兩種工作模式下操作﹕乙太模式(Ethernet mode)，與即時模式(real-time mode)。所謂乙太模式(Ethernet mode)，執行IEEE 802.3的Carrier Sense Multiple Access with Collision Detection (CSMA/CD)[4]通訊協定。而即時模式(real-time mode)則採用Token Passing方式來控制網路傳輸權，並加入允入控制(Admission Control)的機制(如圖2-1所示)。整個子網路在起始時工作於乙太模式(Ethernet mode)。如果子網路中有任一節點欲傳送即時性的資料(如﹕digital video or audio)時，則子網路會切換到即時模式(real-time mode)。一般非即時的應用(如WWW、FTP、Telnet)在即時工作模式下，除傳送速度會降低外，其工作並不受影響。其詳細之動作原理分述如下:

圖2-1 模式切換

    (1)起始狀態

圖 2-2 起始狀態

    (2)乙太模式(Ethernet mode)

    子網路工作於乙太模式時，網路執行IEEE802.3 CSMA/CD通訊協定。

    　

    (3)進入即時模式(real-time mode)

圖2-3 即時性需求發生

　

圖2-4 進入即時模式

　

圖 2-5 產生發言權傳遞串列

　

(4)傳遞發言權(token-passing)

  • 發言權控制者產生發言權傳遞串列(token-passing-list)後，依串列的順序，傳遞發言權(token)與擁有發言權(token)的時間。

  • 節點收到此發言權後，開啟網路出口閘，開始傳遞資料，直到擁有發言權(token)的時間用完為止。

  • 當時間用完後，節點必須暫停資料傳輸並將發言權送還給發言權控制者。

  • 發言權控制者回收發言權(token)後，再將發言權及擁有發言權的時間傳遞給下一個節點 (如圖2-6所示)。

  • 發言權(token)是由RT群組與NRT群組依序傳遞，每一循環發言權會傳遞到RT群組與NRT群組中的每一個節點。

    • 圖2-6 傳遞發言權

    (5)新成員加入NRT群組

    當發言權依傳遞串列的順序完成一循環(cycle)傳遞後，發言權控制者會對子網路廣播加入發言權傳遞串列的訊息，使剛開機或重新啟動的節點也可以加入發言權傳遞串列之NRT群組。

    　

    圖 2-7 加入NRT 群組

    　

    (6)新成員加入RT 群組

    當子網路工作在即時模式下，若NRT群組中有任何節點有即時性的要求，須等發言權傳至此節點時，向發言權控制者提出即時要求。發言權控制者依節點所預約之頻寬進行允入控制(admission control)，判斷系統是否有充分資源來提供新節點即時性服務。如果即時要求被接受，發言權控制者會將新成員加入發言權傳遞串列的RT群組，反之；發言權控制者會將拒絕訊息傳遞給提出要求的節點(如圖2-8所示)，允入控制可依2.1式進行判斷。

    　

    (2.1式)

    NTHT(Node Token Holding Timer) ﹕每一節點擁有發言權的時間，也就是每一節點傳輸資料的時間。

    　

    圖2-8 允入控制

    　

    (7)成員離開RT 群組

    當RT 群組的成員，完成即時性資料傳送，對發言權控制者(token controller)送出一歸還頻寬的訊息。發言權控制者(token controller)便將此節點自發言權傳遞串列(token-pass-list)RT 群組中去除(如圖2-9所示)。

    　

    圖2-9 離開RT 群組

    　

    (8)返回乙太模式(Ethernet mode)

    當RT群組中最後一個節點發出離開RT群組的訊息後，發言權控制者會對子網路廣播返回乙太模式的訊息。子網路上的節點於收到此訊號後，自動打開自己的網路出口閘，回復到乙太模式(如圖2-10所示)。

    　

    圖 2-10 切換回乙太模式

    　

    (9)遺失發言權

    發言權控制者將發言權傳遞給節點後，若超過一定時限未收回發言權，則自動假設此節點已發生關機、當機或故障而無法將發言權送回。發言權控制者會重新產生一個發言權傳給下一節點，並將發生錯誤的節點自發言權傳遞串列(token-passing-list)中去除(如圖2-11所示)。

    　

    圖 2-11 發言權遺失處理

    　

    (10) 發言權控制者(token controller)無動作

    當發言權控制者產生錯誤時，如果子網路正處於乙太工作模式下，任何節點提出即時性服務的要求將無任何回應，子網路無法切換至即時模式。如果子網路正處於即時工作模式，由於每一節點均有一計數器，在發言權傳遞串列最大循環時間結束前，沒收到發言權，節點會自動放棄即時資料的傳遞，並打開本身的網路出口閘回到乙太模式(如圖2-12所示)。

    　

    圖2-12 發言權控制者產生錯誤

    　

    2-2 容錯機制

    對於任何網路架構或通訊協定而言，穩定度及容錯性(fault tolerance)是相當重要的一環。以下對即時乙太網路容錯性機制加以說明：

    1. 當機或關機的節點重新啟動時

      2. 無論此時子網路是處於何種模式，開機的節點都不會影響其他節點正常工作。開機節點燃自動啟動一計數器(MTRT)，在計數器倒數為零或接受到發言權控制者的訊息前，開機的節點都不能對子網路送出資料。當子網路處於乙太模式時，計數器將會歸零，節點可開始傳送資料。當網路工作於即時模式下，在計數器倒數為零前，節點會收到加入發言權傳遞串列的訊息，使節點工作於即時模式。而計數器(MTRT)記錄值如以下二式：

      　

      MTRT > Max Total Bandwidth Time (式2.2)

      　

      Max Total Bandwidth Time = Max RT Time + NRT

      Reserved Bandwidth Time + Hardware Overhead

      (式2.3)

      Max Total Bandwidth Time :發言權(token)循環一周的最大時間。

      NRT Reserved Bandwidth Time :保留NRT群組的最少時間(頻寬) 。

      　

    2. 擁有發言權(token)的節點發生錯誤

      3. 任何節點發生錯誤，發言權控制者皆可於發言權傳完一週內發現並予以更正。同樣的，在控制者將發言權傳遞至節點前啟動一計數器(NTHT)。若在此計數器為零前，節點未將發言權傳回發言權控制者，則表示節點產生錯誤。發言權控制者會將此節點從發言權傳遞串列中去除，並自動產生一個新的發言權，傳遞給串列下一節點。

      　

    3. 多個節點同時關機或發生錯誤

      4. 若同時有多個節點產生錯誤，發言權控制者的處理步驟(2)相同。

      　

    4. 發言權控制者(token controller)發生錯誤

    對Centralized Token-Bus而言，發言權控制者發生錯誤是最大的致命傷，所有的即時服務會被迫中止。由於即時模式下的每個節點均有一計數器(MTRT)，計數至少多久發言權將傳給自己一次。當計數時間結束時，發言權尚未傳至，節點會自動切換回乙太模式，繼續其工作。如此網路並不會因發言權主控者故障而完全無法工作。

    三、效能量測

    量測的環境

    在實測系統上，使用一封閉式乙太網路及四台PC進行以下各項測試，以驗證所設計的架構系統所產生之效能，以下是實驗環境的說明(以Centralized Token-Bus架構為主)：

    伺服器(Token controller)

    P1(Pentium Pro 180)

    客戶端(node)

    P2(Pentium 120)、P3(Pentium 133)

    P4(AMD 233)

    作業系統

    Linux slackware 3.4 (kernel 2.0.30)

    傳遞媒體

    10M(bits/sec) Ethernet use HUB

    表 3.1 實驗環境參數

    　

    圖3-1 測試系統配置圖

    　

    驗證實驗

    為了證明Centralized Token-Bus的理論可行性，進行以下的驗證實驗，這裡非即時(NRT)的節點並不傳遞資料。在圖3-2中，可清楚的看出擁有發言權(token)的節點傳送資料及發言權(token)傳遞的情形，驗證所設計之Centralized Token-Bus架構的正確性。實驗參數(如表3. 2所示)及結果(如圖3-2所示)如下：

    　

    PC名稱

    用途

    PC1

    Token Controller

    PC2

    預約一2 Mbits/sec 即時(RT)服務的Client

    PC3

    非即時(NRT)的Client

    PC4

    非即時(NRT)的Client

    表 3. 2 Centralized Token-Bus 驗證環境說明

    　

    圖 3-2 Centralized Token-Bus 驗證圖

    　

    封包實驗

    此實驗主要的目的在比較RETHER與Centralized Token-Bus的控制信號封包數，因為這些封包數的多寡將直接影響到有效資料的傳輸率。由於RETHER[5,8]所設計的動機取自Token-Bus的即時性及乙太網路的平等觀念，所以在RETHER[5,8]下沒有主從式的設計，換句話說每一個節點都是伺服器也是客戶端。因此每一節點必須付出額外空間去記錄其他節點的情況。當子網路的節點增加，控制封包的長度也必須跟著增加，直接影響頻寬的使用。反之， Centralized Token-Bus 將子網路所有節點統一管理，控制封包的長度為一常數，無論節點數目為多少，皆不會影響到頻寬的使用 (如圖3-3所示)。其比較實驗參數及結果如下：

    RETHER

    Centralized Token-Bus

    Server

    P1、P2、P3、P4

    P1

    Client

    P1、P2、P3、P4

    P2、P3、P4

    表 3.3 RETHER與Centralized Token-Bus 之Client-Server對映

    　

    RETHER

    (數列1)

    Centralized Token-Bus

    (數列2)

    1 pass(S <-> C)

    2184 Byte

    1032 Byte

    1 Server and

    2 Client

    2154 Byte

    1032 Byte

    1 Server and

    99 Client

    5064 Byte

    (計算得知)

    1032 Byte

    (計算得知)

    表 3.4 控制封包數量比較表

    　

    圖 3-3 Centralized Token-Bus 與RETHER 控制封包數的比較

    容錯性實驗

    穩定性及容錯性是一個通訊協定成功的基本要求，因此本實驗即對RETHER[5,8]與Centralized Token-Bus的容錯恢復時間進行比較。容錯的設計是系統維護其正常工作的必要措施。由表3. 5可知，RETHER[5,8]在超過兩個節點發生錯誤時，其恢復機制是相當薄弱的。反觀Centralized Token-Bus，除了發言權控制者(Token Controller)發生錯誤外，其餘的節點發生錯誤的恢復時間皆是可以預知的。其實驗結果比較如下：

    條 件

    使PC3、PC4在即時模式時同時當機，量測網路恢復傳送即時資料的時間。

    RETHER

    Centralized Token-Bus

    恢復時間

    (PC3擁有Token)

    10sec

    6sec

    (每一節點 約3sec)

    恢復時間

    (PC4擁有Token)

    無法恢復

    6sec

    (每一節點 約3sec)

    表 3.5 恢復時間比較表

    　

    四、結論

    在現有乙太網路(Ethernet)[1]下無法對即時性資料提供保證品質的服務，本論文提出一Centralized Token-Bus通訊協定來解決這個問題。Centralized Token-Bus 採用主從式(Client-Server)架構。整個子網路在乙太模式下可提供與一般乙太網路相同的便利及傳輸率。在即時模式時，可利用發言權輪流(round-robin)[3]傳輸以避免資料碰撞現象發生，達到傳遞即時資料的目的。由量測的結果顯示，在固定時間內Centralized Token-Bus所傳送的有效資料較RETHER[5,8]為多，且額外的控制封包數也較少，在容錯性､穩定性Centralized Token-Bus都較RETHER[5,8]為佳。Centralized Token-Bus可確實達成資源預留，有效提供即時性服務的目標。

    　

    參考文獻

    1. Anoop Ghanwani, J. Wayne Pace, Vijay Srinivasan, Andrew Smith and Mick Seaman. A Framework for providing Integrated Services Over Shared and Switched IEEE802 LAN Technologies. INTERNER DRAFT, Internet Engineering Task Force , Expires May 1998.

    2. A.R. Albrecht and P.A Thaler. Introduction to 100VG-AnyLAN and the IEEE 801.12 local area network standard. Hewlett-Packard Journal,46(4),Aug.1995.

    3. Carl A. Waldspurger and William E. Weihl. Stride Scheduling : Deterministic Proportional-Share Resource Management. Technical Memorandum MIT/LCS/TM-528. MIT Laboratory for Computer Science Cambridge, MA 02139. June 22,1995.

    4. ISO/IEC 8802-3(4th edition),Carrier sense multiple access with collision (CSMA/CD) access method and physical layer specifications. (1993-07-08).

    5. C.Venkatramani and T. Chiueh. Design, implementation and evaluation of a software-based real-time Ethernet protocol. ACM SIGCOMM 95,1995.

    6. IEEE/ANSI Standard 802.4-1985,Token passing bus access method and physical layer specifications. IEEE Inc., New York, 1985.

    7. IEEE/ANSI Standard 802.5-1985,Token ring access method and physical layer specifications. IEEE Inc., New York, 1985.

    8. T.Chiueh and C. Venkatramani. The Design, Implementation and Evaluation of RETHER: A Real-Time Ethernet Protocol. PhD thesis, State University of New York at Stony Brook,Nov.1996.