Ví dụ về Differentiated Services

Một phần của tài liệu Đánh giá yêu cầu tài nguyên mạng của ứng dụng Video Conference (Trang 64)

Chúng ta sẽ xem xét một ví dụ về mô hình và cơ chế hoạt động của mô hình dịch vụ phân biệt DiffServ, được minh họa trên Hình 3.10; Trong đó các router R1, R2, R6, R7 là router biên, các router R3, R4, R5 là router lõi, còn H1, H2, H3, H4 là các máy tính của người sử dụng.

 Chức năng của các router biên: Gồm phân loại, đánh dấu gói tin và điều hòa lưu lượng. Ở biên vào của mạng, các gói đến sẽ được đánh dấu. Đặc biệt, trường DS nằm trên phần header gói được thiết lập một giá trị nhất định. Ví dụ trên hình 3.10 các gói được gửi từ H1 đến H3 sẽ được đánh dấu tại R1, trong khi các gói từ H2 tới H4 được đánh dấu tại R2. Những nhãn được đánh dấu trên gói nhận được chính là định danh lớp dịch vụ mà nó thuộc vào. Các lớp lưu lượng khác nhau sẽ nhận được các dịch vụ khác nhau trong mạng lõi. Định nghĩa của RFC sử dụng thuật ngữ tổng hợp hành vi mà không dùng thuật ngữ class traffic. Sau khi được đánh dấu, một gói có thể được chuyển tiếp ngay lập tức vào mạng, trễ một khoảng thời gian trước khi được chuyển đi, hoặc có thể bị loại bỏ. Chúng ta sẽ thấy có nhiều yếu tố ảnh hưởng tới việc gói bị đánh dấu như thế nào, và chúng được chuyển tiếp ngay, trễ lại hay bị loại bỏ.

Hình 3.9. Ví dụ về DiffServ

 Chức năng của các router lõi: Khi một gói đã được đánh dấu DS đi đến một router hỗ trợ DiffServ, các gói được chuyển tiếp tới router kế tiếp dựa vào kỹ thuật hành vi theo từng chặng gắn với các lớp của gói. Hành vi từng chặng ảnh hưởng tới bộ đệm của router và băng thông đường truyền được chia sẻ giữa các lớp đang cạnh tranh nhau về lưu lượng. Một nguyên tắc quan trọng của kiến trúc DiffServ là các cư xử từng chặng của router sẽ chỉ dựa vào đánh dấu gói hay lớp lưu lượng mà nó thuộc vào. Bởi vậy, các gói được gửi từ H1 tới H3 sẽ được đánh dấu giống như đối với các gói từ H2 tới H4, nghĩa là khi đó các router mạng cư xử các gói hoàn toàn giống nhau, mà không quan tâm gói xuất phát từ H1 hay H2. Ví dụ, R3 không phân biệt giữa các gói từ H1 và H3 khi chuyển tiếp các gói tới R4. Bởi vậy, kiến trúc DiffServ tránh được việc phải lưu giữ trạng thái trên router về các cặp nguồn đích riêng biệt – đây là vấn đề (ưu điểm) quan trọng đối với vấn đề mở rộng mạng.

3.3. Tích hợp mô hình IntServ với mô hình DiffServ - Mô hình đề xuất

Chúng ta đã biết, hiện nay các mạng (đặc biệt là mạng Internet) đang sử dụng một trong hai mô hình IntServ hoặc DiffServ để cung cấp các dịch vụ có hỗ trợ đảm bảo chất lượng, như vận chuyển dữ liệu, voice, video,.... Với việc áp dụng mô hình IntServ thì chất lượng của các dịch vụ được bảo đảm, tuy nhiên do nhược điểm tính khả mở kém, nên khó áp dụng trong thực tế. Nếu áp dụng mô hình DiffServ, thì chất lượng các dịch vụ, đặc biệt là dịch vụ truyền voice, video thời gian thực sẽ không được đảm bảo chắc chắn và liên tục, có thể sẽ dẫn đến bị mất hình, âm thanh bị trễ,... Do vậy, trong phần này, luận văn sẽ trình bày chi tiết việc đề xuất một mô hình tích hợp hai mô hình dịch vụ IntServ và

DiffServ với nhau, phát huy được ưu điểm của cả hai mô hình, bằng cách sử dụng hàm ánh xạ.

Hiện nay, các mạng thông thường (không áp dụng các mô hình đảm bảo QoS) chỉ dùng một hàng đợi chung cho các lưu lượng của dịch vụ dữ liệu, voice và video. Để tăng hiệu quả của mạng và đảm bảo chất lượng dịch vụ cho các ứng dụng đa phương tiện thời gian thực, chúng ta cần thực hiện phân biệt các loại lưu lượng và sử dụng các hàng đợi có chính sách phục vụ theo mức ưu tiên cho từng loại ứng dụng. Cụ thể: Đối với ba luồng lưu lượng dữ liệu, voice, video thì chúng ta có thể sử dụng ba hàng đợi khác nhau. Đồng thời, có thể gán các thứ tự ưu tiên cho các gói tin thuộc các luồng lưu lượng như sau: video, voice và dữ liệu.

Hình 3.10. Mô hình kết hợp IntServ với mô hình DiffServ

Trong mô hình đề xuất, sử dụng mô hình IntServ cung cấp đảm bảo chất lượng dịch vụ cho các ứng dụng cuối và mô hình DiffServ được thiết kế đảm bảo chất lượng dịch vụ cho nhân của mạng. Điều này dẫn đến, sự kết hợp của mô hình IntServ tại cạnh và DiffServ tại nhân sẽ có thể cung cấp đảm bảo chất lượng dịch vụ tới các ứng dụng cuối.

Một phần của tài liệu Đánh giá yêu cầu tài nguyên mạng của ứng dụng Video Conference (Trang 64)

Tải bản đầy đủ (PDF)

(89 trang)