1. Trang chủ
  2. » Giáo Dục - Đào Tạo

Đ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

13 92 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 13
Dung lượng 468,74 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

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.. Mỗi nhãn xác định liên kết ảo giữa các nút và quyết định chuyể

Trang 1

Đ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

Trang 2

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

Trang 3

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]

Trang 4

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

Trang 5

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

Trang 6

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 –

Trang 7

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

Trang 8

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

Trang 9

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

Trang 10

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

Ngày đăng: 23/09/2019, 20:30

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w