行政院國家科學委員會專題研究計畫成果報告

國家實驗網路GigaPop維運計畫-子計畫九

中山大學國家實驗網路NBEN維運計畫

NBEN GigaPop Maintenance and Operation-Subproject 9

計畫編號:NSC 91-2219-E-110-001

執行期限:91年1月1日至91年12月31日

主持人:許蒼嶺    國立中山大學電機工程學系

E-mail:sheu@ee.nsysu.edu.tw

 


一、摘要

MPLS (Multiprotocol Label Switching) 使用ATM交換技術類似的標籤交換(Label Switching)技術,來提昇router的傳送效率。並具備訊務分級,傳送品質保證等傳統網路所沒有的功能使得MPLS成為目前網路世界中最受矚目的技術。業界爭相投入開發MPLS相關產品,學術界也有許多人積極的研究改進MPLS。在這份報告中,我們將我們針對MPLS的基本功能,如bandwidth reservation,LSP reroute 及preemption,等逐一驗證現有的產品是否具有這些功能。

 

關鍵詞MPLSClass of Servicebandwidth reservationreroutepreemption

 

MPLS功能測試

首先我們我們針對MPLS所提供的功能作來做驗證。

 

2.1 Bandwidth Reservation

Fig 2.1  Bandwidth reservation測試架構圖

在這個實驗中,我們將測試由RSVP signaling所建立的 LSP是否具有頻寬預留功能。網路架構如圖2.1所示,NSYSU M5與NSYSU M5-2以fast Ethernet連接,並建立1條頻寬預留70Mbps的LSP。

  由於bandwidth reservation功能,必須網路擁擠的狀況下,才能顯現其效果。因此我們使用IP Traffic這個軟體的packet generator,來產生大量的background traffic。因此實驗中總共會傳送2個traffic flow,其中FTP traffic 1則是利用FTP protocol來傳送檔案,經由LSP傳送。Background traffic則經由一般的IP routing傳送。Max transfer rate代表此flow在沒有其他流量干擾下,單獨傳送所能達到的最高速率。

 

Traffic name

Max transfer rate

FTP traffic 1

58Mbps

Background traffic

74Mbps

 

Background traffic我們產生74Mbps的流量,並分別使用TCP與UPD格式傳送,以觀察不同的background traffic對bandwidth reservation的影響。在FTP與Background traffic同時傳送的狀況下,測量到的傳送速率如下。

 

Traffic name

Transfer rate (TCP background traffic)

Transfer rate  (UDP background traffic)

FTP traffic 1

45Mbps

16Mbps

Background traffic

45Mbps

74Mbps

 

從上表的結果來看,FTP traffic的頻寬並未受到應有的保障。在傳送TCP background traffic的情況下,FTP traffic還可以搶到一半的頻寬。但是遇到UDP background traffic,那麼FTP traffic就沒輒了,只能使用剩下的頻寬。由此結果可看出,LSP不具有bandwidth reservation功能。

為了進一步確認,我們使用第二種架構來驗證。如圖2.2所示,我們在圖2.1的架構上,加入NCHC M5作為第2個ftp server,來產生第二個ftp traffic。

Fig 2.2  Bandwidth reservation測試架構圖2

 

Traffic name

Max transfer rate

FTP traffic 2

20Mbps

 

並建立3條LSP,如下表所示,讓所有的資料皆經由LSP傳送。

 

LSP name

Bandwidth reservation

Traffic flow

LSP1

60Mbps

FTP traffic 1

LSP2

30Mbps

FTP traffic 2

LSP3

10Mbps

Background traffic

 

Background traffic設定與前一個實驗相同,在3個flow同時傳送的情況下,測量到的傳送速率如下。

 

Traffic name

Transfer rate (TCP background traffic)

Transfer rate (UDP background traffic)

FTP traffic 1

35Mbps

9Mbps

FTP traffic 2

20Mbps

8Mbps

Background traffic

35Mbps

74Mbps

 

由結果可看出,FTP traffic的頻寬依然沒有應有的保障。我們翻閱Juniper router的使用手冊[2],其中提到Juniper router現階段的RSVP並未提供resource reservation功能,所以LSP也就不具有bandwidth reservation的功能。

 

2.2 LSP Reroute and Preemption

  在這個實驗中我們將測試MPLS的路徑備援的功能,讓一條LSP裡可以設定多條路徑。當使用中的路徑斷線時,能夠立刻切換到新的路徑。以及preemption功能,觀察在頻寬不足的情況下,router是否會釋放低優先權LSP的頻寬,讓高優先權的LSP使用。

 

Fig 2.3  Reroute測試架構圖

 

  這個實驗使用的網路架構如圖2.3所示,為了製造多重路徑的狀況,我們用2條fast Ethernet連接router,形成2條不同的實體路徑。實驗中總共會建立3條LSP如下表所示,LSP1的優先權最高,LSP3的優先權最低。我們將這3條LSP的primary path與secondary path設定在相同的實體線路。

 

LSP name

Bandwidth

reservation

Priority

Primary path

Secondary path

LSP1

70Mbps

1

Path1

Path1-2

LSP2

70Mbps

2

Path2

Path2-2

LSP3

70Mbps

3

Path3

Path3-2

 

2.2.1 LSP Reroute

  首先建立LSP1,然後檢視LSP的狀態。由下表可看出,由於頻寬充足,所以LSP1使用的是primary path。

 

Nsysu@NSYSU_M5> show mpls lsp

Ingress LSP: 1 sessions

To              From     State  Rt ActivePath   P  LSPname

140.117.44.254  172.16.3.1   Up    1 path1       *   LSP1

Total 1 displayed, Up 1, Down 0

 

此時將primary path的網路線拔掉,再次檢視LSP的狀態,發現LSP1已經切換到secondary path了。由於網路架構較小,router很快就偵測到斷線,所以網路線一拔掉,立刻就切換過去了。因此LSP1即使正在傳送資料,也不會受到太大的影響。

 

Nsysu@NSYSU_M5> show mpls lsp

Ingress LSP: 1 sessions

To            From      State  Rt ActivePath  P  LSPname

140.117.44.254  172.16.3.1   Up   1 path1-2        LSP1

Total 1 displayed, Up 1, Down 0

 

如果我們將網路線接回去,那麼經過一段時間後,LSP1會自動回到primary path。因為router每隔一段時間,就會去檢查primary path是否已恢復正常。如果可以使用,仍然會切換回primary path。

 

2.2.2 LSP Preemption

先建立LSP1,LSP1會使用primary path。接著建立LSP3,由於primary path被LSP1佔用,已無足夠頻寬,而且LSP1的priority比LSP3高,因此LSP3會使用secondary path。如果一開始先建立的是LSP3,然後再建立LSP1,則LSP3原本使用primary path,也會被更換到secondary path。此時我們檢視LSP狀態的狀態如下。

Nsysu@NSYSU_M5> show mpls lsp

Ingress LSP: 2 sessions

To              From    State  Rt ActivePath   P  LSPname

140.117.44.254  172.16.3.1  Up    1 path1       *   LSP1

140.117.48.254  172.16.3.1  Up    1 path3-2         LSP3

Total 2 displayed, Up 2, Down 0

 

接著建立LSP2,由於primary path已被priority最高的LSP1佔用,因此LSP2會擠掉secondary path中的LSP3。此時我們檢視LSP的狀態,由下表可看出,LSP3已沒有其他可用的路徑,因此LSP3呈現斷線狀態。

 

Nsysu@NSYSU_M5> show mpls lsp

Ingress LSP: 2 sessions

To              From    State  Rt ActivePath  P  LSPname

140.117.44.254  172.16.3.1  Up    1 path1      *   LSP1

140.117.48.254  172.16.3.1  Dn    1 -              LSP3

Total 2 displayed, Up 1, Down 1

 

Transit LSP: 1 sessions

To            From     State Rt Style Labelin Labelout LSPname

140.117.44.254  172.16.0.2 Up  0  1   100003     3   LSP2

Total 1 displayed, Up 1, Down 0

 

NCHC M5上檢視LSP建立狀況,由於LSP2的priority較低,因此使用的是secondary path。

 

Nsysu@nchc-jm5> show mpls lsp

Ingress LSP: 1 sessions

To              From    State  Rt ActivePath  P  LSPname

140.117.44.254  172.16.0.2  Up    1 path2-2        LSP2

Total 1 displayed, Up 1, Down 0

 

LSP2剛建立時,並不會立刻擠掉LSP3,而會有一段緩衝時間讓LSP3尋找其他可用路徑。只是在這個測試中,並沒有第3條路徑可以給LSP3使用,所以LSP3就斷線了。

 

2.3 Path Selection

  在這個實驗中,我們將測試當網路上有多條路徑存在時,router是否會選擇網路較不擁擠的路徑來建立LSP。

 

Fig 2.4 Path selection測試架構圖

 

我們使用圖2.4的網路架構,建立2條預留不同頻寬的LSP,如下表所示,以製造負載負不平均的網路狀況。

 

LSP name

Primary path

Bandwidth reservation

LSP1

Path1

70Mbps

LSP2

Path2

50Mbps

 

LSP3中,我們嘗試建立2條不同的primary path以便讓router選擇。但是JUNOS限制僅能有1條primary path存在。所以我們只能建立2條secondary path讓router選擇。為了讓router使用secondary path,我們讓primary path的預留較大的頻寬,使得LSP無法在primary path上建立,LSP3的設定如下。

 

 

Path name

Bandwidth reservation

Primary

Path1

70Mbps

Secondary

Path1

20Mbps

Secondary

Path2

20Mbps

 

LSP3建立完成後,我們檢視LSP3的狀態,發現LSP3使用的路徑是path1,也就是較擁擠的路徑。但是一會兒之後,我們再次檢視LSP3的狀態,發現使用的路徑卻變成path2,也就是較不擁擠的路徑。從這個結果來看,router似乎會自動選擇較佳的路徑來建立LSP。不過這樣的路徑選擇方式與我們的期望不同,而我們也不確定這樣的設定方式使否正確,因此這個問題留待未來做進一步的測試。

 

Class of Service功能測試

  由於LSP不具有bandwidth reservation功能,但我們仍然希望能夠保障高優先權的流量,所以我們嘗試使用class of service來解決這個問題。

 

3.1 Traffic Schedule

 

Fig 3.1 CoS測試架構圖

 

這個實驗使用圖3.1的網路架構,我們在NSYSU M5中把FTP traffic歸類為EF,並將DSCP標示為EF。Background traffic則歸類為BE,DSCP不改變。然後由NSYSU M5-2根據DSCP,放到對應的queue中,並作traffic scheduling。在NSYSU M5-2的traffic scheduling設定如下。

 

Forwarding class

使用頻寬

EF

可使用40%的頻寬

BE

可使用60%的頻寬

 

下表為FTP traffic與Background traffic單獨傳送時所能達到的最高速率。

 

Traffic name

Max transfer rate

FTP traffic

80Mbps

Background traffic

74Mbps

 

Background traffic設定為74Mbps的流量,分別使用TCP與UPD格式傳送。在FTP與Background traffic同時傳送的狀況下,測量到的傳送速率如下。

 

Traffic name

Transfer rate (TCP background traffic)

Transfer rate (UDP background traffic)

FTP traffic

36Mbps

36Mbps

Background traffic

54Mbps

54Mbps

 

由上表的結果可看出,不管background traffic是TCP或是UDP格式,FTP traffic都能受到應有的頻寬保障。因此驗證traffic scheduling功能可正確的執行。另外我們使用port mirror功能抓取FTP traffic封包,其DSCP值確實已修改為EF,因此DSCP標示的功能也可正確執行。

  在traffic scheduling中頻寬控制可分為精確與不精確兩種方式,精確控制表示router會嚴格限制這個queue只能使用我們給定的頻寬,即使有多餘的頻寬,也不會給這個queue使用。我們使用精確控制,讓EF queue只能使用40%的頻寬,然後單獨傳送FTP traffic,FTP traffic的頻寬確實被限制在36Mbps,因此精確控制可以正常運作。

 

Fig 3.2  跨單位CoS測試架構圖

 

接著我們使用圖3.2的架構,測試在跨單位的網路架構下,CoS的運作是否正常。在NCHC M5上將FTP流量歸類微EF,並做將DSCP標示為EF,然後在NSYSU M5上根據DSCP作traffic scheduling。由於FTP server的傳送速率較慢,因此無法從傳送速率來判斷traffic scheduling是否成功。不過我們使用port mirror功能抓取封包,發現DSCP已標示成EF,所以CoS應該是有正確的執行。

 

3.2 CoS-based Forwarding

為了進一步保障高優先權的流量,我們希望讓高優先權的流量與低優先權的流量,使用不同的路徑來傳送,避免高優先權的流量受到干擾。CoS-based forwarding的目的就是要提供這樣的功能。

Fig 3.3 CoS-based forwarding測試架構圖

 

我們使用圖3.3的架構來驗證這個功能,我們希望EF traffic能夠經由Route-1傳送,而BE traffic則經由Route-2傳送。因此我們在router中作了以下的設定。

 

Forwarding Class

Next-hop

EF

211.73.90.3

BE

140.117.47.253

 

我們在140.117.46.1中使用traceroute去檢視行走路徑,封包仍然是經由TANET-NBEN傳送。我們用port mirror功能抓取封包,檢視DSCP,發現DSCP已被改為EF,因此可證實封包確實有送到EF queue中,所以CoS-based forwarding並沒有正確的執行。不過這個項目,我們並沒有作更詳細的測試,因此有可能是設定上的錯誤,所以這個功能仍待進一步研究。

 

參考文獻

[1]         E. Rosen, A. Viswanathan, R. Callon, “Multiprotocol Label Switching Architecture”, RFC 3031, Jan. 2001.

[2]         R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification”, RFC 2205, September 1997.

[3]         JUNOS 5.5 Software Documentation, http://www.juniper.net/techpubs/software/junos/junos55/index.html