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

BỘ GIÁO DỤC VÀ ĐÀO TẠO TẬP ĐOÀN BCVT VIỆT NAM
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
*********************************************
NGUYỄN HỒNG SƠN
CHUYÊN ĐỀ 2
PHÁT TRIỂN IP QoS THEO CƠ CHẾ
DIFFSERV
CHUYÊN ĐỀ CẤP TIẾN SỸ
Giáo viên hướng dẫn: TS. L Ê H ỮU L ẬP
TS. V Ũ NH Ư L ÂN
HÀ NỘI 4-2008
2
MỤC LỤC
3
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ụ best-
effort.
-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
4
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
5

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.
6
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
7
đá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à
8
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à in-profile hay out-profile. Các gói in-
profile được gán một mức hủy gói (drop precedence) thấp hơn các gói out-profile
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
Classifier Marker Meter
Remarker
Shaper
Dropper
9
Traffic
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
10
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 (low-
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
một xác suất p, trong đó p là 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
11
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
tiên vào cho mỗi VQ
i
. Ưu tiên gồm 16 mức với 1 là mức ưu tiên cao nhất. Như đã
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
là q
ave
, khi q
ave

nhỏ hơn ngưỡng nhỏ nhất thì hàng đợi trong trạng thái không hủy,
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
Filter
VQ
0
RED
Filter
VQ
1
RED
Filter
VQ
2
RED
Filter
VQ
16
RED
GRED
Classifier
12
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
suất. Như vậy giá trị q
ave
là yếu tố chủ yếu định nghĩa động thái của hàng đợi. Với
các ngưỡng trên và dưới đã cho với giá trị q
ave
càng lớn thì xác suất hủy gói càng

lớn. Khi hiện thực GRED cho DiffServ, các tác giả đề xuất định nghĩa ưu tiên
dùng q
ave
như sau. Với hàng đợi có mức ưu tiên 1 thì giá trị q
ave
của nó chính là giá
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ẽ
có giá trị q
ave
bằng giá trị tính toán trên chính nó cộng với giá trị q
ave
của hàng đợi
mức ưu tiên 1, giá trị q
ave
của hàng đợi trên mức ưu tiên 3 bằng giá trị tính toán của
nó công với giá trị q
ave
của mức ưu tiên 2 và cứ thế. Như vậy giá trị q
ave
của một
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ố
hiện thực thực tế, một số nhà thiết kế đã không dùng cách xác định q
ave
cho mỗi
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 W
i
(t) và R
i
(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ử R
i
(t) có dạng
13
( )
( )
Nit

C
tq
atR
ii
, ,1;0, =≥+=
(1)
Trong đó a
i
là thời gian trễ lan truyền và q(t)/C mô hình cho thời gian trễ do xếp
hàng.
Gọi thông lượng tức thời của luồng TCP thứ i tạo thời điểm t≥0 là B
i
(t).
Giả sử tổn thất gói đối với luồng i được biểu diễn bởi quá trình Poisson {N
i
(t)} với
tốc độ biến đổi thời gian là λ
i
(t). Về bản chất của tốc độ biến đổi theo thời gian
λ
i
(t) có thể mô hình một lược đồ đánh dấu độc lập trong AQM. Phương trình vi
phân sau mô tả động thái của kích thước cửa sổ W
i
(t)
( )( )
( )
( )
tdN
tW

tqR
dt
tdW
i
i
i
i
2
)( −=
(2)
Mô hình này mô tả động thái tăng một lần nhưng giảm nhiều lần của cửa sổ TCP.
Tham số đầu tiên tương ứng với phần tăng, kích thước cửa sổ tăng một ứng với
mỗi RTT. Tham số thứ hai tương ứng với phần giảm, kích thước cửa sổ giảm một
nửa vào lúc phát hiện mất gói (dN
i
(t)=1). Mô hình lưu lượng như là một thông số
động B
i
(t) = W
i
(t)/R
i
(t). Lấy trung bình của hai vế của phương trình vi phân trên ta
có
( )
[ ]
( )( )
( ) ( )
[ ]
[ ]

( )
[ ]
( )
dt
tWE
qR
dt
EWdE
tdNtWE
tqR
dt
EtdWE
ii
i
i
ii
i
i
2
2
λ
−






≈
−







=
Phương trình trên là xấp xỉ vì việc tách E[W
i
(t)dN
i
(t)] thành E[W
i
(t)]E[dN
i
(t)] chỉ
khi hai yếu tố là độc lập, trên thực tế hai yếu tố là không độc lập, đặc biệt trên các
lược đồ đánh dấu tỉ lệ. Tuy nhiên, xấp xỉ này không làm thay đổi bản chất tự nhiên
của cơ chế giảm nhiều lần và chúng ta có thể thu được động học của TCP. λ
i
(t) là
chỉ dấu của tổn thất mà nguồn nhận được. Nó tiếp cận nguồn phát xấp xỉ thời gian
một chu trình đi và về RTT (τ) sau khi một gói bị hủy hay bị đánh dấu tại hàng
đợi. Trong [19] một phương trình vi phân ngẫu nhiên chính xác cho TCP có xét
đến trễ do phản hồi đã được nghiên cứu và theo một ngữ cảnh công bằng. Ở đây sẽ
mô hình τ như một lời giải của các phương trình vi phân này
τ
−=
+=
tt

ttqRt
'
''
))((
14
Trong các lược đồ đánh dấu tỉ lệ dùng AQM, việc đánh dấu và hủy gói được thực
hiện theo kiểu phân bố tổn thất theo tỉ lệ cho các luồng cùng chia sẻ băng thông.
Do đó, nếu thông lượng của một luồng là B(t-τ) tại thời điểm t-τ, tốc độ tổn thất
nhận được tại thời điểm t là
)()(
_
ττ
−






− tBtxp
. Ký hiệu giá trị trung bình của nó
bằng
))((/)()(
___
τττ
−−







− tqRtWtxp
ii
.
Trở lại phương trình vi phân mô tả kích thước cửa sổ trung bình ta có
[ ]
[ ]
dttxp
tqR
tWW
qR
dt
WdE
dt
tqR
tW
txp
W
qR
dt
WdE
i
ii
i
i
i
ii
i
i

))((
))((2
)(
)(
))((
)(
))((
2
)(
_
_
__
_
_
_
_
_
_
τ
τ
τ
τ
τ
τ
−
−
−
−=
−
−

−−≈

Xấp xỉ trên được lấy trên cơ sở áp dụng E[f(x)] ≈ f(E[x]). Do đó
))((
))((2
)(
)(
1
_
_
__
_
_
τ
τ
τ
−
−
−
−= txp
tqR
tWW
qR
dt
Wd
i
ii
i
i
(3)

Giả sử rằng ước lượng hàng đợi trung bình là EWMA trên cơ sở lấy mẫu mỗi δ
giây dùng một trọng số α, 0< α <1,
)()()()1())1((
δαδαδ
kqkxkx +−=+
(4)
Chuyển phương trình trên thành phương trình vi phân
)()( tBqtAx
dt
dx
+=
Trong một hệ thống lấy mẫu số liệu, x(t
k+1
) được cho bởi
∫
+
++
−−
+
+=
1
11
)()()(
)()(
1
k
k
kkk
t
t

k
tA
k
ttA
k
tqBdetxetx
τ
τ
(5)
Lưu ý rằng phương trình vi phân phù hợp với hệ thống rời rạc chính xác tại các
điểm lấy mẫu và không có tích lũy lỗi khi tham số k tăng. So sánh các hệ số trong
(4) và (5) ta có
15
δ
α
A
e=−1
hay
( )
BA
e
−=
−
=
δ
α
1log
Do đó ta có phương trình vi phân mô tả động thái của x như sau
)(
)1(log

)(
)1(log
tqtx
dt
dx
ee
δ
α
δ
α
−
−
−
=
Vì đây là phương trình tuyến tính nên lấy trung bình cả hai vế ta được
)(
)1(log
)(
)1(log
__
_
tqtx
dt
xd
ee
δ
α
δ
α
−

−
−
=
(6)
Sau cùng ta có phương trình vi phân mô tả trạng thái của q, đây là phiên bản vi
phân của phương trình Lindley
∑
=
+−=
N
i
i
i
tq
qR
W
C
dt
tdq
1
)(
)(
1
)(
(7)
Trong đó tham số đầu tiên mô hình sự giảm chiều dài hàng đợi khi nó lớn hơn
không (0), do đó đang truyền gói. Tham số thứ hai tương ứng sự gia tăng kích
thước hàng đợi do các gói đến từ N luồng TCP. Một lần nửa, lấy trung bình ta có
[ ]
[ ]

∑
∑
=
=
+−≈






+−=
N
i
i
i
tq
N
i
i
i
tq
qR
W
CE
qR
W
ECE
dt
tqd

1
_
_
)(
1
)(
_
)(
1
)(
1
)(
Với hàng đợi cổ chai, ta luôn có q(t)>0 với xác suất gần bằng 1. Do đó, ta có thể
xấp xỉ E[1
q(t)
] để có
∑
=
+−≈
N
i
i
i
qR
W
C
dt
tqd
1
_

_
_
)(
)(
(8)
Chúng ta có N+2 cặp phương trình (3) (6) và (8) và N+2 chưa biết, (
___
),,
i
Wqx
có thể
giải được, lời giải sẽ cung cấp một ước lượng về động thái nhất thời trung bình của
16
hệ thống. Lấy được chiều dài hàng đợi, ước lượng hàng đợi và kích thước cửa sổ,
các giá trị này được dùng để xác định độ trễ hay tốc độ tổn thất trung bình.
4.3. Tuyến tính hóa phương trình vi phân mô tả động học của luồng TCP
Cặp phương trình mô tả động học của TCP có thể được viết giản lược như sau
))((
))((2
))(()(
)(
1
)( tRtp
tRtR
tRtWtW
tR
tW −
−
−
−=

•
(9)
CtN
tR
tW
tq −=
•
)(
)(
)(
)(
Trong đó ký hiệu
•
x
là đạo hàm của x theo t
W : kích thước cửa sổ trung bình
q : chiều dài hàng đợi trung bình
R : round trip time
C : dung lượng của liên kết
N: số luồng TCP
p : xác suất đánh dấu hay hủy gói
Chiều dài hàng đợi q và kích thước cửa sổ W là dương và có giá trị bị chặn, nghĩa
là
],0[
_
qq ∈
và
],0[
_
WW ∈

trong đó
_
q
và
_
W
ký hiệu dung lượng bộ đệm và kích
thước cửa sổ tối đa. Động học của luồng được mô tả trong sơ đồ khối ở hình 4.
Xấp xỉ động học này bằng tuyến tính hóa tín hiệu nhỏ một điểm hoạt động nhằm
hiểu thấu đáo các mục tiêu của điều khiển phản hồi AQM.

17
Hình 4-Sơ đồ khối cơ cấu điều khiển luồng
Gọi (W,q) là trạng thái và p như là tín hiệu đầu vào, điểm hoạt động (W
0
,q
0
,p
0
)
được định nghĩa bởi
0=
•
W
và
0=
•
q
sao cho
N

CR
Wq
pWW
0
0
0
2
0
0
20
=⇒=
=⇒=
•
•
(10)
Trong đó
p
T
C
q
R +=
0
.
0
Giả sử N(t) ≡ N và R(t) ≡ R
0
là hằng số, tuyến tính hóa (9) về điểm hoạt động ta có
)(
1
)()(

)(
2
))()(()(
00
0
2
2
0
0
2
0
tq
R
tW
R
N
tq
Rtp
N
CR
RtWtW
CR
N
tW
δδδ
δδδδ
−=
−−−+−=
•
•

(11)
Trong đó
R
1
∫
R
1
N
∫
2
1
Trễ
R giây
1
•
W
W
q
q
C
-
_
•
q
R
1
Hàng đợi cổ chai
Điều khiển cửa sổ
Hệ số tải
18

0
.
0
.
0
.
ppp
qqq
WWW
−=
−=
−=
δ
δ
δ
Thực hiện biến đổi Laplace phương trình vi phân, động học được tuyến tính hóa
được mô tả trong sơ đồ khối ở hình 5.
Hình 5-Sơ đồ khối của kết nối TCP được tuyến tính hóa.
Trong [20] một mô hình cho cơ chế điều khiển cửa sổ được phát triển và cho rằng
có chứa một cấu trúc điều chỉnh Smith trong đó. Tuy nhiên, mô hình trong [16] và
hình 5 không hỗ trợ điều này. Thật sự, đối với điều khiển TCP trong hình 5 để tác
động như một cấu trúc bộ điều chỉnh Smith thì tham số
0
2
0
sR
e
CR
N
−

phải là
0
0
2
1
1
2
sR
e
R
s
N
C
−
+
−
.
Nhận xét rằng tham số
0
sR
e
−
trong hình 5 sẽ không có ý nghĩa khi
0
2
0
1
R
CR
N

〈〈
và vì
00
2
0
1
RW
CR
N
=
nên có thể bỏ qua tham số này nếu W
0
>>1. Trong
các điều kiện bình thường của mạng W
0
>>1 nên có thể bỏ qua tham số này và
xem xét động học đơn giản sau
s
1
)1(
0
2
0
sR
e
CR
N
−
+
0

R
N
0
1
1
R
s
+
0
2
2
0
2
sR
e
N
CR
−
W
δ
q
δ
δp
-
-
Động học
hàng đợi
Điều khiển
cửa sổ
19

)(
1
)()(
)(
2
)(
2
)(
00
0
2
2
0
2
0
tq
R
tW
R
N
tq
Rtp
N
CR
tW
CR
N
tW
δδδ
δδδ

−=
−−−=
•
•
(12)
như mô tả trong hình 6
Hình 6-Sơ đồ khối của kết nối TCP được tuyến tính khi W
0
>>1.
4.4. Ảnh hưởng của điều khiển AQM vào động học của luồng TCP
Dùng mô hình được tuyến tính hóa (12), một hệ thống điều khiển AQM có thể
được mô hình như trong sơ đồ khối ở hình 8. Trong sơ đồ này Ptcp ký hiệu hàm
truyền từ xác suất tổn thất δp đến kích thước cửa sổ δW và P
queue
liên hệ δW với
chiều dài hàng đợi q. Tham số
0
sR
e
−
là biến đổi Laplace của thời gian trễ tại xác
suất tổn thất đã trễ δp(t-R
0
). Trong ngôn ngữ điều khiển, xem khối điều khiển theo
luật AQM như là bộ điều khiển hay bộ bù và phần còn lại của hệ thống là “plant”.
Mục tiêu của việc thiết kế bộ bù là để đảm bảo hệ thống vòng kín ổn định. Tuy
nhiên, còn vài điều khác nữa cũng ảnh hưởng thiết kế điều khiển. Thứ nhất, hệ
thống phải có một đáp ứng ngắn hạn có thể chấp nhận được. Điều thứ hai là việc
thiết kế bộ bù phải bền vững đối với các thay đổi của các tham số và lỗi mô
phỏng. Do đó, nhiệm vụ của người thiết kế là thiết kế các hệ thống có biên an

toàn. Biên an toàn này được gọi là biên ổn định. Có hai đại lượng cổ điển để đo
lường tính ổn định này. Thứ nhất là biên độ lợi (gain margin), là hệ số mà độ lợi
vòng hở của một hệ thống ổn định thay đổi thì hệ thống không ổn định. Nếu quan
sát hình 4 thì biên độ lợi là sự không chắc chắn về tổng số luồng N mà thiết kế có
thể chịu được. Thứ hai là biên pha (phase margin). Định nghĩa của biên pha hơi
phức tạp, nhưng trong ngữ cảnh của AQM có thể xem biên pha như là mức độ
không chắc chắn của trễ hành trình (round trip delay) mà thiết kế có thể chịu để
CR
N
s
N
CR
2
0
2
2
0
2
2
+
0
0
1
R
s
R
N
+
0
sR

e
−
δW δq
δp
-
Động học
hàng đợi
Điều khiển
cửa sổ
20
giữ cho hệ thống không bị mất ổn định. Các biên ổn định của hệ thống có thể suy
ra dễ dàng từ các biểu đồ Bode. Biểu đồ Bode là biểu đồ đáp ứng tần số của hệ
thống được vẽ theo thang đo logarith. Biên độ lợi của hệ thống là bằng đáp ứng
biên độ của hệ thống tại điểm mà đáp ứng pha là -180
0
. Biên pha φ
m
được định
nghĩa như là ω
pm
-180, trong đó ω
pm
là đáp ứng pha tại tần số mà đáp ứng biên độ là
đơn vị (hay 0dB). Hai đại lượng được trình bày trên hình 7. Về trực giác, nếu
không có các biên dương thì hệ thống điều khiển phản hồi bắt đầu có động thái
của một hệ thống phản hồi dương, nghĩa là các lỗi sẽ bị khuếch đại trong vòng và
dẫn đến sự phân cực và mất ổn định.
Hình 7- Các biên ổn định trên biểu đồ Bode.
Động học của plant
Trong hình 8 là một mô tả hê thống điều khiển phản hồi AQM. Hành động của

luật điều khiển AQM là để đánh dấu các gói (với xác suất p) theo một hàm số của
chiều dài hàng đợi q.
21
Hình 8- AQM như một cơ cấu điều khiển có phản hồi.
Từ hình 8, hàm truyền của plant P(s)=P
tcp
(s)P
queue
(s) có thể được biểu diễn qua các
tham số mạng sau:
0
0
2
0
2
2
0
1
)(
;
2
2
)(
R
s
R
N
sP
CR
N

s
N
CR
sP
queue
tcp
+
=
+
=
(13)
Xem hai cực -2N/(R
0
2
C) và -1/R
0
lần lượt là p
tcp
và p
queue
. Động học plant được ký
hiệu bởi hàm truyền P(s) liên quan đến xác suất đánh dấu gói ảnh hưởng thế nào
đến chiều dài hàng đợi. Từ (12) và hình 6 ta có









+








+








=
−
0
2
0
2
12
2
)(
0
R

s
CR
N
s
e
N
C
sP
sR
(14)
Độ lợi của plant trong hàm truyền là
N
C
2
2
. Sự thay đổi độ lợi này theo hàm số của
số luồng N sẽ ảnh hưởng đến độ ổn định của hệ thống. Thật vậy, N tăng một lượng
nhỏ độ lợi tần số cao làm giảm biên ổn định và gia tăng đáp ứng dao động. Kết
quả là tải TCP càng lớn sẽ có khuynh hướng kèm hãm đáp ứng ngắn hạn của vòng
kín.
AQM ổn định về khía cạnh trễ R
0
có thể đặt ra một giới hạn cứng lên băng thông
điều khiển vòng kín và hệ quả là lên tốc độ đáp ứng ngắn hạn. Thật vậy, để có ổn
định các hằng số thời gian bị giới hạn khoảng R
0
/2 giây.
AQM
control law
0

sR
e
−
)(sP
tcp
)(sP
queue
p
δ
W
δ
q
δ
22
Áp dụng vào RED
Hình 9- Sơ đồ khối của hệ thống điều khiển AQM được tuyến tính hóa.
Một hệ thống AQM có thể được mô phỏng như hệ thống điều khiển vòng kín trên
hình 9. Ở đây
0
)(
sR
esP
−
ký hiệu động học hàng đợi TCP được tuyến tính hóa theo
tín hiệu nhỏ. P(s) là P
tcp
(s)P
queue
(s). δp và δq lần lượt ký hiệu sự dao động của xác
suất tổn thất và chiều dài hàng đợi. Trong hình 9 hàm truyền C(s) ký hiệu một

chiến lược điều khiển AQM như RED. Cắt đuôi (tail-drop) là một chiến lược điều
khiển đóng ngắt (on-off) với lượng hủy
{ }
1,0∈p
δ
, theo lý thuyết điều khiển xem
đó như cơ chế đóng ngắt gây ra dao động với biểu hiện phức tạp và động thái hổn
độn như đề cập trong [21]. Các dao động như vậy là điều không mong muốn trong
quản lý hàng đợi và RED được đưa ra để ổn định chúng.
Mô hình hàm truyền cho RED là:
1
)()(
+
==
K
s
L
sCsC
red
red
(15)
Trong đó
δ
α
)1(log
;
minmax
max
−
=

−
=
e
thth
red
K
p
L
α>0 là tham số trung bình hàng đợi và δ là thời gian lấy mẫu [18]. Trong thiết kế
C
red
(s) để ổn định hệ thống điều khiển AQM, các biến động của số luồng N và trễ
R
0
phải được tính đến. Các biến động trong R
0
là do trễ lan truyền T
p
với
p
T
C
q
R +=
0
0
Giả sử số lượng luồng TCP trong dải
−
≥ NN
và thời gian trễ

+
≤ RR
0
, mục tiêu là
chọn các tham số L
red
và K sao cho hệ thống điều khiển vòng kín ổn định với tất cả
các giá trị của N và R
0
trong dải đã cho. Hệ thống trong hình 9 là ổn định nếu các
giá trị đầu vào bị chặn chỉ tạo ra các giá trị đầu ra cũng bị chặn. Điều này ngụ ý
C(s)
0
)(
sR
esP
−
p
δ
q
δ
-
23
rằng các đáp ứng đối với điều kiện ban đầu sẽ bị giới hạn và hội tụ về 0 theo hàm
mũ. Kết quả nghiên cứu trong [22] cho thấy hệ thống điều khiển tuyến tính có
phản hồi trong hình 9 là ổn định đối với tất cả các
−
≥ NN
và
+

≤ RR
0
nếu L
red
và K
thỏa
1
)2(
)(
2
2
2
3
+≤
−
+
KN
CRL
g
red
ω
(16)
Trong đó
( )











=
+
+
−
R
CR
N
g
1
,
2
min1.0
2
ω
(17)
5. Kết luận về hiện thực DiffServ
Xu thế triển khai IP QoS hiện nay đều dùng giải pháp DiffServ, hầu hết các triển
khai trên thực tế đều bám sát vào kiến trúc này. Mỗi nhà cung cấp dịch vụ hay nhà
sản xuất thiết bị có chọn lựa kỹ thuật phát triển khác nhau nhưng vẫn có những
điểm chung cơ bản. Trong đó tại router biên thường dùng các token bucket để thực
hiện các chức năng khác nhau của bộ điều chỉnh lưu lượng theo mô hình DiffServ.
Trong tất cả các router, thuật toán RED được dùng làm cơ chế quản lý hàng đợi và
để hình thành các PHB, đặc biệt là các lớp con trong AF PHB. RED được dùng
với kỳ vọng là cung cấp một cơ chế tránh nghẽn tốt, đồng thời loại bỏ được nhược
điểm đồng bộ của các cơ chế quản lý hàng đợi theo kiểu cắt đuôi (tail drop) nhờ
khả năng hủy gói theo xác suất. Tuy nhiên, việc xác định tham số cho RED trở nên

thiếu thực tế vì gần như rất khó chọn được các tham số RED mà chất lượng mạng
không bị ảnh hưởng xấu. Theo các phân tích cho thấy để hệ thống dùng RED ổn
định cần phải chọn tham số hoạt động cho RED theo các tiêu chí nhất định và
trong một phạm vi xác định của các yếu tố khách quan như cự ly truyền. Điều này
không phải lúc nào cũng dễ dàng trên mạng thực tế khi mà nhu cầu kết nối cũng
như lưu lượng luôn biến động. DiffServ vẫn đang cần có các giải pháp thực tế hơn
để việc triển khai được dễ dàng và họat động bền vững hơn.
24
Tài liệu tham khảo
[1]. K. Nichols et al., “Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers,” RFC 2474, Dec. 1998.
[2]. K. Nichols, V. Jacobson, and L. Zhang, “A Two-Bit Differentiated
Services Architecture for the Internet,” Internet draft, draft-nichols-diff-
svc-arch-00.txt, Nov. 1997
[3]. J. Heinanen et al., “Assured Forwarding PHB Group,” Internet draft,
draftietf- diffserv-af-03.txt, Nov. 1998
[4]. Ferguson and G. Huston, Quality of Service, Wiley, 1998.
[5]. B.Braden et al., “Recommendation on Queue Management and
Congestion Avoidance in the Internet,” RFC 2309, Apr. 1998
[6]. T. Li, “CPE based VPNs using MPLS,” Internet draft, draft-li-MPLS-
vpn- 00.txt, Oct. 1998.
[7]. H. Zhang, “Service Disciplines for Guaranteed Performance Service in
Packet-Switching Networks,” Proc. IEEE, vol. 83, no. 10, Oct. 1995
[8]. W. Yeong, T. Howes, and S. Kille, “Lightweight Directory Access
Protocol,” RFC 1777, Mar. 19958W. Yeong, T. Howes, and S. Kille,
“Lightweight Directory Access Protocol,” RFC 1777, Mar. 1995
[9]. M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies, “An
Architecture for Differentiated Services”, RFC 2475, December 1998
[10]. Kevin Wallace, “Cisco IP Telephony Flash Cards: Weighted Random
Early Detection (WRED)”, Cisco Press, Nov 24, 2004.

/>[11]. A. Dobreff, “Comparison of Simulation and Real Functionality for the
Mapping of Differentiated Services to ATM”, Diploma of the Faculty of
Philosophy and Science of Nature University Bern, Switzerland, 1999
[12]. Sally Floyd and Van Jacobson,"Random Early Detection Gateways for
Congestion Avoidance". August 1993 IEEE/ACM Transactions on
Networking
[13]. Werner Almesberger, Jamal Hadi Salim, Alexey Kuznetsov,
"Differentiated Services on Linux". June 1999
[14]. B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S.
Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K.
Ramakrishnan, S. Shenker, J. Wroclawski, and L. Zhang,
“Recommendations on queue management and congestion avoidance in
the internet,” RFC 2309, April 1998
25