Các Phương Pháp Đảm Bảo Qos Cho Truyền Thông Đa Phương Tiện

thấp. PHB EF yêu cầu một số lượng cổng đầu ra kết nối băng thông đủ lớn để làm cho trễ thấp, tổn hao thấp và jitter thấp.

PHB EF có thể thực hiện được nếu cổng đầu ra kết nối băng thông đủ lớn cộng với kích cỡ bộ đệm nhỏ và các tài nguyên mạng khác được dành cho các gói EF cho phép tốc độ phục vụ của router đối với các gói EF trên một cổng đầu ra vượt quá tốc độ đến λ của các gói tin tại cổng đó.

Điều này có nghĩa là các gói với PHB EF được xem xét với một số lượng đã cấp phát trước băng thông đầu ra và một ưu tiên bảo đảm tổn hao cực tiểu, trễ cực tiểu và jitter cực tiểu trước khi đưa vào hoạt động.

PHB EF thích hợp cho mô phỏng kênh, mô phỏng đường dây được thuê riêng, và các dịch vụ thời gian thực như thoại, video mà không bỏ qua các giá trị tổn hao, trễ và jitter cao.

Hình 2.10 Ví dụ về cài đặt EF

Hình 2.10 chỉ ra một ví dụ về sự thực hiện PHB EF. Đây là một kỹ thuật lập lịch hàng đợi ưu tiên đơn giản. Tại các biên của miền DS, các lưu lượng gói EF được ưu tiên tùy theo các giá trị đã thỏa thuận bởi SLA. Hàng đợi EF trong hình cần đưa các gói tin ra với tốc độ cao hơn tốc độ đến λ của các gói tin. Để cung cấp PHB EF qua một miền DS kiểu end-to-end, băng thông tại các cổng đầu ra của các router lõi cần được cấp phát trước đó để đảm bảo yêu cầu μ > λ. Việc này có thể thực hiện bởi một quá trình cấu hình dự phòng từ trước. Trong hình, các gói EF được đặt tại hàng ưu tiên (hàng đợi bên trên). Với chiều dài như vậy, hàng đợi có thể hoạt động với μ > λ.

Do EF được sử dụng trước tiên cho các dịch vụ thời gian thực như thoại và video và do các dịch vụ thời gian thực sử dụng UDP thay thế cho TCP, RED nhìn chung

không thích hợp cho các hàng đợi EF bởi vì các ứng dụng sử dụng UDP sẽ không đáp ứng cho loại bỏ gói ngẫu nhiên và RED sẽ tách các gói không cần thiết.

2.2.4.2 PHB chuyển tiếp đảm bảo (AF)

PHB AF được xác định bởi RFC 2597. Mục đích của PHB AF là để phân phối các gói tin cậy và vì thế trễ và jitter được coi là không quan trọng bằng mất gói. PHB AF thích hợp cho các dịch vụ không phải thời gian thực như các ứng dụng sử dụng TCP. PHB AF trước tiên định nghĩa 4 lớp: AF1, AF2, AF3, AF4. Cùng với mỗi một trong những lớp AF này, các gói sau đó được phân lớp thành ba lớp con với ba mức ưu tiên tách biệt.

Bảng 2.8 chỉ ra bốn lớp AF và 12 lớp AF con và các giá trị DSCP cho 12 lớp con AF được xác định bởi RFC 2597. RFC 2597 cũng cho phép thêm vào nhiều hơn ba mức ưu tiên tách biệt cho sử dụng nội bộ. Tuy nhiên, những mức ưu tiên tách ra này sẽ chỉ có ý nghĩa trong nội bộ.

Lớp PHB

Lớp con PHB	Loại gói	DSCP
AF4	AF41	Thấp	100010
	AF42	Trung bình	100100
	AF43	Cao	100110
AF3	AF31	Thấp	011010
	AF32	Trung bình	011100
	AF33	Cao	011110
AF2	AF21	Thấp	010010
	AF22	Trung bình	010100
	AF23	Cao	010110
AF1	AF11	Thấp	001010
	AF12	Trung bình	001100
	AF13	Cao	001110

Có thể bạn quan tâm!

Xem toàn bộ 88 trang tài liệu này.

Bảng 2.8 Các DSCP của AF

PHB AF đảm bảo rằng các gói được chuyển tiếp đi với xác suất phân phát tới đích cao cùng với giới hạn của tốc độ được thoả thuận trong một SLA. Nếu lưu lượng AF tại một cổng vào vượt quá tốc độ ưu tiên trước đó, đây là việc không tuân theo thỏa thuận hay “ngoài hồ sơ”, các gói vượt quá này sẽ không được phân phát tới đích với xác suất cao như các gói thuộc lưu lượng đã xác định hay các gói “trong hồ sơ”. Khi có tắc nghẽn mạng, các gói ngoài hồ sơ được loại bỏ trước khi các gói trong hồ sơ bị loại bỏ.

Khi các mức dịch vụ được định nghĩa bằng cách sử dụng các lớp AF, định lượng và chất lượng khác nhau giữa các lớp AF có thể được nhận biết bằng cách cấp phát số lượng băng thông và không gian bộ đệm khác nhau cho bốn lớp AF. Không giống như

EF, hầu hết lưu lượng AF là lưu lượng không thời gian thực sử dụng TCP, và chiến lược quản lý hàng đợi RED là một chiến lược quản lý hàng đợi thích nghi AQM (Adaptive Queue Management) thích hợp để sử dụng cho PHB AF. Bốn lớp PHB AF có thể được thực hiện như bốn hàng đợi riêng biệt. Băng thông cổng đầu ra được chia thành bốn hàng đợi AF. Với mỗi hàng đợi AF, các gói được đánh dấu bằng ba “màu” tương ứng với ba mức ưu tiên tách biệt.

Ngoài 32 nhóm DSCP 1 đã được định nghĩa trong bảng 2.8, 21 DSCP đã được chuẩn hoá như sau: một cho PHB EF, 12 cho PHB AF và 8 cho CSCP. Có 11 nhóm DSCP 1 vẫn còn khả dụng cho các tiêu chuẩn khác.

2.2.5.Ví dụ về Differentiated Services

Chúng ta sẽ xem xét một ví dụ về mô hình và cơ chế hoạt động của Differentatied Service. Kiến trúc của Differentatied Service gồm hai tập chức năng cơ bản:

Chức năng biên: gồm phân loại gói tin (Packet classification) và điều hòa lưu lượng (traffic conditioning). Ở 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 2.12 các gói được gửi từ H1 tới 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 (behavior aggregate) 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 2.12 Ví dụ về DiffServ

Chức năng lõi: Khi một gói đã được đánh dấu DS đi đến một router hỗ trợ DiffServ (Diffservcapable router), 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 (per-hop behavior) gắn với các lớp của gói. Hành vi (Ứng xử) 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 Differentiated Service 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, nếu các gói được gửi từ H1 tới H3 như trong hình sẽ nhận được cùng đánh dấu như các gói từ H2 tới H4, 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à H2 khi chuyển tiếp các gói tới R4. Bởi vậy, kiến trúc Differentatied Service tránh được việc phải giữ trạng thái trên router về các cặp nguồn đích riêng biệt - đây là vấn đề quan trọng đối với vấn đề mở rộng mạng.

Kết luận chương

Chương 2 đã đưa ra và làm rõ hai mô hình chính của việc triển khai, cài đặt chất lượng dịch vụ trong mạng IP. Khi mà mô hình truyền thống best-effort có nhiều nhược điểm thì các mô hình ra đời sau như IntServ và DiffServ đã giải quyết phần nào các vấn đề mà best-effort không giải quyết được. IntServ đi theo hướng đảm bảo chất lượng dịch vụ cho từng luồng riêng, nó được xây dựng gần giống với mô hình chuyển mạch kênh với việc sử dụng giao thức dành trước tài nguyên RSVP. IntSer phù hợp với các dịch vụ đòi hỏi băng thông cố định không bị chia sẻ như các dịch vụ VoIP, dịch vụ multicast Tivi. Tuy nhiên IntSer có những nhược điểm như sử dụng nhiều tài nguyên mạng, khả năng mở rộng không cao và không mềm dẻo. DiffServ ra đời với ý tưởng giải quyết những nhược điểm của mô hình IntServ.

DiffServ đi theo hướng đảm bảo chất lượng dựa trên nguyên lý hành vi theo từng chặng căn cứ vào mức ưu tiên của các gói tin đã được đánh dấu. Việc đưa ra chính sách với các loại lưu lượng khác nhau là do người quản trị quyết định và có thể thay đổi theo thực tế nên nó rất mềm dẻo. DiffServ tận dụng tốt tài nguyên mạng hơn, tránh được tình trạng nhàn rỗi băng thông và năng lực xử lý trên router, ngoài ra mô hình DifServ có thể triển khai trên nhiều miền độc lập do vậy khả năng mở rộng mạng trở nên dễ dàng.

Chương 3: CÁC PHƯƠNG PHÁP ĐẢM BẢO QoS CHO TRUYỀN THÔNG ĐA PHƯƠNG TIỆN

Trong các mạng chuyển mạch gói, các luồng gói tin khác nhau thường phải chia sẻ đường truyền trên suốt chặng đường đến trạm đích. Để đảm bảo việc phân phối dải thông cho các luồng công bằng và đạt hiệu quả cao nhất cần phải có các cơ chế phục vụ thích hợp tại các nút mạng, đặc biệt là tại gateways hoặc routers, những nơi thường xuyên có nhiều luồng dữ liệu khác nhau đi qua. Bộ lập lịch có nhiệm vụ phục vụ gói tin của luồng đã chọn và quyết định gói tin nào sẽ được phục vụ tiếp theo. Ở đây luồng được hiểu là tập các gói tin thuộc cùng một lớp ưu tiên, hoặc cùng phát ra từ một nguồn, hoặc cùng có cùng địa chỉ nguồn và đích...

Ở trạng thái bình thường khi không có tắc nghẽn xảy ra các gói tin sẽ được gửi đi ngay khi chúng được chuyển tới. Trong trường hợp xảy ra tắc nghẽn nếu như không áp dụng các phương pháp đảm bảo QoS, thời gian tắc nghẽn kéo dài có thể phát sinh rớt gói, ảnh hưởng đến chất lượng dịch vụ. Trong một số trường hợp hiện tượng tắc nghẽn kéo dài và lan rộng trong mạng, rất dễ dẫn đến hiện tượng mạng bị “treo”, hoặc các gói bị loại bỏ nhiều gây ảnh hưởng nghiêm trọng đến chất lượng dịch vụ.

Vì vậy trong chương này, tại các mục 3.2 và 3.3, chúng tôi giới thiệu một số kỹ thuật giám sát tải trọng lưu lượng mạng điển hình nhằm tiên đoán và ngăn chặn nghẽn mạch trước khi nó xảy ra thông qua biện pháp làm rớt (loại bỏ) gói tin sớm khi mới có dấu hiệu sắp xảy ra tắc nghẽn.

3.1. Phương pháp bỏ đuôi - DropTail

DropTail là cách thức quản lý hàng đợi đơn giản, truyền thống dựa vào cơ chế FIFO. Tất cả các gói tin đến được xếp vào hàng đợi, khi hàng đợi đầy thì những gói tin đến sau sẽ bị loại bỏ.

Do đặc tính đơn giản, dễ triển khai mà DropTail đã được sử dụng nhiều năm trên hệ thống router ở Internet, tuy nhiên giải thuật này có những nhược điểm như sau:

− Không tránh được hiện tượng “Lock out”: Xảy ra khi có 1 hay vài dòng lưu lượng độc chiếm hàng đợi, làm cho các gói tin của các kết nối khác không thể đi qua router. Hiện tượng này ảnh hưởng rất lớn tới các giao thức truyền tin cậy như TCP, theo giải thuật chống tắc nghẽn thì khi bị Lock out, luồng kết nối TCP sẽ giảm kích thước cửa sổ (window size) và thực hiện giảm tốc độ truyền gói tin theo hàm số mũ.

− Có thể gây nên hiện tượng Global Synchronization: Là kết quả khi hiện tượng “Lock out” xảy ra nặng nề. Một số các router lân cận có hàng đợi bị độc chiếm bởi 1 số kết nối, khiến cho hàng loạt các kết nối TCP khác không thể đi qua và đồng loạt giảm tốc độ truyền. Sau khi các kết nối độc chiếm kia tạm ngừng,

hàng đợi được giải phóng, thì cũng phải mất 1 thời gian đáng kể thì các kết nối TCP mới có thể trở lại tốc độ ban đầu.

− Hiện tượng Full Queue: Dữ liệu truyền trên Internet thường xuyên có sự bùng nổ, các gói tin đến router thường theo từng cụm chứ không phải lần lượt. Vì thế cơ chế hoạt động của DropTail khiến cho hàng đợi có thể dễ dàng bị đầy trong 1 khoảng thời gian dài, dẫn đến thời gian trễ trung bình của các gói tin lớn. Để tránh hiện tượng này thì với DropTail chỉ có cách là tăng bộ đệm của router, cách này tỏ ra hết sức tốn kém và không hiệu quả.

− Không đảm bảo QoS: Với cơ chế DropTail thì không có cách nào để ưu tiên những gói tin quan trọng được truyền qua router sớm hơn khi tất cả đang ở trong hàng đợi. Trong khi đó với truyền thông đa phương tiện, việc bảo đảm kết nối, tốc độ ổn định là hết sức quan trọng mà thuật toán DropTail không thể thỏa mãn được.

Vấn đề của việc chọn kích thước bộ đệm của các router ở trong mạng là thực hiện “hấp thụ” các bùng nổ lưu lượng trong thời gian ngắn nhưng không gây ra trễ xếp hàng quá lớn. Điều này là cần thiết trong việc truyền dữ liệu kiểu cụm. Kích thước hàng đợi quyết định kích thước của các cụm gói tin (lưu lượng tăng đột biến) mà chúng ta muốn truyền được, không bị loại ở các router.

Trong mạng ứng dụng trên nền IP, việc loại bỏ gói là một cơ chế quan trọng của việc thông báo tắc nghẽn một cách gián tiếp đến các trạm đầu cuối. Giải pháp giúp tránh cho hàng đợi của các router bị đầy trong khi lại giảm được tỉ lệ gói tin bị loại được gọi là quản lý hàng đợi động.

3.2. Phương pháp loại bỏ ngẫu nhiên – RED

3.2.1 Tổng quan

RED (Random Early Detection of congestion; Random Early Drop) là một trong những thuật toán AQM đầu tiên được đề xuất vào năm 1993 bởi Sally Floyd và Van Jacobson, hai nhà khoa học của Phòng thí nghiệm Lawrence Berkeley thuộc Đại học Califonia, Mỹ. Do những ưu điểm nổi bật so với các thuật toán quản lý hàng đợi trước đó, RED đã được cài đặt và triển khai rộng rãi trên mạng Internet.

Điểm cơ bản nhất trong công trình của họ là cho rằng nơi hiệu quả nhất để phát hiện tắc nghẽn và phản ứng lại hiện tượng này chính là tại các gateway hay router.

Các thực thể nguồn (thực thể gửi) cũng có thể làm điều này thông qua ước lượng độ trễ end-to-end, sự thay đổi thông lượng, hoặc qua tỉ lệ các gói tin phải phát lại do bị loại bỏ. Tuy nhiên, từ khung nhìn của các thực thể gửi và nhận của một kết nối cụ thể không thể biết những gateway nào trên mạng đang bị tắc nghẽn, không thể phân biệt được độ trễ lan truyền (propagation delay) và độ trễ hàng đợi (queueing delay). Chỉ có gateway mới có cái nhìn đúng đắn về trạng thái của hàng đợi, sự chia sẻ đường truyền của các kết nối đi qua nó tại mọi thời điểm, cũng như yêu cầu chất lượng dịch vụ của

các dòng lưu lượng. RED gateway theo dõi độ dài trung bình của hàng đợi, dựa vào đó để phát hiện sớm dấu hiệu tắc nghẽn sắp xảy ra (chiều dài trung bình của hàng đợi vượt quá một ngưỡng định trước) và phản ứng một cách thích hợp theo một trong hai cách:

− Loại bỏ các gói tin đến theo một xác suất nhất định, để gián tiếp báo cho nguồn về sự tắc nghẽn, nguồn cần giảm tốc độ phát để giữ cho hàng đợi khỏi đầy, duy trì khả năng hấp thu sự đột biến lưu lượng đến.

− Đánh dấu “có tắc nghẽn” theo một xác suất nhất định vào trường ECN trong header của các gói tin TCP để báo cho bên nguồn biết (thực thể nhận sẽ copy bit này vào gói tin biên nhận).

Hình 3. 1 Thuật toán RED

Mục tiêu chính của RED là tránh tắc nghẽn bằng cách điều khiển kích thước hàng đợi trung bình nằm trong một vùng đủ nhỏ và ổn định, cũng có nghĩa là giữ cho độ trễ xếp hàng đủ nhỏ và ổn định. Việc thực hiện mục tiêu này cũng giúp: tránh hiện tượng đồng bộ toàn cục, không chống lại các dòng lưu lượng có đặc tính đột biến (tức là dòng có thông lượng trung bình thấp nhưng độ thăng giáng cao) và duy trì cận trên của kích thước hàng đợi trung bình ngay cả khi không có được sự hợp tác từ các giao thức tầng giao vận.

Để đạt được các mục tiêu trên, các RED gateways phải làm được các công việc sau:

− Việc đầu tiên là phát hiện sớm tắc nghẽn và phản ứng phù hợp để giữ cho kích thước hàng đợi trung bình đủ nhỏ, làm cho mạng hoạt động ở vùng có độ trễ thấp và thông lượng cao, trong khi vẫn cho phép kích thước hàng đợi dao động trong một miền nhất định để hấp thụ các thăng giáng ngắn hạn. Như đã phân tích ở trên gateway là nơi thích hợp nhất để phát hiện tắc nghẽn và cũng là nơi thích hợp nhất để quyết định chọn kết nối cụ thể nào để thông báo tắc nghẽn.

− Việc thứ hai là thông báo tắc nghẽn tới nguồn phát. Việc này được thực hiện bằng cách đánh dấu và thông báo cho nguồn phát giảm lưu lượng xuống. Thông thường RED gateway sẽ loại bỏ gói tin một cách ngẫu nhiên. Tuy nhiên, nếu tắc

nghẽn được phát hiện trước khi hàng đợi đầy thì nên kết hợp với việc đánh dấu gói tin để báo hiệu tắc nghẽn. RED gateway có hai tuỳ chọn: loại bỏ hoặc đánh dấu; trong đó việc đánh dấu được thực hiện bằng cách đánh dấu vào trường ECN của gói tin với một xác suất nhất định, để báo hiệu cho nguồn giảm lưu lượng đưa vào mạng.

− Một mục tiêu quan trọng mà các RED gateway cần đạt được là tránh hiện tượng đồng bộ toàn cục và không chống lại các dòng lưu lượng có đặc tính đột biến. Hiện tượng đồng bộ toàn cục xảy ra khi tất cả các kết nối đồng loạt giảm kích thước cửa sổ phát, dẫn tới thông lượng giảm sút nghiêm trọng ở cùng một thời điểm. Mặt khác, các chiến lược Drop Tail hay Random Drop rất nhạy cảm với các luồng đột biến; tức là hàng đợi tại gateway thường sẽ bị tràn khi có các gói tin từ các luồng này đến. Để tránh hai hiện tượng này, các gateway có thể dùng các thuật toán đặc biệt để phát hiện tắc nghẽn và quyết định kết nối nào sẽ được thông báo tắc nghẽn tại gateway. RED gateway chọn ngẫu nhiên các gói tin đến để đánh dấu; với phương pháp này xác suất đánh dấu một gói tin từ một kết nối cụ thể tỉ lệ với phần băng thông được chia sẻ của kết nối đó tại gateway.

− Một mục tiêu nữa là điều khiển được kích thước hàng đợi trung bình ngay cả khi không có sự hợp tác từ các thực thể nguồn phát. Điều này có thể được thực hiện bằng cách loại bỏ gói tin khi kích thước trung bình vượt quá ngưỡng trên (thay vì đánh dấu nó). Phương pháp này là cần thiết trong trường hợp hầu hết các kết nối có khoảng thời gian phát nhỏ hơn khoảng thời gian khứ hồi, hoặc các thực thể nguồn không có khả năng giảm lưu lượng để phản ứng với việc đánh dấu hoặc loại bỏ gói tin (như các luồng UDP chẳng hạn).

3.2.2 Thuật toán

Phần này sẽ mô tả giải thuật cho các RED gateways. RED gateways tính kích thước hàng đợi trung bình bằng một bộ lọc thông thấp (Low-Pass Filter). Kích thước hàng đợi trung bình này được so sánh với hai ngưỡng: ngưỡng dưới minth và ngưỡng trên maxth. Khi kích thước hàng đợi trung bình bé hơn ngưỡng dưới thì không gói tin đến nào bị đánh dấu hay loại bỏ; khi kích thước hàng đợi trung bình lớn hơn ngưỡng trên thì tất cả các gói tin đến đều bị loại bỏ. Khi kích thước hàng đợi trung bình nằm giữa minth và maxth thì mỗi gói tin đến được đánh dấu hoặc loại bỏ theo một xác suất pa, trong đó pa là một hàm theo kích thước hàng đợi trung bình avg; xác suất đánh dấu hoặc loại bỏ một gói tin của một kết nối cụ thể tỷ lệ với phần băng thông chia sẻ của kết nối đó tại gateway. Giải thuật tổng quát của RED gateway được mô tả như sau: [5]

For each packet arrival

Caculate the average queue size avg If minth ≤ avg < maxth

Xem toàn bộ nội dung bài viết ᛨ