Tải bản đầy đủ

Điều tra và so sánh giải pháp qos MPLS và các dịch vụ phân biệt giải pháp qos

Điều tra và so sánh giải pháp QoS MPLS và các
dịch vụ phân biệt Giải pháp QoS
Trừu tượng
Bài báo này kiểm tra hiệu suất của các dịch vụ phân biệt và phương pháp MPLS để đảm
bảo chất lượng dịch vụ (QoS) trong mạng. Tập hợp các kịch bản đầu tiên có các nguồn
lưu lượng truy cập FTP, thoại và video được ánh xạ vào các lớp DiffServ khác nhau và
được xử lý bởi các bộ định tuyến sử dụng các quy tắc xếp hàng khác nhau, tức là FIFO,
xếp hàng ưu tiên, DWRR và WFQ. Trong tập hợp các kịch bản thứ hai, chúng tôi đã triển
khai Chuyển mạch Nhãn Đa giao thức (MPLS) và các nguồn lưu lượng được ánh xạ vào
các Nhãn chuyển đổi (LSP) khác nhau. Chúng tôi cũng thay đổi khả năng liên kết trong
mạng để tạo ra các tình huống mà luồng giao thông phải tuân thủ tắc nghẽn. Kết quả mô
phỏng được thu thập bằng cách sử dụng OPNET IT Guru17.5showed rằng trong trường
hợp tắc nghẽn DiffServ không thể cung cấp bảo đảm QoS. MPLS, mặt khác, có thể định
tuyến lưu lượng trên các đường dẫn không bị kéo dài giúp các luồng đạt được mức QoS
của chúng.
1. Giới thiệu
Với sự gia tăng nhanh chóng số lượng ứng dụng dựa trên mạng, đã có rất nhiều nỗ lực để
đáp ứng yêu cầu chất lượng dịch vụ (QoS) từ các ứng dụng này mà không làm tăng dung
lượng mạng. 1-2] (IntServ) và dịch vụ phân biệt [3] (DiffServ). Trong khi mỗi phương
pháp tiếp cận có lợi ích riêng của nó, có những lúc IntServ và DiffServ không đủ để đáp
ứng các yêu cầu QoS mong muốn.

Kiến trúc Dịch vụ tích hợp [1-2] cung cấp các đảm bảo dòng chảy chi tiết. Để đạt được
mức QoS này, IntServrequires tất cả các routerson luồng đường đi qua để lưu trữ và quản
lý các resourcessuch có sẵn như khả năng liên kết gửi đi spaceand và hàng đợi sẵn có.
Internet thường giao dịch với hàng tỷ luồng lưu lượng truy cập, nhiều trong số đó có thể
đi qua cùng một bộ định tuyến lõi. Duy trì và quản lý việc đặt trước tài nguyên cho tất cả
các luồng đi qua các bộ định tuyến lõicung cấp chi phí xử lý và lưu trữ khổng lồ. Đó là lý
do tại sao các Kiến trúc Dịch vụ Tích hợp không quy mô tốt cho các mạng lớn, vì
Internetand chỉ được triển khai trên quy mô lớn trong các mạng riêng.
Kiến trúc dịch vụ phân biệt [1] kiến trúc sẽ giải quyết vấn đề khả năng mở rộng bằng
cách hỗ trợ các yêu cầu chất lượng theo từng giai đoạn, chất lượng của từng dịch vụ.
Trong kiến trúc dịch vụ phân biệt, các luồng với các yêu cầu QoS tương tự được kết hợp
thành các tập hợp lưu lượng hoặc các lớp lưu lượng. Mỗi tổng hợp hoặc lớp được xác
định bởi điểm mã dịch vụ phân biệt (DSCP). DSCPvalueis được ghi lại trong trường Loại
dịch vụ (ToS) của tiêu đề IP của gói và thường được đặt trong các cạnh mạng, trước khi
gói được nhập vào lõi mạng. Các bộ định tuyến tuân thủ dịch vụ khác nhau xử lý các gói
đến dựa trên hành vi trên mỗi bước được định cấu hình trước (PHB) chỉ định cách thức
các gói thuộc về một tập hợp nhất định sẽ được xử lý (tức là xếp hàng, chuyển tiếp, lên
lịch, vv). Unmarkedpackets không thuộc bất kỳ lớp nào được xử lý theo đặc tả PHB mặc


định. Kiến trúc các dịch vụ phân biệt cung cấp giải pháp có thể mở rộng cho vấn đề QoS.
Tuy nhiên, các bảo đảm QoS do DiffServ cung cấp được gắn chặt chẽ với việc cung cấp
mạng. Nếu đường dẫn mà tổng lưu lượng truy cập di chuyển không có đủ tài nguyên thì
phương pháp DiffServ sẽ không thể đáp ứng các yêu cầu QoS mong muốn.
Chuyển mạch nhãn Multiprotocol (MPLS) [4-5] là một cách tiếp cận để chuyển tiếp dữ
liệu qua mạng dựa trên nhãn đường dẫn chứ không phải địa chỉ mạng. Mỗi nhãn xác định
liên kết ảo giữa các nút và quyết định chuyển tiếp được thực hiện dựa trên nhãn của
gói.By chỉ định đường dẫn được xác định trước cho lưu lượng truy cập cần theo dõi, cân
bằng tải MPLSallows và phân phối lưu lượng truy cập hiệu quả trong mạng. Khi được
triển khai cùng với DiffServ, MPLScan cũng cung cấp hỗ trợ QoS: MPLS vô trách nhiệm
cho việc phân phối lưu lượng trên các đường dẫn không ngắn nhất nhằm cung cấp việc sử
dụng hiệu quả tài nguyên mạng, trong khi DiffServ phân biệt dịch vụ cho tập hợp lưu
lượng tại các router riêng lẻ [5].

Trong bài báo này, chúng tôi kiểm tra hiệu suất của các cơ chế xếp hàng khác nhau được
sử dụng cùng với các dịch vụ phân biệt và phương pháp tiếp cận MPLS để đảm bảo chất
lượng dịch vụ (QoS). Trong nghiên cứu của chúng tôi, chúng tôi đã kiểm tra hiệu suất của
các ứng dụng video, thoại và video khi gửi lưu lượng truy cập qua mạng với First-InFirst-Out (FIFO), Priority Queuing (PQ), Deficit Weighted Round Robin (DWRR), và
Weighted Fair Các hàng đợi xếp hàng (WFQ) được triển khai tại giao diện bộ định tuyến
được kết nối với liên kết nút cổ chai. Chúng tôi đã kiểm tra hai kịch bản một với MPLS


bị vô hiệu hóa và một số khác đã bật MPLS. Trong kịch bản thứ hai, chúng tôi đã triển
khai Multiprotocol.
Chuyển đổi nhãn (MPLS) và các nguồn lưu lượng được ánh xạ thành các LabelSwitchedPaths (LSP) khác nhau. Chúng tôi đã thay đổi dung lượng liên kết trong mạng
để tạo ra các tình huống mà luồng lưu lượng phải tuân theo tắc nghẽn. Kết quả mô phỏng
thu được bằng cách sử dụng OPNET IT Guruversion 17.5 [6] cho thấy rằng trong trường


hợp severecongestion, DiffServ không thể cung cấp bảo đảm QoS. MPLS, mặt khác, có
thể định tuyến lưu lượng trên các đường dẫn không bị kéo dài giúp các luồng đạt được
mức QoS mong muốn của chúng.
Phần còn lại của bài báo được tổ chức như sau. Phần 2 cung cấp một nghiên cứu tóm tắt
trong đó chúng tôi đã kiểm tra hiệu suất ứng dụng trong mạng IntheDifferentiated
Services với MPLS bị vô hiệu hóa. Trong phần 3 chúng tôi đã kiểm tra hiệu năng ứng
dụng trong mạng với MPLS được kích hoạt và minh họa rằng MPLS có thể giúp các ứng
dụng đạt được mức QoS mong muốn của chúng trong các tình huống mà cách tiếp cận
các dịch vụ khác biệt không thực hiện được. Bài báo kết luận trong Phần 4.
2. Hiệu suất ứng dụng trong mạng dịch vụ phân biệt với MPLS bị vô hiệu hóa
2.1 Thiết lập mô phỏng
Trong nghiên cứu của chúng tôi, chúng tôi đã sử dụng cấu trúc liên kết mạng được hiển
thị trong Hình 1, nơi các nút máy khách (ví dụ, FTP Client, VoIP Caller và Video Caller)
gửi lưu lượng FTP, Voice và Video đến các đích tương ứng của chúng (ví dụ: FTP Server,
VoIP) Người nhận và Người nhận video). Trong kịch bản DiffServ không có MPLS, tất
cả lưu lượng truy cập trên đường đi ngắn nhất thông qua liên kết Router1 –Router 3,
được cấu hình là nút cổ chai. Trong kịch bản MPLS, luồng lưu lượng có thể sử dụng một
đường dẫn thay thế Router 1 –Router 2 –Router 3 cho phép chúng sử dụng tốt hơn tài
nguyên mạng và đạt được mức độ thỏa mãn QoS cao hơn.
Bảng 1 cho thấy cấu hình của các ứng dụng FTP, Thoại và Video và các dấu hiệu DSCP
của chúng. Wesummarize cấu hình của các hàng đợi DiffServ khác nhau trong bảng 2.
Tất cả các cơ chế xếp hàng được cấu hình với các cấu hình QoS toàn cầu và được triển
khai trên các giao diện liên kết với nút cổ chai giữa Router 1 và Router 2.Để đơn giản hóa
việc phân tích và so sánh kết quả thu được, chúng ta đã vô hiệu hóa RED và sử dụng
hằng số tốc độ truyền tải giao thông.


Chúng tôi đặt dung lượng của các liên kết kết nối các nút kết thúc với các cổng của chúng
(ví dụ: Bộ định tuyến 1 và Bộ định tuyến 2) với các nút của dòng DS3. Chúng tôi thay
đổi dung lượng trên liên kết nút cổ chai Router 1 –Router 2 bằng cách đặt nó thành
1.0Mbps, 1.5 Mbps và 2.0Mbps. Cấu hình như vậy dẫn đến các mức tắc nghẽn mạng
khác nhau vì tổng lưu lượng truy cập đến vượt quá khả năng của liên kết nút cổ chai.



2.2. Phân tích kết quả
Hình 2 minh họa tổng lượng lưu lượng được tạo ra bởi các ứng dụng riêng lẻ trong
nghiên cứu này. Cụ thể, lưu lượng truy cập video được tạo ở tốc độ không đổi 1,4 Mbps,
lưu lượng VoIP được tạo với tốc độ không đổi là 45,6 Kb / giây và lưu lượng truy cập
FTP là được gửi ở tốc độ trung bình khoảng 420Kbps. Trong hình 2, có hai dòng cho lưu
lượng ứng dụng FTP: một dòng cho thấy tốc độ truyền khoảng 840 Kb / giây và một tốc
độ truyền khác là 0 Kbps, biểu thị tốc độ truyền trung bình khoảng 420 Kb / giây.
Figure3–5illustrate cách các kỹ thuật xếp hàng khác nhau phân phối băng thông sẵn có
trên liên kết nút cổ chai Router 1 –Router 3among ứng dụng cá nhân. Mỗi hình có bốn
biểu đồ, một cho mỗi cơ chế xếp hàng (nghĩa là, WFQ, DWRR, PQ và FIFO). Mỗi biểu
đồ chứa ba dòng, mỗi dòng đại diện cho ứng dụng thông qua ứng dụng thông qua (tức là,
Video, FTP, VoIP) tại các giá trị khác nhau của khả năng liên kết nút cổ chai. Ví dụ, bảng
điều khiển trên cùng bên trái trong Hình 3 minh họa băng thông được phân bổ cho lưu
lượng video bằng cách sử dụngChế độ xếp hạng công bằng (WFQ) khi nút cổ chaicấp độ
được đặt thành1.0Mbps, 1,5 Mb / giây và 2,0Mb / giây.

Trong các kịch bản mà công suất nút cổ chai được đặt thành 2.0Mbps không có tắc nghẽn
và kết quả là tất cả các ứng dụng đều có thể nhận được lượng băng thông gần với những
gì cần thiết cho ứng dụng của chúng. Tuy nhiên, khi dung lượng liên kết nút cổ chai bị
giảm, các ứng dụng không thể đạt được mức QoS mong muốn.
Cơ chế WFQ phân phối băng thông có sẵn giữa các dòng riêng lẻ theo trọng lượng của
chúng, được thể hiện trong Bảng 2.Trong các tình huống mà dung lượng nút cổ chai được
đặt là 1.5 Mbps và 1.0 Mbpstrong cả ứng dụng Video norFTP đều đã đạt được lượng
băng thông và kết quả là mất mát đáng kể và chậm trễ. Các ứng dụng voiceapplication
(còn được gọi là VoIP), mặt khác, performreasonably welland có thể thu được số lượng
tài nguyên cần thiết. Điều này thường xảy ra do ứng dụng VoIP yêu cầu ít băng thông hơn
đáng kể với phần WFQ được phân bổ của nó.
Mức độ đạt được về chất lượng dịch vụ sử dụng DWRR gần như giống với điều đó khi sử
dụng Xếp hạng công bằng xếp hạng. WFQ cung cấp phân phối tài nguyên công bằng chi


tiết theo từng bit. Cơ chế Round Robin Deficit Weighted cung cấp một phân phối tài
nguyên thô hơn. DWRR dựa trên bộ đếm thâm hụt, xác định lượng dữ liệu theo byte có
thể được phục vụ trong mỗi vòng. Trong mỗi vòng hàng đợi chuyển tiếp gói tin lên giao
diện đi miễn là giá trị của bộ đếm thâm hụt lớn hơn kích thước của gói đó. Kết quả là,
DWRR có thể phục vụ một số lượng gói khác nhau trong mỗi vòng, dẫn đến sự biến thiên
nhiều hơn một chút về băng thông đạt được so với khi sử dụng WFQ.





Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Tải bản đầy đủ ngay

×