Nghiên cứu cải thiện diffserv qos trong mạng ip (tt)

-1-

TẬP ĐỒ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-

- 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.

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


- 34 -

-3-

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

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

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

triển khai DiffServ vẫn chưa đầy đủ các lớp dịch vụ

bình khoảng 0,35 (chỉ mơ phỏng độc lập tại tầng

như đặc tả, từ đó việc cung cấp QoS trên mạng IP

mạng, không kết hợp cơ chế hỗ trợ ở tầng giao

chưa được phổ biến, phần lớn các phiên truyền thông

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

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

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

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

-4

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

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

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

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

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

phục.

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

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

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

nguyên nhân nổi trội. Nguyên nhân thứ nhất thuộc về

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

phương pháp hiện thực DiffServ hiện nay; theo gợi ý

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

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

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

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

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

dịch vụ khác biệt, nhưng các nghiên cứu cho thấy

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

cách dùng RED có khó khăn. Bản thân RED không

truyền thống. Nếu thực hiện bằng phần mềm cần đánh

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

giá độ phức tạp của thuật toán CQM bao hàm thuật

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

toán token bucket động.

tham số hoạt động cho nó mà khơng ảnh hưởng xấu

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

đến phẩm chất của mạng. Nguyên nhân thứ hai là

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

DiffServ của IETF không cung cấp cơ chế end-to-end

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

QoS và khơng có phương pháp điều khiển các lớp

giải phóng tài ngun khơng tường minh trong mạng

QoS giữa các nhà điều hành mạng khác nhau. Thực tế,

theo chế độ connectionless, từ đó xây dựng mơ hình

ứng dụng của người dùng khơng có cách gì để u cầu

định lượng hợp lý làm cơ sở áp dụng các thủ tục điề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-

- 33 -

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

Kết quả là hàng đợi được duy trì với độ dài ổn

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

định, bộ đệm khơng bị tràn. Có thể thay đổi độ dài

bảo.

ổn định của hàng đợi bằng cách thay đổi giá trị

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à

tham chiếu qref 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 qref.
2. Áp dụng cơ chế quản lý hàng đợi CQM thực hiện

phạm vi nghiên cứu trong luận án như sau:

các lớp dịch vụ AF (AFij) cho mạng DiffServ.

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

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

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

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

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

các lớp dịch vụ khác biệt AFij trong mỗi DiffServ

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

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

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

biệt một cách dễ dàng như dự kiến, điều chỉnh

hiện và cơ chế hoạt động, với hai mục tiêu chủ yếu là :

được một cách linh động. Bộ đệm ngõ ra được sử

Đề xuất giải pháp thuận lợi hiệu quả để thực hiện các

dụng với một mức ổn định theo cấu hình, khơng

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

xảy ra hiện tượng nghẽn. Tài nguyên được sử

chấp nhận kết nối (CAC) cho DiffServ domain.

dụng hiệu quả vì khi một lớp dịch vụ ở trạng thái

Đối tượng và phạm vi nghiên cứu

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

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

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

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

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

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

DiffServ domain, gồm tập tiêu chuẩn quyết định

router và cơ chế đảm bảo end-to-end QoS.

cục bộ có bổ sung ràng buộc trên số luồng nhằm

Phương pháp nghiên cứu

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

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

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

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

không tường minh phù hợp với tiêu chuẩn quyết

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

định cục bộ này để cộng tác thực thi thủ tục CAC.

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

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


- 32 -

-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ụ tố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
Hình 3.25 Đồ thị tương quan giữa xác suất mất gói
và hiệu suất.

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

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

Giá trị

Packet size 125 bytes

đầ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

Burst time

400 ms

Idle time

325 ms

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

Data rate

64 kbps

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

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.

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

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-

- 31 -

tạo triển vọng cung cấp end-to-end QoS cho mạng
DiffServ một cách đơn giản.

s

0.5e-6, 0.6e-6, 0.7e-6, 0.8e-6, 0.9e-6, 1e6,1.1e-6, 1.2e-6, 1.3e-6, 1.4e-6, 1.5e-6,

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

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

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

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

trang
Chương 3- Đề xuất các giải pháp nhằm cải thiện
IP theo kiến trúc

QoS cho mạng

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

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

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

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

dịch vụ qua giảm xác suất mất gói mà vẫn đảm bảo

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

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

: 20 trang

3.4 Kết luận : 1 trang

đượ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

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

hưởng đến chất lượng phục vụ, cụ thể là khi tỉ lệ burst

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

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

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

quả mô phỏng cũng chứng tỏ rằng tham số s thực sự

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

đó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 -

-7-

đầu

30

60
90
120
150
180

35.10-3
65.10-3
95.10-3
12,5.10-

3

3

15,5.10-

15,5.10-

3

3

thất gói (packet loss).

-

-

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

16,9.10

210
240

300

18,5.10

21,5.103

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,

24,5.10

2

3

25,2.10-

27,5.10-

2

3

-

-4

1.10

4,9.10-4

2

38,7.10

420

-

36,5.10

-

2

3

39,4.10-

10,3.10-

2

4

-

-

40,9.10

42,5.10

2

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

số

mạng IP

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ế

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

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

3

35,4.10-

390

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

74,4.10-

2

360

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

3

32,8.10

330

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

3

17.4.10

270

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

35.10-3
65.10-3
95.10-3
12,5.10-

Các giá trị

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-

- 29 -

nhau cho khách hàng cũng như cho các dịng lưu

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

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

dẫn chuyển gói cho từng PHB. Hiện có hai PHB được

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

định nghĩa là EF (Expedited Forwarding), AF

(packet loss probability) trong trường hợp khơng có

(Assured Forwarding).

điều khiển chấp nhận kết nối được mơ tả trong hình

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à

Công việc phát triển một hệ thống DiffServ liên

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

quan đến tổ chức và phát triển hai thành phần chính là

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

bộ điều chỉnh lưu lượng (traffic conditioner) tại router

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

biên (edge router) và các PHB tại các router, đặc biệt

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

là các router bên trong (core router).

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

Mỗi PHB được thể hiện qua hai cơ chế: cơ chế

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

quản lý hàng đợi và cơ chế lập lịch gói. Trong đó,
ngun 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.

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
tố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 -

-9-

3.3.5 Hoạt động điều khiển chấp nhận kết nối theo

Điều này không phải lúc nào cũng dễ dàng trên mạng

phương pháp được đề xuất

thực tế, khi mà nhu cầu kết nối cũng như lưu lượng

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

luôn biến động. Đây cũng là lý do vì sao các triển khai

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

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

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

các dịch vụ như trong đặc tả. DiffServ vẫn đang cần

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

có các giải pháp thực tế hơn để việc triển khai được dễ

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

dàng và hoạt động bền vững hơn.

CAC. Các router sẽ áp dụng tiêu chuẩn quyết định đã

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

được xây dựng để thực hiện thủ tục CAC cục bộ trên

DiffServ

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

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

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

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

Ingress router

Core router

sự yếu kém này, có nhiều đề xuất bổ sung cơ chế kiểm

Egress router

Nguồn

Đích
10Mbps

10Mbps

sốt đăng ký tài ngun 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

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.

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

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

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

hiện hữu

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

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

hạn chế cần phải vượt qua để trở thành hiện thực. Bổ

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

sung cơ chế điều khiển chấp nhận cho DiffServ là điều

trong bảng 3.1.


- 10 -

- 27 -

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

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

pháp QoS hồn chỉnh cho mạng IP.

trong cuốn luận án)

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 tố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

m
ì
ï(n + 1) £
1
×r
ï
1 m
ï
2 - sp

í
e
ï
^
ï sp ỉ
ư
ïe × ỗố S + rm ữứ Ê m
ợ

(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
rm 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

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

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

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

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

trong mỗi lớp con lại được chia ra thành ba mức ưu

chấp nhận nếu n và rm thỏa mãn đồng thời hệ bất đẳng

tiên, như vậy AF PHB có 12 mức dịch vụ, ở đây tạm

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

gọi là các AFij trong đó iỴ[0,3] và jỴ[0,2], việc thực

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

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

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


- 26 -

- 11 -

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

vào thuật tốn RED. Phương pháp được đề nghị ở

cho ingress router (hình 3.21) .

đây xuất phát từ hai ý tưởng sau:

n+1

Ingress
router

Core
Router
Request packet

QoS
request

n+1

Core
Router

Không đủ
tài nguyên

Egress
router

Request packet
Marked request packet
Reject packet

-

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

-

Dùng thuật tố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

Clear packet
n-1

Hình 3.21

n-1

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ư

đợ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

sau: Request packet, Accept packet, Reject packet,

pháp là cơ cấu gồm token bucket và bộ điều khiển tạo

Release packet, Clear packet, Confirm packet.

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

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

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 -

- 25 -

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 số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.
r(t)

qref

Bộ điều
khiển

b
y(t)
v(t)

C

u(t)

q(t)

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 hồn tồ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

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 u cầu để thăm dị
domain, nếu một core router có đủ tài ngun để chấp
nhận thì nó tiếp tục chuyển 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 -

- 13 -

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

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

tường minh

đợi bị tràn.

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

Biểu diễn tốn học theo mơ hình luồng động của

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

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

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

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

q(t ) = - 1(q ( t ) > 0) × C + u ( t )
y (t ) ù
é
u (t ) = 1(v(t ) > 0 ) × ê r (t ) +
T úû

ë

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

(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

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.

các DiffServ router dùng token bucket_controller

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

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

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

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

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

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

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

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

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

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

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

trình bày phương pháp thực hiện trong một lớp AF. Sơ

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

đồ ngun lý được mơ tả trên hình 3.13.

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

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

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

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

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

trạng thái (có tích hợp trạng thái luôn đầy) và một bộ

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

điều khiển. Như vậy trong mỗi lớp AF sẽ có ba bộ

là n.
Ingress
router

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

Core
Router

n+1

Core
Router

n+1

Request packet
QoS
request

n+1

Request packet
Request packet
Accept packet

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

Egress
router


- 14 -

- 23 -

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

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

hoạt động tự do ứng với các khóa K chuyển đến vị trí

một mức xác định xấp xỉ 280. Điều này chứng tỏ đã

0 để kết nối với token bucket luôn đầy CTB (constant

đảm bảo điều khiển nghẽn cho hàng đợi đầu ra.

token bucket). Token bucket ln đầy ln có đầy đủ

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

token để chuyển gói số liệu đi. Vì vậy trong chế độ

mạng DiffServ

hoạt động tự do, các gói IP từ tất cả các lớp phụ AFij

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

đều được chuyển đi mà khơng bị bất kỳ hạn chế nào.

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

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

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

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

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

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

dựa vào đo lường trên tải hiện hành để thực hiện chức

tại router cịn nhẹ.

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 -

- 15 -

Controller

Constant
Token
Bucket

r1(t)
b1

y1(t)

qref1
1

K

0
u1(t)

AFi1

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

v1(t)

b. Động thái của u2(t)
Controller

r2(t)
Constant
Token
Bucket

b2
qref2

y2(t)
1

K

0
u2(t)

AFi2

C

v2(t)

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

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

Độ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, u2(t)

q(t) Output
Controller

r3(t)

Constant
Token
Bucket

Hình 3.19

b3
qref3

y3(t)
1

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

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

AF
Monitor

0
u3(t)

AFi3
v3(t)

gói đến bị hủy hay đánh dấu, như hình 3.19b và 3.19c.
Trong đó, nếu để ý sẽ thấy u3(t) giảm nhanh hơn u2(t)

K

Hình 3.13

B

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

gói một cách triệt để trước khi AFi2 làm cơng việc

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

tương tự. Cũng nhận ra rằng tốc độ u1(t) của AFi1

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

giảm nhưng vẫn lớn hơn 350 vì đây là lớp có ưu tiên

monitor) sẽ chuyển khóa K sang vị trí 1 để nối vào

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

token bucket bên trái, tương ứng với token bucket

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

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

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

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


- 16 -

- 21 -

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

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

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

tham chiếu qref.

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

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

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

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

phản hồi, từ đó phát ra một tốc độ token hợp lý sao

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

cho không để hàng đợi bị nghẽn. Token bucket sẽ hủy

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

hay đánh dấu các gói IP đến nếu khơng có đủ token để

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

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

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

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

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

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

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

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

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

Trong hệ thống này, kích thước hàng đợi tham
chiếu qref (thơng số được cấu hình) được dùng như

của token bucket hay các ui(t), biểu hiện động thái của
hàng đợi cổ chai (hàng đợi chia sẻ) ở đầu ra.

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

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

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

(bộ đệm) đầu ra có kích thước 500 gói; tất cả các

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

token bucket đều có thể chứa đến 50 token; tốc độ của

nếu như AFi1, AFi2 và AFi3 lần lượt là dịch vụ vàng

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

(Gold service), dịch vụ bạc (Silver service) và dịch vụ

đồng (Bronze service). Các giá trị của qref tùy thuộc
vào mức độ khác biệt muốn tạo ra giữa các lớp phụ

Theo đề nghị 1, chọn qref1 = B- (b1+b2+b3) = 500 –
150 = 350, qref2 = 250 và qref3 = 200.
Thực hiện chỉnh định theo phương pháp Ziegler-

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

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

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

Kp » 3.14, KI = 0.7

AFij
Động học của hệ thống theo mơ hình luồng động
được biểu diễn như sau:


- 20 -

- 17 -

·

q (t ) = - 1(q ( t ) > 0) × C +

b=20.

å u (t )
3

i

i =1

é

u (t ) = 1(v (t ) > 0) × êr (t )
i

i

êë

i

y (t )ù

+

i
ú
T úû

(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ẽ
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 qref thêm một lượng
thích hợp. Lúc này tham số qref 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 qref = 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
hồn tồ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ổ

đượ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 ui(t) » 1(vi(t)>0)ri(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 ln có:
u i (t ) max = 1( vi ( t ) > 0) ×

[r (t)
i

+

y ( t )]
i

(3.8)
với T lấy giá trị đơn vị của thang thời gian xem xét.
Xem ui(t)=ui(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 qt, ở đâ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à

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

q (t ) = - 1(q ( t ) > 0) C +

å 1(v (t ) > 0) × [r (t )
3

i =1

i

i

+

y ( t)]
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 -

- 19 -

Đề nghị 1: Giả sử hàng đợi có kích thước B gói và

đích và kịch bản mơ phỏng như sau: mơ phỏng hoạt

kích thước thùng chứa của các token bucket lần lượt là

động của cơ chế quản lý hàng đợi có điều khiển gồm

b1, b2 và b3. Để bộ đệm không bị tràn, qref1 nên cấu

một bộ token bucket-controller và một hàng đợi cổ

hình như sau:

chai. Qua đó xác định động thái của hàng đợi cổ chai

q

ref

1

=

B

-

3

å b

i

1

để đánh giá tính ổn định của cơ chế và khả năng điều

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

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

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

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

ngun.

hợp có lượng gói nhập q mức do số token thừa.

bày trên hình 3.16, hình cho thấy số lượng gói trong

Đề nghị 2: Trong chế độ hoạt động có ràng buộc, để

hàng đợi thoạt đầu tăng nhanh lên đến mức tối đa, sau

đạt được khả năng chia sẻ tài nguyên giữa các dịch vụ,

đó giảm xuống và ổn định ở mức xấp xỉ 360.

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

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

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

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

trong cuốn luận án.

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

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

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

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

trên hình 3.17. Như vậy, b càng nhỏ thì dung lượng

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

hàng đợi được dùng càng giảm. Trong khi đó, thường

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

thì y(t) nhỏ hơn b trong quá trình token bucket hoạt

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

động nên sẽ không tận dụng hết hàng đợi.

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ố
Kp » 3,14 và KI = 0,7 để tiến hành mơ phỏng. Mục

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