一、摘要
MPLS (Multiprotocol Label Switching) 使用與ATM交換技術類似的標籤交換(Label
Switching)技術，來提昇router的傳送效率。並具備訊務分級，傳送品質保證等傳統網路所沒有的功能，使得MPLS成為目前網路世界中最受矚目的技術。業界爭相投入開發MPLS相關產品，學術界也有許多人積極的研究改進MPLS。在這份報告中，我們將我們針對MPLS的基本功能，如bandwidth
reservation，LSP reroute 及preemption，等逐一驗證現有的產品是否具有這些功能。
關鍵詞：MPLS、Class of Service、bandwidth reservation、reroute、preemption
二、ＭＰＬＳ功能測試
首先我們我們針對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