PHÁT TRIỂN IP QoS THEO CƠ CHẾ DIFFSERV

Chuyên đề cấp tiến sỹ : PHÁT TRIỂN IP QoS THEO CƠ CHẾ DIFFSERV DiffServ về cơ bản là một lược đồ quan hệ ưu tiên, bằng cách đánh dấu vào trường ToS (Type of Service field) của gói IP và ưu tiên xử lý các gói tùy vào trường này, từ đó hình thành nên các lớp dịch vụ (service class) khác nhau 1. Để nhận các dịch vụ từ nhà cung cấp dịch vụ (Service Provider), người dùng cần phải có hợp đồng mức dịch vụ (Service Level Agreement) với nhà cung cấp dịch vụ. Một SLA về cơ bản là chỉ ra lớp dịch vụ được hỗ trợ và lượng tải cho phép trong mỗi lớp.

BỘ GIÁO DỤC VÀ ĐÀO TẠO TẬP ĐOÀN BCVT VIỆT NAMHỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

MỤC LỤC

CHUYÊN ĐỀ 2

PHÁT TRIỂN IP QoS THEO CƠ CHẾ DIFFSERV

1.Tổng quan về triển khai DiffServ

DiffServ về cơ bản là một lược đồ quan hệ ưu tiên, bằng cách đánh dấu vào trường ToS (Type of Service field) của gói IP và ưu tiên xử lý các gói tùy vào trường này,

từ đó hình thành nên các lớp dịch vụ (service class) khác nhau [1] Để nhận các dịch vụ từ nhà cung cấp dịch vụ (Service Provider), người dùng cần phải có hợp đồng mức dịch vụ (Service Level Agreement) với nhà cung cấp dịch vụ Một SLA

về cơ bản là chỉ ra lớp dịch vụ được hỗ trợ và lượng tải cho phép trong mỗi lớp Một SLA có thể là tĩnh hay động (static SLA hay dynamic SLA) SLA tĩnh được thỏa ước theo định kỳ từng tháng hay năm Một SLA động đòi hỏi người dùng phải dùng giao thức báo hiệu để yêu cầu dịch vụ cho từng cuộc gọi Người dùng

có thể đánh dấu vào gói IP để chỉ ra dịch vụ mong muốn và router nội bộ sẽ đánh dấu gói IP trên cơ sở đó Tại ngõ vào mạng của nhà cung cấp dịch vụ, gói sẽ được phân loại và điều chỉnh theo SLA đã được ký kết Lượng bộ đệm cần cho các hoạt động này cũng được chỉ ra trong SLA Khi gói đi từ domain này sang domain khác, trường ToS của nó có thể được đánh dấu lại dựa trên SLA đã ký kết giữa các domain DiffServ sử dụng các cơ chế phân loại, chỉnh dạng và lập lịch để cung cấp các dịch vụ như:

-Premium Service cho các ứng dụng yêu cầu độ trễ và biến động trễ đều nhỏ

-Assured Service cho các ứng dụng yêu cầu độ tin cậy tốt hơn dịch vụ effort

best Olympic Service cung cấp bộ ba dịch vụ gồm vàng, bạc và đồng với chất lượng dịch vụ của vàng là tốt nhất và đồng là thấp nhất,[2][3]

Điều lưu ý là DiffServ chỉ định nghĩa các mã DSCP (DiffServ Code Point) ghi trong trường ToS và các PHB Còn các nhà cung cấp dịch vụ chịu trách nhiệm qui định dịch vụ cụ thể để cung cấp

DiffServ khác nhau đáng kể so với IntServ (Integrated Service) Thứ nhất, nó chỉ

có một số giới hạn các lớp dịch vụ được chỉ định Vì dịch vụ được gán theo lớp nên lượng thông tin trạng thái lớn hay nhỏ là tùy vào số lượng lớp thay vì tùy vào

số lượng luồng như IntServ, nhờ đó DiffServ có tính khả triển (scalability) cao Thứ hai, các hoạt động phân loại, điều chỉnh phức tạp chỉ diễn ra ở biên giới mạng Các router bên trong domain chỉ cần phân loại các BA (Behavior Aggegate)[9] Do đó, dễ dàng hiện thực và triển khai DiffServ Các mạng của nhà cung cấp

dịch vụ thường có các router biên (edge router) kết nối với khách hàng và nối với các router bên trong (core router) Core router cần phải chuyển gói đi rất nhanh nên nhiệm vụ của chúng phải đơn giản hơn Các router biên không cần phải chuyển gói đi rất nhanh vì hầu hết các liên kết với khách hàng đều chậm Vì vậy các router biên có nhiều thời gian để phân loại và điều chỉnh [4] lưu lượng Các router biên tại các điểm truy nhập mạng NAP (Network Access Point) là ngoại lệ

vì chúng phải chuyển gói đi rất nhanh và còn phải xử lý phân loại và điều chỉnh nên phải được trang bị tốt nhất

Trong mô hình DiffServ có thể gia tăng triển khai dịch vụ đảm bảo (Assured Service) Các router không có khả năng DiffServ sẽ bỏ qua trường ToS của gói Assured Service và chuyển gói dạng này theo dịch vụ Best Effort Tuy nhiên, vì các gói của Assured Service không bị bỏ rơi tại các DiffServ router nên chất lượng toàn cục của lưu lượng Assured Service vẫn tốt hơn so với lưu lượng của Best Effort

Dịch vụ Assured Service hướng đến các khách hàng cần dịch vụ tin cậy từ nhà cung cấp dịch vụ ngay cả trong trường hợp nghẽn mạng Khách hàng phải có SLA với nhà cung cấp dịch vụ và SLA sẽ chỉ ra lượng băng thông sẽ cấp cho khách hàng Khách hàng sẽ chịu trách nhiệm quyết định chia sẻ lượng băng thông này như thế nào cho các ứng dụng của họ SLA cho Assured Service là tĩnh, có nghĩa

là khách hàng có thể bắt đầu truyền số liệu bất cứ lúc nào họ muốn mà không cần báo hiệu cho nhà cung cấp dịch vụ của họ

Assured Service có thể được hiện thực như sau Đầu tiên, sự phân loại và điều chỉnh được thực hiện tại router ngõ vào (ingress router) của mạng phía ISP (Internet Service Provider) Nếu tốc độ của lưu lượng không vượt quá tốc độ bit được chỉ ra trong SLA thì chúng được xem như phù hợp với profile và ngược lại Thứ hai, tất cả các gói phù hợp hay không phù hợp đều được đặt vào một hàng đợi

để tránh sai thứ tự Thứ ba, hàng đơi được quản lý bởi một lược đồ quản lý hàng đợi gọi là phát hiện sớm RED (Random Early Detection) [5] RED có các phiên bản như GRED (generalized RED), RIO (RED with in and out) RED là lược đồ quản lý hàng đợi hủy bỏ gói sớm để ngăn ngừa nghẽn mạng Điều này sẽ tác động lên cơ chế điều khiển luồng (flow control) TCP tại các đầu cuối khác nhau khiến cho tốc độ truyền sẽ thay đổi Bằng cách này RED có thể ngăn chặn hàng đợi của router khỏi bị tràn và do đó tránh được động thái bỏ đuôi (tail-drop) Tail-drop tác động lên nhiều luồng TCP khiến chúng giảm tốc và lại tăng tốc một cách đồng thời Điều này gây ra sự dao động mạnh và có thể ảnh hưởng xấu đến chất lượng mạng RED đã được triển khai rộng rãi trong các mạng của ISP ngày nay RIO là một lược đồ cải tiến của RED Về cơ bản nó giữ lại hai giải thuật chính của RED, một cho các gói phù hợp và một cho các gói không phù hợp Có hai ngưỡng được chỉ ra trong mỗi hàng đợi Khi kích thước hàng đợi còn nhỏ hơn mức thứ nhất, không có gói nào bị hủy Khi kích thước hàng đợi nằm trong khoảng giữa hai

ngưỡng, chỉ có gói không phù hợp là bị hủy một cách ngẫu nhiên Khi hàng đợi vượt quá ngưỡng thứ hai thì cả hai dạng gói đều bị hủy một cách ngẫu nhiên, nhưng gói không phù hợp sẽ bị hủy nhiều hơn Vì các gói phù hợp bị hủy ít hơn ngay cả khi có nghẽn nên khách hàng sẽ nhận được một dịch vụ có thể dự báo được từ mạng nếu họ giữ lưu lượng đúng theo cam kết Khi không có nghẽn các gói không phù hợp vẫn được chuyển nên hiệu suất của mạng cao.

Dịch vụ Best Effort có thể được xử lý theo cách khác hay tương tự với lưu lượng không phù hợp của dịch vụ Assured Service

Premium Service cung cấp dịch vụ có yêu cầu độ trễ và biến động trễ thấp cho khách hàng nên sẽ đảm bảo truyền với tốc độ đỉnh một cách cố định Mỗi khách hàng sẽ có một SLA với ISP, trong đó chỉ ra tốc độ đỉnh mong muốn cho một luồng hay một tập hợp nhiều luồng Khách hàng phải đảm bảo không để vượt quá tốc độ đỉnh đã ký kết, nếu không lưu lượng sẽ bị hủy Về phía ISP sẽ đảm bảo băng thông theo hợp đồng phải luôn khả dụng cho lưu lượng của khách hàng Premium Service thích hợp cho điện thoại IP, hội nghị truyền hình hay xây dựng các kênh leased line ảo cho các mạng riêng ảo VPN (virtual private network) [6]

Vì Premium Service đắt tiền hơn Assured Service nên mong muốn ISP cung cấp SLA cả tĩnh và động SLA động cho phép khách hàng yêu cầu dịch vụ chất lượng cao mà không cần đăng ký Hoạt động điều khiển chấp nhận kết nối rất cần cho SLA động

Premium Service có thể được hiện thực như sau Phía khách hàng, vài thực thể truyền thông sẽ quyết định luồng ứng dụng nào sẽ dùng dịch vụ chất lượng cao Router nối trực tiếp với khách hàng sẻ phân loại và điều chỉnh lưu lượng Về mặt

khái niệm, giả sử có một bit P nào đó trong trường ToS, nếu bit P được cài thì gói

thuộc về Premium Service, ngược lại gói sẽ thuộc về các dịch vụ khác Sau khi chỉnh dạng, bit P của tất cả các gói của luồng được phép dùng Premium Service đều được cài Router ngõ ra của domain khách hàng có thể chỉnh lại lưu lượng để đảm bảo rằng lưu lượng không vượt quá tốc độ đỉnh được chỉ ra trong SLA Về phía nhà cung cấp dịch vụ, ingress router sẽ kiểm tra lưu lượng, lưu lượng vượt

quá tốc độ sẽ bị hủy Tất cả các gói với bit P được cài đều được đưa vào hàng đợi

ưu tiên cho dịch vụ này Các gói trong hàng đợi chất lượng cao bao giờ cũng được truyền đi trước Xử lý truyền được tiến hành theo ba bước: trước tiên, bằng cách điều khiển chấp nhận kết nối lượng lưu lượng chất lượng cao có thể bị giới hạn trong một số phần trăm nhỏ của băng thông liên kết ngõ vào, giả sử 10% Kế đến, các gói vượt quá bị hủy tại ingress router của mạng Các luồng không hợp lệ sẽ không thể ảnh hưởng xấu đến phẩm chất của các luồng hợp lệ khác Sau cùng, các gói chất lượng cao được chuyển đi trước các gói của các lớp khác; chúng có thể dùng 100% băng thông của liên kết ngõ ra

Vì hầu hết các liên kết đều là song công hoàn toàn nên băng thông của liên kết ngõ

ra bằng băng thông của liên kết ngõ vào Do đó, nếu lưu lượng Premium Service được phân phối đều nhau giữa các liên kết thì ba bước trên phải đảm bảo tốc độ phục vụ của hàng đợi Premium Service phải lớn hơn tốc độ đến Do đó, tốt nhất là các gói Premium Service đến trong điều kiện hàng đợi trống hay phải đợi trong thời gian rất ngắn Thời gian trễ hay jitter mà gói Premium Service trãi qua phải rất nhỏ Tuy nhiên, Premium Service lại không đảm bảo giới hạn về định lượng của thời gian trễ và jitter Sự phân phối lưu lượng Premium Service không đều có thể gây ra vấn đề cho Premium Service Trong các mạng ISP, sự tập trung lưu lượng từ các router biên đến các core router bên trong là không thể tránh khỏi, nhưng điều này không thành vấn đề vì tốc độ ngõ ra lớn hơn tốc độ ngõ vào rất nhiều Tuy nhiên, sự tập trung lưu lượng đến core router từ các core router khác thì không thể đảm bảo điều tương tự Bản thân DiffServ không thể giải quyết được khó khăn này Công nghệ lưu lượng/định tuyến dựa vào ràng buộc phải được dùng

để tránh nghẽn gây ra bởi sự phân phối lưu lượng mất cân đối

Bằng cách hạn chế tổng lượng băng thông được yêu cầu bởi lưu lượng Premium Service, người quản trị mạng có thể đảm bảo lưu lượng của Premium Service không làm suy sụp lưu lượng của các dịch vụ khác Cách khác là dùng WFQ (Weighted Fair Queuing) [7] giữa hàng đơi của Premium Service và hàng đợi Assured Service Sau đây là ví dụ về phương thức phân phối tài nguyên tại hai phía khách hàng và ISP

Phân phối tài nguyên tại domain của khách hàng

Cho trước một SLA, domain của khách hàng sẽ quyết định cách thức để các host của domain chia sẻ dịch vụ được chỉ định trong SLA Quá trình này được gọi là sự phân phối dịch vụ Có hai chọn lựa cơ bản:

-Mỗi host tự ra quyết định dùng dịch vụ nào

-Một bộ điều khiển tài nguyên gọi là bandwidth broker (BB) [2] quyết định cho tất cả các host

Một BB có thể là một host, một router hay một phần mềm trên router ngõ ra BB được cấu hình theo các chính sách tổ chức và quản lý tài nguyên của domain Mỗi domain cũng có một BB dự phòng Vì tất cả các host phải cùng chia sẻ lượng tài nguyên có giới hạn được đặc tả bởi SLA nên tốt hơn là phải có một BB để cấp phát tài nguyên

Ở giai đoạn triển khai ban đầu các host không cần cơ chế DiffServ Chúng chỉ cần truyền các gói không đánh dấu Router ngõ ra sẽ đánh dấu trước khi chuyển đến ISP Các gói được xử lý như là dịch vụ Best Effort bên trong domain của khách hàng Trong giai đoạn triển khai kế tiếp, các host có thể có vài cơ chế báo hiệu hay

đánh dấu Trước khi host truyền gói nó có thể quyết định lớp dịch vụ nào cho gói hay có thể tham vấn BB Host có thể đánh dấu các gói hay truyền các gói không đánh dấu Nếu host truyền các gói không đánh dấu thì BB phải dùng vài giao thức như RSVP hay LDAP (Lightweight Directory Protocol) [8] để xác lập các luật phân loại, kiểm tra và chỉnh dạng tại router nối trực tiếp với host sao cho router biết cách đánh dấu các gói truyền.

Nếu SLA giữa khách hàng và ISP là động thì BB trong domain của khách hàng phải dùng vài giao thức báo hiệu để yêu cầu tài nguyên từ ISP

Phân phối tài nguyên tại domain của ISP

Đối với từng SLA, ISP phải quyết định cấu hình các router biên như thế nào để chúng có thể biết cách kiểm soát lưu lượng đến Với SLA tĩnh, các router biên có thể được cấu hình bằng tay theo các luật phân loại, kiểm tra và sửa dạng Do đó, các tài nguyên được phân phối một cách thống kê cho mỗi khách hàng Các tài nguyên không dùng có thể chia sẻ cho các khách hàng khác Với SLA động, sự phân phối tài nguyên có quan hệ gần với quá trình báo hiệu Thành phần BB ở domain khách hàng dùng RSVP để yêu cầu tài nguyên từ ISP Về phía ISP, các quyết định điều khiển chấp nhận được đưa ra bởi BB ở đó Nếu các router biên liên quan trực tiếp đến quá trình báo hiệu, chúng được cấu hình theo các luật phân loại, kiểm tra và sửa dạng tương ứng Nếu BB liên quan đến quá trình báo hiệu chứ không phải router biên, BB phải cấu hình router biên khi chúng phát ra yêu cầu Trong cả hai trường hợp core router của ISP phải được bảo vệ để tránh vấn đề khả triển (scalability)

2 Phương pháp phát triển hệ thống DiffServ

Công việc phát triển một hệ thống DiffServ liên quan đến tổ chức và phát triển hai thành phần chính là bộ điều chỉnh lưu lượng (traffic conditioner) tại router biên (edge router) và các PHB tại các router, đặc biệt là các router bên trong DiffServ domain (core router) Lộ trình của các gói là khi vào edge router sẽ được điều chỉnh lưu lượng cho phù hợp với SLA sau đó được đưa tới giao tiếp ngõ ra của router, tại đó chúng sẽ được định nghĩa PHB (là EF (Expedited Forwarding), AF (Assured Forwarding) hay BE (Best Effort)) Việc này liên quan đến sự phân loại

và chuyển gói vào hàng đợi tương ứng Cách thức kiểm soát các hàng đợi này được chỉ ra bởi cơ chế lập lịch (scheduling mechanism) được dùng Bộ lập lịch gói chịu trách nhiệm hướng dẫn các gói từ các hàng đợi khác nhau thoát ra khỏi hàng đợi và được truyền lên mạng một cách có trật tự Bên trong mạng (core network) căn cứ vào các PHB của từng gói mà các router bên trong (core router) sẽ chuyển các gói đi theo cách xử lý cho từng PHB Như vậy trong phần tử mạng đầu tiên là router biên sẽ được phát triển một bộ điều chỉnh lưu lượng (traffic conditioner) và

các PHB Trong phần tử mạng kế tiếp là các core router chỉ cần phát triển các PHB.

2.1 Phát triển bộ điều chỉnh lưu lượng

Như đã mô tả trong [9] bộ điều chỉnh lưu lượng sẽ gồm các thành phần con là classifier, marker, meter, remarker hay shaper hay dropper Thông thường các thành phần này được hiện thực bằng cách dùng một Token Bucket đơn và một Token Bucket đôi (Dual Token Bucket) [10] Qua đó các thông số của luồng đã cam kết theo SLA được cấu hình thành một Token Bucket profile Các gói lấy được token được xem là các gói hợp lệ (in-profile packet) và các gói còn lại là không hợp lệ (out-profile) [11] Các Token Bucket bảo vệ các luồng với cửa sổ nhỏ, ngăn chặn sự tổn thất gói bằng cách chỉ đánh dấu hợp lệ (in-profile)

Hình 1- Cấu trúc luận lý của bộ điều chỉnh lưu lượng

2.2 Phát triển các PHB

Sau khi các gói đã đi qua giao tiếp ngõ vào của một router mà không bị hủy sẽ được chèn vào giao tiếp ngõ ra của router Hàng đợi tại ngõ ra có thể là một hàng đợi đơn giữ tất cả các gói của các lớp lưu lượng hay gồm một số các hàng đợi, mỗi hàng đợi giữ gói cho mỗi lớp lưu lượng khác nhau Mỗi PHB được thể hiện qua hai cơ chế: cơ chế quản lý hàng đợi và cơ chế lập lịch gói

Cơ chế quản lý hàng đợi

Lưu lượng của mỗi user được đánh dấu là profile hay out-profile Các gói profile được gán một mức hủy gói (drop precedence) thấp hơn các gói out-profile

in-và đựợc mã hóa bằng mã DSCP (DiffServ Code Point) ghi trong trường ToS (Type of Service) của gói Nguyên lý quản lý hàng đợi tích cực (Active Queue

RemarkerShaperDropperTraffic

Profile

Management) RED (Random Early Detection) được dùng để hiện thực quản lý hàng đợi cho DiffServ RED cho phép router hủy gói trước khi hàng đợi bị tràn RED làm được điều này bằng cách hủy các gói theo một xác suất tùy thuộc vào chiều dài hàng đợi trung bình Để hiện thực các mức hủy (drop precedence) khác nhau hay để hình thành các AFij, nguyên lý hàng đợi gồm nhiều RED gọi là GRED (Generalized RED) được dùng Nguyên lý RED này và cách áp dụng vào hiện thực DiffServ sẽ được đề cập ở mục kế tiếp.

Cơ chế lập lịch gói

Có một số cơ chế lập lịch gói có thể được áp dụng bao gồm

-FIFO (first In First Out)

-PQ (Priority Queuing)

-WFQ (Weigh Fair Queuing)

-PQWFQ (Priority Queuing with Weighted Fair Queuing), giải thuật này là

sự kết hợp của PQ và WFQ như trình bày trên hình 2

Hình 2- Tổ chức của cơ chế lập lịch PQWFQ

Lưu lượng ưu tiên cao được chuyển đi với mức ưu tiên cao nhất, bất chấp sự hiện diện của các lưu lượng khác, nhằm hỗ trợ cho các dịch vụ yêu cầu nghiêm ngặt về thời gian thực Trong DiffServ thì dành cho EF PHB Những lưu lượng khác gồm

AF PHB và BE được lập lịch chuyển đi theo giải thuật WFQ

3 Hiện thực DiffServ với RED

3.1 Giải thuật phát hiện sớm ngẫu nhiên RED

RED được đề xuất vào năm 1993 [12] Ý tưởng của RED là cung cấp một phản hồi cho nguồn lưu lượng càng sớm càng tốt trước khi hàng đợi bị tràn để chỉ ra

P Q

WFQ

PQWFQ

Ưu tiên cao

Ưu tiên thấp

nguy cơ bị nghẽn thay vì đợi đến khi nghẽn mới báo Với RED sự hủy gói được phân bố công bằng hơn giữa các luồng.

RED tính toán kích thước hàng đợi trung bình, dùng một bộ lọc thông thấp pass filter) với một EWMA (exponetial weighted moving average) Kích thước hàng đợi trung bình được so với hai ngưỡng: ngưỡng tối thiểu và ngưỡng tối đa Khi kích thướctrung bình của hàng đợi nhỏ hơn ngưỡng tối thiểu thì không có gói nào bị đánh dấu hủy Khi kích thước hàng đợi trung bình lớn hơn ngưỡng tối đa thì tất cả các gói đều bị đánh dấu hủy Nếu các gói bị đánh dấu đều bị hủy sẽ đảm bảo kích thước hàng đợi trung bình không vượt quá ngưỡng tối đa Khi kích thước hàng đợi trung bình nằm giữa ngưỡng tối thiểu và tối đa thì gói sẽ bị đánh dấu với

(low-một xác suất p, trong đó p là (low-một hàm số của kích thước hàng đợi trung bình Xác

suất mà một gói bị đánh dấu là tỉ lệ với băng thông chia sẻ trên liên kết

RED có hai giải thuật riêng biệt: Giải thuật thứ nhất nhằm tính toán kích thước hàng đợi trung bình, xác định hệ số burstiness được phép trong hàng đợi Giải thuật thứ hai để tính toán xác suất đánh dấu gói, xác định tần suất đánh dấu gói, ước lượng mức độ nghẽn hiện hành Mục tiêu ở đây là đánh dấu gói theo khoảng thời gian đều nhau để tránh hiện tượng phân cực hay đồng bộ toàn cục và đánh dấu gói đủ thường xuyên để kiểm soát kích thước hàng đợi trung bình

RED về cơ bản là một nguyên tắc hàng đợi không phân cấp nhằm hạn chế kích thước hàng đợi một cách khôn khéo Các hàng đợi thông thường chỉ hủy gói khi bị đầy chứ không có một động thái tối ưu RED cũng hủy gói theo lối cắt đuôi nhưng theo cách làm từ từ

Một khi chiều dài hàng đợi đạt đến một giá trị nào đó, mỗi gói xếp hàng có một xác suất bị đánh dấu Xác suất này tăng tuyến tính với ngưỡng tối đa, dẫu cho hàng đợi có thể lớn

3.2 Dùng RED trong hiện thực DiffServ

Bản chất tự nhiên của RED rất thích hợp cho thực hiện vài động thái khác thay vì chỉ là cảnh báo nghẽn sớm Vì RED có thể hủy gói một cách ngẫu nhiên theo thông số xác suất có được qua thao tác cấu hình, nên có thể được dùng để hiện thực động thái AF (Assure Forwarding behavior) trong DiffServ Như trong [9] đã đặc tả, trong một lớp AF còn có các mức ưu tiên hủy (drop precedence) gói khác nhau Các drop precedence này có thể được tạo ra bằng cách dùng RED Đây là ý tưởng của các tác giả trong [13] khi họ đề xuất GRED (generalized RED)

RED là một cơ chế cố hữu để đánh dấu các gói một cách ngẫu nhiên Đánh dấu chỉ

có nghĩa là đánh dấu các gói để thông báo cho nơi gửi về nguy cơ của nghẽn hay chỉ đơn thuần là hủy gói Đối với TCP cho phép tùy chọn ECN thì có thể đáp ứng

các gói đánh dấu ECN, với TCP không dùng ECN chỉ đáp ứng với các gói bị hủy Còn đối với UDP và các luồng thụ động khác không phản ứng gì và hủy gói là cách duy nhất để điều khiển chúng.

Xét về đánh dấu hay hủy gói để thông báo nghẽn cho máy nguồn thì RED có ưu điểm là thực hiện điều này một cách ngẫu nhiên bằng giải pháp xác suất Thiết kế ban đầu của RED cố tạo sự công bằng cho các luồng, nhặt lấy gói một cách ngẫu nhiên để giải quyết hiện tượng tụ thành nhóm bởi động thái tự nhiên của TCP, cố gắng điều khiển chiều dài hàng đợi tại các router và cố gắng thông báo nghẽn càng sớm càng tốt để nguồn có những hành động thích hợp

Tuy nhiên, đối với DiffServ sẽ không dùng RED theo cách này, thay vào đó là lợi dụng cơ cấu hủy gói theo xác suất để hiện thực các AF class Mỗi AF class cần hỗ trợ ba mức hủy gói (drop precedence) mà sự khác biệt giữa các mức là xác suất hủy gói RED chỉ hỗ trợ một hàng đợi và một xác suất hủy gói, do đó RED được

mở rộng để hỗ trợ và 16 mức xác suất hủy gói được tạo ra bởi 16 hàng đợi ảo VQ (virtual queue) với thông số cài đặt độc lập Đó là nguyên lý của GRED, hình 3

mô tả hàng đợi với 16 RED trong 1

Hình 3- Tổ chức hàng đợi GRED

GRED như một hàng đợi với đầy đủ các lớp Mỗi lớp có một hàng đợi ảo riêng Mỗi hàng đợi cũng có một bộ lọc (filter) để lọc gói Hoàn toàn có thể gán mức ưu

biết động thái của RED phụ thuộc vào giá trị của chiều dài hàng đợi trung bình gọi

khi lớn hơn ngưỡng lớn nhất thì hàng đợi ở trong trạng thái hủy hoàn toàn, còn

q ave ở trong khoảng giữa hai ngưỡng thì hàng đợi trong trạng thái hủy gói theo xác

lớn Khi hiện thực GRED cho DiffServ, các tác giả đề xuất định nghĩa ưu tiên

trị có được từ quá trình đo lường trên hàng đợi, nhưng hàng đợi mức ưu tiên 2 sẽ

mức ưu tiên nào đó sẽ bằng giá trị tính toán trên nó cộng với tất cả các giá trị được tính trên các hàng đợi ưu tiên có chỉ số đứng trước nó Tuy nhiên, trong một số

hàng đợi ưu tiên như trên, thay vào đó là định nghĩa mỗi động thái chỉ dựa vào các thông số của nó mà không phụ thuộc vào các hàng đợi khác

4 Phân tích động học của RED

4.1 Giới thiệu

Trong [14] đã đề xuất hiện thực RED trong các IP routers như là kỹ thuật quản lý hàng đợi tích cực AQM (Active Queue Management) RED được tin tưởng rằng sẽ khắc phục được các bài toán đồng bộ các luồng và hỗ trợ tốt cho QoS bằng khả năng hủy gói khôn khéo Từ đó, nhiều nghiên cứu đã được thực hiện để phân tích

và đánh giá RED Cho đến nay việc xác định các thông số của RED là không chính xác và nhiều nhà nghiên cứu đã không tán thành việc dùng RED vì khó khăn trong việc xác định này như trong [15] và [16] Trong số các phân tích đánh giá RED có phân tích RED dựa trên quan điểm của lý thuyết điều khiển trong [17] được nhiều người quan tâm Trong nghiên cứu này các tác giả đã dùng mô hình động học của TCP và RED được phát triển trong [18] làm điểm xuất phát để phân tích Phân tích của họ đã đưa ra một số cân nhắc trong việc chọn lựa các tham số cho RED cũng như cung cấp một vài hướng dẫn về thiết kế các hệ thống ổn định tuyến tính và các đại lượng biểu thị tính ổn định và bền vững của hệ thống tuyến tính

4.2 Mô hình luồng động biểu diễn động thái của luồng TCP

Trong [18] một mô hình động học của TCP được phát triển dùng mô hình luồng động và phân tích phương trình vi phân ngẫu nhiên Mô hình này liên quan đến giá trị trung bình của các biến mạng chủ yếu và được phát triển như sau

Cho N luồng TCP được đánh số i=1,….,N đi qua router Gọi Wi(t) và Ri(t) lần lượt

là kích thước cửa sổ TCP và RTT (round trip time) tại thời điểm t ≥ 0 của luồng i Giả sử Ri(t) có dạng