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-In-First-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 Label-SwitchedPaths (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

×

×