- 1 -

TẬP ĐOÀN BƯU CHÍNH VIỄN THÔNG

VIỆT NAM

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH

VIỄN THÔNG

NGUYỄN HỒNG SƠN

Nghiên cứu cải thiện DIFFSERV QoS trong

mạng IP

Tóm tắt Luận án TS Kỹ thuật: Kỹ thuật Viễn

thông

Mã số chuyên ngành 62 52 70.05

Người hướng dẫn: PGS.TS Lê Hữu Lập, TS Vũ

Như Lân

Hà Nội, 2010

- 2 -

A. MỞ ĐẦU

Ngày nay, mạng IP có vai trò thiết yếu trong lĩnh

vực truyền thông. Sự phát triển nhanh chóng của
Internet đã làm cho mạng IP trở thành giao thức

không thể thiếu và ngày càng quan trọng hơn. Trong
khi đó, các nhu cầu về dịch vụ không còn đơn điệu
như trước và trên thực tế các ứng dụng đòi hỏi QoS

xuất hiện ngày càng nhiều. Bối cảnh này đã đặt ra cho

mạng IP nhiều thách thức mới, đòi hỏi mạng IP phải
có các cơ chế QoS hoàn chỉnh để đáp ứng nhu cầu đa

dịch vụ đang gia tăng.

Trong cố gắng đầu tiên tăng cường khả năng QoS

cho mạng IP, tổ chức IETF đã đưa ra cơ chế
Integrated Services (IntServ). Nhưng IntServ sớm tỏ

ra phức tạp, không có tính khả triển (scalability) nên

Differentiated Services (DiffServ) được IETF đề xuất
như là cơ chế thay thế IntServ. Về lý thuyết DiffServ

là kiến trúc QoS quan trọng cho mạng IP, là cơ sở

QoS trong IPv6 và có khả năng phối hợp với MPLS

- 35 -

khiển chấp nhận nối gần giống như môi trường mạng

theo chế độ có kết nối.

- 34 -

0,03 trong khi chạy DiffServ không dùng CAC

với cùng điều kiện tải có xác suất mất gói trung

bình khoảng 0,35 (chỉ mô phỏng độc lập tại tầng
mạng, không kết hợp cơ chế hỗ trợ ở tầng giao

vận như cơ chế điều khiển cửa sổ của TCP). Hiệu

suất sử dụng liên kết cũng khá cao, đạt 90% với

xác suất mất gói xấp xỉ 10

-4

.

2. Kiến nghị hướng phát triển

Vấn đề thực hiện QoS cho mạng IP là bài toán lớn,

đòi hỏi sự phối hợp giải quyết từ nhiều giải pháp khác

nhau. Hai giải pháp được đề xuất ở đây cần được tiếp

tục nghiên cứu phát triển.

Đối với giải pháp thực hiện AFij dựa vào CQM

cần nghiên cứu thiết kế module điều khiển thích hợp,

chú trọng thời gian tác động của bộ điều khiển nếu

thực hiện bằng phần cứng theo lý thuyết điều khiển

truyền thống. Nếu thực hiện bằng phần mềm cần đánh
giá độ phức tạp của thuật toán CQM bao hàm thuật
toán token bucket động.

Đối với giải pháp điều khiển chấp nhận kết nối thì

trước hết cần tiếp tục nghiên cứu mở rộng cho trường

hợp liên domain. Kế đến là lý thuyết hóa đăng ký và

giải phóng tài nguyên không tường minh trong mạng

theo chế độ connectionless, từ đó xây dựng mô hình
định lượng hợp lý làm cơ sở áp dụng các thủ tục điều

- 3 -

tạo ra cơ chế QoS mạnh. Tuy nhiên, trên thực tế các

triển khai DiffServ vẫn chưa đầy đủ các lớp dịch vụ
như đặc tả, từ đó việc cung cấp QoS trên mạng IP
chưa được phổ biến, phần lớn các phiên truyền thông

hiện nay đều phải chạy với mức best-effort. Thiết nghĩ

cải thiện IP QoS trước hết phải cải thiện DiffServ, vì

vậy cần phải tìm ra nguyên nhân khiến DiffServ có

những yếu kém thực tế và đề ra giải pháp để khắc

phục.

Có nhiều nguyên nhân, ở đây có thể nêu ra hai

nguyên nhân nổi trội. Nguyên nhân thứ nhất thuộc về
phương pháp hiện thực DiffServ hiện nay; theo gợi ý

của IETF, tất cả các hiện thực DiffServ đều dùng thuật

toán quản lý hàng đợi tích cực RED để tạo các lớp

dịch vụ khác biệt, nhưng các nghiên cứu cho thấy
cách dùng RED có khó khăn. Bản thân RED không

phải là cơ chế điều khiển nghẽn chính quy, không hỗ

trợ chia sẻ tài nguyên và đặc biệt rất khó chọn lựa các

tham số hoạt động cho nó mà không ảnh hưởng xấu
đến phẩm chất của mạng. Nguyên nhân thứ hai là

DiffServ của IETF không cung cấp cơ chế end-to-end
QoS và không có phương pháp điều khiển các lớp

QoS giữa các nhà điều hành mạng khác nhau. Thực tế,
ứng dụng của người dùng không có cách gì để yêu cầu

một lớp dịch vụ đặc biệt vì không có điều khiển chấp

nhận kết nối (Connection Admission Control). Thiếu

- 4 -

điều khiển chấp nhận nối sẽ khó ngăn chặn tình trạng

quá tải khiến cho khả năng cung cấp QoS không đảm

bảo.

Từ khảo sát phân tích trên đây, Nghiên cứu sinh

nhận thức rằng DiffServ là cơ chế QoS quan trọng
hàng đầu của mạng IP nên mục đích, đối tượng và
phạm vi nghiên cứu trong luận án như sau:

Mục đích nghiên cứu

Làm sáng tỏ hiện trạng và xu thế của IP QoS.

Tìm nguyên nhân của các hạn chế về thực hiện IP

QoS theo kiến trúc DiffServ hiện nay. Đề xuất giải

pháp nhằm cải thiện DiffServ trên phương diện thực

hiện và cơ chế hoạt động, với hai mục tiêu chủ yếu là :
Đề xuất giải pháp thuận lợi hiệu quả để thực hiện các

lớp dịch vụ con AFij và đề xuất cơ chế điều khiển

chấp nhận kết nối (CAC) cho DiffServ domain.
Đối tượng và phạm vi nghiên cứu

Nghiên cứu kiến trúc DiffServ QoS và DiffServ

domain. Tập trung vào hướng triển khai DiffServ

domain, thực hiện các lớp dịch vụ tại các DiffServ

router và cơ chế đảm bảo end-to-end QoS.
Phương pháp nghiên cứu

Với định hướng nghiên cứu ứng dụng, công việc

thực hiện luận án bước đầu gồm thu thập tài liệu, thực

nghiệm trên các thiết bị và hệ thống. Kế tiếp là khảo

sát các giải pháp thực hiện DiffServ trên thực tế,

- 33 -

Kết quả là hàng đợi được duy trì với độ dài ổn
định, bộ đệm không bị tràn. Có thể thay đổi độ dài
ổn định của hàng đợi bằng cách thay đổi giá trị

tham chiếu q

ref

của bộ điều khiển. Muốn sử dụng

hết kích thước bộ đệm chỉ cần điều chỉnh q

ref

.

2. Áp dụng cơ chế quản lý hàng đợi CQM thực hiện

các lớp dịch vụ AF (AF

ij

) cho mạng DiffServ.

Trong đó, cấu hình giá trị tham chiếu qref khác

nhau cho các bộ điều khiển khác nhau để tạo ra

các lớp dịch vụ khác biệt AF

ij

trong mỗi DiffServ

router. Kết quả là tạo ra được các dịch vụ khác

biệt một cách dễ dàng như dự kiến, điều chỉnh
được một cách linh động. Bộ đệm ngõ ra được sử
dụng với một mức ổn định theo cấu hình, không
xảy ra hiện tượng nghẽn. Tài nguyên được sử
dụng hiệu quả vì khi một lớp dịch vụ ở trạng thái

không tải, tài nguyên đang giữ bị thu hồi để cấp

cho lớp dịch vụ khác đang cần.

3. Đề xuất giải pháp CAC theo hướng phân tán cho

DiffServ domain, gồm tập tiêu chuẩn quyết định
cục bộ có bổ sung ràng buộc trên số luồng nhằm

khắc phục mâu thuẩn cơ bản giữa đặc tính kết nối

và không kết nối, và cơ chế báo hiệu kết nối

không tường minh phù hợp với tiêu chuẩn quyết
định cục bộ này để cộng tác thực thi thủ tục CAC.

Kết quả là xác suất mất gói thấp, chỉ khoảng dưới

- 32 -

Hình 3.25 Đồ thị tương quan giữa xác suất mất gói

và hiệu suất.

Bảng 3.4 Các tham số của nguồn 2 (Expo2)

Tham số

Giá trị

Packet size 125 bytes

Burst time

400 ms

Idle time

325 ms

Data rate

64 kbps

C. KẾT LUẬN VÀ KIẾN NGHỊ

1. Kết luận

Luận án “Nghiên cứu cải thiện DiffServ QoS trong

mạng IP” có các kết quả :

1. Đề xuất cơ chế quản lý hàng đợi CQM, trong đó

lấy token bucket kết hợp với bộ điều khiển làm cơ

chế điều khiển cục bộ tại router, điều khiển lưu
lượng đổ vào bộ đệm theo nguyên lý phản hồi.

- 5 -

nghiên cứu các đề xuất cải tiến điển hình. Trên cơ sở
đó xây dựng các giải pháp mới dùng công cụ toán học

và mô phỏng máy tính để kiểm chứng, đúc kết nguyên

lý áp dụng và tham gia hội thảo.

Kết quả chính của luận án :

+ Đã làm rõ hiện trạng và xu thế cũng như cách

thức thực hiện một hạ tầng QoS cho mạng IP theo

kiến trúc DiffServ. Thiết nghĩ, trong điều kiện công

nghệ chế tạo thiết bị mạng của nước ta còn chưa phát

triển thì việc tìm hiểu để nắm bắt cách thức thực hiện

các giải pháp cụ thể trên thiết bị là bước tiếp cận ban
đầu hợp lý.

+ Đã đưa ra giải pháp thực hiện DiffServ mới.

Trong đó, đã thiết kế cơ chế quản lý hàng đợi CQM

dùng token bucket kết hợp với bộ điều khiển. Vận

dụng CQM thực hiện được các lớp dịch vụ trong AF

PHB một cách dễ dàng cùng với khả năng kiểm soát

nghẽn chính qui hơn so với cơ chế dùng thuật toán

RED, cách thực hiện này cũng tạo điều kiện để các

lớp dịch vụ chia sẻ tài nguyên với nhau.

+ Đã phát triển phương pháp điều khiển chấp

nhận kết nối cho DiffServ domain. Trong đó, đề xuất

ý tưởng báo hiệu không tường minh, xây dựng tiêu

chuẩn quyết định đặc trưng làm nền tảng. Cơ chế điều

khiển chấp nhận kết nối mới vẫn đảm bảo được tính

khả triển (scalability) vốn có của mạng DiffServ và

- 6 -

tạo triển vọng cung cấp end-to-end QoS cho mạng

DiffServ một cách đơn giản.

Luận án gồm 129 trang có bố cục như sau:

Mở đầu : 8 trang

Chương 1- Tổng quan IP QoS : 11 trang

Chương 2- Các giải pháp chính cho QoS trong

mạng IP hiện nay

và những hạn chế : 26

trang

Chương 3- Đề xuất các giải pháp nhằm cải thiện

QoS cho mạng

IP theo kiến trúc

DiffServ: 54 trang

3.1 Cơ sở nghiên cứu và các mục tiêu chính : 2

trang

3.2 Giải pháp thực hiện AFij cho mạng

DiffServ : 31 trang

3.3 Giải pháp điều khiển chấp nhận kết nối cho

mạng DiffServ

: 20 trang

3.4 Kết luận : 1 trang

Kết luận và kiến nghị hướng phát triển : 3 trang

Danh mục các công trình của tác giả : 2 trang

Tài liệu tham khảo : 99 tài liệu tham khảo (11

trang)

Luận án có 33 hình và 04 bảng

B. NỘI DUNG

Chương 1 - Tổng quan IP QoS

1.1 Giới thiệu IP QoS

- 31 -

s

0.5e-6, 0.6e-6, 0.7e-6, 0.8e-6, 0.9e-6, 1e-

6,1.1e-6, 1.2e-6, 1.3e-6, 1.4e-6, 1.5e-6,

1.6e-6, 1.7e-6, 1.8e-7

Mô phỏng được thực hiện đầu tiên với nguồn 1

(Expo1) với tham số s được thay đổi như trong bảng

3.2. Mô phỏng lại được thực hiện tiếp tục với nguồn 2

(Expo2) với tham số được mô tả trong bảng 3.3. Kết

quả mô phỏng được trình bày trên hình 3.25. Trong
trường hợp của nguồn 1, ta thấy rằng hiệu suất sử

dụng liên kết đạt xấp xỉ 90% ứng với xác suất mất gói

rất thấp. Khi hiệu suất đạt xấp xỉ 95% thì xác suất mất

gói cũng chỉ khoảng 8,2.10

-4

. Điều này cho thấy việc

sử dụng giải pháp CAC đã cải thiện được chất lượng

dịch vụ qua giảm xác suất mất gói mà vẫn đảm bảo
được hiệu suất sử dụng liên kết ở mức cao.

So sánh kết quả giữa nguồn 1 và nguồn 2 thấy rằng

sự khác biệt tỉ lệ giữa burst time và idle time cũng ảnh
hưởng đến chất lượng phục vụ, cụ thể là khi tỉ lệ burst

time lớn sẽ dẫn đến xác suất mất gói lớn hơn. Qua kết

quả mô phỏng cũng chứng tỏ rằng tham số s thực sự
đóng vai trò điều khiển nhằm tối ưu giữa hai tham số

xác suất mất gói và hiệu suất sử dụng liên kết cho một

nguồn xác định.

- 30 -

đầu

30

35.10

-3

35.10

-3

60

65.10

-3

65.10

-3

90

95.10

-3

95.10

-3

120

12,5.10

-

3

12,5.10

-

3

150

15,5.10

-

3

15,5.10

-

3

180

16,9.10

-

3

18,5.10

-

3

210

74,4.10

-

3

21,5.10

-

3

240

17.4.10

-

2

24,5.10

-

3

270

25,2.10

-

2

27,5.10

-

3

300

32,8.10

-

2

1.10

-4

330

35,4.10

-

2

4,9.10

-4

360

38,7.10

-

2

36,5.10

-

3

390

39,4.10

-

2

10,3.10

-

4

420

40,9.10

-

2

42,5.10

-

3

3.3.6.2 Đánh giá xác suất mất gói và hiệu suất sử

dụng liên kết qua mô phỏng với các nguồn lưu
lượng khác nhau

Bảng 3.3 Các giá trị của s

Tham

số

Các giá trị

- 7 -

Ngày nay IP là nền tảng cho mạng hội tụ đa dịch

vụ. Chủ đề QoS trong mạng IP được quan tâm nghiên

cứu dưới tên gọi IP QoS. Có bốn tham số đo lường

chính của IP QoS là thông lượng (throughput), độ trễ

(end-to-end delay), độ biến động trễ (jitter) và độ tổn

thất gói (packet loss).

1.2. Phương thức cơ bản cung ứng QoS trong

mạng IP

Ba phương thức cơ bản thường dùng để hỗ trợ QoS

trong mạng IP, đó là cung ứng có dự phòng cho mạng,

xếp hàng và phân loại.

1.3. Cơ chế kiểm soát chất lượng mạng phổ biến

cho mạng IP

Ba nhóm cơ chế chính nhằm đạt được một chất

lượng mạng tốt hơn mức “Best Effort” truyền thống

trên mạng IP, đó là:

- Cung cấp dung lượng vượt yêu cầu

- Đăng ký trước tài nguyên: tiêu

biểu là Intserv

- Ưu tiên hóa các dịch vụ và người dùng: tiêu biểu

là DiffServ

Chương 2 -Các giải pháp chính cho QoS trong

mạng IP hiện nay và những hạn chế

2.1 Phát triển IP QoS theo cơ chế DiffServ

DiffServ là một tập hợp công nghệ cho phép nhà

cung cấp dịch vụ mạng đưa ra các dịch vụ mạng khác

- 8 -

nhau cho khách hàng cũng như cho các dòng lưu
lượng mạng của họ. Kiến trúc DiffServ chứa hai thành

phần chính. Một là nguyên tắc ứng xử công bằng phổ

quát trên từng bước gọi là PHB (per hop behaviors) và

thứ hai là chính sách cấu hình các thông số trên đường

dẫn chuyển gói cho từng PHB. Hiện có hai PHB được
định nghĩa là EF (Expedited Forwarding), AF

(Assured Forwarding).

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 (core router).

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. Trong đó,

nguyên lý quản lý hàng đợi tích cực RED (Random
Early Detection) được dùng để quản lý hàng đợi cho

DiffServ.

Vì RED có thể hủy gói một cách ngẫu nhiên theo

thông số xác suất qua thao tác cấu hình, nên có thể
được dùng để thực hiện động thái AF (Assure

Forwarding behavior) trong DiffServ.

Theo các nghiên cứu 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.

- 29 -

Bảng 3.1 Các tham số của nguồn 1 (Expo1)

Tham số

Giá trị

Packet size 125 bytes

Burst time

200 ms

Idle time

200 ms

Data rate

64 kbps

Kết quả mô phỏng xác định xác suất mất gói

(packet loss probability) trong trường hợp không có
điều khiển chấp nhận kết nối được mô tả trong hình

3.23 và hình 3.24 mô tả xác suất mất gói khi có thủ

tục CAC tham gia. Cụ thể hơn, bảng 3.2 đưa ra số liệu

so sánh xác suất mất gói giữa hai trường hợp. Từ kết

quả cho thấy, khi có cơ chế điều khiển chấp nhận kết

nối, xác suất mất gói giảm đi rất nhiều so với trường

hợp chạy DiffServ nguyên bản không CAC.

Hình 3.23 Xác suất mất
gói trong trường hợp
không dùng giải pháp
CAC.

Hình 3.24 Xác suất mất
gói trong trường hợp có
dùng cơ chế CAC được
đề nghị.

Bảng 3.2 Bảng so sánh xác suất mất gói giữa hai

trường hợp không dùng CAC và dùng CAC

Thời điểm tính

toán T (s), tính từ

thời điểm ban

Xác suất mất gói

khi không dùng

CAC

Xác suất mất

gói khi dùng

CAC

- 28 -

3.3.5 Hoạt động điều khiển chấp nhận kết nối theo
phương pháp được đề xuất

Mỗi user với cấp dịch vụ đã thỏa thuận trước với

ISP trong hợp đồng lưu lượng (SLA), dùng thủ tục

báo hiệu gửi yêu cầu tạo kết nối không tường minh

với đối tác. Kết nối không tường minh chỉ được chấp

nhận khi tất cả các router liên quan đều thỏa điều kiện

CAC. Các router sẽ áp dụng tiêu chuẩn quyết định đã
được xây dựng để thực hiện thủ tục CAC cục bộ trên

từng lớp dịch vụ.

3.3.6 Kết quả của giải pháp được đề xuất

Hình 3.22

Sơ đồ mạng thực hiện mô phỏng.

Sơ đồ mạng mô phỏng như hình 3.22. Chương

trình được viết bằng ngôn ngữ OTcl và C++ được biên

dịch bằng gcc trong NS-2 phiên bản 2.29.

3.3.6.1 Kết quả mô phỏng và so sánh với hệ thống

hiện hữu

Dùng mô hình nguồn đóng-ngắt (ON-OFF) với

thời gian đóng ngắt tuân theo phân bố mũ như mô tả

trong bảng 3.1.

Đích

Nguồn

Ingress router

Core router

10Mbps

10Mbps

Egress router

- 9 -

Đ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. Đây cũng là lý do vì sao các triển khai

DiffServ hiện nay vẫn chưa thực hiện một cách đầy đủ

các dịch vụ như trong đặc tả. 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à hoạt động bền vững hơn.

2.3 Vấn đề quản lý đăng ký tài nguyên trong mạng

DiffServ

Kiến trúc DiffServ không đảm bảo một QoS từ đầu

cuối đến đầu cuối (end-to-end QoS) vì không có cơ

chế quản lý đăng ký tài nguyên. Trong nỗ lực cải thiện

sự yếu kém này, có nhiều đề xuất bổ sung cơ chế kiểm
soát đăng ký tài nguyên cho DiffServ hay còn gọi là
điều khiển chấp nhận các yêu cầu QoS từ người dùng.

Các giải pháp được đề nghị cho đến nay thể hiện

thành hai nhóm: tập trung và phân tán. Trong đó, giải

pháp tập trung đưa ra khái niệm Bandwidth Broker,

tuy nhiên giải pháp này vấp phải khuyết điểm là tạo ra

một điểm lỗi nhạy cảm cho toàn bộ hệ thống.

Giải pháp RMD, PBAC, GRIP và PCN mang tính

tiêu biểu cho các giải pháp điều khiển chấp nhận phân

tán. Tuy nhiên, các giải pháp này vẫn còn tồn tại các

hạn chế cần phải vượt qua để trở thành hiện thực. Bổ
sung cơ chế điều khiển chấp nhận cho DiffServ là điều

- 10 -

hiển nhiên và hết sức cấp thiết nhằm đạt được một giải

pháp QoS hoàn chỉnh cho mạng IP.

2.4 Phát triển IP QoS trên nền MPLS

MPLS giải quyết vấn đề QoS cho mạng IP bằng

cách thiết lập các đường dẫn tường minh qua mạng.
Các đường dẫn được gọi là LSP (Label Switching

Path) cung cấp một phương tiện để đảm bảo một chất
lượng dịch vụ đặc biệt. Để hỗ trợ DiffServ, có thể linh

hoạt ánh xạ các BA (Behavior Aggregate) vào các
đường dẫn LSP sao cho phù hợp nhất.

Chương 3 - Đề xuất các giải pháp nhằm cải thiện

QoS cho mạng IP theo kiến trúc DiffServ

3.1 Cơ sở nghiên cứu và các mục tiêu chính

Dựa vào mô hình toán học và mô phỏng máy tính

để nghiên cứu đề xuất giải pháp thực hiện AFij mà
không dùng RED và đề xuất giải pháp điều khiển chấp

nhận nối cho mạng DiffServ tránh các hạn chế của hai

giải pháp tiêu biểu như RMD, PBAC, GRIP và PCN.

3.2 Giải pháp thực hiện AFij cho mạng DiffServ

3.2.1 Giới thiệu đề xuất

Theo đặc tả kiến trúc DiffServ thì AF PHB phức

tạp hơn EF PHB, AF PHB có đến bốn lớp con và

trong mỗi lớp con lại được chia ra thành ba mức ưu
tiên, như vậy AF PHB có 12 mức dịch vụ, ở đây tạm

gọi là các AFij trong đó i

Î[0,3] và jÎ[0,2], việc thực

hiện các AFij này vẫn còn hạn chế và phụ thuộc nhiều

- 27 -

các router như sau: (các chi tiết được trình bày bên

trong cuốn luận án)

(

)

ï

ï

ï

î

ï

ï

ï

í

ì

m

£

÷

ø

ö

ç

è

æ +

×

×

-

m

£

+

m

^

sp

m

sp

r

S

e

r

e

1

2

1

1

n

(s>0)

(3.30)

Trong đó:

n là số luồng được chấp nhận

µ là dung lượng đầu ra được gán cho lớp tương

ứng tại router

ż là tải hiện hành ước lượng được

r

m

là tốc độ trung bình của nguồn lưu lượng yêu

cầu đăng ký

p là tốc độ đỉnh

s là tham số điều khiển, s

qui định giới hạn băng

thông được dùng hay (ŝ + r)

max

=

n

.

m

Như đã nói trong mục đích thiết kế ban đầu, mỗi

router sẽ giữ một tham số n để chỉ ra số luồng đã được

chấp nhận, một luồng mới với tốc độ yêu cầu r

m

được

chấp nhận nếu n và r

m

thỏa mãn đồng thời hệ bất đẳng

thức trên. Tham số s đóng vai trò là tham số điều

khiển trong cơ chế điều khiển chấp nhận kết nối và

được xác định tùy vào hệ số

n

.

- 26 -

dấu, egress router sẽ gửi thông báo không chấp nhận

cho ingress router (hình 3.21) .

Hình 3.21 Thủ tục báo hiệu khi yêu cầu bị từ

chối.

Thủ tục cần sử dụng các gói điều khiển chính như

sau: Request packet, Accept packet, Reject packet,

Release packet, Clear packet, Confirm packet.
3.3.3 Phương pháp ước lượng tải tại DiffServ

router

Trong phương pháp được đề xuất trong luận án này sẽ

áp dụng phương pháp ước lượng tải được công bố bởi

S. Jamin. Mỗi router phải ước lượng tài nguyên bị

chiếm bởi các luồng hiện hành, gọi là ŝ, đây là tham

số đầu vào của tập quyết định trong thủ tục CAC.

3.3.4 Xây dựng tiêu chuẩn quyết định

Phần này đã áp dụng Chernoff bound cho các

phân bố của một tổng các biến ngẫu nhiên độc lập để

phân tích và xây dựng được tiêu chuẩn quyết định cho

QoS
request

Request packet

Request packet

Marked request packet

Reject packet

Clear packet

Không đủ

tài nguyên

n+1

n+1

n-1

n-1

Ingress
router

Egress
router

Core
Router

Core
Router

- 11 -

vào thuật toán RED. Phương pháp được đề nghị ở
đây xuất phát từ hai ý tưởng sau:

-

Đưa bộ điều khiển vào tham gia quản lý
hàng đợi.

-

Dùng thuật toán token-bucket có tốc độ
token linh động để thực hiện chức năng

giám sát và hủy gói.

Trên cơ sở đó xây dựng nên cơ chế quản lý hàng

đợi mới, đặt tên là cơ chế quản lý hàng đợi có thể điều

khiển được, dịch sang tiếng Anh là CQM (Controllabe

Queue Management). Dùng cơ chế CQM để thay thế
cho cơ chế AQM (Active Queue Management) và do
đó không dùng RED nữa. Phần cơ bản của phương
pháp là cơ cấu gồm token bucket và bộ điều khiển tạo

thành cặp gắn kết cho cơ chế, trong đó token bucket sẽ

chịu trách nhiệm giám sát và hủy gói tùy vào số token
mà nó đang có, còn bộ điều khiển sẽ điều khiển tốc độ

luồng token đổ vào token bucket tùy vào chiều dài
hàng đợi. Việc thay đổi mức tham chiếu của bộ điều

khiển sẽ là điểm then chốt để thực hiện các lớp con

khác nhau của AF PHB.

3.2.2 Thiết kế cơ chế quản lý hàng đợi CQM bằng

token bucket và bộ điều khiển

Sơ đồ nguyên lý được trình bày trên hình 3.8.

Lượng gói số liệu đi vào hàng đợi trong khoảng thời
gian nào đó tùy vào khả năng tích lủy token của token

- 12 -

bucket trong khoảng thời gian đó. Vì vậy, để quản lý
lưu lượng đi vào hàng đợi thì phải kiểm soát tốc độ

dòng token đổ vào token bucket. Điều chỉnh tốc độ

token hợp lý sẽ quản lý được hàng đợi một cách hiệu

quả và ngăn chặn được tình trạng tắc nghẽn.

Hình 3.8 Mô hình hoạt động của cơ chế quản lý hàng

đợi dùng token bucket và bộ điều khiển.

Tính hợp lý đặt ra ở đây xoay quanh mục tiêu là khi
kích thước hàng đợi còn trống càng nhỏ thì lưu lượng
đổ vào hàng đợi phải càng ít và do đó tốc độ token

cũng phải càng nhỏ. Kịch bản này hoàn toàn phù hợp

với vai trò của một bộ điều khiển. Vì vậy, công việc
điều chỉnh tốc độ token này được giao cho bộ điều

khiển, bộ điều khiển được đặt ở khoảng giữa hàng đợi
và token bucket. Căn cứ vào độ lệch giữa mức tham

chiếu được cấu hình và kích thước của hàng đợi, bộ
điều khiển sẽ phát ra tốc độ token phù hợp để sử dụng

y(t)

q(t)

u(t)

r(t)

v(t)

b

C

Bộ điều

khiển

q

ref

- 25 -

Hình 3.20 Thủ tục báo hiệu kết nối với yêu cầu được

chấp nhận.

Hình 3.20 mô tả hoạt động của thủ tục báo hiệu kết

nối không tường minh trong trường hợp yêu cầu kết

nối được chấp nhận. Khi user gửi yêu cầu đến ingress

router thì router này sẽ phát ra gói yêu cầu để thăm dò

domain, nếu một core router có đủ tài nguyên để chấp

nhận thì nó tiếp tục chuyển yêu cầu này đến router kế

tiếp và tăng tham số n lên một đơn vị, ngược lại nếu
không đáp ứng yêu cầu thì router phải đánh dấu gói

bằng cách dựng một bit cờ và chuyển gói này đi tiếp.

Nếu router nhận được gói bị đánh dấu thì sẽ chuyển
gói đi tiếp mà không làm công việc nào khác. Ở

egress router khi nhận một gói yêu cầu chưa bị đánh

dấu, nếu có đủ tài nguyên thì sẽ tăng tham số n lên

một đơn vị và gửi thông báo chấp nhận cho ingress

router biết. Ngược lại nếu nhận gói yêu cầu bị đánh

- 24 -

3.3.2 Thiết kế cơ chế báo hiệu cho kết nối không
tường minh

3.3.2.1 Khái niệm kết nối không tường minh

Trên thực tế có trường hợp hai thực thể truyền

thông có thể trao đổi thông tin với nhau nhưng giữa

chúng không có một kết nối rõ ràng nào. Trong trường

hợp này có thể xem hai thực thể truyền thông được

nối với nhau bằng một kết nối không tường minh.

3.3.2.2 Thiết kế cơ chế báo hiệu kết nối không

tường minh cho môi trường DiffServ

Về cơ bản thì thủ tục báo hiệu là giữa ingress

router và egress router nhằm hỏi DiffServ domain có

cho một kết nối không tường minh hay không.

Trong chế độ họat động không kết nối, core router

chấp nhận một luồng mới nhưng tải thực sự của luồng

này có thể được định tuyến qua router khác và router

lại có thể tiếp tục cho phép nhiều luồng mới vì tải thực

tế qua nó vẫn còn trong hạn định. Điều này dẫn đến

tình trạng quá tải trong domain. Giải pháp được

nghiên cứu sinh đưa ra là bổ sung một ràng buộc (hay

luật) vào tập tiêu chuẩn quyết định CAC dựa trên số

luồng hiện hành được router cho phép. Để tạo điều

kiện thực hiện ràng buộc bổ sung này, các DiffServ

router phải theo dõi số lượng luồng đã chấp nhận, gọi

là n.

Ingress
router

Core
Router

Egress
router

QoS

request

Request packet

Request packet

Request packet

Accept packet

n+1

n+1

n+1

n+1

Core
Router

- 13 -

hàng đợi hiệu quả và không để xảy ra tình trạng hàng
đợi bị tràn.

Biểu diễn toán học theo mô hình luồng động của

cơ cấu này như sau: (phân tích động học được trình

bày chi tiết trong cuốn luận án)

( )

)

t

(

u

C

)

0

)

t

(

q

(

1

t

q

+

×

>

-

=

·

( )

( )

(

) ( )

( )

úû

ù

êë

é

+

×

>

=

T

t

y

t

r

0

t

v

1

t

u

(3.1)

3.2.3 Áp dụng cơ chế quản lý hàng đợi CQM gồm
token bucket-controller để thực hiện các AFij
trong mạng IP DiffServ

3.2.3.1 Nguyên lý và kiến trúc thực hiện AFij tại

các DiffServ router dùng token bucket_controller

Mục tiêu chính ở đây là thực hiện các lớp PHB phụ

(subclass) hay AFij trong mỗi lớp AF. Theo kiến trúc

DiffServ thì mỗi lớp AF có ba lớp phụ ứng với ba

mức bị chọn để hủy khác nhau. Vì việc thực hiện các

AFij là giống nhau trong các lớp AF nên ở đây chỉ

trình bày phương pháp thực hiện trong một lớp AF. Sơ
đồ nguyên lý được mô tả trên hình 3.13.

Mỗi AFij được thực hiện bằng cơ chế quản lý hàng

đợi có điều khiển CQM gồm một token bucket hai

trạng thái (có tích hợp trạng thái luôn đầy) và một bộ
điều khiển. Như vậy trong mỗi lớp AF sẽ có ba bộ

token bucket-controller. Hệ thống này được thiết kế để

có hai chế độ hoạt động tách biệt gọi là chế độ hoạt

- 14 -

động tự do và chế độ hoạt động có ràng buộc. Chế độ

hoạt động tự do ứng với các khóa K chuyển đến vị trí
0 để kết nối với token bucket luôn đầy CTB (constant
token bucket). Token bucket luôn đầy luôn có đầy đủ
token để chuyển gói số liệu đi. Vì vậy trong chế độ

hoạt động tự do, các gói IP từ tất cả các lớp phụ AFij
đều được chuyển đi mà không bị bất kỳ hạn chế nào.

Chế độ hoạt động này nhắm đến thỏa mãn các nhu cầu

của lưu lượng AF đã được định chế tại các router biên

(theo hợp đồng lưu lượng) trong điều kiện mức độ tải

tại router còn nhẹ.

- 23 -

nhưng chiều dài hàng đợi gia tăng và đạt ổn định tại

một mức xác định xấp xỉ 280. Điều này chứng tỏ đã
đảm bảo điều khiển nghẽn cho hàng đợi đầu ra.

3.3 Giải pháp điều khiển chấp nhận kết nối cho

mạng DiffServ

3.3.1 Giới thiệu đề xuất

Vì các mạng DiffServ hoạt động theo chế độ không

tạo kết nối (connectionless), do đó các router có thể

mắc lỗi khi chấp nhận quá nhiều luồng mới nếu nó chỉ

dựa vào đo lường trên tải hiện hành để thực hiện chức
năng đăng ký. Chưa có một giải pháp nào chú ý đến

vấn đề này và đây cũng là lý do tại sao RMD, PBAC,

GRIP và PCN vấp phải các hạn chế. Trong phần này

sẽ đề xuất một giải pháp điều khiển chấp nhận kết nối

có thể tránh được các hạn chế của các giải pháp khác

nhờ tập trung khắc phục vấn đề nêu trên. Cụ thể là sẽ

bổ sung ràng buộc vào tiêu chuẩn quyết định trong
CAC để hạn chế sự cho phép quá mức số luồng.

Giải pháp được đề nghị gồm có hai phần chính:

- Cơ chế báo hiệu cho kết nối không tường minh.

- Tiêu chuẩn quyết định cho các DiffServ router

thực hiện CAC.

Phương pháp điều khiển chấp nhận kết nối ở đây

được phát triển để hoạt động cho từng PHB riêng biệt

nhằm tương thích với môi trường DiffServ.

- 22 -

a. Động thái của u

1

(t)

b. Động thái của u

2

(t)

c. Động thái của u

3

(t)

d. Động thái của q(t)

Hình 3.19

Động thái của các thành phần trong cơ

cấu.

Từ kết quả trên hình 3.19 dễ dàng nhận thấy, u

2

(t)

và u

3

(t) giảm nhanh xuống 0 tương ứng với tất cả các

gói đến bị hủy hay đánh dấu, như hình 3.19b và 3.19c.
Trong đó, nếu để ý sẽ thấy u

3

(t) giảm nhanh hơn u

2

(t)

và tiếp cận 0 sớm hơn. Điều này có nghĩa là AF

i3

hủy

gói một cách triệt để trước khi AF

i2

làm công việc

tương tự. Cũng nhận ra rằng tốc độ u

1

(t) của AF

i1

giảm nhưng vẫn lớn hơn 350

vì đây là lớp có ưu tiên

cao nhất (xem hình 3.19a).

Kế tiếp, động thái của hàng đợi đầu ra được thể

hiện trên hình 3.19d cho thấy mặc dù lượng tải lớn

- 15 -

Hình 3.13

Sơ đồ nguyên lý thực hiện AFij trong một

lớp AF.

Khi hệ thống rơi vào tình trạng có nguy cơ bị

nghẽn, thành phần được gọi là bộ giám sát AF (AF

monitor) sẽ chuyển khóa K sang vị trí 1 để nối vào
token bucket bên trái, tương ứng với token bucket

chuyển sang làm việc ở trạng thái thông thường của

nó. Lúc này, hệ thống sẽ vào chế độ hoạt động có ràng

Controller

b

2

y

2

(t)

q

ref2

AF

i2

Controller

b

1

y

1

(t)

q

ref1

AF

i1

Controller

b

3

y

3

(t)

q

ref3

AF

i3

u

1

(t)

u

2

(t)

u

3

(t)

r

1

(t)

r

3

(t)

r

2

(t)

Output

C

q(t)

B

Constant

Token

Bucket

Constant

Token

Bucket

Constant

Token

Bucket

0

1

K

0

1

K

0

1

K

v

1

(t)

v

2

(t)

v

3

(t)

AF

Monitor

- 16 -

buộc. Trong chế độ ràng buộc, lưu lượng của các lớp

phụ AFij chịu sự quản lý của token bucket trong sự

cộng tác với bộ điều khiển. Bộ điều khiển sẽ lấy thông

tin về chiều dài hiện hành của hàng đợi qua cơ cấu

phản hồi, từ đó phát ra một tốc độ token hợp lý sao
cho không để hàng đợi bị nghẽn. Token bucket sẽ hủy
hay đánh dấu các gói IP đến nếu không có đủ token để

chuyển chúng vào hàng đợi chung ở đầu ra. Mức hủy

gói của mỗi token bucket thực sự là cụ thể hóa mức độ

bị chọn để hủy (drop precedence) của AFij và mức

hủy này là khác nhau giữa các AFij.

Trong hệ thống này, kích thước hàng đợi tham

chiếu q

ref

(thông số được cấu hình) được dùng như

tham số then chốt để tạo nên các mức hủy gói khác

nhau. Giá trị tham chiếu này càng lớn thì mức hủy gói

càng nhỏ. Do đó, sẽ cấu hình (gán) q

ref1

>q

ref2

>q

ref3

nếu như AF

i1

, AF

i2

và AF

i3

lần lượt là dịch vụ vàng

(Gold service), dịch vụ bạc (Silver service) và dịch vụ
đồng (Bronze service). Các giá trị của q

ref

tùy thuộc

vào mức độ khác biệt muốn tạo ra giữa các lớp phụ

AFij của nhà cung cấp dịch vụ.

3.2.3.4 Mô hình động học của cơ cấu thực hiện các

AFij

Động học của hệ thống theo mô hình luồng động

được biểu diễn như sau:

- 21 -

Hình 3.18- Cải thiện hiệu quả sử dụng khi nâng mức

tham chiếu q

ref

.

3.2.4.2 Kết quả mô phỏng và đánh giá phương

pháp thực hiện AFij được đề xuất

Để minh chứng cho tính khả thi của giải pháp thực

hiện AFij được đề xuất, hệ thống đã được mô phỏng

trên máy tính dùng phần mềm Matlab. Mục đích của

mô phỏng gồm: kiểm chứng sự khác biệt giữa các

AFij trong hệ thống, khảo sát tính ổn định của hệ

thống và khả năng điều khiển nghẽn. Quá trình khảo

sát tập trung vào biểu hiện của tốc độ lưu lượng đầu ra

của token bucket hay các u

i

(t), biểu hiện động thái của

hàng đợi cổ chai (hàng đợi chia sẻ) ở đầu ra.

Trong kịch bản mô phỏng ở đây giả sử hàng đợi

(bộ đệm) đầu ra có kích thước 500 gói; tất cả các
token bucket đều có thể chứa đến 50 token; tốc độ của

liên kết đầu ra là C = 150 gói/giây.

Theo đề nghị 1, chọn q

ref1

= B- (b

1

+b

2

+b

3

) = 500 –

150 = 350, q

ref2

= 250 và q

ref3

= 200.

Thực hiện chỉnh định theo phương pháp Ziegler-

Nichols thứ hai và xác định được tham số điều khiển

K

p

» 3.14, K

I

= 0.7

- 20 -

b=20.

Tuy nhiên, chúng ta có thể cải thiện được tình trạng

này một cách dễ dàng nếu như ép q

ref

thêm một lượng

thích hợp. Lúc này tham số q

ref

có thể đóng vai trò

như một tham số chỉnh định. Tham số này có thể lấy

giá trị lớn hơn giá trị chiều dài thực tế của hàng đợi
sao cho cơ cấu sử dụng hết bộ đệm đầu ra. Ví dụ trong
trường hợp b = 20, có thể cấu hình q

ref

= 530 và đạt

được mức sử dụng như trên hình 3.18,

nâng mức sử

dụng ổn định từ 310 lên xấp xỉ 360.

Qua kết quả mô phỏng trên cho thấy hệ thống

hoàn toàn khả thi và hoạt động ổn định. Cơ chế không

những đảm bảo về điều khiển nghẽn trên hàng đợi cổ

chai mà còn giúp cải thiện hiệu suất sử dụng.

- 17 -

( )

( )

t

C

)

0

)

t

(

q

(

1

t

q

3

1

i

i

u

å

=

·

+

×

>

-

=

( )

( )

(

)

( )

( )

ú

ú

û

ù

ê

ê

ë

é

+

×

>

=

T

t

t

0

t

1

t

y

r

v

u

i

i

i

i

(3.7)

Trong đó, T là khoảng thời gian truyền liên tục và

C là băng thông của liên kết đầu ra. Giá trị C này sẽ
được gán cố định cho một lớp AF nào đó theo đặc tả

của kiến trúc DiffServ.

Từ (3.7) ta thấy rằng u

i

(t)

» 1(v

i

(t)>0)r

i

(t) nếu T có

giá trị đáng kể và với bất kỳ thang thời gian xem xét

nào ta luôn có:

[

]

)

t

(

)

t

(

)

0

)

t

(

(

1

)

t

(

y

r

v

u

i

i

i

max

i

+

×

>

=

(3.8)

với T lấy giá trị đơn vị của thang thời gian xem xét.

Xem u

i

(t)=u

i

(t)

max

là trường hợp xấu nhất vì là ứng

với trường hợp hàng đợi chia sẻ bị làm đầy với tốc độ

lớn nhất. Để có tính tổng quát, ở đây sẽ đánh giá hệ

thống theo trường hợp xấu nhất này.

Do đó, động học của hàng đợi cổ chai là

( )

[

]

)

t

(

)

t

(

)

0

)

t

(

(

1

C

)

0

)

t

(

q

(

1

t

q

y

r

v

i

i

i

3

1

i

+

×

>

+

>

-

=

å

=

·

(3.9)

(các phân tích chi tiết được trình bày trong cuốn luận
án)
3.2.3.5 Điều kiện áp dụng CQM vào thực hiện AFij

và hệ quả

- 18 -

Đề nghị 1: Giả sử hàng đợi có kích thước B gói và
kích thước thùng chứa của các token bucket lần lượt là

b

1

, b

2

và b

3

. Để bộ đệm không bị tràn, q

ref1

nên cấu

hình như sau:

å

-

=

3

1

1

b

q

i

ref

B

(3.13)

Đề nghị 1 có mục đích đơn giản là tạo ra một

khoảng không gian dự phòng trên hàng đợi cho trường

hợp có lượng gói nhập quá mức do số token thừa.
Đề nghị 2: Trong chế độ hoạt động có ràng buộc, để
đạt được khả năng chia sẻ tài nguyên giữa các dịch vụ,

cần giám sát thường xuyên và điều chỉnh các q

ref

của

các AF

ij

theo lưu đồ giải thuật được trình bày chi tiết

trong cuốn luận án.

3.2.4 Kết quả của giải pháp được đề xuất

3.2.4.1 Kết quả mô phỏng và đánh giá khả năng

của cơ chế quản lý hàng đợi CQM dùng token

bucket và bộ điều khiển

Để phục vụ cho việc mô phỏng đánh giá cơ chế

quản lý hàng đợi CQM (hình 3.8), ở đây chọn loại bộ
điều khiển thông dụng PI có sẵn trong phần mềm

MATLAB Simulink. Giả sử hàng đợi có kích thước

500 gói, token bucket có b =50 gói, tốc độ truyền của

liên kết đầu ra C=150 gói/giây. Sử dụng phương pháp

chỉnh định Ziegler-Nichols xác định được các hệ số

K

p

» 3,14 và K

I

= 0,7 để tiến hành mô phỏng. Mục

- 19 -

đích và kịch bản mô phỏng như sau: mô phỏng hoạt
động của cơ chế quản lý hàng đợi có điều khiển gồm

một bộ token bucket-controller và một hàng đợi cổ
chai. Qua đó xác định động thái của hàng đợi cổ chai
để đánh giá tính ổn định của cơ chế và khả năng điều

khiển nghẽn cũng như cải thiện hiệu quả sử dụng tài

nguyên.

Động thái của chiều dài hàng đợi q(t) được trình

bày trên hình 3.16, hình cho thấy số lượng gói trong
hàng đợi thoạt đầu tăng nhanh lên đến mức tối đa, sau
đó giảm xuống và ổn định ở mức xấp xỉ 360.

Để kiểm tra tác động của kích thước thùng

(bucket) của token bucket đến cơ chế như thế nào,

giảm giá trị b xuống còn 20, lúc này kết quả mô phỏng

cho thấy hàng đợi q(t) ổn định ở mức xấp xỉ 310 như

trên hình 3.17. Như vậy, b càng nhỏ thì dung lượng
hàng đợi được dùng càng giảm. Trong khi đó, thường

thì y(t) nhỏ hơn b trong quá trình token bucket hoạt
động nên sẽ không tận dụng hết hàng đợi.

Hình 3.16 Động thái của

q(t) tương ứng với b=50.

Hình 3.17 Động thái

của q(t) tương ứng với